From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#23223: 25.0.92; Can xref-find-references be sped up? Date: Sat, 9 Apr 2016 06:12:29 +0300 Message-ID: <4424e043-31c7-0da4-213a-ee8ac31d9265@yandex.ru> References: <83pou4m6h7.fsf@gnu.org> <902ac022-3a76-c363-0c77-12b1cdb8d521@yandex.ru> <8360vumzk4.fsf@gnu.org> <83mvp5lauu.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1460171600 20301 80.91.229.3 (9 Apr 2016 03:13:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Apr 2016 03:13:20 +0000 (UTC) Cc: 23223@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Apr 09 05:13:20 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 1aojKp-0001av-Nt for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Apr 2016 05:13:19 +0200 Original-Received: from localhost ([::1]:59097 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aojKo-0000B4-6X for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Apr 2016 23:13:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59855) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aojKj-00007E-If for bug-gnu-emacs@gnu.org; Fri, 08 Apr 2016 23:13:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aojKe-0002tt-In for bug-gnu-emacs@gnu.org; Fri, 08 Apr 2016 23:13:13 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42739) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aojKe-0002tp-Eq for bug-gnu-emacs@gnu.org; Fri, 08 Apr 2016 23:13:08 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1aojKX-0005ck-Ir for bug-gnu-emacs@gnu.org; Fri, 08 Apr 2016 23:13:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Apr 2016 03:13: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.146017155821585 (code B ref 23223); Sat, 09 Apr 2016 03:13:01 +0000 Original-Received: (at 23223) by debbugs.gnu.org; 9 Apr 2016 03:12:38 +0000 Original-Received: from localhost ([127.0.0.1]:55076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aojKA-0005c5-CH for submit@debbugs.gnu.org; Fri, 08 Apr 2016 23:12:38 -0400 Original-Received: from mail-wm0-f47.google.com ([74.125.82.47]:37080) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aojK9-0005bt-Aw for 23223@debbugs.gnu.org; Fri, 08 Apr 2016 23:12:37 -0400 Original-Received: by mail-wm0-f47.google.com with SMTP id n3so42388096wmn.0 for <23223@debbugs.gnu.org>; Fri, 08 Apr 2016 20:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=9aZrTIIdGAqwkvdT62Kj7Wt4P4O4EiK3DCBKZQqu7Og=; b=xH80f+NzcAGzskXB+dHVAG65VfD0aQmyCDGklqbS2YqhZXBjbvdC3DBaOgDCbJKDQA KcgTEuu+ZEOG5d4Ry7FBxYQsvkuU04HIX32qSKvOH8A9miR96AENdmbnTbFcsxVpThgP OlVrPmkZKRs0EG/ybWbvbSf/bKohVXJ++XIAXJApAJSQV+7h7uRTCFmVHFX2ls9zq49t 3hHsLKgoRrur/pcFijTzKXupqtZeYfvKjK9QSfPW/lvT/DGDKpSpVinKcIoM+fypB1/V CwN8giDXNMcmfSgrUURR/Th8WhLdOya5JJCDl2PCZxSz2k95nt9Zenr9lnykTv998yLZ Hx/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=9aZrTIIdGAqwkvdT62Kj7Wt4P4O4EiK3DCBKZQqu7Og=; b=BIszRnP+enJvVx362DpXsNKOifpDFZDU5riQaBMU5xbHbreC2M8ev7P2FE3SI0gXRp TUFe7Hk2YmykvEkne3G1BRsK0pA9zhp1PXJ9kM2X+6A3V50mFN0W+uZFflM5J+tDUnL+ EgeYZKkg2Z8/vQfM19/bfmW03i7lM7MC4zX+UeHLgQGOp5k7cAuf9tEALmhAEU5RQCwd ogALNOz9V+2dNyiIloYgVqtacPGfD9zRRMrYpAL2bismpDVDsyJmyIilLbnDFxjx7zUs hU8uGGLB0O74HLL9T9Iqkky1EypH1HCq+2NEF2jIfVeaze8zKZRtDjYs+6+PniRpSJyc FwTg== X-Gm-Message-State: AD7BkJL5REHotXEspd2ny0/hDHROnONeAc2YCOhctURMIAXIVwvLZXPwPZispSvS9O5Msg== X-Received: by 10.28.97.197 with SMTP id v188mr7189961wmb.67.1460171551653; Fri, 08 Apr 2016 20:12:31 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id m6sm16069239wje.21.2016.04.08.20.12.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 20:12:30 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: <83mvp5lauu.fsf@gnu.org> 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:116250 Archived-At: 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.