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

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> linkov.net>

Date: Tue, 1 Dec 2020 08:56:01 UTC

Severity: normal

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44983 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: bug#44983: Truncate long lines of grep output
Date: Sun, 06 Dec 2020 22:39:15 +0200
> 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.

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.




This bug report was last modified 3 years and 73 days ago.

Previous Next


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