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: Thu, 7 Apr 2016 03:11:25 +0300 Message-ID: References: <83pou4m6h7.fsf@gnu.org> <902ac022-3a76-c363-0c77-12b1cdb8d521@yandex.ru> <8360vumzk4.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 1459987946 3342 80.91.229.3 (7 Apr 2016 00:12:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Apr 2016 00:12:26 +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 Thu Apr 07 02:12:15 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 1anxYS-0008GN-5q for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Apr 2016 02:12:12 +0200 Original-Received: from localhost ([::1]:46425 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anxYQ-0006xY-V6 for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Apr 2016 20:12:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51787) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anxYL-0006x1-Vg for bug-gnu-emacs@gnu.org; Wed, 06 Apr 2016 20:12:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anxYI-0002ta-Kh for bug-gnu-emacs@gnu.org; Wed, 06 Apr 2016 20:12:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39927) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anxYI-0002tW-H5 for bug-gnu-emacs@gnu.org; Wed, 06 Apr 2016 20:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1anxYI-0000d7-85 for bug-gnu-emacs@gnu.org; Wed, 06 Apr 2016 20:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Apr 2016 00:12:02 +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.14599878952386 (code B ref 23223); Thu, 07 Apr 2016 00:12:02 +0000 Original-Received: (at 23223) by debbugs.gnu.org; 7 Apr 2016 00:11:35 +0000 Original-Received: from localhost ([127.0.0.1]:52264 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1anxXr-0000cQ-A4 for submit@debbugs.gnu.org; Wed, 06 Apr 2016 20:11:35 -0400 Original-Received: from mail-wm0-f54.google.com ([74.125.82.54]:34262) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1anxXp-0000c9-Ed for 23223@debbugs.gnu.org; Wed, 06 Apr 2016 20:11:33 -0400 Original-Received: by mail-wm0-f54.google.com with SMTP id l6so3767817wml.1 for <23223@debbugs.gnu.org>; Wed, 06 Apr 2016 17:11:33 -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=EXWlu7eTPwu7NenwDyF/0MnI52/Lofd5WZGrSDFM1e0=; b=zAZKMhZI6CboYY0/OKZQsUN+7EvPwTOqr5uTQPM/hRBZbJMmJp96+S1bZTOH+P0PEv 1KG7iKzPlfnQiE9cE8G6vFFZ4EIzV8ZGhCYbumlxQ8Rb7x3WwCUM9nGBDOediAUahN9Z n4FHmDgkudeFHsG1VuVzXK10O843qruBi3M9rbcIKJyaYl70vRwWn2v2/xi3ugKysYgb QcsLzgPMUs93EuO6Uf+wrGWoV6ZfRvZUIMfqBX6JeqslSf3MUZS9q16gczIix38k363U AoD8Eejsy3szaVPPmf8ZbduQNb/WPeKIWRPVM/3CAs/Ujxe9EeDinXlkomwbApF1cUHt p1fQ== 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=EXWlu7eTPwu7NenwDyF/0MnI52/Lofd5WZGrSDFM1e0=; b=TRxBiWOF2ST/ZFbm2zoIu5ZusDWVm8zWwHQjdyLcgPYWOIIOII93pUyEb3Qn17D8QI igBEZzlxWuByoMJxoho1dPbNkwFFcWaGBYhFBEeV3Q4ycgkHf6GgN6PZgpFWsUz81MCa 5vYNjTSazwNAkaazvzQxGU6tMfXUp+NJsmdKQv0g2PH/ffoC4WoH2zn8AiXod0SGnyQX stcx0YEMetq+H/EQyhxRDbrxv5bdSE+JDF03yT3sWbKwiWqN3r0musfzYRgZls2/bYhi Rl8tv1SZmtkywbFnKPhjusqDnsPJCh9JLHyDJnDKUY8Crps8WW0Oib+hY2p/iBEu2mlG 0OaA== X-Gm-Message-State: AD7BkJI4EYd/SJ5Gz9hxDZMxhIUX9My6T1VAZ/8xcX/i+mKT190GgA2JsIxo51nm4fU7FQ== X-Received: by 10.194.84.66 with SMTP id w2mr143761wjy.6.1459987887729; Wed, 06 Apr 2016 17:11:27 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id gk4sm5631608wjd.7.2016.04.06.17.11.26 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 17:11:26 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: <8360vumzk4.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:116144 Archived-At: On 04/06/2016 08:12 PM, Eli Zaretskii wrote: > But using plain Grep has the same problem: Grep reports the hits, and > we then go ahead and visit each hit, right? Using Grep has the slowness problem, but it doesn't have this opportunity for optimization, since Grep definitely doesn't know what characters constitute a symbol in different languages. But your proposal may speed up Grep searches too, so that's a plus. >> How do I find the appropriate 'buffer' match in this line? > > You already have the code that looks for the match in each line. What > I had in mind is looking in the output of Grep or lid, instead of > visiting the file and looking in that file's buffer. Does this make > sense? Yes, but the search for \_ needs a properly set syntax table, syntax-propertize-function, and possibly other variables that the latter might depend on. Basically, it needs a buffer in the right major mode. And switching major modes is actually not cheap: (benchmark 230 '(with-temp-buffer (c-mode))) => 1.20s in my working Emacs instance (much faster in a pristine one, admittedly). But I'll have a try at doing this while reusing the temporary buffer. Some major modes could also trip over incomplete source code, but we'll get to that when we see that. Syntax highlighting seems out of the question, though, with high likelihood of getting it wrong. We also have the possibility of syntax-propertize-function not applying the correct syntax classes to the code fragment because it doesn't see the whole file, but I guess it's a small-ish price to pay for the performance improvement, and could be fixed on a case-by-case basis. >> Or can we ask 'lid' (and, ideally, Grep too) to include the column of a >> match in the output? > > No, I don't think such an option exists. It could be a great > enhancement request, though ;-) I was hoping you could serve as a liaison in that, being the sole user of id-utils that I know of, so far. But anyway, if there is no such feature now, we have to choose another solution in Emacs 25.1. Even if id-utils were to add this today, it would take time to trickle to the majority of our users. The bar is actually higher: to make use of the enhancement, we'd need Global and CScope to support it, too, or at least to be able to detect the feature at runtime.