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

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

bug#18778: noticeable slowdown for buffers with long lines, word-wrap, a


From: Ivan Shmakov
Subject: bug#18778: noticeable slowdown for buffers with long lines, word-wrap, and brackets
Date: Mon, 20 Oct 2014 19:17:28 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Package: emacs
X-Debbugs-Cc: Eli Zaretskii <eliz@gnu.org>

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

[…]

 > In addition, one of the new UBA features, the so-called Bidirectional
 > Parentheses Algorithm (BPA), affects pure-ASCII text as well, and
 > specifically editing of program sources (which widely use parentheses
 > and brackets of several kinds).

 > The result is some small slowdown -- a few percents in my testing --
 > in redisplay operations.  If more significant slowdown will be
 > reported in some special cases, I will try to find optimizations to
 > countermand that.

        It seems that I’ve just found such a case for 13a3ad6b39c0.

        To reproduce:

        • create a buffer with long lines (see below for the example
          I’ve used), and (setq word-wrap t line-move-visual nil) there;

        • now, enclose every line in [, ] brackets (as in: M-x
          replace-regexp RET .* RET [\&] RET; parentheses or curly
          braces also exhibit the issue.)

        For the resulting buffer, operations like (next-line) or even
        (recenter) now result in a noticeable delay.

        The issue doesn’t appear when word-wrap is not used, or when
        there’s no brackets in the buffer.  Neither the issue appears in
        Emacs built 2014-10-09 from a then-recent Git clone.

        I’ve used the output of the following Shell command as a test.

$ head -n 8192 < /usr/share/dict/american-english | fmt -w 1024 

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A





reply via email to

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