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 05:22:29 +0200

[Message part 1 (text/plain, inline)]

On 07.03.2021 00:26, Dmitry Gutov wrote:
> - 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.

Please try out the attached preparation patch.

It improves the performance of the "very long line" case drastically 
over here, while not doing any truncation yet. Looks like we regressed 
that case when we added rendering of multiple matches on the same line.

We can add the truncation feature on top of it.

Probably also in xref--collect-matches-1 (truncating the value of 
SUMMARY just before the xref-make-match call).

Alternatively, we could experiment with hiding parts of the long line 
using some display/visibility features (except the truncate-lines 
variable, that one keeps things slow). That could be done in 
xref--insert-xrefs or somewhere nearby. That is trickier, though, given 
that we'll probably want to unhide it (wholly or partially) when 
iterating over matches inside.

[xref-insert-xrefs-sparingly.diff (text/x-patch, attachment)]

Previous Next

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