From: Dmitry Gutov <dgutov@yandex.ru>
To: Vitalie Spinu <spinuvit@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Bad moves with xref-find-definitions
Date: Sun, 26 Apr 2015 03:20:01 +0300 [thread overview]
Message-ID: <553C2F31.4070202@yandex.ru> (raw)
In-Reply-To: <87k2x0ne0x.fsf@gmail.com>
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.
next prev parent reply other threads:[~2015-04-26 0:20 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-23 15:07 Bad moves with xref-find-definitions Vitalie Spinu
2015-04-25 14:24 ` Stefan Monnier
2015-04-25 16:25 ` Dmitry Gutov
2015-04-25 17:42 ` Vitalie Spinu
2015-04-25 18:49 ` Vitalie Spinu
2015-04-25 19:07 ` Dmitry Gutov
2015-04-25 18:56 ` João Távora
2015-04-25 23:50 ` Dmitry Gutov
2015-04-26 11:51 ` xref backends for elisp-related modes Was: " João Távora
2015-04-26 13:56 ` Dmitry Gutov
2015-04-26 14:51 ` Eli Zaretskii
2015-04-28 11:06 ` Vitalie Spinu
2015-04-28 11:41 ` João Távora
2015-04-28 11:59 ` Vitalie Spinu
2015-04-28 15:17 ` Eli Zaretskii
2015-04-28 15:45 ` Vitalie Spinu
2015-04-28 16:01 ` Eli Zaretskii
2015-04-28 13:27 ` Stefan Monnier
2015-04-28 21:28 ` Dmitry Gutov
2015-04-29 12:35 ` Vitalie Spinu
2015-04-29 15:45 ` Eli Zaretskii
2015-04-28 15:15 ` Eli Zaretskii
2015-04-28 15:47 ` Vitalie Spinu
2015-04-28 16:03 ` Eli Zaretskii
2015-04-29 6:55 ` Helmut Eller
2015-04-29 12:40 ` Vitalie Spinu
2015-04-29 13:01 ` Helmut Eller
2015-04-29 15:30 ` Vitalie Spinu
2015-04-29 17:09 ` Dmitry Gutov
2015-04-29 12:47 ` Dmitry Gutov
2015-04-29 13:04 ` Helmut Eller
2015-04-29 13:12 ` Dmitry Gutov
2015-04-27 2:20 ` Stefan Monnier
2015-04-25 19:11 ` Dmitry Gutov
2015-04-25 20:43 ` Vitalie Spinu
2015-04-26 3:37 ` Dmitry Gutov
2015-04-26 6:38 ` Bozhidar Batsov
2015-04-26 18:41 ` Dmitry Gutov
2015-04-27 19:36 ` Bozhidar Batsov
2015-04-28 1:23 ` Dmitry Gutov
2015-04-28 11:30 ` Vitalie Spinu
2015-04-26 10:44 ` Vitalie Spinu
2015-04-26 13:14 ` Vitalie Spinu
2015-04-26 15:09 ` Dmitry Gutov
2015-04-26 16:23 ` Vitalie Spinu
2015-04-26 17:51 ` Dmitry Gutov
2015-04-26 20:56 ` Vitalie Spinu
2015-04-27 21:57 ` Dmitry Gutov
2015-04-26 3:34 ` Stefan Monnier
2015-04-26 11:31 ` Vitalie Spinu
2015-04-26 14:50 ` Eli Zaretskii
2015-04-26 15:12 ` Dmitry Gutov
2015-04-26 15:32 ` Eli Zaretskii
2015-04-26 15:20 ` Dmitry Gutov
2015-04-26 16:01 ` Vitalie Spinu
2015-04-26 17:26 ` Dmitry Gutov
2015-04-27 2:26 ` Stefan Monnier
2015-04-25 19:01 ` Dmitry Gutov
2015-04-25 20:34 ` Vitalie Spinu
2015-04-25 21:44 ` Vitalie Spinu
2015-04-26 0:20 ` Dmitry Gutov [this message]
2015-04-26 0:28 ` Dmitry Gutov
2015-04-28 15:31 ` Vitalie Spinu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=553C2F31.4070202@yandex.ru \
--to=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=spinuvit@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.