From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jorgen Schaefer Newsgroups: gmane.emacs.devel Subject: Re: Generalizing find-definition Date: Mon, 3 Nov 2014 08:44:33 +0100 Message-ID: <20141103084433.12117c03@forcix> References: <20141102151524.0d9c665c@forcix> <20141102172944.0f7944e3@forcix> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1415000700 8300 80.91.229.3 (3 Nov 2014 07:45:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2014 07:45:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 03 08:44:53 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 1XlCJo-0002ZC-ST for ged-emacs-devel@m.gmane.org; Mon, 03 Nov 2014 08:44:53 +0100 Original-Received: from localhost ([::1]:60807 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlCJo-0001NS-Hf for ged-emacs-devel@m.gmane.org; Mon, 03 Nov 2014 02:44:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37519) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlCJe-0001Eu-TD for emacs-devel@gnu.org; Mon, 03 Nov 2014 02:44:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlCJY-00072H-UU for emacs-devel@gnu.org; Mon, 03 Nov 2014 02:44:42 -0500 Original-Received: from loki.jorgenschaefer.de ([87.230.15.51]:37091) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlCJY-000725-Lz for emacs-devel@gnu.org; Mon, 03 Nov 2014 02:44:36 -0500 Original-Received: by loki.jorgenschaefer.de (Postfix, from userid 998) id 498E42045AD; Mon, 3 Nov 2014 08:44:35 +0100 (CET) Original-Received: from forcix (port-4853.pppoe.wtnet.de [84.46.19.8]) by loki.jorgenschaefer.de (Postfix) with ESMTPSA id 8F65C2045A9; Mon, 3 Nov 2014 08:44:34 +0100 (CET) In-Reply-To: X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.25; i586-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 87.230.15.51 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:176252 Archived-At: On Sun, 02 Nov 2014 21:22:03 -0500 Stefan Monnier wrote: > > The idea would be to simply swap M-, and M-*, so M-* would then be > > `tags-loop-continue'. > > I'm not sure what would be the benefit of such a swap. The only benefit would be that M-, is now "go back after M-.", which is what a lot of the packages that redefine M-. do to the key. Hence the suggestion to swap the two keys, to unify that apparently rather widespread use of M-,. If Emacs would prefer to keep M-, as is, that is fine with me, too. > What key-binding does SLIME use to get this list buffer (which would > most naturally be implemented as a kind of grep/compilation-mode > buffer)? Would C-u M-. be usable for that? All of SLIME, slime-nav, Geiser and Cider use C-u M-. to prompt the user for a symbol name to go to instead of using the symbol at point, so that might be a useful generalized function if we do not need the prefix for the "next" feature of etags. > > ada-mode also has "show all references of name at point", which > > currently pops up a buffer in compilation-mode, showing > > compilation-style locations of all uses. That's similar > > functionality to find-tag/tags-loop-continue, and similar UI to > > SLIME. > > Sounds like we agree. > > So on the UI side we mostly have: > - "jump to *the* definition of thing at point". > - "list definitions of thing at point". Agreed. So far, I would say this is the same key binding (M-.) which then either jumps to the definition if there is one, or lists them if there is more than one. > - "list uses of thing at point". What key binding would you suggest for that? SLIME apparently uses M-_ and M-? (i.e. the key right of . in different keyboard layouts). > - "return to buffer/position before the last jump". Agreed. > And on the backend side we have: > - identifier-at-point-function Why do we need this? It does not make much sense for this functionality in languages with combined identifiers. For example, in Python, "foo.bar()" can be pretty much anything, it depends heavily on the context. Libraries for introspection expect a position in a file/buffer, not an identifier, to find the definitions. > - find-definition-function (with an argument to decide whether we want > a whole list or just the best/first candidate). I am not sure if it is generally easily possible to sort the list of candidates like that. I guess tags often has the problem of knowing more than one possible candidate, so it would be preferable for tags to default to a single destination? > Etags.el currently offers some additional functionality: > - jump to definition of any identifier, with TAB-completion. C-u M-. could call a separate function when set, which would be provided by the mode author to prompt for an identifier (with tab completion if possible) and goes to the definition of that symbol. Regards, Jorgen