Re: Bad moves with xref-find-definitions

[Bozhidar Batsov <bozhidar@batsov.com>]

[-- Attachment #1: Type: text/plain, Size: 3229 bytes --]

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 <dgutov@yandex.ru> 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?
>
>

[-- Attachment #2: Type: text/html, Size: 4329 bytes --]