emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bad moves with xref-find-definitions


From: Bozhidar Batsov
Subject: Re: Bad moves with xref-find-definitions
Date: Sun, 26 Apr 2015 09:38:06 +0300

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 <address@hidden> 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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]