Replacing find-tag with xref

Replacing find-tag with xref

[R. Diez]

Hi all:

I have a large C++ repository and build my own TAGS file.

I have been using find-tag and etags-select-find-tag-at-point for years. I am used to it, and it works fine.

Some time ago I noticed that find-tag was being deprecated, and I tried the suggested replacement, but I got frustrated and gave up.

This deprecation has now become a more serious issue, because etags.el is no longer present in a convenient package repository, like Emacs' 
default one or MELPA.

So I have tried again to replace find-tag and etags-select-find-tag-at-point with xref-find-definitions-other-window and the like, to no avail.

I realised that there have been long discussions about this in the past. This is the kind of issue that makes me long for an Emacs 
alternative. 8-((( But I guess there is nothing viable yet.

Can someone please help me with this matter? I need working replacements for these functions:

1) find-tag
This is what I use manually when I do not quite know what I am looking for.
It should suggest the thing at point.
It should support autocompletion.
It should always (and hopefully exclusively) look in my TAGS file, no matter what my current buffer is.

2) etags-select-find-tag-at-point
This is what I use on existing source code.
If there is just one match, it should not prompt, just jump to the declaration.
If there are many matches, it should display a list to choose from.
It should always (and hopefully exclusively) look in my TAGS file, no matter what my current buffer is.

I tried to make xref-find-definitions always use the TAGS file, but my Lisp skills are not enough. I found this snippet:

https://github.com/emacs-ess/ESS/issues/686#issuecomment-475378908

But it does not work. I does not find anything.

I wonder whether I could turn xref-etags-mode on globally. And whether that would be enough.

Thanks in advance,
   rdiez

Re: Replacing find-tag with xref

[Noam Postavsky]

On Tue, 30 Apr 2019 at 08:43, R. Diez <rdiezmail-emacs@yahoo.de> wrote:

> Some time ago I noticed that find-tag was being deprecated, and I tried the suggested replacement, but I got frustrated and gave up.
>
> This deprecation has now become a more serious issue, because etags.el is no longer present in a convenient package repository, like Emacs'
> default one or MELPA.

Um, isn't it still in master?

https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/progmodes/etags.el

> I wonder whether I could turn xref-etags-mode on globally. And whether that would be enough.

Yeah, that should work, though (add-hook 'emacs-lisp-mode-hook
#'xref-etags-mode) should currently be enough.

Re: Replacing find-tag with xref

[R. Diez]

>> This deprecation has now become a more serious issue, because etags.el is no longer present in a convenient package repository, like Emacs'
>> default one or MELPA.
> 
> Um, isn't it still in master?

Sorry, in the meantime I have realised that it was actually package etags-select, which was removed from MELPA.


I have managed to come up with alternative implementations for find-tag and etags-select-find-tag-at-point . In case it helps anybody, the 
code is at the bottom.

Incidentally, I think I found a small bug: when xref-find-definitions prompts, and you press Enter (provide an empty string to look for), it 
hangs with 100 % CPU usage.



; find-tag has been deprecated in emacs 25.1, and package etags-select has been removed from MELPA,
; so I am switching now to xref-find-definitions.
;   (global-set-key [M-f11] 'etags-select-find-tag-at-point)
;
; Alternatively, we could use jump-to-definition-at-point-only-from-tags-file.
(global-set-key [M-f11] 'jump-to-definition-at-point)


(defun jump-to-definition-at-point () ""
   (interactive)

   (let* ((thing (xref-backend-identifier-at-point 'etags)))

     (unless thing
       (error "No identifier found at point."))

       ; Alternatively, we could use xref-find-definitions-other-window.
       (xref-find-definitions thing)
   )
)

; This routine makes xref-find-definitions use only the TAGS file. Otherwise, in Lisp mode,
; it would not use the TAGS file at all, but another backend that uses dynamic information to find symbols.
; That would also be the case for other modes in any future if new xref backends are added to Emacs.
;
; An alternative to this routine would be to turn the xref-etags-mode on globally.
; But then we may want to use other backends in other scenarios.
;
; Yet another way would be (add-hook 'emacs-lisp-mode-hook #'xref-etags-mode),
; because the lisp mode is the only thing as of Emacs 26 that uses another backend.
; But again, that can change in the future.

(defun jump-to-definition-at-point-only-from-tags-file () ""
   (interactive)

   (let ((xref-backend-functions '(etags--xref-backend)))
     (jump-to-definition-at-point))
)


(defun jump-to-definition () ""
   (interactive)
   (let ((current-prefix-arg '(1))) ; With a prefix argument, xref-find-definitions will always prompt.
     (call-interactively 'xref-find-definitions)
   )
)


(defun jump-to-definition-only-from-tags-file () ""
   (interactive)

   (let ((xref-backend-functions '(etags--xref-backend)))
     (jump-to-definition))
)

Re: Replacing find-tag with xref

[Noam Postavsky]

On Thu, 2 May 2019 at 05:34, R. Diez <rdiezmail-emacs@yahoo.de> wrote:

> Sorry, in the meantime I have realised that it was actually package etags-select, which was removed from MELPA.

Ah, okay, I don't know anything about that.

> Incidentally, I think I found a small bug: when xref-find-definitions prompts, and you press Enter (provide an empty string to look for), it
> hangs with 100 % CPU usage.

Yes, you're right. etags--xref-find-definitions loops infinitely
looking for "" in the TAGS file (which it always finds), and then
checking if it has found a definition for "" (which it never has, of
course).

Re: Replacing find-tag with xref

[Dmitry Gutov]

On 02.05.2019 14:15, Noam Postavsky wrote:
> Yes, you're right. etags--xref-find-definitions loops infinitely
> looking for "" in the TAGS file (which it always finds), and then
> checking if it has found a definition for "" (which it never has, of
> course).

Should be fixed now, thanks for the nudge.