GNU bug report logs -
#78489
30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions
Previous Next
Full log
Message #26 received at 78489 <at> debbugs.gnu.org (full text, mbox):
> From: Troy Brown <brownts <at> troybrown.dev>
> Date: Mon, 26 May 2025 16:13:19 -0400
> Cc: 78489 <at> debbugs.gnu.org
>
> On Thu, May 22, 2025 at 7:31 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > Thanks for the analysis. Out of curiosity: do you happen to know the
> > reasons why Ada tags have these suffixes? It seems to be Ada-only
> > feature, so I wonder what's it about?
>
> The creation of the Ada TAGS support in Emacs predates my involvement,
> so unfortunately, I don't know the reasoning behind it, other than
> what appears in the manual (wanting to differentiate between symbols
> of the same name in different contents). However, that wouldn't be
> unique to Ada.
>
> > I can propose the patch below instead. Could you please see if it
> > solves your problems with Ada tags?
>
> In the testing I've done, this patch works correctly and addresses the
> original problem reported.
Thanks, I've now installed the fix on the master branch.
> > > However, as I explored this a bit further
> > > I discovered another issue that involves completion. After typing
> > > 'Displ' and then `M-x completion-at-point`, the tag including the
> > > suffix is completed (i.e., "Display_Message/p" is inserted into the
> > > buffer, instead of just "Display_Message").
> >
> > That's how completion on Ada tags worked back when we used etags.el
> > instead of Xref, so I consider this not to be a regression. If you
> > think otherwise, please explain why, or show a recipe which behaves
> > differently in Emacs 24 and before.
>
> Really? So the user would complete and then have to delete the last
> two characters of the completion in their buffer to remove the suffix?
No, the user doesn't need to delete the "/p" part, Emacs will find the
tag whether it does or doesn't and in "/p". You can try that with my
patch, it works.
> I'll take your word for it, that it operated that way, as I don't
> think I have access to an Emacs 24 that I could test that with, but
> that sounds broken...what's the point of completion if the inserted
> text needs to be fixed up in the buffer afterwards?
As I said, there's no need to fix the completion. In addition, these
qualifiers are documented in the "etags --help --language=ada" output,
so they are known to users.
> Did you see the previous response I sent? I think our responses may
> have occurred around the same time. I found a place to correct that
> behavior in `etags-tags-completion-table` which is a regex fixup
> similar to the first one.
Thanks, but I don't think we should make such a change, because users
might actually expect to see the "/p" and other qualifiers in the
completion candidates, since that's how Ada tags worked before we
switched to Xref.
IOW, those "/x" qualifiers of the Ada tags are a user-facing feature,
so any changes in it will be noticed by users. I think we should
preserve the original behavior, however weird it looks.
Thanks.
This bug report was last modified 55 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.