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

[Gregory Heytings]

> Except, um, we still need to fill in the "summary" attribute for all 
> matches, so that there is something to display in the Xref buffer (the 
> line contents around the match), and the -o flag strips those.

That's the purpose of the '.{0,100}' context.  In typical cases (souce 
code files with lines that do not have more than 80 colums) you don't even 
see the difference in the result buffer: you see the whole line.

> And if we were to use the '.{0,100}file.{0,100}' trick, it messes up the 
> location of the match, the reported byte offset become unreliable.

That's a problem to solve, indeed.  At first sight it doesn't seem 
unsolvable.

> Also: grepping for that kind of regexp is noticeably slower than 
> grepping for 'file'. Or even '.file'. Like 85ms vs 7ms slower.

Well, the bug report mentioned delays of 3-4 seconds on files with very 
long lines, so I'd guess that 85 ms is a pretty reasonable speed...