From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el Date: Sun, 7 Mar 2021 00:26:10 +0200 Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15426"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 To: Theodor Thornhill , juri@linkov.net, 46859@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 06 23:27:11 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 1lIfOA-0003tQ-Sj for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Mar 2021 23:27:10 +0100 Original-Received: from localhost ([::1]:54104 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lIfO9-0001k5-EO for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Mar 2021 17:27:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34306) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lIfO2-0001jt-Qt for bug-gnu-emacs@gnu.org; Sat, 06 Mar 2021 17:27:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55176) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lIfO2-0000Sk-Is for bug-gnu-emacs@gnu.org; Sat, 06 Mar 2021 17:27:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lIfO2-00045S-EE for bug-gnu-emacs@gnu.org; Sat, 06 Mar 2021 17:27:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Mar 2021 22:27:02 +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.161506958315665 (code B ref 46859); Sat, 06 Mar 2021 22:27:02 +0000 Original-Received: (at 46859) by debbugs.gnu.org; 6 Mar 2021 22:26:23 +0000 Original-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 Original-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 Original-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) Original-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) In-Reply-To: Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:201693 Archived-At: 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.