From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#44983: Truncate long lines of grep output Date: Sun, 6 Dec 2020 23:37:11 +0200 Message-ID: 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> <87a6uqafmk.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16861"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: 44983@debbugs.gnu.org To: Juri Linkov , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 06 22:38:12 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 1km1jP-0004In-BC for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 06 Dec 2020 22:38:11 +0100 Original-Received: from localhost ([::1]:45634 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1km1jO-0001Ux-Df for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 06 Dec 2020 16:38:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42354) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1km1jG-0001Uo-PS for bug-gnu-emacs@gnu.org; Sun, 06 Dec 2020 16:38:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39979) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1km1jG-0002hn-ID for bug-gnu-emacs@gnu.org; Sun, 06 Dec 2020 16:38:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1km1jG-0005jj-FA for bug-gnu-emacs@gnu.org; Sun, 06 Dec 2020 16:38:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Dec 2020 21:38: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.160729064121993 (code B ref 44983); Sun, 06 Dec 2020 21:38:02 +0000 Original-Received: (at 44983) by debbugs.gnu.org; 6 Dec 2020 21:37:21 +0000 Original-Received: from localhost ([127.0.0.1]:51525 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1km1ib-0005if-3h for submit@debbugs.gnu.org; Sun, 06 Dec 2020 16:37:21 -0500 Original-Received: from mail-ed1-f47.google.com ([209.85.208.47]:42870) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1km1iZ-0005iP-8D for 44983@debbugs.gnu.org; Sun, 06 Dec 2020 16:37:19 -0500 Original-Received: by mail-ed1-f47.google.com with SMTP id v22so11617083edt.9 for <44983@debbugs.gnu.org>; Sun, 06 Dec 2020 13:37:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=aFmUBiZf2ZiYUji/gQHMfaSaPtw3brsedbNZjinp2jA=; b=qERmLw4WxJWQidyn3wxUxIyQm26iplb5Kn5uqUBiORPHO5UyFG4xAoAFZj4awDhWpI DcOVI/wN1pRFXnFATukJQP2s/YlLebcQmy/6WgVh1Hyrv25juuIVvLOS693D2wS2eGq/ gWPJmCTrvkdIByChMnIsWCdRBncac440RurCNbAOeo8pz1lNOIAdf0reaE2d6CqYOQqK JL9mkyAGBgeI15nENbEgQd1vjKfQE8q2CqBkZUfX/mPcvJ6rAKfEg/QWhynF2zc2tNCN LrL2f/sGC5I2E0ASIHM/DatehtvIccziWvVU9ceJ1p9564Rb+uj70qZLTjlK2NcUXtqV LEDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=aFmUBiZf2ZiYUji/gQHMfaSaPtw3brsedbNZjinp2jA=; b=WoqFd4u2VY7N9giR5eskYBgxVbkQvbfVekJl+5T68JYJufM5hD752WjGL9TyW6Q3u1 BQDww1nejfYLcgfUaZ/XODgbeaFPmWptuPZSsy7qQcUq/cd44Tumcrf3QLmVoZrfXG3e +FcS1G2Z+f7vljVCH4XkeOOO9L21x3MnTlFeBBH8fra2JffnppHe8u6nfaaVkqu1B1MF oNuKgQ5YrvTaP+2chyLWqBwu4Gf7hqYe5eduak4R4HcP7BbB49Ux0dcyA40HiajYcHzw +RYYN8lsc3GZlk5Pj9zdcYpOM8vRFqKtYvXefnq13XvQlHj+LvuCAUidSZ7OIhT/aAVk q1hA== X-Gm-Message-State: AOAM533PdZWqlTPNrK+SL1042VET5d6fTKbZLWIoq2bvz91Lub41VQ1h Tn7hnBcnG42Nno4E6DomnPn52ZZAqO1DBA== X-Google-Smtp-Source: ABdhPJy8uMuG9zQqKz10g7Zw/5UWeodnPHJKv2V1gymY/rd9LwgUtdIwUSW+zS71U/+UdzAE0q4HiA== X-Received: by 2002:a50:e78b:: with SMTP id b11mr7485857edn.165.1607290633068; Sun, 06 Dec 2020 13:37:13 -0800 (PST) Original-Received: from [192.168.0.4] ([66.205.71.3]) by smtp.googlemail.com with ESMTPSA id k21sm8703730ejv.80.2020.12.06.13.37.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 13:37:12 -0800 (PST) In-Reply-To: <87a6uqafmk.fsf@mail.linkov.net> Content-Language: en-US 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:195178 Archived-At: 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.