From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Theodor Thornhill via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el Date: Wed, 03 Mar 2021 20:54:46 +0100 Message-ID: References: <87im69uzlt.fsf@mail.linkov.net> <25782781-4baa-5d44-99a1-2e57552ab3a0@yandex.ru> <666564dc-0252-6bf5-04e1-58c9916cffbe@yandex.ru> Reply-To: Theodor Thornhill Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18886"; mail-complaints-to="usenet@ciao.gmane.io" To: Dmitry Gutov , juri@linkov.net, 46859@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Mar 03 20:55:13 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lHXaT-0004oJ-11 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Mar 2021 20:55:13 +0100 Original-Received: from localhost ([::1]:35888 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHXaS-0002mS-3h for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Mar 2021 14:55:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49904) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHXaI-0002lb-36 for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 14:55:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45514) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lHXaH-0002qt-Rl for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 14:55:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lHXaH-0003es-QJ for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 14:55:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Theodor Thornhill Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Mar 2021 19:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46859 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 46859-submit@debbugs.gnu.org id=B46859.161480129114043 (code B ref 46859); Wed, 03 Mar 2021 19:55:01 +0000 Original-Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 19:54:51 +0000 Original-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 Original-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. In-Reply-To: <666564dc-0252-6bf5-04e1-58c9916cffbe@yandex.ru> X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:201317 Archived-At: 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