From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#44983: Truncate long lines of grep output Date: Sun, 06 Dec 2020 22:39:15 +0200 Organization: LINKOV.NET Message-ID: <87a6uqafmk.fsf@mail.linkov.net> References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> <87zh2w7ww1.fsf@mail.linkov.net> <83pn3reyjs.fsf@gnu.org> <87y2ie7for.fsf@mail.linkov.net> <87h7p0f611.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8885"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) Cc: 44983@debbugs.gnu.org, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 06 22:17:34 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1km1PS-0002BG-5C for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 06 Dec 2020 22:17:34 +0100 Original-Received: from localhost ([::1]:33518 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1km1PR-0003jb-6I for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 06 Dec 2020 16:17:33 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38832) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1km1Ox-00036i-1n for bug-gnu-emacs@gnu.org; Sun, 06 Dec 2020 16:17:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39961) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1km1Ow-0004my-RI for bug-gnu-emacs@gnu.org; Sun, 06 Dec 2020 16:17:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1km1Ow-00037V-Nk for bug-gnu-emacs@gnu.org; Sun, 06 Dec 2020 16:17:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Dec 2020 21:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44983 X-GNU-PR-Package: emacs Original-Received: via spool by 44983-submit@debbugs.gnu.org id=B44983.160728937411886 (code B ref 44983); Sun, 06 Dec 2020 21:17:02 +0000 Original-Received: (at 44983) by debbugs.gnu.org; 6 Dec 2020 21:16:14 +0000 Original-Received: from localhost ([127.0.0.1]:51497 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1km1O9-00035d-Lt for submit@debbugs.gnu.org; Sun, 06 Dec 2020 16:16:13 -0500 Original-Received: from relay7-d.mail.gandi.net ([217.70.183.200]:46153) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1km1O7-000358-8i for 44983@debbugs.gnu.org; Sun, 06 Dec 2020 16:16:11 -0500 X-Originating-IP: 91.129.99.98 Original-Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98]) (Authenticated sender: juri@linkov.net) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 7760820004; Sun, 6 Dec 2020 21:16:03 +0000 (UTC) In-Reply-To: <87h7p0f611.fsf@mail.linkov.net> (Juri Linkov's message of "Sat, 05 Dec 2020 21:47:06 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:195177 Archived-At: > 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.