Re: Bad moves with xref-find-definitions

[Dmitry Gutov <dgutov@yandex.ru>]

On 04/25/2015 11:34 PM, Vitalie Spinu wrote:

> Because they just got used to it.

That's a bad explanation. It directly assumes that SLIME developers 
don't know what's good for them.

I think we can settle on the assumption that both approaches are viable.

> Most of people don't track emacs devel.

Still, many do.

> That's not exactly correct. With IDO takes 2-3 keys to select a
> candidate. Navigating to a symbol and then back to the editing location
> takes commonly more. C-u is very difficult to get used to because it's
> an "afore" action and it's inconsistent with other completions in Emacs.

We can really assume usage of Ido in `xref-find-definitions'. Not only 
it's off by default, without `ido-ubiquitous' (a third-party package) 
you simply can't use it with xref-find-definitions.

But 2-3 keypresses sounds like a serious under-estimate to me either 
way. For instance, when I'm on some unrelated symbol, making `C-h f' 
pick `emacs-lisp-mode' forces me to type out at least half of the 
characters in that function's name. I'd probably type it in full until 
it's the first completion, which ends at `emacs-lisp-m' here.

> Human brain is tricky. Mine always chooses the cognitively easier path
> even if it's less efficient in terms of time or muscular effort. I
> couldn't get used to Cider's C-u in half a year of intensive
> use. Instead, I got used to tracking symbols with the cursor pretty
> easily.

Cognitively easier paths are nothing to sneeze at. Who's to say that 
less muscular effort at the expense of more cognitive one is always better?

Further, `C-s emacs-li' in the current buffer followed by M-. might turn 
out to be the same amount of keypresses, even if cursor is currently far 
from that symbol.

>   > In my view, "jump to the thing at point" is a different kind of operation (and
>   > it can work with symbols, file paths, etc).
>
> I fail to see this difference. Instant opening of the doc on symbol
> under point makes as much sense to me as jumping to its definition.

And indeed, SLIME has a set of commands that do just that. 
elisp-slime-nav copies it in its `C-c C-d C-d'.

It's quite nice, even if I've stopped using it around those same 4 
months ago.

Maybe I should say that the `C-h ???' are a special set, and changing 
how they all behave would be harder. Those keybindings aren't as snappy 
as `M-.' or `C-c C-d' anyway.

And find-file is inherently an operation that doesn't usually use the 
content at point.

>   > But while you're only person requesting it, you can modify the
>   > current behavior trivially with `advice-add'.
>
> Well. Cider switched to standard Emacs ways because most of other people
> (including the lead developer) recognized the need for the change.

Did you have a vote?

 From the first thread, I recall Bozhidar stating that both ways have 
merits.

> Good defaults are very hard, mainly because you have to abstract from
> you own habits and think about future generations of users. Most people
> get used to whatever the default is. In this respect the current default
> is rather unfortunate as it will make new folks use navigation commands
> more often than they need to.

Moving point has its own benefits. For instance, when you press `M-,', 
you instantly see which function call the previous jump was related to.

That makes following the control flow of unfamiliar code much easier.

> I don't quite follow. Does xref rely on completion-at-point-functions? I
> don't see this in the code.

No, it's a separate feature, but the principle is the same: by default, 
completion uses the tags table. Major modes (and some minor modes) add 
elements at the beginning of that hook, effectively blocking 
tags-completion-at-point-function from being used in corresponding 
buffers. Is that a problem? Not so much.

> One can do a lot of things in emacs. A lot of emacs users don't even
> know the basics of elisp.

We hope that those users will feel satisfied with the default behavior.

> The point is that tags became more difficult to use. In some modes they
> work, in others they don't. True that loads of modes rebind M-. In this
> respect xref.el is only a marginal improvement. Whether they bind
> M-. directly or set xref-find-definition it's the same cake to the
> mortals.

Some modes use tags, other ones use facilities they consider better than 
tags. If you think a certain mode should use tags in more situations, 
that's as good cause for a bug report as any.

> If you somehow could merge multiple backends into one navigation system,
> that would be a truly big deal. Till then `xref-etags-mode` and alike
> feel like clumsy workarounds.

This request is too vague, sorry. Feel free to outline a specific design 
in a new bug report.