[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Generalizing find-definition
From: |
Jorgen Schaefer |
Subject: |
Re: Generalizing find-definition |
Date: |
Sun, 2 Nov 2014 17:29:44 +0100 |
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.
> > C-M-. is currently bound to find-tag-regexp. There is currently no
> > standard functionality in Emacs to find the callers of a symbol at
> > point, which might be nice to put on C-M-. if it is defined at some
> > point for symmetry reasons.
>
> M-. RET does "find the callers of a symbol at point", AFAICT.
I must be missing something - how does this work? M-. should jump
to the definition of the symbol at point, then RET should just enter a
newline? And if M-. prompts for a tag, RET will just accept the default?
Apparently, SLIME uses M-_ and M-? for edit-uses (to accomodate
differing keyboard layouts), so that might be a better choice anyhow.
> > Comments?
>
> I'm all for it,
Thank you. I'll wait for more feedback and will work on this after the
official git transition.
Regards,
Jorgen
- 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