From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bozhidar Batsov Newsgroups: gmane.emacs.devel Subject: Re: Bad moves with xref-find-definitions Date: Sun, 26 Apr 2015 09:38:06 +0300 Message-ID: References: <87h9s6c27z.fsf@gmail.com> <87zj5wnlyt.fsf@gmail.com> <553BE6F2.4030604@yandex.ru> <87fv7ondlr.fsf@gmail.com> <553C5D75.9060706@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1133f92e3a31d005149adf59 X-Trace: ger.gmane.org 1430030306 28816 80.91.229.3 (26 Apr 2015 06:38:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Apr 2015 06:38:26 +0000 (UTC) Cc: Vitalie Spinu , Stefan Monnier , emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 26 08:38:25 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 1YmGCu-0001WG-UW for ged-emacs-devel@m.gmane.org; Sun, 26 Apr 2015 08:38:25 +0200 Original-Received: from localhost ([::1]:50017 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmGCt-0005ZR-TP for ged-emacs-devel@m.gmane.org; Sun, 26 Apr 2015 02:38:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57218) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmGCf-0005ZF-Rj for emacs-devel@gnu.org; Sun, 26 Apr 2015 02:38:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YmGCe-0002nE-Ex for emacs-devel@gnu.org; Sun, 26 Apr 2015 02:38:09 -0400 Original-Received: from mail-la0-x231.google.com ([2a00:1450:4010:c03::231]:33016) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmGCe-0002ms-21 for emacs-devel@gnu.org; Sun, 26 Apr 2015 02:38:08 -0400 Original-Received: by layy10 with SMTP id y10so60143253lay.0 for ; Sat, 25 Apr 2015 23:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=87b6C0O0XvufKJ3SyVTZR534GxDdF7BxSypQWYxtXxM=; b=C2/rIWpVmVxeMopguckh6nEW0DX+zQAqYvBlaUIFYiwC7ZnIQXC9zeiSg3hPZ0W9RW xS4tc8wBGoWqoV1cuWNykTuvXiORqp1ZqpbHflQUbcFWljLlhLXcFeHJ0zI3sFAbjI+f 0cBORNlDBiW80AWAm4WM0Y5lrsEeD7OLzjjz4TEIfpkiTxuHI1MUAkWLkxDee0zg0NWA h6Ycx9UDRz6AQlXfzTZq+GPBkHUmDZ4E6BTiYWhYpPN2Gh0maj99LbyAA3bViQRz92PF ZujkNmezT6hU0g/WJbJQdxGu5YKASR/RlhqFYBDIDugv+2fd+RbtyDAnAuIpeK05OBbv +LKQ== X-Received: by 10.112.184.70 with SMTP id es6mr5115013lbc.117.1430030286203; Sat, 25 Apr 2015 23:38:06 -0700 (PDT) Original-Received: by 10.112.25.7 with HTTP; Sat, 25 Apr 2015 23:38:06 -0700 (PDT) In-Reply-To: <553C5D75.9060706@yandex.ru> X-Google-Sender-Auth: AuOVy07vZJQ9LbnTtAG8toR3ppM X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::231 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:185902 Archived-At: --001a1133f92e3a31d005149adf59 Content-Type: text/plain; charset=UTF-8 Let me join this discussion. As the maintainer of CIDER, I had to participate into a much longer debate about the merits of both styles on the CIDER issue tracker and feel I can share a thought or two. I believe that the fundamental problem we face is that finding something is not the same as acting on the thing at point. When you opt to immediately act on the symbol/file/etc on point you're forcing the users to do one of two things: * find some suitable place to invoke a command (e.g. move their cursor to a symbol or to an empty place in the buffer) * start wondering what prefix to prepend to the command to alter its behaviour While I think that for navigating sources acting on the thing at point probably makes more sense, when writing code (meaning you'll need to do some doc lookups) you're often wondering "What was the behavior of this function?" or "What were I supposed to use here?" and it's unlikely that the thing at point will help you much (unless you're simply reading code). The global config, as implemented now in CIDER ,has the disadvantage of insufficient granularity - e.g. I'd like to always jump to the source of thing at point, but I wouldn't like for other commands to behave like this. But as the config option controls all similar commands, all of them behave in the same way - either acting on the thing at point or always prompting for confirmation. Clearly I can roll out any custom solution that suits my needs (we're in Emacs after all), but I feel we have a deeper usability problem in Emacs in general and it'd be nice if we could come to some universal solution. Maybe two sets of matching commands per each such operation or something (although handy keybindings are always in short supply). As to whether SLIME's behaviour is preferable to Emacs's - as usual that's super subjective. Btw, the idea of having standard behaviour in major modes for finding definitions, usages & documentation is not bad at all. On 26 April 2015 at 06:37, Dmitry Gutov wrote: > On 04/25/2015 11:43 PM, Vitalie Spinu wrote: > > It probably should be generic such that other "finding" or "jumping" >> functionality can reuse it (prompt-before-jump, auto-jump). >> > > Maybe the rule could be whether the command is almost always related to > the current buffer's contents. > > `describe-function' and friends I would actually consider to be > counter-examples, because they only work with Elisp. > > And similarly how certain other people are attached to etags, I'd always > want to have access to Elisp documentation and sources, even when editing > unrelated code in another language. > > Hence I think we need a separate, generalizable command and binding that > would work with different modes and depend on the current language or > project. That one could work like SLIME's `C-c C-d C-d'. > > The problem is of course that "find-file" is also a "finding" behavior, >> for which you unlikely to want this behavior. So it's difficult to draw >> a line on what are these commands. >> > > Let's stop at xref, for now. > > More specific name like xref-auto-jump seems quite suggestive to me. >> > > How about `xref-prompt-for-identifier', to mirror CIDER's option name? > > --001a1133f92e3a31d005149adf59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let me join this discussion. As the maintainer of CIDER, I= had to participate into a much longer debate about the merits of both styl= es on the CIDER issue tracker and feel I can share a thought or two.
I believe that the fundamental problem we face is that finding= something is not the same as acting on the thing at point. When you opt to= immediately act on the symbol/file/etc on point you're forcing the use= rs to do one of two things:

