[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.
Helmut
- Generalizing find-definition, Jorgen Schaefer, 2014/11/02
- Re: Generalizing find-definition, Stefan Monnier, 2014/11/02
- Re: Generalizing find-definition, Helmut Eller, 2014/11/03
- Re: Generalizing find-definition, Jorgen Schaefer, 2014/11/03
- Re: Generalizing find-definition, Stephen Leake, 2014/11/03
- Re: Generalizing find-definition, Stefan Monnier, 2014/11/03
- Re: Generalizing find-definition, Jorgen Schaefer, 2014/11/03
- Re: Generalizing find-definition, Stefan Monnier, 2014/11/03