From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: emacs-lisp-mode and find-tag Date: Fri, 20 Jun 2014 13:35:07 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1403285748 31985 80.91.229.3 (20 Jun 2014 17:35:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Jun 2014 17:35:48 +0000 (UTC) Cc: ams@gnu.org, emacs-devel To: Josh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 20 19:35:40 2014 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 1Wy2iy-0007lp-Io for ged-emacs-devel@m.gmane.org; Fri, 20 Jun 2014 19:35:40 +0200 Original-Received: from localhost ([::1]:42226 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wy2iy-0004KJ-6Y for ged-emacs-devel@m.gmane.org; Fri, 20 Jun 2014 13:35:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38113) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wy2ii-0004K8-WC for emacs-devel@gnu.org; Fri, 20 Jun 2014 13:35:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wy2ia-0001C2-Ab for emacs-devel@gnu.org; Fri, 20 Jun 2014 13:35:24 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:41267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wy2iS-00019T-FC; Fri, 20 Jun 2014 13:35:08 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNLd+D9/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSSIBAjSGReOegeEOASpGYFqg0wh X-IPAS-Result: ArUGAIDvNVNLd+D9/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSSIBAjSGReOegeEOASpGYFqg0wh X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="68827035" Original-Received: from 75-119-224-253.dsl.teksavvy.com (HELO pastel.home) ([75.119.224.253]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 20 Jun 2014 13:35:07 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 32A3661711; Fri, 20 Jun 2014 13:35:07 -0400 (EDT) In-Reply-To: (josh@foxtail.org's message of "Fri, 20 Jun 2014 09:52:41 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:172583 Archived-At: > +1. There was a discussion[0] about this topic last year and > apparent agreement in principle, but the details are yet to be > worked out. At least two implementations exist already, one > being the patch Leo submitted with that bug and the other being > the `elisp-slime-nav' package I mentioned in that thread (and > whose author has also assigned copyright). Both of those provide navigation commands for Elisp, yes. I'm more interested in introducing generic code, which relies on a `find-tag-function` hook to do the work of finding the definition. > If we do define a standard set of source navigation key bindings, > I hope it includes one for jumping to symbols' references. Unlike > M-. for jumping to definitions, jumping to references doesn't seem > to have a standard binding, even though it's often very handy. Indeed. In general, we need a hooks `find-tag-definition-functions` This should hold functions of one argument (a string): it should return a list of the form (BUFFER-OR-FILE POSITION NEXT) where POSITION can be either a position in a buffer (integer/marker) or a pair (LINE . COLUMN) where COLUMN can be nil. NEXT if non-nil could be a function which will return the same info but for the next definition. Of course both can return nil. Then we need generic code which uses this function to provide the M-. and M-* functionality, plus glue code for etags.el (which should get us back the exact same functionality we have now). Then we can start adding more glue code for other backend: find-function, imenu, semantic, ... And yes, we can add also a find-tag-definition-functions. As well as hooks to get a quick summary (tho we could maybe just use eldoc-documentation-function) and another to get the "full" doc. Stefan