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: Generalizing find-definition Date: Sun, 02 Nov 2014 21:22:03 -0500 Message-ID: References: <20141102151524.0d9c665c@forcix> <20141102172944.0f7944e3@forcix> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1414981360 28886 80.91.229.3 (3 Nov 2014 02:22:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2014 02:22:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: Jorgen Schaefer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 03 03:22:33 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 1Xl7Ht-0003JS-9a for ged-emacs-devel@m.gmane.org; Mon, 03 Nov 2014 03:22:33 +0100 Original-Received: from localhost ([::1]:60001 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xl7Hs-0000Mm-RZ for ged-emacs-devel@m.gmane.org; Sun, 02 Nov 2014 21:22:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45635) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xl7HY-0000Lo-GU for emacs-devel@gnu.org; Sun, 02 Nov 2014 21:22:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xl7HQ-0007Ps-V5 for emacs-devel@gnu.org; Sun, 02 Nov 2014 21:22:12 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:19368) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xl7HQ-0007Pm-Rq for emacs-devel@gnu.org; Sun, 02 Nov 2014 21:22:04 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8NAOatTlRFpY87/2dsb2JhbABcgw6BLII2hn7LUwQCAoEcFwEBfIQDAQEDAVYjBQsLDiYSFA0LDSQTG4gRAwkJxS0NhjgBAQEHAgEfinCDXoI6B4RLBYUVAoZNhAWLZ5FihG6Bb4QWHy+CSwEBAQ X-IPAS-Result: Ag8NAOatTlRFpY87/2dsb2JhbABcgw6BLII2hn7LUwQCAoEcFwEBfIQDAQEDAVYjBQsLDiYSFA0LDSQTG4gRAwkJxS0NhjgBAQEHAgEfinCDXoI6B4RLBYUVAoZNhAWLZ5FihG6Bb4QWHy+CSwEBAQ X-IronPort-AV: E=Sophos;i="5.04,797,1406606400"; d="scan'208";a="95812668" Original-Received: from 69-165-143-59.dsl.teksavvy.com (HELO ceviche.home) ([69.165.143.59]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Nov 2014 21:22:03 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id A3CE3660F3; Sun, 2 Nov 2014 21:22:03 -0500 (EST) In-Reply-To: <20141102172944.0f7944e3@forcix> (Jorgen Schaefer's message of "Sun, 2 Nov 2014 17:29:44 +0100") 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:176246 Archived-At: > 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. This said, one of the benefits of the generic functionality you're suggesting is that users can easily rebind those commands and know that this will affect consistently all packages providing the functionality. >> M-. RET does "find the callers of a symbol at point", AFAICT. Duh, sorry for being dense, of course it doesn't. etags does not offer the needed info, so the etags.el UI doesn't have such a thing. Helmut Eller writes: > bind it at all. SLIME will definitely keep the M-./M-, pair, well > knowing that it's incompatible with the binding for tags-loop-continue. When SLIME uses the new functionality it should mess with its key bindings at all, so the user can more easily make global changes to those key bindings. > In my experience, tags-loop-continue is rather hard to use and I have > long argued to get rid of it and replace it with a better UI. > E.g. tags-loop-continue must be pressed multiple times just to find out > at the end that none of the offered candidates was relevant. SLIME does > it differently: the list of all candidates is displayed in a separate > buffer with one candidate per line; a bit like the results of a search > engine like Google. The user must then move the cursor to the > interesting line and press RET to actually jump to the definition. If > there's only a single candidate, then there's no need to display the > list and we can jump to the candidate right away. SLIME has no analog > to tags-loop-continue (and no key binding for it) because it's not > needed; at least nobody ever asked for such a command. I agree that tags-loop-continue is not super convenient. 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? > 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". - "list uses of thing at point". - "return to buffer/position before the last jump". And on the backend side we have: - identifier-at-point-function - find-definition-function (with an argument to decide whether we want a whole list or just the best/first candidate). - find-uses-function Etags.el currently offers some additional functionality: - jump to definition of any identifier, with TAB-completion. - jump to file (among those listed in the TAGS file), tho currently without TAB-completion. AFAICT, the first could be implemented just in the generic code, except for TAB-completion. And the second one is also provided by things like projectile (among many other thingies), tho it seems that none of the bundled Emacs packages provide a good solution for that common need. Stefan