GNU bug report logs -
#46859
28.0.50; [PATCH]: Add option to truncate long lines in xref.el
Previous Next
Reported by: Theodor Thornhill <theo <at> thornhill.no>
Date: Mon, 1 Mar 2021 20:42:01 UTC
Severity: normal
Tags: patch
Found in version 28.0.50
Fixed in version 28.1
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
>
> 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...
This bug report was last modified 4 years and 89 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.