Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>> Dmitry Gutov on Sat, 25 Apr 2015 22:01:47 +0300 wrote:

 > SLIME has plenty of users who find the approach convenient.

Because they just got used to it. I got used to it myself with CIDER,
but at least I recognize the annoyance of flow disruption and C-u
inconvenience. One RET speedup is really not worth it IMO.

 > And this is the first complaint we've received about that aspect, in
 > the four months since xref had been introduced.

Most of people don't track emacs devel. I tend to upgrade every 3 months
or so. So here I am, complaining first time I saw it.

 > Since you're usually intent on typing out the symbol name, pressing
 > `C-u' before that shouldn't make a lot of difference.

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.

 >> Now, "xref-find-definitions" encourages you to navigate to a symbol
 >> by disrupting the flow twice. Once, when you navigate to a symbol,
 >> and often for the second time when you need to go back to the
 >> editing after you saw the definition. This just fosters a bad habit
 >> of tracking what you read with a cursor. It just cannot be right.

 > I don't know if it's a bad habit. Apparently, it's a common one.

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.

 >> Needless to say that most other functionality in Emacs does ask for
 >> completion before performing an action (documentation, find-file
 >> etc).

 > 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.

 > 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.

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.

 > `completion-at-point-functions' defaults to
 > `'(tags-completion-at-point-function)'. Are you also worried about a
 > major mode overriding it? That's the whole point of adding this kind
 > of variable.

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

 > And if by any chance the major mode does a poor job, you can use 
 > xxx-mode-hook
 > to override it back. In this case, there already exists `xref-etags-mode',
 > because of a prior request.

 > You can also add a separate binding for it. And if/when `find-tag' goes away,
 > you can use that binding for a new command wrapping `xref-find-definitions'.

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

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.

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.


  Vitalie