GNU bug report logs - #46859
28.0.50; [PATCH]: Add option to truncate long lines in xref.el

Previous Next

Full log

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Dmitry Gutov <dgutov <at> yandex.ru>, juri <at> linkov.net, 46859 <at> debbugs.gnu.org
Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines
 in xref.el
Date: Sun, 07 Mar 2021 21:03:09 +0100

Hi!

>
> Please try out the attached preparation patch.
>
> It improves the performance of the "very long line" case drastically 
> over here, while not doing any truncation yet. Looks like we regressed 
> that case when we added rendering of multiple matches on the same line.
>

Yes, this seems to help a lot. Now the search is down from 11 seconds to
1.09. It is comparable to the other good efforts. 

> We can add the truncation feature on top of it.

I think we should, since moving around in the xref-buffer is still very slow.

>
> Probably also in xref--collect-matches-1 (truncating the value of 
> SUMMARY just before the xref-make-match call).
>
> Alternatively, we could experiment with hiding parts of the long line 
> using some display/visibility features (except the truncate-lines 
> variable, that one keeps things slow). That could be done in 
> xref--insert-xrefs or somewhere nearby. That is trickier, though, given 
> that we'll probably want to unhide it (wholly or partially) when 
> iterating over matches inside.

At this point I'm really thinking that truncating without bothering too
much about losing information is worth it, and the added complexity by
retaining information would only make regressions more feasible. I
assume these files are _actually_ read once every blue moon. To maximize
the speedup should be at a higher priority than retaining the matches,
IMO. In any case, if there is a hit on one of these long lines, the
current efforts will render them as results to the xref
buffer. Searching or editing these files wouldn't be emacs' strength
anyways :)

My proposal for the "best" fix would be:

- truncating long lines by default, both for grep and ripgrep
- adding some variation of the "-M <n>" value for ripgrep by default

What do you think?

--
Theo

Previous Next

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