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: Wed, 9 Dec 2020 05:00:19 +0200 Message-ID: <857088a6-fe90-d989-9115-2c159b2a02e6@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> <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> <87mtyo3x1z.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20812"; 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 Wed Dec 09 04:02:07 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 1kmpjy-0005JZ-WD for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 09 Dec 2020 04:02:07 +0100 Original-Received: from localhost ([::1]:43698 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kmpjy-00033R-0a for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 08 Dec 2020 22:02:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39672) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmpiz-0002Sm-E6 for bug-gnu-emacs@gnu.org; Tue, 08 Dec 2020 22:01:06 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49055) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kmpiw-0004C4-35 for bug-gnu-emacs@gnu.org; Tue, 08 Dec 2020 22:01:05 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kmpiw-0001h4-1d for bug-gnu-emacs@gnu.org; Tue, 08 Dec 2020 22:01: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: Wed, 09 Dec 2020 03:01: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.16074828306461 (code B ref 44983); Wed, 09 Dec 2020 03:01:02 +0000 Original-Received: (at 44983) by debbugs.gnu.org; 9 Dec 2020 03:00:30 +0000 Original-Received: from localhost ([127.0.0.1]:60601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmpiQ-0001g9-0t for submit@debbugs.gnu.org; Tue, 08 Dec 2020 22:00:30 -0500 Original-Received: from mail-ed1-f50.google.com ([209.85.208.50]:45976) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmpiO-0001fw-9y for 44983@debbugs.gnu.org; Tue, 08 Dec 2020 22:00:28 -0500 Original-Received: by mail-ed1-f50.google.com with SMTP id r5so413304eda.12 for <44983@debbugs.gnu.org>; Tue, 08 Dec 2020 19:00:28 -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=zStHS/7jxVBX4MVJRQBLUaN/SXAIwYVwT8PemISEw5c=; b=QLNr62j+CKt+3julIRVEN6iBv0xPkhNh9etwod9BIiOBArXubgMjJ2Th0l3N/eXf02 yhqNPF2py10r2ndsBXyhXWp0FEG0PArF98CH8k1L0urKiBtCaAmoPP2rW+Wekeetj7Dd tVraB8oB4zZ3RyhdLHaYOZ6xixXeyP1CThNmRdOOPN+LYdXJZmCBVy8YoGHJa0t5Menq mLv2B3F+E055jdAS6VNvIVwFXQ4meUMfmhV8vnJ3OIa7UhFp3LpBBczY7B8HRPjjlqiI LSB0/dEgBJAbwoM27YJ/U3rwvNrTLPOq587+/D0NQqslUD9AY0RpBCnqoelGKWsmqIj/ nhwg== 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=zStHS/7jxVBX4MVJRQBLUaN/SXAIwYVwT8PemISEw5c=; b=fJF8QeCzvXrAvxxqYWjiVyhM3KIFjZRDX9WZG386Wx82rmiDezh8O68woKhZTEQrRM isbGChV9NPn0ksECdRC9kBPXwzba5idjO2REghfjxSh57l621iYXHw3jO9K9NEIeH0bs FRpBuHHN5eFNpSG5wmUupMrE7XR6uoqiLerIPe7yXmOaSTYalkpl7F5sck8Wf3bWlV7E NL9zmhQ/PYI5DtKqdfvL8jkKrBh77FBlInb8piz8GaEMlVegqmSYVgRPEodfI4WzVPa9 Tfn/XTpmjVMhQWVUOXXqU7WxX5/Y0FnJ1qOhd4GhmRxINj5knar3bZcVQlmiTsYzMUvv BCdw== X-Gm-Message-State: AOAM5330OXklJwr1s2KPillbozrxoKusmqlnl4X+7iXOu1Qrig6t909Z JMHCaxtS82M24STEjO1VgnBxoAnQobOFsw== X-Google-Smtp-Source: ABdhPJwBpQMv3z4IXTaZEOZySncLn415sWNwO3XXseFwKsnTWXVv1ww0DERR0/8Hw/pisV1d6IBxhg== X-Received: by 2002:a50:ee97:: with SMTP id f23mr100887edr.311.1607482821961; Tue, 08 Dec 2020 19:00:21 -0800 (PST) Original-Received: from [192.168.0.4] ([66.205.71.3]) by smtp.googlemail.com with ESMTPSA id pk19sm109039ejb.32.2020.12.08.19.00.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Dec 2020 19:00:20 -0800 (PST) In-Reply-To: <87mtyo3x1z.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:195472 Archived-At: On 08.12.2020 21:41, Juri Linkov wrote: >> 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. > > I think until a long string is inserted to the buffer, truncating the > string in the variable in xref--collect-matches-1 should be much faster. It would surely be faster, but how would that overhead compare to the whole operation? Could be negligible, except in the most extreme cases. After all, the main slowdown factor with long strings is the display engine, and it won't be in play there. The upside is we'd be able to support column limiting with Grep too. Which is the default configuration. And we'd extract the cutoff column into a more visible user option. >> 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). > > They should be merged into one regexp indeed. Because after customizing it > to the rg regexp, grep output doesn't highlight matches anymore (I use both > grep and rg interchangeably by different commands). > > Currently their separate regexps are: > > grep: > "\033\\[0?1;31m > \\(.*?\\) > \033\\[[0-9]*m" > > rg: > "\033\\[[0-9]*m > \033\\[[0-9]*1m > \033\\[[0-9]*1m > \\(.*?\\) > \033\\[[0-9]*0m" > > That could be combined into one regexp: > > "\033\\[[0-9?;]*m > \\(?:\033\\[[0-9]*1m\\)\\{0,2\\} > \\(.*?\\) > \033\\[[0-9]*0?m" Makes sense. Is the parsing performance the same? Also, with the increased complexity, I'd rather we added a couple of tests, or a comment with output examples. Or maybe both.