GNU bug report logs - #30457
26.0.91; bidi-display-reordering makes navigation around melpa/archive-contents slow

Previous Next

Package: emacs;

Reported by: Aaron Jensen <aaronjensen <at> gmail.com>

Date: Wed, 14 Feb 2018 16:51:01 UTC

Severity: normal

Merged with 3219, 4123, 9589, 13675, 15555, 18530, 22143, 24523, 32523, 40007

Found in versions 23.1, 24.2, 24.2.93, 24.3, 24.5, 26.0.91, 27.0.50, 28.0.50

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30457 <at> debbugs.gnu.org
Subject: bug#30457: 26.0.91; bidi-display-reordering makes navigation around melpa/archive-contents slow
Date: Thu, 15 Feb 2018 10:49:23 -0800
Recapturing thread that accidentally went private...

On Wed, Feb 14, 2018 at 7:37 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > So is this bug a WONTFIX then?
> It isn't WONTFIX, I just don't know how to make the BPA implementation
> faster with such long lines and deeply nested parentheses.  It already
> includes all the optimizations I could think of.  But maybe someone
> else will find a way to optimize it more.

I'm only just now learning about BPA, so I apologize if this is a
silly question, but would it be any faster to scan a buffer and
determine that there are no rtl characters so parentheses matching is
unnecessary?

> > And/or does it fall into the general "emacs is not super optimized
> > for long lines" thing?
> It does, sort of.  At least near the end of the buffer you clearly see
> that bidi-display-reordering has a much smaller effect, in relative
> terms.

Yeah, I wasn't aware that the end of the buffer had more slowness, but
that's good to know.

Thanks,

Aaron




This bug report was last modified 2 years and 298 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.