Re: dired-do-find-regexp failure with latin-1 encoding

[Dmitry Gutov <dgutov@yandex.ru>]

On 30.11.2020 22:54, Juri Linkov wrote:
>>> 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.

> 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

Looks sensible to me, but perhaps you want to create a new 
discussion/bug-number for it? Unless you'd like to follow up with a 
patch for xref.el (if the problem applies there).

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