bug#44983: Truncate long lines of grep output

[Dmitry Gutov <dgutov@yandex.ru>]

On 08.12.2020 21:41, Juri Linkov wrote:
>> Alternatively, xref--collect-matches-1 could apply the limit itself, no
>> matter whether grep or rg is used. And it could make sure to only do that
>> after the last match. This might be the slower option, but hard to say in
>> advance, some comparison benchmark could help here.
> 
> I think until a long string is inserted to the buffer, truncating the
> string in the variable in xref--collect-matches-1 should be much faster.

It would surely be faster, but how would that overhead compare to the 
whole operation?

Could be negligible, except in the most extreme cases. After all, the 
main slowdown factor with long strings is the display engine, and it 
won't be in play there.

The upside is we'd be able to support column limiting with Grep too. 
Which is the default configuration. And we'd extract the cutoff column 
into a more visible user option.

>> That aside, could you explain the difference between the regexps? Do grep
>> and rg use different colors or something like that? Ideally, of course,
>> that would be just 1 regexp (if that's possible without loss in
>> performance, or significant loss in clarify).
> 
> They should be merged into one regexp indeed.  Because after customizing it
> to the rg regexp, grep output doesn't highlight matches anymore (I use both
> grep and rg interchangeably by different commands).
> 
> Currently their separate regexps are:
> 
> grep:
> "\033\\[0?1;31m
>   \\(.*?\\)
>   \033\\[[0-9]*m"
> 
> rg:
> "\033\\[[0-9]*m
>   \033\\[[0-9]*1m
>   \033\\[[0-9]*1m
>   \\(.*?\\)
>   \033\\[[0-9]*0m"
> 
> That could be combined into one regexp:
> 
> "\033\\[[0-9?;]*m
>   \\(?:\033\\[[0-9]*1m\\)\\{0,2\\}
>   \\(.*?\\)
>   \033\\[[0-9]*0?m"

Makes sense. Is the parsing performance the same?

Also, with the increased complexity, I'd rather we added a couple of 
tests, or a comment with output examples. Or maybe both.