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

Previous Next

Full log

View this message in rfc822 format

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

Hi Theodor,

On 03.03.2021 21:54, Theodor Thornhill via Bug reports for GNU Emacs, 
the Swiss army knife of text editors wrote:
> Hi again,
> 
>>> I tried another approach which yielded some nice results.
>>
>> Thank you.
>>
>> Could you also try this benchmark with an input string that has no more
>> than, say, 3 matches in the big one-line file? Or maybe just 1.
>>
>> I'd like to compare the relative performance in such scenario, too.
>>
> 
> Curiously, it doesn't seem to affect things much, neither for your patch
> or mine.

I just got around to testing this properly (sorry), and so far I've been 
able to reproduce the slow behavior only when there are many matches in 
the "big long line" file. I'm using a 500KB minified CSS as an example.

When there are only a few matches, the search is relatively 
instantaneous. So that's a weird mismatch with your reports. If you have 
some details to add to reproduce the slowdown in the "few matches" case, 
that could be helpful too.

I'm currently looking at the patch and trying to figure out whether we 
could apply some smaller change, or a change not in xref--insert-xrefs 
(which is relatively complex already) with the same benefits.

Also:

- Could you explain the change to xref--collect-matches-1 in the most 
recent patch? In my testing it doesn't move the needle at all, and it 
seems unnecessary because neither Grep or Ripgrep report matches on the 
same line separately with the current arguments that we pass to them. 
But if we did... what's the idea? Skip all subsequent matches, no matter 
if they're far or close?

- What do you think about making an effort to actually retain all the 
matches in the output? That would mean interpreting the 
xref-truncate-line-to value (or however the var could be renamed) as the 
maximum number of chars to render on the line *per match*. And if there 
is too much text between them, those parts can become "(truncated...)". 
Your current implementation can cut off valid matches, and we probably 
want to preserve them if feasible. OTOH, the default value could go down 
to 200 with this approach.

>>> In addition, we could add another
>>> defcustom for the xref--collect-matches-1 function,
>>
>> That can be done already by the user customizing
>> xref-search-program-alist, I think.
> 
> Oh? How so?

One can add " -M300 --max-columns-preview" in the middle of the ripgrep 
entry in xref-search-program-alist, as well as set xref-search-program 
to 'ripgrep'.

What I mean is, we can provide the "fullest featured" default behavior, 
one which never omits any valid matches and just truncated the line 
context around them, and the users who want even faster searches (at the 
cost of missing matches, esp. in find-replace scenarios) have something 
else to customize too.

Previous Next

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