Re: Bad moves with xref-find-definitions

[Dmitry Gutov <dgutov@yandex.ru>]

On 04/26/2015 09:38 AM, Bozhidar Batsov wrote:

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

"Press C-u to explicitly enter something" is a pretty common Emacs 
pattern. If all modes use the xref interface, it'll become even less of 
a problem.

But on the subject of "what prefix", I think you've made a mistake using 
`C-u' for "show in the other window". Emacs normally uses `C-x 4' for 
that, which is only one keypress longer. The users who prefer the "other 
window" behavior can simply switch the bindings.

> While I think that for navigating sources acting on the thing at point
> probably makes more sense,

It can also be beneficial in other ways. Like I've described in another 
thread, if you're reading a function, say, for the first time and are 
trying to trace its control flow, moving point to the symbol before 
`M-.' means you'll immediately know where you "came from" after pressing 
`M-,'.

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

Which function? Where's the set of functions you're choosing from? If 
the function name is not at point, I'm guessing it's just not typed out 
fully. In that case, you'll probably delegate to the "find doc" or the 
"find sources" function of the completion interface you're using.

In `completion-at-point''s case, you'll probably first complete the name 
fully and then jump to it. However, using xref-find-apropos is not out 
of the question either.

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

The settings granularity shouldn't be that much a problem: introduce 
another possible value for cider-prompt-for-symbol, which will be a list 
of commands for which to always prompt.

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

The key question is which set of commands the variable can affect at 
all. For me, "jump to", "show references" and "show doc", all should use 
the contents at point by default.

> Maybe two sets of matching commands per each such operation or something
> (although handy keybindings are always in short supply).

Probably not: being able to press `C-u' together with a per-command user 
option should be enough for everyone.