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

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

bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses sa


From: Joseph Turner
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@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





reply via email to

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