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: Mon, 8 Mar 2021 04:48:33 +0200 Message-ID: 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> 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="36811"; 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 Mon Mar 08 03:49:10 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 1lJ5xF-0009RY-Of for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Mar 2021 03:49:09 +0100 Original-Received: from localhost ([::1]:57816 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJ5xE-0001kl-8t for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Mar 2021 21:49:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49252) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJ5x8-0001kc-0t for bug-gnu-emacs@gnu.org; Sun, 07 Mar 2021 21:49:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58507) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lJ5x7-0002bb-Ow for bug-gnu-emacs@gnu.org; Sun, 07 Mar 2021 21:49:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lJ5x7-0000Ek-N0 for bug-gnu-emacs@gnu.org; Sun, 07 Mar 2021 21:49:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Mar 2021 02:49: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.1615171731894 (code B ref 46859); Mon, 08 Mar 2021 02:49:01 +0000 Original-Received: (at 46859) by debbugs.gnu.org; 8 Mar 2021 02:48:51 +0000 Original-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 Original-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 Original-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) Original-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) 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:201796 Archived-At: 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).