From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#23223: 25.0.92; Can xref-find-references be sped up? Date: Sat, 09 Apr 2016 10:25:43 +0300 Message-ID: <83vb3ri6q0.fsf@gnu.org> References: <83pou4m6h7.fsf@gnu.org> <902ac022-3a76-c363-0c77-12b1cdb8d521@yandex.ru> <8360vumzk4.fsf@gnu.org> <83mvp5lauu.fsf@gnu.org> <4424e043-31c7-0da4-213a-ee8ac31d9265@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1460186831 27473 80.91.229.3 (9 Apr 2016 07:27:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Apr 2016 07:27:11 +0000 (UTC) Cc: 23223@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Apr 09 09:27:10 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aonIU-0005RS-Bm for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Apr 2016 09:27:10 +0200 Original-Received: from localhost ([::1]:59489 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aonIT-0007iB-N3 for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Apr 2016 03:27:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38999) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aonIP-0007e7-Da for bug-gnu-emacs@gnu.org; Sat, 09 Apr 2016 03:27:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aonIM-0002FN-7S for bug-gnu-emacs@gnu.org; Sat, 09 Apr 2016 03:27:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42763) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aonIM-0002FI-49 for bug-gnu-emacs@gnu.org; Sat, 09 Apr 2016 03:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1aonIM-0003Mx-0R for bug-gnu-emacs@gnu.org; Sat, 09 Apr 2016 03:27:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Apr 2016 07:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23223 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23223-submit@debbugs.gnu.org id=B23223.146018679212910 (code B ref 23223); Sat, 09 Apr 2016 07:27:01 +0000 Original-Received: (at 23223) by debbugs.gnu.org; 9 Apr 2016 07:26:32 +0000 Original-Received: from localhost ([127.0.0.1]:55100 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aonHr-0003MA-S9 for submit@debbugs.gnu.org; Sat, 09 Apr 2016 03:26:32 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aonHq-0003Ly-JE for 23223@debbugs.gnu.org; Sat, 09 Apr 2016 03:26:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aonHi-0001sz-8n for 23223@debbugs.gnu.org; Sat, 09 Apr 2016 03:26:25 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36271) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aonHi-0001sv-5W; Sat, 09 Apr 2016 03:26:22 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1115 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aonHh-0005il-G2; Sat, 09 Apr 2016 03:26:21 -0400 In-reply-to: <4424e043-31c7-0da4-213a-ee8ac31d9265@yandex.ru> (message from Dmitry Gutov on Sat, 9 Apr 2016 06:12:29 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:116254 Archived-At: > Cc: 23223@debbugs.gnu.org > From: Dmitry Gutov > Date: Sat, 9 Apr 2016 06:12:29 +0300 > > >> 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. I agree. > > 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. Would it help to only use the mode's syntax table, and avoid switching on the major mode as a whole? > 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). That problem is relevant for IDutils as well (the scanner is determined by the file's extension only), so we already have a certain (hopefully, small) number of misses and false positives. I think this cannot be entirely avoided. So maybe we shouldn't try so hard avoiding false positives. E.g., the "M-x gid" command, which comes with IDutils and is a trivial wrapper around lid invocation, simply shows the output in a Grep-like buffer, through which you can step with next-error. It is lightning-fast: what takes 13 sec with xref-find-references, takes less than 2 sec with "M-x gid". > 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. Perhaps use insert-file-contents-literally, as decoding could slow down things considerably. You are only looking for ASCII text. Also note that a mode can be specified in file-local variables at the file's end, though.