Subject: bug#44983: Truncate long lines of grep output

From: Juri Linkov <[email-masked]>
Date: Tue, 01 Dec 2020 10:45:29 +0200

[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.

>> I tried to fix this problem, and fortunately the fix is simple
>> with the 1-liner patch.
>> It does exactly the same thing that we recently did to hide
>> overly long grep command lines with 'grep-find-abbreviate'.
>> The patch even uses the same 'grep-find-abbreviate-properties'
>> to allow clicking the hidden part to expand it.
>> diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el
>> index dafba22f77..e0df2402ee 100644
>> --- a/lisp/progmodes/grep.el
>> +++ b/lisp/progmodes/grep.el
>> @@ -492,6 +492,9 @@ grep-mode-font-lock-keywords
>>         (0 grep-context-face)
>>         (1 (if (eq (char-after (match-beginning 1)) ?\0)
>>                `(face nil display ,(match-string 2)))))
>> +     ;; Hide excessive parts of grep output lines
>> +     ("^.+?:.\\{,64\\}\\(.*\\).\\{10\\}$"
>> +      1 grep-find-abbreviate-properties)
>>        ;; Hide excessive part of rgrep command
>>        ("^find \\(\\. -type d .*\\\\)\\)"
>>         (1 (if grep-find-abbreviate grep-find-abbreviate-properties
>>
>> More customizability could be added later to define the
>> length of the hidden part, etc.
>
> Maybe we'll want it to be dynamically determined by fill-column.
>
> Or just be a big enough value (e.g. 256) that the only lines where this
> rule is hit are obviously too long.

Or maybe determined by the frame width.

This will avoid the need of using such workarounds as in bug#44941:

grep -a "$@" | cut -c -200