From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: Generalizing find-definition Date: Sun, 02 Nov 2014 20:51:40 +0100 Message-ID: References: <20141102151524.0d9c665c@forcix> <20141102172944.0f7944e3@forcix> <20141102193514.279d3053@forcix> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1414957953 17328 80.91.229.3 (2 Nov 2014 19:52:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Nov 2014 19:52:33 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 02 20:52:26 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 1Xl1CL-0007t7-QE for ged-emacs-devel@m.gmane.org; Sun, 02 Nov 2014 20:52:25 +0100 Original-Received: from localhost ([::1]:59065 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xl1CL-0000zo-GI for ged-emacs-devel@m.gmane.org; Sun, 02 Nov 2014 14:52:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55417) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xl1C2-0000zG-LI for emacs-devel@gnu.org; Sun, 02 Nov 2014 14:52:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xl1Bu-0008KV-TR for emacs-devel@gnu.org; Sun, 02 Nov 2014 14:52:06 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:41280) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xl1Bu-0008KH-MS for emacs-devel@gnu.org; Sun, 02 Nov 2014 14:51:58 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xl1Bs-0007k1-VQ for emacs-devel@gnu.org; Sun, 02 Nov 2014 20:51:57 +0100 Original-Received: from dial-181146.pool.broadband44.net ([212.46.181.146]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 02 Nov 2014 20:51:56 +0100 Original-Received: from eller.helmut by dial-181146.pool.broadband44.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 02 Nov 2014 20:51:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 44 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: dial-181146.pool.broadband44.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) Cancel-Lock: sha1:y6aOLzso130Zp7IIJgQmm8JloLQ= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:176242 Archived-At: On Sun, Nov 02 2014, Jorgen Schaefer wrote: > Could you elaborate a bit on what you'd like to see for "a good UI"? My > idea so far was to simply have modes provide a function that returns a > marker or nil, while the function can check for interactive calls if it > wants to, and use that in the usual go to location in same > window/other window/other frame and go back. But I'm very open to ideas > to make this better. Let me define a bit of terminology that I use in SLIME: M-. parses the "symbol" at point and then asks the external process to search a list of "candidates" that match the symbol. A candidate is a "location" with a short description. A location is a file:line:column triple (in the simplest case). The primary complication for a "good UI" is the case when there is more than one candidate. etags.el solves this complication by introducing the tags-loop-continue command to cycle through the list of candidates (I think etags.el does not compute an explicit list of candidates, but instead keeps a marker in the TAGS buffer and tags-loop-continue will quite literally continue the search starting from that marker). I don't like this kind of UI. It would be better to display the list of candidates instead of keeping it hidden. Displaying the list of candidates in an auxiliary buffer, make it easy to select an interesting candidate and finally close the buffer is the job of the UI. Doing this well is not so easy. I spent quite some time to make it good in SLIME. It's still not perfect, but IMO way better than what etags.el offers. Parsing the "symbol" at point for M-. will be language dependent and some language may need to determine a lot of context (current module/class/function etc.). In SLIME, it's relatively easy as we only need to determine the current package and then the symbol like in Elisp. I think a "good UI" should, by default, determine the symbol around point without asking each time (as find-tag does). BTW: M-x rgrep needs to solve similar UI issues as it also needs to deal with a "list of candidates". Maybe there's an opportunity to share/unify some things. Helmut