* find some suitable p= lace to invoke a command (e.g. move their cursor to a symbol or to an empty= place in the buffer)
* start wondering what prefix to prepend to= the command to alter its behaviour

While I think = that for navigating sources acting on the thing at point probably makes mor= e sense, when writing code (meaning you'll need to do some doc lookups)= you're often wondering "What was the behavior of this function?&q= uot; or "What were I supposed to use here?" and it's unlikely= that the thing at point will help you much (unless you're simply readi= ng code).=C2=A0

The global config, as implemented = now in CIDER ,has the disadvantage of insufficient granularity - e.g. I'= ;d like to always jump to the source of thing at point, but I wouldn't = like for other commands to behave like this. But as the config option contr= ols all similar commands, all of them behave in the same way - either actin= g on the thing at point or always prompting for confirmation.=C2=A0

Clearly I can roll out any custom solution that suits my = needs (we're in Emacs after all), but I feel we have a deeper usability= problem in Emacs in general and it'd be nice if we could come to some = universal solution. Maybe two sets of matching commands per each such opera= tion or something (although handy keybindings are always in short supply).= =C2=A0

As to whether SLIME's behaviour is pref= erable to Emacs's - as usual that's super subjective.=C2=A0

Btw, the idea of having standard behaviour in major modes= for finding definitions, usages & documentation is not bad at all.=C2= =A0

On= 26 April 2015 at 06:37, Dmitry Gutov <dgutov@yandex.ru> wrot= e:
On 04/25/2015 11:43 P= M, Vitalie Spinu wrote:

It probably should be generic such that other "finding" or "= jumping"
functionality can reuse it (prompt-before-jump, auto-jump).

 Maybe the rule could be whether the command is almost always related to the= current buffer's contents.

`describe-function' and friends I would actually consider to be counter= -examples, because they only work with Elisp.

And similarly how certain other people are attached to etags, I'd alway= s want to have access to Elisp documentation and sources, even when editing= unrelated code in another language.

Hence I think we need a separate, generalizable command and binding that wo= uld work with different modes and depend on the current language or project= . That one could work like SLIME's `C-c C-d C-d'.<= br>
The problem is of course that "find-file" is also a "finding= " behavior,
for which you unlikely to want this behavior. So it's difficult to draw=
a line on what are these commands.

 Let's stop at xref, for now.

More specific name like xref-auto-jump seems quite suggestive to me.

 How about `xref-prompt-for-identifier', to mirror CIDER's option na= me?


--001a1133f92e3a31d005149adf59--