From: Vitalie Spinu <spinuvit@gmail.com>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: emacs-devel@gnu.org
Subject: Re: Bad moves with xref-find-definitions
Date: Sat, 25 Apr 2015 22:34:06 +0200 [thread overview]
Message-ID: <87k2x0ne0x.fsf@gmail.com> (raw)
In-Reply-To: <553BE49B.20302@yandex.ru> (Dmitry Gutov's message of "Sat, 25 Apr 2015 22:01:47 +0300")
>>> 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
next prev parent reply other threads:[~2015-04-25 20:34 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 [this message]
2015-04-25 21:44 ` Vitalie Spinu
2015-04-26 0:20 ` Dmitry Gutov
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=87k2x0ne0x.fsf@gmail.com \
--to=spinuvit@gmail.com \
--cc=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
/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.