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

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Juri Linkov <juri@HIDDEN>; dated Tue, 1 Dec 2020 08:56:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 14 Dec 2020 16:15:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 14 11:15:27 2020
Received: from localhost ([127.0.0.1]:53938 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koqVT-0000Uz-Eh
	for submit <at> debbugs.gnu.org; Mon, 14 Dec 2020 11:15:27 -0500
Received: from eggs.gnu.org ([209.51.188.92]:45072)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1koqVS-0000Nx-4n
 for 44983 <at> debbugs.gnu.org; Mon, 14 Dec 2020 11:15:26 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:54650)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1koqVM-0004pP-9q; Mon, 14 Dec 2020 11:15:20 -0500
Received: from [176.228.60.248] (port=4350 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1koqVJ-0007zb-8p; Mon, 14 Dec 2020 11:15:19 -0500
Date: Mon, 14 Dec 2020 18:15:08 +0200
Message-Id: <835z54cqk3.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
In-Reply-To: <874kkpcvfw.fsf@HIDDEN> (message from Juri Linkov on
 Sun, 13 Dec 2020 22:17:23 +0200)
Subject: Re: bug#44983: Truncate long lines of grep output
References: <87h7p0f611.fsf@HIDDEN> <87a6uqafmk.fsf@HIDDEN>
 <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN>
 <87zh2q61n6.fsf@HIDDEN>
 <3620abd0-ce79-cc9d-3fb2-255e91f13da1@HIDDEN>
 <87mtyo3x1z.fsf@HIDDEN>
 <857088a6-fe90-d989-9115-2c159b2a02e6@HIDDEN>
 <87lfe6x1uf.fsf@HIDDEN>
 <X9FE+14vRj+xMTiJ@HIDDEN>
 <87czzi2ju2.fsf@HIDDEN>
 <X9Hzip0BBizFJnL0@HIDDEN>
 <87bley7o4a.fsf@HIDDEN> <838sa1eo5u.fsf@HIDDEN>
 <874kkpcvfw.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org, bugs@HIDDEN, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Juri Linkov <juri@HIDDEN>
> Cc: bugs@HIDDEN,  44983 <at> debbugs.gnu.org,  dgutov@HIDDEN
> Date: Sun, 13 Dec 2020 22:17:23 +0200
> 
> >> > In my opinion I believe that majority of users who ever clicked
> >> > "Search Files (grep)" gave up after few attempts.
> >> 
> >> Indeed, "Search for files (grep)" menu option is not user friendly.
> >
> > In what way is it not user-friendly?  It just invokes "M-x grep".
> 
> It's not friendly for users who don't know syntax of grep command line.

If someone wants to add a more user-friendly dialog for searching text
(or perhaps reuse a dialog provided by the GUI toolkits), I think it
will be welcome.  It is not a simple job, though, because the dialog
should allow access to most of the advanced features of Grep.

> OTOH, "Recursive grep" (rgrep) is easier to use, but its menu item text
> is not clear to users who don't know what is grep.  Maybe a better title
> for 'rgrep' would be "Search text in files"?

FWIW, I don't think rgrep is significantly more user-friendly, so IMO
it is not the model on which to base a better UI.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 13 Dec 2020 20:43:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 13 15:43:16 2020
Received: from localhost ([127.0.0.1]:50527 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koYD6-0004rH-2z
	for submit <at> debbugs.gnu.org; Sun, 13 Dec 2020 15:43:16 -0500
Received: from relay2-d.mail.gandi.net ([217.70.183.194]:64965)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1koYD5-0004qj-DG
 for 44983 <at> debbugs.gnu.org; Sun, 13 Dec 2020 15:43:15 -0500
X-Originating-IP: 91.129.99.98
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id E290E40002;
 Sun, 13 Dec 2020 20:43:07 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
Organization: LINKOV.NET
References: <87h7p0f611.fsf@HIDDEN> <87a6uqafmk.fsf@HIDDEN>
 <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN>
 <87zh2q61n6.fsf@HIDDEN>
 <3620abd0-ce79-cc9d-3fb2-255e91f13da1@HIDDEN>
 <87mtyo3x1z.fsf@HIDDEN>
 <857088a6-fe90-d989-9115-2c159b2a02e6@HIDDEN>
 <87lfe6x1uf.fsf@HIDDEN>
 <X9FE+14vRj+xMTiJ@HIDDEN>
 <87czzi2ju2.fsf@HIDDEN>
 <X9Hzip0BBizFJnL0@HIDDEN>
 <87bley7o4a.fsf@HIDDEN> <838sa1eo5u.fsf@HIDDEN>
Date: Sun, 13 Dec 2020 22:17:23 +0200
In-Reply-To: <838sa1eo5u.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 13 Dec
 2020 17:11:41 +0200")
Message-ID: <874kkpcvfw.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org, bugs@HIDDEN, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> > In my opinion I believe that majority of users who ever clicked
>> > "Search Files (grep)" gave up after few attempts.
>> 
>> Indeed, "Search for files (grep)" menu option is not user friendly.
>
> In what way is it not user-friendly?  It just invokes "M-x grep".

It's not friendly for users who don't know syntax of grep command line.

OTOH, "Recursive grep" (rgrep) is easier to use, but its menu item text
is not clear to users who don't know what is grep.  Maybe a better title
for 'rgrep' would be "Search text in files"?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 13 Dec 2020 17:36:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 13 12:36:56 2020
Received: from localhost ([127.0.0.1]:50040 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koVIl-0001pQ-UY
	for submit <at> debbugs.gnu.org; Sun, 13 Dec 2020 12:36:56 -0500
Received: from stw1.rcdrun.com ([217.170.207.13]:56161)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bugs@HIDDEN>) id 1koVIk-0001pA-0c
 for 44983 <at> debbugs.gnu.org; Sun, 13 Dec 2020 12:36:54 -0500
Received: from localhost ([::ffff:197.157.34.185])
 (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by stw1.rcdrun.com with ESMTPSA
 id 00000000000308F7.000000005FD6512F.00004E19; Sun, 13 Dec 2020 10:36:47 -0700
Date: Sun, 13 Dec 2020 18:37:49 +0300
From: Jean Louis <bugs@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
Message-ID: <X9Y1Texjc/fMlrNM@HIDDEN>
References: <87zh2q61n6.fsf@HIDDEN>
 <3620abd0-ce79-cc9d-3fb2-255e91f13da1@HIDDEN>
 <87mtyo3x1z.fsf@HIDDEN>
 <857088a6-fe90-d989-9115-2c159b2a02e6@HIDDEN>
 <87lfe6x1uf.fsf@HIDDEN>
 <X9FE+14vRj+xMTiJ@HIDDEN>
 <87czzi2ju2.fsf@HIDDEN>
 <X9Hzip0BBizFJnL0@HIDDEN>
 <87bley7o4a.fsf@HIDDEN> <838sa1eo5u.fsf@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <838sa1eo5u.fsf@HIDDEN>
User-Agent: Mutt/2.0 (3d08634) (2020-11-07)
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 44983
Cc: dgutov@HIDDEN, 44983 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

* Eli Zaretskii <eliz@HIDDEN> [2020-12-13 18:12]:
> > From: Juri Linkov <juri@HIDDEN>
> > Date: Sat, 12 Dec 2020 22:42:13 +0200
> > Cc: 44983 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
> > 
> > > I do not find it problematic. Grep is anyway kind of advanced tool. I
> > > think that Emacs "Search for files (grep)" menu option is anyway not
> > > user friendly.
> > > ...
> > > What would be more user friendly would be a form or wizard that would
> > > specify if all files are to be searched or recursively, and what would
> > > be the search term. That would degrade power of grep but it would be
> > > more user friendly to many people.
> > >
> > > In my opinion I believe that majority of users who ever clicked
> > > "Search Files (grep)" gave up after few attempts.
> > 
> > Indeed, "Search for files (grep)" menu option is not user friendly.
> 
> In what way is it not user-friendly?  It just invokes "M-x grep".

User of Emacs are many, just Debian GNU/Linux reports 16000 users
known from the popularity contest package. It is probably small
percentage of overall number of users. Recently there was Emacs survey
and they interviewed 7000 users. Emacs has many bugs but we do not get
enough bugs reported. The ratio is reported bugs does not nearly
correspond to number of users.

From our view point it is user friendly. For me is user friendly if we
place Emacs functions in the menu without their descriptions.

From view point of many thousands of users it is not user friendly and
means nothing.

What does Recursive grep means? You have to know command line to know
what it means. Majority of GNU/Linux users do not even use command
line or terminals. We use it, but we are not representative number of
users.

"Search files recursively" would be better useful meaning

"Recursive grep" is reserved for power users. It is user friendly for
subset of users, not for majority of users.

Message from my staff member who was using Emacs and went thoroughly
through Tutorial:

[18:34] Happiness > > I have one analysis question, without expectation:
> Would you know how to search files by using Emacs?
> Do you know what means "grep"?
> Do you know what is "recursive grep"?
> No need to look up, just tell me
I have learned it but it might need me to repeat again as in the
tutorial I was practising, not yet well captured these terms on memory

But tutorial is not related to those terms. She cannot know what I
mean possibly. She can write reports but would not, without special
explanation, understand what means "Recursive grep".







Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 13 Dec 2020 17:32:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 13 12:32:12 2020
Received: from localhost ([127.0.0.1]:50035 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koVEC-0001if-BL
	for submit <at> debbugs.gnu.org; Sun, 13 Dec 2020 12:32:12 -0500
Received: from stw1.rcdrun.com ([217.170.207.13]:35033)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bugs@HIDDEN>) id 1koVEA-0001iS-UI
 for 44983 <at> debbugs.gnu.org; Sun, 13 Dec 2020 12:32:11 -0500
Received: from localhost ([::ffff:197.157.34.185])
 (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by stw1.rcdrun.com with ESMTPSA
 id 00000000000308F4.000000005FD65012.00004CFE; Sun, 13 Dec 2020 10:32:02 -0700
Date: Sun, 13 Dec 2020 13:57:26 +0300
From: Jean Louis <bugs@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
Message-ID: <X9XzlvizQo0VKu4V@HIDDEN>
References: <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN>
 <87zh2q61n6.fsf@HIDDEN>
 <3620abd0-ce79-cc9d-3fb2-255e91f13da1@HIDDEN>
 <87mtyo3x1z.fsf@HIDDEN>
 <857088a6-fe90-d989-9115-2c159b2a02e6@HIDDEN>
 <87lfe6x1uf.fsf@HIDDEN>
 <X9FE+14vRj+xMTiJ@HIDDEN>
 <87czzi2ju2.fsf@HIDDEN>
 <X9Hzip0BBizFJnL0@HIDDEN>
 <87bley7o4a.fsf@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <87bley7o4a.fsf@HIDDEN>
User-Agent: Mutt/2.0 (3d08634) (2020-11-07)
X-Spam-Score: 1.1 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  * Juri Linkov <juri@HIDDEN> [2020-12-13 00:09]: > > I
 do not find it problematic. Grep is anyway kind of advanced tool. I > > think
 that Emacs "Search for files (grep)" menu option is anyway not > [...] 
 Content analysis details:   (1.1 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 1.1 DATE_IN_PAST_06_12     Date: is 6 to 12 hours before Received: date
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.1 (/)

* Juri Linkov <juri@HIDDEN> [2020-12-13 00:09]:
> > I do not find it problematic. Grep is anyway kind of advanced tool. I
> > think that Emacs "Search for files (grep)" menu option is anyway not
> > user friendly.
> > ...
> > What would be more user friendly would be a form or wizard that would
> > specify if all files are to be searched or recursively, and what would
> > be the search term. That would degrade power of grep but it would be
> > more user friendly to many people.
> >
> > In my opinion I believe that majority of users who ever clicked
> > "Search Files (grep)" gave up after few attempts.
> 
> Indeed, "Search for files (grep)" menu option is not user friendly.
> This is why we added a wizard command "Recursive Grep..." under it
> in the same menu.

Good for programmers, good for you and good for me. Emacs is for
advanced users from that view point. From that view point everything
fits into place. 

From view point of users coming to Emacs "Recursive Grep" will not
have its meaning. Or any meaning at all.

It would be good to have a popularity-contest package similar to
Debian, where one could gather statistics what is actually used by
some users and submit that statistics.

Other good test could be to put 5 people together who used computers
for last 10 years regardless of their operating system and tell them
to open up Emacs and find files containing the term "Emacs" and watch
how they are doing.






Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 13 Dec 2020 15:11:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 13 10:11:59 2020
Received: from localhost ([127.0.0.1]:49918 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koT2V-00066q-KV
	for submit <at> debbugs.gnu.org; Sun, 13 Dec 2020 10:11:59 -0500
Received: from eggs.gnu.org ([209.51.188.92]:40580)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1koT2U-00066d-6Y
 for 44983 <at> debbugs.gnu.org; Sun, 13 Dec 2020 10:11:58 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:36333)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1koT2O-00077X-HT; Sun, 13 Dec 2020 10:11:52 -0500
Received: from [176.228.60.248] (port=3168 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1koT2N-0007GO-W4; Sun, 13 Dec 2020 10:11:52 -0500
Date: Sun, 13 Dec 2020 17:11:41 +0200
Message-Id: <838sa1eo5u.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
In-Reply-To: <87bley7o4a.fsf@HIDDEN> (message from Juri Linkov on
 Sat, 12 Dec 2020 22:42:13 +0200)
Subject: Re: bug#44983: Truncate long lines of grep output
References: <87h7p0f611.fsf@HIDDEN> <87a6uqafmk.fsf@HIDDEN>
 <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN>
 <87zh2q61n6.fsf@HIDDEN>
 <3620abd0-ce79-cc9d-3fb2-255e91f13da1@HIDDEN>
 <87mtyo3x1z.fsf@HIDDEN>
 <857088a6-fe90-d989-9115-2c159b2a02e6@HIDDEN>
 <87lfe6x1uf.fsf@HIDDEN>
 <X9FE+14vRj+xMTiJ@HIDDEN>
 <87czzi2ju2.fsf@HIDDEN>
 <X9Hzip0BBizFJnL0@HIDDEN> <87bley7o4a.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org, bugs@HIDDEN, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Juri Linkov <juri@HIDDEN>
> Date: Sat, 12 Dec 2020 22:42:13 +0200
> Cc: 44983 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
> 
> > I do not find it problematic. Grep is anyway kind of advanced tool. I
> > think that Emacs "Search for files (grep)" menu option is anyway not
> > user friendly.
> > ...
> > What would be more user friendly would be a form or wizard that would
> > specify if all files are to be searched or recursively, and what would
> > be the search term. That would degrade power of grep but it would be
> > more user friendly to many people.
> >
> > In my opinion I believe that majority of users who ever clicked
> > "Search Files (grep)" gave up after few attempts.
> 
> Indeed, "Search for files (grep)" menu option is not user friendly.

In what way is it not user-friendly?  It just invokes "M-x grep".




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 12 Dec 2020 21:08:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 12 16:08:47 2020
Received: from localhost ([127.0.0.1]:46917 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1koC8E-0004uq-SR
	for submit <at> debbugs.gnu.org; Sat, 12 Dec 2020 16:08:47 -0500
Received: from relay3-d.mail.gandi.net ([217.70.183.195]:41885)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1koC8D-0004uP-8Y
 for 44983 <at> debbugs.gnu.org; Sat, 12 Dec 2020 16:08:45 -0500
X-Originating-IP: 91.129.99.98
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 3EEA960005;
 Sat, 12 Dec 2020 21:08:37 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Jean Louis <bugs@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
Organization: LINKOV.NET
References: <87h7p0f611.fsf@HIDDEN> <87a6uqafmk.fsf@HIDDEN>
 <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN>
 <87zh2q61n6.fsf@HIDDEN>
 <3620abd0-ce79-cc9d-3fb2-255e91f13da1@HIDDEN>
 <87mtyo3x1z.fsf@HIDDEN>
 <857088a6-fe90-d989-9115-2c159b2a02e6@HIDDEN>
 <87lfe6x1uf.fsf@HIDDEN>
 <X9FE+14vRj+xMTiJ@HIDDEN>
 <87czzi2ju2.fsf@HIDDEN>
 <X9Hzip0BBizFJnL0@HIDDEN>
Date: Sat, 12 Dec 2020 22:42:13 +0200
In-Reply-To: <X9Hzip0BBizFJnL0@HIDDEN> (Jean Louis's message of
 "Thu, 10 Dec 2020 13:08:10 +0300")
Message-ID: <87bley7o4a.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> I do not find it problematic. Grep is anyway kind of advanced tool. I
> think that Emacs "Search for files (grep)" menu option is anyway not
> user friendly.
> ...
> What would be more user friendly would be a form or wizard that would
> specify if all files are to be searched or recursively, and what would
> be the search term. That would degrade power of grep but it would be
> more user friendly to many people.
>
> In my opinion I believe that majority of users who ever clicked
> "Search Files (grep)" gave up after few attempts.

Indeed, "Search for files (grep)" menu option is not user friendly.
This is why we added a wizard command "Recursive Grep..." under it
in the same menu.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 10 Dec 2020 20:48:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 10 15:48:20 2020
Received: from localhost ([127.0.0.1]:39424 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1knSrM-0000bv-IR
	for submit <at> debbugs.gnu.org; Thu, 10 Dec 2020 15:48:20 -0500
Received: from mail-ej1-f54.google.com ([209.85.218.54]:45504)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1knSrK-0000bf-QM
 for 44983 <at> debbugs.gnu.org; Thu, 10 Dec 2020 15:48:19 -0500
Received: by mail-ej1-f54.google.com with SMTP id qw4so9242558ejb.12
 for <44983 <at> debbugs.gnu.org>; Thu, 10 Dec 2020 12:48: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=7Nm1qeLABUHEWbNzunEGpTriGqDzuLG5ibT+AHtrGuM=;
 b=F2tgYTl1PRJvdcdHIpfvNYI5PcBLOMfHKZkMqoiWpOm4eYgHBiLsvYf8Ugcp6I/i6E
 X4TbiAYSzuTkTSvKtAurTKrQXrqQDsXEbz3dDQGorPKMInL0YhQrYcFTrYfxjsQ3FUbA
 D74w45lmVnX3YX7HlwmDFCMtJE1ljUeWsLq2Q6m4MM+HofyubqPnT0H/C9oSnB0nNcWL
 fvdGGjgIYJwbm0i5aeFmzSNcRPfzJtEtHZewROeKxaYx3T550qtJvLloKTGL1u3mNM98
 g3qs/5Pau0tsmLFt+Nbqf58m02kUa6GB64Hn+BqyAX5J1YunZL+Le/DQYQDFNaXzj++P
 dnMg==
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=7Nm1qeLABUHEWbNzunEGpTriGqDzuLG5ibT+AHtrGuM=;
 b=Kp7lOeCCbNEz1V5rh3x7VNH3COjIHEQaULfQ8pA0hhyeZzMg6WvTXk1k+YCDgvvLnq
 9/aeSb0WbOvaWRxRLhDAqGo1zz+ABNcH/URyX0jwpKq7mzduJBv3bGUQgLeuATQ5vCs5
 UCRc3J9GuX20ygXdCuI0pAJcWA9MsaclBs6tYiAbW5+BU0EbFDadxRFbeP1RSB0zA3ge
 J8rB7H3/db+bEk1w8swfZyxw7ZqgogZd45ASg3LFfIY3TRX3hKLmVMwcjXDoCoNnnrbw
 JUemO4jhwuSH90EPvsL4oVLqkrEW7Vz6iTe+hKoRyRXAzmxMhyYQv96LTzsVCcY68Otq
 C3Uw==
X-Gm-Message-State: AOAM530QCeChClD+cd1ohnpYtbIj9Wj2P9gvpYZZAP6CE/LPVjgXfzoc
 xvHLg+dKnlKrvyR5TxCc155KLlBUCxNeQQ==
X-Google-Smtp-Source: ABdhPJyLn3Ua01zj7rmKKtXOy1+0buWq2XTwEdNrGz8OMHgNtCtIUlsT2hP8iZHuXcyGn8Uw3YDN1g==
X-Received: by 2002:a17:907:4243:: with SMTP id
 np3mr7997782ejb.212.1607633292722; 
 Thu, 10 Dec 2020 12:48:12 -0800 (PST)
Received: from [192.168.0.4] ([66.205.71.3])
 by smtp.googlemail.com with ESMTPSA id m2sm5834268edf.27.2020.12.10.12.48.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 10 Dec 2020 12:48:11 -0800 (PST)
Subject: Re: bug#44983: Truncate long lines of grep output
To: Juri Linkov <juri@HIDDEN>
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN> <83ft4pik35.fsf@HIDDEN>
 <87sg8p5kw0.fsf@HIDDEN> <83eek8hoyx.fsf@HIDDEN>
 <87h7p4r1n9.fsf@HIDDEN>
 <62EB4762-278D-43E7-8699-BBDC47818A50@HIDDEN>
 <87zh2w7ww1.fsf@HIDDEN> <83pn3reyjs.fsf@HIDDEN>
 <87y2ie7for.fsf@HIDDEN> <87h7p0f611.fsf@HIDDEN>
 <87a6uqafmk.fsf@HIDDEN>
 <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN>
 <87zh2q61n6.fsf@HIDDEN>
 <3620abd0-ce79-cc9d-3fb2-255e91f13da1@HIDDEN>
 <87mtyo3x1z.fsf@HIDDEN>
 <857088a6-fe90-d989-9115-2c159b2a02e6@HIDDEN>
 <87lfe6x1uf.fsf@HIDDEN>
 <c7ee54eb-ee1a-3c7b-7c92-325a05c049c5@HIDDEN>
 <87k0tq14qn.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <3de35876-d646-54d9-dcf7-6f307eb41fa0@HIDDEN>
Date: Thu, 10 Dec 2020 22:48:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <87k0tq14qn.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

On 10.12.2020 10:18, Juri Linkov wrote:
>>> BTW, for sorting currently xref-search-program-alist uses:
>>>       "| sort -t: -k1,1 -k2n,2"
>>> but fortunately ripgrep has a special option to do the same with:
>>>       "--sort path"
>> Somehow, that option came out to be consistently slower in my
>> benchmarking. Even when the results are only a few lines (that's actually
>> when the difference should be most apparent, because with many lines Elisp
>> takes up the most of CPU time). You can try it yourself:
>>
>> (benchmark 10 '(project-find-regexp ":package-version '(xref"))
>>
>>    0.86 with '| sort'
>>    1.33 with '--sort path'
> I confirm that in my tests '--sort path' is 2 times slower than '| sort'.

And that's because '--sort path' forces single-threaded mode: 
https://github.com/BurntSushi/ripgrep/issues/152




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 10 Dec 2020 10:43:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 10 05:43:43 2020
Received: from localhost ([127.0.0.1]:37109 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1knJQF-00063n-Gy
	for submit <at> debbugs.gnu.org; Thu, 10 Dec 2020 05:43:43 -0500
Received: from stw1.rcdrun.com ([217.170.207.13]:55963)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bugs@HIDDEN>) id 1knJQD-00063V-TK
 for 44983 <at> debbugs.gnu.org; Thu, 10 Dec 2020 05:43:42 -0500
Received: from localhost ([::ffff:41.202.241.31])
 (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by stw1.rcdrun.com with ESMTPSA
 id 000000000001E527.000000005FD1FBD7.00001ED3; Thu, 10 Dec 2020 03:43:34 -0700
Date: Thu, 10 Dec 2020 13:08:10 +0300
From: Jean Louis <bugs@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
Message-ID: <X9Hzip0BBizFJnL0@HIDDEN>
References: <87h7p0f611.fsf@HIDDEN> <87a6uqafmk.fsf@HIDDEN>
 <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN>
 <87zh2q61n6.fsf@HIDDEN>
 <3620abd0-ce79-cc9d-3fb2-255e91f13da1@HIDDEN>
 <87mtyo3x1z.fsf@HIDDEN>
 <857088a6-fe90-d989-9115-2c159b2a02e6@HIDDEN>
 <87lfe6x1uf.fsf@HIDDEN>
 <X9FE+14vRj+xMTiJ@HIDDEN>
 <87czzi2ju2.fsf@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <87czzi2ju2.fsf@HIDDEN>
User-Agent: Mutt/2.0 (3d08634) (2020-11-07)
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

* Juri Linkov <juri@HIDDEN> [2020-12-10 11:34]:
> > Also see this:
> > ,----
> > | grep -oE '.{0,20}jQuery.{0,20}' bootstrap.min.js
> > `----
> 
> But what if the user enters such a regexp as "abc|xyz",
> then it will be composed into such command:
> 
>   grep -oE '.{0,20}abc|xyz.{0,20}'
> 
> that matches either 20 characters before "abc", or 20 characters
> after "xyz".  Then needs to add parentheses:
> 
>   grep -oE '.{0,20}(abc|xyz).{0,20}'

I do not find it problematic. Grep is anyway kind of advanced tool. I
think that Emacs "Search for files (grep)" menu option is anyway not
user friendly. It is made for those who know what is GNU/Linux, UNIX,
BSD. When user is faced with that option most probably will give up
soon in using it. Because the prompt asks user to enter something like:

grep --color -nH --null -e

but does not tell the user what it means, neither that one has to put
joker or file names after the term. Usability is degraded as the
function is only for advanced users there. Majority of GNU/Linux users
use GUI for any work.

In that sense advanced users should know how to use grep to at least
get results they need and want.  You put good intentions to beautify
the grep output.  But it is probably not necessary. They will not mind
of highlighting. They can do:

grep -nH --null -e

And there will be no highlighting. It gives the result. 

What would be more user friendly would be a form or wizard that would
specify if all files are to be searched or recursively, and what would
be the search term. That would degrade power of grep but it would be
more user friendly to many people.

In my opinion I believe that majority of users who ever clicked
"Search Files (grep)" gave up after few attempts.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 10 Dec 2020 08:34:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 10 03:34:25 2020
Received: from localhost ([127.0.0.1]:36960 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1knHP7-0002qc-2L
	for submit <at> debbugs.gnu.org; Thu, 10 Dec 2020 03:34:25 -0500
Received: from relay8-d.mail.gandi.net ([217.70.183.201]:36335)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1knHP3-0002q9-Qh
 for 44983 <at> debbugs.gnu.org; Thu, 10 Dec 2020 03:34:22 -0500
X-Originating-IP: 91.129.99.98
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 3AAA31BF208;
 Thu, 10 Dec 2020 08:34:13 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
Organization: LINKOV.NET
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN>
 <83ft4pik35.fsf@HIDDEN> <87sg8p5kw0.fsf@HIDDEN>
 <83eek8hoyx.fsf@HIDDEN> <87h7p4r1n9.fsf@HIDDEN>
 <62EB4762-278D-43E7-8699-BBDC47818A50@HIDDEN>
 <87zh2w7ww1.fsf@HIDDEN> <83pn3reyjs.fsf@HIDDEN>
 <87y2ie7for.fsf@HIDDEN> <87h7p0f611.fsf@HIDDEN>
 <87a6uqafmk.fsf@HIDDEN>
 <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN>
 <87zh2q61n6.fsf@HIDDEN>
 <3620abd0-ce79-cc9d-3fb2-255e91f13da1@HIDDEN>
 <87mtyo3x1z.fsf@HIDDEN>
 <857088a6-fe90-d989-9115-2c159b2a02e6@HIDDEN>
 <87lfe6x1uf.fsf@HIDDEN>
 <c7ee54eb-ee1a-3c7b-7c92-325a05c049c5@HIDDEN>
Date: Thu, 10 Dec 2020 10:18:16 +0200
In-Reply-To: <c7ee54eb-ee1a-3c7b-7c92-325a05c049c5@HIDDEN> (Dmitry Gutov's
 message of "Wed, 9 Dec 2020 22:06:01 +0200")
Message-ID: <87k0tq14qn.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> Perhaps you would like to come up with the name for the new user option?

Maybe something like 'xref-search-truncate' with a number of columns,
nil by default.

>> BTW, for sorting currently xref-search-program-alist uses:
>>      "| sort -t: -k1,1 -k2n,2"
>> but fortunately ripgrep has a special option to do the same with:
>>      "--sort path"
>
> Somehow, that option came out to be consistently slower in my
> benchmarking. Even when the results are only a few lines (that's actually
> when the difference should be most apparent, because with many lines Elisp
> takes up the most of CPU time). You can try it yourself:
>
> (benchmark 10 '(project-find-regexp ":package-version '(xref"))
>
>   0.86 with '| sort'
>   1.33 with '--sort path'

I confirm that in my tests '--sort path' is 2 times slower than '| sort'.

>> BTW, it's possible to see all highlighted parts of the output
>> by changing the argument 'MODE' of 'compilation-start' in 'grep'
>> from #'grep-mode to t (so it uses comint-mode in grep buffers).
>
> Because ansi-color-process-output is in comint-output-filter-functions?

Exactly.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 10 Dec 2020 08:34:21 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 10 03:34:21 2020
Received: from localhost ([127.0.0.1]:36957 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1knHP2-0002qL-Rb
	for submit <at> debbugs.gnu.org; Thu, 10 Dec 2020 03:34:21 -0500
Received: from relay6-d.mail.gandi.net ([217.70.183.198]:35207)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1knHP1-0002q4-0p
 for 44983 <at> debbugs.gnu.org; Thu, 10 Dec 2020 03:34:19 -0500
X-Originating-IP: 91.129.99.98
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 206BBC0009;
 Thu, 10 Dec 2020 08:34:10 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Jean Louis <bugs@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
Organization: LINKOV.NET
References: <83pn3reyjs.fsf@HIDDEN> <87y2ie7for.fsf@HIDDEN>
 <87h7p0f611.fsf@HIDDEN> <87a6uqafmk.fsf@HIDDEN>
 <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN>
 <87zh2q61n6.fsf@HIDDEN>
 <3620abd0-ce79-cc9d-3fb2-255e91f13da1@HIDDEN>
 <87mtyo3x1z.fsf@HIDDEN>
 <857088a6-fe90-d989-9115-2c159b2a02e6@HIDDEN>
 <87lfe6x1uf.fsf@HIDDEN>
 <X9FE+14vRj+xMTiJ@HIDDEN>
Date: Thu, 10 Dec 2020 10:06:53 +0200
In-Reply-To: <X9FE+14vRj+xMTiJ@HIDDEN> (Jean Louis's message of
 "Thu, 10 Dec 2020 00:43:23 +0300")
Message-ID: <87czzi2ju2.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> Also see this:
> ,----
> | grep -oE '.{0,20}jQuery.{0,20}' bootstrap.min.js
> `----

But what if the user enters such a regexp as "abc|xyz",
then it will be composed into such command:

  grep -oE '.{0,20}abc|xyz.{0,20}'

that matches either 20 characters before "abc", or 20 characters
after "xyz".  Then needs to add parentheses:

  grep -oE '.{0,20}(abc|xyz).{0,20}'

What is worse is that the whole match is highlighted,
including 20 characters before and after the real match.
So it seems this solution is not perfect.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 9 Dec 2020 21:46:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 09 16:46:28 2020
Received: from localhost ([127.0.0.1]:36391 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kn7I3-0003fG-UX
	for submit <at> debbugs.gnu.org; Wed, 09 Dec 2020 16:46:28 -0500
Received: from stw1.rcdrun.com ([217.170.207.13]:56469)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bugs@HIDDEN>) id 1kn7I2-0003f0-4Z
 for 44983 <at> debbugs.gnu.org; Wed, 09 Dec 2020 16:46:26 -0500
Received: from localhost ([::ffff:41.202.241.31])
 (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
 by stw1.rcdrun.com with ESMTPSA
 id 000000000001E43F.000000005FD145AA.00006024; Wed, 09 Dec 2020 14:46:18 -0700
Date: Thu, 10 Dec 2020 00:43:23 +0300
From: Jean Louis <bugs@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
Message-ID: <X9FE+14vRj+xMTiJ@HIDDEN>
References: <83pn3reyjs.fsf@HIDDEN> <87y2ie7for.fsf@HIDDEN>
 <87h7p0f611.fsf@HIDDEN> <87a6uqafmk.fsf@HIDDEN>
 <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN>
 <87zh2q61n6.fsf@HIDDEN>
 <3620abd0-ce79-cc9d-3fb2-255e91f13da1@HIDDEN>
 <87mtyo3x1z.fsf@HIDDEN>
 <857088a6-fe90-d989-9115-2c159b2a02e6@HIDDEN>
 <87lfe6x1uf.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <87lfe6x1uf.fsf@HIDDEN>
User-Agent: Mutt/2.0 (3d08634) (2020-11-07)
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Also see this:

https://www.topbug.net/blog/2016/08/18/truncate-long-matching-lines-of-grep=
-a-solution-that-preserves-color/

,----
| For the example above, the following command should print only 20
| characters before and after the searching keyword (This requires GNU
| grep. If you are on Mac OS X and using the BSD grep, please consider
| following this article to install GNU grep):
|=20
| grep -oE '.{0,20}jQuery.{0,20}' bootstrap.min.js
`----

where I get this:

grep -o --color -nH --null -E  ".{0,20}setting.{0,20}" tmp-2020-11-26-01:3*
tmp-2020-11-26-01:32:17986egO=003: supported, but its setting does not have=
 prior

Grep finished with 1 match found at Thu Dec 10 00:42:21

=66rom this line long made-up line:

=E2=80=98--color[=3DWHEN]=E2=80=99 =E2=80=98--colour[=3DWHEN]=E2=80=99 Surr=
ound the matched (non-empty) strings, matching lines, context lines, file n=
ames, line numbers, byte offsets, and separators (for fields and groups of =
context lines) with escape sequences to display them in color on the termin=
al.  The colors are defined by the environment variable =E2=80=98GREP_COLOR=
S=E2=80=99 and default to =E2=80=98ms=3D01;31:mc=3D01;31:sl=3D:cx=3D:fn=3D3=
5:ln=3D32:bn=3D32:se=3D36=E2=80=99 for bold red matched text, magenta file =
names, green line numbers, green byte offsets, cyan separators, and default=
 terminal colors otherwise. The deprecated environment variable =E2=80=98GR=
EP_COLOR=E2=80=99 is still supported, but its setting does not have priorit=
y; it defaults to =E2=80=9801;31=E2=80=99 (bold red) which only covers the =
color for matched text. WHEN is =E2=80=98never=E2=80=99, =E2=80=98always=E2=
=80=99, or =E2=80=98auto=E2=80=99. =E2=80=98-L=E2=80=99 =E2=80=98--files-wi=
thout-match=E2=80=99 Suppress normal output; instead print the name of each=
 input file from which no output would normally have been printed.  The sca=
nning of each file stops on the first match. =E2=80=98-l=E2=80=99 =E2=80=98=
--files-with-matches=E2=80=99 Suppress normal output; instead print the nam=
e of each input file from which output would normally have been printed.  T=
he scanning of each file stops on the first match.  (=E2=80=98-l=E2=80=99 i=
s specified by POSIX.)

and that solves the problem of truncating long lines.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 9 Dec 2020 20:06:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 09 15:06:13 2020
Received: from localhost ([127.0.0.1]:36226 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kn5j2-0007U0-Uc
	for submit <at> debbugs.gnu.org; Wed, 09 Dec 2020 15:06:13 -0500
Received: from mail-ej1-f50.google.com ([209.85.218.50]:46647)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1kn5j0-0007Tk-Nx
 for 44983 <at> debbugs.gnu.org; Wed, 09 Dec 2020 15:06:11 -0500
Received: by mail-ej1-f50.google.com with SMTP id bo9so3938875ejb.13
 for <44983 <at> debbugs.gnu.org>; Wed, 09 Dec 2020 12:06:10 -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=XIMB9fbmfWFhWH/cqM83IPRdpDuFrguuZhCiKT/a1nA=;
 b=UjGOd5cC/95Zjjf51TjJRTZM+Rcb2Yd1CNo5c28+406XY64jYiB7E1CmOOl+kCGAU3
 7HO7PIPMQb92Y806Qc1JgXGX1BsGxsML6z27NFvzcuAePYn+J+IhjFMkERpjFujyebmp
 kBuvWJB2MaxlAt0FDIyD3bvelClvFfdTY+G6o4wX7tJNqY6TJ6YL0E2rCxl/gx0zKb38
 ZZ0jOJJfucSoLhZLqLPgIE3IWttqxB0zm48CdjXoqILwsJ3iWlDM+pDVoupWMJyw2XL8
 Lxn16DGv0hKZ7jynC2R17oawxT36m82I++wMEhbx+2dRxIWsC1qBrldUBKGpATfIlZ3Y
 ymVw==
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=XIMB9fbmfWFhWH/cqM83IPRdpDuFrguuZhCiKT/a1nA=;
 b=rDv4dJHDI91tWxHKo8Bh7eNcSoBEGQKQuoNTgPMaUPkcG/+lsjSM/bUXw0d1MSOsaM
 0QneU+5CbJul2bjSt+EVJcQoVX1dU2mdigPjhOgFvK57l8FYTH1WwgYGXrJlVQRCy6/F
 zrpjHfybymDEOTy4eq4ZaR7RJEZKOCPV/MrFIapGEvIvM9/BfGu459m/MchYklRqj/EQ
 Ol9B1Dm4Nl6jUDdqmTsWAXp2+Ydx39amdPA+8n5nG+KRDUkNZk/MTCJ4XsX0wf4JO0m2
 Kst3MPScVxooVAEm+IEONtenI6Nx79QMyWqW9w/lLiUXuVuS3QflHc5lYVOVdJBaoyWe
 dBGA==
X-Gm-Message-State: AOAM532qfh98sbKawU7YOcM1hvwuEO82z4vqCUuBobJV50lAQ89DRnrx
 sdckdoP1JHedM6xWZP4mxoI+l23z0IyhNA==
X-Google-Smtp-Source: ABdhPJyeFHXTpzZWphQrBthRg69Yd2OIhbMRpR59px3x/uGxTwCtb/AJPRj7iTqtIFCMB2I7Q1LGgQ==
X-Received: by 2002:a17:907:20f1:: with SMTP id
 rh17mr3433768ejb.147.1607544364545; 
 Wed, 09 Dec 2020 12:06:04 -0800 (PST)
Received: from [192.168.0.4] ([66.205.71.3])
 by smtp.googlemail.com with ESMTPSA id be6sm2642367edb.29.2020.12.09.12.06.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 09 Dec 2020 12:06:03 -0800 (PST)
Subject: Re: bug#44983: Truncate long lines of grep output
To: Juri Linkov <juri@HIDDEN>
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN> <83ft4pik35.fsf@HIDDEN>
 <87sg8p5kw0.fsf@HIDDEN> <83eek8hoyx.fsf@HIDDEN>
 <87h7p4r1n9.fsf@HIDDEN>
 <62EB4762-278D-43E7-8699-BBDC47818A50@HIDDEN>
 <87zh2w7ww1.fsf@HIDDEN> <83pn3reyjs.fsf@HIDDEN>
 <87y2ie7for.fsf@HIDDEN> <87h7p0f611.fsf@HIDDEN>
 <87a6uqafmk.fsf@HIDDEN>
 <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN>
 <87zh2q61n6.fsf@HIDDEN>
 <3620abd0-ce79-cc9d-3fb2-255e91f13da1@HIDDEN>
 <87mtyo3x1z.fsf@HIDDEN>
 <857088a6-fe90-d989-9115-2c159b2a02e6@HIDDEN>
 <87lfe6x1uf.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <c7ee54eb-ee1a-3c7b-7c92-325a05c049c5@HIDDEN>
Date: Wed, 9 Dec 2020 22:06:01 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <87lfe6x1uf.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

On 09.12.2020 21:17, Juri Linkov wrote:
>>> 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.
> 
> This is exactly what we need.  After that this bug report/feature request
> can be closed.

Perhaps you would like to come up with the name for the new user option? 
The changes to xref--collect-matches-1 should be straightforward (it 
will include a choice, though: whether to cut off matches when they 
don't fit). Since you're the one who has experienced poor performance 
because of this, though, you can do the benchmarking. Basically, what we 
need to know is whether the new option indeed makes performance acceptable.

> BTW, for sorting currently xref-search-program-alist uses:
> 
>      "| sort -t: -k1,1 -k2n,2"
> 
> but fortunately ripgrep has a special option to do the same with:
> 
>      "--sort path"

Somehow, that option came out to be consistently slower in my 
benchmarking. Even when the results are only a few lines (that's 
actually when the difference should be most apparent, because with many 
lines Elisp takes up the most of CPU time). You can try it yourself:

(benchmark 10 '(project-find-regexp ":package-version '(xref"))

   0.86 with '| sort'
   1.33 with '--sort path'

$ rg --version
ripgrep 12.1.1 (rev 7cb211378a)
-SIMD -AVX (compiled)
+SIMD +AVX (runtime)

We can also document it in the docstring, though. For those who don't 
have 'sort' installed.

>>> 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?
> 
> Performance is not a problem.  The problem is that more lax regexp
> causes more false positives.  So the above regexp highlighted even
> the separator colons (':') between file names and column numbers.
> 
> BTW, it's possible to see all highlighted parts of the output
> by changing the argument 'MODE' of 'compilation-start' in 'grep'
> from #'grep-mode to t (so it uses comint-mode in grep buffers).

Because ansi-color-process-output is in comint-output-filter-functions?

> Anyway, I found the shortest change needed to support ripgrep,
> and pushed to master.

Excellent.

>> Also, with the increased complexity, I'd rather we added a couple of tests,
>> or a comment with output examples. Or maybe both.
> 
> Fortunately, we have all possible cases listed in etc/grep.txt,
> so it was easy to check if everything is highlighted correctly now.
> Also I added ripgrep samples to etc/grep.txt.

Thanks!




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 9 Dec 2020 19:22:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 09 14:22:22 2020
Received: from localhost ([127.0.0.1]:36139 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kn52c-0004Da-ES
	for submit <at> debbugs.gnu.org; Wed, 09 Dec 2020 14:22:22 -0500
Received: from relay8-d.mail.gandi.net ([217.70.183.201]:46057)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1kn52a-0004D7-5U
 for 44983 <at> debbugs.gnu.org; Wed, 09 Dec 2020 14:22:20 -0500
X-Originating-IP: 91.129.99.98
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id C8BA01BF207;
 Wed,  9 Dec 2020 19:22:12 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
Organization: LINKOV.NET
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN>
 <83ft4pik35.fsf@HIDDEN> <87sg8p5kw0.fsf@HIDDEN>
 <83eek8hoyx.fsf@HIDDEN> <87h7p4r1n9.fsf@HIDDEN>
 <62EB4762-278D-43E7-8699-BBDC47818A50@HIDDEN>
 <87zh2w7ww1.fsf@HIDDEN> <83pn3reyjs.fsf@HIDDEN>
 <87y2ie7for.fsf@HIDDEN> <87h7p0f611.fsf@HIDDEN>
 <87a6uqafmk.fsf@HIDDEN>
 <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN>
 <87zh2q61n6.fsf@HIDDEN>
 <3620abd0-ce79-cc9d-3fb2-255e91f13da1@HIDDEN>
 <87mtyo3x1z.fsf@HIDDEN>
 <857088a6-fe90-d989-9115-2c159b2a02e6@HIDDEN>
Date: Wed, 09 Dec 2020 21:17:28 +0200
Message-ID: <87lfe6x1uf.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

>>> 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.

This is exactly what we need.  After that this bug report/feature request
can be closed.

BTW, for sorting currently xref-search-program-alist uses:

    "| sort -t: -k1,1 -k2n,2"

but fortunately ripgrep has a special option to do the same with:

    "--sort path"

>>> 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?

Performance is not a problem.  The problem is that more lax regexp
causes more false positives.  So the above regexp highlighted even
the separator colons (':') between file names and column numbers.

BTW, it's possible to see all highlighted parts of the output
by changing the argument 'MODE' of 'compilation-start' in 'grep'
from #'grep-mode to t (so it uses comint-mode in grep buffers).

Anyway, I found the shortest change needed to support ripgrep,
and pushed to master.

> Also, with the increased complexity, I'd rather we added a couple of tests,
> or a comment with output examples. Or maybe both.

Fortunately, we have all possible cases listed in etc/grep.txt,
so it was easy to check if everything is highlighted correctly now.
Also I added ripgrep samples to etc/grep.txt.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 9 Dec 2020 03:00:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 08 22:00:30 2020
Received: from localhost ([127.0.0.1]:60601 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmpiQ-0001g9-0t
	for submit <at> debbugs.gnu.org; Tue, 08 Dec 2020 22:00:30 -0500
Received: from mail-ed1-f50.google.com ([209.85.208.50]:45976)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1kmpiO-0001fw-9y
 for 44983 <at> debbugs.gnu.org; Tue, 08 Dec 2020 22:00:28 -0500
Received: by mail-ed1-f50.google.com with SMTP id r5so413304eda.12
 for <44983 <at> 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)
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)
Subject: Re: bug#44983: Truncate long lines of grep output
To: Juri Linkov <juri@HIDDEN>
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN> <83ft4pik35.fsf@HIDDEN>
 <87sg8p5kw0.fsf@HIDDEN> <83eek8hoyx.fsf@HIDDEN>
 <87h7p4r1n9.fsf@HIDDEN>
 <62EB4762-278D-43E7-8699-BBDC47818A50@HIDDEN>
 <87zh2w7ww1.fsf@HIDDEN> <83pn3reyjs.fsf@HIDDEN>
 <87y2ie7for.fsf@HIDDEN> <87h7p0f611.fsf@HIDDEN>
 <87a6uqafmk.fsf@HIDDEN>
 <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN>
 <87zh2q61n6.fsf@HIDDEN>
 <3620abd0-ce79-cc9d-3fb2-255e91f13da1@HIDDEN>
 <87mtyo3x1z.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <857088a6-fe90-d989-9115-2c159b2a02e6@HIDDEN>
Date: Wed, 9 Dec 2020 05:00:19 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <87mtyo3x1z.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 8 Dec 2020 19:48:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 08 14:48:24 2020
Received: from localhost ([127.0.0.1]:59885 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmiyF-0005MF-TC
	for submit <at> debbugs.gnu.org; Tue, 08 Dec 2020 14:48:24 -0500
Received: from relay4-d.mail.gandi.net ([217.70.183.196]:36245)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1kmiyC-0005Lx-DV
 for 44983 <at> debbugs.gnu.org; Tue, 08 Dec 2020 14:48:22 -0500
X-Originating-IP: 91.129.99.98
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 02150E000C;
 Tue,  8 Dec 2020 19:48:12 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
Organization: LINKOV.NET
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN>
 <83ft4pik35.fsf@HIDDEN> <87sg8p5kw0.fsf@HIDDEN>
 <83eek8hoyx.fsf@HIDDEN> <87h7p4r1n9.fsf@HIDDEN>
 <62EB4762-278D-43E7-8699-BBDC47818A50@HIDDEN>
 <87zh2w7ww1.fsf@HIDDEN> <83pn3reyjs.fsf@HIDDEN>
 <87y2ie7for.fsf@HIDDEN> <87h7p0f611.fsf@HIDDEN>
 <87a6uqafmk.fsf@HIDDEN>
 <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN>
 <87zh2q61n6.fsf@HIDDEN>
 <3620abd0-ce79-cc9d-3fb2-255e91f13da1@HIDDEN>
Date: Tue, 08 Dec 2020 21:41:28 +0200
In-Reply-To: <3620abd0-ce79-cc9d-3fb2-255e91f13da1@HIDDEN> (Dmitry Gutov's
 message of "Mon, 7 Dec 2020 04:41:09 +0200")
Message-ID: <87mtyo3x1z.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

> 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.

>> 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).

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"




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 8 Dec 2020 19:15:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 08 14:15:48 2020
Received: from localhost ([127.0.0.1]:59808 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmiSi-0004Si-AX
	for submit <at> debbugs.gnu.org; Tue, 08 Dec 2020 14:15:48 -0500
Received: from mail-wm1-f50.google.com ([209.85.128.50]:40334)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1kmiSg-0004SS-L8
 for 44983 <at> debbugs.gnu.org; Tue, 08 Dec 2020 14:15:47 -0500
Received: by mail-wm1-f50.google.com with SMTP id a3so3321179wmb.5
 for <44983 <at> debbugs.gnu.org>; Tue, 08 Dec 2020 11:15:46 -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=yCZ0BUwOFQLPUHs3tHkG3X2e6MPRJXHIoML7LWjxDPM=;
 b=s0kZxpTLW5sHSQ5wtvjEUcO5RlUTctYGYU0aFkWiOK0fOl3VY8sQKmOLakMfhm7Uba
 cStInXAIouuqxuKH4Z+2CAGHdcgktJ22Yrnk9P/oxZAreRS99YCQFCc/p6Xm9kod3Jjk
 D7NJ5YnhuONPnHOYhSq42TTNPxLhqR1CHsqskMOenrL7IowX8QHutk+xbN70A8rp/Flf
 OvVsDNtb5zPPBtdpvD+myhqQ6zlwhjntCmzINDoU2gAosatjHuZVL18cKI8lhRJx52Kv
 Cf/7HBE4ADKhvbtu967gUGhIin8Wcgqf7Ju92eMrxQms3WjTGqUkkfharMXJVLqOgtY/
 r4vQ==
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=yCZ0BUwOFQLPUHs3tHkG3X2e6MPRJXHIoML7LWjxDPM=;
 b=gY4FGlJ8SRGaQiZBmmWI/auzz9+NY9rHopBG1LwE3kyMjPOdSLe2EM3y6k3ad5mJ/T
 Ybjuf/4Rc0WfBrzNK9f1FMcSV7VFMx01IJwwA0U4eQbDJb/4sZUPiZ9tE6fzfh0GmxnT
 7Yt7ZcGWRXWILk4yC3YQYd6HQvuATc4upGKXGlgZIBTPe9eLp0BvX3F3kY/7l4/OFgGY
 ycUxqDCTNBdAEKmHqbsca7af60A4f3yv9u/h7Snc4Tn1MIsfHaFbpjINDuXYTN8UlZNK
 WjedM4J8guW8xhhxqIIurjbBgfbyYvNN3GE7T+uUmZ5QC/B87bRWAyXfOunJCrsI7Rf5
 CNxg==
X-Gm-Message-State: AOAM531/de9Z1owvxcbz2SxEWjNlUKkIUZ3nmTvai9MOTrHrFLoCfUh2
 nTKeQYYticUItUwV24AsC2zixgWwu/e/wg==
X-Google-Smtp-Source: ABdhPJyaxWD8P3W2HHXEVWB8wGQRHrPrwxe29MVge5zzSr8v3+1U1xmbz0PZLZVuCVmG4FnMXxdofw==
X-Received: by 2002:a1c:2d8b:: with SMTP id t133mr4970970wmt.127.1607454940574; 
 Tue, 08 Dec 2020 11:15:40 -0800 (PST)
Received: from [192.168.0.4] ([66.205.71.3])
 by smtp.googlemail.com with ESMTPSA id 35sm21534367wro.71.2020.12.08.11.15.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 08 Dec 2020 11:15:39 -0800 (PST)
Subject: Re: bug#44983: Truncate long lines of grep output
To: rms@HIDDEN
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN> <83ft4pik35.fsf@HIDDEN>
 <87sg8p5kw0.fsf@HIDDEN> <83eek8hoyx.fsf@HIDDEN>
 <87h7p4r1n9.fsf@HIDDEN>
 <62EB4762-278D-43E7-8699-BBDC47818A50@HIDDEN>
 <87zh2w7ww1.fsf@HIDDEN> <83pn3reyjs.fsf@HIDDEN>
 <87y2ie7for.fsf@HIDDEN> <87h7p0f611.fsf@HIDDEN>
 <87a6uqafmk.fsf@HIDDEN>
 <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN>
 <E1kmVeZ-0008VA-9Q@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <f93a556e-0ed8-2b73-14f7-7b7a0b66b1d5@HIDDEN>
Date: Tue, 8 Dec 2020 21:15:37 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <E1kmVeZ-0008VA-9Q@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 44983
Cc: eliz@HIDDEN, 44983 <at> debbugs.gnu.org, juri@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

On 08.12.2020 07:35, Richard Stallman wrote:
> What is xref-search?

We don't actually employ such a notion, but if I was asked to define it, 
it would be the act of using a command based on xref-matches-in-files 
(which see). The main thing that separates that from 'M-x grep', though, 
is the implementation approach.

> Is this something I could use instead of cut, to truncate
> long lines of grep output?

You can use the commands based on it. And we could change the 
implementation of the aforementioned function that it would "cut" such 
long lines. In that case, the cutting could be performed using Emacs 
Lisp. 'cut' could still be used instead, though. Or 'ripgrep' could be 
instructed to do that.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 8 Dec 2020 05:35:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 08 00:35:24 2020
Received: from localhost ([127.0.0.1]:56304 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kmVem-0008GU-Dt
	for submit <at> debbugs.gnu.org; Tue, 08 Dec 2020 00:35:24 -0500
Received: from eggs.gnu.org ([209.51.188.92]:38148)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rms@HIDDEN>) id 1kmVek-0008GF-7Y
 for 44983 <at> debbugs.gnu.org; Tue, 08 Dec 2020 00:35:23 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:44126)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <rms@HIDDEN>)
 id 1kmVee-0004FN-4H; Tue, 08 Dec 2020 00:35:16 -0500
Received: from rms by fencepost.gnu.org with local (Exim 4.82)
 (envelope-from <rms@HIDDEN>)
 id 1kmVeZ-0008VA-9Q; Tue, 08 Dec 2020 00:35:12 -0500
Content-Type: text/plain; charset=Utf-8
From: Richard Stallman <rms@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN> (message from
 Dmitry Gutov on Sun, 6 Dec 2020 23:37:11 +0200)
Subject: Re: bug#44983: Truncate long lines of grep output
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN> <83ft4pik35.fsf@HIDDEN>
 <87sg8p5kw0.fsf@HIDDEN> <83eek8hoyx.fsf@HIDDEN>
 <87h7p4r1n9.fsf@HIDDEN>
 <62EB4762-278D-43E7-8699-BBDC47818A50@HIDDEN>
 <87zh2w7ww1.fsf@HIDDEN> <83pn3reyjs.fsf@HIDDEN>
 <87y2ie7for.fsf@HIDDEN> <87h7p0f611.fsf@HIDDEN>
 <87a6uqafmk.fsf@HIDDEN>
 <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN>
Message-Id: <E1kmVeZ-0008VA-9Q@HIDDEN>
Date: Tue, 08 Dec 2020 00:35:11 -0500
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 44983
Cc: eliz@HIDDEN, 44983 <at> debbugs.gnu.org, juri@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rms@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

What is xref-search?

Is this something I could use instead of cut, to truncate
long lines of grep output?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 7 Dec 2020 02:41:21 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 06 21:41:21 2020
Received: from localhost ([127.0.0.1]:51837 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1km6Sn-0002iU-1H
	for submit <at> debbugs.gnu.org; Sun, 06 Dec 2020 21:41:21 -0500
Received: from mail-ej1-f47.google.com ([209.85.218.47]:34901)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1km6Sk-0002iG-8H
 for 44983 <at> debbugs.gnu.org; Sun, 06 Dec 2020 21:41:19 -0500
Received: by mail-ej1-f47.google.com with SMTP id f23so17336440ejk.2
 for <44983 <at> 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)
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)
Subject: Re: bug#44983: Truncate long lines of grep output
To: Juri Linkov <juri@HIDDEN>
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN> <83ft4pik35.fsf@HIDDEN>
 <87sg8p5kw0.fsf@HIDDEN> <83eek8hoyx.fsf@HIDDEN>
 <87h7p4r1n9.fsf@HIDDEN>
 <62EB4762-278D-43E7-8699-BBDC47818A50@HIDDEN>
 <87zh2w7ww1.fsf@HIDDEN> <83pn3reyjs.fsf@HIDDEN>
 <87y2ie7for.fsf@HIDDEN> <87h7p0f611.fsf@HIDDEN>
 <87a6uqafmk.fsf@HIDDEN>
 <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN>
 <87zh2q61n6.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <3620abd0-ce79-cc9d-3fb2-255e91f13da1@HIDDEN>
Date: Mon, 7 Dec 2020 04:41:09 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <87zh2q61n6.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

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 <D> <X> -type f <F> -print0 | sort -z |
>   xargs -0 -e rg -inH --color always --no-heading -M 200 --max-columns-preview -e <R>"
> 
> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 6 Dec 2020 21:55:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 06 16:55:47 2020
Received: from localhost ([127.0.0.1]:51548 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1km20Q-0006AE-Qz
	for submit <at> debbugs.gnu.org; Sun, 06 Dec 2020 16:55:47 -0500
Received: from relay10.mail.gandi.net ([217.70.178.230]:54261)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1km20P-0006A2-Oo
 for 44983 <at> debbugs.gnu.org; Sun, 06 Dec 2020 16:55:46 -0500
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay10.mail.gandi.net (Postfix) with ESMTPSA id 26418240002;
 Sun,  6 Dec 2020 21:55:37 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
Organization: LINKOV.NET
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN>
 <83ft4pik35.fsf@HIDDEN> <87sg8p5kw0.fsf@HIDDEN>
 <83eek8hoyx.fsf@HIDDEN> <87h7p4r1n9.fsf@HIDDEN>
 <62EB4762-278D-43E7-8699-BBDC47818A50@HIDDEN>
 <87zh2w7ww1.fsf@HIDDEN> <83pn3reyjs.fsf@HIDDEN>
 <87y2ie7for.fsf@HIDDEN> <87h7p0f611.fsf@HIDDEN>
 <87a6uqafmk.fsf@HIDDEN>
 <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN>
Date: Sun, 06 Dec 2020 23:54:53 +0200
In-Reply-To: <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN> (Dmitry Gutov's
 message of "Sun, 6 Dec 2020 23:37:11 +0200")
Message-ID: <87zh2q61n6.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 44983
Cc: Eli Zaretskii <eliz@HIDDEN>, 44983 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> 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?
It works nice, thanks.  Should this be added by default?

>> 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 <D> <X> -type f <F> -print0 | sort -z |
 xargs -0 -e rg -inH --color always --no-heading -M 200 --max-columns-preview -e <R>"

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.

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.")
 




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 6 Dec 2020 21:37:21 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 06 16:37:21 2020
Received: from localhost ([127.0.0.1]:51525 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1km1ib-0005if-3h
	for submit <at> debbugs.gnu.org; Sun, 06 Dec 2020 16:37:21 -0500
Received: from mail-ed1-f47.google.com ([209.85.208.47]:42870)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1km1iZ-0005iP-8D
 for 44983 <at> debbugs.gnu.org; Sun, 06 Dec 2020 16:37:19 -0500
Received: by mail-ed1-f47.google.com with SMTP id v22so11617083edt.9
 for <44983 <at> 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)
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)
Subject: Re: bug#44983: Truncate long lines of grep output
To: Juri Linkov <juri@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN> <83ft4pik35.fsf@HIDDEN>
 <87sg8p5kw0.fsf@HIDDEN> <83eek8hoyx.fsf@HIDDEN>
 <87h7p4r1n9.fsf@HIDDEN>
 <62EB4762-278D-43E7-8699-BBDC47818A50@HIDDEN>
 <87zh2w7ww1.fsf@HIDDEN> <83pn3reyjs.fsf@HIDDEN>
 <87y2ie7for.fsf@HIDDEN> <87h7p0f611.fsf@HIDDEN>
 <87a6uqafmk.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <b46f7e79-7420-95a8-537c-d0035da56c83@HIDDEN>
Date: Sun, 6 Dec 2020 23:37:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <87a6uqafmk.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 6 Dec 2020 21:16:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 06 16:16:13 2020
Received: from localhost ([127.0.0.1]:51497 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1km1O9-00035d-Lt
	for submit <at> debbugs.gnu.org; Sun, 06 Dec 2020 16:16:13 -0500
Received: from relay7-d.mail.gandi.net ([217.70.183.200]:46153)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1km1O7-000358-8i
 for 44983 <at> debbugs.gnu.org; Sun, 06 Dec 2020 16:16:11 -0500
X-Originating-IP: 91.129.99.98
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 7760820004;
 Sun,  6 Dec 2020 21:16:03 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
Organization: LINKOV.NET
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN>
 <83ft4pik35.fsf@HIDDEN> <87sg8p5kw0.fsf@HIDDEN>
 <83eek8hoyx.fsf@HIDDEN> <87h7p4r1n9.fsf@HIDDEN>
 <62EB4762-278D-43E7-8699-BBDC47818A50@HIDDEN>
 <87zh2w7ww1.fsf@HIDDEN> <83pn3reyjs.fsf@HIDDEN>
 <87y2ie7for.fsf@HIDDEN> <87h7p0f611.fsf@HIDDEN>
Date: Sun, 06 Dec 2020 22:39:15 +0200
In-Reply-To: <87h7p0f611.fsf@HIDDEN> (Juri Linkov's message of "Sat, 
 05 Dec 2020 21:47:06 +0200")
Message-ID: <87a6uqafmk.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 5 Dec 2020 19:53:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 05 14:53:27 2020
Received: from localhost ([127.0.0.1]:48281 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kldcV-0002q7-Ck
	for submit <at> debbugs.gnu.org; Sat, 05 Dec 2020 14:53:27 -0500
Received: from relay10.mail.gandi.net ([217.70.178.230]:54397)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1kldcT-0002pj-SF
 for 44983 <at> debbugs.gnu.org; Sat, 05 Dec 2020 14:53:26 -0500
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay10.mail.gandi.net (Postfix) with ESMTPSA id 6C6F9240006;
 Sat,  5 Dec 2020 19:53:18 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
Organization: LINKOV.NET
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN>
 <83ft4pik35.fsf@HIDDEN> <87sg8p5kw0.fsf@HIDDEN>
 <83eek8hoyx.fsf@HIDDEN> <87h7p4r1n9.fsf@HIDDEN>
 <62EB4762-278D-43E7-8699-BBDC47818A50@HIDDEN>
 <87zh2w7ww1.fsf@HIDDEN> <83pn3reyjs.fsf@HIDDEN>
 <87y2ie7for.fsf@HIDDEN>
Date: Sat, 05 Dec 2020 21:47:06 +0200
In-Reply-To: <87y2ie7for.fsf@HIDDEN> (Juri Linkov's message of "Thu, 
 03 Dec 2020 23:17:08 +0200")
Message-ID: <87h7p0f611.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> I suggested to request the equivalent of "cut -c" to be a feature
>> added to Grep.
>>
>> Failing that, I don't think Emacs should do something like that,
>> especially since 'cut' is not guaranteed to be available.  Users who
>> have such problems can, of course, modify the Grep command to do that.
>
> Finally I solved the long-standing problem by customizing
> grep-find-template to
>
>   "find <D> <X> -type f <F> -print0 | sort -z | xargs -0 -e grep <C> --color=always -inH -e <R> | cut -c -200"

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.

This is like the character limit for a SMS message is 160 characters,
whereas actually this means not characters, but bytes, because
on an UTF text the SMS limit is only 70 characters.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 3 Dec 2020 21:39:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 03 16:39:10 2020
Received: from localhost ([127.0.0.1]:41965 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kkwJi-0007UW-Fc
	for submit <at> debbugs.gnu.org; Thu, 03 Dec 2020 16:39:10 -0500
Received: from relay6-d.mail.gandi.net ([217.70.183.198]:40223)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1kkwJh-0007UK-Ex
 for 44983 <at> debbugs.gnu.org; Thu, 03 Dec 2020 16:39:09 -0500
X-Originating-IP: 91.129.99.98
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 3023BC0002;
 Thu,  3 Dec 2020 21:39:01 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
Organization: LINKOV.NET
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN>
 <83ft4pik35.fsf@HIDDEN> <87sg8p5kw0.fsf@HIDDEN>
 <83eek8hoyx.fsf@HIDDEN> <87h7p4r1n9.fsf@HIDDEN>
 <62EB4762-278D-43E7-8699-BBDC47818A50@HIDDEN>
 <87zh2w7ww1.fsf@HIDDEN> <83pn3reyjs.fsf@HIDDEN>
Date: Thu, 03 Dec 2020 23:17:08 +0200
In-Reply-To: <83pn3reyjs.fsf@HIDDEN> (Eli Zaretskii's message of "Thu, 03 Dec
 2020 16:47:51 +0200")
Message-ID: <87y2ie7for.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

> And when you say "slow" do you mean slow in receiving Grep output,
> slow in displaying the received output, or slow in moving though the
> *grep* buffer after everything was displayed?

Slow in receiving, slow in displaying, or but not slow in moving
though the hidden parts of long lines.

>> Then instead of hiding long lines using font-lock,
>> I tried to do the same using the process filter:
>> 
>> (defun grep-filter ()
>>   (save-excursion
>>     (let ((end (point-marker)))
>>       (goto-char compilation-filter-start)
>>       (forward-line 0)
>>       (while (< (point) end)
>>         (let ((eol (line-end-position)))
>>           (when (> (- eol (point)) 64)
>>             (put-text-property (+ 64 (point)) (line-end-position)
>>                                'display "[…]"))
>>           (forward-line 1))))))
>> 
>> Still very slow.
>
> Same question as above.

Slow in receiving and slow in displaying.

>> Then tried to delete the excessive parts of long lines:
>> 
>> (defun grep-filter-try ()
>>   (save-excursion
>>     (let ((end (point-marker)))
>>       (goto-char compilation-filter-start)
>>       (forward-line 0)
>>       (while (< (point) end)
>>         (let ((eol (line-end-position)))
>>           (when (> (- eol (point)) 64)
>>             (delete-region (min (+ 64 (point)) (point-max)) (line-end-position)))
>>           (forward-line 1))))))
>> 
>> Now Emacs becomes more responsive.  But still output processing
>> takes too much time.
>
> What is "output processing", and how did you measure the time it
> takes?

Measuring visually, it takes too much time to output the long lines.

>> Finally, the last thing to try was the same solution that Richard
>> showed in bug#44941:
>> 
>>   grep -a "$@" | cut -c -200
>> 
>> that gives the best possible result.
>> 
>> I doubt that it would be possible to invent something better.
>> 
>> So the question is should this be customizable for adding
>> `cut -c` automatically to the end of the grep command line,
>> possibly with `stdbuf -oL` suggested by Andreas.
>
> I suggested to request the equivalent of "cut -c" to be a feature
> added to Grep.
>
> Failing that, I don't think Emacs should do something like that,
> especially since 'cut' is not guaranteed to be available.  Users who
> have such problems can, of course, modify the Grep command to do that.

Finally I solved the long-standing problem by customizing
grep-find-template to

  "find <D> <X> -type f <F> -print0 | sort -z | xargs -0 -e grep <C> --color=always -inH -e <R> | cut -c -200"

I'm not sure if something like this could be added to grep, but
here is an example how such a new option could look:


--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=gnu-sort-cut.patch

diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el
index dafba22f77..a5a2142a9e 100644
--- a/lisp/progmodes/grep.el
+++ b/lisp/progmodes/grep.el
@@ -534,6 +534,7 @@ grep-find-use-xargs
                  (const :tag "find -exec {} +" exec-plus)
                  (const :tag "find -print0 | xargs -0" gnu)
                  (const :tag "find -print0 | sort -z | xargs -0'" gnu-sort)
+                 (const :tag "find -print0 | sort -z | xargs -0' ... | cut -c -200" gnu-sort-cut)
                  string
 		 (const :tag "Not Set" nil))
   :set #'grep-apply-setting
@@ -722,7 +723,8 @@ grep-compute-defaults
 		     (goto-char (point-min))
 		     (search-forward "--color" nil t))
 		   ;; Windows and DOS pipes fail `isatty' detection in Grep.
-		   (if (memq system-type '(windows-nt ms-dos))
+		   (if (or (eq grep-find-use-xargs 'gnu-sort-cut)
+                           (memq system-type '(windows-nt ms-dos)))
 		       'always 'auto)))))
 
     (unless (and grep-command grep-find-command
@@ -775,6 +777,9 @@ grep-compute-defaults
 		      ((eq grep-find-use-xargs 'gnu-sort)
 		       (format "%s . -type f -print0 | sort -z | \"%s\" -0 %s"
 			       find-program xargs-program grep-command))
+		      ((eq grep-find-use-xargs 'gnu-sort-cut)
+		       (format "%s . -type f -print0 | sort -z | \"%s\" -0 %s | cut -c -200"
+			       find-program xargs-program grep-command))
 		      ((memq grep-find-use-xargs '(exec exec-plus))
 		       (let ((cmd0 (format "%s . -type f -exec %s"
 					   find-program grep-command))
@@ -803,6 +808,9 @@ grep-compute-defaults
 			((eq grep-find-use-xargs 'gnu-sort)
 			 (format "%s <D> <X> -type f <F> -print0 | sort -z | \"%s\" -0 %s"
 				 find-program xargs-program gcmd))
+			((eq grep-find-use-xargs 'gnu-sort-cut)
+			 (format "%s <D> <X> -type f <F> -print0 | sort -z | \"%s\" -0 %s | cut -c -200"
+				 find-program xargs-program gcmd))
 			((eq grep-find-use-xargs 'exec)
 			 (format "%s <D> <X> -type f <F> -exec %s %s %s%s"
 				 find-program gcmd quot-braces null quot-scolon))

--=-=-=--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 3 Dec 2020 16:30:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 03 11:30:24 2020
Received: from localhost ([127.0.0.1]:41513 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kkrUu-0008K2-Ns
	for submit <at> debbugs.gnu.org; Thu, 03 Dec 2020 11:30:24 -0500
Received: from lists.gnu.org ([209.51.188.17]:57494)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <geb-bug-gnu-emacs@HIDDEN>)
 id 1kkrUs-0008Jo-RB
 for submit <at> debbugs.gnu.org; Thu, 03 Dec 2020 11:30:23 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:41054)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <geb-bug-gnu-emacs@HIDDEN>)
 id 1kkrUs-00021x-DM
 for bug-gnu-emacs@HIDDEN; Thu, 03 Dec 2020 11:30:22 -0500
Received: from static.214.254.202.116.clients.your-server.de
 ([116.202.254.214]:46312 helo=ciao.gmane.io)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <geb-bug-gnu-emacs@HIDDEN>)
 id 1kkrUq-0000XN-6E
 for bug-gnu-emacs@HIDDEN; Thu, 03 Dec 2020 11:30:22 -0500
Received: from list by ciao.gmane.io with local (Exim 4.92)
 (envelope-from <geb-bug-gnu-emacs@HIDDEN>)
 id 1kkrUm-00066g-GD
 for bug-gnu-emacs@HIDDEN; Thu, 03 Dec 2020 17:30:16 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: bug-gnu-emacs@HIDDEN
From: Rudolf Schlatte <rudi@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
Date: Thu, 03 Dec 2020 17:30:10 +0100
Message-ID: <m2czzqett9.fsf@HIDDEN>
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN>
 <83ft4pik35.fsf@HIDDEN> <87sg8p5kw0.fsf@HIDDEN>
 <83eek8hoyx.fsf@HIDDEN> <87h7p4r1n9.fsf@HIDDEN>
 <62EB4762-278D-43E7-8699-BBDC47818A50@HIDDEN>
 <87zh2w7ww1.fsf@HIDDEN> <83pn3reyjs.fsf@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (darwin)
Cancel-Lock: sha1:n2kTAMnTkv6vwSbhOI81FxOsbR8=
Received-SPF: pass client-ip=116.202.254.214;
 envelope-from=geb-bug-gnu-emacs@HIDDEN; helo=ciao.gmane.io
X-Spam_score_int: -15
X-Spam_score: -1.6
X-Spam_bar: -
X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9,
 HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.1 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Juri Linkov <juri@HIDDEN>
>> Cc: dgutov@HIDDEN, 44983 <at> debbugs.gnu.org
>> Date: Wed, 02 Dec 2020 22:53:18 +0200
>> 
>> > Does it help to set bidi-inhibit-bpa non-nil?
>> 
>> This helped to open the file with a lot of '{'.
>> But on minified files grep.el is still very slow.
>
> What are "minified files"?

Javascript libraries are often “minified” for deployment by shortening
identifiers and eliminating whitespace, including linebreaks.  So a
300kb library might be compressed into a 200kb one-line file.  Trying to
open such files makes Emacs unresponsive.

Rudi





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 3 Dec 2020 14:48:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 03 09:48:21 2020
Received: from localhost ([127.0.0.1]:39034 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kkpu9-0000uQ-I3
	for submit <at> debbugs.gnu.org; Thu, 03 Dec 2020 09:48:21 -0500
Received: from eggs.gnu.org ([209.51.188.92]:52514)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kkpu7-0000uB-Kh
 for 44983 <at> debbugs.gnu.org; Thu, 03 Dec 2020 09:48:20 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:44553)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kkpu0-0005Um-MT; Thu, 03 Dec 2020 09:48:12 -0500
Received: from [176.228.60.248] (port=4053 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kkpu0-0000JO-2z; Thu, 03 Dec 2020 09:48:12 -0500
Date: Thu, 03 Dec 2020 16:47:51 +0200
Message-Id: <83pn3reyjs.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
In-Reply-To: <87zh2w7ww1.fsf@HIDDEN> (message from Juri Linkov on
 Wed, 02 Dec 2020 22:53:18 +0200)
Subject: Re: bug#44983: Truncate long lines of grep output
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN>
 <83ft4pik35.fsf@HIDDEN> <87sg8p5kw0.fsf@HIDDEN>
 <83eek8hoyx.fsf@HIDDEN> <87h7p4r1n9.fsf@HIDDEN>
 <62EB4762-278D-43E7-8699-BBDC47818A50@HIDDEN>
 <87zh2w7ww1.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Juri Linkov <juri@HIDDEN>
> Cc: dgutov@HIDDEN, 44983 <at> debbugs.gnu.org
> Date: Wed, 02 Dec 2020 22:53:18 +0200
> 
> > Does it help to set bidi-inhibit-bpa non-nil?
> 
> This helped to open the file with a lot of '{'.
> But on minified files grep.el is still very slow.

What are "minified files"?

And when you say "slow" do you mean slow in receiving Grep output,
slow in displaying the received output, or slow in moving though the
*grep* buffer after everything was displayed?

> Then instead of hiding long lines using font-lock,
> I tried to do the same using the process filter:
> 
> (defun grep-filter ()
>   (save-excursion
>     (let ((end (point-marker)))
>       (goto-char compilation-filter-start)
>       (forward-line 0)
>       (while (< (point) end)
>         (let ((eol (line-end-position)))
>           (when (> (- eol (point)) 64)
>             (put-text-property (+ 64 (point)) (line-end-position)
>                                'display "[…]"))
>           (forward-line 1))))))
> 
> Still very slow.

Same question as above.

> Then tried to delete the excessive parts of long lines:
> 
> (defun grep-filter-try ()
>   (save-excursion
>     (let ((end (point-marker)))
>       (goto-char compilation-filter-start)
>       (forward-line 0)
>       (while (< (point) end)
>         (let ((eol (line-end-position)))
>           (when (> (- eol (point)) 64)
>             (delete-region (min (+ 64 (point)) (point-max)) (line-end-position)))
>           (forward-line 1))))))
> 
> Now Emacs becomes more responsive.  But still output processing
> takes too much time.

What is "output processing", and how did you measure the time it
takes?

> Finally, the last thing to try was the same solution that Richard
> showed in bug#44941:
> 
>   grep -a "$@" | cut -c -200
> 
> that gives the best possible result.
> 
> I doubt that it would be possible to invent something better.
> 
> So the question is should this be customizable for adding
> `cut -c` automatically to the end of the grep command line,
> possibly with `stdbuf -oL` suggested by Andreas.

I suggested to request the equivalent of "cut -c" to be a feature
added to Grep.

Failing that, I don't think Emacs should do something like that,
especially since 'cut' is not guaranteed to be available.  Users who
have such problems can, of course, modify the Grep command to do that.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 2 Dec 2020 21:35:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 02 16:35:24 2020
Received: from localhost ([127.0.0.1]:37580 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kkZmV-0004mW-RL
	for submit <at> debbugs.gnu.org; Wed, 02 Dec 2020 16:35:24 -0500
Received: from relay11.mail.gandi.net ([217.70.178.231]:40881)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1kkZmU-0004mI-7g
 for 44983 <at> debbugs.gnu.org; Wed, 02 Dec 2020 16:35:22 -0500
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay11.mail.gandi.net (Postfix) with ESMTPSA id BE00C100007;
 Wed,  2 Dec 2020 21:35:14 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
Organization: LINKOV.NET
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN>
 <83ft4pik35.fsf@HIDDEN> <87sg8p5kw0.fsf@HIDDEN>
 <83eek8hoyx.fsf@HIDDEN> <87h7p4r1n9.fsf@HIDDEN>
 <62EB4762-278D-43E7-8699-BBDC47818A50@HIDDEN>
Date: Wed, 02 Dec 2020 22:53:18 +0200
In-Reply-To: <62EB4762-278D-43E7-8699-BBDC47818A50@HIDDEN> (Eli Zaretskii's
 message of "Wed, 02 Dec 2020 12:28:17 +0200")
Message-ID: <87zh2w7ww1.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> Or maybe the problem is caused by special characters
>> used in minified web assets that contain many '{' chars.
>> And indeed, after inserting 100 thousands of '{'
>>
>> (insert (propertize (make-string 100000 ?{)
>>          'display "[…]" 'invisible t) "\n")
>>
>> and saving to a file, later visiting such file
>> Emacs becomes unresponsive for indefinite time.
>> But visiting the file with 100 thousands '{'
>> with find-file-literally causes no such problem.
>
> Does it help to set bidi-inhibit-bpa non-nil?

This helped to open the file with a lot of '{'.
But on minified files grep.el is still very slow.

Then instead of hiding long lines using font-lock,
I tried to do the same using the process filter:

(defun grep-filter ()
  (save-excursion
    (let ((end (point-marker)))
      (goto-char compilation-filter-start)
      (forward-line 0)
      (while (< (point) end)
        (let ((eol (line-end-position)))
          (when (> (- eol (point)) 64)
            (put-text-property (+ 64 (point)) (line-end-position)
                               'display "[…]"))
          (forward-line 1))))))

Still very slow.  Then tried to delete the excessive parts of long lines:

(defun grep-filter-try ()
  (save-excursion
    (let ((end (point-marker)))
      (goto-char compilation-filter-start)
      (forward-line 0)
      (while (< (point) end)
        (let ((eol (line-end-position)))
          (when (> (- eol (point)) 64)
            (delete-region (min (+ 64 (point)) (point-max)) (line-end-position)))
          (forward-line 1))))))

Now Emacs becomes more responsive.  But still output processing
takes too much time.

Finally, the last thing to try was the same solution that Richard
showed in bug#44941:

  grep -a "$@" | cut -c -200

that gives the best possible result.

I doubt that it would be possible to invent something better.

So the question is should this be customizable for adding
`cut -c` automatically to the end of the grep command line,
possibly with `stdbuf -oL` suggested by Andreas.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 2 Dec 2020 10:28:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 02 05:28:29 2020
Received: from localhost ([127.0.0.1]:34394 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kkPN6-00057X-MP
	for submit <at> debbugs.gnu.org; Wed, 02 Dec 2020 05:28:29 -0500
Received: from eggs.gnu.org ([209.51.188.92]:35034)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kkPN3-00057B-Ud
 for 44983 <at> debbugs.gnu.org; Wed, 02 Dec 2020 05:28:27 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:46801)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kkPMy-00078O-Mr; Wed, 02 Dec 2020 05:28:20 -0500
Received: from [2001:4df7:1:7649::1] (port=55684)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kkPMx-0006rB-AY; Wed, 02 Dec 2020 05:28:20 -0500
Date: Wed, 02 Dec 2020 12:28:17 +0200
User-Agent: K-9 Mail for Android
In-Reply-To: <87h7p4r1n9.fsf@HIDDEN>
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN> <83ft4pik35.fsf@HIDDEN>
 <87sg8p5kw0.fsf@HIDDEN> <83eek8hoyx.fsf@HIDDEN>
 <87h7p4r1n9.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: bug#44983: Truncate long lines of grep output
To: Juri Linkov <juri@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
Message-ID: <62EB4762-278D-43E7-8699-BBDC47818A50@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

On December 2, 2020 11:35:38 AM GMT+02:00, Juri Linkov <juri@linkov=2Enet> =
wrote:
>
> Or maybe the problem is caused by special characters
> used in minified web assets that contain many '{' chars=2E
> And indeed, after inserting 100 thousands of '{'
>=20
> (insert (propertize (make-string 100000 ?{)
>          'display "[=E2=80=A6]" 'invisible t) "\n")
>=20
> and saving to a file, later visiting such file
> Emacs becomes unresponsive for indefinite time=2E
> But visiting the file with 100 thousands '{'
> with find-file-literally causes no such problem=2E

Does it help to set bidi-inhibit-bpa non-nil?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 2 Dec 2020 09:39:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 02 04:39:27 2020
Received: from localhost ([127.0.0.1]:34246 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kkObf-0001f8-4C
	for submit <at> debbugs.gnu.org; Wed, 02 Dec 2020 04:39:27 -0500
Received: from relay8-d.mail.gandi.net ([217.70.183.201]:43657)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1kkObb-0001ed-0O
 for 44983 <at> debbugs.gnu.org; Wed, 02 Dec 2020 04:39:25 -0500
X-Originating-IP: 91.129.99.98
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 50E3C1BF207;
 Wed,  2 Dec 2020 09:39:14 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
Organization: LINKOV.NET
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN>
 <83ft4pik35.fsf@HIDDEN> <87sg8p5kw0.fsf@HIDDEN>
 <83eek8hoyx.fsf@HIDDEN>
Date: Wed, 02 Dec 2020 11:35:38 +0200
In-Reply-To: <83eek8hoyx.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 02 Dec
 2020 05:21:58 +0200")
Message-ID: <87h7p4r1n9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

>> It's very strange that after adding the text property 'display "[…]"
>> on a very long line, motion commands are still very slow in that buffer.
>>
>> Could you help to understand why hiding long regions
>> doesn't help to improve performance?
>
> I can try, but please tell which commands are slow.  Is it C-f/C-b,
> C-n/C-p, C-v/M-v, something else?

Hmm, something strange is going on.  After inserting million-char lines:

(dotimes (_ 10)
  (insert (propertize (make-string 1000000 ?a)
           'display "[…]" 'invisible t) "\n"))

No problem, everything is still fast, C-f/C-b, C-n/C-p, C-v/M-v
move fast.  After saving to a file, grep on this file is fast
with the previous patch that hides long lines.

However, when grepping on minified web assets files
where all styles and scripts are on one long line,
then output becomes slower and slower as the line
inserted by the grep process filter grows longer.

It works this way: compilation-filter/grep-filter
inserts the next chunk of the long line, then
font-lock applies the rule from the previous patch
that hides the inserted substring starting from the
fixed position from the beginning of the line until
the end of the line, and repeats the same for every
new inserted chunk of the long line.

Maybe instead of using font-lock to hide long parts
of grep lines, it would be better to do the same
directly in compilation-filter/grep-filter?

Or maybe the problem is caused by special characters
used in minified web assets that contain many '{' chars.
And indeed, after inserting 100 thousands of '{'

(insert (propertize (make-string 100000 ?{)
         'display "[…]" 'invisible t) "\n")

and saving to a file, later visiting such file
Emacs becomes unresponsive for indefinite time.
But visiting the file with 100 thousands '{'
with find-file-literally causes no such problem.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 2 Dec 2020 03:22:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 01 22:22:08 2020
Received: from localhost ([127.0.0.1]:33761 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kkIiV-0006kq-VE
	for submit <at> debbugs.gnu.org; Tue, 01 Dec 2020 22:22:08 -0500
Received: from eggs.gnu.org ([209.51.188.92]:47876)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kkIiU-0006kO-Ht
 for 44983 <at> debbugs.gnu.org; Tue, 01 Dec 2020 22:22:06 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:41538)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kkIiP-0002qd-7z; Tue, 01 Dec 2020 22:22:01 -0500
Received: from [176.228.60.248] (port=4700 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kkIiO-0001hj-Pm; Tue, 01 Dec 2020 22:22:01 -0500
Date: Wed, 02 Dec 2020 05:21:58 +0200
Message-Id: <83eek8hoyx.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
In-Reply-To: <87sg8p5kw0.fsf@HIDDEN> (message from Juri Linkov on
 Tue, 01 Dec 2020 22:35:55 +0200)
Subject: Re: bug#44983: Truncate long lines of grep output
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN>
 <83ft4pik35.fsf@HIDDEN> <87sg8p5kw0.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Juri Linkov <juri@HIDDEN>
> Cc: Dmitry Gutov <dgutov@HIDDEN>,  44983 <at> debbugs.gnu.org
> Date: Tue, 01 Dec 2020 22:35:55 +0200
> 
> >> Perhaps (setq truncate-lines t) could help in that case?
> >
> > Not necessarily, because the truncated parts are still in the buffer,
> > and the display code which is slow in that case basically moves
> > through the buffer one character at a time in many cases.  Only some
> > specific scenarios (read: a small number of commands) can jump to the
> > next physical line disregarding the truncated parts.
> 
> It's very strange that after adding the text property 'display "[…]"
> on a very long line, motion commands are still very slow in that buffer.
> 
> Could you help to understand why hiding long regions
> doesn't help to improve performance?

I can try, but please tell which commands are slow.  Is it C-f/C-b,
C-n/C-p, C-v/M-v, something else?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 1 Dec 2020 20:37:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 01 15:37:31 2020
Received: from localhost ([127.0.0.1]:33343 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kkCOx-0003Sa-CX
	for submit <at> debbugs.gnu.org; Tue, 01 Dec 2020 15:37:31 -0500
Received: from relay7-d.mail.gandi.net ([217.70.183.200]:35189)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1kkCOv-0003SB-V0
 for 44983 <at> debbugs.gnu.org; Tue, 01 Dec 2020 15:37:30 -0500
X-Originating-IP: 91.129.99.98
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id E804120004;
 Tue,  1 Dec 2020 20:37:22 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
Organization: LINKOV.NET
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN>
 <83ft4pik35.fsf@HIDDEN>
Date: Tue, 01 Dec 2020 22:35:55 +0200
In-Reply-To: <83ft4pik35.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 01 Dec
 2020 18:09:50 +0200")
Message-ID: <87sg8p5kw0.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

>> Perhaps (setq truncate-lines t) could help in that case?
>
> Not necessarily, because the truncated parts are still in the buffer,
> and the display code which is slow in that case basically moves
> through the buffer one character at a time in many cases.  Only some
> specific scenarios (read: a small number of commands) can jump to the
> next physical line disregarding the truncated parts.

It's very strange that after adding the text property 'display "[…]"
on a very long line, motion commands are still very slow in that buffer.

Could you help to understand why hiding long regions
doesn't help to improve performance?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 1 Dec 2020 20:37:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 01 15:37:28 2020
Received: from localhost ([127.0.0.1]:33340 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kkCOu-0003SL-1z
	for submit <at> debbugs.gnu.org; Tue, 01 Dec 2020 15:37:28 -0500
Received: from relay10.mail.gandi.net ([217.70.178.230]:51169)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1kkCOt-0003S7-41
 for 44983 <at> debbugs.gnu.org; Tue, 01 Dec 2020 15:37:27 -0500
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay10.mail.gandi.net (Postfix) with ESMTPSA id D5F44240003;
 Tue,  1 Dec 2020 20:37:19 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
Organization: LINKOV.NET
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN>
Date: Tue, 01 Dec 2020 22:34:37 +0200
In-Reply-To: <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN> (Dmitry Gutov's
 message of "Tue, 1 Dec 2020 17:02:09 +0200")
Message-ID: <87lfeh6zw8.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>>> Is the same problem exhibited by commands using the Xref UI? I don't
>>> remember seeing it, but of course our projects can be very different.
>> No difference from grep, Xref output has the same problem.
>
> Perhaps (setq truncate-lines t) could help in that case?

I customized truncate-lines to t long ago, and still this doesn't help
to improve performance on long lines in grep output.

> Then the lines would be cut at the window width, as you suggest below.
>
>> This will avoid the need of using such workarounds as in bug#44941:
>> grep -a "$@" | cut -c -200
>
> That might cut filenames unnecessary. Even when those a long, we need them
> in their entirety.
>
> The Grep results parsing code could be changed to only take the first XY
> characters of each line, though.

The proposed patch doesn't cut filenames, it hides only endings of long lines.
But still performance is not much better on very long lines.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 1 Dec 2020 18:27:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 01 13:27:19 2020
Received: from localhost ([127.0.0.1]:33265 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kkAMx-0006RQ-0L
	for submit <at> debbugs.gnu.org; Tue, 01 Dec 2020 13:27:19 -0500
Received: from eggs.gnu.org ([209.51.188.92]:37064)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kkAMv-0006RD-UE
 for 44983 <at> debbugs.gnu.org; Tue, 01 Dec 2020 13:27:18 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:60465)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kkAMp-0003t4-NX; Tue, 01 Dec 2020 13:27:11 -0500
Received: from [176.228.60.248] (port=3873 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kkAMi-0000q3-6x; Tue, 01 Dec 2020 13:27:05 -0500
Date: Tue, 01 Dec 2020 20:26:59 +0200
Message-Id: <83k0u1gz64.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Andreas Schwab <schwab@HIDDEN>
In-Reply-To: <87v9dleaom.fsf@HIDDEN> (message from Andreas Schwab on Tue,
 01 Dec 2020 17:46:33 +0100)
Subject: Re: bug#44983: Truncate long lines of grep output
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN>
 <83ft4pik35.fsf@HIDDEN> <87v9dleaom.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 44983
Cc: juri@HIDDEN, 44983 <at> debbugs.gnu.org, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Andreas Schwab <schwab@HIDDEN>
> Cc: Dmitry Gutov <dgutov@HIDDEN>,  44983 <at> debbugs.gnu.org,  juri@HIDDEN
> Date: Tue, 01 Dec 2020 17:46:33 +0100
> 
> > Not necessarily, because the truncated parts are still in the buffer,
> > and the display code which is slow in that case basically moves
> > through the buffer one character at a time in many cases.  Only some
> > specific scenarios (read: a small number of commands) can jump to the
> > next physical line disregarding the truncated parts.
> 
> But moving though the buffer is much faster than rendering it.

I meant moving in the likes of move_it_to.  These simulate display, so
they are almost as slow as rendering itself.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 1 Dec 2020 16:46:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 01 11:46:38 2020
Received: from localhost ([127.0.0.1]:33179 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kk8nV-0003Ix-Ul
	for submit <at> debbugs.gnu.org; Tue, 01 Dec 2020 11:46:38 -0500
Received: from mail-out.m-online.net ([212.18.0.9]:35520)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <whitebox@HIDDEN>) id 1kk8nT-0003FW-Lt
 for 44983 <at> debbugs.gnu.org; Tue, 01 Dec 2020 11:46:36 -0500
Received: from frontend01.mail.m-online.net (unknown [192.168.8.182])
 by mail-out.m-online.net (Postfix) with ESMTP id 4Clp0B43smz1qsbS;
 Tue,  1 Dec 2020 17:46:34 +0100 (CET)
Received: from localhost (dynscan1.mnet-online.de [192.168.6.70])
 by mail.m-online.net (Postfix) with ESMTP id 4Clp0B2Kycz1s0kX;
 Tue,  1 Dec 2020 17:46:34 +0100 (CET)
X-Virus-Scanned: amavisd-new at mnet-online.de
Received: from mail.mnet-online.de ([192.168.8.182])
 by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new,
 port 10024)
 with ESMTP id ZE6JHM5PD0Vs; Tue,  1 Dec 2020 17:46:33 +0100 (CET)
X-Auth-Info: igPVp1lXzNP6nqmEr9P5BdLkAj+ZUnXsZ274RLJCu+eN9EJqImnh64fIOMmsy9jh
Received: from igel.home (ppp-46-244-164-228.dynamic.mnet-online.de
 [46.244.164.228])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by mail.mnet-online.de (Postfix) with ESMTPSA;
 Tue,  1 Dec 2020 17:46:33 +0100 (CET)
Received: by igel.home (Postfix, from userid 1000)
 id 199DF2C3623; Tue,  1 Dec 2020 17:46:33 +0100 (CET)
From: Andreas Schwab <schwab@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#44983: Truncate long lines of grep output
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN>
 <83ft4pik35.fsf@HIDDEN>
X-Yow: ..  someone in DAYTON, Ohio is selling USED CARPETS to a SERBO-CROATIAN
Date: Tue, 01 Dec 2020 17:46:33 +0100
In-Reply-To: <83ft4pik35.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 01 Dec
 2020 18:09:50 +0200")
Message-ID: <87v9dleaom.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.4 (/)
X-Debbugs-Envelope-To: 44983
Cc: juri@HIDDEN, 44983 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.4 (-)

On Dez 01 2020, Eli Zaretskii wrote:

>> From: Dmitry Gutov <dgutov@HIDDEN>
>> Date: Tue, 1 Dec 2020 17:02:09 +0200
>> 
>> >>> This is a bug problem - often grep output lines are so long
>> >>> that Emacs freezes, so need to kill the process.  Updating
>> >>> manually ignored-files every time a new file causes freeze
>> >>> is very unreliable and time-consuming workaround.
>> >>
>> >> And a non-obvious one (for an average user).
>> >>
>> >> Is the same problem exhibited by commands using the Xref UI? I don't
>> >> remember seeing it, but of course our projects can be very different.
>> > 
>> > No difference from grep, Xref output has the same problem.
>> 
>> Perhaps (setq truncate-lines t) could help in that case?
>
> Not necessarily, because the truncated parts are still in the buffer,
> and the display code which is slow in that case basically moves
> through the buffer one character at a time in many cases.  Only some
> specific scenarios (read: a small number of commands) can jump to the
> next physical line disregarding the truncated parts.

But moving though the buffer is much faster than rendering it.

Andreas.

-- 
Andreas Schwab, schwab@HIDDEN
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 1 Dec 2020 16:10:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 01 11:10:04 2020
Received: from localhost ([127.0.0.1]:33082 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kk8E8-0007MX-G9
	for submit <at> debbugs.gnu.org; Tue, 01 Dec 2020 11:10:04 -0500
Received: from eggs.gnu.org ([209.51.188.92]:55868)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kk8E6-0007Lw-HI
 for 44983 <at> debbugs.gnu.org; Tue, 01 Dec 2020 11:10:02 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:57521)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kk8E0-0004iq-54; Tue, 01 Dec 2020 11:09:56 -0500
Received: from [176.228.60.248] (port=3006 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kk8Dz-00013q-Gw; Tue, 01 Dec 2020 11:09:55 -0500
Date: Tue, 01 Dec 2020 18:09:50 +0200
Message-Id: <83ft4pik35.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN> (message from
 Dmitry Gutov on Tue, 1 Dec 2020 17:02:09 +0200)
Subject: Re: bug#44983: Truncate long lines of grep output
References: <87v9dlc3ti.fsf_-_@HIDDEN>
 <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 44983
Cc: 44983 <at> debbugs.gnu.org, juri@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Dmitry Gutov <dgutov@HIDDEN>
> Date: Tue, 1 Dec 2020 17:02:09 +0200
> 
> >>> This is a bug problem - often grep output lines are so long
> >>> that Emacs freezes, so need to kill the process.  Updating
> >>> manually ignored-files every time a new file causes freeze
> >>> is very unreliable and time-consuming workaround.
> >>
> >> And a non-obvious one (for an average user).
> >>
> >> Is the same problem exhibited by commands using the Xref UI? I don't
> >> remember seeing it, but of course our projects can be very different.
> > 
> > No difference from grep, Xref output has the same problem.
> 
> Perhaps (setq truncate-lines t) could help in that case?

Not necessarily, because the truncated parts are still in the buffer,
and the display code which is slow in that case basically moves
through the buffer one character at a time in many cases.  Only some
specific scenarios (read: a small number of commands) can jump to the
next physical line disregarding the truncated parts.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at 44983 <at> debbugs.gnu.org:


Received: (at 44983) by debbugs.gnu.org; 1 Dec 2020 15:02:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 01 10:02:22 2020
Received: from localhost ([127.0.0.1]:32918 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kk7Ab-0005S4-3D
	for submit <at> debbugs.gnu.org; Tue, 01 Dec 2020 10:02:21 -0500
Received: from mail-wm1-f43.google.com ([209.85.128.43]:37719)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1kk7AY-0005Rl-81
 for 44983 <at> debbugs.gnu.org; Tue, 01 Dec 2020 10:02:20 -0500
Received: by mail-wm1-f43.google.com with SMTP id h21so5764281wmb.2
 for <44983 <at> debbugs.gnu.org>; Tue, 01 Dec 2020 07:02:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=OOYuJTfR5zm7X1po2G3zE+yM6qp7Q99jCD2nEiYfbDQ=;
 b=PbDPJw7Mb1MexmcySCN5SY0sAP+IuJ7Uk4o9oWVFfD3nt+pL4y3b4R1aziaU05ebqE
 dzup8Jso5dlFKzyv3aQ8Y7jEHrSyGjvR2aTEwv9QbYuTdV1Jt2LDS2HoDwtnqpWpb7lP
 bs4OaelUicKRMpXYoQsR8VaRzpx9ve7cTcGqjl2DSz5/N+xxyPfDzoC5oI6ucRWdhxku
 KmwVjno7pQ5+YHIzwjslRFInhaI5ixfeYNZtOhn/3pOwZXAr/iURHDr2xB+Wj4Yryd+v
 3bZ5kcAFzhlFK5tKjzjRSm9iycrp520stZmzt91372qHmg8geW6vUgmcTSYaTZqSLThm
 Z5Ag==
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:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=OOYuJTfR5zm7X1po2G3zE+yM6qp7Q99jCD2nEiYfbDQ=;
 b=TkhEHkIqL0kXJTMhxjPdB8DBbUm4SRl40+AFo3yuC5TIbs1hU8P87TBs9+kYrC14Pl
 wvAHcsG2pMuh1f5MCG6MzG3sVShLIKNsyFFI+3kSgVFDbLPhowmgHokmSJPmECF20GF5
 4ymKrBtMcgvrD4lFkIRFMKzZRxS7Z+KISfW7W+mlc2Yl5EvgjudlLT6SCfLNESxAKCUh
 6gax+nSzP8o26g75C8vGumXlk+uNG0HGS6OkHqtqg/CIJ6WtuZjOLyr3T9aYqoVM2Jq+
 IoNGOk3tUMxAC4aDbkP0kHDRzsrfUCbWjNj/BTQFLDrGQqA0KW0XMHpa03wmvklm/Jgb
 mfDA==
X-Gm-Message-State: AOAM532Hk4C5/j0+5gO4EBDgA1SZdLGcQyfJFzeE4k8m/lozp/IW2Jqm
 JkRmQbsORrJQIlpVYGZe9RZYaZUOCZ+Vhw==
X-Google-Smtp-Source: ABdhPJxbdpvofGWV+mLmQb8cHngxzBR/ZmpCdmhIW4IYvMM9nDPWRRbP7iXQ6Xeu4l/WHTon037tLg==
X-Received: by 2002:a1c:2b05:: with SMTP id r5mr2998853wmr.179.1606834931955; 
 Tue, 01 Dec 2020 07:02:11 -0800 (PST)
Received: from [192.168.0.4] ([66.205.71.3])
 by smtp.googlemail.com with ESMTPSA id x25sm207466wmc.3.2020.12.01.07.02.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 01 Dec 2020 07:02:11 -0800 (PST)
Subject: Re: bug#44983: Truncate long lines of grep output
To: Juri Linkov <juri@HIDDEN>, 44983 <at> debbugs.gnu.org
References: <87v9dlc3ti.fsf_-_@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <cbefb9b0-58ce-40d8-70de-5b39efe12525@HIDDEN>
Date: Tue, 1 Dec 2020 17:02:09 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <87v9dlc3ti.fsf_-_@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 44983
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

On 01.12.2020 10:45, Juri Linkov wrote:
> [New bug report from emacs-devel]
>>>>> For grep output a bigger problem is that grep on binary data
>>>>> might output too long lines before the terminating newline.
>>>>
>>>> (*) We already have this kind of problem with "normal" files which contain
>>>> minified assets (JS or CSS). The file contents are usually normal ASCII,
>>>> but it's just one line which can reach several MBs in length.
>>>>
>>>> The usual way to deal with that is with project-ignores and
>>>> grep-find-ignored-files. That works for both cases.
>>> This is a bug problem - often grep output lines are so long
>>> that Emacs freezes, so need to kill the process.  Updating
>>> manually ignored-files every time a new file causes freeze
>>> is very unreliable and time-consuming workaround.
>>
>> And a non-obvious one (for an average user).
>>
>> Is the same problem exhibited by commands using the Xref UI? I don't
>> remember seeing it, but of course our projects can be very different.
> 
> No difference from grep, Xref output has the same problem.

Perhaps (setq truncate-lines t) could help in that case?

Then the lines would be cut at the window width, as you suggest below.

> This will avoid the need of using such workarounds as in bug#44941:
> 
> grep -a "$@" | cut -c -200

That might cut filenames unnecessary. Even when those a long, we need 
them in their entirety.

The Grep results parsing code could be changed to only take the first XY 
characters of each line, though.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 1 Dec 2020 08:55:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 01 03:55:22 2020
Received: from localhost ([127.0.0.1]:57723 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kk1RS-0003V1-ET
	for submit <at> debbugs.gnu.org; Tue, 01 Dec 2020 03:55:22 -0500
Received: from lists.gnu.org ([209.51.188.17]:38194)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1kk1RR-0003Us-92
 for submit <at> debbugs.gnu.org; Tue, 01 Dec 2020 03:55:21 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:43706)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <juri@HIDDEN>) id 1kk1RR-0002Vj-02
 for bug-gnu-emacs@HIDDEN; Tue, 01 Dec 2020 03:55:21 -0500
Received: from relay11.mail.gandi.net ([217.70.178.231]:43351)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <juri@HIDDEN>) id 1kk1RP-0001oO-2U
 for bug-gnu-emacs@HIDDEN; Tue, 01 Dec 2020 03:55:20 -0500
Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98])
 (Authenticated sender: juri@HIDDEN)
 by relay11.mail.gandi.net (Postfix) with ESMTPSA id B0D4810000B
 for <bug-gnu-emacs@HIDDEN>; Tue,  1 Dec 2020 08:55:15 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: Truncate long lines of grep output
Organization: LINKOV.NET
Date: Tue, 01 Dec 2020 10:45:29 +0200
Message-ID: <87v9dlc3ti.fsf_-_@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=217.70.178.231; envelope-from=juri@HIDDEN;
 helo=relay11.mail.gandi.net
X-Spam_score_int: -25
X-Spam_score: -2.6
X-Spam_bar: --
X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.6 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.6 (--)

[New bug report from emacs-devel]
>>>> For grep output a bigger problem is that grep on binary data
>>>> might output too long lines before the terminating newline.
>>>
>>> (*) We already have this kind of problem with "normal" files which contain
>>> minified assets (JS or CSS). The file contents are usually normal ASCII,
>>> but it's just one line which can reach several MBs in length.
>>>
>>> The usual way to deal with that is with project-ignores and
>>> grep-find-ignored-files. That works for both cases.
>> This is a bug problem - often grep output lines are so long
>> that Emacs freezes, so need to kill the process.  Updating
>> manually ignored-files every time a new file causes freeze
>> is very unreliable and time-consuming workaround.
>
> And a non-obvious one (for an average user).
>
> Is the same problem exhibited by commands using the Xref UI? I don't
> remember seeing it, but of course our projects can be very different.

No difference from grep, Xref output has the same problem.

>> I tried to fix this problem, and fortunately the fix is simple
>> with the 1-liner patch.
>> It does exactly the same thing that we recently did to hide
>> overly long grep command lines with 'grep-find-abbreviate'.
>> The patch even uses the same 'grep-find-abbreviate-properties'
>> to allow clicking the hidden part to expand it.
>> diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el
>> index dafba22f77..e0df2402ee 100644
>> --- a/lisp/progmodes/grep.el
>> +++ b/lisp/progmodes/grep.el
>> @@ -492,6 +492,9 @@ grep-mode-font-lock-keywords
>>         (0 grep-context-face)
>>         (1 (if (eq (char-after (match-beginning 1)) ?\0)
>>                `(face nil display ,(match-string 2)))))
>> +     ;; Hide excessive parts of grep output lines
>> +     ("^.+?:.\\{,64\\}\\(.*\\).\\{10\\}$"
>> +      1 grep-find-abbreviate-properties)
>>        ;; Hide excessive part of rgrep command
>>        ("^find \\(\\. -type d .*\\\\)\\)"
>>         (1 (if grep-find-abbreviate grep-find-abbreviate-properties
>>
>> More customizability could be added later to define the
>> length of the hidden part, etc.
>
> Maybe we'll want it to be dynamically determined by fill-column.
>
> Or just be a big enough value (e.g. 256) that the only lines where this
> rule is hit are obviously too long.

Or maybe determined by the frame width.

This will avoid the need of using such workarounds as in bug#44941:

grep -a "$@" | cut -c -200




Acknowledgement sent to Juri Linkov <juri@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#44983; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 14 Dec 2020 16:30:02 UTC

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