From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master d7df36e: Rewrite elisp--xref-find-definitions to handle many more cases; add tests. Date: Tue, 11 Aug 2015 19:13:36 +0300 Message-ID: <55CA1F30.6050402@yandex.ru> References: <20150811025613.30799.89490@vcs.savannah.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 1439309645 15972 80.91.229.3 (11 Aug 2015 16:14:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Aug 2015 16:14:05 +0000 (UTC) To: emacs-devel@gnu.org, Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 11 18:14:05 2015 Return-path: Envelope-to: ged-emacs-devel@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 1ZPCBf-0003Hj-Vj for ged-emacs-devel@m.gmane.org; Tue, 11 Aug 2015 18:14:04 +0200 Original-Received: from localhost ([::1]:35138 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPCBe-0003ga-LU for ged-emacs-devel@m.gmane.org; Tue, 11 Aug 2015 12:14:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32985) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPCBQ-0003fE-Cq for emacs-devel@gnu.org; Tue, 11 Aug 2015 12:13:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZPCBJ-0005di-ME for emacs-devel@gnu.org; Tue, 11 Aug 2015 12:13:48 -0400 Original-Received: from mail-lb0-x235.google.com ([2a00:1450:4010:c04::235]:32980) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPCBJ-0005cv-DI for emacs-devel@gnu.org; Tue, 11 Aug 2015 12:13:41 -0400 Original-Received: by lbbsx3 with SMTP id sx3so32698227lbb.0 for ; Tue, 11 Aug 2015 09:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=F0ovuqjX9WlZViC3lvbX3Lx9ZV3YbJvMqn174MjuH3U=; b=RzicaOzdPq0o2dDZcU+IUWvkTletwHMA05ANqyTA/2FqWvIAmNfpIzxmqSuzEYlTnY q1nQVtNKIkm/02lwNdZK0L+aGBc8+X40WrDZIfX0TNU6FZi1btaj2YqJBUh4VWYLM50r +NWPVJtcOO73J0yKtHeb5qQp+8R/UQ0v3nbTHRlVP2oipv3MaS6yAb+65D8udfd1FQVI YQXTdu1eW+iGah4nX2MdpBKO0q+Vuda28JsF67ol+vjdk/SBq7BUpjNKrI5KiMKofHbm mEV+pY9Q+RyuNFeGsZrWf0Sxdx78hBpAN1tveOTcVGXKDNdA1VwoL4+eLSbXbhFvxDEp 5AgA== X-Received: by 10.152.42.170 with SMTP id p10mr26905846lal.39.1439309619669; Tue, 11 Aug 2015 09:13:39 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id gg1sm562765lbc.27.2015.08.11.09.13.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2015 09:13:38 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::235 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:188727 Archived-At: Thank you, this is a considerable improvement. See comments below. On 08/11/2015 05:56 AM, Stephen Leake wrote: > branch: master > commit d7df36e745a5ba480559b6c8b5ebc93a18fe9bd1 > Author: Stephen Leake > Commit: Stephen Leake > > Always output all available definitions. How come you saw fit to undo the tweaks that I've added over time? In particular, now jumping to whitespace-mode will show two entries, even though they both lead to one location. That's a waste of time. > -(defvar elisp--xref-format > +(defconst elisp--xref-format > (let ((str "(%s %s)")) > (put-text-property 1 3 'face 'font-lock-keyword-face str) > (put-text-property 4 6 'face 'font-lock-function-name-face str) > str)) I'm not sure which part of the change did that, but now I don't see the colors in the output. Even though the approach is questionable, the result should be worth keeping. > +(defconst elisp--xref-format-cl-defmethod > + (let ((str "(%s %s %s)")) > + (put-text-property 1 3 'face 'font-lock-keyword-face str) > + (put-text-property 4 6 'face 'font-lock-function-name-face str) > + str)) > + > +(defcustom find-feature-regexp I think these should still go into find-func.el. Even if you can't require it at the top of elisp-mode.el, you can do that at the beginning of elisp--xref-find-definitions. If that's actually needed. > + ((setq generic (cl--generic symbol)) > + (dolist (method (cl--generic-method-table generic)) > + (let* ((info (cl--generic-method-info method)) > + (met-name (cons symbol (cl--generic-method-specializers method))) > + (descr (format elisp--xref-format-cl-defmethod 'cl-defmethod symbol (nth 1 info))) > + (file (find-lisp-object-file-name met-name 'cl-defmethod))) This should also account, if possible, for the default method definitions performed by cl-defgeneric (and hide them). For instance, looking for project-search-path will display three entries, but the last two both lead to its generic definition. This is actually inaccurate as well, since both the first and the second item come from cl-defgeneric. > +;; When tests are run from the Makefile, 'default-directory' is $HOME, > +;; so we must provide this dir to expand-file-name in the expected > +;; results. The Makefile sets EMACS_TEST_DIRECTORY. > +(defconst emacs-test-dir (getenv "EMACS_TEST_DIRECTORY")) You could also use (or load-file-name (buffer-file-name)). That has the benefit of being usable when tests are run inside the interactive session. Not via Makefile. > +;; Source for both variable and defun is "(define-minor-mode > +;; compilation-minor-mode". There is no way to tell that from the > +;; symbol. (and (fboundp sym) (memq sym minor-mode-list)) seemed to be a decent indicator.