* Re: emacs-lisp-mode and find-tag
@ 2014-06-20 20:22 Barry OReilly
2014-06-21 1:08 ` Stefan Monnier
0 siblings, 1 reply; 12+ messages in thread
From: Barry OReilly @ 2014-06-20 20:22 UTC (permalink / raw)
To: monnier, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 226 bytes --]
> `find-tag-definition-functions`
> This should hold functions of one argument (a string)
As I remarked in the bug report, the tag name alone is not
sufficient for Semantic, because it considers the code
surrounding the tag.
[-- Attachment #2: Type: text/html, Size: 277 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: emacs-lisp-mode and find-tag
2014-06-20 20:22 emacs-lisp-mode and find-tag Barry OReilly
@ 2014-06-21 1:08 ` Stefan Monnier
0 siblings, 0 replies; 12+ messages in thread
From: Stefan Monnier @ 2014-06-21 1:08 UTC (permalink / raw)
To: Barry OReilly; +Cc: emacs-devel
>> `find-tag-definition-functions`
>> This should hold functions of one argument (a string)
> As I remarked in the bug report, the tag name alone is not
> sufficient for Semantic, because it considers the code
> surrounding the tag.
Very good point. So either we limit it to "find def of thing-at-point",
or we need to have a "get thing at point" plus "find def of thing".
Splitting the two is tricky because different backends will want to
represent their "thing" differently, so the thing returned by one
backend's "get thing at point" won't be accepted by the "find def of
thing" of other backends.
Yet, the separation would be useful for things like company-mode
which want to let you jump to the definition of a completion candidate
(i.e. a "tag" which is not in the buffer).
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread
* emacs-lisp-mode and find-tag
@ 2014-06-20 12:32 Alfred M. Szmidt
2014-06-20 13:08 ` Eli Zaretskii
2014-06-20 14:30 ` Stefan Monnier
0 siblings, 2 replies; 12+ messages in thread
From: Alfred M. Szmidt @ 2014-06-20 12:32 UTC (permalink / raw)
To: emacs-devel
Is there some specific reason why M-. (find-tag) doesn't work by
default in emacs-lisp files? There seems to be little point in using
etags seeing that emacs already knows where the source is of a given
function.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: emacs-lisp-mode and find-tag
2014-06-20 12:32 Alfred M. Szmidt
@ 2014-06-20 13:08 ` Eli Zaretskii
2014-06-20 15:52 ` Alfred M. Szmidt
2014-06-20 14:30 ` Stefan Monnier
1 sibling, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2014-06-20 13:08 UTC (permalink / raw)
To: ams; +Cc: emacs-devel
> Date: Fri, 20 Jun 2014 08:32:32 -0400
> From: ams@gnu.org (Alfred M. Szmidt)
>
> Is there some specific reason why M-. (find-tag) doesn't work by
> default in emacs-lisp files?
What do you mean "by default"? Do you mean without using the TAGS
table? Because with the TAGS table, it works perfectly for me.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: emacs-lisp-mode and find-tag
2014-06-20 12:32 Alfred M. Szmidt
2014-06-20 13:08 ` Eli Zaretskii
@ 2014-06-20 14:30 ` Stefan Monnier
2014-06-20 15:52 ` Alfred M. Szmidt
1 sibling, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2014-06-20 14:30 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: emacs-devel
> Is there some specific reason why M-. (find-tag) doesn't work by
> default in emacs-lisp files? There seems to be little point in using
> etags seeing that emacs already knows where the source is of a given
> function.
Because currently M-. doesn't mean "jump to definition" but "jump to
definition according to TAGS file".
I think it would be good to provide a generic M-. (and M-*, ..) binding
that several backends (etags, symbol-file, ...) can then use.
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: emacs-lisp-mode and find-tag
2014-06-20 14:30 ` Stefan Monnier
@ 2014-06-20 15:52 ` Alfred M. Szmidt
2014-06-20 16:24 ` Stefan Monnier
2014-06-20 16:52 ` Josh
0 siblings, 2 replies; 12+ messages in thread
From: Alfred M. Szmidt @ 2014-06-20 15:52 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
> Is there some specific reason why M-. (find-tag) doesn't work by
> default in emacs-lisp files? There seems to be little point in
> using etags seeing that emacs already knows where the source is
> of a given function.
Because currently M-. doesn't mean "jump to definition" but "jump
to definition according to TAGS file".
That kinda depends on the mode, no?
I think it would be good to provide a generic M-. (and M-*, ..)
binding that several backends (etags, symbol-file, ...) can then
use.
That would be very nice indeed.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: emacs-lisp-mode and find-tag
2014-06-20 15:52 ` Alfred M. Szmidt
@ 2014-06-20 16:24 ` Stefan Monnier
2014-06-20 16:52 ` Josh
1 sibling, 0 replies; 12+ messages in thread
From: Stefan Monnier @ 2014-06-20 16:24 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: emacs-devel
>> Is there some specific reason why M-. (find-tag) doesn't work by
>> default in emacs-lisp files? There seems to be little point in
>> using etags seeing that emacs already knows where the source is
>> of a given function.
> Because currently M-. doesn't mean "jump to definition" but "jump
> to definition according to TAGS file".
> That kinda depends on the mode, no?
No, that's the problem. Of course, some modes may decide to rebind
M-. but that's rare.
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: emacs-lisp-mode and find-tag
2014-06-20 15:52 ` Alfred M. Szmidt
2014-06-20 16:24 ` Stefan Monnier
@ 2014-06-20 16:52 ` Josh
2014-06-20 17:35 ` Stefan Monnier
1 sibling, 1 reply; 12+ messages in thread
From: Josh @ 2014-06-20 16:52 UTC (permalink / raw)
To: ams; +Cc: Stefan Monnier, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 944 bytes --]
On Fri, Jun 20, 2014 at 8:52 AM, Alfred M. Szmidt <ams@gnu.org> wrote:
>
> I think it would be good to provide a generic M-. (and M-*, ..)
> binding that several backends (etags, symbol-file, ...) can then
> use.
>
> That would be very nice indeed.
>
+1. There was a discussion[0] about this topic last year and
apparent agreement in principle, but the details are yet to be
worked out. At least two implementations exist already, one
being the patch Leo submitted with that bug and the other being
the `elisp-slime-nav' package I mentioned in that thread (and
whose author has also assigned copyright).
If we do define a standard set of source navigation key bindings,
I hope it includes one for jumping to symbols' references. Unlike
M-. for jumping to definitions, jumping to references doesn't seem
to have a standard binding, even though it's often very handy.
[0] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15641
Josh
[-- Attachment #2: Type: text/html, Size: 1656 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: emacs-lisp-mode and find-tag
2014-06-20 16:52 ` Josh
@ 2014-06-20 17:35 ` Stefan Monnier
2014-06-20 18:53 ` Ivan Kanis
0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2014-06-20 17:35 UTC (permalink / raw)
To: Josh; +Cc: ams, emacs-devel
> +1. There was a discussion[0] about this topic last year and
> apparent agreement in principle, but the details are yet to be
> worked out. At least two implementations exist already, one
> being the patch Leo submitted with that bug and the other being
> the `elisp-slime-nav' package I mentioned in that thread (and
> whose author has also assigned copyright).
Both of those provide navigation commands for Elisp, yes.
I'm more interested in introducing generic code, which relies on
a `find-tag-function` hook to do the work of finding the definition.
> If we do define a standard set of source navigation key bindings,
> I hope it includes one for jumping to symbols' references. Unlike
> M-. for jumping to definitions, jumping to references doesn't seem
> to have a standard binding, even though it's often very handy.
Indeed. In general, we need a hooks
`find-tag-definition-functions`
This should hold functions of one argument (a string): it should
return a list of the form (BUFFER-OR-FILE POSITION NEXT) where
POSITION can be either a position in a buffer (integer/marker) or
a pair (LINE . COLUMN) where COLUMN can be nil. NEXT if non-nil could
be a function which will return the same info but for the
next definition. Of course both can return nil.
Then we need generic code which uses this function to provide the
M-. and M-* functionality, plus glue code for etags.el (which should get
us back the exact same functionality we have now). Then we can start
adding more glue code for other backend: find-function, imenu, semantic,
...
And yes, we can add also a find-tag-definition-functions. As well as
hooks to get a quick summary (tho we could maybe just use
eldoc-documentation-function) and another to get the "full" doc.
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: emacs-lisp-mode and find-tag
2014-06-20 17:35 ` Stefan Monnier
@ 2014-06-20 18:53 ` Ivan Kanis
2014-06-20 19:07 ` Josh
0 siblings, 1 reply; 12+ messages in thread
From: Ivan Kanis @ 2014-06-20 18:53 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Josh, ams, emacs-devel
June, 20 at 13:35 Stefan wrote:
> I'm more interested in introducing generic code, which relies on
> a `find-tag-function` hook to do the work of finding the definition.
I have used the following two functions for a while now. The second I
have bound to M-, to pop back like in slime. (The default M-* is awkward
IMO).
I bind the functions in the elisp-mode, help-mode and the debugger-mode.
They are not generic though...
(defun ivan-elisp-find-object ()
"Jump to definition of function or variable near point."
(interactive)
(let ((object (intern (current-word)))
(insert (lambda() (ring-insert ivan-elisp-mark-ring (point-marker)))))
(cond ((functionp object)
(funcall insert)
(find-function object))
((boundp object)
(funcall insert)
(find-variable object))
(t (message "symbol %s not found" (current-word))))))
(defun ivan-elisp-pop-mark ()
"Pop to the previous location before jumping to a definition."
(interactive)
(if (ring-empty-p ivan-elisp-mark-ring)
(message "No previous locations")
(let ((marker (ring-remove ivan-elisp-mark-ring 0)))
(switch-to-buffer (or (marker-buffer marker)
(message "The marked buffer has been deleted")))
(goto-char (marker-position marker))
(set-marker marker nil nil))))
--
I have been at my book, and am now past the craggy paths of study, and
come to the flowery plains of honour and reputation.
-- Ben Jonson
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: emacs-lisp-mode and find-tag
2014-06-20 18:53 ` Ivan Kanis
@ 2014-06-20 19:07 ` Josh
0 siblings, 0 replies; 12+ messages in thread
From: Josh @ 2014-06-20 19:07 UTC (permalink / raw)
To: Ivan Kanis; +Cc: ams, Stefan Monnier, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 368 bytes --]
On Fri, Jun 20, 2014 at 11:53 AM, Ivan Kanis <ivan@kanis.fr> wrote:
>
> I have used the following two functions for a while now. The second I
> have bound to M-, to pop back like in slime. (The default M-* is awkward
> IMO).
>
I agree, and the M-,/M-. pair have the added mnemonic benefit of sharing
the arrow-like < and > keys (at least on standard U.S. keyboards).
[-- Attachment #2: Type: text/html, Size: 717 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-06-21 1:08 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-06-20 20:22 emacs-lisp-mode and find-tag Barry OReilly
2014-06-21 1:08 ` Stefan Monnier
-- strict thread matches above, loose matches on Subject: below --
2014-06-20 12:32 Alfred M. Szmidt
2014-06-20 13:08 ` Eli Zaretskii
2014-06-20 15:52 ` Alfred M. Szmidt
2014-06-20 14:30 ` Stefan Monnier
2014-06-20 15:52 ` Alfred M. Szmidt
2014-06-20 16:24 ` Stefan Monnier
2014-06-20 16:52 ` Josh
2014-06-20 17:35 ` Stefan Monnier
2014-06-20 18:53 ` Ivan Kanis
2014-06-20 19:07 ` Josh
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.