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

[Dmitry Gutov]

On 07.03.2021 22:16, Theodor Thornhill via Bug reports for GNU Emacs, 
the Swiss army knife of text editors wrote:
> > 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.
> Yeah, I had an implementation where I "snipped" between matches and
> concatenated them together, but that still yielded too large a line for
> my emacs on a 3 million char length file, so I scrapped that idea. I
> guess it still is possible, though!

It should be able to perform better now, now that xref--insert-xrefs 
doesn't have to delete most of the text its inserted in these scenarios. 
We didn't really anticipate summary lines this long and the memory churn 
that came with them.

If you still get lines that are loo long in these cases, even with all 
extra text snipped away, hiding parts of the summary using text 
properties should be possible. I just tried putting 'invisible' on the 
whole line after column 600, and scrolling became instantaneous again.

As long as we undo these properties (or, perhaps, scroll the visible 
part?) when xref-next-line is called, the user would still be able to 
visit all matches.