[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bad moves with xref-find-definitions
Re: Bad moves with xref-find-definitions
Sun, 26 Apr 2015 03:20:01 +0300
Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0
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
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
> 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
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
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
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.
Re: Bad moves with xref-find-definitions, Dmitry Gutov, 2015/04/25