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

From: Dmitry Gutov <[email-masked]>
Date: Sun, 6 Dec 2020 23:37:11 +0200

On 06.12.2020 22:39, Juri Linkov wrote:
>> I noticed the problems caused by "cut -c": it counts bytes,
>> not multi-byte characters.  Even though it documentation says
>> that -b selects bytes, and -c selects characters, still
>> when used with "cut -c -200" it selects bytes, not UTF characters.
>>
>> Often it cuts in the middle of a multi-byte UTF-8 character,
>> so octal codes are displayed at the end of grep lines.
> 
> OTOH, ripgrep has the suitable options:
> 
>    -M, --max-columns NUM
>        Don’t print lines longer than this limit in bytes. Longer lines are omitted,
>        and only the number of matches in that line is printed.
> 
>    --max-columns-preview
>        When the --max-columns flag is used, ripgrep will by default completely
>        replace any line that is too long with a message indicating that a matching
>        line was removed.  When this flag is combined with --max-columns, a preview
>        of the line (corresponding to the limit size) is shown instead, where the
>        part of the line exceeding the limit is not shown.

You can experiment with these Right Now(tm) by customizing 
xref-search-program-alist (as well as xref-search-program). They'll only 
affect commands that use xref-matches-in-files, though.

> Wouldn't it be unthinkable to add support of ripgrep to grep.el?
> This will allow switching to ripgrep when there is a need to
> search in files with long lines.

I'm fairly sure nothing in terms of politics is stopping us here, but if 
we wanted to update grep.el's abstractions to use different search 
programs, it looks like a bigger job to me.

Though maybe you can get away with customizing a select number of 
variables? Like grep-template, grep-find-template, etc.