From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 23223@debbugs.gnu.org
Subject: bug#23223: 25.0.92; Can xref-find-references be sped up?
Date: Sat, 9 Apr 2016 06:12:29 +0300 [thread overview]
Message-ID: <4424e043-31c7-0da4-213a-ee8ac31d9265@yandex.ru> (raw)
In-Reply-To: <83mvp5lauu.fsf@gnu.org>
On 04/07/2016 06:03 PM, Eli Zaretskii wrote:
> Heh, I completely forgot how IDutils work. The ID database doesn't
> store the locations where the identifiers were found, all it stores is
> the list of identifiers found in each file. When lid is invoked, it
> queries the database about the files that reference the identifier;
> then it opens each file in the query results, and searches for the
> identifier on each line of that file. When lid is invoked to produce
> a Grep-like output and with the -w option (which is what we do), it
> searches each line for the moral equivalent of
>
> [^[:alnum:]_]IDENT[^[:alnum:]_]
>
> where IDENT is the identifier we asked about.
That explains everything, thanks.
>> I was hoping you could serve as a liaison in that, being the sole user of id-utils that I know of, so far.
>
> I could do that, but given the explanation above of what -w means, it
> will hardly help us, right?
It might if -w were to be improved, though. We can request for it to be
smarter and do the post-filtering itself, using a language-aware
scanner. Even if no other feature is added, the accuracy of results will
improve for all users of id-utils, and Emacs will automatically end up
having to do less work for this feature.
That's not pressing, though.
> Right. So I think we need to assume that the program we invoke to
> bring the matches is not smart enough anyway, and Emacs will have to
> search in the matches for those we want to present, filtering out the
> false positives. This assumption seems to fit well all the programs
> that can support the queries required by xref-find-references.
Probably.
> I'm not sure I understand what you have in mind for that, though. Are
> you going to switch the major mode of the temporary buffer as
> determined by the file name of each match?
Yes. We can avoid switching if the major mode of the previous match was
the same as the current one. Having too many major modes involved in one
search is highly unlikely, so the switching overhead shouldn't be too
much of a problem, actually.
> Maybe we should take a
> hint from the major mode of the buffer in which the command was
> invoked?
That could only work for the output of xref-find-references, but not
project-find-regexp, which is also in need of speeding up.
Anyway, whether we "take a hint" or not, we're going to end up with
imperfect results: if we don't visit the target buffers, we're going to
have to ignore all the ways Emacs allows specifying the major mode,
aside from auto-mode-alist ("mode: " specification,
interpreter-mode-alist, magic-mode-alist, magic-fallback-mode-alist).
Hmm. Maybe we can still support most of those using
(insert-file-contents "file-name" nil 0 200), at the cost of some extra
overhead.
next prev parent reply other threads:[~2016-04-09 3:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-05 15:16 bug#23223: 25.0.92; Can xref-find-references be sped up? Eli Zaretskii
2016-04-06 0:37 ` Dmitry Gutov
2016-04-06 15:09 ` Dmitry Gutov
2016-04-06 17:20 ` Eli Zaretskii
2016-04-06 23:11 ` Dmitry Gutov
2016-04-07 2:49 ` Eli Zaretskii
2016-04-06 17:12 ` Eli Zaretskii
2016-04-07 0:11 ` Dmitry Gutov
2016-04-07 15:03 ` Eli Zaretskii
2016-04-09 3:12 ` Dmitry Gutov [this message]
2016-04-09 7:25 ` Eli Zaretskii
2016-04-10 23:27 ` Dmitry Gutov
2016-04-11 15:56 ` Eli Zaretskii
2016-04-11 23:25 ` Dmitry Gutov
2016-04-12 15:50 ` Eli Zaretskii
2016-04-12 18:49 ` Dmitry Gutov
2016-04-12 19:16 ` Eli Zaretskii
2016-04-12 20:26 ` Dmitry Gutov
2016-04-13 2:44 ` Eli Zaretskii
2016-04-13 10:18 ` Dmitry Gutov
2016-04-13 15:16 ` Eli Zaretskii
2016-04-15 14:29 ` Eli Zaretskii
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4424e043-31c7-0da4-213a-ee8ac31d9265@yandex.ru \
--to=dgutov@yandex.ru \
--cc=23223@debbugs.gnu.org \
--cc=eliz@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.