From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#44983: Truncate long lines of grep output Date: Tue, 1 Dec 2020 17:02:09 +0200 Message-ID: References: <87v9dlc3ti.fsf_-_@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20716"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 To: Juri Linkov , 44983@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 01 16:03:21 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 1kk7BY-0005FM-41 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Dec 2020 16:03:20 +0100 Original-Received: from localhost ([::1]:57500 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kk7BW-0001k6-V9 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Dec 2020 10:03:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56402) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kk7BH-0001jk-8W for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2020 10:03:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49605) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kk7BG-0005vY-MX for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2020 10:03:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kk7BG-0005T7-H8 for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2020 10:03:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Dec 2020 15:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44983 X-GNU-PR-Package: emacs Original-Received: via spool by 44983-submit@debbugs.gnu.org id=B44983.160683494220965 (code B ref 44983); Tue, 01 Dec 2020 15:03:02 +0000 Original-Received: (at 44983) by debbugs.gnu.org; 1 Dec 2020 15:02:22 +0000 Original-Received: from localhost ([127.0.0.1]:32918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kk7Ab-0005S4-3D for submit@debbugs.gnu.org; Tue, 01 Dec 2020 10:02:21 -0500 Original-Received: from mail-wm1-f43.google.com ([209.85.128.43]:37719) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kk7AY-0005Rl-81 for 44983@debbugs.gnu.org; Tue, 01 Dec 2020 10:02:20 -0500 Original-Received: by mail-wm1-f43.google.com with SMTP id h21so5764281wmb.2 for <44983@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) Original-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) In-Reply-To: <87v9dlc3ti.fsf_-_@mail.linkov.net> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:194740 Archived-At: 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.