From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#44983: Truncate long lines of grep output Date: Tue, 01 Dec 2020 18:09:50 +0200 Message-ID: <83ft4pik35.fsf@gnu.org> References: <87v9dlc3ti.fsf_-_@mail.linkov.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24592"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 44983@debbugs.gnu.org, juri@linkov.net To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 01 17:11:41 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kk8Fh-0006J0-2f for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Dec 2020 17:11:41 +0100 Original-Received: from localhost ([::1]:48322 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kk8Fg-0007To-4d for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Dec 2020 11:11:40 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46114) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kk8F4-0007TW-9X for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2020 11:11:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49769) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kk8F3-00056t-Us for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2020 11:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kk8F3-0007Nr-Q4 for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2020 11:11:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Dec 2020 16:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44983 X-GNU-PR-Package: emacs Original-Received: via spool by 44983-submit@debbugs.gnu.org id=B44983.160683900428309 (code B ref 44983); Tue, 01 Dec 2020 16:11:01 +0000 Original-Received: (at 44983) by debbugs.gnu.org; 1 Dec 2020 16:10:04 +0000 Original-Received: from localhost ([127.0.0.1]:33082 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kk8E8-0007MX-G9 for submit@debbugs.gnu.org; Tue, 01 Dec 2020 11:10:04 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55868) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kk8E6-0007Lw-HI for 44983@debbugs.gnu.org; Tue, 01 Dec 2020 11:10:02 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57521) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kk8E0-0004iq-54; Tue, 01 Dec 2020 11:09:56 -0500 Original-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 ) id 1kk8Dz-00013q-Gw; Tue, 01 Dec 2020 11:09:55 -0500 In-Reply-To: (message from Dmitry Gutov on Tue, 1 Dec 2020 17:02:09 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:194748 Archived-At: > From: Dmitry Gutov > 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.