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

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

bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.e


From: Juri Linkov
Subject: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el
Date: Thu, 04 Mar 2021 11:24:30 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)

>> Reusing visited files is a nice feature, but still needs a fix.
>> Test case: visit emacs/src/xdisp.c and type
>>    C-x p g expose_frame RET
>> See that not all lines from xdisp.c have font-lock highlighting.
>> After applying this patch, all xref output lines from xdisp.c
>> have font-lock faces:
>
> I thought about this, but applying font-lock rules is not exactly a trivial
> action. So I figured we better avoid it (and only call syntax-propertize
> when necessary) to get the best performance possible.
>
> Have you tried benchmarking with and without your patch? Particular case of
> interest: many files, each already visited, with 1 match in each of
> them. Or few matches.
>
> The opposite would be one file with many matches inside of it. This case
> should be relatively inexpensive for this patch, but it's worth measuring
> to compare too.
>
> P.S. The "(unless syntax-needed" guard in the proposed patch is not needed.

;; Without patch
(benchmark-run 10 (project-find-regexp "expose_frame")) ;; (1.936206149 21 
0.27307954999999995)

;; With patch without the "(unless syntax-needed" guard
(benchmark-run 10 (project-find-regexp "expose_frame")) ;; (2.195018443 31 
0.354854643)

I don't know if extra font-locking is worth worse performance.
But I took this idea for consistency from occur that uses
'font-lock-ensure' in 'occur-engine-line'.





reply via email to

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