From: Dmitry Gutov <dgutov@yandex.ru>
To: Theodor Thornhill <theo@thornhill.no>,
juri@linkov.net, 46859@debbugs.gnu.org
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 [thread overview]
Message-ID: <92f18de5-6dae-8041-2da0-e4b782f9003e@yandex.ru> (raw)
In-Reply-To: <m2lfb4j9mh.fsf@Theodors-MBP.lan>
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.
next prev parent reply other threads:[~2021-03-06 22:26 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-01 20:40 bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-01 22:07 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-02 19:25 ` Juri Linkov
2021-03-02 21:13 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-02 21:37 ` Dmitry Gutov
2021-03-02 21:45 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-02 22:14 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-02 22:37 ` Dmitry Gutov
2021-03-03 16:13 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-03 17:29 ` Dmitry Gutov
2021-03-03 19:54 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-06 22:26 ` Dmitry Gutov [this message]
2021-03-07 1:29 ` Dmitry Gutov
2021-03-07 3:22 ` Dmitry Gutov
2021-03-07 20:03 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-08 2:48 ` Dmitry Gutov
2021-03-07 20:16 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-07 20:26 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-08 2:56 ` Dmitry Gutov
2021-03-10 2:06 ` Dmitry Gutov
2021-05-17 15:27 ` Lars Ingebrigtsen
2021-05-17 15:44 ` Dmitry Gutov
2021-05-17 16:57 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-05-18 0:39 ` Dmitry Gutov
2021-03-03 9:05 ` Juri Linkov
2021-03-03 9:52 ` Gregory Heytings
2021-03-03 12:47 ` Dmitry Gutov
2021-03-03 13:53 ` Gregory Heytings
2021-03-03 14:00 ` Dmitry Gutov
2021-03-03 15:04 ` Gregory Heytings
2021-03-03 17:11 ` Gregory Heytings
2021-03-03 17:26 ` Dmitry Gutov
2021-03-03 17:42 ` Gregory Heytings
2021-03-03 19:14 ` Dmitry Gutov
2021-03-03 19:34 ` Gregory Heytings
2021-03-03 19:52 ` Juri Linkov
2021-03-03 20:34 ` Gregory Heytings
2021-03-04 3:36 ` Eli Zaretskii
2021-03-04 9:19 ` Gregory Heytings
2021-03-04 14:08 ` Eli Zaretskii
2021-03-04 14:39 ` Gregory Heytings
2021-03-04 15:13 ` Eli Zaretskii
2021-03-04 16:47 ` Gregory Heytings
2021-03-04 17:13 ` Eli Zaretskii
2021-03-04 17:35 ` Gregory Heytings
2021-03-04 18:28 ` Eli Zaretskii
2021-03-06 12:31 ` Dmitry Gutov
2021-03-06 12:37 ` Dmitry Gutov
2021-03-06 12:54 ` Gregory Heytings
2021-03-06 14:26 ` Dmitry Gutov
2021-03-06 22:47 ` Gregory Heytings
2021-03-06 23:00 ` Dmitry Gutov
2021-03-06 23:24 ` Gregory Heytings
2021-03-07 3:08 ` Dmitry Gutov
2021-03-07 8:13 ` Gregory Heytings
2021-03-08 3:24 ` Dmitry Gutov
2021-03-08 8:26 ` Gregory Heytings
2021-03-08 11:47 ` Dmitry Gutov
2021-03-06 12:49 ` Gregory Heytings
2021-03-06 14:07 ` Dmitry Gutov
2021-03-03 20:30 ` Dmitry Gutov
2021-03-03 21:06 ` Gregory Heytings
2021-03-06 12:44 ` Dmitry Gutov
2021-03-06 12:58 ` Gregory Heytings
2021-03-06 14:06 ` Dmitry Gutov
2021-03-06 22:55 ` Gregory Heytings
2021-03-03 19:59 ` Juri Linkov
2021-03-04 2:50 ` Dmitry Gutov
2021-03-04 9:24 ` Juri Linkov
2021-03-04 17:20 ` Dmitry Gutov
2021-03-04 17:56 ` Juri Linkov
2021-03-04 18:57 ` Dmitry Gutov
2021-03-06 12:39 ` Dmitry Gutov
2021-03-03 16:14 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=92f18de5-6dae-8041-2da0-e4b782f9003e@yandex.ru \
--to=dgutov@yandex.ru \
--cc=46859@debbugs.gnu.org \
--cc=juri@linkov.net \
--cc=theo@thornhill.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).