GNU bug report logs - #67390
28; shorthands-font-lock-shorthands assumes shorthand uses same separator

Previous Next

Full log

Message #32 received at 67390 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Joseph Turner <joseph <at> ushin.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 67390 <at> debbugs.gnu.org, Adam Porter <adam <at> alphapapa.net>,
 Jonas Bernoulli <jonas <at> bernoul.li>
Subject: Re: 28;
 shorthands-font-lock-shorthands assumes shorthand uses same separator
Date: Sun, 26 Nov 2023 22:02:01 +0000

On Sun, Nov 26, 2023 at 8:38 PM Joseph Turner <joseph <at> ushin.org> wrote:
>
> João Távora <joaotavora <at> gmail.com> writes:
>
> > On Sat, Nov 25, 2023 at 10:43 PM Joseph Turner <joseph <at> ushin.org> wrote:

> > So, benchmarking it will have to be, I'm afraid, because AFAIK
> > font-locking is a very performance sensitive area of Emacs.
>
> Yes.  I would like to learn how to do this!

I'm CCing Eli.

In the past, ISTR, Eli suggested to benchmark such things by visiting a
very large file in its beginning, then scrolling down by holding
the down arrow or PgDn for some fixed time period, like 30 seconds.
The  Emacs that scrolls the farthest is the most performant.  Not
entirely fail-proof (other processes may interfere, etc), but not
bad either.

So here you could create very large fictitious Elisp file with 0, 1, 3 and
10 shorthands each and then run your version vs my version and record
the final line numbers.  Then show the files and the numbers.

> > In the meantime I will push my patch, but keep the bug open to see
> > if it is worth pushing Joseph's version.
>
> Thank you!!

Now done in 36941e9e6a (master).

> I'm happy to discuss this further if others are interested.

I'm keeping this open.

João

Previous Next

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