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

Previous Next

Full log

View this message in rfc822 format

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

João Távora <joaotavora <at> gmail.com> writes:

> 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 a 2.5M Elisp file with 0 shorthand prefixes, after 30s of pressing
C-v (scroll-up-command), point was on line 19238.

I then tried the same file with 1 and 4 shorthands, and I got basically
the same result:

| With 1 shorthand prefix |       |
|-------------------------+-------|
| No patch                | 19447 |
| mismatch                | 19238 |
| compare all prefixes    | 19024 |

| With 4 shorthand prefixes |       |
|---------------------------+-------|
| No patch                  | 19211 |
| mismatch                  | 19521 |
| compare all prefixes      | 19339 |

There is a big margin of error (probably around 500-1000 lines) since my
method wasn't at all exact. I stopped holding C-v when the stopwatch on
another device hit 30s, and I might have held for ±1s.

If this approach to benchmarking is valid, I think it indicates that
shorthands has no significant effect on performance in either case,
though there may be a greater difference with more shorthand prefixes.

> My version keeps a behaviour that can be considered buggy.
> If a shorthand prefix has a common suffix with the longhand prefix
> then that suffix will not be highlighted. Like:

> ;; Local Variables:
> ;; read-symbol-shorthands: (("bcrumb-" . "breadcrumb-")
> ;; End:

> Here only "b" would be highlighted, effectively showing the user
> how much typing was saved.  Is this wrong?  Does it makes sense
> to use shorthands like this?

Another example case:

;; Local Variables:
;; read-symbol-shorthands: (("aw-" . "ace-window-")
;; End:

Here only "a" would be highlighted.

Thanks,

Joseph

Previous Next

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