bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9218: 24.0.50; bidi-display-reordering slowdown


From: Florian Beck
Subject: bug#9218: 24.0.50; bidi-display-reordering slowdown
Date: Mon, 01 Aug 2011 22:38:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Florian Beck <abstraktion@t-online.de>
>> Cc: abstraktion@t-online.de,  9218@debbugs.gnu.org
>> Date: Mon, 01 Aug 2011 21:34:30 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Does setting bidi-paragraph-direction to left-to-right solve the
>> >> problem?
>> >
>> > I meant without resetting bidi-display-reordering to nil, of course.
>> 
>> The file opens just as fast as with bidi turned of, yes. Scrolling is
>> still somewhat erratic: scrolling down takes 12s the first time
>
> By "scrolling down" you mean all the way to the end, or just one
> screenful?

`scroll-up-command'

And `end-of-buffer' takes the same time (12s vs 1s).

But it does not matter really. ANY command takes several seconds in that
buffer, e.g. C-h k <up> or C-x C-b – whereas they are instantanious with
bidi turned off.

In fact <NEXT> may even be slowed down because of fontification going on
(it only is slow the first time). Other commands are reproduciable.
Strange. C-h k is instantenious, but C-h k <up> takes several seconds to
complete. Happens also when selecting the other window (*Help*) with the mouse 
or
when running C-h k <up> in the other window.

Once the large buffer is no longer displayed in any window, the speed
returns to normal (as in before bidi).

>
>> then, after `(beginning-of-buffer)' it only takes ~1s (as usual for
>> that file). But I can live with that.
>> 
>> But that still requires me to set a per file variable.
>
> I think Org Mode should set bidi-paragraph-direction in all its
> buffers.  Can you see any disadvantages to such a solution?

Personally, no. People writing right-to-left prose might, though.

I just don't understand why it has to be that slow. I have paragraphs of
reasonable length. Is it because of the folded display? (But then there
are only some 6000 visible lines which should be fast in any case.) Org
mode does quite a bit of fontification, i.e. it already parses the
buffer. Is there a way for org mode to tell the display engine where a
new paragraph should be considered, what is to be displayed RtL or LtR,
etc?

-- 

Florian Beck





reply via email to

[Prev in Thread] Current Thread [Next in Thread]