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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>, 44983 <at> debbugs.gnu.org
Subject: bug#44983: Truncate long lines of grep output
Date: Tue, 1 Dec 2020 17:02:09 +0200

On 01.12.2020 10:45, Juri Linkov wrote:
> [New bug report from emacs-devel]
>>>>> For grep output a bigger problem is that grep on binary data
>>>>> might output too long lines before the terminating newline.
>>>>
>>>> (*) We already have this kind of problem with "normal" files which contain
>>>> minified assets (JS or CSS). The file contents are usually normal ASCII,
>>>> but it's just one line which can reach several MBs in length.
>>>>
>>>> The usual way to deal with that is with project-ignores and
>>>> grep-find-ignored-files. That works for both cases.
>>> This is a bug problem - often grep output lines are so long
>>> that Emacs freezes, so need to kill the process.  Updating
>>> manually ignored-files every time a new file causes freeze
>>> is very unreliable and time-consuming workaround.
>>
>> And a non-obvious one (for an average user).
>>
>> Is the same problem exhibited by commands using the Xref UI? I don't
>> remember seeing it, but of course our projects can be very different.
> 
> No difference from grep, Xref output has the same problem.

Perhaps (setq truncate-lines t) could help in that case?

Then the lines would be cut at the window width, as you suggest below.

> This will avoid the need of using such workarounds as in bug#44941:
> 
> grep -a "$@" | cut -c -200

That might cut filenames unnecessary. Even when those a long, we need 
them in their entirety.

The Grep results parsing code could be changed to only take the first XY 
characters of each line, though.

Previous Next

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