Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions

From: Troy Brown <[email-masked]>
Date: Tue, 27 May 2025 07:43:33 -0400

On Tue, May 27, 2025 at 6:57 AM Eli Zaretskii <[email-masked]> wrote:
>
> > 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.

Thank you.

> > > > 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 did try it with the patch, but I'm still seeing an issue (with
completion).  That's why I don't think the patch fixes everything,
just navigation.

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

I would be fine if the suffix appeared in the completion candidates
list, just not inserted in the buffer once a candidate is selected.

I think I'm not explaining the situation clearly.  The completion
issue isn't whether it finds a candidate, the issue is what is
inserted into the buffer once the candidate has been selected...or
when there is only a single candidate and the completion is
automatically inserted without displaying the "*Completions*" buffer.
I'd be fine if the completion buffer displayed the suffix, as long as
it wasn't inserted into the buffer.

I'll try with an example, as I think that demonstrates the problem.
This assumes the same setup as was documented in the original email
bug report, with the following in the buffer (notice the "Disp"
partial on line 9).  This also includes your previously suggested fix,
but without my suggested additional fix.

--8<---------------cut here---------------start------------->8---
with Ada.Text_IO; use Ada.Text_IO;

procedure Hello_World is
   procedure Display_Message is
   begin
      Put_Line ("Hello, World!");
   end Display_Message;
begin  -- Hello_World
   Disp
end Hello_World;
--8<---------------cut here---------------end--------------->8---

Assuming point is after "Disp" on line 9, I perform `M-x
completion-at-point`.  In this example, there is only a single
completion for this prefix in the TAGS file, thus it is automatically
completed in the file buffer without displaying the *Completions*
buffer.  After the completion, the buffer contents look like the
following:

--8<---------------cut here---------------start------------->8---
with Ada.Text_IO; use Ada.Text_IO;

procedure Hello_World is
   procedure Display_Message is
   begin
      Put_Line ("Hello, World!");
   end Display_Message;
begin  -- Hello_World
   Display_Message/p
end Hello_World;
--8<---------------cut here---------------end--------------->8---

As you can see above the "/p" suffix is added into the buffer as part
of the completion.  This is not valid syntax.  I must therefore delete
"/p" before adding the final semicolon.  This is what my suggested fix
was attempting to address...preventing the insertion of the invalid
suffix into the buffer.