[Top][All Lists]

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

Re: Generalizing find-definition

From: Helmut Eller
Subject: Re: Generalizing find-definition
Date: Sun, 02 Nov 2014 19:14:55 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

On Sun, Nov 02 2014, Jorgen Schaefer wrote:

> On Sun, 02 Nov 2014 10:34:28 -0500
> Stefan Monnier <address@hidden> wrote:
>> > M-* is the standard opposite command for this, so that would be
>> > extracted as well.  SLIME and a few other modes re-define M-, to be
>> > the opposite for M-. instead for easier navigation.  How do you
>> > feel about swapping the definition of M-, and M-* in etags.el?
>> That's incompatible with the current M-, binding.
>> What would then be the equivalent of the current M-, ?
> The idea would be to simply swap M-, and M-*, so M-* would then be
> `tags-loop-continue'. As I do not use tags, I do not know how often
> that command is used and whether M-* is too inconvenient for this,
> though.

In SLIME, M-, and M-* do the same thing.

Using M-, for pop-tag-mark is IMO very desirable, because on most
keyboards . and , are on adjacent keys and it's easy, almost pleasant,
to jump to a definition and back -- at least in the case when there's a
unique match.

We keep the binding for M-* around mostly because some users have stored
it in their muscle memory.  But it seems to me that M-* is quite hard to
press (on US keyboards) and if it weren't for tradition, we wouldn't
bind it at all.  SLIME will definitely keep the M-./M-, pair, well
knowing that it's incompatible with the binding for tags-loop-continue.

In my experience, tags-loop-continue is rather hard to use and I have
long argued to get rid of it and replace it with a better UI.
E.g. tags-loop-continue must be pressed multiple times just to find out
at the end that none of the offered candidates was relevant.  SLIME does
it differently: the list of all candidates is displayed in a separate
buffer with one candidate per line; a bit like the results of a search
engine like Google.  The user must then move the cursor to the
interesting line and press RET to actually jump to the definition.  If
there's only a single candidate, then there's no need to display the
list and we can jump to the candidate right away.  SLIME has no analog
to tags-loop-continue (and no key binding for it) because it's not
needed; at least nobody ever asked for such a command.

For SLIME, we would happily use the "standard" find-definition
infrastructure if it comes with a good UI.  The tags-loop-continue based
design is not acceptable for us.


reply via email to

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