From unknown Tue Jun 17 03:39:24 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#44983 <44983@debbugs.gnu.org> To: bug#44983 <44983@debbugs.gnu.org> Subject: Status: Truncate long lines of grep output Reply-To: bug#44983 <44983@debbugs.gnu.org> Date: Tue, 17 Jun 2025 10:39:24 +0000 retitle 44983 Truncate long lines of grep output reassign 44983 emacs submitter 44983 Juri Linkov severity 44983 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 01 03:55:22 2020 Received: (at submit) by debbugs.gnu.org; 1 Dec 2020 08:55:22 +0000 Received: from localhost ([127.0.0.1]:57723 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kk1RS-0003V1-ET for submit@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 ) id 1kk1RR-0003Us-92 for submit@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 ) id 1kk1RR-0002Vj-02 for bug-gnu-emacs@gnu.org; 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 ) id 1kk1RP-0001oO-2U for bug-gnu-emacs@gnu.org; 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@linkov.net) by relay11.mail.gandi.net (Postfix) with ESMTPSA id B0D4810000B for ; Tue, 1 Dec 2020 08:55:15 +0000 (UTC) From: Juri Linkov To: bug-gnu-emacs@gnu.org Subject: Truncate long lines of grep output Organization: LINKOV.NET Date: Tue, 01 Dec 2020 10:45:29 +0200 Message-ID: <87v9dlc3ti.fsf_-_@mail.linkov.net> 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@linkov.net; 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 01 10:02:22 2020 Received: (at 44983) by debbugs.gnu.org; 1 Dec 2020 15:02:22 +0000 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 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 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) 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 , 44983@debbugs.gnu.org References: <87v9dlc3ti.fsf_-_@mail.linkov.net> From: Dmitry Gutov Message-ID: 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_-_@mail.linkov.net> 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 01 11:10:04 2020 Received: (at 44983) by debbugs.gnu.org; 1 Dec 2020 16:10:04 +0000 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 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 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 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 Date: Tue, 01 Dec 2020 18:09:50 +0200 Message-Id: <83ft4pik35.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (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_-_@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: 44983@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 01 11:46:38 2020 Received: (at 44983) by debbugs.gnu.org; 1 Dec 2020 16:46:38 +0000 Received: from localhost ([127.0.0.1]:33179 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kk8nV-0003Ix-Ul for submit@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 ) id 1kk8nT-0003FW-Lt for 44983@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 To: Eli Zaretskii Subject: Re: bug#44983: Truncate long lines of grep output References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> 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@gnu.org> (Eli Zaretskii's message of "Tue, 01 Dec 2020 18:09:50 +0200") Message-ID: <87v9dleaom.fsf@igel.home> 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@linkov.net, 44983@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.4 (-) On Dez 01 2020, Eli Zaretskii wrote: >> 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. But moving though the buffer is much faster than rendering it. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 01 13:27:19 2020 Received: (at 44983) by debbugs.gnu.org; 1 Dec 2020 18:27:19 +0000 Received: from localhost ([127.0.0.1]:33265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkAMx-0006RQ-0L for submit@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 ) id 1kkAMv-0006RD-UE for 44983@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii To: Andreas Schwab In-Reply-To: <87v9dleaom.fsf@igel.home> (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_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87v9dleaom.fsf@igel.home> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: juri@linkov.net, 44983@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Andreas Schwab > Cc: Dmitry Gutov , 44983@debbugs.gnu.org, juri@linkov.net > 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 01 15:37:28 2020 Received: (at 44983) by debbugs.gnu.org; 1 Dec 2020 20:37:28 +0000 Received: from localhost ([127.0.0.1]:33340 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkCOu-0003SL-1z for submit@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 ) id 1kkCOt-0003S7-41 for 44983@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@linkov.net) by relay10.mail.gandi.net (Postfix) with ESMTPSA id D5F44240003; Tue, 1 Dec 2020 20:37:19 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#44983: Truncate long lines of grep output Organization: LINKOV.NET References: <87v9dlc3ti.fsf_-_@mail.linkov.net> Date: Tue, 01 Dec 2020 22:34:37 +0200 In-Reply-To: (Dmitry Gutov's message of "Tue, 1 Dec 2020 17:02:09 +0200") Message-ID: <87lfeh6zw8.fsf@mail.linkov.net> 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@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 01 15:37:31 2020 Received: (at 44983) by debbugs.gnu.org; 1 Dec 2020 20:37:31 +0000 Received: from localhost ([127.0.0.1]:33343 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkCOx-0003Sa-CX for submit@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 ) id 1kkCOv-0003SB-V0 for 44983@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@linkov.net) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id E804120004; Tue, 1 Dec 2020 20:37:22 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#44983: Truncate long lines of grep output Organization: LINKOV.NET References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> Date: Tue, 01 Dec 2020 22:35:55 +0200 In-Reply-To: <83ft4pik35.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 01 Dec 2020 18:09:50 +0200") Message-ID: <87sg8p5kw0.fsf@mail.linkov.net> 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@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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? From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 01 22:22:08 2020 Received: (at 44983) by debbugs.gnu.org; 2 Dec 2020 03:22:08 +0000 Received: from localhost ([127.0.0.1]:33761 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkIiV-0006kq-VE for submit@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 ) id 1kkIiU-0006kO-Ht for 44983@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <87sg8p5kw0.fsf@mail.linkov.net> (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_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> 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@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: Dmitry Gutov , 44983@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? From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 02 04:39:27 2020 Received: (at 44983) by debbugs.gnu.org; 2 Dec 2020 09:39:27 +0000 Received: from localhost ([127.0.0.1]:34246 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkObf-0001f8-4C for submit@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 ) id 1kkObb-0001ed-0O for 44983@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@linkov.net) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 50E3C1BF207; Wed, 2 Dec 2020 09:39:14 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#44983: Truncate long lines of grep output Organization: LINKOV.NET References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> Date: Wed, 02 Dec 2020 11:35:38 +0200 In-Reply-To: <83eek8hoyx.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 02 Dec 2020 05:21:58 +0200") Message-ID: <87h7p4r1n9.fsf@mail.linkov.net> 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@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 02 05:28:29 2020 Received: (at 44983) by debbugs.gnu.org; 2 Dec 2020 10:28:29 +0000 Received: from localhost ([127.0.0.1]:34394 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkPN6-00057X-MP for submit@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 ) id 1kkPN3-00057B-Ud for 44983@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 ) 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 ) 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@mail.linkov.net> References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> 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 From: Eli Zaretskii Message-ID: <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: 44983@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On December 2, 2020 11:35:38 AM GMT+02:00, Juri Linkov = 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? From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 02 16:35:24 2020 Received: (at 44983) by debbugs.gnu.org; 2 Dec 2020 21:35:24 +0000 Received: from localhost ([127.0.0.1]:37580 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkZmV-0004mW-RL for submit@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 ) id 1kkZmU-0004mI-7g for 44983@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@linkov.net) by relay11.mail.gandi.net (Postfix) with ESMTPSA id BE00C100007; Wed, 2 Dec 2020 21:35:14 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#44983: Truncate long lines of grep output Organization: LINKOV.NET References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> Date: Wed, 02 Dec 2020 22:53:18 +0200 In-Reply-To: <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> (Eli Zaretskii's message of "Wed, 02 Dec 2020 12:28:17 +0200") Message-ID: <87zh2w7ww1.fsf@mail.linkov.net> 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@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 03 09:48:21 2020 Received: (at 44983) by debbugs.gnu.org; 3 Dec 2020 14:48:22 +0000 Received: from localhost ([127.0.0.1]:39034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkpu9-0000uQ-I3 for submit@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 ) id 1kkpu7-0000uB-Kh for 44983@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <87zh2w7ww1.fsf@mail.linkov.net> (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_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> <87zh2w7ww1.fsf@mail.linkov.net> 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@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: dgutov@yandex.ru, 44983@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. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 03 11:30:24 2020 Received: (at submit) by debbugs.gnu.org; 3 Dec 2020 16:30:25 +0000 Received: from localhost ([127.0.0.1]:41513 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkrUu-0008K2-Ns for submit@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 ) id 1kkrUs-0008Jo-RB for submit@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 ) id 1kkrUs-00021x-DM for bug-gnu-emacs@gnu.org; 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 ) id 1kkrUq-0000XN-6E for bug-gnu-emacs@gnu.org; Thu, 03 Dec 2020 11:30:22 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1kkrUm-00066g-GD for bug-gnu-emacs@gnu.org; Thu, 03 Dec 2020 17:30:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Rudolf Schlatte Subject: Re: bug#44983: Truncate long lines of grep output Date: Thu, 03 Dec 2020 17:30:10 +0100 Message-ID: References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> <87zh2w7ww1.fsf@mail.linkov.net> <83pn3reyjs.fsf@gnu.org> 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@m.gmane-mx.org; 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) Eli Zaretskii writes: >> From: Juri Linkov >> Cc: dgutov@yandex.ru, 44983@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 From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 03 16:39:10 2020 Received: (at 44983) by debbugs.gnu.org; 3 Dec 2020 21:39:10 +0000 Received: from localhost ([127.0.0.1]:41965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkwJi-0007UW-Fc for submit@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 ) id 1kkwJh-0007UK-Ex for 44983@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@linkov.net) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 3023BC0002; Thu, 3 Dec 2020 21:39:01 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#44983: Truncate long lines of grep output Organization: LINKOV.NET References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> <87zh2w7ww1.fsf@mail.linkov.net> <83pn3reyjs.fsf@gnu.org> Date: Thu, 03 Dec 2020 23:17:08 +0200 In-Reply-To: <83pn3reyjs.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 03 Dec 2020 16:47:51 +0200") Message-ID: <87y2ie7for.fsf@mail.linkov.net> 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@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 -type f -print0 | sort -z | xargs -0 -e grep --color=always -inH -e | 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 -type f -print0 | sort -z | \"%s\" -0 %s" find-program xargs-program gcmd)) + ((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 gcmd)) ((eq grep-find-use-xargs 'exec) (format "%s -type f -exec %s %s %s%s" find-program gcmd quot-braces null quot-scolon)) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 05 14:53:27 2020 Received: (at 44983) by debbugs.gnu.org; 5 Dec 2020 19:53:27 +0000 Received: from localhost ([127.0.0.1]:48281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kldcV-0002q7-Ck for submit@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 ) id 1kldcT-0002pj-SF for 44983@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@linkov.net) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 6C6F9240006; Sat, 5 Dec 2020 19:53:18 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#44983: Truncate long lines of grep output Organization: LINKOV.NET References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> <87zh2w7ww1.fsf@mail.linkov.net> <83pn3reyjs.fsf@gnu.org> <87y2ie7for.fsf@mail.linkov.net> Date: Sat, 05 Dec 2020 21:47:06 +0200 In-Reply-To: <87y2ie7for.fsf@mail.linkov.net> (Juri Linkov's message of "Thu, 03 Dec 2020 23:17:08 +0200") Message-ID: <87h7p0f611.fsf@mail.linkov.net> 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@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 -type f -print0 | sort -z | xargs -0 -e grep --color=always -inH -e | 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 06 16:16:13 2020 Received: (at 44983) by debbugs.gnu.org; 6 Dec 2020 21:16:14 +0000 Received: from localhost ([127.0.0.1]:51497 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1km1O9-00035d-Lt for submit@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 ) id 1km1O7-000358-8i for 44983@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@linkov.net) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 7760820004; Sun, 6 Dec 2020 21:16:03 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#44983: Truncate long lines of grep output Organization: LINKOV.NET References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> <87zh2w7ww1.fsf@mail.linkov.net> <83pn3reyjs.fsf@gnu.org> <87y2ie7for.fsf@mail.linkov.net> <87h7p0f611.fsf@mail.linkov.net> Date: Sun, 06 Dec 2020 22:39:15 +0200 In-Reply-To: <87h7p0f611.fsf@mail.linkov.net> (Juri Linkov's message of "Sat, 05 Dec 2020 21:47:06 +0200") Message-ID: <87a6uqafmk.fsf@mail.linkov.net> 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@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 06 16:37:21 2020 Received: (at 44983) by debbugs.gnu.org; 6 Dec 2020 21:37:21 +0000 Received: from localhost ([127.0.0.1]:51525 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1km1ib-0005if-3h for submit@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 ) id 1km1iZ-0005iP-8D for 44983@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@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 , Eli Zaretskii References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> <87zh2w7ww1.fsf@mail.linkov.net> <83pn3reyjs.fsf@gnu.org> <87y2ie7for.fsf@mail.linkov.net> <87h7p0f611.fsf@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: 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@mail.linkov.net> 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@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 06 16:55:47 2020 Received: (at 44983) by debbugs.gnu.org; 6 Dec 2020 21:55:47 +0000 Received: from localhost ([127.0.0.1]:51548 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1km20Q-0006AE-Qz for submit@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 ) id 1km20P-0006A2-Oo for 44983@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@linkov.net) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 26418240002; Sun, 6 Dec 2020 21:55:37 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#44983: Truncate long lines of grep output Organization: LINKOV.NET References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> <87zh2w7ww1.fsf@mail.linkov.net> <83pn3reyjs.fsf@gnu.org> <87y2ie7for.fsf@mail.linkov.net> <87h7p0f611.fsf@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> Date: Sun, 06 Dec 2020 23:54:53 +0200 In-Reply-To: (Dmitry Gutov's message of "Sun, 6 Dec 2020 23:37:11 +0200") Message-ID: <87zh2q61n6.fsf@mail.linkov.net> 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 , 44983@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 -type f -print0 | sort -z | xargs -0 -e rg -inH --color always --no-heading -M 200 --max-columns-preview -e " But this also requires customizing grep-match-regexp to the value "\033\\[[0-9]*m\033\\[[0-9]*1m\033\\[[0-9]*1m\\(.*?\\)\033\\[[0-9]*0m" provided by Simon in bug#41766. 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.") From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 06 21:41:21 2020 Received: (at 44983) by debbugs.gnu.org; 7 Dec 2020 02:41:21 +0000 Received: from localhost ([127.0.0.1]:51837 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1km6Sn-0002iU-1H for submit@debbugs.gnu.org; Sun, 06 Dec 2020 21:41:21 -0500 Received: from mail-ej1-f47.google.com ([209.85.218.47]:34901) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1km6Sk-0002iG-8H for 44983@debbugs.gnu.org; Sun, 06 Dec 2020 21:41:19 -0500 Received: by mail-ej1-f47.google.com with SMTP id f23so17336440ejk.2 for <44983@debbugs.gnu.org>; Sun, 06 Dec 2020 18:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=5tgD30EuWkTt2tyVQ+PMrb9dcAph/KPazWHnyvIpLC4=; b=UvSwZpelfo9WOUdXFAEX6Oo9Dg1bu0/O93KX/40WBLT+yi9QsirEQpLOYjPCsgEZpP LCxG6WFDQ2xl0Z9qL5Y7wBOv5m9agCVjuo9nAbBOJeS4JlLHaORo+/p3lFCfKa5GDAJo 641bBvyOTpKCUIb00PwrJoYAWEZ+sLNzJFAjmrkx85/vwo/9lWhej+2bju0MDHbnXyOp QI6rVHO1TbLrEWVn+8B6949MW97NhwyKygdwnxT6V6uuCPqZJjyDDwLFoa0jgv+zQvK0 dMHPIoXsOxetVHTbwlQT92cRz6XseMh+IAslQRetUXR66JonmTZyE3bNd4sEVT3/qcbB 85IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5tgD30EuWkTt2tyVQ+PMrb9dcAph/KPazWHnyvIpLC4=; b=m5v/sg5w8tzICQPR+aYKRIGDU+fkFmDNO0iN5xMgEcNQzeW9QWuVRL1V+1Jnt0uPpK /ciqMS2D1+Fc1oIaFGLyBz4jk3z5LaadIjTAiOaGUY2QH+4OHLb8AAAZaWOScHaYAQ+B 3d5GPKBxvkSFLAkj2vFpnD6mtkJY+DLZJISBNqzvpXY0Vjntt0UHVWL3xp/XI5e247Zj PmxrkJ0YBqN1Qkbeb+3BtDU7klMAI2IRtEX8unJ2uX3t/KQgNwC6ccecca34wMLAc/90 Us16ghy9X8IDV5zdjrTgxOLGDA7zxbAD9R+0vbsV996+1bRY4p10na5iKfQlLT69hvEZ VQjg== X-Gm-Message-State: AOAM531Bz2tyxmFRgNZKgF8AZ7N6BaXiY26QbJogiZhFo9lJBJsBi0+4 KyFJG4Docv8+QkEYTZgruwsPxL473gvbqw== X-Google-Smtp-Source: ABdhPJyKLQuYjV3N4BzgObeA/tnKNYzFXpWCMLD9BNngcS+RPcFiabhfn0YKLmSVz6QiLjqdKXqtHw== X-Received: by 2002:a17:906:2612:: with SMTP id h18mr17354784ejc.469.1607308871770; Sun, 06 Dec 2020 18:41:11 -0800 (PST) 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 References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> <87zh2w7ww1.fsf@mail.linkov.net> <83pn3reyjs.fsf@gnu.org> <87y2ie7for.fsf@mail.linkov.net> <87h7p0f611.fsf@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> <87zh2q61n6.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> 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@mail.linkov.net> 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@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 -type f -print0 | sort -z | > xargs -0 -e rg -inH --color always --no-heading -M 200 --max-columns-preview -e " > > But this also requires customizing grep-match-regexp to the value > "\033\\[[0-9]*m\033\\[[0-9]*1m\033\\[[0-9]*1m\\(.*?\\)\033\\[[0-9]*0m" > provided by Simon in bug#41766. It's odd your last suggestion in that bug was not applied (adding :type '(choice) to grep-match-regexp). Perhaps do that now? Although, personally, I've found a symbolic value to work better for a var like that (example: xref-search-program). This way we can ultimately consolidate info about a particular program in one place (some alist). That aside, could you explain the difference between the regexps? Do grep and rg use different colors or something like that? Ideally, of course, that would be just 1 regexp (if that's possible without loss in performance, or significant loss in clarify). > And also required a small fix in grep.el: > > diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el > index dafba22f77..0a5fd6bf5d 100644 > --- a/lisp/progmodes/grep.el > +++ b/lisp/progmodes/grep.el > @@ -412,7 +412,7 @@ grep-regexp-alist > (- mend beg)))))) > nil nil > (3 '(face nil display ":"))) > - ("^Binary file \\(.+\\) matches$" 1 nil nil 0 1)) > + ("^Binary file \\(.+\\) matches" 1 nil nil 0 1)) > "Regexp used to match grep hits. > See `compilation-error-regexp-alist' for format details.") Nice. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 00:35:24 2020 Received: (at 44983) by debbugs.gnu.org; 8 Dec 2020 05:35:24 +0000 Received: from localhost ([127.0.0.1]:56304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmVem-0008GU-Dt for submit@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 ) id 1kmVek-0008GF-7Y for 44983@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 ) 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 ) id 1kmVeZ-0008VA-9Q; Tue, 08 Dec 2020 00:35:12 -0500 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: Dmitry Gutov In-Reply-To: (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_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> <87zh2w7ww1.fsf@mail.linkov.net> <83pn3reyjs.fsf@gnu.org> <87y2ie7for.fsf@mail.linkov.net> <87h7p0f611.fsf@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> Message-Id: Date: Tue, 08 Dec 2020 00:35:11 -0500 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: eliz@gnu.org, 44983@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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) From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 14:15:48 2020 Received: (at 44983) by debbugs.gnu.org; 8 Dec 2020 19:15:48 +0000 Received: from localhost ([127.0.0.1]:59808 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmiSi-0004Si-AX for submit@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 ) id 1kmiSg-0004SS-L8 for 44983@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@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@gnu.org References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> <87zh2w7ww1.fsf@mail.linkov.net> <83pn3reyjs.fsf@gnu.org> <87y2ie7for.fsf@mail.linkov.net> <87h7p0f611.fsf@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: 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: 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@gnu.org, 44983@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 14:48:24 2020 Received: (at 44983) by debbugs.gnu.org; 8 Dec 2020 19:48:24 +0000 Received: from localhost ([127.0.0.1]:59885 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmiyF-0005MF-TC for submit@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 ) id 1kmiyC-0005Lx-DV for 44983@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@linkov.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 02150E000C; Tue, 8 Dec 2020 19:48:12 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#44983: Truncate long lines of grep output Organization: LINKOV.NET References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> <87zh2w7ww1.fsf@mail.linkov.net> <83pn3reyjs.fsf@gnu.org> <87y2ie7for.fsf@mail.linkov.net> <87h7p0f611.fsf@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> <87zh2q61n6.fsf@mail.linkov.net> <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> Date: Tue, 08 Dec 2020 21:41:28 +0200 In-Reply-To: <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> (Dmitry Gutov's message of "Mon, 7 Dec 2020 04:41:09 +0200") Message-ID: <87mtyo3x1z.fsf@mail.linkov.net> 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@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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" From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 22:00:30 2020 Received: (at 44983) by debbugs.gnu.org; 9 Dec 2020 03:00:30 +0000 Received: from localhost ([127.0.0.1]:60601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmpiQ-0001g9-0t for submit@debbugs.gnu.org; Tue, 08 Dec 2020 22:00:30 -0500 Received: from mail-ed1-f50.google.com ([209.85.208.50]:45976) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmpiO-0001fw-9y for 44983@debbugs.gnu.org; Tue, 08 Dec 2020 22:00:28 -0500 Received: by mail-ed1-f50.google.com with SMTP id r5so413304eda.12 for <44983@debbugs.gnu.org>; Tue, 08 Dec 2020 19:00:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zStHS/7jxVBX4MVJRQBLUaN/SXAIwYVwT8PemISEw5c=; b=QLNr62j+CKt+3julIRVEN6iBv0xPkhNh9etwod9BIiOBArXubgMjJ2Th0l3N/eXf02 yhqNPF2py10r2ndsBXyhXWp0FEG0PArF98CH8k1L0urKiBtCaAmoPP2rW+Wekeetj7Dd tVraB8oB4zZ3RyhdLHaYOZ6xixXeyP1CThNmRdOOPN+LYdXJZmCBVy8YoGHJa0t5Menq mLv2B3F+E055jdAS6VNvIVwFXQ4meUMfmhV8vnJ3OIa7UhFp3LpBBczY7B8HRPjjlqiI LSB0/dEgBJAbwoM27YJ/U3rwvNrTLPOq587+/D0NQqslUD9AY0RpBCnqoelGKWsmqIj/ nhwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zStHS/7jxVBX4MVJRQBLUaN/SXAIwYVwT8PemISEw5c=; b=fJF8QeCzvXrAvxxqYWjiVyhM3KIFjZRDX9WZG386Wx82rmiDezh8O68woKhZTEQrRM isbGChV9NPn0ksECdRC9kBPXwzba5idjO2REghfjxSh57l621iYXHw3jO9K9NEIeH0bs FRpBuHHN5eFNpSG5wmUupMrE7XR6uoqiLerIPe7yXmOaSTYalkpl7F5sck8Wf3bWlV7E NL9zmhQ/PYI5DtKqdfvL8jkKrBh77FBlInb8piz8GaEMlVegqmSYVgRPEodfI4WzVPa9 Tfn/XTpmjVMhQWVUOXXqU7WxX5/Y0FnJ1qOhd4GhmRxINj5knar3bZcVQlmiTsYzMUvv BCdw== X-Gm-Message-State: AOAM5330OXklJwr1s2KPillbozrxoKusmqlnl4X+7iXOu1Qrig6t909Z JMHCaxtS82M24STEjO1VgnBxoAnQobOFsw== X-Google-Smtp-Source: ABdhPJwBpQMv3z4IXTaZEOZySncLn415sWNwO3XXseFwKsnTWXVv1ww0DERR0/8Hw/pisV1d6IBxhg== X-Received: by 2002:a50:ee97:: with SMTP id f23mr100887edr.311.1607482821961; Tue, 08 Dec 2020 19:00:21 -0800 (PST) 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 References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> <87zh2w7ww1.fsf@mail.linkov.net> <83pn3reyjs.fsf@gnu.org> <87y2ie7for.fsf@mail.linkov.net> <87h7p0f611.fsf@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> <87zh2q61n6.fsf@mail.linkov.net> <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> <87mtyo3x1z.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <857088a6-fe90-d989-9115-2c159b2a02e6@yandex.ru> 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@mail.linkov.net> 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@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 09 14:22:22 2020 Received: (at 44983) by debbugs.gnu.org; 9 Dec 2020 19:22:22 +0000 Received: from localhost ([127.0.0.1]:36139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kn52c-0004Da-ES for submit@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 ) id 1kn52a-0004D7-5U for 44983@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@linkov.net) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id C8BA01BF207; Wed, 9 Dec 2020 19:22:12 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#44983: Truncate long lines of grep output Organization: LINKOV.NET References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> <87zh2w7ww1.fsf@mail.linkov.net> <83pn3reyjs.fsf@gnu.org> <87y2ie7for.fsf@mail.linkov.net> <87h7p0f611.fsf@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> <87zh2q61n6.fsf@mail.linkov.net> <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> <87mtyo3x1z.fsf@mail.linkov.net> <857088a6-fe90-d989-9115-2c159b2a02e6@yandex.ru> Date: Wed, 09 Dec 2020 21:17:28 +0200 Message-ID: <87lfe6x1uf.fsf@mail.linkov.net> 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@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 09 15:06:13 2020 Received: (at 44983) by debbugs.gnu.org; 9 Dec 2020 20:06:13 +0000 Received: from localhost ([127.0.0.1]:36226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kn5j2-0007U0-Uc for submit@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 ) id 1kn5j0-0007Tk-Nx for 44983@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@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 References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> <87zh2w7ww1.fsf@mail.linkov.net> <83pn3reyjs.fsf@gnu.org> <87y2ie7for.fsf@mail.linkov.net> <87h7p0f611.fsf@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> <87zh2q61n6.fsf@mail.linkov.net> <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> <87mtyo3x1z.fsf@mail.linkov.net> <857088a6-fe90-d989-9115-2c159b2a02e6@yandex.ru> <87lfe6x1uf.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: 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@mail.linkov.net> 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@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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! From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 09 16:46:28 2020 Received: (at 44983) by debbugs.gnu.org; 9 Dec 2020 21:46:28 +0000 Received: from localhost ([127.0.0.1]:36391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kn7I3-0003fG-UX for submit@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 ) id 1kn7I2-0003f0-4Z for 44983@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 To: Juri Linkov Subject: Re: bug#44983: Truncate long lines of grep output Message-ID: References: <83pn3reyjs.fsf@gnu.org> <87y2ie7for.fsf@mail.linkov.net> <87h7p0f611.fsf@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> <87zh2q61n6.fsf@mail.linkov.net> <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> <87mtyo3x1z.fsf@mail.linkov.net> <857088a6-fe90-d989-9115-2c159b2a02e6@yandex.ru> <87lfe6x1uf.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <87lfe6x1uf.fsf@mail.linkov.net> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 44983 Cc: 44983@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 03:34:21 2020 Received: (at 44983) by debbugs.gnu.org; 10 Dec 2020 08:34:21 +0000 Received: from localhost ([127.0.0.1]:36957 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knHP2-0002qL-Rb for submit@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 ) id 1knHP1-0002q4-0p for 44983@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@linkov.net) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 206BBC0009; Thu, 10 Dec 2020 08:34:10 +0000 (UTC) From: Juri Linkov To: Jean Louis Subject: Re: bug#44983: Truncate long lines of grep output Organization: LINKOV.NET References: <83pn3reyjs.fsf@gnu.org> <87y2ie7for.fsf@mail.linkov.net> <87h7p0f611.fsf@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> <87zh2q61n6.fsf@mail.linkov.net> <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> <87mtyo3x1z.fsf@mail.linkov.net> <857088a6-fe90-d989-9115-2c159b2a02e6@yandex.ru> <87lfe6x1uf.fsf@mail.linkov.net> Date: Thu, 10 Dec 2020 10:06:53 +0200 In-Reply-To: (Jean Louis's message of "Thu, 10 Dec 2020 00:43:23 +0300") Message-ID: <87czzi2ju2.fsf@mail.linkov.net> 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@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 03:34:25 2020 Received: (at 44983) by debbugs.gnu.org; 10 Dec 2020 08:34:25 +0000 Received: from localhost ([127.0.0.1]:36960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knHP7-0002qc-2L for submit@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 ) id 1knHP3-0002q9-Qh for 44983@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@linkov.net) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 3AAA31BF208; Thu, 10 Dec 2020 08:34:13 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#44983: Truncate long lines of grep output Organization: LINKOV.NET References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> <87zh2w7ww1.fsf@mail.linkov.net> <83pn3reyjs.fsf@gnu.org> <87y2ie7for.fsf@mail.linkov.net> <87h7p0f611.fsf@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> <87zh2q61n6.fsf@mail.linkov.net> <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> <87mtyo3x1z.fsf@mail.linkov.net> <857088a6-fe90-d989-9115-2c159b2a02e6@yandex.ru> <87lfe6x1uf.fsf@mail.linkov.net> Date: Thu, 10 Dec 2020 10:18:16 +0200 In-Reply-To: (Dmitry Gutov's message of "Wed, 9 Dec 2020 22:06:01 +0200") Message-ID: <87k0tq14qn.fsf@mail.linkov.net> 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@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 05:43:43 2020 Received: (at 44983) by debbugs.gnu.org; 10 Dec 2020 10:43:43 +0000 Received: from localhost ([127.0.0.1]:37109 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knJQF-00063n-Gy for submit@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 ) id 1knJQD-00063V-TK for 44983@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 To: Juri Linkov Subject: Re: bug#44983: Truncate long lines of grep output Message-ID: References: <87h7p0f611.fsf@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> <87zh2q61n6.fsf@mail.linkov.net> <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> <87mtyo3x1z.fsf@mail.linkov.net> <857088a6-fe90-d989-9115-2c159b2a02e6@yandex.ru> <87lfe6x1uf.fsf@mail.linkov.net> <87czzi2ju2.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87czzi2ju2.fsf@mail.linkov.net> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 44983 Cc: 44983@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) * Juri Linkov [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. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 15:48:20 2020 Received: (at 44983) by debbugs.gnu.org; 10 Dec 2020 20:48:20 +0000 Received: from localhost ([127.0.0.1]:39424 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knSrM-0000bv-IR for submit@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 ) id 1knSrK-0000bf-QM for 44983@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@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 References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> <87zh2w7ww1.fsf@mail.linkov.net> <83pn3reyjs.fsf@gnu.org> <87y2ie7for.fsf@mail.linkov.net> <87h7p0f611.fsf@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> <87zh2q61n6.fsf@mail.linkov.net> <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> <87mtyo3x1z.fsf@mail.linkov.net> <857088a6-fe90-d989-9115-2c159b2a02e6@yandex.ru> <87lfe6x1uf.fsf@mail.linkov.net> <87k0tq14qn.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <3de35876-d646-54d9-dcf7-6f307eb41fa0@yandex.ru> 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@mail.linkov.net> 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@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 12 16:08:47 2020 Received: (at 44983) by debbugs.gnu.org; 12 Dec 2020 21:08:47 +0000 Received: from localhost ([127.0.0.1]:46917 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koC8E-0004uq-SR for submit@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 ) id 1koC8D-0004uP-8Y for 44983@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@linkov.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 3EEA960005; Sat, 12 Dec 2020 21:08:37 +0000 (UTC) From: Juri Linkov To: Jean Louis Subject: Re: bug#44983: Truncate long lines of grep output Organization: LINKOV.NET References: <87h7p0f611.fsf@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> <87zh2q61n6.fsf@mail.linkov.net> <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> <87mtyo3x1z.fsf@mail.linkov.net> <857088a6-fe90-d989-9115-2c159b2a02e6@yandex.ru> <87lfe6x1uf.fsf@mail.linkov.net> <87czzi2ju2.fsf@mail.linkov.net> Date: Sat, 12 Dec 2020 22:42:13 +0200 In-Reply-To: (Jean Louis's message of "Thu, 10 Dec 2020 13:08:10 +0300") Message-ID: <87bley7o4a.fsf@mail.linkov.net> 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@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 13 10:11:59 2020 Received: (at 44983) by debbugs.gnu.org; 13 Dec 2020 15:11:59 +0000 Received: from localhost ([127.0.0.1]:49918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koT2V-00066q-KV for submit@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 ) id 1koT2U-00066d-6Y for 44983@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <87bley7o4a.fsf@mail.linkov.net> (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@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> <87zh2q61n6.fsf@mail.linkov.net> <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> <87mtyo3x1z.fsf@mail.linkov.net> <857088a6-fe90-d989-9115-2c159b2a02e6@yandex.ru> <87lfe6x1uf.fsf@mail.linkov.net> <87czzi2ju2.fsf@mail.linkov.net> <87bley7o4a.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: 44983@debbugs.gnu.org, bugs@gnu.support, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Date: Sat, 12 Dec 2020 22:42:13 +0200 > Cc: 44983@debbugs.gnu.org, Dmitry Gutov > > > 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". From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 13 12:32:12 2020 Received: (at 44983) by debbugs.gnu.org; 13 Dec 2020 17:32:12 +0000 Received: from localhost ([127.0.0.1]:50035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koVEC-0001if-BL for submit@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 ) id 1koVEA-0001iS-UI for 44983@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 To: Juri Linkov Subject: Re: bug#44983: Truncate long lines of grep output Message-ID: References: <87zh2q61n6.fsf@mail.linkov.net> <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> <87mtyo3x1z.fsf@mail.linkov.net> <857088a6-fe90-d989-9115-2c159b2a02e6@yandex.ru> <87lfe6x1uf.fsf@mail.linkov.net> <87czzi2ju2.fsf@mail.linkov.net> <87bley7o4a.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87bley7o4a.fsf@mail.linkov.net> 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 [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@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.1 (/) * Juri Linkov [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. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 13 12:36:56 2020 Received: (at 44983) by debbugs.gnu.org; 13 Dec 2020 17:36:56 +0000 Received: from localhost ([127.0.0.1]:50040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koVIl-0001pQ-UY for submit@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 ) id 1koVIk-0001pA-0c for 44983@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 To: Eli Zaretskii Subject: Re: bug#44983: Truncate long lines of grep output Message-ID: References: <87zh2q61n6.fsf@mail.linkov.net> <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> <87mtyo3x1z.fsf@mail.linkov.net> <857088a6-fe90-d989-9115-2c159b2a02e6@yandex.ru> <87lfe6x1uf.fsf@mail.linkov.net> <87czzi2ju2.fsf@mail.linkov.net> <87bley7o4a.fsf@mail.linkov.net> <838sa1eo5u.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <838sa1eo5u.fsf@gnu.org> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 44983 Cc: dgutov@yandex.ru, 44983@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) * Eli Zaretskii [2020-12-13 18:12]: > > From: Juri Linkov > > Date: Sat, 12 Dec 2020 22:42:13 +0200 > > Cc: 44983@debbugs.gnu.org, Dmitry Gutov > > > > > 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". From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 13 15:43:16 2020 Received: (at 44983) by debbugs.gnu.org; 13 Dec 2020 20:43:16 +0000 Received: from localhost ([127.0.0.1]:50527 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koYD6-0004rH-2z for submit@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 ) id 1koYD5-0004qj-DG for 44983@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@linkov.net) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id E290E40002; Sun, 13 Dec 2020 20:43:07 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#44983: Truncate long lines of grep output Organization: LINKOV.NET References: <87h7p0f611.fsf@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> <87zh2q61n6.fsf@mail.linkov.net> <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> <87mtyo3x1z.fsf@mail.linkov.net> <857088a6-fe90-d989-9115-2c159b2a02e6@yandex.ru> <87lfe6x1uf.fsf@mail.linkov.net> <87czzi2ju2.fsf@mail.linkov.net> <87bley7o4a.fsf@mail.linkov.net> <838sa1eo5u.fsf@gnu.org> Date: Sun, 13 Dec 2020 22:17:23 +0200 In-Reply-To: <838sa1eo5u.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 13 Dec 2020 17:11:41 +0200") Message-ID: <874kkpcvfw.fsf@mail.linkov.net> 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@debbugs.gnu.org, bugs@gnu.support, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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"? From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 14 11:15:27 2020 Received: (at 44983) by debbugs.gnu.org; 14 Dec 2020 16:15:27 +0000 Received: from localhost ([127.0.0.1]:53938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koqVT-0000Uz-Eh for submit@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 ) id 1koqVS-0000Nx-4n for 44983@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <874kkpcvfw.fsf@mail.linkov.net> (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@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> <87zh2q61n6.fsf@mail.linkov.net> <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> <87mtyo3x1z.fsf@mail.linkov.net> <857088a6-fe90-d989-9115-2c159b2a02e6@yandex.ru> <87lfe6x1uf.fsf@mail.linkov.net> <87czzi2ju2.fsf@mail.linkov.net> <87bley7o4a.fsf@mail.linkov.net> <838sa1eo5u.fsf@gnu.org> <874kkpcvfw.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: 44983@debbugs.gnu.org, bugs@gnu.support, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: bugs@gnu.support, 44983@debbugs.gnu.org, dgutov@yandex.ru > 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 14 15:09:44 2020 Received: (at 44983) by debbugs.gnu.org; 14 Dec 2020 20:09:44 +0000 Received: from localhost ([127.0.0.1]:54625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kouAC-0002C3-Jk for submit@debbugs.gnu.org; Mon, 14 Dec 2020 15:09:44 -0500 Received: from mail-ej1-f51.google.com ([209.85.218.51]:34164) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kouAB-0002Bq-K4 for 44983@debbugs.gnu.org; Mon, 14 Dec 2020 15:09:44 -0500 Received: by mail-ej1-f51.google.com with SMTP id g20so24371769ejb.1 for <44983@debbugs.gnu.org>; Mon, 14 Dec 2020 12:09:43 -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=rDEyKWl9wiEwJ39uRXsp+w1ZhuHhg0lPEmuZkRtKLwM=; b=p4CymdhjJBi7Kpy1XpagGKXOAsrdPYFf1RAtgOQkiuLzUEP4C6+igPb7tZGduDjmoJ nb7ZNx93AQ6qD8/AxJ6ZDrMOtc67aeq+MnhX6WUa9Vu8O8EhFOw6MiX0wLRnAAht76Tz yCwYEenUmYYefXe2I1gUre4pPrQ4Z2UEZZGK/s5Q7LEBYaPlBGQfuoXlPujNGWha4VMm pTwnP3wz55Hrd9bPw+QzO6u3m0Ezp2Kxz4pW8L/RGzqgwN87tZcPCX7MSGZ2kVUIFW2K 8/uSK7YuXDDlrzYXTDdgkR81wRO1eFHJLrFIyH57kfleuIKH9haRRuQM9qUlC1vRxsSV GX0g== 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=rDEyKWl9wiEwJ39uRXsp+w1ZhuHhg0lPEmuZkRtKLwM=; b=QjXT61EvqlktJ/6VXXAO4/qh32Upn1HmmiatR2yhDyAJF6rbrYnkm9U+veR8lZAIX4 3FpTbfz95cVBp7zXESMfyGDQGxzLKslxjmaTWzW+lPInNSQg0zmIzCH5bfgmJSVuSnP7 Ee1RuAwjYtBlPGPlTbJzh57WkDyHPmyMin70p2+FvICQZ6LLCDoXLRU47Vj9DNJoisth V4Py0kBNNLJQ8s13jv4E8N6Om+pgCQ2C3Fft+cWya9TbAZssj3NxtberW+HEn1NdVaMe SmndflvOof/my7Aex9SmvmQfWaIresJFAx5kLriaNnvm2DIEdkoRVH6QwXMvFeGul/z9 20sw== X-Gm-Message-State: AOAM531maDXBXaWm8yfCv3EFAEaBumwYPzMkqQomsMfxXk0J1R2UyrgI FKxXtS3jNvzKCWv6PuPv7KfagTapTLtS+w== X-Google-Smtp-Source: ABdhPJwqZsmDA94GWm49/od8HEM1hhGEFTm4o2aKYMwCd8SHExNbdS+NZwmKylMZrtmsZ8JUTTx9sg== X-Received: by 2002:a17:906:cf81:: with SMTP id um1mr24737786ejb.122.1607976577571; Mon, 14 Dec 2020 12:09:37 -0800 (PST) Received: from [192.168.0.5] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id mb22sm14402819ejb.35.2020.12.14.12.09.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Dec 2020 12:09:36 -0800 (PST) Subject: Re: bug#44983: Truncate long lines of grep output To: Eli Zaretskii , Juri Linkov References: <87h7p0f611.fsf@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> <87zh2q61n6.fsf@mail.linkov.net> <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> <87mtyo3x1z.fsf@mail.linkov.net> <857088a6-fe90-d989-9115-2c159b2a02e6@yandex.ru> <87lfe6x1uf.fsf@mail.linkov.net> <87czzi2ju2.fsf@mail.linkov.net> <87bley7o4a.fsf@mail.linkov.net> <838sa1eo5u.fsf@gnu.org> <874kkpcvfw.fsf@mail.linkov.net> <835z54cqk3.fsf@gnu.org> From: Dmitry Gutov Message-ID: Date: Mon, 14 Dec 2020 22:09:34 +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: <835z54cqk3.fsf@gnu.org> 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@debbugs.gnu.org, bugs@gnu.support X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 14.12.2020 18:15, Eli Zaretskii wrote: >>>>> 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. Perhaps a better option would be to take advantage of the 'transient' package (currently in GNU ELPA, but unreleased). Here's an example of its UI (bottom window): https://camo.githubusercontent.com/f87497aec74dd0efee4ef78ba2b33b24d5535446b5d5cbef768653f4b945c38c/687474703a2f2f726561646d652e656d6163736169722e6d652f7472616e7369656e742e706e67 From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 24 15:38:39 2020 Received: (at 44983) by debbugs.gnu.org; 24 Dec 2020 20:38:39 +0000 Received: from localhost ([127.0.0.1]:56064 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ksXNe-0008I9-R9 for submit@debbugs.gnu.org; Thu, 24 Dec 2020 15:38:39 -0500 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:43541) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ksXNb-0008HU-EC for 44983@debbugs.gnu.org; Thu, 24 Dec 2020 15:38:37 -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@linkov.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id E124FE0003; Thu, 24 Dec 2020 20:38:27 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#44983: Truncate long lines of grep output Organization: LINKOV.NET References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> <87zh2w7ww1.fsf@mail.linkov.net> <83pn3reyjs.fsf@gnu.org> <87y2ie7for.fsf@mail.linkov.net> <87h7p0f611.fsf@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> <87zh2q61n6.fsf@mail.linkov.net> <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> <87mtyo3x1z.fsf@mail.linkov.net> <857088a6-fe90-d989-9115-2c159b2a02e6@yandex.ru> <87lfe6x1uf.fsf@mail.linkov.net> Date: Thu, 24 Dec 2020 22:33:18 +0200 In-Reply-To: <87lfe6x1uf.fsf@mail.linkov.net> (Juri Linkov's message of "Wed, 09 Dec 2020 21:17:28 +0200") Message-ID: <87pn2zkkq9.fsf@mail.linkov.net> 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.7 (/) X-Debbugs-Envelope-To: 44983 Cc: 44983@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-=-= Content-Type: text/plain > Anyway, I found the shortest change needed to support ripgrep, > and pushed to master. Here is another patch needed to support rg because currently rg fails when --color is used without a value. OTOH, in grep --color is the same as --color=auto, so this is a win-win situation: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=grep-color-auto.patch diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el index 5dc99cc7e9..ef73dac4c0 100644 --- a/lisp/progmodes/grep.el +++ b/lisp/progmodes/grep.el @@ -79,7 +79,7 @@ grep-highlight-matches markers for highlighting and adds the --color option in front of any explicit grep options before starting the grep. -When this option is `auto', grep uses `--color' to highlight +When this option is `auto', grep uses `--color=auto' to highlight matches only when it outputs to a terminal (when `grep' is the last command in the pipe), thus avoiding the use of any potentially-harmful escape sequences when standard output goes to a file or pipe. @@ -95,7 +95,7 @@ grep-highlight-matches :type '(choice (const :tag "Do not highlight matches with grep markers" nil) (const :tag "Highlight matches with grep markers" t) (const :tag "Use --color=always" always) - (const :tag "Use --color" auto) + (const :tag "Use --color=auto" auto) (other :tag "Not Set" auto-detect)) :set #'grep-apply-setting :version "22.1") @@ -743,7 +743,7 @@ grep-compute-defaults `(nil nil nil "--color" "x" ,(null-device)) nil 1) (if (eq grep-highlight-matches 'always) - "--color=always" "--color")) + "--color=always" "--color=auto")) "") grep-options))) (unless grep-template @@ -1000,7 +1000,7 @@ grep-expand-template ((eq grep-highlight-matches 'always) (push "--color=always" opts)) ((eq grep-highlight-matches 'auto) - (push "--color" opts))) + (push "--color=auto" opts))) opts)) (excl . ,excl) (dir . ,dir) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 24 18:39:05 2020 Received: (at 44983) by debbugs.gnu.org; 24 Dec 2020 23:39:06 +0000 Received: from localhost ([127.0.0.1]:56272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ksaCH-0004HD-Nx for submit@debbugs.gnu.org; Thu, 24 Dec 2020 18:39:05 -0500 Received: from mail-ej1-f47.google.com ([209.85.218.47]:44247) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ksaCC-0004Gd-Ik for 44983@debbugs.gnu.org; Thu, 24 Dec 2020 18:39:04 -0500 Received: by mail-ej1-f47.google.com with SMTP id w1so4780178ejf.11 for <44983@debbugs.gnu.org>; Thu, 24 Dec 2020 15:39:00 -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=WE3s0zG56/sHOD54gwOKa6bIgrx7PClQTnPSrclzcAs=; b=iROEWjw6AMLCkIoRopjfCBB62Ig8zYwL6MhhQwYkELK5ePeZPe+zqEkmnp241RnUzr v7bPoh42ThdZmiqw86TGl3YL0ThfmXhCg8jJlomPsx//1/DkGz2CItpvSp87A8EYREX9 n3rXJkAztaved5Dg25jOmYxA6MvzaeuapZigDohcnCcqLwszKG6vLHTkmolFiqQJ7LhX tCR/i74ERz4RRl6URiCUx/TRvj2SOJ1S6fhymzZ0Xlm84tF+wf4DT+UVGewqvE9KgJLw VokpcXzQRPsbStF7Plu8TZCie4DjPvyVtOUpIjbpQ2cDcTHr65ZNY6QtklCZGuwemQK4 K1Ew== 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=WE3s0zG56/sHOD54gwOKa6bIgrx7PClQTnPSrclzcAs=; b=uR/ehRo212hf2hWhTon7J0WaITaEGp5/Q4xSW1Lh/VAyWnFcO7MoiCNjEqWG/digzb Tmrf5M60YDr4fIY36w2kX9aXHnxJNupQtmVKnffV5Zm5Z3LEjHPKFB2Cl6/X0i3Lb/gi wukLY34tKq/8D97oKczTQBQ8OjQzURwLtvMog1Gl50nc9I1jON0sZqBQj8aNUmSdcF8N t2NINVBNVPAFjRt3Xyuji+ltzb8juUZpYNGVB90bd088UCA4Ot8dH3v23BAL7KdWCBh9 6O9J1q0OeRv9IdKo4VQw2WlOzKqTWEXi0p9/QFI9Itn8+l21brtsOkg+EzfS5kX5uVGD +UuQ== X-Gm-Message-State: AOAM5309OJwGl8RwwdfA0mC39henba42dXceL2SG4MIHNx+nZwKfprvQ phAZDi63GCtJvVqt5+PqSVH9Vk1ACjO2eA== X-Google-Smtp-Source: ABdhPJzb0SXMuZqw5LZslqHHNPMK+x8CcT/ryfZE4rsCUYaW+ITQfKvQBNdy2yUH8gpuLboIIaKirg== X-Received: by 2002:a17:906:a48:: with SMTP id x8mr29208055ejf.444.1608853134214; Thu, 24 Dec 2020 15:38:54 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id i18sm18887790edt.68.2020.12.24.15.38.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Dec 2020 15:38:53 -0800 (PST) Subject: Re: bug#44983: Truncate long lines of grep output To: Juri Linkov References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <62EB4762-278D-43E7-8699-BBDC47818A50@gnu.org> <87zh2w7ww1.fsf@mail.linkov.net> <83pn3reyjs.fsf@gnu.org> <87y2ie7for.fsf@mail.linkov.net> <87h7p0f611.fsf@mail.linkov.net> <87a6uqafmk.fsf@mail.linkov.net> <87zh2q61n6.fsf@mail.linkov.net> <3620abd0-ce79-cc9d-3fb2-255e91f13da1@yandex.ru> <87mtyo3x1z.fsf@mail.linkov.net> <857088a6-fe90-d989-9115-2c159b2a02e6@yandex.ru> <87lfe6x1uf.fsf@mail.linkov.net> <87pn2zkkq9.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <18e81d13-c805-abdc-e0d5-f1228ae71269@yandex.ru> Date: Fri, 25 Dec 2020 01:38:51 +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: <87pn2zkkq9.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 44983 Cc: 44983@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) On 24.12.2020 22:33, Juri Linkov wrote: > Here is another patch needed to support rg because currently rg fails > when --color is used without a value. OTOH, in grep --color is the same as > --color=auto, so this is a win-win situation: Makes sense. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 07:39:53 2022 Received: (at 44983) by debbugs.gnu.org; 29 Apr 2022 11:39:53 +0000 Received: from localhost ([127.0.0.1]:51003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkOyW-0000Hh-Rd for submit@debbugs.gnu.org; Fri, 29 Apr 2022 07:39:53 -0400 Received: from quimby.gnus.org ([95.216.78.240]:36852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkOyV-0000HT-TM for 44983@debbugs.gnu.org; Fri, 29 Apr 2022 07:39:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=nduQx8n9kENxDFFYr8VPxuwcX8yjXLNBxztZq8F3le0=; b=gV8leLNLic2Du85jwtIvapuFNN Ail4SZVc+x/aZLU9qtRpHo5zFC0VhedqfijlkB9Q9/Dcxf2tObNfIXqrrP5xWI5C2j+T5VHXidhDs fVktQiFPpylDse57qRbt90X3NrI+UBRu9AUAXs5c2hKOL7Kilv7L+1XeEz6BWjstqKws=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkOyM-0006pm-IA; Fri, 29 Apr 2022 13:39:44 +0200 From: Lars Ingebrigtsen To: Juri Linkov Subject: Re: bug#44983: Truncate long lines of grep output References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> X-Now-Playing: Kid606's _Should I kill myself or have a red bull: Live Set 2013_: "Part Two- 5. Dark Archipelago 6. Tokyo (Kid606 remix of Magic Panda)" Date: Fri, 29 Apr 2022 13:39:41 +0200 In-Reply-To: <87h7p4r1n9.fsf@mail.linkov.net> (Juri Linkov's message of "Wed, 02 Dec 2020 11:35:38 +0200") Message-ID: <87tuacf79e.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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 @@CONTACT_ADDRESS@@ for details. Content preview: Juri Linkov writes: > 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? I now have a rough patch that does this, but the problem is that even if I splat a "..." display over the text, font-lock seems to insist on going over the data anyway, so the display is still dog slo [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: Eli Zaretskii , 44983@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Juri Linkov writes: > 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? I now have a rough patch that does this, but the problem is that even if I splat a "..." display over the text, font-lock seems to insist on going over the data anyway, so the display is still dog slow. I thought I remembered there was a way to say to font-lock "ignore this bit of the buffer", but I can't find it now. Do I misremember? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 08:22:25 2022 Received: (at 44983) by debbugs.gnu.org; 29 Apr 2022 12:22:25 +0000 Received: from localhost ([127.0.0.1]:51099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkPdh-0005mf-IT for submit@debbugs.gnu.org; Fri, 29 Apr 2022 08:22:25 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37002) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkPdf-0005mS-Lf for 44983@debbugs.gnu.org; Fri, 29 Apr 2022 08:22:24 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47098) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkPdZ-0000R0-KO; Fri, 29 Apr 2022 08:22:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=jza7B08KbFeCBc4VZy4y7dKXGcdJG8mgT3ibgIuu/1g=; b=JqYilNVMM3nu uNfxHq0okMeTQvecqqEM4g86cQMbQtvU3MYIhQ/aEIIq6l1CEmk6hbayYtOafzMx8Gb0p5UiPqGpO dg6U85zPArRRx45UgobX4YOubhfzMZcwsNYPycQNgzoK4B3RKq6zu0hg/In/8I3VK/V19PTvirEcr vyTj9bJenZcjVggLSZWwZgDSFkUZriOhXgft6zTgni0zCOYCtI/wrEUBNxogf3RyrZigGK0mwOcJK 06VDCGNleF5S29p3hdVPl8w1MYrc52hJM7lq6vylINgqPH2dM0tYGPCnfRl7bCb48LrQ2WsfUw7uZ 433G9ebS6Vb7hMe2eR3QvQ==; Received: from [87.69.77.57] (port=3267 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkPdY-0006Gr-0M; Fri, 29 Apr 2022 08:22:16 -0400 Date: Fri, 29 Apr 2022 15:22:18 +0300 Message-Id: <83tuac9j0l.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87tuacf79e.fsf@gnus.org> (message from Lars Ingebrigtsen on Fri, 29 Apr 2022 13:39:41 +0200) Subject: Re: bug#44983: Truncate long lines of grep output References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <87tuacf79e.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: dgutov@yandex.ru, 44983@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: Eli Zaretskii , 44983@debbugs.gnu.org, dgutov@yandex.ru > Date: Fri, 29 Apr 2022 13:39:41 +0200 > > I thought I remembered there was a way to say to font-lock "ignore this > bit of the buffer", but I can't find it now. Do I misremember? Make the text invisible? If that doesn't help either, I suggest to profile the code, because it could be the slow display is due to something else. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 08:42:01 2022 Received: (at 44983) by debbugs.gnu.org; 29 Apr 2022 12:42:01 +0000 Received: from localhost ([127.0.0.1]:51137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkPwe-0008SX-T2 for submit@debbugs.gnu.org; Fri, 29 Apr 2022 08:42:01 -0400 Received: from quimby.gnus.org ([95.216.78.240]:37448) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkPwd-0008SL-4W for 44983@debbugs.gnu.org; Fri, 29 Apr 2022 08:41:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=iJRfb4ZF5p7IEDdfHzOeC8SZCAYolpBxfiWGc6LBwME=; b=FBGjJWMmPWReKxRxUgyXxSSA5y 6j9+WvCV463dIMgz5NfGs0AXp0Crs6klm71FW/SANN7YNe+9JU8ug4R6gLKPtgQwDP63LkjzttJp8 NB4S7dV8MCKRAq9/mxcgJjtGYSeGp/KidHxDiULEUJDsILqIBbGEzi3NaDcDRr3+RBrk=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkPwU-0008CY-3x; Fri, 29 Apr 2022 14:41:52 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#44983: Truncate long lines of grep output References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <87tuacf79e.fsf@gnus.org> <83tuac9j0l.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAJ1BMVEUnKjFIWW55hYZX Ym+RmZyMd4beO1DQtL/MydHqHjSzucl8quv////g3T9KAAAAAWJLR0QMgbNRYwAAAAd0SU1FB+YE HQwnHwXtPUkAAAGjSURBVDjLbdFLbsIwEAZgrmDcCxBygcSpVHVpoqrqtmXBvg2EA5DQAxCLAwR5 XzXWdN37dfyIY1MGCYb5/DtOMpvN5nmSJEv9tSCJrxmC/5OR+U1YEkJuQoaQ3wAdIBSblPMyBB3Q kbTUZUA3nJs5obwc4c4uWVgg6QSm4ZmD+RWsCIkiHjIPRQRTgNAIpoDbywEP5vbyDhYZu4pY4Czc ihYeVixMUOaBZZSxac4KBytmyozZfVW95g7sPNMPPW27ppYfqQFul+MUoGla0aEYWOBilrzAGWBo jMj+Tb8PyvJSCSFAB7CEONbvCJRmz8LOh62R5tRXCAUr9Bw3+tlIU31V9QgPehsT+JVj1VsNnQvA xoNsDeyVHsPTNL8IDeKwv5rL1kInq/W6kmFA2IsfZVy7EU7xvBcW8Ke+DrhEHNGBEaLIdgIQhyDQ ejiD6qKzjoB3p6YTtxFAFwcMAOCzVZsoYEGps1LuxD1eUAilEB71Tkq5E++ww1OKEbC+bUAoUBEM Q20C5tVAmAC8yf4TZ/gBFQKeeDv2EAIcbeA/fF18C38TwJZnmmD7qQAAACV0RVh0ZGF0ZTpjcmVh dGUAMjAyMi0wNC0yOVQxMjozOTozMSswMDowMHK/KSgAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjIt MDQtMjlUMTI6Mzk6MzErMDA6MDAD4pGUAAAAAElFTkSuQmCC X-Now-Playing: Colleen's _A Flame My Love, A Frequency_: "One Warm Spark" Date: Fri, 29 Apr 2022 14:41:49 +0200 In-Reply-To: <83tuac9j0l.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 29 Apr 2022 15:22:18 +0300") Message-ID: <87tuacdpte.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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 @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> I thought I remembered there was a way to say to font-lock "ignore this >> bit of the buffer", but I can't find it now. Do I misremember? > > Make the text invisible? Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: dgutov@yandex.ru, 44983@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> I thought I remembered there was a way to say to font-lock "ignore this >> bit of the buffer", but I can't find it now. Do I misremember? > > Make the text invisible? The text is covered by a display property, which should be much the same thing. > If that doesn't help either, I suggest to profile the code, because it > could be the slow display is due to something else. Hm, yes... even if I disable font-lock-mode, it's still slow. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 09:08:19 2022 Received: (at 44983) by debbugs.gnu.org; 29 Apr 2022 13:08:19 +0000 Received: from localhost ([127.0.0.1]:51218 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkQM6-0000mr-T3 for submit@debbugs.gnu.org; Fri, 29 Apr 2022 09:08:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48034) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkQM5-0000ma-1U for 44983@debbugs.gnu.org; Fri, 29 Apr 2022 09:08:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48142) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkQLz-0000zj-Cq; Fri, 29 Apr 2022 09:08:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=hTzAYYuJ9JPzzHVCZ3hAj/bAe0NS9TvrKkzhMURXBxg=; b=k65RAdyA/lai y5lPvMsEOZ+f4+U0ZlzZDYwoNy8LSx6RUjBNWT2nxTkxVcOUKdZkSuos8AFqii03Tt4TXrNui55lE KbVx8qnn4DElHab6W7caKsndeLWefX8Ad2UekfXXktnXj7l8OtJQfhFAMW2rijWw0X2Wmkpurk7XI 6jWHam3GCRSvOhvJzQU+lqFZeiTO1gnUENITA0AJmxwCo6L0PyShZRPOz6sCDnMpZz9qyNRt40KKO OaQe66eipAZT466gxt4y+mE/5bKnhuEz2sfkuZQWfeo5GjDQy0ZqMxaGA38Euu1oTjJomz7uZJzID jzFxgDbwkEFJA3bZQpTowQ==; Received: from [87.69.77.57] (port=2267 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkQLy-0001dl-N6; Fri, 29 Apr 2022 09:08:11 -0400 Date: Fri, 29 Apr 2022 16:08:08 +0300 Message-Id: <83sfpw9gw7.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87tuacdpte.fsf@gnus.org> (message from Lars Ingebrigtsen on Fri, 29 Apr 2022 14:41:49 +0200) Subject: Re: bug#44983: Truncate long lines of grep output References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <87tuacf79e.fsf@gnus.org> <83tuac9j0l.fsf@gnu.org> <87tuacdpte.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: dgutov@yandex.ru, 44983@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: juri@linkov.net, 44983@debbugs.gnu.org, dgutov@yandex.ru > Date: Fri, 29 Apr 2022 14:41:49 +0200 > > Eli Zaretskii writes: > > >> I thought I remembered there was a way to say to font-lock "ignore this > >> bit of the buffer", but I can't find it now. Do I misremember? > > > > Make the text invisible? > > The text is covered by a display property, which should be much the same > thing. Not really, it isn't. The effect on the glass is the same, but the effect on the display code is different. > > If that doesn't help either, I suggest to profile the code, because it > > could be the slow display is due to something else. > > Hm, yes... even if I disable font-lock-mode, it's still slow. Then I think a profile should tell something interesting. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 12:02:30 2022 Received: (at 44983) by debbugs.gnu.org; 29 Apr 2022 16:02:30 +0000 Received: from localhost ([127.0.0.1]:55168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkT4g-0004aH-95 for submit@debbugs.gnu.org; Fri, 29 Apr 2022 12:02:30 -0400 Received: from mail-ed1-f49.google.com ([209.85.208.49]:42804) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkT4d-0004a3-TK for 44983@debbugs.gnu.org; Fri, 29 Apr 2022 12:02:28 -0400 Received: by mail-ed1-f49.google.com with SMTP id z19so9563834edx.9 for <44983@debbugs.gnu.org>; Fri, 29 Apr 2022 09:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=3qmh62eoxG5AphfGeKD4MOZRguVMi/UmIUsJLrItpv4=; b=eMnhc0iiqVmXmgnX3ibb+5EvqgtXhD/zp1lYPtCI/uiTosQ7Gf6XPYQSHr7gjB24O8 cCjFiWa/dKUOOaPREuNjVQFBFgtH2wSkd6Sk4kcfuQAXgG9vBiYC2VwYQxPxi3hl58ZC o/UkVIn8OpWxbHBm+VdIOD23u2jU8Wvmr/4PiwD8d6dD55fOO7sRj/AFZWzG7CEx9cGk QN4Vico1nRgi2Zrt8mra2hiTX3iMDCeUAZLbHm27tfeXxy98q8wq3PRlCUof23vFw9Fj Ue7mE8LAzLG+gojOviPBGlJto7immjzVui7iXz08Y9CGoXJu29vzuoILQUj+EssFX0Ic SAtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=3qmh62eoxG5AphfGeKD4MOZRguVMi/UmIUsJLrItpv4=; b=ZtZT/Miaqltyp81DVxSSkMKTBevB2pC+KEcFnipzOEKCftLr26rhn+/jSX7t519yg/ m4MTuansa5vyVrIlCh3HlRYydWMkaxLZEf7RD8sYdbbCfgsL0QQWrQnv80GGTQ88WWUY gGcmf2PgVHZifTnYrqGqKkEjUm3PDwl0CQXAvu73dGH1I3nMEmk4FOscJq5IpDs4Q4sO Hz6atFtfLG7oStv0rFwL7K0Vcj3z9BfmPQDj/Xugf7jMvefFug5QJR4+KTatEygQI/Es cUECzUqj/H+E/ZCrjK/qLwJizwLCB3/Lb27wQTOGvwBo9A7MLvu4rkYBdhp77ootiJ4a 6vuw== X-Gm-Message-State: AOAM530wLwikKWSgC6/qZ7BGOaH6lQmICXKxeGWwbYjoKljGBpQ0SLrr 5qU+c+iXsIJYCWbx64wjFnI= X-Google-Smtp-Source: ABdhPJxJJ8WlbIOpHXhS4wjMYwnoTCmWmDFUGYN7XlmzhGjI0MWnICIr1DkWxjKZYQPgoHjSxcRSAw== X-Received: by 2002:a05:6402:5201:b0:426:124:a40b with SMTP id s1-20020a056402520100b004260124a40bmr17639673edd.198.1651248142033; Fri, 29 Apr 2022 09:02:22 -0700 (PDT) Received: from [192.168.236.48] ([173.237.64.48]) by smtp.googlemail.com with ESMTPSA id jl26-20020a17090775da00b006f3ef214dbdsm749237ejc.35.2022.04.29.09.02.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 09:02:21 -0700 (PDT) Message-ID: Date: Fri, 29 Apr 2022 19:02:19 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: bug#44983: Truncate long lines of grep output Content-Language: en-US To: Lars Ingebrigtsen , Juri Linkov References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <87tuacf79e.fsf@gnus.org> From: Dmitry Gutov In-Reply-To: <87tuacf79e.fsf@gnus.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 44983 Cc: Eli Zaretskii , 44983@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 29.04.2022 14:39, Lars Ingebrigtsen wrote: > Juri Linkov writes: > >> 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? > I now have a rough patch that does this, but the problem is that even if > I splat a "..." display over the text, font-lock seems to insist on > going over the data anyway, so the display is still dog slow. > > I thought I remembered there was a way to say to font-lock "ignore this > bit of the buffer", but I can't find it now. Do I misremember? FWIW, this is more or less solved for Xref output buffers these days. And the solution is based on the 'invisible' property. See bug#46859. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 13:22:44 2022 Received: (at 44983) by debbugs.gnu.org; 29 Apr 2022 17:22:45 +0000 Received: from localhost ([127.0.0.1]:55278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkUKK-0000Ua-Pk for submit@debbugs.gnu.org; Fri, 29 Apr 2022 13:22:44 -0400 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:43819) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkUKJ-0000UA-76 for 44983@debbugs.gnu.org; Fri, 29 Apr 2022 13:22:43 -0400 Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id 73727FF805; Fri, 29 Apr 2022 17:22:35 +0000 (UTC) From: Juri Linkov To: Lars Ingebrigtsen Subject: Re: bug#44983: Truncate long lines of grep output Organization: LINKOV.NET References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <87tuacf79e.fsf@gnus.org> Date: Fri, 29 Apr 2022 20:15:00 +0300 In-Reply-To: <87tuacf79e.fsf@gnus.org> (Lars Ingebrigtsen's message of "Fri, 29 Apr 2022 13:39:41 +0200") Message-ID: <86r15fvn5j.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.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: Eli Zaretskii , 44983@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> 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? > > I now have a rough patch that does this, but the problem is that even if > I splat a "..." display over the text, font-lock seems to insist on > going over the data anyway, so the display is still dog slow. > > I thought I remembered there was a way to say to font-lock "ignore this > bit of the buffer", but I can't find it now. Do I misremember? I don't remember such font-lock text property, but now I have no problems when long lines are hidden initially with: ``` (add-hook 'xref-after-update-hook (lambda () (setq-local outline-regexp (if (eq xref-file-name-display 'abs) "/" "[^ 0-9]") outline-default-state 1 outline-default-rules '(subtree-has-long-lines) outline-default-long-line 1000) (outline-minor-mode +1))) ``` From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 20:27:21 2022 Received: (at 44983) by debbugs.gnu.org; 30 Apr 2022 00:27:21 +0000 Received: from localhost ([127.0.0.1]:55639 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkaxF-00041y-2Z for submit@debbugs.gnu.org; Fri, 29 Apr 2022 20:27:21 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]:41690) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkaxD-00041l-Ka for 44983@debbugs.gnu.org; Fri, 29 Apr 2022 20:27:19 -0400 Received: by mail-wr1-f46.google.com with SMTP id c11so2850450wrn.8 for <44983@debbugs.gnu.org>; Fri, 29 Apr 2022 17:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=Mav066NCDuxx+fsZEUcOyfBTSUyhECbCXZVB8WLMUwg=; b=Lah327tL87RSFDrmEasLrGxMcRUCJO+4cnJrtPdX8DyB5I0oSMbX2wYotMf4LzEqRa XIuFvF/6yi4ivKHQjAE1ifP4QCv0HQSHgmaKgN4uhtCRc1sJZq24Vj2G0Z5LsM6NUTwT 1ZO2poZ4xj4WKX7BKTQBTK4dtCyJ8JPey+/NqusQPIp4NpYQVFEKQ9FekI+jQqx54k/k SSm1Q9I5lulisAsqoBOrUdEaowdblSAVYWs8rIcVii4Le3qPILqUBH0rmeLu9IQCg6DH tibJQfT96r3JtnPO8dNAhMJNwWeTgtxKXkG2GLj4Rx2Y3vtvtWQCWGe9SH5iYvzWAoL8 4ldA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=Mav066NCDuxx+fsZEUcOyfBTSUyhECbCXZVB8WLMUwg=; b=sTQEDMCcaTtLVJQgwoPS3H7uRtjmosmhbKrCmZiE89U0dU5whCQYZIxsL/hox4fIE1 jklDAEoyftbq9JC9F3qcovRsiRUWTBVOCq7a+3DZGcZXKkoJLpDjPjKm4zkmMMK35lmn BiTfzIBF4DOKglnzkIvohKAa8kl7zalxL8M/al7a5h/wIpi45WJiMJ3kElMMITStiorw 0tqxkdkgccEj+VmJmxfwrPArTCqyje/kMSDPty+2pORHylNviJyNSQsDQAZWJO81T0AS eWVX0eZ3UhkNFXI20uj95xT5RHYxj7LWatA/+A8qPuIMWW9BvPLgIzNvZPxLKCDubKFq jMuw== X-Gm-Message-State: AOAM5314InYrpC6T6Kre4TDuyTTQZ6LJr2Z1+Xyc5QWkMhpTeKaoJUVx grPCoZ/uOhaNIFq9YmI8BRc= X-Google-Smtp-Source: ABdhPJw9Unapj2cdv3jnHWnKbPM+B6IOQ0eiacCITgit/SCFYuRDT/IrIyyatrdnSGSNOuhbPsEqfA== X-Received: by 2002:a5d:4008:0:b0:20a:ea86:e101 with SMTP id n8-20020a5d4008000000b0020aea86e101mr1180015wrp.141.1651278433737; Fri, 29 Apr 2022 17:27:13 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id r15-20020a7bc08f000000b003942a244ecasm483092wmh.15.2022.04.29.17.27.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 17:27:13 -0700 (PDT) Message-ID: Date: Sat, 30 Apr 2022 03:27:11 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: bug#44983: Truncate long lines of grep output Content-Language: en-US To: Juri Linkov , Lars Ingebrigtsen References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <87tuacf79e.fsf@gnus.org> <86r15fvn5j.fsf@mail.linkov.net> From: Dmitry Gutov In-Reply-To: <86r15fvn5j.fsf@mail.linkov.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 44983 Cc: 44983@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 29.04.2022 20:15, Juri Linkov wrote: > I don't remember such font-lock text property, but now I have no problems > when long lines are hidden initially with: When you apply this, do you disable the existing mechanism for dealing with long lines? By setting 'xref-truncation-width' to nil. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 05:24:42 2022 Received: (at 44983) by debbugs.gnu.org; 30 Apr 2022 09:24:42 +0000 Received: from localhost ([127.0.0.1]:55865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkjLF-00032j-Rs for submit@debbugs.gnu.org; Sat, 30 Apr 2022 05:24:42 -0400 Received: from quimby.gnus.org ([95.216.78.240]:46586) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkjLE-00032S-1F for 44983@debbugs.gnu.org; Sat, 30 Apr 2022 05:24:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=GE1fwtlq8cTnEpRLZGKERgARCSK/5mHMb6yGi5GT6Eg=; b=gbuppBl6zOXO6Qcxw6k3AxqCCm eFfLgYB1TtRhVzf1Atvykb3T4X8NNGAoj5GBU1zTl1TRaAFZikW+BRjHKN5pxeNH+b2A9oYdghXIM 7I53JPKWH9J6p7kbbHvq6Osreea3CvDLopGMQdO2yChoJ5Nu3bv56Gr+0C0bA05XFUVs=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkjL5-00061h-7D; Sat, 30 Apr 2022 11:24:33 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#44983: Truncate long lines of grep output References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <87tuacf79e.fsf@gnus.org> <83tuac9j0l.fsf@gnu.org> <87tuacdpte.fsf@gnus.org> <83sfpw9gw7.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAKlBMVEWCrLqi3PCr6/yW zuWNvM53pMwWIXQjM4Q1S5FUcZhxlaY3Q1lRZWr///+A617ZAAAAAWJLR0QN9rRh9QAAAAd0SU1F B+YEHgkEMXPsKuIAAAGiSURBVDjLnZQ/T8JAGMYrm8jSDg7E5U6MhDiJEhUGgzpAmDB+AJcWvwDF 3cChi5CYADoILFJucHDhz4CEheM+lL2WlLu2JsqT5u3w63PP+14vJ23IXimyvCuloa/AbwCuAQLW 64aVvTxb/JoHQGN1/9YsUTXNgxKrUQYSap0HBQe4HJoDoE+GDeDfgP5vB4qbOnlgNa7woKgy2VWY o4fum82PAWq0EBLmmNGeVMv1KCWE8gCORtnRdHYwIMkVYFlgQi9IOoQpNh2HPHh8rZoZd9Wn6qjR 8e9KE7qCzavT4Tzewse495LnwWcod0naXzQzpmTKLzVckMhzrd8KYjoRBuxSPKFBgsPB1EwIRwgV SqhQQaiCBEe5qOvmo2m6VhRA4AgbWSztZt7DmF8KDun327yf7GNjnFtObnUN6HjaGoZSCxxc7Aig buBpd2szho3zMwGU1aK9K6stsYHZp6MOD0rQrSXQFC9Q1gO6FwRcjkhV8Qfbzq91gYQIWAawGo8V hONjnmRFti2yEA6tKwQyH1iFA/GKgdanJgDe24eBtuyvH1Kw/DAZoN4eAAAAJXRFWHRkYXRlOmNy ZWF0ZQAyMDIyLTA0LTMwVDA5OjA0OjQ5KzAwOjAwB5IYrwAAACV0RVh0ZGF0ZTptb2RpZnkAMjAy Mi0wNC0zMFQwOTowNDo0OSswMDowMHbPoBMAAAAASUVORK5CYII= X-Now-Playing: New Order's _Movement: Remaster (1)_: "The Him" Date: Sat, 30 Apr 2022 11:24:29 +0200 In-Reply-To: <83sfpw9gw7.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 29 Apr 2022 16:08:08 +0300") Message-ID: <87levm6i0i.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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 @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> > If that doesn't help either, I suggest to profile the code, because it >> > could be the slow display is due to something else. >> >> Hm, yes... even if I disable font-lock-mode, it's still slow. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: dgutov@yandex.ru, 44983@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> > If that doesn't help either, I suggest to profile the code, because it >> > could be the slow display is due to something else. >> >> Hm, yes... even if I disable font-lock-mode, it's still slow. > > Then I think a profile should tell something interesting. Turns out to be font lock anyway: 9152 88% - redisplay_internal (C function) 9148 88% - jit-lock-function 9148 88% - jit-lock-fontify-now 9148 88% - jit-lock--run-functions 9144 87% - run-hook-wrapped 9144 87% - # 9144 87% - font-lock-fontify-region 9144 87% - font-lock-default-fontify-region 9144 87% font-lock-fontify-keywords-region Apparently disabling font-lock-mode in the *grep* buffer wasn't sufficient to make it go away for some reason or other. Disabling global-font-lock-mode makes the problem go away. And using invisible text instead of a display property makes no difference -- font-lock seems to really want to do font locking on ever-growing lines that are inserted into the buffer by the process. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 05:36:54 2022 Received: (at 44983) by debbugs.gnu.org; 30 Apr 2022 09:36:54 +0000 Received: from localhost ([127.0.0.1]:55873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkjX4-0003NR-80 for submit@debbugs.gnu.org; Sat, 30 Apr 2022 05:36:54 -0400 Received: from quimby.gnus.org ([95.216.78.240]:46642) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkjX2-0003ND-5P for 44983@debbugs.gnu.org; Sat, 30 Apr 2022 05:36:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=hdbp/Ut77RTW2C85hSusZHeYQA+Sn5foNCPXtZ0jPdY=; b=N8RratKCvXl0WYCshOMtivzvt0 X8sCkPqENmI5jM4ho5O24rLIzGHmbqT5/K/a1lCh+Fusd0ETDNgDmUAgMECQYBt6m5KVe03Bx4r2L 1a3Qhe7X+zFZu0HgiF/H7Kx4PVcmsOFOwQBeSnRPF/d3W2g89UCeJU4LHGOjgdP+zJvk=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkjWs-00067Q-7A; Sat, 30 Apr 2022 11:36:44 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#44983: Truncate long lines of grep output References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <87tuacf79e.fsf@gnus.org> <83tuac9j0l.fsf@gnu.org> <87tuacdpte.fsf@gnus.org> <83sfpw9gw7.fsf@gnu.org> <87levm6i0i.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAALVBMVEXm3Lvr4L3Szrnl 3cHt5svX2satrKC5wa+cj3lgZF7NqplGSEghHBWGZmb///+bgJr+AAAAAWJLR0QOb70wTwAAAAd0 SU1FB+YEHgkfFebZBakAAAGZSURBVDjLlZTPToNAEMa36gNI8Aka0pieMJB6F+y/pBdj+wBNumjP BuwLGHvw2ojUS2+S9Io22z4BcNf4Mi4wyy5CE50DJPPbb+bb2c0iVIhj+Nfrybcm1SQILQ0VoYMk LyeJM02IDEgyLDRNIycJkLNkHkamQYj+DCFvaqamHaK0lLieKvRMUZO1IjDBGO2hl0HWo5hPuyel fucZkDRucjjUoZaag5ZltW2M72CRyvJmBz+6rvussPZIBkv9uRdF0UaBuioHb6/bKNwdVYDdNiQf TMFLDRbziHgvCtsjksH84P0KP30zYHDQDYZXt2SqsE1y8HmzjGL/ugQ6p5uIxLgMLkde6MU2L8VG fjFaPpDY5oqTXBHMvMApg05jTLygQtGb3IckwKwH30dvPKMT8cv76E3sL5cDQUEsf10A4Le7nfrr RQXo+83masUAHSI/WmxhDK4MAbQosG0AunAZzi3HdhwBsPvWthoYOzBd8WgLYQhHWwwKpCpFalev luwDRm7376C2F+j/Bul7oZcBBLwhavZ60JH8AKC8MrWmlyDIAAAAJXRFWHRkYXRlOmNyZWF0ZQAy MDIyLTA0LTMwVDA5OjMxOjIxKzAwOjAwjdnyCgAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wNC0z MFQwOTozMToyMSswMDowMPyESrYAAAAASUVORK5CYII= X-Now-Playing: New Order's _Everything's Gone Green_: "Everything's Gone Green" Date: Sat, 30 Apr 2022 11:36:37 +0200 In-Reply-To: <87levm6i0i.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sat, 30 Apr 2022 11:24:29 +0200") Message-ID: <87fslu6hga.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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 @@CONTACT_ADDRESS@@ for details. Content preview: I've instrumented some functions to try to see what's going on. I've set things up so that grep lines that are longer than 200 chars are invisible starting at the 200th character. While the grep is running, `jit-lock-fontify-now' is called repeatedly and takes lon [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: dgutov@yandex.ru, 44983@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) I've instrumented some functions to try to see what's going on. I've set things up so that grep lines that are longer than 200 chars are invisible starting at the 200th character. While the grep is running, `jit-lock-fontify-now' is called repeatedly and takes longer time each time, but with the same region: Fontifying *grep* 392-1892 Fontifying *grep* 392-1892 Fontifying *grep* 392-1892 392 is the start of the line, and 1892 is in the invisible portion of the line. That's 1500 characters, so it should be fast -- but perhaps it's extending it to the end of the line anyway? But before I start trying to debug that, I'm wondering: Why is `jit-lock-fontify-now' called at all here? There have been no display changes -- the text was inserted, but as invisible text, so no font locking should be necessary. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 05:40:50 2022 Received: (at 44983) by debbugs.gnu.org; 30 Apr 2022 09:40:50 +0000 Received: from localhost ([127.0.0.1]:55883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkjas-0003TN-3a for submit@debbugs.gnu.org; Sat, 30 Apr 2022 05:40:50 -0400 Received: from quimby.gnus.org ([95.216.78.240]:46686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkjaq-0003T8-E2 for 44983@debbugs.gnu.org; Sat, 30 Apr 2022 05:40:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=MNNkuAT8LtNF89HQfogQli4usb9gG3ZUMCXb8KN96uE=; b=TzaGcgqdAQ5zFfHaU0F3sEMS/G yEHAnDfYLVBbZSYhVEAInngpjO4ef6AxLssisZlA9sTrjGYaicrdTOyp2bGWjZSbBPusjqpd3RBX0 8aS197MkvJJZkFQox6cy3HFGE9EqbjupgOxt/ofxZgMsrAw54AIhJvX9Ubb0nTeZvvY0=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkjah-00069m-El; Sat, 30 Apr 2022 11:40:41 +0200 From: Lars Ingebrigtsen To: Dmitry Gutov Subject: Re: bug#44983: Truncate long lines of grep output References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <87tuacf79e.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAALVBMVEXm3Lvr4L3Szrnl 3cHt5svX2satrKC5wa+cj3lgZF7NqplGSEghHBWGZmb///+bgJr+AAAAAWJLR0QOb70wTwAAAAd0 SU1FB+YEHgkfFebZBakAAAGZSURBVDjLlZTPToNAEMa36gNI8Aka0pieMJB6F+y/pBdj+wBNumjP BuwLGHvw2ojUS2+S9Io22z4BcNf4Mi4wyy5CE50DJPPbb+bb2c0iVIhj+Nfrybcm1SQILQ0VoYMk LyeJM02IDEgyLDRNIycJkLNkHkamQYj+DCFvaqamHaK0lLieKvRMUZO1IjDBGO2hl0HWo5hPuyel fucZkDRucjjUoZaag5ZltW2M72CRyvJmBz+6rvussPZIBkv9uRdF0UaBuioHb6/bKNwdVYDdNiQf TMFLDRbziHgvCtsjksH84P0KP30zYHDQDYZXt2SqsE1y8HmzjGL/ugQ6p5uIxLgMLkde6MU2L8VG fjFaPpDY5oqTXBHMvMApg05jTLygQtGb3IckwKwH30dvPKMT8cv76E3sL5cDQUEsf10A4Le7nfrr RQXo+83masUAHSI/WmxhDK4MAbQosG0AunAZzi3HdhwBsPvWthoYOzBd8WgLYQhHWwwKpCpFalev luwDRm7376C2F+j/Bul7oZcBBLwhavZ60JH8AKC8MrWmlyDIAAAAJXRFWHRkYXRlOmNyZWF0ZQAy MDIyLTA0LTMwVDA5OjMxOjIxKzAwOjAwjdnyCgAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wNC0z MFQwOTozMToyMSswMDowMPyESrYAAAAASUVORK5CYII= X-Now-Playing: New Order's _Everything's Gone Green_: "Procession" Date: Sat, 30 Apr 2022 11:40:38 +0200 In-Reply-To: (Dmitry Gutov's message of "Fri, 29 Apr 2022 19:02:19 +0300") Message-ID: <87bkwi6h9l.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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 @@CONTACT_ADDRESS@@ for details. Content preview: Dmitry Gutov writes: > FWIW, this is more or less solved for Xref output buffers these > days. And the solution is based on the 'invisible' property. Skimming the code there, it seems like xref just gets a list that it inserts into the buffer, and then applies the invisibility spec to the long lines? That's a bit different from what compilation-mod [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: Eli Zaretskii , 44983@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Dmitry Gutov writes: > FWIW, this is more or less solved for Xref output buffers these > days. And the solution is based on the 'invisible' property. Skimming the code there, it seems like xref just gets a list that it inserts into the buffer, and then applies the invisibility spec to the long lines? That's a bit different from what compilation-mode/grep is doing, where a process inserts text. I.e., invisible text, in general, works fine, but there's some bad interaction between processes/invisible/font-lock somewhere. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 05:56:22 2022 Received: (at 44983) by debbugs.gnu.org; 30 Apr 2022 09:56:22 +0000 Received: from localhost ([127.0.0.1]:55893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkjpt-0003sT-ST for submit@debbugs.gnu.org; Sat, 30 Apr 2022 05:56:22 -0400 Received: from quimby.gnus.org ([95.216.78.240]:46790) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkjps-0003sH-VY for 44983@debbugs.gnu.org; Sat, 30 Apr 2022 05:56:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=3wHIzeCpkpAJDgcW5H506G8FbKB+at0SU8WVbshpWKw=; b=tv4zU5Ybw2nbW9frav9jo8CI51 2aPbWqV5wKFXAb4/+fDyCUsRuRmuT/lyOK/lJ+Qpj8a1piK7hxeBaqSIVyD3l3xrE912u6TD+5VEy pHd/dBHVxO/+4s6FrtMvKCPSwfXewrlxjkx5mj4NpQdbP4WZpl1Hq/LvfPczx0CDvzfs=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkjpj-0006Jr-KA; Sat, 30 Apr 2022 11:56:14 +0200 From: Lars Ingebrigtsen To: Dmitry Gutov Subject: Re: bug#44983: Truncate long lines of grep output References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <87tuacf79e.fsf@gnus.org> <87bkwi6h9l.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAALVBMVEXm3Lvr4L3Szrnl 3cHt5svX2satrKC5wa+cj3lgZF7NqplGSEghHBWGZmb///+bgJr+AAAAAWJLR0QOb70wTwAAAAd0 SU1FB+YEHgkfFebZBakAAAGZSURBVDjLlZTPToNAEMa36gNI8Aka0pieMJB6F+y/pBdj+wBNumjP BuwLGHvw2ojUS2+S9Io22z4BcNf4Mi4wyy5CE50DJPPbb+bb2c0iVIhj+Nfrybcm1SQILQ0VoYMk LyeJM02IDEgyLDRNIycJkLNkHkamQYj+DCFvaqamHaK0lLieKvRMUZO1IjDBGO2hl0HWo5hPuyel fucZkDRucjjUoZaag5ZltW2M72CRyvJmBz+6rvussPZIBkv9uRdF0UaBuioHb6/bKNwdVYDdNiQf TMFLDRbziHgvCtsjksH84P0KP30zYHDQDYZXt2SqsE1y8HmzjGL/ugQ6p5uIxLgMLkde6MU2L8VG fjFaPpDY5oqTXBHMvMApg05jTLygQtGb3IckwKwH30dvPKMT8cv76E3sL5cDQUEsf10A4Le7nfrr RQXo+83masUAHSI/WmxhDK4MAbQosG0AunAZzi3HdhwBsPvWthoYOzBd8WgLYQhHWwwKpCpFalev luwDRm7376C2F+j/Bul7oZcBBLwhavZ60JH8AKC8MrWmlyDIAAAAJXRFWHRkYXRlOmNyZWF0ZQAy MDIyLTA0LTMwVDA5OjMxOjIxKzAwOjAwjdnyCgAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wNC0z MFQwOTozMToyMSswMDowMPyESrYAAAAASUVORK5CYII= X-Now-Playing: New Order's _Everything's Gone Green_: "Temptation" Date: Sat, 30 Apr 2022 11:56:11 +0200 In-Reply-To: <87bkwi6h9l.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sat, 30 Apr 2022 11:40:38 +0200") Message-ID: <874k2a6gjo.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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 @@CONTACT_ADDRESS@@ for details. Content preview: This is the cause of the problem: (defvar grep-mode-font-lock-keywords '(;; Command output lines. (": \\(.+\\): \\(?:Permission denied\\|No such \\(?:file or directory\\|device or address\\)\\)$" 1 grep-error-face) Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: 44983@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is the cause of the problem: (defvar grep-mode-font-lock-keywords '(;; Command output lines. (": \\(.+\\): \\(?:Permission denied\\|No such \\(?:file or directory\\|device or address\\)\\)$" 1 grep-error-face) With that removed, everything's nice and fast. Limiting that .+ to 200 characters also makes things fast: diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el index 17905dec2e..7620536b4b 100644 --- a/lisp/progmodes/grep.el +++ b/lisp/progmodes/grep.el @@ -456,7 +456,7 @@ grep-find-abbreviate-properties (defvar grep-mode-font-lock-keywords '(;; Command output lines. - (": \\(.+\\): \\(?:Permission denied\\|No such \\(?:file or directory\\|device or address\\)\\)$" + (": \\(.\\{,200\\}\\): \\(?:Permission denied\\|No such \\(?:file or directory\\|device or address\\)\\)$" 1 grep-error-face) ;; remove match from grep-regexp-alist before fontifying ("^Grep[/a-zA-Z]* started.*" But I guess the real question here is still why we're font-locking invisible text. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 06:09:16 2022 Received: (at 44983) by debbugs.gnu.org; 30 Apr 2022 10:09:16 +0000 Received: from localhost ([127.0.0.1]:55915 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkk2O-0004DZ-7G for submit@debbugs.gnu.org; Sat, 30 Apr 2022 06:09:16 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36552) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkk2M-0004DM-Lp for 44983@debbugs.gnu.org; Sat, 30 Apr 2022 06:09:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42160) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkk2H-0008HA-0M; Sat, 30 Apr 2022 06:09:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=kr3Uwb+YlPxAkoliKThQbLG3ZVGT+N5li5L3Lt6zH6o=; b=CIVhC8xXBZom qWFu1dls0FsMtfbpdSQtqiG7AE1VsCa7tvt2+/aNrkuontZMhMaZz97MYFqD8UK2Udbclx1Ln9yuY hM8SOoZEjn71hFvLnI/ap5AgvDADnpoOZIcZnq+vyI8kXXKflP4ZNDStEH9fYimLvRdbBnNne6OGS NDPs1EssaezrrdR45W/LRGdC9um/NPDEaY5rXKf98sxlRRUmTIChQwxowHoycgdg+qTkyYv7JbdxR rtU88UHqbGRcrkBob2w3O0HLCn98ntJ2NUq7M4EG4V2PsZGqOROjo0DhTzmBCkCot+SESyk5ncKop Cfs/LslxbN7bh6fwxtPPnw==; Received: from [87.69.77.57] (port=4148 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkk2G-0004X9-EV; Sat, 30 Apr 2022 06:09:08 -0400 Date: Sat, 30 Apr 2022 13:09:12 +0300 Message-Id: <83o80i992v.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <874k2a6gjo.fsf@gnus.org> (message from Lars Ingebrigtsen on Sat, 30 Apr 2022 11:56:11 +0200) Subject: Re: bug#44983: Truncate long lines of grep output References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <87tuacf79e.fsf@gnus.org> <87bkwi6h9l.fsf@gnus.org> <874k2a6gjo.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: juri@linkov.net, 44983@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Date: Sat, 30 Apr 2022 11:56:11 +0200 > Cc: 44983@debbugs.gnu.org, Juri Linkov > > But I guess the real question here is still why we're font-locking > invisible text. We are not. The display engine will never call jit-lock on a region that starts in invisible text. But a region that starts in visible text can end in invisible text, and font-lock doesn't pay attention to invisibility spec, AFAIR, it just looks at the buffer text disregarding everything else. For me, the more important question is: why the problem didn't disappear when you turned off font-lock-mode in the offending buffer. And I think I know why: you need to turn off jit-lock-mode as well. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 06:15:14 2022 Received: (at 44983) by debbugs.gnu.org; 30 Apr 2022 10:15:14 +0000 Received: from localhost ([127.0.0.1]:55921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkk89-0004MX-Tk for submit@debbugs.gnu.org; Sat, 30 Apr 2022 06:15:14 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36900) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkk88-0004MH-9w for 44983@debbugs.gnu.org; Sat, 30 Apr 2022 06:15:12 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42230) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkk7z-0000Wb-R2; Sat, 30 Apr 2022 06:15:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=COIaC8McigieTTKqvX2ICWuIBZRnPIjCAPl+yO7ck3s=; b=FMRO3OxPaJQW a5uFmKDqGVe6vrpeO+FBQn/SCdC6WW/fErP53x2cZ1Du3nakQV6G5dUOZxHiiuwssNu9iolpU03Ra nUWpTp9bXzYoaQWyiNJjE49DAZC6iu7iED/4x331AZgHoTFFsmKyfo+FboFMj8VkBP/qdEH38pG5C K3M5BH5TwzfMHlR53kBeaX9uFonF/224Ini75s+WXsomHEvVbBqgSNYii5ZoLMFOnVnorh2JOX8x0 s1QyCcv8mkShIw0+tadDgMJNUrzZJIIMPifpPZ6pRyQ9EmxdynmhooFWXlpdAdFugSccwE6n9C6vT vz7i5lrTwt3HG/rEXunjew==; Received: from [87.69.77.57] (port=4510 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkk7z-00052h-9D; Sat, 30 Apr 2022 06:15:03 -0400 Date: Sat, 30 Apr 2022 13:15:07 +0300 Message-Id: <83mtg298t0.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87fslu6hga.fsf@gnus.org> (message from Lars Ingebrigtsen on Sat, 30 Apr 2022 11:36:37 +0200) Subject: Re: bug#44983: Truncate long lines of grep output References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <87tuacf79e.fsf@gnus.org> <83tuac9j0l.fsf@gnu.org> <87tuacdpte.fsf@gnus.org> <83sfpw9gw7.fsf@gnu.org> <87levm6i0i.fsf@gnus.org> <87fslu6hga.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: dgutov@yandex.ru, 44983@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: juri@linkov.net, 44983@debbugs.gnu.org, dgutov@yandex.ru > Date: Sat, 30 Apr 2022 11:36:37 +0200 > > But before I start trying to debug that, I'm wondering: Why is > `jit-lock-fontify-now' called at all here? There have been no display > changes -- the text was inserted, but as invisible text, so no font > locking should be necessary. Are you saying that buffer position 392 was in invisible text? If so, jit-lock-fontify-now should not have been called. But if position 392 is visible, then what you see is expected: the buffer text has changed, and therefore redisplay will arrange to redisplay the buffer. Part of redisplaying the buffer is making sure the text that might wind up on display is fontified. Which part will actually be on display can only be known _after_ the text is fontified (because fontification can change faces, and thus affect what's visible in the window). So we always fontify the 500-character chunk, per jit-lock.el's defaults. Did I answer your question? From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 07:00:06 2022 Received: (at 44983) by debbugs.gnu.org; 30 Apr 2022 11:00:06 +0000 Received: from localhost ([127.0.0.1]:55953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkkpZ-0005dL-PL for submit@debbugs.gnu.org; Sat, 30 Apr 2022 07:00:05 -0400 Received: from quimby.gnus.org ([95.216.78.240]:47054) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkkpW-0005cD-FL for 44983@debbugs.gnu.org; Sat, 30 Apr 2022 07:00:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=qsTBQl0wZqJwJjC4eV6YledFIYWpPYNZRTTVf97xFTU=; b=h9USBv0kLX3yZw16K3QcNXB9HE HpX6OwkZFJHXrmmXEUKdydyvXno0ggBtTJjzpBa09JhtZaZEf9ZiginCkjqxezUc/ZHsXm/gTaKLm FiN8xI7N/XZ9MDfiH8ydjCsSDR64VBlvESd2vcDR0FkHTPO2CdgTfkWylxp6U1ZUGiaI=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkkpN-00070H-A8; Sat, 30 Apr 2022 12:59:55 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#44983: Truncate long lines of grep output References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <87tuacf79e.fsf@gnus.org> <87bkwi6h9l.fsf@gnus.org> <874k2a6gjo.fsf@gnus.org> <83o80i992v.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEX8+/uopaMnJCTS 0M6Cfnz////M28vfAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+YEHgo5F8lPWfgAAAFqSURBVDjLdZOB kYQgDEXjYQGgFLDEFABiAQtn/zVdQGTB5ZidWSeP8JNPAChrwc+y4NUdh9gALYW+40cTR4dBjxLQ CjxLXLRxlLqCqQOR1A3mDpwU7qp++qMO/C1gf4J1mHGShDGobT/A6v8BBx0wKpeWuBQR3TlC4Zje KWyX7iAGcwJTxMei/VwsaPxaNCMB4AD4SdgRME5rCd1OPvdAkuxcBwxfl4lorVZrp0FzMPzjtlIT nd2TFSwLhxUNOCNu2TyhYqcRWPZdJsC6JiNodKRyjoe2jxBJRAzf4EQDZTgcH1YBIW7gUk1Jvu+D pefXNZh9H7w70qXRAcrjZbPGA6TR3lIfq7cdyCORJHwH3HX3pfumD7vmf67LrQ2Ixu75Y2MJJysg f9pYpNZcV9nPPpdXRUJCtWSb4ru+kWTLbeILdlPfZwblojZ+zrEC+ckwzbQTNBpmaQGXpAYjypYp JQfAZIUB2C6r/gB9NXonsqP/TwAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMi0wNC0zMFQxMDo1Nzoy MyswMDowMOV3srkAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDQtMzBUMTA6NTc6MjMrMDA6MDCU KgoFAAAAAElFTkSuQmCC X-Now-Playing: New Order's _Low-Life (1)_: "Sunrise" Date: Sat, 30 Apr 2022 12:59:52 +0200 In-Reply-To: <83o80i992v.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 30 Apr 2022 13:09:12 +0300") Message-ID: <87wnf64z13.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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 @@CONTACT_ADDRESS@@ for details. Content preview: I've now implemented the line-hiding in Emacs 29. Grepping for "Grenadine" in the Emacs tree now takes approx two seconds, while it takes about a minute in Emacs 28 (and Emacs is unusable while it's r [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: juri@linkov.net, 44983@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) I've now implemented the line-hiding in Emacs 29. Grepping for "Grenadine" in the Emacs tree now takes approx two seconds, while it takes about a minute in Emacs 28 (and Emacs is unusable while it's running). -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 07:00:13 2022 Received: (at control) by debbugs.gnu.org; 30 Apr 2022 11:00:13 +0000 Received: from localhost ([127.0.0.1]:55956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkkph-0005en-1U for submit@debbugs.gnu.org; Sat, 30 Apr 2022 07:00:13 -0400 Received: from quimby.gnus.org ([95.216.78.240]:47072) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkkpf-0005dV-Tp for control@debbugs.gnu.org; Sat, 30 Apr 2022 07:00:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=VBdcJKtG7h8bNRlt84aPSJ6dBQVQ/h3/qI8BVxHSCy4=; b=gSA/6/SMZDDmgzcTyrsNJCLIyb nRtzh0Z5O/6NYXMvYjAG7wJF7xA6Xe79ro2CBzYSF3ddR840uaZWP3V0jgpCIWrvH8Yo5Yo3w0PCb q5k9+qFAcXikH13PDeg73VyYmSqvbkxWZeDRVvR/2XCJ2K7PfvoLqAwBmKEKOpIRR/tY=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkkpY-00070X-4L for control@debbugs.gnu.org; Sat, 30 Apr 2022 13:00:05 +0200 Date: Sat, 30 Apr 2022 13:00:03 +0200 Message-Id: <87v8uq4z0s.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #44983 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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 @@CONTACT_ADDRESS@@ for details. Content preview: close 44983 29.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 44983 29.1 quit From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 07:03:10 2022 Received: (at 44983) by debbugs.gnu.org; 30 Apr 2022 11:03:10 +0000 Received: from localhost ([127.0.0.1]:55963 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkksY-0005jt-E2 for submit@debbugs.gnu.org; Sat, 30 Apr 2022 07:03:10 -0400 Received: from quimby.gnus.org ([95.216.78.240]:47108) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkksW-0005jd-Hh for 44983@debbugs.gnu.org; Sat, 30 Apr 2022 07:03:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=/RprUk1uMRPQqtS//oHa67mwpiNTloFzPNVLxGVtse0=; b=ZxLUTnNpUP7fOS+xT+tq/Elfqy 8+KIc/Xj26fnrZPlwQ9AEh5hM5m0YQndJ48mtg754xQIbTbJaU4INdMEI0uWLJ07r8Ye5TTrlYQyY r3YSLjO8AAETwlbcHEk7Haza1qUE+1uROLrlhuXBXh0l3gL4HVj+peMfirX7DrK1kzt8=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkksN-00073l-ML; Sat, 30 Apr 2022 13:03:01 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#44983: Truncate long lines of grep output References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <87tuacf79e.fsf@gnus.org> <87bkwi6h9l.fsf@gnus.org> <874k2a6gjo.fsf@gnus.org> <83o80i992v.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEX8+/uopaMnJCTS 0M6Cfnz////M28vfAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+YEHgo5F8lPWfgAAAFqSURBVDjLdZOB kYQgDEXjYQGgFLDEFABiAQtn/zVdQGTB5ZidWSeP8JNPAChrwc+y4NUdh9gALYW+40cTR4dBjxLQ CjxLXLRxlLqCqQOR1A3mDpwU7qp++qMO/C1gf4J1mHGShDGobT/A6v8BBx0wKpeWuBQR3TlC4Zje KWyX7iAGcwJTxMei/VwsaPxaNCMB4AD4SdgRME5rCd1OPvdAkuxcBwxfl4lorVZrp0FzMPzjtlIT nd2TFSwLhxUNOCNu2TyhYqcRWPZdJsC6JiNodKRyjoe2jxBJRAzf4EQDZTgcH1YBIW7gUk1Jvu+D pefXNZh9H7w70qXRAcrjZbPGA6TR3lIfq7cdyCORJHwH3HX3pfumD7vmf67LrQ2Ixu75Y2MJJysg f9pYpNZcV9nPPpdXRUJCtWSb4ru+kWTLbeILdlPfZwblojZ+zrEC+ckwzbQTNBpmaQGXpAYjypYp JQfAZIUB2C6r/gB9NXonsqP/TwAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMi0wNC0zMFQxMDo1Nzoy MyswMDowMOV3srkAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDQtMzBUMTA6NTc6MjMrMDA6MDCU KgoFAAAAAElFTkSuQmCC X-Now-Playing: New Order's _Low-Life (1)_: "Sunrise" Date: Sat, 30 Apr 2022 13:02:59 +0200 In-Reply-To: <83o80i992v.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 30 Apr 2022 13:09:12 +0300") Message-ID: <87r15e4yvw.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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 @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > We are not. The display engine will never call jit-lock on a region > that starts in invisible text. But a region that starts in visible > text can end in invisible text, and font-lock doesn't pay a [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: juri@linkov.net, 44983@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > We are not. The display engine will never call jit-lock on a region > that starts in invisible text. But a region that starts in visible > text can end in invisible text, and font-lock doesn't pay attention to > invisibility spec, AFAIR, it just looks at the buffer text > disregarding everything else. Yes, that's correct, I think. But shouldn't it be smarter here? That is, the display engine does know that all the text it inserted was invisible, so calling jit-lock again (with the same parameters as previous time) is futile. However, this is probably not something many modes do, so putting more effort into optimising this is probably not worth it. > For me, the more important question is: why the problem didn't > disappear when you turned off font-lock-mode in the offending buffer. > And I think I know why: you need to turn off jit-lock-mode as well. Probably. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 07:04:59 2022 Received: (at 44983) by debbugs.gnu.org; 30 Apr 2022 11:04:59 +0000 Received: from localhost ([127.0.0.1]:55967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkkuI-0005mQ-Pr for submit@debbugs.gnu.org; Sat, 30 Apr 2022 07:04:58 -0400 Received: from quimby.gnus.org ([95.216.78.240]:47130) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkkuH-0005mC-Jg for 44983@debbugs.gnu.org; Sat, 30 Apr 2022 07:04:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=EhW4RmosFnzF09veH56Cotla8Xl941JbZB6OzBJo53A=; b=U1qjvChaxb5OQJ57A2+pqRAC1e un5/SAn2nEiumlCLaiHlazcOGLlzhD9PtMBvbY4KsSGcCbMbT6P8KJHrFuD9Alixh0EkhNL5YtpJd E0IQWc1yRCsQBQV5abhMvXlAiogvPQ1ONMsmmcwX2kwT6OpcBHQ0IozXCr7S/iqKFCho=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkku9-00074I-7V; Sat, 30 Apr 2022 13:04:51 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#44983: Truncate long lines of grep output References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <87tuacf79e.fsf@gnus.org> <83tuac9j0l.fsf@gnu.org> <87tuacdpte.fsf@gnus.org> <83sfpw9gw7.fsf@gnu.org> <87levm6i0i.fsf@gnus.org> <87fslu6hga.fsf@gnus.org> <83mtg298t0.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEX8+/uopaMnJCTS 0M6Cfnz////M28vfAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+YEHgo5F8lPWfgAAAFqSURBVDjLdZOB kYQgDEXjYQGgFLDEFABiAQtn/zVdQGTB5ZidWSeP8JNPAChrwc+y4NUdh9gALYW+40cTR4dBjxLQ CjxLXLRxlLqCqQOR1A3mDpwU7qp++qMO/C1gf4J1mHGShDGobT/A6v8BBx0wKpeWuBQR3TlC4Zje KWyX7iAGcwJTxMei/VwsaPxaNCMB4AD4SdgRME5rCd1OPvdAkuxcBwxfl4lorVZrp0FzMPzjtlIT nd2TFSwLhxUNOCNu2TyhYqcRWPZdJsC6JiNodKRyjoe2jxBJRAzf4EQDZTgcH1YBIW7gUk1Jvu+D pefXNZh9H7w70qXRAcrjZbPGA6TR3lIfq7cdyCORJHwH3HX3pfumD7vmf67LrQ2Ixu75Y2MJJysg f9pYpNZcV9nPPpdXRUJCtWSb4ru+kWTLbeILdlPfZwblojZ+zrEC+ckwzbQTNBpmaQGXpAYjypYp JQfAZIUB2C6r/gB9NXonsqP/TwAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMi0wNC0zMFQxMDo1Nzoy MyswMDowMOV3srkAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDQtMzBUMTA6NTc6MjMrMDA6MDCU KgoFAAAAAElFTkSuQmCC X-Now-Playing: New Order's _Low-Life (1)_: "Elegia" Date: Sat, 30 Apr 2022 13:04:46 +0200 In-Reply-To: <83mtg298t0.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 30 Apr 2022 13:15:07 +0300") Message-ID: <87mtg24ysx.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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 @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > Part of redisplaying the buffer is making sure the text that might > wind up on display is fontified. Which part will actually be on > display can only be known _after_ the text is fontified (becaus [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: dgutov@yandex.ru, 44983@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > Part of redisplaying the buffer is making sure the text that might > wind up on display is fontified. Which part will actually be on > display can only be known _after_ the text is fontified (because > fontification can change faces, and thus affect what's visible in the > window). Yeah, that's true -- font-lock might end up making the text visible, even, I guess? But then we're being slightly inconsistent -- if the entire region is invisible, then we don't let font-lock do anything, you said. But it probably doesn't really matter much. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 07:12:50 2022 Received: (at 44983) by debbugs.gnu.org; 30 Apr 2022 11:12:50 +0000 Received: from localhost ([127.0.0.1]:55984 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkl1u-0005yj-2C for submit@debbugs.gnu.org; Sat, 30 Apr 2022 07:12:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkl1r-0005yW-Gx for 44983@debbugs.gnu.org; Sat, 30 Apr 2022 07:12:47 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42842) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkl1l-0001Kf-Nb; Sat, 30 Apr 2022 07:12:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=+cp02sqp6GaP7/04pTYsqE//rfunjuO48WNbIq8tOiE=; b=CccGVuAHPdQp g+5lvKg5abC/tKfEuYG4IGy7GjvZfWEal6p2bK1ZlwjFs5wTVAnP+nMzbLs9i0ZSZZ1RbY2XzhAKv FDB4DqIAN5H6pxGjOI4mNuT80NYF4Y9ptmP4sRCutwU66hrHg7MDvbQ2VFaGOboCaGghJ3YI6gsmG XMvYrp9XgpLck9wuW19tjqO/t/uxyB+PqKctQ29O6OBsa0j12fE9mlNNZuMzwCVAOKbHw9ZDiWsGz 3MVUqwpJ91ibuF4SbFQvZOQIPlLkHazD57abvFgA1s82JZTnJKfLDhNF36ZcQPR9d9qakCHjdI7yI HRXMilD7LpEj1MIvuMjePw==; Received: from [87.69.77.57] (port=4258 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkl1l-0004Oe-4y; Sat, 30 Apr 2022 07:12:41 -0400 Date: Sat, 30 Apr 2022 14:12:45 +0300 Message-Id: <83fslu964y.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87r15e4yvw.fsf@gnus.org> (message from Lars Ingebrigtsen on Sat, 30 Apr 2022 13:02:59 +0200) Subject: Re: bug#44983: Truncate long lines of grep output References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <87tuacf79e.fsf@gnus.org> <87bkwi6h9l.fsf@gnus.org> <874k2a6gjo.fsf@gnus.org> <83o80i992v.fsf@gnu.org> <87r15e4yvw.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44983 Cc: juri@linkov.net, 44983@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: dgutov@yandex.ru, 44983@debbugs.gnu.org, juri@linkov.net > Date: Sat, 30 Apr 2022 13:02:59 +0200 > > Eli Zaretskii writes: > > > We are not. The display engine will never call jit-lock on a region > > that starts in invisible text. But a region that starts in visible > > text can end in invisible text, and font-lock doesn't pay attention to > > invisibility spec, AFAIR, it just looks at the buffer text > > disregarding everything else. > > Yes, that's correct, I think. But shouldn't it be smarter here? That > is, the display engine does know that all the text it inserted was > invisible No, it doesn't know that. The display engine handles the 'fontified' property first, and the invisible property only after that. Even more importantly, the display engine handles these properties only when it gets to a character with that property, so it's enough that we have a single character with no invisible property that needs to be fontified, to have the display engine invoke jit-lock on a chunk of text starting with that visible character. From debbugs-submit-bounces@debbugs.gnu.org Sun May 01 13:48:18 2022 Received: (at 44983) by debbugs.gnu.org; 1 May 2022 17:48:18 +0000 Received: from localhost ([127.0.0.1]:34115 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlDg9-0000Uq-Ua for submit@debbugs.gnu.org; Sun, 01 May 2022 13:48:18 -0400 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:39961) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlDg8-0000UN-Ai for 44983@debbugs.gnu.org; Sun, 01 May 2022 13:48:16 -0400 Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id 13228FF805; Sun, 1 May 2022 17:48:08 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#44983: Truncate long lines of grep output Organization: LINKOV.NET References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <87tuacf79e.fsf@gnus.org> <86r15fvn5j.fsf@mail.linkov.net> Date: Sun, 01 May 2022 20:14:17 +0300 In-Reply-To: (Dmitry Gutov's message of "Sat, 30 Apr 2022 03:27:11 +0300") Message-ID: <86pmkxgopi.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.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: Lars Ingebrigtsen , 44983@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> I don't remember such font-lock text property, but now I have no problems >> when long lines are hidden initially with: > > When you apply this, do you disable the existing mechanism for dealing with > long lines? By setting 'xref-truncation-width' to nil. Oops, I forgot about xref-truncation-width. Maybe it's actually xref-truncation-width that fixed the problem. From unknown Tue Jun 17 03:39:24 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 30 May 2022 11:24:09 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator