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: Mon, 7 Dec 2020 04:41:09 +0200 Message-ID: <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> 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> <87zh2q61n6.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="30441"; 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 Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 07 03:42:26 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 1km6Tq-0007oE-J2 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 07 Dec 2020 03:42:26 +0100 Original-Received: from localhost ([::1]:34112 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1km6Tp-0007lL-IR for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 06 Dec 2020 21:42:25 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36776) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1km6TS-0007l4-IA for bug-gnu-emacs@gnu.org; Sun, 06 Dec 2020 21:42:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40291) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1km6TS-0000J7-B1 for bug-gnu-emacs@gnu.org; Sun, 06 Dec 2020 21:42:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1km6TS-0002jQ-8P for bug-gnu-emacs@gnu.org; Sun, 06 Dec 2020 21:42: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: Mon, 07 Dec 2020 02:42: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.160730888110450 (code B ref 44983); Mon, 07 Dec 2020 02:42:02 +0000 Original-Received: (at 44983) by debbugs.gnu.org; 7 Dec 2020 02:41:21 +0000 Original-Received: from localhost ([127.0.0.1]:51837 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1km6Sn-0002iU-1H for submit@debbugs.gnu.org; Sun, 06 Dec 2020 21:41:21 -0500 Original-Received: from mail-ej1-f47.google.com ([209.85.218.47]:34901) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1km6Sk-0002iG-8H for 44983@debbugs.gnu.org; Sun, 06 Dec 2020 21:41:19 -0500 Original-Received: by mail-ej1-f47.google.com with SMTP id f23so17336440ejk.2 for <44983@debbugs.gnu.org>; Sun, 06 Dec 2020 18:41:18 -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=5tgD30EuWkTt2tyVQ+PMrb9dcAph/KPazWHnyvIpLC4=; b=UvSwZpelfo9WOUdXFAEX6Oo9Dg1bu0/O93KX/40WBLT+yi9QsirEQpLOYjPCsgEZpP LCxG6WFDQ2xl0Z9qL5Y7wBOv5m9agCVjuo9nAbBOJeS4JlLHaORo+/p3lFCfKa5GDAJo 641bBvyOTpKCUIb00PwrJoYAWEZ+sLNzJFAjmrkx85/vwo/9lWhej+2bju0MDHbnXyOp QI6rVHO1TbLrEWVn+8B6949MW97NhwyKygdwnxT6V6uuCPqZJjyDDwLFoa0jgv+zQvK0 dMHPIoXsOxetVHTbwlQT92cRz6XseMh+IAslQRetUXR66JonmTZyE3bNd4sEVT3/qcbB 85IA== 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=5tgD30EuWkTt2tyVQ+PMrb9dcAph/KPazWHnyvIpLC4=; b=m5v/sg5w8tzICQPR+aYKRIGDU+fkFmDNO0iN5xMgEcNQzeW9QWuVRL1V+1Jnt0uPpK /ciqMS2D1+Fc1oIaFGLyBz4jk3z5LaadIjTAiOaGUY2QH+4OHLb8AAAZaWOScHaYAQ+B 3d5GPKBxvkSFLAkj2vFpnD6mtkJY+DLZJISBNqzvpXY0Vjntt0UHVWL3xp/XI5e247Zj PmxrkJ0YBqN1Qkbeb+3BtDU7klMAI2IRtEX8unJ2uX3t/KQgNwC6ccecca34wMLAc/90 Us16ghy9X8IDV5zdjrTgxOLGDA7zxbAD9R+0vbsV996+1bRY4p10na5iKfQlLT69hvEZ VQjg== X-Gm-Message-State: AOAM531Bz2tyxmFRgNZKgF8AZ7N6BaXiY26QbJogiZhFo9lJBJsBi0+4 KyFJG4Docv8+QkEYTZgruwsPxL473gvbqw== X-Google-Smtp-Source: ABdhPJyKLQuYjV3N4BzgObeA/tnKNYzFXpWCMLD9BNngcS+RPcFiabhfn0YKLmSVz6QiLjqdKXqtHw== X-Received: by 2002:a17:906:2612:: with SMTP id h18mr17354784ejc.469.1607308871770; Sun, 06 Dec 2020 18:41:11 -0800 (PST) Original-Received: from [192.168.0.4] ([66.205.71.3]) by smtp.googlemail.com with ESMTPSA id h12sm10001732eja.113.2020.12.06.18.41.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 18:41:10 -0800 (PST) In-Reply-To: <87zh2q61n6.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:195198 Archived-At: On 06.12.2020 23:54, Juri Linkov wrote: >>> 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. > > You mean adding "-M 200 --max-columns-preview" to xref-search-program-alist? Yup. > It works nice, thanks. Should this be added by default? Maybe someday? Currently, it has a certain side-effect: whenever there are matches that don't fit the specified width, they will be omitted from the resulting xref buffer. Depending on the user's intent, it can be a problem. Perhaps they did, after all, intend to search that minified JS file as well? This should be fixable (in xref--collect-matches-1, probably), but we'd have to consider carefully on what to do in situations like that. E.g., if we put some placeholder there, that would mean that "search and replace" won't work. Alternatively, xref--collect-matches-1 could apply the limit itself, no matter whether grep or rg is used. And it could make sure to only do that after the last match. This might be the slower option, but hard to say in advance, some comparison benchmark could help here. >>> 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. > > I customized grep-find-template to "find -type f -print0 | sort -z | > xargs -0 -e rg -inH --color always --no-heading -M 200 --max-columns-preview -e " > > But this also requires customizing grep-match-regexp to the value > "\033\\[[0-9]*m\033\\[[0-9]*1m\033\\[[0-9]*1m\\(.*?\\)\033\\[[0-9]*0m" > provided by Simon in bug#41766. It's odd your last suggestion in that bug was not applied (adding :type '(choice) to grep-match-regexp). Perhaps do that now? Although, personally, I've found a symbolic value to work better for a var like that (example: xref-search-program). This way we can ultimately consolidate info about a particular program in one place (some alist). That aside, could you explain the difference between the regexps? Do grep and rg use different colors or something like that? Ideally, of course, that would be just 1 regexp (if that's possible without loss in performance, or significant loss in clarify). > And also required a small fix in grep.el: > > diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el > index dafba22f77..0a5fd6bf5d 100644 > --- a/lisp/progmodes/grep.el > +++ b/lisp/progmodes/grep.el > @@ -412,7 +412,7 @@ grep-regexp-alist > (- mend beg)))))) > nil nil > (3 '(face nil display ":"))) > - ("^Binary file \\(.+\\) matches$" 1 nil nil 0 1)) > + ("^Binary file \\(.+\\) matches" 1 nil nil 0 1)) > "Regexp used to match grep hits. > See `compilation-error-regexp-alist' for format details.") Nice.