GNU bug report logs - #44983
Truncate long lines of grep output

Previous Next

Full log

Message #86 received at 44983 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 44983 <at> debbugs.gnu.org
Subject: Re: bug#44983: Truncate long lines of grep output
Date: Thu, 10 Dec 2020 10:18:16 +0200

> Perhaps you would like to come up with the name for the new user option?

Maybe something like 'xref-search-truncate' with a number of columns,
nil by default.

>> BTW, for sorting currently xref-search-program-alist uses:
>>      "| sort -t: -k1,1 -k2n,2"
>> but fortunately ripgrep has a special option to do the same with:
>>      "--sort path"
>
> Somehow, that option came out to be consistently slower in my
> benchmarking. Even when the results are only a few lines (that's actually
> when the difference should be most apparent, because with many lines Elisp
> takes up the most of CPU time). You can try it yourself:
>
> (benchmark 10 '(project-find-regexp ":package-version '(xref"))
>
>   0.86 with '| sort'
>   1.33 with '--sort path'

I confirm that in my tests '--sort path' is 2 times slower than '| sort'.

>> BTW, it's possible to see all highlighted parts of the output
>> by changing the argument 'MODE' of 'compilation-start' in 'grep'
>> from #'grep-mode to t (so it uses comint-mode in grep buffers).
>
> Because ansi-color-process-output is in comint-output-filter-functions?

Exactly.

Previous Next

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