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

[Dmitry Gutov <dgutov@yandex.ru>]

On 03.03.2021 21:34, Gregory Heytings wrote:
> 
>>> Yes.  You get, for each match: the line number (from the beginning of 
>>> the file), the byte offset (from the beginning of the file) of the 
>>> first displayed character, and the context of the match.
>>
>> OK, so we get the byte offset, but not the length of the match (which 
>> we'll also need later, for purposes such as highlighting and 
>> replacement). And what happens if there are several matches on the 
>> same line? We need columns for all of them.
>>
> 
> I don't know exactly what you want to do, I initially chimed in this 
> conversation to react to Juri's "GNU grep has no option to truncate 
> output", to mention that GNU grep does have an option to do this; 
> perhaps it doesn't do exactly what you want.
> 
> I could be wrong, but I believe that adapting what you want to what GNU 
> grep provides will always be more efficient than the opposite.

That's the general principle I have tried to follow, but Grep has proved 
suboptimal for a number of purposes (matching one regexp to multiple 
lines among them).

>>> And you can easily get the byte offset of each beginning of line with 
>>> "grep -nbo '^.'", so calculating the byte offset from the beginning 
>>> of the line is easy.
>>
>> Do you mean to suggest we call grep one more time for each matching line?
>>
> 
> No, once for each file.  "grep -nbo '^.' FILE" returns a "<line>:<offset 
> of first char>:<first char>" line for each line in FILE.  With this you 
> can easily calculate the offset of a match on a given line.  This will 
> be more efficient than calculating the offset of a match by parsing each 
> line with Elisp code.

That's still +1 Grep invocation per file, right? Can't say for sure, 
perhaps it will be more efficient than parsing in Lisp, but at least 
with Lisp I know that parsing 10-20 matches is fast (and, actually, it's 
fairly instantaneous with 1000s of matches, as long as we don't 
encounter pathological files where all contents reside on one line).

With your approach we'll have to deal with interpreting Grep outputs 
which list every line in the searched files. This will almost certainly 
be slower in the case when there are only handful of matches. But 
benchmarks welcome.