From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 01 15:41:09 2021 Received: (at submit) by debbugs.gnu.org; 1 Mar 2021 20:41:09 +0000 Received: from localhost ([127.0.0.1]:51010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGpLp-0006NY-1D for submit@debbugs.gnu.org; Mon, 01 Mar 2021 15:41:09 -0500 Received: from lists.gnu.org ([209.51.188.17]:39218) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGpLn-0006NR-FR for submit@debbugs.gnu.org; Mon, 01 Mar 2021 15:41:07 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34322) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lGpLm-0006Ne-3X for bug-gnu-emacs@gnu.org; Mon, 01 Mar 2021 15:41:07 -0500 Received: from out2.migadu.com ([2001:41d0:2:aacc::]:18389) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lGpLe-0006xU-Ed for bug-gnu-emacs@gnu.org; Mon, 01 Mar 2021 15:41:05 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Theodor Thornhill To: bug-gnu-emacs@gnu.org Subject: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el Date: Mon, 01 Mar 2021 21:40:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no Received-SPF: pass client-ip=2001:41d0:2:aacc::; envelope-from=theo@thornhill.no; helo=out2.migadu.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) 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.4 (--) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi! When using the xref buffer, especially in combination with 'project-find-regexp', sometimes my projects has huge one-line files. The simplest example of these kind of files are the minified ".js" files that are compiled. Right now I have one at 500 000 columns, which admittedly is a lot. However, when 'project-find-regexp' searches these files and finds a hit in one of them, the search takes a long time. In addition, navigating the xref buffer when the results show up also takes a long time, because of the troubles emacs has with long lines. Before the supplied patch, one search with 'project-find-regexp' with ripgrep enabled takes around 3-4 seconds. With the supplied patch, the search is almost instantaneous. The added functionality is created to not kick in before a certain threshold, where 500 columns seems reasonably long. Anything above that will be truncated, but xref will still show that there was a hit. I'm sure the patch can be improved, so please, don't hesitate to tell me. I consider this a great improvement, and I hope you will to=C2=A7 Have a nice day, -- Theodor Thornhill --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Add-option-to-truncate-long-lines.patch >From dcc2078c20d8edd32407498c16d65ea46d44a3a0 Mon Sep 17 00:00:00 2001 From: Theodor Thornhill Date: Mon, 1 Mar 2021 21:26:44 +0100 Subject: [PATCH] Add option to truncate long lines * (xref-truncate-line-to): New option. Set cut-off point for long lines in xref buffer * (xref--truncate-long-lines-p): Helper function for xref--insert-xrefs. * (xref--insert-xrefs): By truncating long lines we get a huge speedup both when invoking xref, and while navigating the xref buffer. --- lisp/progmodes/xref.el | 37 ++++++++++++++++++++++++++++++------- 1 file changed, 30 insertions(+), 7 deletions(-) diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index 18fdd963fb..98dacef94f 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -872,6 +872,19 @@ beginning of the line." (xref--search-property 'xref-item)) (xref-show-location-at-point)) +(defcustom xref-truncate-line-to 500 + "Max number of columns to display in xref buffer." + :type '(choice + (fixnum :tag "Number of lines") + (null :tag "Don't truncate")) + :version "28.1" + :package-version '(xref . "1.0.5")) + +(defun xref--truncate-long-lines-p (summary) + (cl-check-type summary xref-item) + (and (numberp xref-truncate-line-to) + (> (length summary) xref-truncate-line-to))) + (defun xref--insert-xrefs (xref-alist) "Insert XREF-ALIST in the current-buffer. XREF-ALIST is of the form ((GROUP . (XREF ...)) ...), where @@ -902,14 +915,24 @@ GROUP is a string for decoration purposes and XREF is an " "))) ;; Render multiple matches on the same line, together. (when (and line (equal prev-line-key line-key)) - (when-let ((column (xref-location-column location))) - (delete-region - (save-excursion - (forward-line -1) - (move-to-column (+ (length prefix) column)) + ;; Overwrite if we want to truncate long lines. + (if (xref-truncate-long-lines-p new-summary) + (delete-region + (save-excursion (forward-line -1) (point)) + (point)) + (when-let ((column (xref-location-column location))) + (delete-region + (save-excursion + (forward-line -1) + (move-to-column (+ (length prefix) column)) + (point)) (point)) - (point)) - (setq new-summary (substring summary column) prefix ""))) + (setq new-summary (substring summary column) prefix "")))) + ;; Truncate + (when (xref-truncate-long-lines-p new-summary) + (setq new-summary + (concat (substring new-summary 0 xref-truncate-line-to) + " (...truncated)"))) (xref--insert-propertized (list 'xref-item xref 'mouse-face 'highlight -- 2.24.3 (Apple Git-128) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 01 17:07:42 2021 Received: (at 46859) by debbugs.gnu.org; 1 Mar 2021 22:07:42 +0000 Received: from localhost ([127.0.0.1]:51100 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGqha-0002Ko-1O for submit@debbugs.gnu.org; Mon, 01 Mar 2021 17:07:42 -0500 Received: from out2.migadu.com ([188.165.223.204]:19569) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGqhX-0002Kf-Nm for 46859@debbugs.gnu.org; Mon, 01 Mar 2021 17:07:40 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Theodor Thornhill To: 46859@debbugs.gnu.org Subject: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el Date: Mon, 01 Mar 2021 23:07:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46859 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 There was a typo in the previous patch, sorry about that! -- Theo --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Add-option-to-truncate-long-lines.patch >From 1697033f216a9792e374bda20816ff91491aa38e Mon Sep 17 00:00:00 2001 From: Theodor Thornhill Date: Mon, 1 Mar 2021 23:05:32 +0100 Subject: [PATCH] Add option to truncate long lines * (xref-truncate-line-to): New option. Set cut-off point for long lines in xref buffer * (xref--truncate-long-lines-p): Helper function for xref--insert-xrefs. * (xref--insert-xrefs): By truncating long lines we get a huge speedup both when invoking xref, and while navigating the xref buffer. --- lisp/progmodes/xref.el | 37 ++++++++++++++++++++++++++++++------- 1 file changed, 30 insertions(+), 7 deletions(-) diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index 18fdd963fb..c893137973 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -872,6 +872,19 @@ beginning of the line." (xref--search-property 'xref-item)) (xref-show-location-at-point)) +(defcustom xref-truncate-line-to 500 + "Max number of columns to display in xref buffer." + :type '(choice + (fixnum :tag "Number of lines") + (null :tag "Don't truncate")) + :version "28.1" + :package-version '(xref . "1.0.5")) + +(defun xref--truncate-long-lines-p (summary) + (cl-check-type summary xref-item) + (and (numberp xref-truncate-line-to) + (> (length summary) xref-truncate-line-to))) + (defun xref--insert-xrefs (xref-alist) "Insert XREF-ALIST in the current-buffer. XREF-ALIST is of the form ((GROUP . (XREF ...)) ...), where @@ -902,14 +915,24 @@ GROUP is a string for decoration purposes and XREF is an " "))) ;; Render multiple matches on the same line, together. (when (and line (equal prev-line-key line-key)) - (when-let ((column (xref-location-column location))) - (delete-region - (save-excursion - (forward-line -1) - (move-to-column (+ (length prefix) column)) + ;; Overwrite if we want to truncate long lines. + (if (xref--truncate-long-lines-p new-summary) + (delete-region + (save-excursion (forward-line -1) (point)) + (point)) + (when-let ((column (xref-location-column location))) + (delete-region + (save-excursion + (forward-line -1) + (move-to-column (+ (length prefix) column)) + (point)) (point)) - (point)) - (setq new-summary (substring summary column) prefix ""))) + (setq new-summary (substring summary column) prefix "")))) + ;; Truncate + (when (xref--truncate-long-lines-p new-summary) + (setq new-summary + (concat (substring new-summary 0 xref-truncate-line-to) + " (...truncated)"))) (xref--insert-propertized (list 'xref-item xref 'mouse-face 'highlight -- 2.24.3 (Apple Git-128) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 02 14:43:12 2021 Received: (at submit) by debbugs.gnu.org; 2 Mar 2021 19:43:12 +0000 Received: from localhost ([127.0.0.1]:54260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHAvI-0003GP-87 for submit@debbugs.gnu.org; Tue, 02 Mar 2021 14:43:12 -0500 Received: from lists.gnu.org ([209.51.188.17]:60900) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHAvG-0003GG-Us for submit@debbugs.gnu.org; Tue, 02 Mar 2021 14:43:11 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59236) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHAvG-00028p-Mn for bug-gnu-emacs@gnu.org; Tue, 02 Mar 2021 14:43:10 -0500 Received: from relay12.mail.gandi.net ([217.70.178.232]:60349) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHAvE-0006ZW-0G for bug-gnu-emacs@gnu.org; Tue, 02 Mar 2021 14:43:10 -0500 Received: from mail.gandi.net (m91-129-96-116.cust.tele2.ee [91.129.96.116]) (Authenticated sender: juri@linkov.net) by relay12.mail.gandi.net (Postfix) with ESMTPSA id DB26820000A; Tue, 2 Mar 2021 19:43:02 +0000 (UTC) From: Juri Linkov To: Theodor Thornhill via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el Organization: LINKOV.NET References: Date: Tue, 02 Mar 2021 21:25:50 +0200 In-Reply-To: (Theodor Thornhill via's message of "Mon, 01 Mar 2021 21:40:50 +0100") Message-ID: <87im69uzlt.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=iso-8859-1 Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=217.70.178.232; envelope-from=juri@linkov.net; helo=relay12.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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 Cc: 46859@debbugs.gnu.org, Theodor Thornhill 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 (--) > The added functionality is created to not kick in before a certain > threshold, where 500 columns seems reasonably long. Anything above that > will be truncated, but xref will still show that there was a hit. > > I'm sure the patch can be improved, so please, don't hesitate to tell > me. > > I consider this a great improvement, and I hope you will to§ I've customized 'xref-search-program-alist' that defines ripgrep command line to contain additional options: -M 500 --max-columns-preview that truncates long lines of ripgrep output after we discussed this in https://debbugs.gnu.org/44983 But maybe your new option would be easier to customize. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 02 16:14:15 2021 Received: (at submit) by debbugs.gnu.org; 2 Mar 2021 21:14:15 +0000 Received: from localhost ([127.0.0.1]:54367 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHCLP-0005XM-6M for submit@debbugs.gnu.org; Tue, 02 Mar 2021 16:14:15 -0500 Received: from lists.gnu.org ([209.51.188.17]:43466) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHCLM-0005XE-QY for submit@debbugs.gnu.org; Tue, 02 Mar 2021 16:14:14 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51424) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHCLL-0005fv-1F for bug-gnu-emacs@gnu.org; Tue, 02 Mar 2021 16:14:12 -0500 Received: from out1.migadu.com ([2001:41d0:2:863f::]:35449) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHCLD-0002vU-UY for bug-gnu-emacs@gnu.org; Tue, 02 Mar 2021 16:14:10 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Theodor Thornhill To: Juri Linkov , "Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors" Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: <87im69uzlt.fsf@mail.linkov.net> References: <87im69uzlt.fsf@mail.linkov.net> Date: Tue, 02 Mar 2021 22:13:57 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no Received-SPF: pass client-ip=2001:41d0:2:863f::; envelope-from=theo@thornhill.no; helo=out1.migadu.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: 46859@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.4 (--) Hi! Juri Linkov writes: > > I've customized 'xref-search-program-alist' that defines ripgrep > command line to contain additional options: > > -M 500 --max-columns-preview > Oh, right. That's pretty smart - and fast! > that truncates long lines of ripgrep output > after we discussed this in https://debbugs.gnu.org/44983 > I'm sorry - completely missed that bug, it seems. > But maybe your new option would be easier to customize. Yeah, maybe. However, without benchmarking, it is quite clear that adding your option is faster than my patch, since ripgrep has to search the whole minified file. I assume it short circuits, so that results are delivered quicker to emacs. Maybe this bug can be closed. Thanks for linking to that thread, and sorry for the noise :) -- Theo From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 02 16:37:58 2021 Received: (at 46859) by debbugs.gnu.org; 2 Mar 2021 21:37:58 +0000 Received: from localhost ([127.0.0.1]:54410 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHCiL-0008Bn-H5 for submit@debbugs.gnu.org; Tue, 02 Mar 2021 16:37:58 -0500 Received: from mail-wr1-f43.google.com ([209.85.221.43]:36205) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHCiJ-0008Ba-Je for 46859@debbugs.gnu.org; Tue, 02 Mar 2021 16:37:56 -0500 Received: by mail-wr1-f43.google.com with SMTP id u14so21441765wri.3 for <46859@debbugs.gnu.org>; Tue, 02 Mar 2021 13:37:55 -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=4f3UzxTDdTbybWja9EjOzou+OxvJlKdmUPRaaJ/bOg4=; b=QXCsAHlz7F6ySL10wrJp4phTU/fDLtj5hVhK5t/4E7DtnVVuiV/nvjG203NfEWM6+2 vAR6gGoe3KUdckv67mFmN9ntcdmINFaQrQrFiRDpOWGa7kjXOkNz9+LEe+/35sgoySRK hl9SHwT7MDiW6waKobo2mSYCwFcXi+1vUJopxReb3+Hwx2TCFHSUBz+azSD8oUp6Ih1u lQHfBeiQq1t1Zv4MWk5SFTkgQwxSCxB6G3jgCD+Az12vm8v0Ld2ZjDrdiSeDNXAfBdX0 EheKQYw9nuajoTLJjTbH0+1jVl3yzr41+mzM0vBoyzl+HwvRpja+vwgvlvyyLoZIQJfy zMEQ== 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=4f3UzxTDdTbybWja9EjOzou+OxvJlKdmUPRaaJ/bOg4=; b=OvaBONbTwazQTFMiKS1EWaqn8/0OpXXSaJCMp1V2ool+b+Kg65Fun0fr+ReHr9eBHb 6DQtTo4q24xbndEvt958efZ/ZJojX05fDqyXONnb7kgA8eO3ysLsCESNqEeORafarau9 42/ybha04Rn5bLGSV60oYP6g32S7mevfiK+tXAB5PJvxkXlGkgnRHRDq8Su6On/4dF+f 3iby74RBgHtVj9tgBl5p7zlFRpd4wYGiwYTED9xXIUaNYC8pDpEL3oQO62dMq6/nz7W/ 4jnLWs2z20JqA/yUJ1/+etFKiG9Rt8J9BB/PubUrxumlaFKmBqtPS9Tw6PSUV1q38zFW Sn8Q== X-Gm-Message-State: AOAM531bfcTX+WcVTsUSANvhlxIsHoitFAJGcEwk9IiAOnxSqTLYzV59 gpIcNL64d/glj0mMUHnCxM2ptf+mbYM= X-Google-Smtp-Source: ABdhPJxCOZHFQL9YthPfZOJOvw9nbaiGO5n2iti1sOtpZtdz+YAMoa6fz40/f0tPkrtven4lXZ+g2w== X-Received: by 2002:a5d:6951:: with SMTP id r17mr23417396wrw.279.1614721069548; Tue, 02 Mar 2021 13:37:49 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id g202sm3824467wme.20.2021.03.02.13.37.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Mar 2021 13:37:49 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Theodor Thornhill , juri@linkov.net, 46859@debbugs.gnu.org References: <87im69uzlt.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Tue, 2 Mar 2021 23:37:45 +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: 46859 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 (/) Hi Theodor, On 02.03.2021 23:13, Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > Yeah, maybe. However, without benchmarking, it is quite clear that > adding your option is faster than my patch, since ripgrep has to search > the whole minified file. I assume it short circuits, so that results > are delivered quicker to emacs. Maybe this bug can be closed. Could you try benchmarking both approaches? If the performance improvement from yours is at all comparable with Juri's, I'm inclined to prefer that direction for reasons described in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44983#71. In both cases Ripgrep (or Grep) will search the whole file. The -M flag just affects its output. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 02 16:45:51 2021 Received: (at 46859) by debbugs.gnu.org; 2 Mar 2021 21:45:51 +0000 Received: from localhost ([127.0.0.1]:54414 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHCpy-0008N2-Nt for submit@debbugs.gnu.org; Tue, 02 Mar 2021 16:45:50 -0500 Received: from out2.migadu.com ([188.165.223.204]:45033) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHCpv-0008Ms-I3 for 46859@debbugs.gnu.org; Tue, 02 Mar 2021 16:45:49 -0500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Theodor Thornhill MIME-Version: 1.0 Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el Date: Tue, 2 Mar 2021 22:45:43 +0100 Message-Id: References: In-Reply-To: To: Dmitry Gutov X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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: -1.0 (-) > 2. mar. 2021 kl. 22:37 skrev Dmitry Gutov : >=20 > =EF=BB=BFHi Theodor, >=20 >> On 02.03.2021 23:13, Theodor Thornhill via Bug reports for GNU Emacs, the= Swiss army knife of text editors wrote: >> Yeah, maybe. However, without benchmarking, it is quite clear that >> adding your option is faster than my patch, since ripgrep has to search >> the whole minified file. I assume it short circuits, so that results >> are delivered quicker to emacs. Maybe this bug can be closed. >=20 > Could you try benchmarking both approaches? >=20 Absolutely, I will see what I can come up with. > If the performance improvement from yours is at all comparable with Juri's= , I'm inclined to prefer that direction for reasons described in https://deb= bugs.gnu.org/cgi/bugreport.cgi?bug=3D44983#71. >=20 Yeah, that was my initial motivation for this change as well.=20 > In both cases Ripgrep (or Grep) will search the whole file. The -M flag ju= st affects its output. Oh, ok! Ill get back to you. =E2=80=94 Theo= From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 02 17:14:53 2021 Received: (at 46859) by debbugs.gnu.org; 2 Mar 2021 22:14:53 +0000 Received: from localhost ([127.0.0.1]:54455 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHDI5-0000cx-6F for submit@debbugs.gnu.org; Tue, 02 Mar 2021 17:14:53 -0500 Received: from out2.migadu.com ([188.165.223.204]:59215) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHDI2-0000co-FP for 46859@debbugs.gnu.org; Tue, 02 Mar 2021 17:14:51 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Theodor Thornhill To: Dmitry Gutov , juri@linkov.net, 46859@debbugs.gnu.org Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: References: <87im69uzlt.fsf@mail.linkov.net> Date: Tue, 02 Mar 2021 23:14:47 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46859 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 (-) Hi, Dmitry, Dmitry Gutov writes: > Hi Theodor, > > On 02.03.2021 23:13, Theodor Thornhill via Bug reports for GNU Emacs, > the Swiss army knife of text editors wrote: >> Yeah, maybe. However, without benchmarking, it is quite clear that >> adding your option is faster than my patch, since ripgrep has to search >> the whole minified file. I assume it short circuits, so that results >> are delivered quicker to emacs. Maybe this bug can be closed. > > Could you try benchmarking both approaches? > Ok, so here are some numbers: ;; With nothing (benchmark-run 10 (project-find-regexp "UrlChange")) ;; (11.748253 14 0.23526199999999997) ;; With -M 500 (benchmark-run 10 (project-find-regexp "UrlChange")) ;; (0.293626 0 0.0) ;; My patch (benchmark-run 10 (project-find-regexp "UrlChange")) ;; (1.230833 8 0.13783999999999996) > If the performance improvement from yours is at all comparable with > Juri's, I'm inclined to prefer that direction for reasons described in > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44983#71. > So, now it looks like my patch is an improvement, but not as much as limiting from ripgrep. I think that is because in my version, we still loop over the whole file, we just delete the contents so that we always show 500 columns. I'm interested in seeing if I could gain some more performance by short circuiting after the first iteration of a match on the same line. In my test scenario there are a lot of matches on the same huge line. What do you think? -- Theo From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 02 17:37:21 2021 Received: (at 46859) by debbugs.gnu.org; 2 Mar 2021 22:37:21 +0000 Received: from localhost ([127.0.0.1]:54470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHDdp-0001B2-JT for submit@debbugs.gnu.org; Tue, 02 Mar 2021 17:37:21 -0500 Received: from mail-wr1-f46.google.com ([209.85.221.46]:35165) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHDdm-0001An-Qm for 46859@debbugs.gnu.org; Tue, 02 Mar 2021 17:37:20 -0500 Received: by mail-wr1-f46.google.com with SMTP id l12so21558463wry.2 for <46859@debbugs.gnu.org>; Tue, 02 Mar 2021 14:37: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=eUYonnpzxtQqtiTFzlyrxWIzWhGKce5o2bVb6/cGDwI=; b=fG+02pkVeKSxf2XtJwZhW4UMoGo8pqRT7xs+uuzqV6hTqeTrhSimSunEfI5qJity+A QSOCr5qfXUbmgu70EAcrWj4NSXUyrcxrYFaag+KDEFDTITQdrEcdA0oT2xjx4o4lHZUx kmqlnlKgz6Xj7g/y1F+sVsXtr8tz61FnRFxcev94hPJHhJui0WKwjoF9emN5eNk5igi8 2zrO4Fw19hZACIGLGVO+sllRegULTzvh0nxDRgpv1W1g2rpgEFqO2GIgIImJQj8q3ql8 gvv/XG8an75sPjtxXZX4kt5KYtG3tC7yonlFekgdmzF+BU8jBlHOcU65BiRbv2WgohBd gtXw== 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=eUYonnpzxtQqtiTFzlyrxWIzWhGKce5o2bVb6/cGDwI=; b=r51YGjqhTACrWp/sCTp8aKxlDYiGthMC6mGJT8tjhH5m/n9g4OQn+pzCj9AhLorwJ/ eqvmOJNeBXH87iMIftlBOcm8s2t8m5VoDTs0tHOuH5mw8Womrv1hrcKTyByqHzJUD+D/ Eyv0anQFwK8qauiQQHY/v7mJb5T69Ra2Iid58olZGoBsw9+4O2de7V8YCagEHBTx402S NvB53crsXcvF99DgUv4abGG39PUYXi3mrkQCjTqjirbaExjBzCtpWtmzzBXYhFe0Oo+k YhH+1V9cDEn57o3fZRNU+NK32J99oFZz4U3T4c1Vswpm6pURAxH2PX19eGokh7YTGQtP FQlA== X-Gm-Message-State: AOAM5339DLPSTIUSNqAJwS6i8PWlqOv2T4KQd1ba33gbVscIvSbg8lt/ t6WrjCoGxYb1tFwWLZK1A1JJKQBx89M= X-Google-Smtp-Source: ABdhPJxM/unBl4msrM9a2vHFdOzPG43578iSw7rDRpGv03xuceUZi8SBq/HAnV1EhhcbrnaVZKhpEA== X-Received: by 2002:adf:ed06:: with SMTP id a6mr18120970wro.208.1614724632858; Tue, 02 Mar 2021 14:37:12 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id g17sm28700727wru.60.2021.03.02.14.37.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Mar 2021 14:37:12 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Theodor Thornhill , juri@linkov.net, 46859@debbugs.gnu.org References: <87im69uzlt.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <25782781-4baa-5d44-99a1-2e57552ab3a0@yandex.ru> Date: Wed, 3 Mar 2021 00:37:08 +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: 46859 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 03.03.2021 00:14, Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > I'm interested in seeing if I could gain some more > performance by short circuiting after the first iteration of a match on > the same line. In my test scenario there are a lot of matches on the > same huge line. What do you think? You probably mean to short-circuit as soon as you reach the target column (there might be multiple matches within those 500 chars), skipping the rest of the matches on the same line. Sounds worth a try. Another approach would be to truncate the line sometime earlier, like: diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index 18fdd963fb..63a17a8521 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -1531,7 +1531,10 @@ xref-matches-in-files (while (re-search-forward grep-re nil t) (push (list (string-to-number (match-string line-group)) (match-string file-group) - (buffer-substring-no-properties (point) (line-end-position))) + (buffer-substring-no-properties (point) + (min + (+ (point) 500) + (line-end-position)))) hits))) (xref--convert-hits (nreverse hits) regexp))) ...of course, ideally we would keep all contents of the line somewhere in memory and truncate with (setq truncate-line t). But IIRC Juri said this didn't give us as much of a speedup as we'd want. Another question: how many hits do you usually have in that huge one-line file? If it's more than 2-3, it might be that our current algorithm which creates "match objects" will duplicate this string unnecessarily N times (which is the number of hits), in xref--collect-matches-1, to then cut it up and merge into one line again when printing the buffer. In which case the patch above should also show a healthy improvement, but we could figure out something better instead. Anyway, please benchmark your "earlier short-circuit" approach and then the above patch too. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 04:29:58 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 09:29:58 +0000 Received: from localhost ([127.0.0.1]:55145 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHNpO-0008Vd-Al for submit@debbugs.gnu.org; Wed, 03 Mar 2021 04:29:58 -0500 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:58205) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHNpK-0008VC-Tk for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 04:29:57 -0500 X-Originating-IP: 91.129.96.116 Received: from mail.gandi.net (m91-129-96-116.cust.tele2.ee [91.129.96.116]) (Authenticated sender: juri@linkov.net) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id A4DDA1C000B; Wed, 3 Mar 2021 09:29:47 +0000 (UTC) From: Juri Linkov To: Theodor Thornhill Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el Organization: LINKOV.NET References: <87im69uzlt.fsf@mail.linkov.net> Date: Wed, 03 Mar 2021 11:05:20 +0200 In-Reply-To: (Theodor Thornhill's message of "Tue, 02 Mar 2021 22:13:57 +0100") Message-ID: <878s74fv27.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: 46859 Cc: 46859@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 (-) >> But maybe your new option would be easier to customize. > > Yeah, maybe. However, without benchmarking, it is quite clear that > adding your option is faster than my patch, since ripgrep has to search > the whole minified file. I assume it short circuits, so that results > are delivered quicker to emacs. Maybe this bug can be closed. Your new option is still necessary for the default case when 'xref-search-program' is 'grep' since GNU grep has no option to truncate output, so xref should do post-processing for grep. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 04:52:43 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 09:52:43 +0000 Received: from localhost ([127.0.0.1]:55206 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHOBP-0000dZ-0P for submit@debbugs.gnu.org; Wed, 03 Mar 2021 04:52:43 -0500 Received: from heytings.org ([95.142.160.155]:41174) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHOBM-0000dO-U7 for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 04:52:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1614765159; bh=YYgOc0gHcS0ato+zRr/MXUaAGmAK2Gs5QaJ/hv/DBLY=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=wMAZkhtJ+IWqGCCoBEoeCMeaKY7VWMWAv/HgtYjpxzLIJa4+2lvlgaOXtqYWj3gLe AGTh0ircyWHb3CjR7o23HI08WB26G+7TUyrOxCNxJoQGhIcUzFnMlu6OEwNmistbUI Cqmotgj2wDxMwXutkxpPDFQnx+vp3IAj8FQ9s0Fw60/30QU4L3ZzHcraz6/lcGT5Ut bbqchkXYVdvpruK/+pVpAiqgj+Fwm3sDtvgasSVucP7lRlIfGcjP8eN4H1/nnX5Vhp mzCdHKLcn7LHOjNYC/DH1EnZc34NDCKBeoBtx8o15Y+8pM1PIjm/65aWf7FW8xtE+p FK3q7KEdC/0Jw== Date: Wed, 03 Mar 2021 09:52:38 +0000 From: Gregory Heytings To: Juri Linkov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: <878s74fv27.fsf@mail.linkov.net> Message-ID: <4119ea3055ef8f306fc0@heytings.org> References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) >>> But maybe your new option would be easier to customize. >> >> Yeah, maybe. However, without benchmarking, it is quite clear that >> adding your option is faster than my patch, since ripgrep has to search >> the whole minified file. I assume it short circuits, so that results >> are delivered quicker to emacs. Maybe this bug can be closed. > > Your new option is still necessary for the default case when > 'xref-search-program' is 'grep' since GNU grep has no option to truncate > output, so xref should do post-processing for grep. > Actually, it is possible to truncate output with GNU grep: grep -oE '.{0,100}PATTERN.{0,100}' prints at most 100 characters before and after PATTERN. I find this much better than ripgrep -M. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 07:47:18 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 12:47:18 +0000 Received: from localhost ([127.0.0.1]:55345 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHQuM-0000jL-C7 for submit@debbugs.gnu.org; Wed, 03 Mar 2021 07:47:18 -0500 Received: from mail-wm1-f43.google.com ([209.85.128.43]:34336) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHQuJ-0000j2-JN for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 07:47:16 -0500 Received: by mail-wm1-f43.google.com with SMTP id o7-20020a05600c4fc7b029010a0247d5f0so2777215wmq.1 for <46859@debbugs.gnu.org>; Wed, 03 Mar 2021 04:47:15 -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=ntVYEkF70JwxJqv7jsDix2Y7zPgxcdHnZf8s8RyL5SE=; b=Bcte3cZiNItwWAhAT5T4ADeTOX9o/HezR907XmyQ4I/C4l7HOkdOC9JupEc/C/llUK YKUuo7RH8xfECzlZ8FP104O84NxbLjuJKhWpY1OGJ5Vj4WC6ixtbGge+BiwS0T0Xuiu7 i8ZEi+kMU0DzUALluwVnfqhJnt9tpgRdQwI1QWV4zZht3Ul8j84Mj7bdjPW6lBofUDdX 2H2Eq6EINgfl0KKeHLDdioxpKJhHa7wVixevACbf8PuPXVlBm093EWsiKGYP3neUDBA7 mA49u5V5l0Y6CrUtMxZWJQClhD7buZgLqljwnBCvqWVvhF+N+eFSX5ljZNrg7L0u6gbK lYsQ== 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=ntVYEkF70JwxJqv7jsDix2Y7zPgxcdHnZf8s8RyL5SE=; b=XKOF2LfpmxuVPZZpDwFDNc/6q6lIezcmqe8JH6QoTY7yciPVKI8hECKaotIJV1eSul xR5FJ6FleokzKqJZtUGgozBCgY46nHsWwIyEhM6pz1Qb8ZeiR6JlLBbw8JgYhmXtkDSe 1OAmbNExMEOlnji/8lGSEbsRpRJl4iJgJqq47T7crkq2iXEW+SUHXbMrB/NeAp6ocESP AZRLRoBnMYyKnQzJ6fjp9/Dn618YQiEGGWCgjJJU6ZZF90/5WPkIxY0a7d47bYz3/ZsS Ashr9huPRuZCCvBUAw6MWVj50tS17oCEo32zeYANUdM4xYZgybVwCYSC02lyV7+2Sn2Q aPmg== X-Gm-Message-State: AOAM532nrXLm0lERRKijT7TL8iHhODzRItEGAw1YADR4cVbINFMNxVPT FZkXpFIZtT3BhX9/6caYodpzsvlw2JY= X-Google-Smtp-Source: ABdhPJyLJ8rSrg2Q7ggU5jDMPAcjI57Dkrj5mDmFkhcsczksvXspLhDC1jSbcB83HciZtPWziuly0w== X-Received: by 2002:a1c:4382:: with SMTP id q124mr9196371wma.16.1614775629685; Wed, 03 Mar 2021 04:47:09 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id i8sm37560688wry.90.2021.03.03.04.47.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Mar 2021 04:47:08 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Gregory Heytings , Juri Linkov References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> From: Dmitry Gutov Message-ID: Date: Wed, 3 Mar 2021 14:47:05 +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: <4119ea3055ef8f306fc0@heytings.org> 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: 46859 Cc: 46859@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 03.03.2021 11:52, Gregory Heytings wrote: > Actually, it is possible to truncate output with GNU grep: > > grep -oE '.{0,100}PATTERN.{0,100}' > > prints at most 100 characters before and after PATTERN.  I find this > much better than ripgrep -M. I'm not sure how to parse that output (it would be quite different from what we get now), and if the one-long-line file has many matches inside, we'll still get them all, which we might or might not want. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 08:54:08 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 13:54:08 +0000 Received: from localhost ([127.0.0.1]:55422 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHRwy-0004dU-B2 for submit@debbugs.gnu.org; Wed, 03 Mar 2021 08:54:08 -0500 Received: from heytings.org ([95.142.160.155]:41388) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHRws-0004d1-AW for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 08:54:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1614779636; bh=zy8Ydqx+6csVq8aAuj3N7PorcTaHh4gT6va1uhwBl9w=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=c6zTzzPdzJEorR59ACOP6g9Du7pa2RYTRmc7VvRkQayxWLdBu+f3dJ4HIVeDjWUCO KwuEOR84QzAT3/081Gr7jPcEkwzkYtSsiMQHoajbP1UdU/55fk+LyZnsxK/4J3JaW3 LjjI81rJuXU8ebRv8IUnNoin10fP7wukA3KYovZJGq3aeQKzAA/lIzPLVJWBdJvGgC Dgj9MKOqfWo6n5EODbbYC6/0Bmq01ukMBDhnVMcMiLhii3xy4I96Z/rdu8mtnsQZ0m W5zu77dzYXmArNOL9a7omRNbyGl2C13HQ8t3OJ7jzpMuhk9M7qf98IWfgWJXywFUDc aRnFz4Xa/lmrg== Date: Wed, 03 Mar 2021 13:53:56 +0000 From: Gregory Heytings To: Dmitry Gutov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: Message-ID: <4119ea30557ef84ca190@heytings.org> References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="rQ53CY9bon" Content-ID: <4119ea3055caa77083e0@heytings.org> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) --rQ53CY9bon Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-ID: <4119ea3055f423fb8702@heytings.org> >> Actually, it is possible to truncate output with GNU grep: >>=20 >> grep -oE '.{0,100}PATTERN.{0,100}' >>=20 >> prints at most 100 characters before and after PATTERN.=C2=A0 I find thi= s=20 >> much better than ripgrep -M. > > I'm not sure how to parse that output (it would be quite different from= =20 > what we get now), > How so? AFAICS, it's the exact same kind of output, except that it gets=20 truncated. And it's (obviously?) better to see the context of the pattern= =20 you are searching for, instead of the first characters of the lines on=20 which the pattern is found, in which the pattern might not be present. > > and if the one-long-line file has many matches inside, we'll still get=20 > them all, which we might or might not want. > Indeed, if one-long-line has many matches inside, you'll get them all,=20 which IMO makes perfect sense. Note that this does not happen when all matches are inside the boundaries.= =20 For example, if your search for '.{0,100}b.{0,100}' on "aaaabbbbcccc", you= =20 get a single match; if you search for '.{0,1}b.{0,1}' on that same string= =20 you get two matches. --rQ53CY9bon-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 09:01:07 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 14:01:07 +0000 Received: from localhost ([127.0.0.1]:55426 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHS3m-0004pw-Rc for submit@debbugs.gnu.org; Wed, 03 Mar 2021 09:01:07 -0500 Received: from mail-wm1-f48.google.com ([209.85.128.48]:39301) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHS3k-0004pK-9l for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 09:01:04 -0500 Received: by mail-wm1-f48.google.com with SMTP id u125so6429096wmg.4 for <46859@debbugs.gnu.org>; Wed, 03 Mar 2021 06:01:04 -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=T4Y+TKmLrCYoNyuSyp5ZFciorkbm2yis+/A57ViYieY=; b=TkUPMr7xLjjNXWUTsSJDWtaJiIsVb8DmiAGCWhcrfCvbvIs/ZSJeaeThelHgXqcK8y bYbnJMQaqDhYmnh4eiVvsXJBfxeyn3ohvgnRBugs+72Zb0g7Q1fIFdlCPByWHZBPUqmd 0he9qs30ze0YUJOj+ckpKr6M9jxiUcxx5ARg0DhyjA42VNm7zNnzHCzHNWW9R8Cryyec opAQrzLW4cQ9lQELD69Yyh3c+WfW5DvLUt2oMrywluL5hj3Sj8ZPZ4oB+/n9jOItpnWa GoJPgQV/9Xt+8sCTud6hD7+b99bGQfjSlA23xUMet1ahBxtsd9oZaP2Mva1g70FtEjox uvhw== 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=T4Y+TKmLrCYoNyuSyp5ZFciorkbm2yis+/A57ViYieY=; b=nnuIVxZ+f7PrjoJrxGf9YYvUqS7NuEHAy2PUgXvgoZQ9dJppGR68w87J2tNq3fOMyA Ze9MBwzH4LGbCjsFXZomFiup9FIOjiIVPUh9s47WLpxcNfvQo72UckiA3SUemq4PbEqW OPrXW6rUaFYY0CIywfokhie/qTxU3ZMuURaMrwA1U24X7ukEM55wRnRcbVGmSSID7xkt yjy9uBiuVJa075O81km+E0Bm3kS8nff5oGDj8KKoIa4NTIKU0Mf4tMuRNGzCf/rf0Eze tzAgYm+ZRqFenC7/yl2NiN4Q5fKw+RDxunRDWXeaUiIGOnQEYiab0o6jcauX5IDmB03V rSiw== X-Gm-Message-State: AOAM532qE4gVVe4Af78zTsCCH9fJBeiiD/05PZsmYk66CeIc6363SBLd 9lzpQIm3iNXcV6n5Z8vU+VFpUAyxMh0= X-Google-Smtp-Source: ABdhPJzcKTTZaiPYO2j8x7zRcIj77V3XbcoUSQkyRerxKMmQ0tZTk/FBlj/pxANrRMZugT8HGnC/zA== X-Received: by 2002:a1c:2155:: with SMTP id h82mr9436256wmh.169.1614780058317; Wed, 03 Mar 2021 06:00:58 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id x25sm7724540wmj.14.2021.03.03.06.00.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Mar 2021 06:00:57 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Gregory Heytings References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> From: Dmitry Gutov Message-ID: <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> Date: Wed, 3 Mar 2021 16:00:55 +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: <4119ea30557ef84ca190@heytings.org> 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: 46859 Cc: 46859@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 03.03.2021 15:53, Gregory Heytings wrote: > How so?  AFAICS, it's the exact same kind of output, except that it gets > truncated.  And it's (obviously?) better to see the context of the > pattern you are searching for, instead of the first characters of the > lines on which the pattern is found, in which the pattern might not be > present. Since Grep doesn't return the column number of the match, we get it from parsing the string again. And if the string is now modified to be truncated from both sides, the column number will become wrong. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 10:04:25 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 15:04:25 +0000 Received: from localhost ([127.0.0.1]:56603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHT33-0000L5-AA for submit@debbugs.gnu.org; Wed, 03 Mar 2021 10:04:25 -0500 Received: from heytings.org ([95.142.160.155]:41470) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHT31-0000Kx-Jg for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 10:04:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1614783862; bh=gvlZQhi64dHvbleT13x4EmschqlJ2ZJNlAIzvg5U4a8=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=n3BsQVWD48Rl01SaGwwOGJyoDVW//aJCYinXtNp6crqm8eoKsJE1MwjwyKN1rVdvu iPz0DId+8fEn04q0XHjhCnLbQwYQ5gxuaXLtkbjnZCxRmEQuKM9RTp2PQ5sgDINuyG rwu+3y6rAc+g2v0fsdFo2cQ98UFiClxX+kmYaGcwmBpOw4yrWa6Dvo+7SVbh8DfE5/ 3kgkgXCUNfmCZ2o+nQ9wyPGjb1go15VBquHHZi0SbG9tUB57PGOUrh6wIzrRdoKqTV 5a8bCY4pn/Y/s9D4bEw6592GY/VuXmXwZCDrmSRCaUlcabt697qkxuve8ii4ABiuCE ZEt3WsOJNtxBQ== Date: Wed, 03 Mar 2021 15:04:22 +0000 From: Gregory Heytings To: Dmitry Gutov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> Message-ID: <4119ea30554b406efbbf@heytings.org> References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="6ZRdvFg1td" Content-ID: <4119ea3055bd958c98f8@heytings.org> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) --6ZRdvFg1td Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-ID: <4119ea30556dcf8da8d0@heytings.org> >> How so?=C2=A0 AFAICS, it's the exact same kind of output, except that it= =20 >> gets truncated.=C2=A0 And it's (obviously?) better to see the context of= the=20 >> pattern you are searching for, instead of the first characters of the=20 >> lines on which the pattern is found, in which the pattern might not be= =20 >> present. > > Since Grep doesn't return the column number of the match, we get it from= =20 > parsing the string again. And if the string is now modified to be=20 > truncated from both sides, the column number will become wrong. > I did not understand that you need the column number of the match. That=20 could perhaps become a feature request for GNU grep: with -o and -n, also= =20 print the column number of the first character. That being said, if you truncate the N first characters of the matching=20 line, you have to parse the original line (that is, not the line that grep= =20 or another tool outputs) to find the matches anyway. --6ZRdvFg1td-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 11:14:07 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 16:14:07 +0000 Received: from localhost ([127.0.0.1]:56725 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHU8U-0004In-P1 for submit@debbugs.gnu.org; Wed, 03 Mar 2021 11:14:07 -0500 Received: from out0.migadu.com ([94.23.1.103]:20484) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHU8Q-0004ID-Ct for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 11:14:05 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Theodor Thornhill To: Dmitry Gutov , juri@linkov.net, 46859@debbugs.gnu.org Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: <25782781-4baa-5d44-99a1-2e57552ab3a0@yandex.ru> References: <87im69uzlt.fsf@mail.linkov.net> <25782781-4baa-5d44-99a1-2e57552ab3a0@yandex.ru> Date: Wed, 03 Mar 2021 17:13:58 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46859 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 (-) Hi again! Dmitry Gutov writes: > On 03.03.2021 00:14, Theodor Thornhill via Bug reports for GNU Emacs, > the Swiss army knife of text editors wrote: >> I'm interested in seeing if I could gain some more >> performance by short circuiting after the first iteration of a match on >> the same line. In my test scenario there are a lot of matches on the >> same huge line. What do you think? I couldn't really find any approaches that yielded better results with short-circuiting in mind, so I dropped that idea. > You probably mean to short-circuit as soon as you reach the target > > ...of course, ideally we would keep all contents of the line somewhere > in memory and truncate with (setq truncate-line t). But IIRC Juri said > this didn't give us as much of a speedup as we'd want. > > Another question: how many hits do you usually have in that huge > one-line file? If it's more than 2-3, it might be that our current > algorithm which creates "match objects" will duplicate this string > unnecessarily N times (which is the number of hits), in > xref--collect-matches-1, to then cut it up and merge into one line again > when printing the buffer. In which case the patch above should also show > a healthy improvement, but we could figure out something better instead. > This long line has 25 matches, so yeah, that takes some time. With your hint here I tried another approach which yielded some nice results. Ok, some benchmarks: ;; With nothing (benchmark-run 10 (project-find-regexp "UrlChange")) ;; (11.748253 14 0.23526199999999997) ;; With -M 500 (benchmark-run 10 (project-find-regexp "UrlChange")) ;; (0.293626 0 0.0) ;; My first patch (benchmark-run 10 (project-find-regexp "UrlChange")) ;; (1.230833 8 0.13783999999999996) ;; Dmitrys patch (benchmark-run 10 (project-find-regexp "UrlChange")) ;; (1.007787 0 0.0) ;; Latest diff (attached at the bottom) (benchmark-run 10 (project-find-regexp "UrlChange")) ;; (1.0351299999999999 0 0.0) So there are some interesting findings here: - There are some improvements to gain - None so far kills "-M 500" - Pretty close between Dmitrys and my last patch However, only my patch actually renders the long file as a match in the output buffer. All the others seem to drop it altogether. IMO that is one point in favour of my approaches. In addition, we could add another defcustom for the xref--collect-matches-1 function, "xref--collect-all-matches-p" or something like that. Retrofitting the current variable seems a little off. That means you could customize xref to render the whole long line if you want, while not bothering about multiple matches. Not sure if that has a great benefit, though. What do you think? Are any of these approaches worth pursuing further? -- Theo diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index 18fdd963fb..fb422dcffa 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -872,6 +872,18 @@ beginning of the line." (xref--search-property 'xref-item)) (xref-show-location-at-point)) +(defcustom xref-truncate-line-to 500 + "Max number of columns to display in xref buffer." + :type '(choice + (fixnum :tag "Number of lines") + (null :tag "Don't truncate")) + :version "28.1" + :package-version '(xref . "1.0.5")) + +(defun xref--truncate-long-lines-p (summary) + (and (numberp xref-truncate-line-to) + (> (length summary) xref-truncate-line-to))) + (defun xref--insert-xrefs (xref-alist) "Insert XREF-ALIST in the current-buffer. XREF-ALIST is of the form ((GROUP . (XREF ...)) ...), where @@ -902,14 +914,22 @@ GROUP is a string for decoration purposes and XREF is an " "))) ;; Render multiple matches on the same line, together. (when (and line (equal prev-line-key line-key)) - (when-let ((column (xref-location-column location))) - (delete-region - (save-excursion - (forward-line -1) - (move-to-column (+ (length prefix) column)) + (if (xref--truncate-long-lines-p summary) + (delete-region + (save-excursion (forward-line -1) (point)) + (point)) + (when-let ((column (xref-location-column location))) + (delete-region + (save-excursion + (forward-line -1) + (move-to-column (+ (length prefix) column)) + (point)) (point)) - (point)) - (setq new-summary (substring summary column) prefix ""))) + (setq new-summary (substring summary column) prefix "")))) + (when (xref--truncate-long-lines-p new-summary) + (setq new-summary + (concat (substring new-summary 0 xref-truncate-line-to) + " (...truncated)"))) (xref--insert-propertized (list 'xref-item xref 'mouse-face 'highlight @@ -1678,7 +1698,7 @@ Such as the current syntax table and the applied syntax properties." syntax-needed))))) (defun xref--collect-matches-1 (regexp file line line-beg line-end syntax-needed) - (let (matches) + (let (matches prev-line) (when syntax-needed (syntax-propertize line-end)) ;; FIXME: This results in several lines with the same @@ -1688,14 +1708,18 @@ Such as the current syntax table and the applied syntax properties." (or (null matches) (> (point) line-beg)) (re-search-forward regexp line-end t)) - (let* ((beg-column (- (match-beginning 0) line-beg)) - (end-column (- (match-end 0) line-beg)) - (loc (xref-make-file-location file line beg-column)) - (summary (buffer-substring line-beg line-end))) - (add-face-text-property beg-column end-column 'xref-match - t summary) - (push (xref-make-match summary loc (- end-column beg-column)) - matches))) + + (unless (and (eq prev-line line) + (numberp xref-truncate-line-to)) + (let* ((beg-column (- (match-beginning 0) line-beg)) + (end-column (- (match-end 0) line-beg)) + (loc (xref-make-file-location file line beg-column)) + (summary (buffer-substring line-beg line-end))) + (add-face-text-property beg-column end-column 'xref-match + t summary) + (push (xref-make-match summary loc (- end-column beg-column)) + matches))) + (setq prev-line line)) (nreverse matches))) (defun xref--find-file-buffer (file) From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 11:14:48 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 16:14:48 +0000 Received: from localhost ([127.0.0.1]:56737 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHU9A-0004KN-C0 for submit@debbugs.gnu.org; Wed, 03 Mar 2021 11:14:48 -0500 Received: from out1.migadu.com ([91.121.223.63]:18591) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHU98-0004KE-BU for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 11:14:47 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Theodor Thornhill To: Juri Linkov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: <878s74fv27.fsf@mail.linkov.net> References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> Date: Wed, 03 Mar 2021 17:14:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) Hi Juri, Juri Linkov writes: >>> But maybe your new option would be easier to customize. >> >> Yeah, maybe. However, without benchmarking, it is quite clear that >> adding your option is faster than my patch, since ripgrep has to search >> the whole minified file. I assume it short circuits, so that results >> are delivered quicker to emacs. Maybe this bug can be closed. > > Your new option is still necessary for the default case when > 'xref-search-program' is 'grep' since GNU grep has no option > to truncate output, so xref should do post-processing for grep. Yeah, agreed -- Theo From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 12:11:16 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 17:11:16 +0000 Received: from localhost ([127.0.0.1]:56874 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHV1n-0005nZ-U0 for submit@debbugs.gnu.org; Wed, 03 Mar 2021 12:11:16 -0500 Received: from heytings.org ([95.142.160.155]:41640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHV1m-0005nR-Ma for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 12:11:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1614791473; bh=LCgcftj7fcUBEktxdraaUo8j/bOOytLop9/p1sqeCzk=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=aEnZMtaIq03fYKtozJmFYBwDqTWaX8QcAbGcg5Y+S9qfBLkBQEzI9/J2+HSRagcz4 ldYQv9Gip+nvRu3JV/bDJiR2jQtLtnEohnC/bmJhnBD6kQmuJ2xnzyWZKOLGvfCLkG 3lX5lR59yum7BaIdKqLf0fStQN1FQo8JUz0Eod4cII2c381CNCn2PmoI/VW7rNDkZz P232TQDkK3ztJsK7bu6rfjMoDfjUeDV/OKNPaWpW0r1KllAMIHQ5Crq+3uLr2V1mnO 2QS+nX5e3AybwI6o2SryEKUk/7pAces9FZOmWghqjObN8sEXh6ploOY/QdC8SjnYmx Zp/DVAqfo5hPA== Date: Wed, 03 Mar 2021 17:11:12 +0000 From: Gregory Heytings To: Dmitry Gutov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: <4119ea30554b406efbbf@heytings.org> Message-ID: <4119ea30558f1e4145b0@heytings.org> References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="6lDZpfECT8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) --6lDZpfECT8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable >>> How so?=C2=A0 AFAICS, it's the exact same kind of output, except that i= t=20 >>> gets truncated.=C2=A0 And it's (obviously?) better to see the context o= f=20 >>> the pattern you are searching for, instead of the first characters of= =20 >>> the lines on which the pattern is found, in which the pattern might=20 >>> not be present. >>=20 >> Since Grep doesn't return the column number of the match, we get it=20 >> from parsing the string again. And if the string is now modified to be= =20 >> truncated from both sides, the column number will become wrong. > > I did not understand that you need the column number of the match.=20 > That could perhaps become a feature request for GNU grep: with -o and=20 > -n, also print the column number of the first character. > I wrote too fast. In fact you can get the column number with GNU grep=20 without parsing the original line: grep -nb -oE '.{0,100}PATTERN.{0,100}' --6lDZpfECT8-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 12:26:16 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 17:26:17 +0000 Received: from localhost ([127.0.0.1]:56891 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHVGK-0006AN-Nf for submit@debbugs.gnu.org; Wed, 03 Mar 2021 12:26:16 -0500 Received: from mail-wr1-f53.google.com ([209.85.221.53]:35412) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHVGI-0006A9-0C for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 12:26:15 -0500 Received: by mail-wr1-f53.google.com with SMTP id l12so24564074wry.2 for <46859@debbugs.gnu.org>; Wed, 03 Mar 2021 09:26:13 -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=gwg6tBHs4uTnZyo1Je+vMwC54F6SHSr/+fXn5nzZ31g=; b=k3NrpTTFZR7KAuXYAqzX3v5wX/p3g2bvzsrvkrseuNKHfE6k7080XoMX5F63YO1+wh aPAZ2FlAMYdCPLsJw7cYynRp4WsvGYauqT8Ha2GHQOlqAmmh6YdqPpaSIK294sfe+ZpE 3AodMxibXECuZ7OjbxWgue6G7N5eYZIb55UL4ZC49cu5nZFyI1n/j6EF9Finfxsypi3M tAqCPE/fDP+o8Q16JUniMm5JJEOGYGXjcHnNX4CeIN4GvAhU3hrNXMCMCBnsxjgh+oMD 7eSc/tyP51mHFbSCw1q1fq2ZoMUJbilxhvUn+D+FDXRtl6CiSBHuADawD7s99bSdQp5R 2Kbg== 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=gwg6tBHs4uTnZyo1Je+vMwC54F6SHSr/+fXn5nzZ31g=; b=gw8uzTjap/X0jGoee09g+VyagH4StizjfBqINYNEHkKcIX715vUZtLTwhT8uqoRbRd XDrPH1QRGcGYEe2/377uVWOn2U1InEgsI0agkKgVxdbqu7IQyBdGC+fAaIK/cHcooaGS /LF/VChn8PB/V3Do2ASBzd+9vxjb9h1eyWP9x1A8Ivj5FbLzrlRGrP5mIAgyriHnzUsN 1KDUjD5g8O06VR7dSDEpN/45EcZ/XVEzAqd0+eMx4ZVxmTeY7q+YFj+rohPE6aDhe1nr G0butgRXgAuZVS4LRCCytzZVMlejwRu41rUC0ZULkHtx1ibdbIyc3zHbd8ox4xf9+m0v 7C0A== X-Gm-Message-State: AOAM5322nBEC3+sI7zi0efCpe8vMxkeB+pBl/vrh0jpEtLUgFUXrAjqh qIgiLC8/fCuWcP50kZ++7B918vwt3gg= X-Google-Smtp-Source: ABdhPJzv+g24NO/VyQCNwWLaK5v0fR3rdMNyAUHaBuqRQeuNBkImkE+2ILxo4rFZHtt09alrEqiP+w== X-Received: by 2002:a5d:4587:: with SMTP id p7mr14477004wrq.205.1614792368106; Wed, 03 Mar 2021 09:26:08 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id e1sm34663728wrd.44.2021.03.03.09.26.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Mar 2021 09:26:06 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Gregory Heytings References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> From: Dmitry Gutov Message-ID: Date: Wed, 3 Mar 2021 19:26:03 +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: <4119ea30558f1e4145b0@heytings.org> 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: 46859 Cc: 46859@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 03.03.2021 19:11, Gregory Heytings wrote: > I wrote too fast.  In fact you can get the column number with GNU grep > without parsing the original line: > > grep -nb -oE '.{0,100}PATTERN.{0,100}' This outputs byte offset from the beginning of the file, doesn't it? Which will require at least reading the file into memory to convert. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 12:29:47 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 17:29:47 +0000 Received: from localhost ([127.0.0.1]:56899 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHVJj-0006FQ-7l for submit@debbugs.gnu.org; Wed, 03 Mar 2021 12:29:47 -0500 Received: from mail-wm1-f41.google.com ([209.85.128.41]:34751) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHVJf-0006FB-HW for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 12:29:46 -0500 Received: by mail-wm1-f41.google.com with SMTP id o7-20020a05600c4fc7b029010a0247d5f0so3242341wmq.1 for <46859@debbugs.gnu.org>; Wed, 03 Mar 2021 09:29:43 -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=p5HHyvSY4NXucIrogzqiI8el4iqtNQ6JrcfqERBFFhQ=; b=JSNwhberAGxuPUeZJPCCuqRDCQFGDBaqMO6mlu3W30UeyTe9KkTRSFn+Ssc2FLXkaN +k86QZvY5G04F10PmRd3U7Vrwe65ZV/CQrcfSrRe5ZTkguKjFC7/aP2EbVhAlXl9TbfF BkcNg2pGf20VaNDB601zPHheK6Xyvcl8aZ2Lcgy8DZ5HTz28O6T7PsN3OX/uabzf36BX XmSeXNagXF/l56EQpqv5slIgkSLmy8b6zogAOEDmG77VLb4BvCEzDiL9Adk2v7E9GfYv I3iCTgkO80uuswO5mCXeSDnCULNGGLvPJfeSv0vmaaeYGzX+B8W9HuI0Z7GrsNKTkvRh YZJg== 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=p5HHyvSY4NXucIrogzqiI8el4iqtNQ6JrcfqERBFFhQ=; b=lF/gDMCEhQSMIa4Lm5yhWgjL5ZFDKeyElMr023de83qh8Nj6+PoqBxCRNfpcXMTEed 0TG4BLAeDjWjt+CAmuWxNF3Nh4HeZRn9rOoHFHa+l+a+Ht64N1gRhoUWUFNJJu/IQK7x G1Wi9Xi7rkyDvOzmOmQXT+tr4w9W2KiRIPGtX7qXqJUwJ12sR51+elkbQPuQ8Ptta5KK Z92kLImVgHiqoqLu6qswn+rhay1PWc0LtXBAyNwHPKnAxtPHTcVuajFiSYFxISCngSvt 15KD+/csAAj2vv5gIuk+/K5lrjvNZ+On363Kdy7NW9MU7J8HlZPxdQqIzVgBSoRty8h/ CTxQ== X-Gm-Message-State: AOAM533KWbNZDVFQxRhjxBcxJrIJjEMT8vAlXA7i1JdulMFjxCF2bVAE wopjuPk1mMNBcgpCMPhcNqPEz34Pe04= X-Google-Smtp-Source: ABdhPJz6QZUQCH4yAIwh2oXaGKXP8REl3ojJcWbxudvW1wAuSRaowmCZyC1qz35cUGyZOhNYK9k4gw== X-Received: by 2002:a05:600c:2282:: with SMTP id 2mr66369wmf.93.1614792577808; Wed, 03 Mar 2021 09:29:37 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id m10sm6367754wmh.13.2021.03.03.09.29.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Mar 2021 09:29:37 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Theodor Thornhill , juri@linkov.net, 46859@debbugs.gnu.org References: <87im69uzlt.fsf@mail.linkov.net> <25782781-4baa-5d44-99a1-2e57552ab3a0@yandex.ru> From: Dmitry Gutov Message-ID: <666564dc-0252-6bf5-04e1-58c9916cffbe@yandex.ru> Date: Wed, 3 Mar 2021 19:29: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: 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: 46859 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 03.03.2021 18:13, Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > This long line has 25 matches, so yeah, that takes some time. With your > hint here I tried another approach which yielded some nice results. Thank you. Could you also try this benchmark with an input string that has no more than, say, 3 matches in the big one-line file? Or maybe just 1. I'd like to compare the relative performance in such scenario, too. > However, only my patch actually renders the long file as a match in the output buffer. All the others seem to drop it altogether. IMO that is one point in favour of my approaches. Indeed. > In addition, we could add another defcustom for the xref--collect-matches-1 function, That can be done already by the user customizing xref-search-program-alist, I think. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 12:42:21 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 17:42:21 +0000 Received: from localhost ([127.0.0.1]:56916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHVVt-0006Yn-0U for submit@debbugs.gnu.org; Wed, 03 Mar 2021 12:42:21 -0500 Received: from heytings.org ([95.142.160.155]:41672) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHVVr-0006Yf-5Y for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 12:42:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1614793337; bh=RCHRnxPk7+omvb4/97UvIk1xoURPrSDYKJ4E+1F0PLo=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=ARwSF0BLOnPoMZdY6X9mPlIJJiYCB8eejhn1pj6SXKcNI9FCViKmMuVekrseSqpR2 uC930W6UTnHcf9oqdkRTpziFTqflw91WEyPqBk1/94OGzqIpqAwBI/6rzQIT0kwSYY OZv0XxzV2nlbE4UQKpd4UjZG3AlID74Q/vyGckeRJrJPMaa2h+AEhBUUUtVzzOmCa0 BAbOGuzb0jp3tnUsiVQM1WDyDU/srSaRi8n9MkxHu2NZYoPI06+nKYj+OyqYT9mkvG jUSFib6iG2lcVId5BP66zs/k7Nir2WY58qxydZuFOfqsdaYl/FXFvEnZgnncIQyQjS 9SwSN28YCVduw== Date: Wed, 03 Mar 2021 17:42:17 +0000 From: Gregory Heytings To: Dmitry Gutov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: Message-ID: <4119ea30555e80bdcf7e@heytings.org> References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="fDXorRHs7h" Content-ID: <4119ea30553ac6192247@heytings.org> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) --fDXorRHs7h Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-ID: <4119ea305512c14d3e0a@heytings.org> >> I wrote too fast.=C2=A0 In fact you can get the column number with GNU g= rep=20 >> without parsing the original line: >>=20 >> grep -nb -oE '.{0,100}PATTERN.{0,100}' > > This outputs byte offset from the beginning of the file, doesn't it? > Yes. You get, for each match: the line number (from the beginning of the= =20 file), the byte offset (from the beginning of the file) of the first=20 displayed character, and the context of the match. > > Which will require at least reading the file into memory to convert. > I don't understand what you mean by that, but it seems to me that in any=20 case it's much more efficient than parsing the output of grep with Elisp. And you can easily get the byte offset of each beginning of line with=20 "grep -nbo '^.'", so calculating the byte offset from the beginning of the= =20 line is easy. --fDXorRHs7h-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 14:14:19 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 19:14:19 +0000 Received: from localhost ([127.0.0.1]:57001 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHWws-0000XR-Rm for submit@debbugs.gnu.org; Wed, 03 Mar 2021 14:14:19 -0500 Received: from mail-wr1-f51.google.com ([209.85.221.51]:41692) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHWwm-0000X7-II for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 14:14:16 -0500 Received: by mail-wr1-f51.google.com with SMTP id f12so21125343wrx.8 for <46859@debbugs.gnu.org>; Wed, 03 Mar 2021 11:14:12 -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=LHPBk0XCfCXkEhAVCSvA7tVLzIRQ+NAnHhub+PslT+A=; b=nWcQxORZjjXTeClW8PZJ9N9J+Ng2JnoXmsuwtgS2hCxs0bdGlnEXAJOC4/Yd6U6u1H UF01v2izvUKUpHBuiaZ7+Knf5e7rbo8F2LsSSNyWpIS61AO5fj9IiEY0e0HWdSiwIRD1 k9ihqCXt2YUvFTdYT59sjBpxK50xkgvxJ9RK9Y2AF1sf5O8r7rKlvSUXiiqGSxQvhLwV UwA/yfnXwBZAGhVBucTAqcIO+Pd1Bxzdy9inVToJgMm/0aJu46Auf0bV/f36eft+UTHK ieL+6bGzhVbkPILUeRMaQzcHQEr3zcofKARWx2BdF3iViCAxVoAUnr3WhTZ4KEEkLqMI MGJQ== 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=LHPBk0XCfCXkEhAVCSvA7tVLzIRQ+NAnHhub+PslT+A=; b=j2g9t2TaN0lYzt4DW0WfVkZaYHiNFKqoE1Cfkc8xZJubmPkvjCyNskxDW4oqdf4imD +8yY0r6f5UuwwkrUWQ53sHMJDtd3isGCC1BiN7iv7KfthQtWgBhmq8//44yBvDNXE8Ou ZQ7GEtB/kp+FynimTLdevndoc2zVYXatk7r/Dm1HhTMV88vMTy+fsoqX4XhQ1mD6ZdGA nDzR3GSfVuF5L6+N/Lhx6pLmYpoDxZgPL6ejJiUcPKHtIXO0LHxwijKA5mjTQMybl+mO dpLCr6hopPH8Zix6GnnrjPzE4KhhFMYVhYO3H44VvvNPwF33ZszZmd8jxF1QUGZfC/qG s64A== X-Gm-Message-State: AOAM533SCENsHq7qqsokU62k5uRCiGBIU4CjnSqZCm6CIKZqjmb3094k 823/NNO79LhWNc2vlnrAgZNCuR7GDQM= X-Google-Smtp-Source: ABdhPJxoWoua+c2vh7tTYGcVZUTYzHNUaxXAZePebBPJouEfCY4eBfqzhQjo0aCFcMEs7DrZUyx+EA== X-Received: by 2002:adf:e7cf:: with SMTP id e15mr208803wrn.346.1614798846807; Wed, 03 Mar 2021 11:14:06 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id k4sm43258017wrd.9.2021.03.03.11.14.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Mar 2021 11:14:06 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Gregory Heytings References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> From: Dmitry Gutov Message-ID: <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> Date: Wed, 3 Mar 2021 21:14:02 +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: <4119ea30555e80bdcf7e@heytings.org> 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: 46859 Cc: 46859@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 03.03.2021 19:42, Gregory Heytings wrote: > >>> I wrote too fast.  In fact you can get the column number with GNU >>> grep without parsing the original line: >>> >>> grep -nb -oE '.{0,100}PATTERN.{0,100}' >> >> This outputs byte offset from the beginning of the file, doesn't it? >> > > Yes.  You get, for each match: the line number (from the beginning of > the file), the byte offset (from the beginning of the file) of the first > displayed character, and the context of the match. OK, so we get the byte offset, but not the length of the match (which we'll also need later, for purposes such as highlighting and replacement). And what happens if there are several matches on the same line? We need columns for all of them. >> Which will require at least reading the file into memory to convert. >> > > I don't understand what you mean by that, but it seems to me that in any > case it's much more efficient than parsing the output of grep with Elisp. We currently don't visit the file buffer if it's not already visited, parsing the line in a temp buffer instead. That approach resulted in a nice perf improvement. > And you can easily get the byte offset of each beginning of line with > "grep -nbo '^.'", so calculating the byte offset from the beginning of > the line is easy. Do you mean to suggest we call grep one more time for each matching line? From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 14:34:35 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 19:34:35 +0000 Received: from localhost ([127.0.0.1]:57032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHXGU-00039u-Op for submit@debbugs.gnu.org; Wed, 03 Mar 2021 14:34:34 -0500 Received: from heytings.org ([95.142.160.155]:41796) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHXGS-00039l-3j for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 14:34:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1614800071; bh=1ClAw3RPSUscBSP7kAeCdHcqgKQyynIyTdjzHZclfCg=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=sf6h9AjJRBJlqIkWETzgpj6vTRwz1d0gwYhyXB6H5gwjlOta4WXnK52b45GyIofAQ 2Q2SZoVLGX2SIm198271v2PDloKWXPNGVKNUN8Esjvh8SV47HdRuE1k8XVCBQkqREh N5kDq1EbO3yN2rTMcBM0lZZj+zEz5UHLZNQEyqzC/QQA0Yk+2c7aAybGXzvGAdDiZf APSh3E3ZZubjzMVs3Y5D0Jbek74d/JVOwKJKCMfxkDu3p7Vipte10qvJWXYq4D7st1 EedBdFcjNabFykYdaXe7z2hYoXdMTNnnBwQuTj3AYjfyQVFBJ1EiN+wGdfFeljeTew zx9GB8ZQ1jIQA== Date: Wed, 03 Mar 2021 19:34:30 +0000 From: Gregory Heytings To: Dmitry Gutov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> Message-ID: <4119ea30553e3f90ab8c@heytings.org> References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="G0L0IVQL72" Content-ID: <4119ea30550b7a3e6ebb@heytings.org> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) --G0L0IVQL72 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-ID: <4119ea305501a07f8b35@heytings.org> >> Yes.=C2=A0 You get, for each match: the line number (from the beginning = of=20 >> the file), the byte offset (from the beginning of the file) of the=20 >> first displayed character, and the context of the match. > > OK, so we get the byte offset, but not the length of the match (which=20 > we'll also need later, for purposes such as highlighting and=20 > replacement). And what happens if there are several matches on the same= =20 > line? We need columns for all of them. > I don't know exactly what you want to do, I initially chimed in this=20 conversation to react to Juri's "GNU grep has no option to truncate=20 output", to mention that GNU grep does have an option to do this; perhaps= =20 it doesn't do exactly what you want. I could be wrong, but I believe that adapting what you want to what GNU=20 grep provides will always be more efficient than the opposite. >> And you can easily get the byte offset of each beginning of line with=20 >> "grep -nbo '^.'", so calculating the byte offset from the beginning of= =20 >> the line is easy. > > Do you mean to suggest we call grep one more time for each matching=20 > line? > No, once for each file. "grep -nbo '^.' FILE" returns a "::" line for each line in FILE. With this you=20 can easily calculate the offset of a match on a given line. This will be= =20 more efficient than calculating the offset of a match by parsing each line= =20 with Elisp code. --G0L0IVQL72-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 14:54:51 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 19:54:51 +0000 Received: from localhost ([127.0.0.1]:57060 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHXa7-0003eR-36 for submit@debbugs.gnu.org; Wed, 03 Mar 2021 14:54:51 -0500 Received: from out1.migadu.com ([91.121.223.63]:33934) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHXa5-0003eI-CY for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 14:54:50 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Theodor Thornhill To: Dmitry Gutov , juri@linkov.net, 46859@debbugs.gnu.org Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: <666564dc-0252-6bf5-04e1-58c9916cffbe@yandex.ru> References: <87im69uzlt.fsf@mail.linkov.net> <25782781-4baa-5d44-99a1-2e57552ab3a0@yandex.ru> <666564dc-0252-6bf5-04e1-58c9916cffbe@yandex.ru> Date: Wed, 03 Mar 2021 20:54:46 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46859 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 (-) Hi again, >> I tried another approach which yielded some nice results. > > Thank you. > > Could you also try this benchmark with an input string that has no more > than, say, 3 matches in the big one-line file? Or maybe just 1. > > I'd like to compare the relative performance in such scenario, too. > Curiously, it doesn't seem to affect things much, neither for your patch or mine. >> However, only my patch actually renders the long file as a match in the > output buffer. All the others seem to drop it altogether. IMO that is > one point in favour of my approaches. > > Indeed. > >> In addition, we could add another >> defcustom for the xref--collect-matches-1 function, > > That can be done already by the user customizing > xref-search-program-alist, I think. Oh? How so? -- Theo From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 15:01:57 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 20:01:57 +0000 Received: from localhost ([127.0.0.1]:57072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHXgz-0003qT-5D for submit@debbugs.gnu.org; Wed, 03 Mar 2021 15:01:57 -0500 Received: from relay1-d.mail.gandi.net ([217.70.183.193]:64107) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHXgx-0003qE-4L for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 15:01:56 -0500 X-Originating-IP: 91.129.96.116 Received: from mail.gandi.net (m91-129-96-116.cust.tele2.ee [91.129.96.116]) (Authenticated sender: juri@linkov.net) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id A5D21240003; Wed, 3 Mar 2021 20:01:46 +0000 (UTC) From: Juri Linkov To: Gregory Heytings Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el Organization: LINKOV.NET References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> Date: Wed, 03 Mar 2021 21:52:22 +0200 In-Reply-To: <4119ea30553e3f90ab8c@heytings.org> (Gregory Heytings's message of "Wed, 03 Mar 2021 19:34:30 +0000") Message-ID: <87y2f42ex5.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: 46859 Cc: 46859@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 (-) >> OK, so we get the byte offset, but not the length of the match (which >> we'll also need later, for purposes such as highlighting and >> replacement). And what happens if there are several matches on the same >> line? We need columns for all of them. > > I don't know exactly what you want to do, I initially chimed in this > conversation to react to Juri's "GNU grep has no option to truncate > output", to mention that GNU grep does have an option to do this; perhaps > it doesn't do exactly what you want. By an option I meant a command line switch of GNU grep, not something that looks like a hack. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 15:02:00 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 20:02:00 +0000 Received: from localhost ([127.0.0.1]:57075 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHXh2-0003qj-Bh for submit@debbugs.gnu.org; Wed, 03 Mar 2021 15:02:00 -0500 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:50145) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHXh0-0003qJ-3S for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 15:01:58 -0500 X-Originating-IP: 91.129.96.116 Received: from mail.gandi.net (m91-129-96-116.cust.tele2.ee [91.129.96.116]) (Authenticated sender: juri@linkov.net) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 8736920002; Wed, 3 Mar 2021 20:01:50 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el Organization: LINKOV.NET References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> Date: Wed, 03 Mar 2021 21:59:39 +0200 In-Reply-To: <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> (Dmitry Gutov's message of "Wed, 3 Mar 2021 21:14:02 +0200") Message-ID: <875z282el0.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: 46859 Cc: Gregory Heytings , 46859@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 > We currently don't visit the file buffer if it's not already visited, > parsing the line in a temp buffer instead. That approach resulted in a nice > perf improvement. Reusing visited files is a nice feature, but still needs a fix. Test case: visit emacs/src/xdisp.c and type C-x p g expose_frame RET See that not all lines from xdisp.c have font-lock highlighting. After applying this patch, all xref output lines from xdisp.c have font-lock faces: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=xref-font-lock-ensure.patch diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index 18fdd963fb..6a5361f852 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -1691,7 +1701,10 @@ xref--collect-matches-1 (let* ((beg-column (- (match-beginning 0) line-beg)) (end-column (- (match-end 0) line-beg)) (loc (xref-make-file-location file line beg-column)) - (summary (buffer-substring line-beg line-end))) + (summary (progn + (unless syntax-needed + (font-lock-ensure line-beg line-end)) + (buffer-substring line-beg line-end)))) (add-face-text-property beg-column end-column 'xref-match t summary) (push (xref-make-match summary loc (- end-column beg-column)) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 15:30:24 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 20:30:24 +0000 Received: from localhost ([127.0.0.1]:57117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHY8V-0004Yp-SD for submit@debbugs.gnu.org; Wed, 03 Mar 2021 15:30:24 -0500 Received: from mail-wr1-f43.google.com ([209.85.221.43]:37527) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHY8S-0004YW-0l for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 15:30:21 -0500 Received: by mail-wr1-f43.google.com with SMTP id v15so25171583wrx.4 for <46859@debbugs.gnu.org>; Wed, 03 Mar 2021 12:30: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=Qq3hjv+4ektbFQU0agOXnnQlOMGgZ2l8alPISvd9GPU=; b=ks645ckew+Xxd/f0d2kVEImcFig6PV17cUpbiOl1FFRWeKNPEtoSErxG8AVIZhTPrf SULpEvtpDjsRPUs/gM6JlcBXVMlUGZ3Z9g1WJcauErana5mhIgF8eDoQ3K/4TbyGHi/A Xw+iamwkPYXYJF3qxVPH1sB7qD7JKOX7DdMMGNpU63OV7RMH6kYW0iscHoyfal12Qq7n Svo6sz0yBt9/cpeqJPJ3vZcslVBjAGlhVBcmkSW3/DveQK6kbv/bWJrcg8LhwWwAGcO/ DuIw2oE4rnu5jXCQdSzOOLxOeyl+h7jDbXDGkstAUJLfw1eeWo/xhfR6uuKyXTeRzacp zxZg== 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=Qq3hjv+4ektbFQU0agOXnnQlOMGgZ2l8alPISvd9GPU=; b=VJ3Mt1+yqCJe9T/wjsOMDsSYK7w9tlc4FP1NlLgAYnisuDLrFIrL5he7aZXTouN6Cp noaAwtvKKzTrW5UXQSdusINLWXqDXAFQP5vHI1FIFw/youPdCahWmvHnnTY9a8bdehqo FMjjk6POQG5ArvygspZXqHbFw7nhp402XKgx5esNmEF5HEV2RhfD7YkJKSLHKpqH77wP 3NFT0Tf9gOMOVjisJjI9e3CGAh+NfE5LHx387SrKpK1I64nO4TyeQ5ISuEqlLGuuy69a KMPJxB5HH7w5abXTJ9Swl7sM0HLolnyTER+IcU9Pdsa7VzVbW12c44JTcZF1Y+JmMwFv 0Mcg== X-Gm-Message-State: AOAM533eY69d1Y0GzKP9poTVsGxW32i6/8VCK8taUFjTSi114j3PwPDB u7TRPld0IfCLkNiJOWEkfl6Ig9QH4n8= X-Google-Smtp-Source: ABdhPJxdkPTIDr+cAS7TufFkkoUSloQykjyvryAZkNrQtKQqleoqRVPTg28RyNDGtGBb9I9grSpyvw== X-Received: by 2002:adf:f144:: with SMTP id y4mr436972wro.408.1614803414095; Wed, 03 Mar 2021 12:30:14 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id y18sm32592598wrq.61.2021.03.03.12.30.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Mar 2021 12:30:13 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Gregory Heytings References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> From: Dmitry Gutov Message-ID: <08b51962-6305-5188-0bea-b17b4139646c@yandex.ru> Date: Wed, 3 Mar 2021 22:30: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: <4119ea30553e3f90ab8c@heytings.org> 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: 46859 Cc: 46859@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 03.03.2021 21:34, Gregory Heytings wrote: > >>> Yes.  You get, for each match: the line number (from the beginning of >>> the file), the byte offset (from the beginning of the file) of the >>> first displayed character, and the context of the match. >> >> OK, so we get the byte offset, but not the length of the match (which >> we'll also need later, for purposes such as highlighting and >> replacement). And what happens if there are several matches on the >> same line? We need columns for all of them. >> > > I don't know exactly what you want to do, I initially chimed in this > conversation to react to Juri's "GNU grep has no option to truncate > output", to mention that GNU grep does have an option to do this; > perhaps it doesn't do exactly what you want. > > I could be wrong, but I believe that adapting what you want to what GNU > grep provides will always be more efficient than the opposite. That's the general principle I have tried to follow, but Grep has proved suboptimal for a number of purposes (matching one regexp to multiple lines among them). >>> And you can easily get the byte offset of each beginning of line with >>> "grep -nbo '^.'", so calculating the byte offset from the beginning >>> of the line is easy. >> >> Do you mean to suggest we call grep one more time for each matching line? >> > > No, once for each file.  "grep -nbo '^.' FILE" returns a ": of first char>:" line for each line in FILE.  With this you > can easily calculate the offset of a match on a given line.  This will > be more efficient than calculating the offset of a match by parsing each > line with Elisp code. That's still +1 Grep invocation per file, right? Can't say for sure, perhaps it will be more efficient than parsing in Lisp, but at least with Lisp I know that parsing 10-20 matches is fast (and, actually, it's fairly instantaneous with 1000s of matches, as long as we don't encounter pathological files where all contents reside on one line). With your approach we'll have to deal with interpreting Grep outputs which list every line in the searched files. This will almost certainly be slower in the case when there are only handful of matches. But benchmarks welcome. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 15:34:50 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 20:34:50 +0000 Received: from localhost ([127.0.0.1]:57121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHYCo-0004eo-Gc for submit@debbugs.gnu.org; Wed, 03 Mar 2021 15:34:50 -0500 Received: from heytings.org ([95.142.160.155]:41916) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHYCm-0004ef-J7 for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 15:34:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1614803687; bh=hHLq4PdAlUPHF+F3Su+JyOmofxi3ucjxH/KysFsWoVY=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=BRBObt1SxPGCkCtX2UWLH1h00EfnJlZXm2G6fguveXfvvyShoHebVKCi9Gat74Ogd HepAddHokMk4hnV4eA/QQkcTHuiiFQINmLyIwjQNT8EsXknHQZbgLTKw/8kPZwQXYo 7mDiLfEbpNjw1+DmdQNHLpBI2Ooi+4lclD1rh8UJVDWiyOpYApBuCn/Z+PSU46vP7l auc13cOinJwOtPhng2i9OXwvZKtol4nAMx+hBIHWlR48qeAa2NuCSmJb6A8ZBH1IOZ 9QHrqw5BwAIky8XyqrmDRQhqOB5Guf5vrvypEl11XSqr7LW4PNqlGBnAB/+VyhC/oX FW4o7mLwIbBlA== Date: Wed, 03 Mar 2021 20:34:46 +0000 From: Gregory Heytings To: Juri Linkov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: <87y2f42ex5.fsf@mail.linkov.net> Message-ID: <4119ea30552873ab9870@heytings.org> References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) >>> OK, so we get the byte offset, but not the length of the match (which >>> we'll also need later, for purposes such as highlighting and >>> replacement). And what happens if there are several matches on the >>> same line? We need columns for all of them. >> >> I don't know exactly what you want to do, I initially chimed in this >> conversation to react to Juri's "GNU grep has no option to truncate >> output", to mention that GNU grep does have an option to do this; >> perhaps it doesn't do exactly what you want. > > By an option I meant a command line switch of GNU grep, not something > that looks like a hack. > It's not a hack at all, it's a command line switch: -o. The amount of context, which defaults to zero, is given in the regexp instead of as an argument to the command line switch. This -o option has been present since GNU grep 2.5, twenty years ago. You can use it together with other options: grep -o PATTERN FILE prints the matches grep -no PATTERN FILE prints the matches and their line number grep -bo PATTERN FILE prints the matches and their offset grep -bo '.\{0,BEFORE\}PATTERN.\{0,AFTER\}' FILE prints the matches with a given BEFORE and AFTER context and so forth. And the -o option is supported by ripgrep, ag and ack, with almost the same syntax. It's perhaps not what you want, but at least to me it seems more powerful than ripgrep's -M option. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 16:07:06 2021 Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 21:07:06 +0000 Received: from localhost ([127.0.0.1]:57130 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHYi2-0005Pa-At for submit@debbugs.gnu.org; Wed, 03 Mar 2021 16:07:06 -0500 Received: from heytings.org ([95.142.160.155]:41952) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHYhx-0005P6-8h for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 16:07:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1614805620; bh=/yChIEvTGnrzUSgzHcqbW+RvzdPqkV0FusndRe/K0cA=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=p85ssnemBXkqBWEz6MtIviSraR45I1rm3N0z664Y23uNR5h4XU1i2xhygYHxIGEbo uOiCq0V8lXBp1T0P0Py2cn97AqnN4hZ85hCQSc9QvTHBlvqhqdUfIlSKudDqkhr2TX +G00O9MzAo43PaL1gyfSggsHvhomJQ/PSqw4ORLNTHegtB0dIi9ayORJSCP31cU1yR /u3sPm5Ru9MuWBofXZVnVv/DSuyma/myW1ZapyeERmvZOZWWDPRNiIo+9NAZDbRHYV bQ+LgjYCLA2k1Lvomc0l02tpZhQnCpmYn+P3ctRCJ9M9rPxQJbJyvjCf5ojeObTPp6 5XQRlcfv5A7lQ== Date: Wed, 03 Mar 2021 21:06:59 +0000 From: Gregory Heytings To: Dmitry Gutov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: <08b51962-6305-5188-0bea-b17b4139646c@yandex.ru> Message-ID: <4119ea3055bd6f6d2e91@heytings.org> References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <08b51962-6305-5188-0bea-b17b4139646c@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) > > With your approach we'll have to deal with interpreting Grep outputs > which list every line in the searched files. This will almost certainly > be slower in the case when there are only handful of matches. But > benchmarks welcome. > I don't know what you exactly need (I don't (yet?) use project), so I can't elaborate further or provide benchmarks alas. Could you perhaps tell me what you need? From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 21:50:59 2021 Received: (at 46859) by debbugs.gnu.org; 4 Mar 2021 02:50:59 +0000 Received: from localhost ([127.0.0.1]:57357 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHe4p-0000qO-Lh for submit@debbugs.gnu.org; Wed, 03 Mar 2021 21:50:59 -0500 Received: from mail-wr1-f51.google.com ([209.85.221.51]:33110) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHe4n-0000qC-TN for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 21:50:58 -0500 Received: by mail-wr1-f51.google.com with SMTP id 7so25956272wrz.0 for <46859@debbugs.gnu.org>; Wed, 03 Mar 2021 18:50:57 -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=1o+9TC4lGOQnoDyKqBvcv9yYIJLciesGKnw03Oni8yM=; b=gnMRmU7Br/FVhRbjWoTd+qNJ/WEnNwaouPrN+4SLbKYNXXJ+Sev7cxohDwxalHdftC mWeVxXd9UUrCWSjflC7MkJ0dfRWG8EShEOlxsJRo+tNH2Xq5d+0mH/h/daj3JxE8vN30 9mViTWNlvJEe2GqFL0Thl3jY0AbfeN88oBo8f/qOcWFRaCtX6eUbkf4ke5Lz0743SSPh GYaBR07Dn1+PfIfM0UdpBFSJFklIxgHNmCkwthUfX0ug/wDbRs0GAZkN2+oiup1m987C ZTUyT5BVkH3Lr8V1OvHds+aGUNQSP+Bke/XCUg8/6dZo6PVnGaUmuLGORRkUBSrujuVl 0wZQ== 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=1o+9TC4lGOQnoDyKqBvcv9yYIJLciesGKnw03Oni8yM=; b=dDWb9tqAOsh0D26m428erwIf2dx7P7hiS7RKi8JQEccXrphlCzlthKiuw2/2Vurj8X 8CIgPDwrczVVhTLfRXpx5LizGeDwHUkQAq/6qOLemJraDI5m7CktqhE4hqDOZ7rjHUPB YKERF+d3AQN50u2tvX95IvpfBq6Dkwmxmes3AWrqJyd2HBeY6wwNS4zDwspgquTBvjOk TfyrBEAZPTTwJ8XfnXJQQ0g5cc3KfbpBmtLGDboIISUTdRdDJlgahiu80KNEkp93Npqs gIjNQqSNb/4h+kkPvuuQlPkRdFgF4s5Aqi1jCVgPnrxyGnhgfkDb6MuKjkJklkKK+Idk VSiQ== X-Gm-Message-State: AOAM532Dj/5NHMTTbABR2HDmHel4aVlsmcAXLvC5JS8BU7QdwXVzUps3 B2fjQuBrzqKSgWperNH363oSKNscHVE= X-Google-Smtp-Source: ABdhPJym2SnkOueqvbdiSTt6g0PHQC8R4/JEAKr//Gz7dstBe5rjf+mmW/ksdIPU1HvTnEpung23JQ== X-Received: by 2002:a5d:42d2:: with SMTP id t18mr1605030wrr.258.1614826252004; Wed, 03 Mar 2021 18:50:52 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id d16sm34053119wrx.79.2021.03.03.18.50.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Mar 2021 18:50:51 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Juri Linkov References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <875z282el0.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <9d87da5b-e30e-149d-a467-a2c4c752a60e@yandex.ru> Date: Thu, 4 Mar 2021 04:50:48 +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: <875z282el0.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: 46859 Cc: Gregory Heytings , 46859@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 (/) Hi Juri, On 03.03.2021 21:59, Juri Linkov wrote: >> We currently don't visit the file buffer if it's not already visited, >> parsing the line in a temp buffer instead. That approach resulted in a nice >> perf improvement. > > Reusing visited files is a nice feature, but still needs a fix. > > Test case: visit emacs/src/xdisp.c and type > > C-x p g expose_frame RET > > See that not all lines from xdisp.c have font-lock highlighting. > After applying this patch, all xref output lines from xdisp.c > have font-lock faces: I thought about this, but applying font-lock rules is not exactly a trivial action. So I figured we better avoid it (and only call syntax-propertize when necessary) to get the best performance possible. Have you tried benchmarking with and without your patch? Particular case of interest: many files, each already visited, with 1 match in each of them. Or few matches. The opposite would be one file with many matches inside of it. This case should be relatively inexpensive for this patch, but it's worth measuring to compare too. P.S. The "(unless syntax-needed" guard in the proposed patch is not needed. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 03 22:36:36 2021 Received: (at 46859) by debbugs.gnu.org; 4 Mar 2021 03:36:36 +0000 Received: from localhost ([127.0.0.1]:57376 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHemx-00042t-P4 for submit@debbugs.gnu.org; Wed, 03 Mar 2021 22:36:35 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39390) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHemv-00042h-W9 for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 22:36:34 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51049) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHemp-0004eO-6i; Wed, 03 Mar 2021 22:36:27 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3603 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lHemo-0002sS-CL; Wed, 03 Mar 2021 22:36:27 -0500 Date: Thu, 04 Mar 2021 05:36:07 +0200 Message-Id: <83eegvk2u0.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings In-Reply-To: <4119ea30552873ab9870@heytings.org> (message from Gregory Heytings on Wed, 03 Mar 2021 20:34:46 +0000) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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: -1.7 (-) > Date: Wed, 03 Mar 2021 20:34:46 +0000 > From: Gregory Heytings > Cc: 46859@debbugs.gnu.org > > > By an option I meant a command line switch of GNU grep, not something > > that looks like a hack. > > It's not a hack at all, it's a command line switch: -o. The amount of > context, which defaults to zero, is given in the regexp instead of as an > argument to the command line switch. > > This -o option has been present since GNU grep 2.5, twenty years ago. > > You can use it together with other options: > > grep -o PATTERN FILE prints the matches > grep -no PATTERN FILE prints the matches and their line number > grep -bo PATTERN FILE prints the matches and their offset > grep -bo '.\{0,BEFORE\}PATTERN.\{0,AFTER\}' FILE prints the matches with a given BEFORE and AFTER context > > and so forth. > > And the -o option is supported by ripgrep, ag and ack, with almost the > same syntax. While you discuss all those possibilities, please be aware that byte offsets have one more problem: converting them to character offsets or columns might not be trivial, especially if the encoding of the file is not UTF-8. (Apologies if you already discussed this.) From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 04 04:19:54 2021 Received: (at 46859) by debbugs.gnu.org; 4 Mar 2021 09:19:54 +0000 Received: from localhost ([127.0.0.1]:57701 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHk9C-0004IB-0y for submit@debbugs.gnu.org; Thu, 04 Mar 2021 04:19:54 -0500 Received: from heytings.org ([95.142.160.155]:42570) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHk9A-0004I2-G9 for 46859@debbugs.gnu.org; Thu, 04 Mar 2021 04:19:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1614849591; bh=3G2IbMGriRgqPmrvFpLgEJ2og2yRSkUfKzPNXNJFGt8=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=L62LSL9mydmAAbVUrbq353+WSXENSArwzlaR4J3sXKROWR4TTIuHgWOeibnO+Arym lAQF86rVECNzq4/hoTeNzGCux5Wp0MqdHUNNbnzrHgLGbUSKFAZd7+/afiFNLAoI1R WOvJOJkqrN4FCkGAuR8NtuhS4o5GHOwc5c/ErrJf7rwnB2saML1BagDTkJ6eZrxPn8 Qbgt55kVnKte7M6raB4HBJRNxJ474c1RcNSE8YcpC/B6ZawuMFjyGaMG9UKiXTBUkJ TX0FNcmNNlkm4pJOdNeTgsBpOuLsxgYWQPEvhq0kfNg0PLek7cgWsrwI63S8iMl/qA dBIfHlMN8SzCg== Date: Thu, 04 Mar 2021 09:19:50 +0000 From: Gregory Heytings To: Eli Zaretskii Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: <83eegvk2u0.fsf@gnu.org> Message-ID: <9cff0f8894658f3b50c8@heytings.org> References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) > > While you discuss all those possibilities, please be aware that byte > offsets have one more problem: converting them to character offsets or > columns might not be trivial, especially if the encoding of the file is > not UTF-8. (Apologies if you already discussed this.) > We did not discuss this, thanks for pointing that out. Is this not easy to do with byte-to-position? What I would suggest is to use "grep -nbo '.\{0,50\}PATTERN.\{0,50\}'", to hide the byte position in the xref buffer, and when the user jumps to an occurrence to use something like (goto-char (byte-to-position (get-byte-position))). Does that make sense? From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 04 05:16:25 2021 Received: (at 46859) by debbugs.gnu.org; 4 Mar 2021 10:16:25 +0000 Received: from localhost ([127.0.0.1]:57775 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHl1s-0007lh-PD for submit@debbugs.gnu.org; Thu, 04 Mar 2021 05:16:24 -0500 Received: from relay12.mail.gandi.net ([217.70.178.232]:46963) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHl1r-0007lE-DX for 46859@debbugs.gnu.org; Thu, 04 Mar 2021 05:16:23 -0500 Received: from mail.gandi.net (m91-129-96-116.cust.tele2.ee [91.129.96.116]) (Authenticated sender: juri@linkov.net) by relay12.mail.gandi.net (Postfix) with ESMTPSA id E9D55200015; Thu, 4 Mar 2021 10:16:14 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el Organization: LINKOV.NET References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <875z282el0.fsf@mail.linkov.net> <9d87da5b-e30e-149d-a467-a2c4c752a60e@yandex.ru> Date: Thu, 04 Mar 2021 11:24:30 +0200 In-Reply-To: <9d87da5b-e30e-149d-a467-a2c4c752a60e@yandex.ru> (Dmitry Gutov's message of "Thu, 4 Mar 2021 04:50:48 +0200") Message-ID: <87czwf9sq9.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: 46859 Cc: Gregory Heytings , 46859@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 (-) >> Reusing visited files is a nice feature, but still needs a fix. >> Test case: visit emacs/src/xdisp.c and type >> C-x p g expose_frame RET >> See that not all lines from xdisp.c have font-lock highlighting. >> After applying this patch, all xref output lines from xdisp.c >> have font-lock faces: > > I thought about this, but applying font-lock rules is not exactly a trivial > action. So I figured we better avoid it (and only call syntax-propertize > when necessary) to get the best performance possible. > > Have you tried benchmarking with and without your patch? Particular case of > interest: many files, each already visited, with 1 match in each of > them. Or few matches. > > The opposite would be one file with many matches inside of it. This case > should be relatively inexpensive for this patch, but it's worth measuring > to compare too. > > P.S. The "(unless syntax-needed" guard in the proposed patch is not needed. ;; Without patch (benchmark-run 10 (project-find-regexp "expose_frame")) ;; (1.936206149 21 0.27307954999999995) ;; With patch without the "(unless syntax-needed" guard (benchmark-run 10 (project-find-regexp "expose_frame")) ;; (2.195018443 31 0.354854643) I don't know if extra font-locking is worth worse performance. But I took this idea for consistency from occur that uses 'font-lock-ensure' in 'occur-engine-line'. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 04 09:09:17 2021 Received: (at 46859) by debbugs.gnu.org; 4 Mar 2021 14:09:17 +0000 Received: from localhost ([127.0.0.1]:58186 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHofF-0005ay-ES for submit@debbugs.gnu.org; Thu, 04 Mar 2021 09:09:17 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHofB-0005aT-Km for 46859@debbugs.gnu.org; Thu, 04 Mar 2021 09:09:16 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60069) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHof6-0006WH-6a; Thu, 04 Mar 2021 09:09:08 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2479 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lHof5-0008A5-Mq; Thu, 04 Mar 2021 09:09:08 -0500 Date: Thu, 04 Mar 2021 16:08:49 +0200 Message-Id: <83y2f3huz2.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings In-Reply-To: <9cff0f8894658f3b50c8@heytings.org> (message from Gregory Heytings on Thu, 04 Mar 2021 09:19:50 +0000) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) > Date: Thu, 04 Mar 2021 09:19:50 +0000 > From: Gregory Heytings > cc: 46859@debbugs.gnu.org > > > While you discuss all those possibilities, please be aware that byte > > offsets have one more problem: converting them to character offsets or > > columns might not be trivial, especially if the encoding of the file is > > not UTF-8. (Apologies if you already discussed this.) > > > > We did not discuss this, thanks for pointing that out. > > Is this not easy to do with byte-to-position? No. byte-to-position works for text in an Emacs buffer, whereas we are talking about the text in its original file on disk. Unless that file is encoded in UTF-8, byte-to-position will give you wrong results. You need to use filepos-to-bufferpos, and you will need to specify the file's encoding. And it's relatively slow for non-UTF-8 encoded files. > What I would suggest is to use "grep -nbo '.\{0,50\}PATTERN.\{0,50\}'", to > hide the byte position in the xref buffer, and when the user jumps to an > occurrence to use something like (goto-char (byte-to-position > (get-byte-position))). Does that make sense? Yes, but see above about encodings other than UTF-8. For example, if the original file is in Latin-1, each character is 1 byte, but in an Emacs buffer non-ASCII Latin-1 characters will take 2 bytes. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 04 09:39:28 2021 Received: (at 46859) by debbugs.gnu.org; 4 Mar 2021 14:39:28 +0000 Received: from localhost ([127.0.0.1]:58236 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHp8S-0006NP-9I for submit@debbugs.gnu.org; Thu, 04 Mar 2021 09:39:28 -0500 Received: from heytings.org ([95.142.160.155]:42938) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHp8O-0006NF-Ts for 46859@debbugs.gnu.org; Thu, 04 Mar 2021 09:39:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1614868763; bh=ItK91PCkD14HTyk9TK/H7golE3Kn2so/if0FI+QnepU=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=HccmgNIiL2b+tGqd12p1tunoMKKuNWY5Wf8QkNqNyPuPDwLJSw9fGeGHHQ6xSGUbd CHtYo4hHvCGERQI8FU4oJ9/vMhyIgBR/736rcD+vyO6XsBWmKIWooRq0HNxJNU/aUm YKUBFiW4bO41NrfbGe9V2kn/mCwHQc/9IpCZ5LBfNR6lJzFXsPyajPE6co07yo7q6W 4u2BCApe4/LB3Rl1siNCC2iJeQjVerzPuPIJijJt7B0FPm/7W3RuuxDZGKCnJUd9UK jKK+lQopzVCuJpJJhusWqQqaoL7Ql7THCwYrt4ch00lVPBjz64J5I4JGXM1Se4M2eo qcRBZfJZdyJtw== Date: Thu, 04 Mar 2021 14:39:23 +0000 From: Gregory Heytings To: Eli Zaretskii Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: <83y2f3huz2.fsf@gnu.org> Message-ID: <9cff0f88942d4103c685@heytings.org> References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) > > No. byte-to-position works for text in an Emacs buffer, whereas we are > talking about the text in its original file on disk. Unless that file > is encoded in UTF-8, byte-to-position will give you wrong results. You > need to use filepos-to-bufferpos, and you will need to specify the > file's encoding. And it's relatively slow for non-UTF-8 encoded files. > Thank you, I was not aware of that subtlety. But you provide the solution: when an xref is followed, the file is opened in a buffer, at which point buffer-file-coding-system is set. So it seems that it suffices to do (goto-char (filepos-to-bufferpos (get-byte-position))). I just did a filepos-to-bufferpos for one of the last bytes of a 6 MB Latin-1 file, and it took only ~2 ms. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 04 10:13:46 2021 Received: (at 46859) by debbugs.gnu.org; 4 Mar 2021 15:13:46 +0000 Received: from localhost ([127.0.0.1]:59941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHpfe-0007cg-9F for submit@debbugs.gnu.org; Thu, 04 Mar 2021 10:13:46 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49342) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHpfb-0007cT-HJ for 46859@debbugs.gnu.org; Thu, 04 Mar 2021 10:13:44 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33728) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHpfW-0001tC-6t; Thu, 04 Mar 2021 10:13:38 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2448 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lHpfV-0004Uj-A4; Thu, 04 Mar 2021 10:13:37 -0500 Date: Thu, 04 Mar 2021 17:13:20 +0200 Message-Id: <83mtvjhrzj.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings In-Reply-To: <9cff0f88942d4103c685@heytings.org> (message from Gregory Heytings on Thu, 04 Mar 2021 14:39:23 +0000) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) > Date: Thu, 04 Mar 2021 14:39:23 +0000 > From: Gregory Heytings > cc: 46859@debbugs.gnu.org > > But you provide the solution: when an xref is followed, the file is opened > in a buffer, at which point buffer-file-coding-system is set. So it seems > that it suffices to do (goto-char (filepos-to-bufferpos > (get-byte-position))). Yes. But it can be slow. > I just did a filepos-to-bufferpos for one of the last bytes of a 6 MB > Latin-1 file, and it took only ~2 ms. Which value of QUALITY did you use? Also, what happens with multibyte encodings that are not UTF-8, like iso-2022, for example? From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 04 11:47:34 2021 Received: (at 46859) by debbugs.gnu.org; 4 Mar 2021 16:47:34 +0000 Received: from localhost ([127.0.0.1]:60013 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHr8Q-0001Uu-HW for submit@debbugs.gnu.org; Thu, 04 Mar 2021 11:47:34 -0500 Received: from heytings.org ([95.142.160.155]:43082) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHr8O-0001Um-Jd for 46859@debbugs.gnu.org; Thu, 04 Mar 2021 11:47:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1614876451; bh=v5FFdOTvUizGiu0aNKqUQbkDZKvKIyhlk6Da4xHu+W8=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=rCa3sXzvRqYOpKw8qIurc9Nj+tKDaVrV4Sy305FjEeKILHg1qqOBRDMwiPjP4G5yd NF6dw4UpK+yxr1e2EUqV4r50jdhaKEGr1FJbG+YoSD/bm0cHubXFMjN5uqfoAEuU6T JHx8iOHlY9zr+bM1MqulyAwcHcWY8tUzTm4DVaSCxp6WbIGK14RQE0Bo45BJSBpI48 7fJWAXOwhs1oHkOMgrEQYbI6RAdTAd7lTY/h+S/lYM/t1X46zFCuE7ZFU+RwL/aVqS SPbs8SrnGoyA0Ch0zYE7RPPVKzjAyZ+CLgoqPu2BRCJN+mA9R8QoQKRPteVi6tMDoR nh82b7ULgl5Gg== Date: Thu, 04 Mar 2021 16:47:30 +0000 From: Gregory Heytings To: Eli Zaretskii Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: <83mtvjhrzj.fsf@gnu.org> Message-ID: <9cff0f889435d8d03313@heytings.org> References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> <83mtvjhrzj.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) >> But you provide the solution: when an xref is followed, the file is >> opened in a buffer, at which point buffer-file-coding-system is set. >> So it seems that it suffices to do (goto-char (filepos-to-bufferpos >> (get-byte-position))). > > Yes. But it can be slow. > Can it become so slow that it would have an impact on user experience? filepos-to-bufferpos would be called only when the xref link is followed, so I guess that even a 0.1 or 0.2 second delay should be okay. >> I just did a filepos-to-bufferpos for one of the last bytes of a 6 MB >> Latin-1 file, and it took only ~2 ms. > > Which value of QUALITY did you use? > I just tried again on a 25 MB Latin-1 file, on one of the last bytes it took ~13 ms without specifying a quality. I tried with nil, 'approximate and 'best, but do not see any difference, the result with benchmark-run is always ~13 ms. > > Also, what happens with multibyte encodings that are not UTF-8, like > iso-2022, for example? > Well, the Latin-1 file is already different from UTF-8. I don't know anything about ISO-2022, but tried with a 25 MB file, created with iconv, which Emacs recognizes as an iso-2022-7bit-dos one. In that case filepos-to-bufferpos does not work at all, with 'approximate you get a position that is about 2 million characters away from the correct one, and with 'best or nil you get nil... From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 04 12:13:43 2021 Received: (at 46859) by debbugs.gnu.org; 4 Mar 2021 17:13:43 +0000 Received: from localhost ([127.0.0.1]:60055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHrXi-000287-RC for submit@debbugs.gnu.org; Thu, 04 Mar 2021 12:13:43 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57506) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHrXh-00027u-CR for 46859@debbugs.gnu.org; Thu, 04 Mar 2021 12:13:41 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37131) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHrXa-0008F6-Em; Thu, 04 Mar 2021 12:13:35 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3359 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lHrXZ-0003yA-Iq; Thu, 04 Mar 2021 12:13:34 -0500 Date: Thu, 04 Mar 2021 19:13:16 +0200 Message-Id: <834khq266r.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings In-Reply-To: <9cff0f889435d8d03313@heytings.org> (message from Gregory Heytings on Thu, 04 Mar 2021 16:47:30 +0000) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> <83mtvjhrzj.fsf@gnu.org> <9cff0f889435d8d03313@heytings.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) > Date: Thu, 04 Mar 2021 16:47:30 +0000 > From: Gregory Heytings > cc: 46859@debbugs.gnu.org > > > Yes. But it can be slow. > > Can it become so slow that it would have an impact on user experience? I don't know, Grep is a somewhat special application. > filepos-to-bufferpos would be called only when the xref link is followed, > so I guess that even a 0.1 or 0.2 second delay should be okay. Yes, 0.1 sec is definitely okay. > I just tried again on a 25 MB Latin-1 file, on one of the last bytes it > took ~13 ms without specifying a quality. I tried with nil, 'approximate > and 'best, but do not see any difference, the result with benchmark-run is > always ~13 ms. > > > Also, what happens with multibyte encodings that are not UTF-8, like > > iso-2022, for example? > > Well, the Latin-1 file is already different from UTF-8. AFAIR, with single-byte encoding we take a shortcut there. > I don't know anything about ISO-2022, but tried with a 25 MB file, created > with iconv, which Emacs recognizes as an iso-2022-7bit-dos one. In that > case filepos-to-bufferpos does not work at all, with 'approximate you get > a position that is about 2 million characters away from the correct one, > and with 'best or nil you get nil... Not 'best, 'exact. Did you try 'exact? It should have worked, barring any bugs. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 04 12:20:44 2021 Received: (at 46859) by debbugs.gnu.org; 4 Mar 2021 17:20:44 +0000 Received: from localhost ([127.0.0.1]:60073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHreW-0002LD-Aa for submit@debbugs.gnu.org; Thu, 04 Mar 2021 12:20:44 -0500 Received: from mail-wm1-f53.google.com ([209.85.128.53]:40637) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHreT-0002Kl-Pv for 46859@debbugs.gnu.org; Thu, 04 Mar 2021 12:20:43 -0500 Received: by mail-wm1-f53.google.com with SMTP id o2so9934888wme.5 for <46859@debbugs.gnu.org>; Thu, 04 Mar 2021 09:20:41 -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=cb0VyegjtcF63aVgMLeVrj3R/MLdB2alG/Sl7CEEHuQ=; b=TohaYDLQuJIsiSxNQmdTe2Oig6q/JgZRXJg/AFqcF1Df6XnniAXRSpBlefW+3tDC7g f2S1rtg88M39psLAkDvMI+YhFQuVU+o1CzVtst3XZk6RllYos5BsZVicWZegazul9MxT CPZ6ZmDu0DqdT+PF1XeY9FkgMuOIQh/9638EAKPgoGc54g3H7zscKK204Z7eRaxlmdFS EDGrIjSLhRZYignDKSQ4xyYmZwhOEFef1idibmZJGty/JbNCWRBdb0+c3UZF6hCqWuGp BMutag5l3uA/zNBt9yohMCL3Ag8eqJj+JEBVaWvp2F4em6yK6YqL/4mC+YugYtcKWBOH xXkA== 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=cb0VyegjtcF63aVgMLeVrj3R/MLdB2alG/Sl7CEEHuQ=; b=pxVEi3bfpaOAiBwR9yv9zru9OhvULtkFRK//laJXyBZbITIfRKr9WsxwwpZlZaSwHS /5PzUv5RHSUvaLUVNXtRbo0J3EJLEfnopFPZ81QPrnRpFzNdov580upAftFp/NoDF0ib qrjEWpjjZpqYDH8g89ipffyZuqTn5CCv8BT5ysIDjYTm0Sa5hyFntj+ILkmliCXNrZMe s5NOCPF2l7KNnP+7Gw6AqAdPP0GeOkmK84GcVFTm1dXOPewgBcjv2UGx8sYhdDaCoGuB zKFkSFXzzAWD6sdRrUoz5d2iFQkwwU6OrukLM9VwVQPM2utqRwaDw+Jc701UWtR8SuOL XolQ== X-Gm-Message-State: AOAM531NsqG5fX5Tl5yrXBEyS2XCnGLr0uiLoW2lNzSdhDIjbMUEp1Tj 75ErN1NykQJ8DljmYQ9VNKHzL+umYjU= X-Google-Smtp-Source: ABdhPJzTKu6WAr/uVY8Sg71tGcD1lWCIYPqpjGnTs2uAOo8lfKd1PqeIU2FGJ0M2/EmqW/H66c+AiQ== X-Received: by 2002:a1c:a7d3:: with SMTP id q202mr4927113wme.93.1614878436224; Thu, 04 Mar 2021 09:20:36 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id s3sm18173800wrt.93.2021.03.04.09.20.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Mar 2021 09:20:35 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Juri Linkov References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <875z282el0.fsf@mail.linkov.net> <9d87da5b-e30e-149d-a467-a2c4c752a60e@yandex.ru> <87czwf9sq9.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Thu, 4 Mar 2021 19:20:32 +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: <87czwf9sq9.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: 46859 Cc: Gregory Heytings , 46859@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 04.03.2021 11:24, Juri Linkov wrote: > ;; Without patch > (benchmark-run 10 (project-find-regexp "expose_frame")) ;; (1.936206149 21 0.27307954999999995) > > ;; With patch without the "(unless syntax-needed" guard > (benchmark-run 10 (project-find-regexp "expose_frame")) ;; (2.195018443 31 0.354854643) Thanks. Note that running the benchmark 10 times means that on the last 9 iterations the lines are already fontified. The cost of doing this should be apparent with more search hits, though. For example: (benchmark-run 1 (project-find-regexp "expose")) > I don't know if extra font-locking is worth worse performance. > But I took this idea for consistency from occur that uses > 'font-lock-ensure' in 'occur-engine-line'. If you're sure you want this behavior, we can make it a user option. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 04 12:35:47 2021 Received: (at 46859) by debbugs.gnu.org; 4 Mar 2021 17:35:47 +0000 Received: from localhost ([127.0.0.1]:60090 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHrt4-0002jK-Ci for submit@debbugs.gnu.org; Thu, 04 Mar 2021 12:35:47 -0500 Received: from heytings.org ([95.142.160.155]:43156) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHrt2-0002jA-20 for 46859@debbugs.gnu.org; Thu, 04 Mar 2021 12:35:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1614879342; bh=L1fJEMwGDYo8svqrGEfunJIJowbFsPgkIIVUuDwmzGU=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=WKLdv39ykaUjzVj35Hh3XyrdgQ0YwBVdATEsOJNGCsOVIYyuJux9q75LO7brC6+VL LZkKxhYkIhDSAZUwKvIHCz1BOP8wy/rKCS6gveZvmpFrxvcgh/yhHEOliwnQl6x0y+ fJ+sfFMPr1dOwYEKPq3N3jbopKnTKsAahe1F9EIuysTjTtAFL4l8e06Bo2Vr2r99EM /tx0NZOVPunhBuRVODrqwQmGv9oI7GVvwye2NEzr6eCvQn0KETgMLGfV2Be1xGzVJM c8DVpuElFQnM8wUmikXYxDOLPRPCs92VdiMvuF79c4MnPS/wS7TPqHTC1RbYDcBjDM xaaP7p1zAVXww== Date: Thu, 04 Mar 2021 17:35:42 +0000 From: Gregory Heytings To: Eli Zaretskii Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: <834khq266r.fsf@gnu.org> Message-ID: <9cff0f8894ab45713d12@heytings.org> References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> <83mtvjhrzj.fsf@gnu.org> <9cff0f889435d8d03313@heytings.org> <834khq266r.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) >> I don't know anything about ISO-2022, but tried with a 25 MB file, >> created with iconv, which Emacs recognizes as an iso-2022-7bit-dos one. >> In that case filepos-to-bufferpos does not work at all, with >> 'approximate you get a position that is about 2 million characters away >> from the correct one, and with 'best or nil you get nil... > > Not 'best, 'exact. Did you try 'exact? It should have worked, barring > any bugs. > Sorry for mixing things up. Just tried 'exact, it works, it's slow (but not horribly slow: 1.2 seconds on that 25 MB file), but it doesn't give the correct answer alas, it's about ~1000 characters away from the correct position. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 04 13:29:03 2021 Received: (at 46859) by debbugs.gnu.org; 4 Mar 2021 18:29:03 +0000 Received: from localhost ([127.0.0.1]:60188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHsid-00042k-4n for submit@debbugs.gnu.org; Thu, 04 Mar 2021 13:29:03 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44702) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHsia-00042G-55 for 46859@debbugs.gnu.org; Thu, 04 Mar 2021 13:29:01 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38496) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHsiT-0000sB-AL; Thu, 04 Mar 2021 13:28:54 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3993 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lHsiR-00039n-IL; Thu, 04 Mar 2021 13:28:52 -0500 Date: Thu, 04 Mar 2021 20:28:32 +0200 Message-Id: <83zgzizsbz.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings In-Reply-To: <9cff0f8894ab45713d12@heytings.org> (message from Gregory Heytings on Thu, 04 Mar 2021 17:35:42 +0000) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> <83mtvjhrzj.fsf@gnu.org> <9cff0f889435d8d03313@heytings.org> <834khq266r.fsf@gnu.org> <9cff0f8894ab45713d12@heytings.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) > Date: Thu, 04 Mar 2021 17:35:42 +0000 > From: Gregory Heytings > cc: 46859@debbugs.gnu.org > > > Not 'best, 'exact. Did you try 'exact? It should have worked, barring > > any bugs. > > Sorry for mixing things up. Just tried 'exact, it works, it's slow (but > not horribly slow: 1.2 seconds on that 25 MB file), but it doesn't give > the correct answer alas, it's about ~1000 characters away from the correct > position. Sounds like a bug, I'd appreciate a bug report with the details (including the file, if you can share it). Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 04 13:44:40 2021 Received: (at 46859) by debbugs.gnu.org; 4 Mar 2021 18:44:40 +0000 Received: from localhost ([127.0.0.1]:60222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHsxk-0004RE-ET for submit@debbugs.gnu.org; Thu, 04 Mar 2021 13:44:40 -0500 Received: from relay2-d.mail.gandi.net ([217.70.183.194]:53787) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHsxi-0004Qc-9H for 46859@debbugs.gnu.org; Thu, 04 Mar 2021 13:44:38 -0500 X-Originating-IP: 91.129.96.116 Received: from mail.gandi.net (m91-129-96-116.cust.tele2.ee [91.129.96.116]) (Authenticated sender: juri@linkov.net) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 7BC6A4000D; Thu, 4 Mar 2021 18:44:30 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el Organization: LINKOV.NET References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <875z282el0.fsf@mail.linkov.net> <9d87da5b-e30e-149d-a467-a2c4c752a60e@yandex.ru> <87czwf9sq9.fsf@mail.linkov.net> Date: Thu, 04 Mar 2021 19:56:28 +0200 In-Reply-To: (Dmitry Gutov's message of "Thu, 4 Mar 2021 19:20:32 +0200") Message-ID: <87mtviajlf.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: 46859 Cc: Gregory Heytings , 46859@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 know if extra font-locking is worth worse performance. >> But I took this idea for consistency from occur that uses >> 'font-lock-ensure' in 'occur-engine-line'. > > If you're sure you want this behavior, we can make it a user option. I'm not sure because most hits are not fontified anyway when not all files are visited especially in a large codebase. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 04 13:58:01 2021 Received: (at 46859) by debbugs.gnu.org; 4 Mar 2021 18:58:01 +0000 Received: from localhost ([127.0.0.1]:60240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHtAf-0004lH-C2 for submit@debbugs.gnu.org; Thu, 04 Mar 2021 13:58:01 -0500 Received: from mail-wm1-f53.google.com ([209.85.128.53]:37631) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHtAb-0004l2-BT for 46859@debbugs.gnu.org; Thu, 04 Mar 2021 13:57:59 -0500 Received: by mail-wm1-f53.google.com with SMTP id m1so10716727wml.2 for <46859@debbugs.gnu.org>; Thu, 04 Mar 2021 10:57:57 -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=XihY01nJqBrnFUvr1iVd64M7+xHJ37AZNnm12AkE76g=; b=S485ZzA78RbJbAvh5pFz1BgoKz57i8BL1Gaxl+aq+mfe3Nqwq4LoKOLeBB0GP4rcjj GL8EWwUEIs/qgxF5PPlJ1JFuk9pNVyg6pQrkQ2XuSLhNzb0wh71DcmXkenIdyaUiOBTs fjlT/25EarUzQPw7xRcyTmaSaPCtP4dh0oimPlrTcaKJ8FfsBEn+ALPDd1nJSFqtEq4b JrZTTDj7c4b7tzGxfkbEpRIrfL3dCkEG37MO3txAKTkx5LSjPB58D8ZVTXVPKAowcVr5 xpWjwAk8KHmuGrj06sI5sSnhSF1MPJSb6OTXCFH36zzt0pPfpkGtdISRkJ/W7ReiIJCd 6+Qg== 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=XihY01nJqBrnFUvr1iVd64M7+xHJ37AZNnm12AkE76g=; b=ZZAP9oon/ZIKMQNtdQqI+qOxSvwsxaNx3Q0UTcTZTE+ymZMahzjUQjIUrugueyTqDQ hylUktSQHTB4XMzB3j1e5RdHPtlOPisfI8fQhe2mU95nMRI0kSk7T42HWC4yY7yf4Roy rPSssmOQK6QMjeh3/RTM3KpnrsdWADVjmjK6BNOTmQ1APDnVwyMg8SPbJQfVrnb+rlSB lhCUN/bvGGSwL2E6GbKasH3jkMHedSrnMRAX4bJjRWl/zVr0dcUYr+9rImkFJ5/Qc07V b7f4SxEvhAHF7qaLtIXadPpdqG74NxjaahJ1lNBYaQHt7LqMGRGX4tGY3Okhr58GotDi mGSQ== X-Gm-Message-State: AOAM530MT3UufganDA5A/mmYyVf4QbxEv4U53u3//yCIqiZWq98+8YkI ttMkgajEoD+93KF8jnCHJloW0ry26FI= X-Google-Smtp-Source: ABdhPJyuKJjZVOC92iONk2ZwQRk7C8fhpydxo+vLT3TheqFJuJWy+J5xFEzqikridW5xowCfJ+wamg== X-Received: by 2002:a1c:a958:: with SMTP id s85mr5524580wme.4.1614884271344; Thu, 04 Mar 2021 10:57:51 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id o3sm445543wmq.46.2021.03.04.10.57.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Mar 2021 10:57:50 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Juri Linkov References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <875z282el0.fsf@mail.linkov.net> <9d87da5b-e30e-149d-a467-a2c4c752a60e@yandex.ru> <87czwf9sq9.fsf@mail.linkov.net> <87mtviajlf.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Thu, 4 Mar 2021 20:57:48 +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: <87mtviajlf.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: 46859 Cc: Gregory Heytings , 46859@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 04.03.2021 19:56, Juri Linkov wrote: > I'm not sure because most hits are not fontified anyway > when not all files are visited especially in a large codebase. Yes, so highlighting won't be universal anyway. OTOH, if we have a long file which is visited somewhere near the beginning, and there are a lot of hits inside, font-lock-ensure can create some noticeable overhead. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 07:31:45 2021 Received: (at 46859) by debbugs.gnu.org; 6 Mar 2021 12:31:45 +0000 Received: from localhost ([127.0.0.1]:36178 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIW5x-0005FP-66 for submit@debbugs.gnu.org; Sat, 06 Mar 2021 07:31:45 -0500 Received: from mail-ej1-f49.google.com ([209.85.218.49]:45125) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIW5v-00059l-Kk for 46859@debbugs.gnu.org; Sat, 06 Mar 2021 07:31:43 -0500 Received: by mail-ej1-f49.google.com with SMTP id mm21so9239123ejb.12 for <46859@debbugs.gnu.org>; Sat, 06 Mar 2021 04:31: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=1SHtJ/Q6HIVrXDL8u00aifpy5xzQIR8aJcVP5NOF4Ec=; b=oRkHaiUynm1tqyjLmOcsXr1Qf6BqayepDyv7XQ2eJkdj/d/vW8SZzlEy3BFUCV2WaJ 4u5uHq3O0oM0XIhamCaJ9urRCEe6KNNf4AczX+TeXbKl+Sme2RwrIhQzRTL/tGCVQ31t lZ1FEEajA1yY2Wr98d7w1vh4Sj9PZIFB707Kp4kdE47Z8lxD+Gte9gulcwbyqlB+3L5k KaGcUmDbajEl8GtDv4+6DLoenQBD4h5mRF1KOL05A3i0QwweBCc9xuaUJ+xDKZxTeUUY SpJ1SmOuHG+y8P5CKwuBbxSQxEP7DKOR2T5nIV6DCPPlR4/Ao0BNMfoCI1bnSP1G27j6 3msQ== 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=1SHtJ/Q6HIVrXDL8u00aifpy5xzQIR8aJcVP5NOF4Ec=; b=er9tCF74GIS+84dujNE/KJLi25Cy7DbruUswjZWHROAcE9Vkmf78jnX/Hmiu72Wdnc gCaEpoKSPtMlPUrMWP6ZIZFboaziTKuEJBWxuByaQg3SGQvfZl/c7Nxhrta1/toaJFfL we5J2NjOU9wnNYoWjQdjnJ3ujHEPvkSmf/26rgJNgce36Ma53iXTVHJM8l2aVL9KjAjv VxCsoyfDkBdfva3tdFVpAohW5J2T7cer7nRkiHDbxPojIllKa1MjMEDTlqpWbHBx1b+m SsnLnlc5/TEYQEeWWyksUORQVUHqB+Ni0Ys7HnnDDXUJjS0Y+r475n0Ke/OZM9ojYUXo j9Hg== X-Gm-Message-State: AOAM5321xbL/Rf26OSxFlMWXktCuG18su2EInJzV38XIZeF+ECuLg2Yn u/3MFySuZnlMm0yewkQaAQMSkRla6xw= X-Google-Smtp-Source: ABdhPJzNsSV7OocwhZAsSa9zjhvab4VVuGkmKLBBS+kG+M0hj1soHyxC2xCzmWI8CuL+TSYszncACQ== X-Received: by 2002:a17:906:dfce:: with SMTP id jt14mr6797325ejc.83.1615033897863; Sat, 06 Mar 2021 04:31:37 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id f3sm3250948ejd.42.2021.03.06.04.31.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Mar 2021 04:31:37 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Gregory Heytings , Eli Zaretskii References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> <83mtvjhrzj.fsf@gnu.org> <9cff0f889435d8d03313@heytings.org> <834khq266r.fsf@gnu.org> <9cff0f8894ab45713d12@heytings.org> From: Dmitry Gutov Message-ID: <16ac41d4-5718-0cec-a68b-4abcc736ee4a@yandex.ru> Date: Sat, 6 Mar 2021 14:31:28 +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: <9cff0f8894ab45713d12@heytings.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: 46859 Cc: 46859@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 04.03.2021 19:35, Gregory Heytings wrote: > Just tried 'exact, it works, it's slow (but not horribly slow: 1.2 > seconds on that 25 MB file) 1.2s is pretty slow for this purpose. Otherwise it would be possible to use this approach (by introducing a Grep-specific location type) and avoid parsing the line contents for every match. One downside would be missing on the syntax highlighting which we sometimes get for already-fontified parts of buffers, but it's unreliable anyway. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 07:37:38 2021 Received: (at 46859) by debbugs.gnu.org; 6 Mar 2021 12:37:38 +0000 Received: from localhost ([127.0.0.1]:36196 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIWBe-000672-HS for submit@debbugs.gnu.org; Sat, 06 Mar 2021 07:37:38 -0500 Received: from mail-wr1-f54.google.com ([209.85.221.54]:37416) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIWBc-00066o-Ht for 46859@debbugs.gnu.org; Sat, 06 Mar 2021 07:37:37 -0500 Received: by mail-wr1-f54.google.com with SMTP id v15so5443823wrx.4 for <46859@debbugs.gnu.org>; Sat, 06 Mar 2021 04:37:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=u5pLcM2SWv+vlbB81aPAkFLcDu1WeFU13yMdpAcwhmM=; b=hsqsmfjwAu7qeBxwtAycfmZAVFwzS/MiwQZXVHv9rsa3YNE5gWVfpXzsjsEyhHmyBG 4w9M1y6PRfqyL2bE9JmRLKPg5DP5UZRPT/40LSRRbHREgr/4hbhdaShwCM9EO1wEqUHo /vuXMemSGNDx6RnhZYkKwORHymfHI90vkMdWN40Cvhlp4VUEVXts5iM3eOLgZROQvE6X NxnmgyLUVQj2pzJfYJIZXfEpLRa7/7qisPT8wmyU1acgCJCGRTTYJJWmgKe7CfdLDd98 RyVWzajesKyPRSBxxlixz6BBxLV11/M63JJAbqcLZViIVsaea95kUwPzc50+DSO5PTUe 9ujw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:from:to:cc:references:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=u5pLcM2SWv+vlbB81aPAkFLcDu1WeFU13yMdpAcwhmM=; b=QRfTITla4MpGVAEZ9BJJPx6IJr0AV/lISDg5Zs62Q6TWbLDJ/2+ChB3/2dGkIs+8Yu wjTFty/aVLxoi9d3niFCdS3klXok3abDvuxZSPafwiWInABIYujvACNkhSb9wNszXbGp 3abFGJ1mDr9hA3qORpFTsUcf1Ii009/kKcf22o3iCH8T5UyIFpDvaJ5tOvyshE0mt1ve p71ro7TKaEjQNv9ouz1RZvBvIH9Pan5AJQ7ZvzJPuT3C2t5aePOgYUNQV7ornV0Huuke zh6woKO38mKvXAILSDQ9O0I259XbrXzjkyKjkjZzfElmOTCm9GSuY5nkMyaivPqEZzCb rGhA== X-Gm-Message-State: AOAM531xNfxqYynyCPqdbTrM0/U85gNQm5zB0rbtWYfN3svWUAfhzEiA BfTUbeSfKFV1Sz3D7m5l0WWfzGbloHg= X-Google-Smtp-Source: ABdhPJwVNx3tLeE3ahRLqgIBJFJ3U5i3xSgGQkcU9RQTKj8kHEtwewBegwmNVjJ0pttp826pA6BPDg== X-Received: by 2002:adf:828e:: with SMTP id 14mr14043519wrc.123.1615034250718; Sat, 06 Mar 2021 04:37:30 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id a21sm9063858wmb.5.2021.03.06.04.37.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Mar 2021 04:37:30 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el From: Dmitry Gutov To: Gregory Heytings , Eli Zaretskii References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> <83mtvjhrzj.fsf@gnu.org> <9cff0f889435d8d03313@heytings.org> <834khq266r.fsf@gnu.org> <9cff0f8894ab45713d12@heytings.org> <16ac41d4-5718-0cec-a68b-4abcc736ee4a@yandex.ru> Message-ID: <109276c6-30fb-b1ca-cafa-48a15710099b@yandex.ru> Date: Sat, 6 Mar 2021 14:37:26 +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: <16ac41d4-5718-0cec-a68b-4abcc736ee4a@yandex.ru> 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: 46859 Cc: 46859@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.03.2021 14:31, Dmitry Gutov wrote: > Otherwise it would be possible to use this approach (by introducing a > Grep-specific location type) and avoid parsing the line contents for > every match. Except, um, we still need to fill in the "summary" attribute for all matches, so that there is something to display in the Xref buffer (the line contents around the match), and the -o flag strips those. And if we were to use the '.{0,100}file.{0,100}' trick, it messes up the location of the match, the reported byte offset become unreliable. Also: grepping for that kind of regexp is noticeably slower than grepping for 'file'. Or even '.file'. Like 85ms vs 7ms slower. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 07:39:47 2021 Received: (at 46859) by debbugs.gnu.org; 6 Mar 2021 12:39:47 +0000 Received: from localhost ([127.0.0.1]:36200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIWDi-0006AL-T8 for submit@debbugs.gnu.org; Sat, 06 Mar 2021 07:39:47 -0500 Received: from mail-wr1-f48.google.com ([209.85.221.48]:36583) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIWDg-0006A5-Hl for 46859@debbugs.gnu.org; Sat, 06 Mar 2021 07:39:44 -0500 Received: by mail-wr1-f48.google.com with SMTP id u14so5471011wri.3 for <46859@debbugs.gnu.org>; Sat, 06 Mar 2021 04:39:44 -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=yqpicjki1r5ANV1oj4wU87vuGCj8TDUnTmagDg0PUPo=; b=eYQA5rLRUoyzwj9/6P+GvcyeGuuuHjOkhI7eJmbmgJoQDKq1fHLIYXUtDSCwInFoOC LDuIiIIVJJF0W3FybYILzurpGbjaMJzgAkFXNveVLeaZhJuEg4zWAUI80LuGz/up7Z+t MgvM8k8iAJ/67hnDAJFb+AZhWU3ef1jaiqdBw7QwVf/Lb17G1chDqrbAdXAZmRh0Z665 TfcaYy4lim5yOfv8mH6NEVWc3yUwjPHZNkDYwAVJcJvFLwGIGAKU1/xgbjdUoRpnISyO IzExJ6Z+AVzVzUFVHh/ZjxfDvpkhJ1Y2WRY0fsVQAXGG+iYAKj7qgDIhQYrbv49vrPOt WzCQ== 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=yqpicjki1r5ANV1oj4wU87vuGCj8TDUnTmagDg0PUPo=; b=cnLfXfagMxErGswrf/VmfNM9j8J/Q3VUGGCWnn16LRLnPBnDOinRko1LbjSExf4XD3 tLnVERTDGae5r981R4wLyuDShnfy1PR45XXE85myODtLjVorWesfNxjmO5BYiP6kkjDb yw1HPI5ezXVOMxHlU6s0Cv6dPLyv2D3WRswnVadqsQ/hTXJCBhsOMMUbA+K4PEbj+vWI sou8SRB14tJx+VV/Np0bYd+9hADD+WHXXZVEVDNL3QJHVHm6ba7HckEbfwBI6UTsCwSz iYoGhIVaA4ll40DvVL1Pz98gt8P21Apo5QE4Zz7bZD6vqVi65aIBaIc0rfgceugVg2mi 5XZw== X-Gm-Message-State: AOAM532jEZ4Oqpzra8EugDNL5EwJqm4z17M1gx91ROblfW+evYGiPVzU CT8M3EXRk4yXfX3c6uaoHTEWjzMTsiQ= X-Google-Smtp-Source: ABdhPJwnX4/znO+LTMlnu6M/68FBy7jUxprtCMbm0RP1xS5FkpLHlLRFeHMhYRqohDMIerptFiuXlg== X-Received: by 2002:a5d:6703:: with SMTP id o3mr13962917wru.357.1615034379008; Sat, 06 Mar 2021 04:39:39 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id s18sm2208125wrr.27.2021.03.06.04.39.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Mar 2021 04:39:38 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Juri Linkov References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <875z282el0.fsf@mail.linkov.net> <9d87da5b-e30e-149d-a467-a2c4c752a60e@yandex.ru> <87czwf9sq9.fsf@mail.linkov.net> <87mtviajlf.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Sat, 6 Mar 2021 14:39:36 +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: <87mtviajlf.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: 46859 Cc: Gregory Heytings , 46859@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 04.03.2021 19:56, Juri Linkov wrote: >>> I don't know if extra font-locking is worth worse performance. >>> But I took this idea for consistency from occur that uses >>> 'font-lock-ensure' in 'occur-engine-line'. >> If you're sure you want this behavior, we can make it a user option. > I'm not sure because most hits are not fontified anyway > when not all files are visited especially in a large codebase. Other values for this option for better consistency could mean "strip all fontifications" and "make sure to visit every file and fontify every line". I'm not sure anybody would want either of them, though. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 07:45:01 2021 Received: (at 46859) by debbugs.gnu.org; 6 Mar 2021 12:45:01 +0000 Received: from localhost ([127.0.0.1]:36208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIWIm-0006IK-Pq for submit@debbugs.gnu.org; Sat, 06 Mar 2021 07:45:01 -0500 Received: from mail-wr1-f49.google.com ([209.85.221.49]:34221) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIWIl-0006I7-50 for 46859@debbugs.gnu.org; Sat, 06 Mar 2021 07:44:59 -0500 Received: by mail-wr1-f49.google.com with SMTP id u16so5459126wrt.1 for <46859@debbugs.gnu.org>; Sat, 06 Mar 2021 04:44:59 -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=i9kTuyLJOcwVnnK1Hqcz7peiUKoz+t+vR5D5al7psK8=; b=iO6aAW1oRsIluYd/rOpfSBkQQggr+jUTqnVzJy1IcLQxrkM+8zDbUk0fajVsk7+zk+ +lQYPYTUhxYJLufvm6kvoaMiLwa5i8jhHNnojVMtBA0sD6AN2alXNVrofNFBLcj3eqRn vF6KBpx1slV/Ls8yXlJvavPdufynDw7q4536RhcVdEwBsmGLrbeLl1k3vhP56tjOg4zf eXmjfm8LJcZ1IC4qiKLAhxaSNhQNjAo3ZYl0DN7mr7XGiDRRC9iqg7TBKnlM+B81Ye3q I11JENFmHVRytGegrm1xzQL6P1G2VC8+BN3BnpW1JbsP7nquxDI170PcRRQ8ZxAAKcoi ql3g== 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=i9kTuyLJOcwVnnK1Hqcz7peiUKoz+t+vR5D5al7psK8=; b=o+aK4/JFXz0s59xx6xPvTJ9xsPjBVSYv/ZKAkPhOLzjZ9jtNyTFT2N7xJuAkV00rDS l4+pziniiurgRG97pllo06bXIgQng1/YITHegj+SkiI8Uvb/ox6N02fVZrUuP6pdP5KM 0ha8Hjfvz5gSnXUF4AgCwhr6BIp3nvaI9OExvLqy8I5iDW9FEFVkEwBsDD4oQv3pkLQJ YYBSNZYuRml0tyhrfGUIO0ctijrur/oxAsfkl11rgj/YFd0ZLlbWuNlA6tr6hl/xu9c5 K9aEWaYsyH3YNyWH4yyZ495FvxXoesOOhMI4U9R/o6kSdfpYMk6OEJMMpfcmfnbXYcu+ NLbg== X-Gm-Message-State: AOAM532GlXyGRatW5uCoOGDUOTdJUrCNcjRcImgjeSdfxiEz0QI6P3Bz LHEeJpEq5urjl/Dv8VoFTLcinEeMoIg= X-Google-Smtp-Source: ABdhPJzkZPP1+m7M0Dk2UDNY1l2F9yoTJHSG5CCKvdUPJBXWwRHytJmPyrIzb8lB3r7PynoeBhNhuQ== X-Received: by 2002:adf:fe01:: with SMTP id n1mr14087521wrr.341.1615034693325; Sat, 06 Mar 2021 04:44:53 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id p6sm8642862wru.2.2021.03.06.04.44.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Mar 2021 04:44:53 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Gregory Heytings References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <08b51962-6305-5188-0bea-b17b4139646c@yandex.ru> <4119ea3055bd6f6d2e91@heytings.org> From: Dmitry Gutov Message-ID: Date: Sat, 6 Mar 2021 14:44:45 +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: <4119ea3055bd6f6d2e91@heytings.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: 46859 Cc: 46859@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 03.03.2021 23:06, Gregory Heytings wrote: > >> >> With your approach we'll have to deal with interpreting Grep outputs >> which list every line in the searched files. This will almost >> certainly be slower in the case when there are only handful of >> matches. But benchmarks welcome. >> > > I don't know what you exactly need (I don't (yet?) use project), so I > can't elaborate further or provide benchmarks alas. The same code is also used in the default implementation of xref-find-references, in case you ever tried it. > Could you perhaps tell me what you need? We are discussing changes to xref.el, because project-find-regexp delegates a lot of its logic to it. Check out xref-matches-in-files and xref--convert-hits which it calls at the end. What you're thinking of seems to require a Grep-specific version of xref--convert-hits logic, which in the end constructs specialized xref items with a new type of location (alternative to xref-file-location). From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 07:49:19 2021 Received: (at 46859) by debbugs.gnu.org; 6 Mar 2021 12:49:19 +0000 Received: from localhost ([127.0.0.1]:36212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIWMx-0008UF-Cv for submit@debbugs.gnu.org; Sat, 06 Mar 2021 07:49:19 -0500 Received: from heytings.org ([95.142.160.155]:45462) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIWMu-0008U5-Br for 46859@debbugs.gnu.org; Sat, 06 Mar 2021 07:49:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1615034955; bh=RdnFDBijsg/ewvfutvseWXdbHTAKycK4s+HOZaOyjPw=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=Nna0ChR0L2O9KyAe3Hu0ROP7ARaJ170S7zjSWV/NjpCZWTw+uGWj/U3zrfCnk1hML T/rSCZhVv5is8iNriV5a/Vynl66WTqQnEckmz5R3DbWJ4pUoILAE4ojSVxSDoh0xDv PpSpHVW7AQeP0sv8O3podUJRKa0lFcrYcFfilhbZwmmcu7pzAMoy8DsbHmLXLWAD+j zI2fanVgpB9nQe1iS8XQ+75PrBg8iMbOexjq9PDhfFYJbKcrmYXeqle6z4shk4cM/m unVt8DiqQyZgliavczwx2ygLwLSWMQgjANFmTnelHzXEOZI0XhUp1lZi3UfoZ/Mzh8 TleXTzQoltKdQ== Date: Sat, 06 Mar 2021 12:49:14 +0000 From: Gregory Heytings To: Dmitry Gutov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: <16ac41d4-5718-0cec-a68b-4abcc736ee4a@yandex.ru> Message-ID: <7de1aeec52418a3d5fd5@heytings.org> References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> <83mtvjhrzj.fsf@gnu.org> <9cff0f889435d8d03313@heytings.org> <834khq266r.fsf@gnu.org> <9cff0f8894ab45713d12@heytings.org> <16ac41d4-5718-0cec-a68b-4abcc736ee4a@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) >> Just tried 'exact, it works, it's slow (but not horribly slow: 1.2 >> seconds on that 25 MB file) > > 1.2s is pretty slow for this purpose. > It is: (1) on a 25 MB file (not the typical case), (2) on a file with an exotic encoding (not a typical case either). On typical files (UTF-8 or single byte encoding) the delay is not noticeable (a few milliseconds). > > Otherwise it would be possible to use this approach (by introducing a > Grep-specific location type) and avoid parsing the line contents for > every match. > It would be much faster, especially with very long lines, which was the question with which this bug report started. > > One downside would be missing on the syntax highlighting which we > sometimes get for already-fontified parts of buffers, but it's > unreliable anyway. > Yes, I don't understand why syntax highlighting is used in such buffers, IMO it's useless, it would be useful only if (1) it were reliable and (2) all lines were highlighted. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 07:54:43 2021 Received: (at 46859) by debbugs.gnu.org; 6 Mar 2021 12:54:43 +0000 Received: from localhost ([127.0.0.1]:36216 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIWSB-0000Aj-0u for submit@debbugs.gnu.org; Sat, 06 Mar 2021 07:54:43 -0500 Received: from heytings.org ([95.142.160.155]:45472) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIWS9-0000AY-Ba for 46859@debbugs.gnu.org; Sat, 06 Mar 2021 07:54:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1615035280; bh=raaNAvR/I0txbYXFMWdFRcmL28hZD49gO8hDY2bdCsA=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=lcj/oM7C1BeQ6PIMb/jfyL2n+2IvQHR/AHrMbVGyBqtV8BSaxgr+fqjL0BuO+k3Zg jSQ97T2Q0fA+UUyp6tsgkgsqtJR0nWtu0SxHy0tGnzdu4wXahz0bs+E+KuIlDbyDTc jENf+mCjTP8X96cpci55XiSeT5f5iKmZV1dx9rgtBEmUdw1pzhaDHQMuoPytfilSem 9TLP5ZmddQPppV+CUyXmAZELwz9FJv36o1QHJLz2iIz83yiUcAaoSpT6AnZf2z/yS5 7XUC6vAGqyk4GPwLEG0mbmX9K6xds1G0UeidvygJvVBLa9tyKFBfzbyHqTkuD50p9I fl4P6pXg0c87Q== Date: Sat, 06 Mar 2021 12:54:40 +0000 From: Gregory Heytings To: Dmitry Gutov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: <109276c6-30fb-b1ca-cafa-48a15710099b@yandex.ru> Message-ID: <7de1aeec520f4204be5b@heytings.org> References: <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> <83mtvjhrzj.fsf@gnu.org> <9cff0f889435d8d03313@heytings.org> <834khq266r.fsf@gnu.org> <9cff0f8894ab45713d12@heytings.org> <16ac41d4-5718-0cec-a68b-4abcc736ee4a@yandex.ru> <109276c6-30fb-b1ca-cafa-48a15710099b@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) > > Except, um, we still need to fill in the "summary" attribute for all > matches, so that there is something to display in the Xref buffer (the > line contents around the match), and the -o flag strips those. > That's the purpose of the '.{0,100}' context. In typical cases (souce code files with lines that do not have more than 80 colums) you don't even see the difference in the result buffer: you see the whole line. > > And if we were to use the '.{0,100}file.{0,100}' trick, it messes up the > location of the match, the reported byte offset become unreliable. > That's a problem to solve, indeed. At first sight it doesn't seem unsolvable. > > Also: grepping for that kind of regexp is noticeably slower than > grepping for 'file'. Or even '.file'. Like 85ms vs 7ms slower. > Well, the bug report mentioned delays of 3-4 seconds on files with very long lines, so I'd guess that 85 ms is a pretty reasonable speed... From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 07:58:47 2021 Received: (at 46859) by debbugs.gnu.org; 6 Mar 2021 12:58:47 +0000 Received: from localhost ([127.0.0.1]:36235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIWW7-0000Hu-9x for submit@debbugs.gnu.org; Sat, 06 Mar 2021 07:58:47 -0500 Received: from heytings.org ([95.142.160.155]:45486) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIWW5-0000Hm-N7 for 46859@debbugs.gnu.org; Sat, 06 Mar 2021 07:58:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1615035524; bh=pu+nG5SOmflDqTN4zDTSaXX68YuOoo+9gkng1Kb0Z5M=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=e7045l54YoVxTJ47HiyHlG++qFnfN0pPPCcml4Kg05B87LtAgJUwjtek0iKqZvyvw q9cQnLR7X5iqephkavoFKs6obapfPFt/lxFsTZJfRvYSjeZkFWpdvumvba8H6lxdxf j8qrCvSAfdF0/nHiiUL/fZPuOCc/26WsQdEFlTffJc7uqgzwGzU65cb98o4vHQWvzJ rdVqkiu8FKjzNEeNGSORBPTERPbs/yjrz5RLbMgcX7IJIUIqh3u4/qry7lwTXkS9Ib nv9hupcN7bsosxh3xp6yP4EnIqwZtUbODTT3Sy4enaTJvb819QVvr5eA0CTzTGIbGs 50k63yuhJp0Mg== Date: Sat, 06 Mar 2021 12:58:44 +0000 From: Gregory Heytings To: Dmitry Gutov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: Message-ID: <7de1aeec52b5dcf97969@heytings.org> References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <08b51962-6305-5188-0bea-b17b4139646c@yandex.ru> <4119ea3055bd6f6d2e91@heytings.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) >> I don't know what you exactly need (I don't (yet?) use project), so I >> can't elaborate further or provide benchmarks alas. > > The same code is also used in the default implementation of > xref-find-references, in case you ever tried it. > >> Could you perhaps tell me what you need? > > We are discussing changes to xref.el, because project-find-regexp > delegates a lot of its logic to it. > > Check out xref-matches-in-files and xref--convert-hits which it calls at > the end. > Okay, thanks, what you need is clearer to me, I'll have a look. > > What you're thinking of seems to require a Grep-specific version of > xref--convert-hits logic, which in the end constructs specialized xref > items with a new type of location (alternative to xref-file-location). > Yes, that's what I'm thinking of indeed, but it's not specific to "grep" because it would work the same way with ripgrep, ag and ack. But indeed it's specific to grep-like tools. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 09:06:31 2021 Received: (at 46859) by debbugs.gnu.org; 6 Mar 2021 14:06:31 +0000 Received: from localhost ([127.0.0.1]:36302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIXZf-000451-FA for submit@debbugs.gnu.org; Sat, 06 Mar 2021 09:06:31 -0500 Received: from mail-wr1-f45.google.com ([209.85.221.45]:41720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIXZd-00044m-VD for 46859@debbugs.gnu.org; Sat, 06 Mar 2021 09:06:30 -0500 Received: by mail-wr1-f45.google.com with SMTP id f12so5627265wrx.8 for <46859@debbugs.gnu.org>; Sat, 06 Mar 2021 06:06:29 -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=h1f8UAJvmoOpZK6rQJa/aobB1wxHgsxcvHo3bF22ius=; b=BakprGJKPef8EYHG/LQi1gyyWnyTsYY+hFXHTzSowWea+qWO3u4xtfMW5fJO3dP7ev +BL6CIPyt36Gm6pI3OHwP3sGko8BElMAvlVczDf+cWT9wFu5/cMFq3nmhLAemdvNGkr4 sJN6uDKF8d6sLnfTVVtv9QZQFn1qjdEfmySShHE3fgLwfCS/WFL/anMWBZRB/U4DzEoa vxIqkELZ/YupkP+0l6QI76O2mrB1TOqREeRlRxCh9umrc6G6E5CS+PQ+0cc6ZxXWrPxv cK+oxMXlp/6CSle0+5k/M+Sl4F6J07VYAQA/45UkN5jAR2oSP0mxH+yC3Ba0i6HeD0Nf cExg== 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=h1f8UAJvmoOpZK6rQJa/aobB1wxHgsxcvHo3bF22ius=; b=COjYWtjmX6vb92F5fn0hkTIKRMra5ijCL98wGmx1VcP1gSuzsqkJppAX4dY7Jbmk3Q 573RgzRXBbxwETsuo+vWMkcxHKPKdMd63xeYvnyLDN6N41MEXdSs9fZc/lAQi9Iok4UF 6wVn9+UtaGsVUGIctttEdZ8itAq/OGgIFfZAPqdgW0bEapnthORXel/zlA0W+n1ekTj1 +CECrmThnm1DLuVIX0c2prp8huj1O0893rU0cibu2O5Rsaezj/kcOY0AjQ3B549QHwEY vgXncXP2ayaRUrTK/EfY1jnp+cG8+evrJ05oR78IvxB4g4s/Nb5/YyrUy7ltU0jP8aTg LXnQ== X-Gm-Message-State: AOAM530TUkVePoqJSihXDn6NDRv2+B2ujcClm/Yyk5NK91ZMA3eNvVD6 O6AAsJvQO6X3FSbCP3pcRHw+TnnNwpA= X-Google-Smtp-Source: ABdhPJwPqSjhNKlwK/O58Yk/bJPL3PgDOMHFqVhvBRnS6sZF1q/035gBeF1QWl6pGMLeuiKs4Lp/NQ== X-Received: by 2002:adf:fb91:: with SMTP id a17mr14141226wrr.93.1615039584267; Sat, 06 Mar 2021 06:06:24 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id g9sm9403766wrp.14.2021.03.06.06.06.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Mar 2021 06:06:23 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Gregory Heytings References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <08b51962-6305-5188-0bea-b17b4139646c@yandex.ru> <4119ea3055bd6f6d2e91@heytings.org> <7de1aeec52b5dcf97969@heytings.org> From: Dmitry Gutov Message-ID: <18b76762-1f98-a69f-6f23-4e6b13ccf207@yandex.ru> Date: Sat, 6 Mar 2021 16:06:20 +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: <7de1aeec52b5dcf97969@heytings.org> 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: 46859 Cc: 46859@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.03.2021 14:58, Gregory Heytings wrote: >> What you're thinking of seems to require a Grep-specific version of >> xref--convert-hits logic, which in the end constructs specialized xref >> items with a new type of location (alternative to xref-file-location). >> > > Yes, that's what I'm thinking of indeed, but it's not specific to "grep" > because it would work the same way with ripgrep, ag and ack.  But indeed > it's specific to grep-like tools. Ah, ok. If ripgrep can do this as well, it would be more general (a good thing). Note that it mentions the following in the description of its -b argument: If ripgrep does transcoding, then the byte offset is in terms of the the result of transcoding and not the original data. This applies similarly to another transformation on the source, such as decompression or a --pre filter. Note that when the PCRE2 regex engine is used, then UTF-8 transcoding is done by default. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 09:08:06 2021 Received: (at 46859) by debbugs.gnu.org; 6 Mar 2021 14:08:06 +0000 Received: from localhost ([127.0.0.1]:36306 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIXbB-00047p-Qx for submit@debbugs.gnu.org; Sat, 06 Mar 2021 09:08:06 -0500 Received: from mail-wm1-f46.google.com ([209.85.128.46]:47030) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIXb8-00047G-V6 for 46859@debbugs.gnu.org; Sat, 06 Mar 2021 09:08:04 -0500 Received: by mail-wm1-f46.google.com with SMTP id d139-20020a1c1d910000b029010b895cb6f2so1007534wmd.5 for <46859@debbugs.gnu.org>; Sat, 06 Mar 2021 06:08:02 -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=sB53rtQ8vFvyP7ACoLqBlXga+HRypJLhSi0TqYnexkE=; b=Ksxv9VA0cmD13cpjUHpxgJqhVnHCTDmrpIfRNVvZbdHK+oI4vpH33cBKtSxgZlJStk /Vb00Q1utdcdjfLobgX2bDhmpg3WZIR9dQ8VYOZSWdFDF/KiXww7ee73tnyciHgKeKVL oegUSL6kWowHgIyhsnag7Kx9phvrKXcccdrDV1QsUlF0fBTDm0oiTvu9DACpGjohG7h8 pNJN7Ms3dbbm94n7eD6g4aZbgO9OpcB0TTC5RnrYp6Plk47wc3EGcTZlo8sFigRYb5GI x35oSIu2r5oH4yRV5LWDrdPuU+kGUY9L6KZs1qHwLC0HZtZFVgmYmzCuil4rtnTVxia+ PTsg== 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=sB53rtQ8vFvyP7ACoLqBlXga+HRypJLhSi0TqYnexkE=; b=tgWqXLX8gOJN8BdPqIiVovUqc5Ixn7F9qiL+2TZDEMsisHHPrERJfYDzo8BV+5nRMz pHwLw3AlwVrcsn4O1BeYyETChrNJ8KdedTgc/DQnqZfIDHru9aIDldXGm5rl0/dWWSYl D98DmBe1F9CsJA4zSSX12Q7h28DQFqUyppQSb3dEBeXFzvygaIA/dbqCGSk8uiyKkq6k xYa3lbOha4Ar97dGuVysGQETZJ02TZintyu93Hvu8rneIXfeNgcBG0PTeLtjqcib/iWf JJC8ce9F2uH5cVIXzLiZPhM2wg8gbHSVHbGf5Mf9sMasL6zljbrm9ANGkAG5XArSmUaS ts6g== X-Gm-Message-State: AOAM5318BBflNcssZHHlVGUoF6begrDzM6Azwxg675AGlTmZ3PNPqxOG LVx+ZzGGc0twe/UT6bh74MAgwSsolZU= X-Google-Smtp-Source: ABdhPJxJ83xaJsbWAfVZgqAjSeH6NXuzt/pEQjspXx+4h3HY+cNL0XrZfhnrCKfWDSOQ8/AZ7XbGsg== X-Received: by 2002:a1c:32ca:: with SMTP id y193mr11028186wmy.56.1615039677278; Sat, 06 Mar 2021 06:07:57 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id g11sm9065508wrw.89.2021.03.06.06.07.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Mar 2021 06:07:56 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Gregory Heytings References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> <83mtvjhrzj.fsf@gnu.org> <9cff0f889435d8d03313@heytings.org> <834khq266r.fsf@gnu.org> <9cff0f8894ab45713d12@heytings.org> <16ac41d4-5718-0cec-a68b-4abcc736ee4a@yandex.ru> <7de1aeec52418a3d5fd5@heytings.org> From: Dmitry Gutov Message-ID: <2512c264-fb97-c20e-7959-7b8a527ea7aa@yandex.ru> Date: Sat, 6 Mar 2021 16:07:53 +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: <7de1aeec52418a3d5fd5@heytings.org> 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: 46859 Cc: 46859@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.03.2021 14:49, Gregory Heytings wrote: > >>> Just tried 'exact, it works, it's slow (but not horribly slow: 1.2 >>> seconds on that 25 MB file) >> >> 1.2s is pretty slow for this purpose. >> > > It is: (1) on a 25 MB file (not the typical case), (2) on a file with an > exotic encoding (not a typical case either).  On typical files (UTF-8 or > single byte encoding) the delay is not noticeable (a few milliseconds). A few milliseconds is much better, as long as we're not too mistaken about the set of "typical files". Or we'd be exchanging one set of tradeoffs for another. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 09:26:40 2021 Received: (at 46859) by debbugs.gnu.org; 6 Mar 2021 14:26:40 +0000 Received: from localhost ([127.0.0.1]:36321 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIXtA-0004aG-5o for submit@debbugs.gnu.org; Sat, 06 Mar 2021 09:26:40 -0500 Received: from mail-ed1-f41.google.com ([209.85.208.41]:45133) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIXt8-0004a1-On for 46859@debbugs.gnu.org; Sat, 06 Mar 2021 09:26:39 -0500 Received: by mail-ed1-f41.google.com with SMTP id dm26so7119098edb.12 for <46859@debbugs.gnu.org>; Sat, 06 Mar 2021 06:26:38 -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=CRRnvrvzwQjZDkBZ3SsuP5L/Iwx8yd1cN/xXyPVJkxw=; b=CkOWwxnRIym7Tzj3/2zYINa0x+8yVNaF6crYuQq3HmZjhJVsOlsCF3n7vQcrMsYqKh Fz2JAwkyONMN3BQSOGD42GoozFCouas3hspIttnTMGDmjSZ2aX4Gx8GgdqAjTLxC7m1G ZPEtizQ3PCKZGQDSGkNr7STfu2oARbtNgOp8NyQ63bNfsK1gHgpURUrWNRM2kNibSavs sHgjRtZl4Of8yztt1G6xlRrXA1Lif23eLzVAD4u3X4imXckS1aK0u73m+zYYjfI3YLEZ firDb8epD8qo2NlvCw2v0n63MARKNpQZcvFdU771w6oMgYQcisqS5cUao2HpXnUzwihN /uPQ== 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=CRRnvrvzwQjZDkBZ3SsuP5L/Iwx8yd1cN/xXyPVJkxw=; b=SHJh8RH/Hv+zMEQXBhxFvmBhndcWlCZQPlbnpMDNCCgKbP7XQc5MxKfglNrjPpW8WH FBOeCCeLs3VfG52jKOAasz2pfOT47odw+X84/1c7Cs18PpyhSivR1hoa2RGPtl+9FPyy V8opfkr1J+ApTaUjo2ZWyEh3Wk6O+3MYcYsWXXnwKzzUWsdsdYI70qXf50o3biORZFi8 /WHAtHA6qAnCWw810zLNi07ZUfoJbAh+FwG2fxuJ0CyB27Lt4ziMZLjfmjCXBxJe4ho8 Yow1seiT8M2By98k8gDc5Zd8oZV7UOA92SykE0plKlxL97n/sspyvmkxZpm2SB+7b4k3 91DA== X-Gm-Message-State: AOAM5324/GFD+6edNbANAzL6/7vNskih5/k2159K4Vp5fYGe99ChtPa4 1vERvHpofu/+utfNVAgJFg0Dm7Wy4UU= X-Google-Smtp-Source: ABdhPJzLewDD4IL41kAWCJDmGtH+5zN8z4IJx5SY4qruwGMugorFIl5BBaes6wAVm6rnRFZ1KOAx1A== X-Received: by 2002:a05:6402:499:: with SMTP id k25mr14114614edv.294.1615040793089; Sat, 06 Mar 2021 06:26:33 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id m7sm3559969edp.81.2021.03.06.06.26.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Mar 2021 06:26:32 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Gregory Heytings References: <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> <83mtvjhrzj.fsf@gnu.org> <9cff0f889435d8d03313@heytings.org> <834khq266r.fsf@gnu.org> <9cff0f8894ab45713d12@heytings.org> <16ac41d4-5718-0cec-a68b-4abcc736ee4a@yandex.ru> <109276c6-30fb-b1ca-cafa-48a15710099b@yandex.ru> <7de1aeec520f4204be5b@heytings.org> From: Dmitry Gutov Message-ID: Date: Sat, 6 Mar 2021 16:26:29 +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: <7de1aeec520f4204be5b@heytings.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: 46859 Cc: 46859@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.03.2021 14:54, Gregory Heytings wrote: >> Also: grepping for that kind of regexp is noticeably slower than >> grepping for 'file'. Or even '.file'. Like 85ms vs 7ms slower. >> > > Well, the bug report mentioned delays of 3-4 seconds on files with very > long lines, so I'd guess that 85 ms is a pretty reasonable speed... We do want fast searches to remain fast, too. I got that 85ms timing when searching just one file. A project can often contain thousands of files. In my further testing, the difference is not as stark because of other Elisp overhead on file listing, serialization/deserialization/process calls/parsing output, but even with all that in my work project the difference between such searches can be 0.27s vs 0.43s. With further optimizations of project file listing logic, the difference can become even more pronounced (project-files in the same project takes 0.14s). You can benchmark it yourself with this form: (benchmark 1 '(project-find-regexp ".\\{0,100\\}file.\\{0,100\\}")) vs (benchmark 1 '(project-find-regexp "file")) (I get 9s vs 7s in the same project for this particular search). From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 17:26:23 2021 Received: (at 46859) by debbugs.gnu.org; 6 Mar 2021 22:26:23 +0000 Received: from localhost ([127.0.0.1]:38489 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIfNO-00044b-Rp for submit@debbugs.gnu.org; Sat, 06 Mar 2021 17:26:23 -0500 Received: from mail-wm1-f44.google.com ([209.85.128.44]:42903) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIfNM-00044N-Vn for 46859@debbugs.gnu.org; Sat, 06 Mar 2021 17:26:21 -0500 Received: by mail-wm1-f44.google.com with SMTP id b2-20020a7bc2420000b029010be1081172so1490697wmj.1 for <46859@debbugs.gnu.org>; Sat, 06 Mar 2021 14:26:20 -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=L9lfSmiAQFMn+O7tr2+g2dB+D3MOjgck5scxepZ5CNs=; b=uc7JpXn7Ot8v6x/n+VUR8KUkik3aagnsh0HDxIzmaKnRt3Cio3MDe7t68FqPFxWfB6 K8fg5wJgcGJU6K63b1IOuabgpN/Ak9eZXN4/PCpqR1YUzWp6Ii+UheJ0k6mOqnQ6pjwb m5D0VGHeNnwpIFyUsfo8lrjv8rXiiyB8//bHSIFO9ZtQMLFa1IRXjIyfyUu8ohcPwQAG qfJOIPc+yE1PGYpg/Msj6uy3XzU+aISVrJvVt/mvlxxkryT6W4CkuPHqzkoo49mzTzH7 40ssIjqK3EIBqHdIkwXP00rSDxMGw6BTRKrQ2TCX4OEmqItWzibtTUTxjrwLWiQN6BHB F49A== 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=L9lfSmiAQFMn+O7tr2+g2dB+D3MOjgck5scxepZ5CNs=; b=FEPsFkKMZvH5Qk+YDGTGt/4bdHp2le2jchLjfgwTPIXcV8dUJZjumb7DuzE8qsuRK9 5ejh8kVBKDqd2Nh8AVCSqnSCdpGVOYDi9V4ui4bl8KFxIBjSeXDeR0+W1JYidY/zL7Rl tvscdESo50XroXxegz2Vephwkg9qgZFlYkiumHXKmJhfTJgesjNdx46m5NKQAtau/gey 4281KhSFvgLujvCYdLG66IwMyc+RWVdB5j6HA+VqsogVlb+CQZWrq954kiREKxGnl+V7 OtomKJpz2h4JGJ4eV8Hcb3DOxG0cYGU1Dh+ERDPHWqr6KcrKi5hnadirNmQrGy/Jw0nG /tNw== X-Gm-Message-State: AOAM5307jtWJLSnK6RodvAW9JQOSKUeLu/3GrBUabzBsMlTFxwE7Pl+/ 0JX0VA/3Emem96YizD5+Rj7t240wehg= X-Google-Smtp-Source: ABdhPJxqCqb5wMHbYinDOwHAFpRBTd5o4VqYekxz+2P1GHRrxcK5mwk2L9eU8fFOYxBq0L+6iitF8g== X-Received: by 2002:a1c:c903:: with SMTP id f3mr15044969wmb.69.1615069574974; Sat, 06 Mar 2021 14:26:14 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id m2sm10461035wml.34.2021.03.06.14.26.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Mar 2021 14:26:14 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Theodor Thornhill , juri@linkov.net, 46859@debbugs.gnu.org References: <87im69uzlt.fsf@mail.linkov.net> <25782781-4baa-5d44-99a1-2e57552ab3a0@yandex.ru> <666564dc-0252-6bf5-04e1-58c9916cffbe@yandex.ru> From: Dmitry Gutov Message-ID: <92f18de5-6dae-8041-2da0-e4b782f9003e@yandex.ru> Date: Sun, 7 Mar 2021 00:26: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: 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: 46859 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 (/) Hi Theodor, On 03.03.2021 21:54, Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > Hi again, > >>> I tried another approach which yielded some nice results. >> >> Thank you. >> >> Could you also try this benchmark with an input string that has no more >> than, say, 3 matches in the big one-line file? Or maybe just 1. >> >> I'd like to compare the relative performance in such scenario, too. >> > > Curiously, it doesn't seem to affect things much, neither for your patch > or mine. I just got around to testing this properly (sorry), and so far I've been able to reproduce the slow behavior only when there are many matches in the "big long line" file. I'm using a 500KB minified CSS as an example. When there are only a few matches, the search is relatively instantaneous. So that's a weird mismatch with your reports. If you have some details to add to reproduce the slowdown in the "few matches" case, that could be helpful too. I'm currently looking at the patch and trying to figure out whether we could apply some smaller change, or a change not in xref--insert-xrefs (which is relatively complex already) with the same benefits. Also: - Could you explain the change to xref--collect-matches-1 in the most recent patch? In my testing it doesn't move the needle at all, and it seems unnecessary because neither Grep or Ripgrep report matches on the same line separately with the current arguments that we pass to them. But if we did... what's the idea? Skip all subsequent matches, no matter if they're far or close? - What do you think about making an effort to actually retain all the matches in the output? That would mean interpreting the xref-truncate-line-to value (or however the var could be renamed) as the maximum number of chars to render on the line *per match*. And if there is too much text between them, those parts can become "(truncated...)". Your current implementation can cut off valid matches, and we probably want to preserve them if feasible. OTOH, the default value could go down to 200 with this approach. >>> In addition, we could add another >>> defcustom for the xref--collect-matches-1 function, >> >> That can be done already by the user customizing >> xref-search-program-alist, I think. > > Oh? How so? One can add " -M300 --max-columns-preview" in the middle of the ripgrep entry in xref-search-program-alist, as well as set xref-search-program to 'ripgrep'. What I mean is, we can provide the "fullest featured" default behavior, one which never omits any valid matches and just truncated the line context around them, and the users who want even faster searches (at the cost of missing matches, esp. in find-replace scenarios) have something else to customize too. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 17:47:48 2021 Received: (at 46859) by debbugs.gnu.org; 6 Mar 2021 22:47:48 +0000 Received: from localhost ([127.0.0.1]:38499 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIfi8-0004a3-10 for submit@debbugs.gnu.org; Sat, 06 Mar 2021 17:47:48 -0500 Received: from heytings.org ([95.142.160.155]:46090) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIfi6-0004Zv-T4 for 46859@debbugs.gnu.org; Sat, 06 Mar 2021 17:47:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1615070865; bh=0bU0utP3jUKMI50MOVEwhQ5yj77QgsjOkNq2tb3fBQ8=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=xVCKpweq7daXJeRurPbuzXF+GQIAN5OYbzpvLiwqVUbom2N8RwER1UmEefbkFyT70 l1+aCi28/1EXgG18MDuuDzh+e24GkSVM8HNiC/R78JlasbpSsB8X4+T3pTR92/MpJl /Fxk+Ik7nBaSPXbU8xxPGimjgUepWtFkW9+tM/tBtL7lOOHDRdj/c7NIZAbVhLBGaz iItYGRxybAxbahGaw+k3h5xvhXf2zXS7xhACDGIY+NuFciR+uSCxjFjO7z2iV34uwS hgQx/TxxLM0UDHz5eXoM49oFiZqtSiCajCH4fVm0bScpbr0+QkanIpFXF3ebfXxMB0 2SkpE5JAs9mXw== Date: Sat, 06 Mar 2021 22:47:45 +0000 From: Gregory Heytings To: Dmitry Gutov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: Message-ID: <7de1aeec52841199faed@heytings.org> References: <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> <83mtvjhrzj.fsf@gnu.org> <9cff0f889435d8d03313@heytings.org> <834khq266r.fsf@gnu.org> <9cff0f8894ab45713d12@heytings.org> <16ac41d4-5718-0cec-a68b-4abcc736ee4a@yandex.ru> <109276c6-30fb-b1ca-cafa-48a15710099b@yandex.ru> <7de1aeec520f4204be5b@heytings.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) >>> Also: grepping for that kind of regexp is noticeably slower than >>> grepping for 'file'. Or even '.file'. Like 85ms vs 7ms slower. >> >> Well, the bug report mentioned delays of 3-4 seconds on files with very >> long lines, so I'd guess that 85 ms is a pretty reasonable speed... > > We do want fast searches to remain fast, too. > > I got that 85ms timing when searching just one file. A project can often > contain thousands of files. > I just did a number of timing tests. The timings were done in a shell, on a fresh clone of the Emacs repository, which contains ~5000 files, and in which one searches for the 43 occurrences of "expose_frame". The timings are (in seconds): with GNU grep (version 3.6): 0.124 | "find -name '.?*' -prune -o -type f -print | xargs grep -i -snHE expose_frame" 0.178 | "find -name '.?*' -prune -o -type f -print | xargs grep -i -snobHE '.{0,50}expose_frame.{0,50}'" 0.253 | "find -name '.?*' -prune -o -type f -print | xargs grep -i -snobHE '.{0,80}expose_frame.{0,80}'" 0.325 | "find -name '.?*' -prune -o -type f -print | xargs grep -i -snobHE '.{0,100}expose_frame.{0,100}'" with ripgrep (version 12.1.1): 0.045 | "find -name '.?*' -prune -o -type f -print | xargs rg -i -nH --no-messages expose_frame" 0.079 | "find -name '.?*' -prune -o -type f -print | xargs rg -i -nobH --no-messages '.{0,50}expose_frame.{0,50}'" 0.109 | "find -name '.?*' -prune -o -type f -print | xargs rg -i -nobH --no-messages '.{0,80}expose_frame.{0,80}'" 0.113 | "find -name '.?*' -prune -o -type f -print | xargs rg -i -nobH --no-messages '.{0,100}expose_frame.{0,100}'" It seems that a reasonable compromise is a context of 80 characters, which is only two times slower than a string search with both GNU grep and ripgrep, and still very fast. (FTR, I also compared these performances with ack, ag and git grep. To my surprise, they are much slower: ack is about three times slower than GNU grep on a string search, ag is a bit slower than GNU grep on string searches but much much slower on regexp searches, and git grep is a bit faster than ripgrep (and GNU grep) on string searches but again much much slower on regexp searches.) From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 17:55:26 2021 Received: (at 46859) by debbugs.gnu.org; 6 Mar 2021 22:55:26 +0000 Received: from localhost ([127.0.0.1]:38503 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIfpV-0004ko-UJ for submit@debbugs.gnu.org; Sat, 06 Mar 2021 17:55:26 -0500 Received: from heytings.org ([95.142.160.155]:46100) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIfpT-0004kf-Og for 46859@debbugs.gnu.org; Sat, 06 Mar 2021 17:55:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1615071323; bh=Q7RWliDisgMgu9K6Fhs5ibWB1iB5kWm04O+eitp+ZAM=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=iI6ux/1d1nVAp40UQcVzxJoV1BDIm4nOUY76Zg0FjGLtGxTdQy3gjMM2xXi6Mq5uO MWuuEa67zb4WDXuZhchQJ+BElxTn+49i6Idp7rbIyCXhywGvu7vvhjuFUdDyZwzBiK pfiY8+JcoNskVdsC9gCHGkvk0PPy+2UbO1AFVPUD0imYsdj8BPID1h1Z3Q36iy4wYA mnDzmqtIdUBHXsi6K3+OiXAr5ojdN6Zv1UY6Okku2tvLgBXKRnfzCXCKi+idxgJGwa QiYfTUrJySUzYFYFdvlJvPPI7m7jT3JNpgo3kmTjAKhO93Lt+5B93vKLdbOgw0MuKF u35ful7lycGqw== Date: Sat, 06 Mar 2021 22:55:22 +0000 From: Gregory Heytings To: Dmitry Gutov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: <18b76762-1f98-a69f-6f23-4e6b13ccf207@yandex.ru> Message-ID: <7de1aeec528615c163d1@heytings.org> References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <08b51962-6305-5188-0bea-b17b4139646c@yandex.ru> <4119ea3055bd6f6d2e91@heytings.org> <7de1aeec52b5dcf97969@heytings.org> <18b76762-1f98-a69f-6f23-4e6b13ccf207@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) > > Ah, ok. If ripgrep can do this as well, it would be more general (a good > thing). > Yes, indeed. > > Note that it mentions the following in the description of its -b > argument: > > If ripgrep does transcoding, then the byte offset is in terms of the > the result of transcoding and not the original data. This applies > similarly to another transformation on the source, such as > decompression or a --pre filter. Note that when the PCRE2 regex engine > is used, then UTF-8 transcoding is done by default. > As the manpage mentions, this transcoding is done by default _only_ when the PCRE2 regex engine is used, that is, when ripgrep was built with PCRE2 (the Debian package for example is built without PCRE2) and when the --pcre2 flag is passed. And even in that case it is possible to disable the transcoding with --no-encoding. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 18:00:49 2021 Received: (at 46859) by debbugs.gnu.org; 6 Mar 2021 23:00:49 +0000 Received: from localhost ([127.0.0.1]:38515 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIfuj-0004ts-Gx for submit@debbugs.gnu.org; Sat, 06 Mar 2021 18:00:49 -0500 Received: from mail-ed1-f46.google.com ([209.85.208.46]:39580) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIfuh-0004tf-L9 for 46859@debbugs.gnu.org; Sat, 06 Mar 2021 18:00:48 -0500 Received: by mail-ed1-f46.google.com with SMTP id h10so8835920edl.6 for <46859@debbugs.gnu.org>; Sat, 06 Mar 2021 15:00:47 -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=Pwtb4x89wpQxThhU3dsA0L+p6IDfP1cStyeM057OFYQ=; b=lIJbso604WPXlyc+JtfOcA+oqedMiE/+K+gcOzEx0mmgMA3Ecympj9lkth8cIeHvTv ieUTgPbvgnojN1P8e5ryItUXLFrcJzQTl9YvmXx8Vz8bIj3/JFmcWoM0LVu9k58evSWc 9NwL+CYAgh19xE+3NWKnvAa3TW1sGQmQLoUf0hE8xkSFIig6QtQFX0rpOymDBu4riXej 5Bssl2fk720J/rL1//cpw4URugoI7itgBQJIhPAIJ0rsqj7yPvznmatCQY0V/8gxqBoe B9hDDtT2UtEgS4UkKrxgLD2Iatx9oiZXIVauDRqCGsu5GJSdC8XUqBc9YA+wzh/PGgUm 7nEA== 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=Pwtb4x89wpQxThhU3dsA0L+p6IDfP1cStyeM057OFYQ=; b=FckIc4GDc1G/E1XWbjrr9wt3kZW2NCsiAXsOoBJO931ShqHgmtKLL+XgyzWokk8Q2Z +PsFqcKFjt8mSmkOE1SovXlZpILhYP3bs+aSM9oQ8LEEPbI6Hs3HA3xbp3uAhASv1pb7 DU9H+ZP4XK7ivRNvmXHLKFQZFMBKOipTS5hrraJXIBdLcpYEPAaHQEah3mtpVWy7s546 4Yvh26TDtAmRgWJyS4ozIL2x8LyP2l10aup+ewRUZTQAd74GCO0Z99fIslgsp6/wZKhp /vwCPdWRqx6VHQrvBhZ1YZWiBjWETJGwUUQd4lFr8k+bECNFu+Ajs2pPA1bvbHahlTAs s9MA== X-Gm-Message-State: AOAM533YBq/ReNsG75CMucRl2rVDMEbj95sIK0DKKI+7I84nGd7IMCAE s+o1naMm6JXXJr1F4j84guHkKAHAjOI= X-Google-Smtp-Source: ABdhPJzbfjNGsGaECE/P8pCQTX2zTu66hJ3OR03ywjyyBZrcaX+wNDc92cDW7/MrkcAcIZpl9Gh5jw== X-Received: by 2002:a05:6402:3487:: with SMTP id v7mr2203270edc.302.1615071641656; Sat, 06 Mar 2021 15:00:41 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id f22sm4013138eje.34.2021.03.06.15.00.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Mar 2021 15:00:41 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Gregory Heytings References: <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> <83mtvjhrzj.fsf@gnu.org> <9cff0f889435d8d03313@heytings.org> <834khq266r.fsf@gnu.org> <9cff0f8894ab45713d12@heytings.org> <16ac41d4-5718-0cec-a68b-4abcc736ee4a@yandex.ru> <109276c6-30fb-b1ca-cafa-48a15710099b@yandex.ru> <7de1aeec520f4204be5b@heytings.org> <7de1aeec52841199faed@heytings.org> From: Dmitry Gutov Message-ID: Date: Sun, 7 Mar 2021 01:00:39 +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: <7de1aeec52841199faed@heytings.org> 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: 46859 Cc: 46859@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 (/) Hi Gregory, On 07.03.2021 00:47, Gregory Heytings wrote: > I just did a number of timing tests.  The timings were done in a shell, > on a fresh clone of the Emacs repository, which contains ~5000 files, > and in which one searches for the 43 occurrences of "expose_frame". > > The timings are (in seconds): > > with GNU grep (version 3.6): > > 0.124 | "find  -name '.?*' -prune -o -type f -print | xargs grep -i > -snHE expose_frame" > 0.178 | "find  -name '.?*' -prune -o -type f -print | xargs grep -i > -snobHE '.{0,50}expose_frame.{0,50}'" > 0.253 | "find  -name '.?*' -prune -o -type f -print | xargs grep -i > -snobHE '.{0,80}expose_frame.{0,80}'" > 0.325 | "find  -name '.?*' -prune -o -type f -print | xargs grep -i > -snobHE '.{0,100}expose_frame.{0,100}'" > > with ripgrep (version 12.1.1): > > 0.045 | "find  -name '.?*' -prune -o -type f -print | xargs rg -i -nH > --no-messages expose_frame" > 0.079 | "find  -name '.?*' -prune -o -type f -print | xargs rg -i -nobH > --no-messages '.{0,50}expose_frame.{0,50}'" > 0.109 | "find  -name '.?*' -prune -o -type f -print | xargs rg -i -nobH > --no-messages '.{0,80}expose_frame.{0,80}'" > 0.113 | "find  -name '.?*' -prune -o -type f -print | xargs rg -i -nobH > --no-messages '.{0,100}expose_frame.{0,100}'" > > It seems that a reasonable compromise is a context of 80 characters, > which is only two times slower than a string search with both GNU grep > and ripgrep, and still very fast. 'find' is rarely the fastest way to list all the files in the project. Have you timed it alone? 'git ls-files' is usually much faster, and that's what 'project-files' uses under the covers. So if you redo your test with 'project-find-regexp' as I suggested, you might discover a different slowdown multiplier. > (FTR, I also compared these performances with ack, ag and git grep.  To > my surprise, they are much slower: ack is about three times slower than > GNU grep on a string search, ag is a bit slower than GNU grep on string > searches but much much slower on regexp searches, and git grep is a bit > faster than ripgrep (and GNU grep) on string searches but again much > much slower on regexp searches.) ripgrep is generally the best all-arounder these days, though it might be slower in certain odd cases. 'git grep' is not a real option because it uses Git's list of tracked files directly, and we can't really do that. And that skews the comparisons. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 18:24:43 2021 Received: (at 46859) by debbugs.gnu.org; 6 Mar 2021 23:24:43 +0000 Received: from localhost ([127.0.0.1]:38526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIgHq-0005Qy-QX for submit@debbugs.gnu.org; Sat, 06 Mar 2021 18:24:43 -0500 Received: from heytings.org ([95.142.160.155]:46146) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIgHp-0005Qp-BR for 46859@debbugs.gnu.org; Sat, 06 Mar 2021 18:24:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1615073079; bh=wzP8p9v2sINtZlztms0dNkRp+wQ6IsV10IugooNMCqM=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=tvBTsfKs60KQudf4CVeo77HSpoHm8mq00z0bdm+VrG+wg7SwLPZ5Nu9smEzS31BU+ HYjB0rBD5BiXqfRWoApqmh52GMevgP7ucpX0g+V7m3PwNLJCvnRIKdFJRxd5ToV19I 29ZrAFxMTEilVo20ZRTYtbo5N+nkC6bFL9//cgkK7ZjSLSFYswQtpykZtJVYUhURZ5 5v7frICafgegAg23eihHcCbNEtpe74BUlNF9lifPMvVFZW80n/OyNgfyutPANJTr4O 9L9Up6PkFWP646DLkgSSTtye5juICf/zIc96k4IgFAFfnrKWBBx1TTNzlgQc+mNMdO GJcEtw9PYqGlA== Date: Sat, 06 Mar 2021 23:24:39 +0000 From: Gregory Heytings To: Dmitry Gutov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: Message-ID: <7de1aeec5237788b3d98@heytings.org> References: <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> <83mtvjhrzj.fsf@gnu.org> <9cff0f889435d8d03313@heytings.org> <834khq266r.fsf@gnu.org> <9cff0f8894ab45713d12@heytings.org> <16ac41d4-5718-0cec-a68b-4abcc736ee4a@yandex.ru> <109276c6-30fb-b1ca-cafa-48a15710099b@yandex.ru> <7de1aeec520f4204be5b@heytings.org> <7de1aeec52841199faed@heytings.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) > > 'find' is rarely the fastest way to list all the files in the project. > Have you timed it alone? > > 'git ls-files' is usually much faster, and that's what 'project-files' > uses under the covers. > I don't see a big difference: find takes 0.006 s, git ls-files 0.002 s. Okay, that's three times slower, but those four milliseconds are not the bottleneck here. I just ran some of the timing tests again, and they are about ten milliseconds faster with git ls-files, which is not a huge difference. (Of course I do not object to the use of git ls-files.) > > So if you redo your test with 'project-find-regexp' as I suggested, you > might discover a different slowdown multiplier. > I wanted to first time these things outside of Emacs, it seems to me that it's a more objective comparison. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 20:29:39 2021 Received: (at 46859) by debbugs.gnu.org; 7 Mar 2021 01:29:39 +0000 Received: from localhost ([127.0.0.1]:38642 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIiEl-0002UF-1W for submit@debbugs.gnu.org; Sat, 06 Mar 2021 20:29:39 -0500 Received: from mail-wm1-f50.google.com ([209.85.128.50]:43841) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIiEj-0002Tz-JX for 46859@debbugs.gnu.org; Sat, 06 Mar 2021 20:29:37 -0500 Received: by mail-wm1-f50.google.com with SMTP id a25-20020a1cf0190000b029010b1cbe2dd0so1613995wmb.2 for <46859@debbugs.gnu.org>; Sat, 06 Mar 2021 17:29:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:from:to:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tddgKPkiQsuYHn61llMMoqymS/OV90jn0km/cBE/IKY=; b=F0fi6V1hM9b6QOKHeple1c8u/3vN/YtlRhkbAkn9Wyuv3N4JS42D09uxDttmzA15RT HVMw4M2TNuDHQ7qkNLVYAFdo5Ce4PWUq2F2INJyW+aMFgysY7Qsu04PKZvCOxyVHDpln bFa+kiT0r/CSsJLAyAltXmmxX5vhO9YR9ltlqU10WsrztgqolmLpzFbGVgjcjUpDaCYW mVV/VJbtFRPyhE3hcezpe9+JiOpqx1qlgm8Zyp5ifc7N2qS8wxFz6SuD08TxFdj4dlXe 1/8OaIbWTpi7DNZSr253FVFbPu4+V3cO6bASQUcbYRs1VRTIoEmM9NZ+5xSUgHONHDSK ZH8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:from:to:references:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tddgKPkiQsuYHn61llMMoqymS/OV90jn0km/cBE/IKY=; b=HOVatOmbctDZ6D8gZ3jJO2G9YQv0RmBXYps+oQAPCIj55Nlm3sgntq20nXhmYbT/cB jFQTuPO7OSCc3RFiRyVTGiQ4thz4zBJJZyipjug6PO0KCMUbgw6x1+FNB4fT7YQzlE44 N3rRpSwv26Qg/ll3G/As6XRsulBCLjVOqt9Tfb2AsBNE/5dncrbik6DaqX9espFFNETn 6gRjqFkZWF+Dq2msnoTpRhs0qTcgKI8E+dnwXZxwrrxaIAU95dng9W78/4dKODg7ED11 syagprp2CO2TVq59aJMab9XGdH4KIUznsMfVjf0wpFrM66D0yKaNgA8uOcMmd1bYBM5M hPeA== X-Gm-Message-State: AOAM530lNiLblVU0FdPrQdpAU6OYkm2YlYKIXlW8p5WNf2XBE2CHXZQS msliASFSZOAQi/C6BkK2GZlliAUI9xI= X-Google-Smtp-Source: ABdhPJzv5twhnxEYkl9nbac9KRVTEkNCDO1HIS0k1PQYfuLYZkRaLvEWsKQhIC+t5kvEVQ6KQ7ZWWQ== X-Received: by 2002:a1c:4e07:: with SMTP id g7mr15720019wmh.29.1615080571772; Sat, 06 Mar 2021 17:29:31 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id g16sm11067331wrs.76.2021.03.06.17.29.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Mar 2021 17:29:30 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el From: Dmitry Gutov To: Theodor Thornhill , juri@linkov.net, 46859@debbugs.gnu.org References: <87im69uzlt.fsf@mail.linkov.net> <25782781-4baa-5d44-99a1-2e57552ab3a0@yandex.ru> <666564dc-0252-6bf5-04e1-58c9916cffbe@yandex.ru> <92f18de5-6dae-8041-2da0-e4b782f9003e@yandex.ru> Message-ID: <47854960-c7b7-8396-26ec-8ca7acded6b8@yandex.ru> Date: Sun, 7 Mar 2021 03:29:27 +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: <92f18de5-6dae-8041-2da0-e4b782f9003e@yandex.ru> 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: 46859 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 07.03.2021 00:26, Dmitry Gutov wrote: > - Could you explain the change to xref--collect-matches-1 in the most > recent patch? In my testing it doesn't move the needle at all, and it > seems unnecessary because neither Grep or Ripgrep report matches on the > same line separately with the current arguments that we pass to them. > But if we did... what's the idea? Skip all subsequent matches, no matter > if they're far or close? I misread the code, so please skip the second sentence. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 22:08:54 2021 Received: (at 46859) by debbugs.gnu.org; 7 Mar 2021 03:08:54 +0000 Received: from localhost ([127.0.0.1]:38692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIjmo-00051s-CZ for submit@debbugs.gnu.org; Sat, 06 Mar 2021 22:08:54 -0500 Received: from mail-wm1-f50.google.com ([209.85.128.50]:46001) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIjmm-00051e-Dg for 46859@debbugs.gnu.org; Sat, 06 Mar 2021 22:08:52 -0500 Received: by mail-wm1-f50.google.com with SMTP id r10-20020a05600c35cab029010c946c95easo1672681wmq.4 for <46859@debbugs.gnu.org>; Sat, 06 Mar 2021 19:08:52 -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=Y21ShyFkDiiLMVF1mBHW+FbynZMVIzOISJ8hleyaxUc=; b=EakZE4nsaw76kL4mI9j/wtEGJ+BV8NXOY0hDC1/Ct1f9IpgaSJGr4kr/XDi1QHkOSX WRRKKy1murXjuogMVajE1fN+A1MPZC/6OIXbMtCrt0mTic78T9C4456gM2pdBtb+CnHq YRhzNnG4sK2wT8ROttNp9+/MtS1sS4QruOVafdUJAgmAQ5UxLW0h8fM6Mfo52vw4ApJ9 U9gn8+6ycm9DfuvMm5DIJZ0a0wCMdMT8JLDppmBEqAugUWJVdsEeHLIWQzR24F1FwTpk DmXVtRkzZ6FtU5GLj5NA47a8EvX9wwGRWo7wWwAqNmTrhOnKWOdYOeAZvi9uVp9aZnw4 MZKw== 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=Y21ShyFkDiiLMVF1mBHW+FbynZMVIzOISJ8hleyaxUc=; b=QJivS5XUysJYdaXdNgp+Mnl7trkKJHEjyq4GfaT03yojUXVOC0MSKV1dojYNcVSK8e BWR5Q1k46zwhKjex7bYF9kuTJC4pPNqHgKeVeSuNGicq8E8SD4WV1/SxGomc3hnYDlFi 0lNIzMeF5f5IMg4M9gNTS2NWCZEU9KYDEfr70z0iZbJfvHa1GHAxk8EauMOi9ogzIU79 G3+P/KOUidGSuCfoz1iUnh4x77A1iynmNWm0DU8Fb08QJ6fB8QasT+27gnanf1RvLlEU vhMSJz+ClnH4I+zfQBFaxlw623WX9s8uytjFK0wn/ewXuowNWAH5mqhvgDL3MYRayjlI gQbg== X-Gm-Message-State: AOAM533RZhagELzqrYhSzJk9baJuhBpacyGcdsk3glMJMrb+R+qqGNDB yRME+t7ZegX+bedTSANVY0pDxvacJ5I= X-Google-Smtp-Source: ABdhPJwq7c2d0Bhx9fpS6wqcZ6oTTcQNecv9ySNClp9dIoc+1zpq4pBy6L+lQPjWyLhBEq53v49Muw== X-Received: by 2002:a05:600c:6d4:: with SMTP id b20mr16027499wmn.142.1615086526596; Sat, 06 Mar 2021 19:08:46 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id c128sm33121124wme.3.2021.03.06.19.08.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Mar 2021 19:08:45 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Gregory Heytings References: <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> <83mtvjhrzj.fsf@gnu.org> <9cff0f889435d8d03313@heytings.org> <834khq266r.fsf@gnu.org> <9cff0f8894ab45713d12@heytings.org> <16ac41d4-5718-0cec-a68b-4abcc736ee4a@yandex.ru> <109276c6-30fb-b1ca-cafa-48a15710099b@yandex.ru> <7de1aeec520f4204be5b@heytings.org> <7de1aeec52841199faed@heytings.org> <7de1aeec5237788b3d98@heytings.org> From: Dmitry Gutov Message-ID: <9bffe138-52a4-e489-f049-949657a18dd4@yandex.ru> Date: Sun, 7 Mar 2021 05:08:42 +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: <7de1aeec5237788b3d98@heytings.org> 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: 46859 Cc: 46859@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 07.03.2021 01:24, Gregory Heytings wrote: > >> >> 'find' is rarely the fastest way to list all the files in the project. >> Have you timed it alone? >> >> 'git ls-files' is usually much faster, and that's what 'project-files' >> uses under the covers. >> > > I don't see a big difference: find takes 0.006 s, git ls-files 0.002 s. > Okay, that's three times slower, but those four milliseconds are not the > bottleneck here.  I just ran some of the timing tests again, and they > are about ten milliseconds faster with git ls-files, which is not a huge > difference.  (Of course I do not object to the use of git ls-files.) Sounds like you're testing the case of a project with not many files which compensate for their number in (larger) size. That would indeed be sweet sport for using find in this scenario, so please consider that objection withdrawn. >> So if you redo your test with 'project-find-regexp' as I suggested, >> you might discover a different slowdown multiplier. >> > > I wanted to first time these things outside of Emacs, it seems to me > that it's a more objective comparison. Very well. But testing inside Emacs is important, too. Because with the results you shown as of yet, the proposed alternative is twice as slow as the existing code in the average case. Is that right? I wouldn't like searches that take 200ms now take 400ms. Emacs's overhead could alter that picture, however. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 22:22:41 2021 Received: (at 46859) by debbugs.gnu.org; 7 Mar 2021 03:22:41 +0000 Received: from localhost ([127.0.0.1]:38699 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIk08-0005Mf-Lh for submit@debbugs.gnu.org; Sat, 06 Mar 2021 22:22:40 -0500 Received: from mail-wm1-f54.google.com ([209.85.128.54]:50375) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIk07-0005MT-H6 for 46859@debbugs.gnu.org; Sat, 06 Mar 2021 22:22:40 -0500 Received: by mail-wm1-f54.google.com with SMTP id i9so3974736wml.0 for <46859@debbugs.gnu.org>; Sat, 06 Mar 2021 19:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:from:to:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=altuaoKsVg9y0CPzLztm7Yu6oldIGeNZw8vCI4U3ihk=; b=pIm6dCGhPRQl75ScgpbvQhxT4r/VJiaYVIN4+rqnroZRL3TdebzVq5ErfNgmRkB1nw IaLuPpVgpXYt9TSNq4nCwQ67VelVPpUKUaDM0+nNdCsy5zBxxAgMzIIUv35gICl/vVBt DcH+gZ9pNsqB1ndSM+aQ3KIqrIohrtuscK0CNLG4LATf9XdMbiU1xnkPDpaDbUjrD/gd hsJf7HhgTGGlEm1Xpsd9ShKgskdyjdPe7C0hZBj5DJ1lDbI4MuwyrTnNXw1+6EMIIa5Q 5jeoDEW3JenLEkpK0+8NYPfZ16JOwHvE78e2FLaett0KztvAtY6ASnYu5SLG64JNUlmE MZfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:from:to:references:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=altuaoKsVg9y0CPzLztm7Yu6oldIGeNZw8vCI4U3ihk=; b=tpaJd3CHPUNIJ+4ujoZpApzlscbKwes8qt0NkusYjKyv/2nXO3IA3j7J7GDMqa8rlv iEhjeCbTaCqW8ow9oUofj1Tl9YQt4E87FoMfj+nYgAbDov5ycE1CRSMY5i0bFefNcDPM npoCtMtiG2oFWg2ZyM3T2TiDx9il1vFLJvoO2f4+xWOi5xgzEP7AQn2TedtZzWKfHrmi MxWLuy0Fjz8n9T75plaK2GdDW8c3czfRPFbGFUplBF6H23Zg96BVnq2zyrik6sU1guER PG67iHyzciqA7bDHT6oRsasEm1A43lEhEih4WPhRVnNFem6W8DXVtLOb2rjHXcsVbxwk 2l9g== X-Gm-Message-State: AOAM531IvjdTItR6xVwN0QAY7bCVwK7dMJaW2fm98zvj2rXqI//EnhLu KROeCTsJSb0SbhkU3NmFOWyNNF8ymlw= X-Google-Smtp-Source: ABdhPJwbMBpBwQE5mN0r26XT1GNVx7VgnDMO2fZgxhm95Mc/282PbLmqVW1wyo3iAw5gUynXZzImAQ== X-Received: by 2002:a1c:4e0e:: with SMTP id g14mr15475435wmh.160.1615087353723; Sat, 06 Mar 2021 19:22:33 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id u4sm12187509wrm.24.2021.03.06.19.22.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Mar 2021 19:22:33 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el From: Dmitry Gutov To: Theodor Thornhill , juri@linkov.net, 46859@debbugs.gnu.org References: <87im69uzlt.fsf@mail.linkov.net> <25782781-4baa-5d44-99a1-2e57552ab3a0@yandex.ru> <666564dc-0252-6bf5-04e1-58c9916cffbe@yandex.ru> <92f18de5-6dae-8041-2da0-e4b782f9003e@yandex.ru> Message-ID: Date: Sun, 7 Mar 2021 05:22:29 +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: <92f18de5-6dae-8041-2da0-e4b782f9003e@yandex.ru> Content-Type: multipart/mixed; boundary="------------B63986FBEFE02685EE38A73F" Content-Language: en-US X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 46859 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 (/) This is a multi-part message in MIME format. --------------B63986FBEFE02685EE38A73F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 07.03.2021 00:26, Dmitry Gutov wrote: > - What do you think about making an effort to actually retain all the > matches in the output? That would mean interpreting the > xref-truncate-line-to value (or however the var could be renamed) as the > maximum number of chars to render on the line *per match*. And if there > is too much text between them, those parts can become "(truncated...)". > Your current implementation can cut off valid matches, and we probably > want to preserve them if feasible. OTOH, the default value could go down > to 200 with this approach. Please try out the attached preparation patch. It improves the performance of the "very long line" case drastically over here, while not doing any truncation yet. Looks like we regressed that case when we added rendering of multiple matches on the same line. We can add the truncation feature on top of it. Probably also in xref--collect-matches-1 (truncating the value of SUMMARY just before the xref-make-match call). Alternatively, we could experiment with hiding parts of the long line using some display/visibility features (except the truncate-lines variable, that one keeps things slow). That could be done in xref--insert-xrefs or somewhere nearby. That is trickier, though, given that we'll probably want to unhide it (wholly or partially) when iterating over matches inside. --------------B63986FBEFE02685EE38A73F Content-Type: text/x-patch; charset=UTF-8; name="xref-insert-xrefs-sparingly.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xref-insert-xrefs-sparingly.diff" diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index 18fdd963fb..5c5a0508de 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -886,30 +886,24 @@ xref--insert-xrefs (length (and line (format "%d" line))))) for line-format = (and max-line-width (format "%%%dd: " max-line-width)) - with prev-line-key = nil + with prev-group = nil + with prev-line = nil do (xref--insert-propertized '(face xref-file-header xref-group t) group "\n") (cl-loop for (xref . more2) on xrefs do (with-slots (summary location) xref (let* ((line (xref-location-line location)) - (new-summary summary) - (line-key (list (xref-location-group location) line)) (prefix - (if line - (propertize (format line-format line) - 'face 'xref-line-number) - " "))) + (cond + ((not line) " ") + ((equal line prev-line) "") + (t (propertize (format line-format line) + 'face 'xref-line-number))))) ;; Render multiple matches on the same line, together. - (when (and line (equal prev-line-key line-key)) - (when-let ((column (xref-location-column location))) - (delete-region - (save-excursion - (forward-line -1) - (move-to-column (+ (length prefix) column)) - (point)) - (point)) - (setq new-summary (substring summary column) prefix ""))) + (when (and (equal prev-group group) + (not (equal prev-line line))) + (insert "\n")) (xref--insert-propertized (list 'xref-item xref 'mouse-face 'highlight @@ -917,9 +911,10 @@ xref--insert-xrefs 'help-echo (concat "mouse-2: display in another window, " "RET or mouse-1: follow reference")) - prefix new-summary) - (setq prev-line-key line-key))) - (insert "\n")))) + prefix summary) + (setq prev-line line + prev-group group)))) + (insert "\n"))) (defun xref--analyze (xrefs) "Find common filenames in XREFS. @@ -1678,20 +1673,30 @@ xref--collect-matches syntax-needed))))) (defun xref--collect-matches-1 (regexp file line line-beg line-end syntax-needed) - (let (matches) + (let (match-pairs matches) (when syntax-needed (syntax-propertize line-end)) - ;; FIXME: This results in several lines with the same - ;; summary. Solve with composite pattern? (while (and ;; REGEXP might match an empty string. Or line. - (or (null matches) + (or (null match-pairs) (> (point) line-beg)) (re-search-forward regexp line-end t)) - (let* ((beg-column (- (match-beginning 0) line-beg)) - (end-column (- (match-end 0) line-beg)) + (push (cons (match-beginning 0) + (match-end 0)) + match-pairs)) + (setq match-pairs (nreverse match-pairs)) + (while match-pairs + (let* ((beg-end (pop match-pairs)) + (beg-column (- (car beg-end) line-beg)) + (end-column (- (cdr beg-end) line-beg)) (loc (xref-make-file-location file line beg-column)) - (summary (buffer-substring line-beg line-end))) + (summary (buffer-substring (if matches (car beg-end) line-beg) + (if match-pairs + (caar match-pairs) + line-end)))) + (when matches + (cl-decf beg-column (- (car beg-end) line-beg)) + (cl-decf end-column (- (car beg-end) line-beg))) (add-face-text-property beg-column end-column 'xref-match t summary) (push (xref-make-match summary loc (- end-column beg-column)) --------------B63986FBEFE02685EE38A73F-- From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 07 03:13:41 2021 Received: (at 46859) by debbugs.gnu.org; 7 Mar 2021 08:13:41 +0000 Received: from localhost ([127.0.0.1]:38858 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIoXW-0004Ij-Hm for submit@debbugs.gnu.org; Sun, 07 Mar 2021 03:13:41 -0500 Received: from heytings.org ([95.142.160.155]:46564) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIoXU-0004Ia-Up for 46859@debbugs.gnu.org; Sun, 07 Mar 2021 03:13:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1615104803; bh=YljmdQSkeDozW5tZ4rCw3Wgm9oqB3VArfRKSLQmcvhM=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=m0p5CtHMxkUhq7nK93Mf8pIITUWscLzqr/8g1eGD1Dfd6dO1lnINnubv+v9X4NBsw 4A1nJ7tXfOHX3GZc2V45lHy5tFc2z1xX/NmwMBpxLOI/Wc5US0VGfspymqmcWAFdoY JYjSUxJK9i+j9kZR6p3JAYLDv4wwAFxtV/kgXCh21VICXs1k+epL8f4uvbitic6v+6 BtXbmA+6oawnD4bXtL5vRsauy3AB5+Z4CXxbsCHjNZG3JA+wDmEF8kJGl/XrWLNwSS 2+2hzrA8xsp9893JTHrcRg5AGTN0cq8GUn5IwBQmjAX7Z78mdoNeVHZ9S53Imf22hd qrOZrzUPNTJWA== Date: Sun, 07 Mar 2021 08:13:23 +0000 From: Gregory Heytings To: Dmitry Gutov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: <9bffe138-52a4-e489-f049-949657a18dd4@yandex.ru> Message-ID: <36d537dd5d4b52827fc3@heytings.org> References: <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> <83mtvjhrzj.fsf@gnu.org> <9cff0f889435d8d03313@heytings.org> <834khq266r.fsf@gnu.org> <9cff0f8894ab45713d12@heytings.org> <16ac41d4-5718-0cec-a68b-4abcc736ee4a@yandex.ru> <109276c6-30fb-b1ca-cafa-48a15710099b@yandex.ru> <7de1aeec520f4204be5b@heytings.org> <7de1aeec52841199faed@heytings.org> <7de1aeec5237788b3d98@heytings.org> <9bffe138-52a4-e489-f049-949657a18dd4@yandex.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ePt0aOXSVB" Content-ID: <36d537dd5d207d1760da@heytings.org> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) --ePt0aOXSVB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-ID: <36d537dd5d8a3d4e7cb5@heytings.org> >> I don't see a big difference: find takes 0.006 s, git ls-files 0.002 s.= =20 >> Okay, that's three times slower, but those four milliseconds are not=20 >> the bottleneck here.=C2=A0 I just ran some of the timing tests again, an= d=20 >> they are about ten milliseconds faster with git ls-files, which is not= =20 >> a huge difference.=C2=A0 (Of course I do not object to the use of git=20 >> ls-files.) > > Sounds like you're testing the case of a project with not many files=20 > which compensate for their number in (larger) size. > As I said, my tests are performed on a fresly cloned copy of the Emacs=20 repository (~5000 files). It's not a huge project, but it's not a small=20 one either. >>> So if you redo your test with 'project-find-regexp' as I suggested,=20 >>> you might discover a different slowdown multiplier. >>=20 >> I wanted to first time these things outside of Emacs, it seems to me=20 >> that it's a more objective comparison. > > Very well. > > But testing inside Emacs is important, too. > Yes. It is important to test at each step of the pipe; step N can't=20 become faster than step N-1. > > Because with the results you shown as of yet, the proposed alternative=20 > is twice as slow as the existing code in the average case. Is that=20 > right? I wouldn't like searches that take 200ms now take 400ms. > Of course you can't get a benefit without paying a certain price. The=20 tests show that, on the Emacs repository, a search takes 250 ms instead of= =20 125 ms with GNU grep, and 100 ms instead of 50 ms with ripgrep. IMO that= =20 price is not too high, especially not for a user dialog (I don't see how a= =20 user could be annoyed, or even notice, that something takes 250 ms instead= =20 of 125 ms), but it's just my opinion. > > Emacs's overhead could alter that picture, however. > Indeed. --ePt0aOXSVB-- From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 07 15:03:17 2021 Received: (at 46859) by debbugs.gnu.org; 7 Mar 2021 20:03:17 +0000 Received: from localhost ([127.0.0.1]:41564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIzcS-0007LC-SH for submit@debbugs.gnu.org; Sun, 07 Mar 2021 15:03:17 -0500 Received: from out1.migadu.com ([91.121.223.63]:23196) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIzcO-0007L1-Vz for 46859@debbugs.gnu.org; Sun, 07 Mar 2021 15:03:15 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1615147391; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YBX+2mt3H5LDh9Jd36NvDkDYHAlit5nL45OAIk21qAU=; b=c3Q2oNWT78Jr8agXHS15EvKLTjwGQU1FqYyfjk0aEyudB/xZe+eP/5XRQZUX5SUCVWCFY4 5lMaCN2lnGYnnxMEejv3jGGuc3+2pGy8Ekjeh81erjYisWqEmthQfwRmlYgRfxkvgo7Xw8 F4buzjWr/QA0AVMI8ImC1v1LLmwrVuMeVUnP3pFySlECohh1bhh9LGXdgO6yM6K06c0aK0 X0wTUn6zDtlaq9s4/Dq5pZdBdqpVEnnc1p/wRc9jRlLlqTpyXaORHtKHX+MVVAaSKdQUZO 4x5sFvefx7d/Lc3H9Ewa6T/hcdxIhPYoZCRlVfQo1gGrElYBCJMLuiqVc6m1bQ== From: Theodor Thornhill To: Dmitry Gutov , juri@linkov.net, 46859@debbugs.gnu.org Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: References: <87im69uzlt.fsf@mail.linkov.net> <25782781-4baa-5d44-99a1-2e57552ab3a0@yandex.ru> <666564dc-0252-6bf5-04e1-58c9916cffbe@yandex.ru> <92f18de5-6dae-8041-2da0-e4b782f9003e@yandex.ru> Date: Sun, 07 Mar 2021 21:03:09 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46859 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 (-) Hi! > > Please try out the attached preparation patch. > > It improves the performance of the "very long line" case drastically > over here, while not doing any truncation yet. Looks like we regressed > that case when we added rendering of multiple matches on the same line. > Yes, this seems to help a lot. Now the search is down from 11 seconds to 1.09. It is comparable to the other good efforts. > We can add the truncation feature on top of it. I think we should, since moving around in the xref-buffer is still very slow. > > Probably also in xref--collect-matches-1 (truncating the value of > SUMMARY just before the xref-make-match call). > > Alternatively, we could experiment with hiding parts of the long line > using some display/visibility features (except the truncate-lines > variable, that one keeps things slow). That could be done in > xref--insert-xrefs or somewhere nearby. That is trickier, though, given > that we'll probably want to unhide it (wholly or partially) when > iterating over matches inside. At this point I'm really thinking that truncating without bothering too much about losing information is worth it, and the added complexity by retaining information would only make regressions more feasible. I assume these files are _actually_ read once every blue moon. To maximize the speedup should be at a higher priority than retaining the matches, IMO. In any case, if there is a hit on one of these long lines, the current efforts will render them as results to the xref buffer. Searching or editing these files wouldn't be emacs' strength anyways :) My proposal for the "best" fix would be: - truncating long lines by default, both for grep and ripgrep - adding some variation of the "-M " value for ripgrep by default What do you think? -- Theo From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 07 15:16:24 2021 Received: (at 46859) by debbugs.gnu.org; 7 Mar 2021 20:16:24 +0000 Received: from localhost ([127.0.0.1]:41575 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIzpA-0007dz-BZ for submit@debbugs.gnu.org; Sun, 07 Mar 2021 15:16:24 -0500 Received: from out1.migadu.com ([91.121.223.63]:26078) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIzp7-0007dl-AZ for 46859@debbugs.gnu.org; Sun, 07 Mar 2021 15:16:23 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1615148179; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=okQnYE3jwCSp11O9vhcyI4egdBQmvoojg7nMnJnDYts=; b=SL6Ec+oBsPQ9t7gOPllI8+AkyrZUeHeBfdZ65the8+BADl+Y7jHzah+cXwiPpURSZNbm0Y bdSTGFHjlW7ZP/n1tIBKGF0qvnhiEcpVMzjrTP0azDQVqYJ058tFg0sHGv0gVWT7ivoiQv oiMv9MgMgBgLG+ki4sI1FO7QG/ZiKfIcXC4dq1MJsVZjOjwdTOoShLWY3Rg3MmlN3S6rHB jJUrt8uIZ0NCC/5ZsWqQrsobI+JeftsSEuZlidVWzPVfxxkZiksh/LyQr9L94MSIHIx6AR H2rZz+GmzswKEjqnX3pd29Rv4oU7XYLBTzp9P1stc2O87dVJ0nUkm9v5GWWVaw== From: Theodor Thornhill To: Dmitry Gutov , juri@linkov.net, 46859@debbugs.gnu.org Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: <92f18de5-6dae-8041-2da0-e4b782f9003e@yandex.ru> References: <87im69uzlt.fsf@mail.linkov.net> <25782781-4baa-5d44-99a1-2e57552ab3a0@yandex.ru> <666564dc-0252-6bf5-04e1-58c9916cffbe@yandex.ru> <92f18de5-6dae-8041-2da0-e4b782f9003e@yandex.ru> Date: Sun, 07 Mar 2021 21:16:18 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46859 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 (-) Hi Dmitry, > I just got around to testing this properly (sorry), No worries > and so far I've been > able to reproduce the slow behavior only when there are many matches in > the "big long line" file. I'm using a 500KB minified CSS as an example. > > When there are only a few matches, the search is relatively > instantaneous. So that's a weird mismatch with your reports. If you have > some details to add to reproduce the slowdown in the "few matches" case, > that could be helpful too. Hmm. Theres always a possibility of a human error on my part during the benchmarks, of course! > > I'm currently looking at the patch and trying to figure out whether we > could apply some smaller change, or a change not in xref--insert-xrefs > (which is relatively complex already) with the same benefits. > Yeah, I also wanted to not add too much to that function, but I couldn't get improvements other places :) > Also: > > - Could you explain the change to xref--collect-matches-1 in the most > recent patch? In my testing it doesn't move the needle at all, and it > seems unnecessary because neither Grep or Ripgrep report matches on the > same line separately with the current arguments that we pass to them. > But if we did... what's the idea? Skip all subsequent matches, no matter > if they're far or close? > Yeah, skipping subsequent matches yielded an improvement from ~1.09 to ~1.03 seconds, so not the biggest improvement, but it was consistent. Thus I kept it. > - What do you think about making an effort to actually retain all the > matches in the output? I see why we would want to do that, but as I mentioned in the last mail I sent, these files are mostly "junk" anyways. However, it is probably best to be able to retain them if we can. I just think speed should be more important > That would mean interpreting the xref-truncate-line-to value (or > however the var could be renamed) as the maximum number of chars to > render on the line *per match*. And if there is too much text between > them, those parts can become "(truncated...)". Your current > implementation can cut off valid matches, and we probably want to > preserve them if feasible. OTOH, the default value could go down to > 200 with this approach. > Yeah, I had an implementation where I "snipped" between matches and concatenated them together, but that still yielded too large a line for my emacs on a 3 million char length file, so I scrapped that idea. I guess it still is possible, though! > What I mean is, we can provide the "fullest featured" default behavior, > one which never omits any valid matches and just truncated the line > context around them, and the users who want even faster searches (at the > cost of missing matches, esp. in find-replace scenarios) have something > else to customize too. Yeah, I think this is the best approach too. Especially for grep users. I'll still probably use (add-to-list 'xref-search-program-alist '(ripgrep . "xargs -0 rg -nH --no-messages -g '!*/' -e -M 400 --max-columns-preview | sort -t: -k1,1 -k2n,2")) Or something to that effect anyways :) -- Theo From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 07 15:26:19 2021 Received: (at 46859) by debbugs.gnu.org; 7 Mar 2021 20:26:19 +0000 Received: from localhost ([127.0.0.1]:41592 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIzyl-0007sy-GL for submit@debbugs.gnu.org; Sun, 07 Mar 2021 15:26:19 -0500 Received: from out0.migadu.com ([94.23.1.103]:19163) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIzyj-0007sq-Pk for 46859@debbugs.gnu.org; Sun, 07 Mar 2021 15:26:18 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1615148776; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dPoKCXddVdmtBgKQSfWNBvJf/GSMn044c3gDkEIwwyA=; b=RMxpdhFYO26v5aOq9U59g7QubOOtAap8T9cw9Q9vAO5SkuPz7rKie6SHlH2my3h0T9+N9V Nhu8PlXvhY14DEwy6YRiQd+pjQk/AOnHoIoa+/xzwYTimTOh/qTe+fcosUXqCmSB9eM9WH SZdHiuONHlk0fYEjWbT5b4ao/9NJ0xdRiOplPRUAl32RfSmbiwXuVH15SBDZbKxCpMPGpE n4HpBLTeCPaC5AlXiPv8dMw2cgASvdR6QNnyD5qz2JRSuOH+fEQhwpBHjIyytSg7NqeXQ4 sWGMOUOJ84HsAAsDQC4t2cqgUXF1rjUwXCOVxrUfOCFSwv3WlvB4qZuEcqKMJQ== From: Theodor Thornhill To: Dmitry Gutov , juri@linkov.net, 46859@debbugs.gnu.org Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: References: <87im69uzlt.fsf@mail.linkov.net> <25782781-4baa-5d44-99a1-2e57552ab3a0@yandex.ru> <666564dc-0252-6bf5-04e1-58c9916cffbe@yandex.ru> <92f18de5-6dae-8041-2da0-e4b782f9003e@yandex.ru> Date: Sun, 07 Mar 2021 21:26:14 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46859 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 (-) Forgot to say: I'll probably try to make some new benchmarks with all the approaches when I get some free time. -- Theo From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 07 21:48:51 2021 Received: (at 46859) by debbugs.gnu.org; 8 Mar 2021 02:48:51 +0000 Received: from localhost ([127.0.0.1]:41820 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJ5ww-0000EL-TE for submit@debbugs.gnu.org; Sun, 07 Mar 2021 21:48:51 -0500 Received: from mail-wr1-f46.google.com ([209.85.221.46]:39939) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJ5wq-0000E2-5n for 46859@debbugs.gnu.org; Sun, 07 Mar 2021 21:48:49 -0500 Received: by mail-wr1-f46.google.com with SMTP id l11so6429107wrp.7 for <46859@debbugs.gnu.org>; Sun, 07 Mar 2021 18:48:44 -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=QkpHxE/ZR7iRyCSDLnO+IlSHHq3bQjWWVqQHYKvyWPo=; b=oYdWnGE32K7e7ZNk+EY8+Q03J2ormxa+zdWWRPG3kI7po+lwkMnOYfqb5BFGWRYdfG 6YC03IqSA+GVRzaMkDx8l/wH/8Uy4qXFP9BDHXjj0OO2yuB8MLtFOKGcC5aOrRTJm1Ny lCWwsILmvuncZYqyd1I28JcrYnNRTsGqrOBe70HzRGGnb5Mrp+ikdAHq4EBaS9xjG5CE gLpkWnBqc4ZlPiDYO+0671fvGbLqScX2eFkErvzBAOftHppMBGN9LlGlFQ5DGpJEfHxs BARROzawuDhTw8bYsQjJgTEQgXqmbf1oSyp4icaEUgn+hcQMPL1n7iPkOWDmyio1N3a9 RaaQ== 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=QkpHxE/ZR7iRyCSDLnO+IlSHHq3bQjWWVqQHYKvyWPo=; b=I2M39EdwwFDE0gUYNPHhBhbuJGAeLxtxF2wK/e0T9U3dxdhbEE1jgvi8ckY9inwTcM gaQHJ6JqONI///ezd4mR48Gs5cWqlQW+tzTthiKLI1TvZeCCFZZF1EFo6G5mam4dtagg f+mgdH0uAa8Fe5sHLH1PmDiGZwGM/aPvIoZ34pAqnH1zmrbsbqmot+UHwlXMRMhP/hj+ 7O0UWdyPa+yZ8taXHNnZYPBA5fT4FSVCxs654OlO6g0eUiX6vTNC4tNtVouhahH6K7d0 28mKRiSMwNKAH4gDmXNvzeSTHHgXflYfhcmTpKHljwaPlkvSAyy9s/Jr8pGa2A6AaZ51 KVIA== X-Gm-Message-State: AOAM530K+g7oRpKw7kI2fVtn3piE+CLUnPAJiaonXbzPoVEIAYpeUjXs 4sNzoos0jkHNQs5sIbv47frVDu/5J0o= X-Google-Smtp-Source: ABdhPJxf24ii+jatUzWdCHzgF1J9rcZ/+PhHeqnhJF9KKKRgA6DASheZZdVdZsZvcFqyGWvDXUdSyw== X-Received: by 2002:a05:6000:1547:: with SMTP id 7mr20522250wry.301.1615171718104; Sun, 07 Mar 2021 18:48:38 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id i26sm17913243wmb.18.2021.03.07.18.48.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Mar 2021 18:48:37 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Theodor Thornhill , juri@linkov.net, 46859@debbugs.gnu.org References: <87im69uzlt.fsf@mail.linkov.net> <25782781-4baa-5d44-99a1-2e57552ab3a0@yandex.ru> <666564dc-0252-6bf5-04e1-58c9916cffbe@yandex.ru> <92f18de5-6dae-8041-2da0-e4b782f9003e@yandex.ru> From: Dmitry Gutov Message-ID: Date: Mon, 8 Mar 2021 04:48:33 +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: 46859 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 (/) Hi again, On 07.03.2021 22:03, Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: >> Please try out the attached preparation patch. >> >> It improves the performance of the "very long line" case drastically >> over here, while not doing any truncation yet. Looks like we regressed >> that case when we added rendering of multiple matches on the same line. >> > > Yes, this seems to help a lot. Now the search is down from 11 seconds to > 1.09. It is comparable to the other good efforts. Excellent! I've pushed this change, along with some stuff it depends on, to master in commit 8e103ebef1. >> We can add the truncation feature on top of it. > > I think we should, since moving around in the xref-buffer is still very slow. I see that too. >> Probably also in xref--collect-matches-1 (truncating the value of >> SUMMARY just before the xref-make-match call). >> >> Alternatively, we could experiment with hiding parts of the long line >> using some display/visibility features (except the truncate-lines >> variable, that one keeps things slow). That could be done in >> xref--insert-xrefs or somewhere nearby. That is trickier, though, given >> that we'll probably want to unhide it (wholly or partially) when >> iterating over matches inside. > > At this point I'm really thinking that truncating without bothering too > much about losing information is worth it, and the added complexity by > retaining information would only make regressions more feasible. With the latest change, retaining that info should be particularly difficult: you adjust the SUMMARY values inside xref--collect-matches-1 using the context information at hand, and that's almost it (mostly note to self: also need to update xref--outdated-p accordingly). > I > assume these files are _actually_ read once every blue moon. To maximize > the speedup should be at a higher priority than retaining the matches, > IMO. In any case, if there is a hit on one of these long lines, the > current efforts will render them as results to the xref > buffer. Searching or editing these files wouldn't be emacs' strength > anyways :) Depends on the performance improvement multiplier, I suppose. But I'm inclined to believe that if the user did search those files, and did not include them in, say, project-vc-ignores value, they probably want to be able to see all matches. Sometimes losing valid hits can be a significant problem, and since Xref is implemented in an opaque way it is, we should make an effort not to omit information in the name of performance, at least while feasible. > My proposal for the "best" fix would be: > > - truncating long lines by default, both for grep and ripgrep > - adding some variation of the "-M " value for ripgrep by default > > What do you think? I think that would be a good non-default option for users who really know what they're doing. And it's already available for those who use ripgrep. After all, there can be files out there with some long lines (not kilobytes long, probably, but >500 chars? why not) that aren't minified CSS or JS. If those were the only problem, we could as well recommend everybody add those to their project ignores and be done with it (which is what I usually do personally). From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 07 21:57:02 2021 Received: (at 46859) by debbugs.gnu.org; 8 Mar 2021 02:57:02 +0000 Received: from localhost ([127.0.0.1]:41828 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJ64s-0000Qr-Ao for submit@debbugs.gnu.org; Sun, 07 Mar 2021 21:57:02 -0500 Received: from mail-wm1-f51.google.com ([209.85.128.51]:37791) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJ64r-0000QM-4o for 46859@debbugs.gnu.org; Sun, 07 Mar 2021 21:57:01 -0500 Received: by mail-wm1-f51.google.com with SMTP id f22-20020a7bc8d60000b029010c024a1407so2900307wml.2 for <46859@debbugs.gnu.org>; Sun, 07 Mar 2021 18:57:01 -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=H+QyGXWYqfgmBXUYZ3AB+K2oxGxNxkUrb+d1lRaKVhs=; b=b3prgwsmJCbIxTpAbgClG8HESGXCcvlSh7+GF12ZVsXpVzVt5SHuOKo7ODhRh+jnMo 1UyKgStVwFch/aGB88gmacDo3EAClLKp8165w/jRMuN7oWN7Czv3wuLoOIxvvKnL1eyN TbORP0ZEgpKlUewVx9qmmeLqZKcznd1Ozw3LA5WnFE1eZnLJBYOSbSWsm5DRd/RN0GxQ b+Tl/TCM+Iz0rmhh4l/fS9jkSKmZUyvXfJN4GRppAzm2R+f47xVtQlgzOt2DseWPjYyH +MHml3901WU91HL9552M5mb+qDAf94FBiDD+w+4BuOVV/njCFfpIgIPiEm9HUCJ+ySTm DO0w== 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=H+QyGXWYqfgmBXUYZ3AB+K2oxGxNxkUrb+d1lRaKVhs=; b=L0dAn3OGv1JjPsXRm+jkJ1luTM036amRjF+KnjQ0XlwsYBe//waMwjY4WfKejyDx07 B3yZZ7h6LQtk+c+kldDYqCaR0exTPXoQZIZOMtCnxXzB9m+38f32LBAM+HcIT/jqonWi +FOYM+DOUXM5pbCZDOGP8xDT1WoxxGPZpnAtcaMXF3DPnD2IZxAlxhM5wjiRZ3mbTShC VnSWmTS8BBTyHfr22W77zFpzpxy9rYOuFg+xk6fTUgTRnugEKzz1dIeK/XaNAF5NUzaz iNZqTem1qeQV+tdUqrjWH+cpdmoyIkuC1ardraDzSxMXqSM/yVP8qerMVyTywCgGk2XZ D2ag== X-Gm-Message-State: AOAM532JG+pP1o4YzNoxPgRz92S6xFjKrOj9bunEQdxbi9eVSV7jnvTP Z/T8cn0Nz1v2E7LLsz2nsVT6MKwEGrk= X-Google-Smtp-Source: ABdhPJw190gM+iWcaWy3o25yIC+AqjBh7i7CbNSvqp6WWvXCMFLMONBV/r+NwQBAIRMT04IAHBg1sw== X-Received: by 2002:a1c:23d0:: with SMTP id j199mr19846581wmj.52.1615172215199; Sun, 07 Mar 2021 18:56:55 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id u4sm16805487wrm.24.2021.03.07.18.56.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Mar 2021 18:56:54 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Theodor Thornhill , juri@linkov.net, 46859@debbugs.gnu.org References: <87im69uzlt.fsf@mail.linkov.net> <25782781-4baa-5d44-99a1-2e57552ab3a0@yandex.ru> <666564dc-0252-6bf5-04e1-58c9916cffbe@yandex.ru> <92f18de5-6dae-8041-2da0-e4b782f9003e@yandex.ru> From: Dmitry Gutov Message-ID: <5cca8644-f111-57b6-442d-e39f21090fea@yandex.ru> Date: Mon, 8 Mar 2021 04:56:47 +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: 46859 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 07.03.2021 22:16, Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: >> That would mean interpreting the xref-truncate-line-to value (or >> however the var could be renamed) as the maximum number of chars to >> render on the line*per match*. And if there is too much text between >> them, those parts can become "(truncated...)". Your current >> implementation can cut off valid matches, and we probably want to >> preserve them if feasible. OTOH, the default value could go down to >> 200 with this approach. >> > Yeah, I had an implementation where I "snipped" between matches and > concatenated them together, but that still yielded too large a line for > my emacs on a 3 million char length file, so I scrapped that idea. I > guess it still is possible, though! It should be able to perform better now, now that xref--insert-xrefs doesn't have to delete most of the text its inserted in these scenarios. We didn't really anticipate summary lines this long and the memory churn that came with them. If you still get lines that are loo long in these cases, even with all extra text snipped away, hiding parts of the summary using text properties should be possible. I just tried putting 'invisible' on the whole line after column 600, and scrolling became instantaneous again. As long as we undo these properties (or, perhaps, scroll the visible part?) when xref-next-line is called, the user would still be able to visit all matches. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 07 22:24:49 2021 Received: (at 46859) by debbugs.gnu.org; 8 Mar 2021 03:24:49 +0000 Received: from localhost ([127.0.0.1]:41843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJ6Vl-000174-8k for submit@debbugs.gnu.org; Sun, 07 Mar 2021 22:24:49 -0500 Received: from mail-wm1-f46.google.com ([209.85.128.46]:46684) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJ6Ve-00016n-Tm for 46859@debbugs.gnu.org; Sun, 07 Mar 2021 22:24:47 -0500 Received: by mail-wm1-f46.google.com with SMTP id d139-20020a1c1d910000b029010b895cb6f2so2891593wmd.5 for <46859@debbugs.gnu.org>; Sun, 07 Mar 2021 19:24:42 -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=HyRLmnT7BlVNJvl78mIcg4WBFm31yk0pI/lQWYll5vo=; b=Ssubsd/HCiHAktXg6iNigCh8+JlE0JthZ3UGQeXwGR/x3/8aRqNP8ilCFQLG4yhsD4 fZGLJ9Nsvx0O5+qQS08WQsKgLpib3d3azCRjhBF74cQ5t+LNJnEBWWScX/9xRAh3oluR IspESA3tUCy0CiIphvuN9wDdTWSZUZ7mIw61FAlYM3TebfahDjYdnUjFXOpN4/1JV8TE Txoubdr4BPFKAPGB+wJrGpWVr9CI426mjN1MUai13WjXt4tKv4PyHFml6WjfugY7e7RW +LVofEifIb6kyEazdOMSVMfV9hn7nTOWk9BNyjTfHzScQM8aj0oh5dTONl8cqHMVETkL vEgA== 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=HyRLmnT7BlVNJvl78mIcg4WBFm31yk0pI/lQWYll5vo=; b=sfv1/t9W+2sxKRUzjMSTmlszgdcdLB2VGqKuoDof91X1Q5pXrIRNYetLJkyBpiFsFX pvRS9Fv2H7A6Exd23onk0TnfmFYwOHOZnJFkk15s/zuXqNi2k7y8p41av6403bZBFFoY Y9IbKA9RJ+DtAbrTpIkPwSiEU+sb/zWHcY698PItdYnJ04wjLkPP4HqJWb6OLhPcP3NJ LiNG1ufKUWHN4Czfthum8ySNZkTvKXOe43WR4+LDZs4E5XFux5KkvTMsxNozWM4N3lj3 gXHS3EET8xJwS3nAEq2UKWLjCr/YVqS3aRFM9x6cBOtkhKw/7j6aInuFnTh5qz/GZGNF LmzA== X-Gm-Message-State: AOAM532kTp02Q/brEXEr5BrRtyxG/DQTQJDMkCYB9ION+2ogYo3rqh59 K7oYyWDLG23nP+fyH9lE24KdOqNjbfE= X-Google-Smtp-Source: ABdhPJxvnT1revoMb0UsYX8L8WLx9oa+1MZYLA92Gx15M38Ur4xdVGSUh4gSp4RfwJWQg1XLM0hbeA== X-Received: by 2002:a1c:c90c:: with SMTP id f12mr20282958wmb.98.1615173876985; Sun, 07 Mar 2021 19:24:36 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id v9sm16318441wrn.86.2021.03.07.19.24.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Mar 2021 19:24:36 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Gregory Heytings References: <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> <83mtvjhrzj.fsf@gnu.org> <9cff0f889435d8d03313@heytings.org> <834khq266r.fsf@gnu.org> <9cff0f8894ab45713d12@heytings.org> <16ac41d4-5718-0cec-a68b-4abcc736ee4a@yandex.ru> <109276c6-30fb-b1ca-cafa-48a15710099b@yandex.ru> <7de1aeec520f4204be5b@heytings.org> <7de1aeec52841199faed@heytings.org> <7de1aeec5237788b3d98@heytings.org> <9bffe138-52a4-e489-f049-949657a18dd4@yandex.ru> <36d537dd5d4b52827fc3@heytings.org> From: Dmitry Gutov Message-ID: Date: Mon, 8 Mar 2021 05:24:33 +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: <36d537dd5d4b52827fc3@heytings.org> 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: 46859 Cc: 46859@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 (/) Hi Gregory, On 07.03.2021 10:13, Gregory Heytings wrote: > As I said, my tests are performed on a fresly cloned copy of the Emacs > repository (~5000 files).  It's not a huge project, but it's not a small > one either. Hmm, both 'find' and 'git ls-files' take a little more than that on the Emacs repository. But my impression on 'find' is skewed because it performs much worse as soon as we try to ignore files with it. When no predicates are used, it's fairly fast and shouldn't be too much of a problem in this comparison. >> Because with the results you shown as of yet, the proposed alternative >> is twice as slow as the existing code in the average case. Is that >> right? I wouldn't like searches that take 200ms now take 400ms. >> > > Of course you can't get a benefit without paying a certain price. Well, yes and no. I have just improved performance in the case under discussion significantly with no loss in functionality or measurable loss of performance in "normal" cases. I don't mean to be discouraging, but the benefits should be pretty great for us to pay the price of 2x slower matching speed. And it wouldn't be necessary of Grep had an option to limit the displayed context around the match without us mucking with the regexp. It would solve the issue of incorrect byte position, too. > The > tests show that, on the Emacs repository, a search takes 250 ms instead > of 125 ms with GNU grep, and 100 ms instead of 50 ms with ripgrep. IMO > that price is not too high, especially not for a user dialog (I don't > see how a user could be annoyed, or even notice, that something takes > 250 ms instead of 125 ms), but it's just my opinion. The bigger the project, the longer it will take. Emacs is not the biggest project size we want to support. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 08 03:26:58 2021 Received: (at 46859) by debbugs.gnu.org; 8 Mar 2021 08:26:59 +0000 Received: from localhost ([127.0.0.1]:42037 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJBEA-0000Mk-O7 for submit@debbugs.gnu.org; Mon, 08 Mar 2021 03:26:58 -0500 Received: from heytings.org ([95.142.160.155]:47728) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJBE8-0000Mb-Hu for 46859@debbugs.gnu.org; Mon, 08 Mar 2021 03:26:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1615192015; bh=X7uGAn+XLBQxJnL1e1AEYerAox2xxrphuAhtC8GlcoY=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=gm1tmdIsbjgyTDY7PH5zHZlGrQQnAdKojgxryr36YwFid05kcIFaUj95aGmEjPQuJ oJhXlf81AlfCXf4hzbTq+i8mGiHRD9+kF6zHzHBq0SQSn9BE8xOQZHgywjVS9WsqCH Vak7FPhN0sb7hfXr9MOa12s8S9hYneARZx3tPyQ9+6IrXtWPoryd5Oqzu78vGC3eVO H7mglJWVtShGGSnf0E06/3UtOJTuxaPvAGAV/AhGMueCcqsa7ntCAfWSKZJQZNenXo 3eZJyhiFU8Fjep2VVy97Btwti5lqTHytSZ/t29QoaP4ggDN9f0Eh6nLLt1XAuAltBl MKonzDvV3ITiA== Date: Mon, 08 Mar 2021 08:26:54 +0000 From: Gregory Heytings To: Dmitry Gutov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el In-Reply-To: Message-ID: <3120d19b1d215cabb415@heytings.org> References: <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> <83mtvjhrzj.fsf@gnu.org> <9cff0f889435d8d03313@heytings.org> <834khq266r.fsf@gnu.org> <9cff0f8894ab45713d12@heytings.org> <16ac41d4-5718-0cec-a68b-4abcc736ee4a@yandex.ru> <109276c6-30fb-b1ca-cafa-48a15710099b@yandex.ru> <7de1aeec520f4204be5b@heytings.org> <7de1aeec52841199faed@heytings.org> <7de1aeec5237788b3d98@heytings.org> <9bffe138-52a4-e489-f049-949657a18dd4@yandex.ru> <36d537dd5d4b52827fc3@heytings.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="G0TePI94Kb" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@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 (-) --G0TePI94Kb Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable >> As I said, my tests are performed on a fresly cloned copy of the Emacs= =20 >> repository (~5000 files).=C2=A0 It's not a huge project, but it's not a= =20 >> small one either. > > Hmm, both 'find' and 'git ls-files' take a little more than that on the= =20 > Emacs repository. > Not on my (not recent) development laptop... > > And it wouldn't be necessary of Grep had an option to limit the=20 > displayed context around the match without us mucking with the regexp.=20 > It would solve the issue of incorrect byte position, too. > I just submitted a feature request for GNU grep:=20 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D47001 . If it's accepted /= =20 implemented, I'll do the same for ripgrep. --G0TePI94Kb-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 08 06:48:07 2021 Received: (at 46859) by debbugs.gnu.org; 8 Mar 2021 11:48:07 +0000 Received: from localhost ([127.0.0.1]:42290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJEMo-0005Mf-QA for submit@debbugs.gnu.org; Mon, 08 Mar 2021 06:48:07 -0500 Received: from mail-ej1-f48.google.com ([209.85.218.48]:44979) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJEMl-0005M8-M7 for 46859@debbugs.gnu.org; Mon, 08 Mar 2021 06:48:05 -0500 Received: by mail-ej1-f48.google.com with SMTP id ox4so4135359ejb.11 for <46859@debbugs.gnu.org>; Mon, 08 Mar 2021 03:48:03 -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=5Sr0jv7g4+tNzHEiyKHrfGj57tzvKNPJjbSglvie7+c=; b=fDhFRLlnxcEzFG5v9qAUUsmPTU0o3sLTtU8EopaIr8Oc1+/WO7VO/Ai9slsXuec0yo IwNhUIwRi0kT75A27oJ3zkwxeaOsdcJ3LPKcBt2VoOlbQSDsp9g3C9zAxcmtcpcManPZ OQ1EcyC3WkObwHK1rSDGeBqSOvat+e6oUlLfL17PWOV5qJ7hZprncE8a5P3/OhZmJx0z 38e86hN6dXr4uVuF3KDl5INhrCidRMkYKJwOinKFnD95u6H1Jv97hvrAVuaQb/cz8YSI S5y5nT45E5ACjoDoF611/a38OMTwcwgCyU2tsqPeEZwx4vPuuW44nGH37doC7rXU3PLw NQzA== 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=5Sr0jv7g4+tNzHEiyKHrfGj57tzvKNPJjbSglvie7+c=; b=AUWL/WswCEdiURrpNup8Au/ImRiI46ROBw1DhwHyb0qQUjhSEieAt4YZ8qDoMpNZ8D FTvngUpMqLcy/nIyvAdTiylou7LSQClpfafn+KjrV4wj8yxOzIXfiISOC/B5DgxPcFjJ 5s5Q4hbIOKR1+lG4Kr8Mwp5HSegL8B52uRXWkT/XzSwv+jHbqwjEnVMJAWbYLiDTDub9 KcB8uaTUqMtSF54Fm2Qu5wD46zS/+Nk42vqNmKSM1exCI8soXyQFmupuWRSxcxQpCseu mOan90a9uP/eI9pyrnTuFhi/D60rMXtdsS1DjI85HskkjZL+40hf3yAOQkZbqs0v9yJ5 uTYg== X-Gm-Message-State: AOAM530QBpEhtK7gBQ1XkPbt5IkGuFWfGN6GRBgiGngA3dw7z7KpvKDS o9tvTZSNjFBjHCnIv+Bj2R6YJbrNKgs= X-Google-Smtp-Source: ABdhPJzP246ur8W23fxTtb/mUQoXnMZVp7fP8VzEO7+/x0SznVzBtz2obtURlBrM8kqbQPDFEp6aZQ== X-Received: by 2002:a17:906:cd12:: with SMTP id oz18mr14684405ejb.498.1615204077711; Mon, 08 Mar 2021 03:47:57 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id r17sm7014677edt.70.2021.03.08.03.47.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Mar 2021 03:47:56 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Gregory Heytings References: <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> <83mtvjhrzj.fsf@gnu.org> <9cff0f889435d8d03313@heytings.org> <834khq266r.fsf@gnu.org> <9cff0f8894ab45713d12@heytings.org> <16ac41d4-5718-0cec-a68b-4abcc736ee4a@yandex.ru> <109276c6-30fb-b1ca-cafa-48a15710099b@yandex.ru> <7de1aeec520f4204be5b@heytings.org> <7de1aeec52841199faed@heytings.org> <7de1aeec5237788b3d98@heytings.org> <9bffe138-52a4-e489-f049-949657a18dd4@yandex.ru> <36d537dd5d4b52827fc3@heytings.org> <3120d19b1d215cabb415@heytings.org> From: Dmitry Gutov Message-ID: <254ddd87-cd3e-048c-96bc-7002b927060b@yandex.ru> Date: Mon, 8 Mar 2021 13:47:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <3120d19b1d215cabb415@heytings.org> 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: 46859 Cc: 46859@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.03.2021 10:26, Gregory Heytings wrote: > >>> As I said, my tests are performed on a fresly cloned copy of the >>> Emacs repository (~5000 files).  It's not a huge project, but it's >>> not a small one either. >> >> Hmm, both 'find' and 'git ls-files' take a little more than that on >> the Emacs repository. >> > > Not on my (not recent) development laptop... ~/v/emacs-master (master|…) $ time find . >/dev/null ________________________________________________________ Executed in 31,65 millis fish external usr time 8,78 millis 0,00 millis 8,78 millis sys time 23,05 millis 1,10 millis 21,95 millis *shrug* >> And it wouldn't be necessary of Grep had an option to limit the >> displayed context around the match without us mucking with the regexp. >> It would solve the issue of incorrect byte position, too. >> > > I just submitted a feature request for GNU grep: > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=47001 .  If it's accepted / > implemented, I'll do the same for ripgrep. Thank you. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 09 21:06:56 2021 Received: (at 46859) by debbugs.gnu.org; 10 Mar 2021 02:06:56 +0000 Received: from localhost ([127.0.0.1]:48321 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJoFT-0006du-Q5 for submit@debbugs.gnu.org; Tue, 09 Mar 2021 21:06:56 -0500 Received: from mail-ej1-f53.google.com ([209.85.218.53]:34511) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJoFR-0006dg-RN for 46859@debbugs.gnu.org; Tue, 09 Mar 2021 21:06:55 -0500 Received: by mail-ej1-f53.google.com with SMTP id hs11so34169546ejc.1 for <46859@debbugs.gnu.org>; Tue, 09 Mar 2021 18:06:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:from:to:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=SLYvQE56+CkTAbcXgMqA+OSmE6ef/mqAmVQDokSUnkI=; b=Sx4OtC/FFDxQvf9trfb49BKSeI2oFGFGwii7kX2G75wqs5W/bZA6CwWYBURvADmwZ+ 0Hx/yC510Xaob3SPA7mjfl+5Gga1pJZhu+8XCw6ZARBTz3bD1TrEd8X7uTr5rYtTL3nB FO+/VJkPBatNc4X/Dy2MIAg2smt2+HPJ0IKt2xuXkkYaJkTWjJkGvAOz+FfH/DwZLmeW Y8a4Ydl9LYJY9zN7C+B2Gu2A9Zlo8a/VKhd1cWwHDPJWMuw15FWvweKkAe1Qd+RLhkxo TmdP5G0WuggL6JONrCAINVgjDVhwegD9hSGvQrBiRNHH7AQHHB8JDiWy4urS7IogpYzq /dwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:from:to:references:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=SLYvQE56+CkTAbcXgMqA+OSmE6ef/mqAmVQDokSUnkI=; b=B8IGp6oFBdxHyS4S06Db3Togronq5p46sIvyPGAP5YT/cucCFHoO0L9ILDOEEpeg7G bAm/wGS/JFNtYvSmhIfXvmmVdVBGr0J3FyqyJXLR2z4n2LCFPYxFa462qZ6bRICdKLzV ZBbcOomy2bx+wTsmdboacRvk9QZbur1e++mFgVjuJqnaBbATWqHHFEl6F4r3V7m+yGaj Oe3WZv8OAgc73QnIbk3U16fR9ZLxZbJ4tEXqcUauXGeA/+0pcgVf6Wx9ojZb+Mo6xLAT CJsE+Prh+sl+Apv+SVYuaJsChckDpA+lZMOHSvctqbYagOlS2yugkBTCf3SJM+eRpIDK d+eg== X-Gm-Message-State: AOAM533PWyWM8zlDv94JtRlpK6bF45Omccg54nbf0jMZXhHyAY36jErV fiPu5+6ZfzfF9GRqY6G8NQ03GgOl3qs= X-Google-Smtp-Source: ABdhPJzj8hru0fcnDTYKljWJ6hSSP+ku7DgYnUpDE/kkttbQIy1hOpqla+T52h3232BZ45XVgckpyA== X-Received: by 2002:a17:906:6047:: with SMTP id p7mr1017137ejj.400.1615342007867; Tue, 09 Mar 2021 18:06:47 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id l1sm5303999edt.59.2021.03.09.18.06.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Mar 2021 18:06:38 -0800 (PST) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el From: Dmitry Gutov To: Theodor Thornhill , juri@linkov.net, 46859@debbugs.gnu.org References: <87im69uzlt.fsf@mail.linkov.net> <25782781-4baa-5d44-99a1-2e57552ab3a0@yandex.ru> <666564dc-0252-6bf5-04e1-58c9916cffbe@yandex.ru> <92f18de5-6dae-8041-2da0-e4b782f9003e@yandex.ru> <5cca8644-f111-57b6-442d-e39f21090fea@yandex.ru> Message-ID: Date: Wed, 10 Mar 2021 04:06:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <5cca8644-f111-57b6-442d-e39f21090fea@yandex.ru> Content-Type: multipart/mixed; boundary="------------C48D6F379D558C4D475CE693" Content-Language: en-US X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 46859 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 (/) This is a multi-part message in MIME format. --------------C48D6F379D558C4D475CE693 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 08.03.2021 04:56, Dmitry Gutov wrote: > If you still get lines that are loo long in these cases, even with all > extra text snipped away, hiding parts of the summary using text > properties should be possible. I just tried putting 'invisible' on the > whole line after column 600, and scrolling became instantaneous again. > > As long as we undo these properties (or, perhaps, scroll the visible > part?) when xref-next-line is called, the user would still be able to > visit all matches. Here's an experimental patch that does this. As long as there are no matches near the end of the long string, everything seems snappy. If we do end up scrolling to near its end, though, moving around that line becomes slower. --------------C48D6F379D558C4D475CE693 Content-Type: text/x-patch; charset=UTF-8; name="xref-long-line-visibility-truncation.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xref-long-line-visibility-truncation.diff" diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index c066d9dc02..8decfcbb6c 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -891,6 +891,39 @@ xref--mouse-2 (xref--search-property 'xref-item)) (xref-show-location-at-point)) +(defcustom xref-truncate-to-width 400 + "The column to visually \"truncate\" an Xref buffer line." + :type 'integer) + +(defun xref--apply-truncation () + (add-to-invisibility-spec '(ellipsis . t)) + (let (;; FIXME: Treat the line number prefix specially. + (bol (line-beginning-position)) + (eol (line-end-position)) + (inhibit-read-only t) + pos) + (when (and (> (- eol bol) + xref-truncate-to-width) + ;; Either truncation not applied yet, or it hides the current + ;; position: need to refresh. + (or (and (null (get-text-property (1- eol) 'invisible)) + (null (get-text-property bol 'invisible))) + (get-text-property (point) 'invisible))) + (cond + ((< (- (point) bol) xref-truncate-to-width) + (setq pos (+ bol xref-truncate-to-width)) + (remove-text-properties bol pos '(invisible)) + (put-text-property pos eol 'invisible 'ellipsis)) + ((< (- eol (point)) xref-truncate-to-width) + (setq pos (- eol xref-truncate-to-width)) + (remove-text-properties pos eol '(invisible)) + (put-text-property bol pos 'invisible 'ellipsis)) + (t + (setq pos (- (point) (/ xref-truncate-to-width 2))) + (put-text-property bol pos 'invisible 'ellipsis) + (remove-text-properties pos (+ pos xref-truncate-to-width) '(invisible)) + (put-text-property (+ pos xref-truncate-to-width) eol 'invisible 'ellipsis)))))) + (defun xref--insert-xrefs (xref-alist) "Insert XREF-ALIST in the current-buffer. XREF-ALIST is of the form ((GROUP . (XREF ...)) ...), where @@ -934,6 +967,11 @@ xref--insert-xrefs (setq prev-line line prev-group group)))) (insert "\n")) + (save-excursion + (goto-char (point-min)) + (while (not (eobp)) + (forward-line 1) + (xref--apply-truncation))) (run-hooks 'xref-after-update-hook)) (defun xref--analyze (xrefs) @@ -971,6 +1009,7 @@ xref--show-common-initialize (buffer-undo-list t)) (erase-buffer) (xref--insert-xrefs xref-alist) + (add-hook 'post-command-hook 'xref--apply-truncation nil t) (goto-char (point-min)) (setq xref--original-window (assoc-default 'window alist) xref--original-window-intent (assoc-default 'display-action alist)) --------------C48D6F379D558C4D475CE693-- From debbugs-submit-bounces@debbugs.gnu.org Mon May 17 11:28:07 2021 Received: (at 46859) by debbugs.gnu.org; 17 May 2021 15:28:07 +0000 Received: from localhost ([127.0.0.1]:53554 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lifA7-0002u2-H8 for submit@debbugs.gnu.org; Mon, 17 May 2021 11:28:07 -0400 Received: from quimby.gnus.org ([95.216.78.240]:58844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lifA4-0002tO-Rg for 46859@debbugs.gnu.org; Mon, 17 May 2021 11:28:05 -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=gMxS42+Ue4mbPTAEmXiDDK5hht5AToqhACkT9R4Qpig=; b=mBl4k0I09N6g1MsvT8W2DlTPRJ vfuzXjaSfQQs2Sq1eKNJt6fCqVkDrysRJ9yoEvbvLvHZgkjvwq+7ArV3Jn5b59SMnPfPIBGN+TGny g27M4d6L7plhRJAL0Q91Vfk2kYna1mat1pk998l3ccR6yQKF94e9Vbd2hXvR9cpIBlQY=; Received: from cm-84.212.220.105.getinternet.no ([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 1lif9w-0000vM-9K; Mon, 17 May 2021 17:27:58 +0200 From: Lars Ingebrigtsen To: Dmitry Gutov Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el References: <87im69uzlt.fsf@mail.linkov.net> <25782781-4baa-5d44-99a1-2e57552ab3a0@yandex.ru> <666564dc-0252-6bf5-04e1-58c9916cffbe@yandex.ru> <92f18de5-6dae-8041-2da0-e4b782f9003e@yandex.ru> <5cca8644-f111-57b6-442d-e39f21090fea@yandex.ru> X-Now-Playing: Al's _LP_: "Qiyamah" Date: Mon, 17 May 2021 17:27:55 +0200 In-Reply-To: (Dmitry Gutov's message of "Wed, 10 Mar 2021 04:06:11 +0200") Message-ID: <87mtstidms.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.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: > Here's an experimental patch that does this. > > As long as there are no matches near the end of the long string, > everything seems snappy. If we do end up scrolling to near its end, > though, movi [...] 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: 0.0 (/) X-Debbugs-Envelope-To: 46859 Cc: 46859@debbugs.gnu.org, Theodor Thornhill , 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: -1.0 (-) Dmitry Gutov writes: > Here's an experimental patch that does this. > > As long as there are no matches near the end of the long string, > everything seems snappy. If we do end up scrolling to near its end, > though, moving around that line becomes slower. I think that's a fair trade-off. I only lightly skimmed this long thread, but this patch was never applied? (And it was the final message here.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon May 17 11:45:06 2021 Received: (at 46859) by debbugs.gnu.org; 17 May 2021 15:45:06 +0000 Received: from localhost ([127.0.0.1]:53586 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lifQY-0005dM-Fy for submit@debbugs.gnu.org; Mon, 17 May 2021 11:45:06 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:39834) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lifQW-0005XJ-Br for 46859@debbugs.gnu.org; Mon, 17 May 2021 11:45:05 -0400 Received: by mail-wr1-f41.google.com with SMTP id v12so6919021wrq.6 for <46859@debbugs.gnu.org>; Mon, 17 May 2021 08:45:04 -0700 (PDT) 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=89VbtWiRwQ55tfuWLW4o6pS45SKDX0Xj9eOuZpfeVn8=; b=Ncsis7OGi14dbfa55M76TsWYo5RSnLiNy/iXbUQZz50PJ/v88pPkhiU8/KjeoEYOC/ Fg3cifOm+6gsNcGYgLhxgXTXDd9ANCiWHL1L+goVUtDAh1H9DXIlWIVRIYsIXOkqfETr ILHbr/E9zJEnBs7Hkd48opq9+sEHGmgMLoZBIts6w7QXjLNVU8o2bL/ZYrnTiWe8K/gq BXE/QPtO3rgFSF34zzP1/PPXhcj0qiyVVejAj4q/Zu4nJ7osQW/+PhWkeH74xXIOjnw9 zHIzQh7H13md6rntLpXePdLAEbxnYN7FQ9wf11bOE0wgPIRJlD9aQer/rxd3Ol0o0+cb 7k2A== 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=89VbtWiRwQ55tfuWLW4o6pS45SKDX0Xj9eOuZpfeVn8=; b=iRmFuONgdflHY+IxnUlZM6/ir3YoJXkmzN7fwz1vRYsCvp//sV7SfdrZKEL1ljn+Et lTLGPxdutguUiAmiWChvW+TQs8N6hS9eoukrF+k99Ylrx94jC8uZei150I3KmMN4gmRj xi3dCisITO7Y+WZV/wCGd+jIk4DzyFnO/K5Gp14gBen/HyMvQTEziszPCjMgDOJv+y/b 68imJ3C3yZOgaM+/r8BvkHkUvg8h28D8YnlAVYpJ5EfaBEg1y/RVZsbtzKfeY6OQmOXF 3yrpXszxnWa6AIrKH6rVl8uPxCKTt8w6RhZPLrXHnR+N/HXLRQADk+kS1FM69K92NhsI PkZQ== X-Gm-Message-State: AOAM533uEHmFS0+m1mAKbhZ+KmxmySEkLKhbvOvSqjigLHPY79m6Ea+0 DH4SQ7jrDkRhIv5B8zYivzk= X-Google-Smtp-Source: ABdhPJwxqsV4RGC54S/Qmxa7W+3kPaX2Q2o+T7oDbXeRix7/eJt/IrwTjrS2g7GEZHvJZfRpSZOCNA== X-Received: by 2002:a5d:598f:: with SMTP id n15mr367307wri.21.1621266298427; Mon, 17 May 2021 08:44:58 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id q27sm14892995wrz.79.2021.05.17.08.44.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 May 2021 08:44:57 -0700 (PDT) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Lars Ingebrigtsen References: <87im69uzlt.fsf@mail.linkov.net> <25782781-4baa-5d44-99a1-2e57552ab3a0@yandex.ru> <666564dc-0252-6bf5-04e1-58c9916cffbe@yandex.ru> <92f18de5-6dae-8041-2da0-e4b782f9003e@yandex.ru> <5cca8644-f111-57b6-442d-e39f21090fea@yandex.ru> <87mtstidms.fsf@gnus.org> From: Dmitry Gutov Message-ID: Date: Mon, 17 May 2021 18:44:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <87mtstidms.fsf@gnus.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: 46859 Cc: 46859@debbugs.gnu.org, Theodor Thornhill , 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 17.05.2021 18:27, Lars Ingebrigtsen wrote: > I think that's a fair trade-off. I only lightly skimmed this long > thread, but this patch was never applied? (And it was the final message > here.) I was looking for some user experience feedback (with possible subsequent tweaks, etc), but the current behavior is indeed annoying enough to install this anyway. Will do that shortly. From debbugs-submit-bounces@debbugs.gnu.org Mon May 17 12:57:19 2021 Received: (at 46859) by debbugs.gnu.org; 17 May 2021 16:57:19 +0000 Received: from localhost ([127.0.0.1]:53723 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ligYR-0005Z5-1w for submit@debbugs.gnu.org; Mon, 17 May 2021 12:57:19 -0400 Received: from out0.migadu.com ([94.23.1.103]:34912) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ligYN-0005Ys-59 for 46859@debbugs.gnu.org; Mon, 17 May 2021 12:57:17 -0400 Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1621270633; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kM7UIkddGwSaHmJIq9GYxQHDZ5VIim3BpSef7wIWaAU=; b=aT7MS5eriKkmhevxrAoWmnQFgDX0hUtt30gyimDl9WM1iEiKoAlIEXNBGIsDeu9kw+0b8H m6ZM/EcKGPqbaW/HyELDg5BO3bjsEdeKTYV2eIFIymSI5oNfRiLr681uo16dagKx2/AuQc 2vwv6c4X/qoGLXiwKfRp3lK/73FNhDrUKf01Pc+HZ3rrOpApEWLcgtmRFWwrW60YsntmVk UAUtHaCj79eAIHUS8f1BhpMLwcrq5+QvVbNu/q1d4UTWMF7D9fJ3ezOoZ4bxYIYchhtMKJ KQUVUUEZLjMa3Qzih8+N+Am+oY0Kp5CfuuUAyKgO/LkfE9SM92xMLj/NXD2wCg== Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Theodor Thornhill MIME-Version: 1.0 Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el Date: Mon, 17 May 2021 18:57:11 +0200 Message-Id: <5E938190-7EFF-444C-9A3F-C6820AA7F1E5@thornhill.no> References: In-Reply-To: To: Dmitry Gutov X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46859 Cc: Lars Ingebrigtsen , 46859@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: -1.7 (-) Hi and sorry for the late reply, > I was looking for some user experience feedback (with possible subsequent t= weaks, etc), but the current behavior is indeed annoying enough to install t= his anyway. Agreed. When testing I found it to be a nice improvement. > Will do that shortly. Nice :) =E2=80=94 Theo From debbugs-submit-bounces@debbugs.gnu.org Mon May 17 20:40:05 2021 Received: (at 46859-done) by debbugs.gnu.org; 18 May 2021 00:40:05 +0000 Received: from localhost ([127.0.0.1]:54070 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1linmH-0000Wg-Be for submit@debbugs.gnu.org; Mon, 17 May 2021 20:40:05 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]:45759) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1linmD-0000W6-Br for 46859-done@debbugs.gnu.org; Mon, 17 May 2021 20:40:03 -0400 Received: by mail-wr1-f43.google.com with SMTP id h4so8192627wrt.12 for <46859-done@debbugs.gnu.org>; Mon, 17 May 2021 17:40:01 -0700 (PDT) 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=vG/Wr6Fwsa73pQuqxqQF0vQQFjSLsKcbPgbebYLsbAM=; b=gezQx45vf2cHt4557CBNvRFI1XjCrf/qHz9tyg4lKadvK3gKGqyVjmEBIKL9gAo0hr 7fgpIZ2h9ePMSeqV0ZJeB0EUI+QR5dDtiVzLWudOXayZh7LmJOiBu54nH9U/Ifaubjf6 VRHVZSdVvt9hUeQ+NqC8oPvohwsEMACWcxRXV/vyBz3u7IFJkshnFoFQt8AlAqBILmET UtmqfXMnXtnp+PAaxDN2CLjORXI5K8vvz7J6gPQg1ubfrS9innhZBQfvwBZSuzCY3BqD uQHn+XEDIhsgn8n47DqaTUsWu0aXMY04HlCdiyXh9WApe0RMB4GQQ8IfHYYi++CfDb2m /+KQ== 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=vG/Wr6Fwsa73pQuqxqQF0vQQFjSLsKcbPgbebYLsbAM=; b=WJwTWM3y90UCC8rVXzijlfIJKST2GupVMp11MnBLMnr2raiILfSaK7SUQkvKbqDztL 4S6nIPljpuodTsHa3y+rhlNoM+woCEfvZRC9at69CiC4IcJVgl5xZQbCddn2SEOkTw+9 rmTVlSCmVjbpaPGU2NlWCBu/HFFkKWntKQzxk/b02SsvJS6txwrfEctuw+uhiDMsTj/a Ru73SjJSF96tX8q0gzyk6q/b39YeHDweOwQOP0K0/TgzBJftgtQkfCXGgoGlMgVMJ1lu xqN50O0yQJM3thkSno1u2eeuEZSBeZhhRpCoJJdzEvRcf14hFOqYvHX5Nt77zsd+ouv8 Mp4Q== X-Gm-Message-State: AOAM532FjeYc3n12i8U1SafddRG0hUjUS7H7kfqbwQTBGcOJrA95RkaM 7Ea1QYL3pjTKc23pumWd1mc= X-Google-Smtp-Source: ABdhPJyhgzAl1k3+F4gSqun46AsGyGdNMRWXaqaLT4Kk0LDe4EC1X8T6ytf4SgJrjmbk711kAg/PWA== X-Received: by 2002:a05:6000:108b:: with SMTP id y11mr3079807wrw.166.1621298395472; Mon, 17 May 2021 17:39:55 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id e38sm859842wmp.21.2021.05.17.17.39.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 May 2021 17:39:54 -0700 (PDT) Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el To: Theodor Thornhill References: <5E938190-7EFF-444C-9A3F-C6820AA7F1E5@thornhill.no> From: Dmitry Gutov Message-ID: <01ad60b1-950c-b8bb-7384-23e5482ecc58@yandex.ru> Date: Tue, 18 May 2021 03:39:53 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <5E938190-7EFF-444C-9A3F-C6820AA7F1E5@thornhill.no> 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: 46859-done Cc: Lars Ingebrigtsen , 46859-done@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 (/) Version: 28.1 On 17.05.2021 19:57, Theodor Thornhill wrote: > Hi and sorry for the late reply, > >> I was looking for some user experience feedback (with possible subsequent tweaks, etc), but the current behavior is indeed annoying enough to install this anyway. > > Agreed. When testing I found it to be a nice improvement. Very good. I've pushed an updated version in d83db639d3: - It make sure not to hide the line number with the ellipsis anymore. - The option was renamed to xref-truncation-width. - It can be set to nil to disable the feature. Please try the new version when you have the time. From unknown Fri Sep 12 01:59:02 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 15 Jun 2021 11:24:06 +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