emacs-lisp-mode and find-tag

emacs-lisp-mode and find-tag

[Alfred M. Szmidt]

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.

Re: emacs-lisp-mode and find-tag

[Eli Zaretskii]

> 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.

Re: emacs-lisp-mode and find-tag

[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?  

That would be exactly what I mean.

Re: emacs-lisp-mode and find-tag

[Stefan Monnier]

> 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

Re: emacs-lisp-mode and find-tag

[Alfred M. Szmidt]

   > 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.

Re: emacs-lisp-mode and find-tag

[Stefan Monnier]

>> 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

Re: emacs-lisp-mode and find-tag

[Josh]

[-- 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 --]

Re: emacs-lisp-mode and find-tag

[Stefan Monnier]

> +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

Re: emacs-lisp-mode and find-tag

[Ivan Kanis]

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

Re: emacs-lisp-mode and find-tag

[Josh]

[-- 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 --]

Re: emacs-lisp-mode and find-tag

[Barry OReilly]

[-- 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 --]

Re: emacs-lisp-mode and find-tag

[Stefan Monnier]

>> `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