GNU bug report logs - #78489
30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions

Previous Next

To reply to this bug, email your comments to 78489 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Troy Brown <brownts <at> troybrown.dev>
To: "simon254--- via Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
Subject: 30.1.50;
 Using etags, Ada and xref-find-definitions doesn't find definitions
Date: Sun, 18 May 2025 21:37:19 -0400

For this issue, you can just load the Ada source into Fundamental
mode.  The problem doesn't appear to be with the major mode, but
instead with the etags backend for xref not fully supporting the Ada
tags generated by etags.  The following source file can be used to
reproduce the problem (named hello_world.adb):

--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;
end Hello_World;
--8<---------------cut here---------------end--------------->8---

1. Generate TAGS: etags *.adb
2. emacs -Q hello_world.adb
3. Place point over Display_Message on line 9
4. M-x xref-find-definitions
5. Select TAGS file previously generated
6. Message buffer contains "No definitions found for: Display_Message"

Digging into this, it appears the reason the definition is not found
is because of the `etags-xref-find-definitions-tag-order`, or more
specifically, that `tag-exact-match-p` contained in that list does not
account for the suffix appended by etags for Ada tags.  According to
the the Emacs manual [(info "(emacs) Tag Syntax")], Ada tags will
contain a "/b", "/f", "/k", "/p", "/s" or "/t" suffix to distinguish
the type of tag.  This can be observed by looking at the contents of
the generated TAGS file.  When invoking `xref-find-definitions`, the
symbol at point (i.e., "Display_Message" in this example) will not
exactly match the tag found in the TAGS file (i.e.,
"Display_Message/p"), thus the observed "No definitions found"
message.

I assume this is just an oversight that `xref-find-definitions` does
not work out of the box with Ada tags.  The older `M-x find-tag` will
work as expected, as well as other functions which don't expect an
exact match (i.e., `M-x xref-find-apropos`).  However, It's surprising
that `xref-find-definitions` does not work out of the box with the
output that etags generates.

I've worked around this issue by creating `ada-tag-exact-match-p`
which mimics `tag-exact-match-p` but handles the Ada suffixes
generated by etags, and then adding it to
`etags-xref-find-definitions-tag-order`.

--8<---------------cut here---------------start------------->8---
(defun ada-tag-exact-match-p (tag)
  (let* ((ada-tag-suffix (rx "/" (or "b" "f" "k" "p" "s" "t")))
(ada-tag (concat (regexp-quote tag) ada-tag-suffix)))
    (or (and (looking-at (concat ada-tag-suffix (rx ?\001)))
     (eq (char-after (- (point) (length tag) 1)) ?\177))
(looking-at (concat (rx (* (not (or ?\177 ?\n))) ?\177) ada-tag (rx ?\001))))))

(with-eval-after-load 'etags
  (add-to-list 'etags-xref-find-definitions-tag-order
'ada-tag-exact-match-p 'append))
--8<---------------cut here---------------end--------------->8---

It's unclear to me how special handling like this should be handled in
the etags xref backend.

Message #8 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Troy Brown <brownts <at> troybrown.dev>
Cc: 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50;
 Using etags, Ada and xref-find-definitions doesn't find definitions
Date: Thu, 22 May 2025 14:31:04 +0300

> Date: Sun, 18 May 2025 21:37:19 -0400
> From:  Troy Brown via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> For this issue, you can just load the Ada source into Fundamental
> mode.  The problem doesn't appear to be with the major mode, but
> instead with the etags backend for xref not fully supporting the Ada
> tags generated by etags.  The following source file can be used to
> reproduce the problem (named hello_world.adb):
> 
> --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;
> end Hello_World;
> --8<---------------cut here---------------end--------------->8---
> 
> 1. Generate TAGS: etags *.adb
> 2. emacs -Q hello_world.adb
> 3. Place point over Display_Message on line 9
> 4. M-x xref-find-definitions
> 5. Select TAGS file previously generated
> 6. Message buffer contains "No definitions found for: Display_Message"
> 
> Digging into this, it appears the reason the definition is not found
> is because of the `etags-xref-find-definitions-tag-order`, or more
> specifically, that `tag-exact-match-p` contained in that list does not
> account for the suffix appended by etags for Ada tags.  According to
> the the Emacs manual [(info "(emacs) Tag Syntax")], Ada tags will
> contain a "/b", "/f", "/k", "/p", "/s" or "/t" suffix to distinguish
> the type of tag.  This can be observed by looking at the contents of
> the generated TAGS file.  When invoking `xref-find-definitions`, the
> symbol at point (i.e., "Display_Message" in this example) will not
> exactly match the tag found in the TAGS file (i.e.,
> "Display_Message/p"), thus the observed "No definitions found"
> message.

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?

> I assume this is just an oversight that `xref-find-definitions` does
> not work out of the box with Ada tags.

Yes.

> The older `M-x find-tag` will work as expected, as well as other
> functions which don't expect an exact match (i.e., `M-x
> xref-find-apropos`).  However, It's surprising that
> `xref-find-definitions` does not work out of the box with the output
> that etags generates.

Xref intentionally switched to exact matches, so as to avoid the extra
step for the user to select one of the possible inexact matches.  But
doing that with Ada needs special handling, due to this idiosyncrasy
of Ada tags.

> It's unclear to me how special handling like this should be handled in
> the etags xref backend.

I can propose the patch below instead.  Could you please see if it
solves your problems with Ada tags?

Message #11 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Troy Brown <brownts <at> troybrown.dev>
Cc: 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50;
 Using etags, Ada and xref-find-definitions doesn't find definitions
Date: Thu, 22 May 2025 14:31:22 +0300

> Date: Sun, 18 May 2025 21:37:19 -0400
> From:  Troy Brown via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> For this issue, you can just load the Ada source into Fundamental
> mode.  The problem doesn't appear to be with the major mode, but
> instead with the etags backend for xref not fully supporting the Ada
> tags generated by etags.  The following source file can be used to
> reproduce the problem (named hello_world.adb):
> 
> --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;
> end Hello_World;
> --8<---------------cut here---------------end--------------->8---
> 
> 1. Generate TAGS: etags *.adb
> 2. emacs -Q hello_world.adb
> 3. Place point over Display_Message on line 9
> 4. M-x xref-find-definitions
> 5. Select TAGS file previously generated
> 6. Message buffer contains "No definitions found for: Display_Message"
> 
> Digging into this, it appears the reason the definition is not found
> is because of the `etags-xref-find-definitions-tag-order`, or more
> specifically, that `tag-exact-match-p` contained in that list does not
> account for the suffix appended by etags for Ada tags.  According to
> the the Emacs manual [(info "(emacs) Tag Syntax")], Ada tags will
> contain a "/b", "/f", "/k", "/p", "/s" or "/t" suffix to distinguish
> the type of tag.  This can be observed by looking at the contents of
> the generated TAGS file.  When invoking `xref-find-definitions`, the
> symbol at point (i.e., "Display_Message" in this example) will not
> exactly match the tag found in the TAGS file (i.e.,
> "Display_Message/p"), thus the observed "No definitions found"
> message.

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?

> I assume this is just an oversight that `xref-find-definitions` does
> not work out of the box with Ada tags.

Yes.

> The older `M-x find-tag` will work as expected, as well as other
> functions which don't expect an exact match (i.e., `M-x
> xref-find-apropos`).  However, It's surprising that
> `xref-find-definitions` does not work out of the box with the output
> that etags generates.

Xref intentionally switched to exact matches, so as to avoid the extra
step for the user to select one of the possible inexact matches.  But
doing that with Ada needs special handling, due to this idiosyncrasy
of Ada tags.

> It's unclear to me how special handling like this should be handled in
> the etags xref backend.

I can propose the patch below instead.  Could you please see if it
solves your problems with Ada tags?

diff --git a/lisp/progmodes/etags.el b/lisp/progmodes/etags.el
index 42057a3..f14d915 100644
--- a/lisp/progmodes/etags.el
+++ b/lisp/progmodes/etags.el
@@ -1649,7 +1649,10 @@ tag-exact-match-p
   (or (and (eq (char-after (point)) ?\001)
 	   (eq (char-after (- (point) (length tag) 1)) ?\177))
       ;; We are not on the explicit tag name, but perhaps it follows.
-      (looking-at (concat "[^\177\n]*\177" (regexp-quote tag) "\001"))))
+      (looking-at (concat "[^\177\n]*\177"
+                          (regexp-quote tag)
+                          ;; The optional "/x" part is for Ada tags.
+                          "\\(/[fpsbtk]\\)?\001"))))
 
 ;; t if point is at a tag line that has an implicit name.
 ;; point should be just after a string that matches TAG.

Message #14 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Troy Brown <brownts <at> troybrown.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Mon, 26 May 2025 16:13:19 -0400

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

Message #17 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Troy Brown <brownts <at> troybrown.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Mon, 26 May 2025 22:28:22 -0400

On Mon, May 26, 2025 at 4:13 PM Troy Brown <brownts <at> troybrown.dev> wrote:
>
> In the testing I've done, this patch works correctly and addresses the
> original problem reported.  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").

I found a spot in `etags-tags-completion-table` that needed
adjustment.  After this fix, the completion works as expected too.

diff --git a/lisp/progmodes/etags.el b/lisp/progmodes/etags.el
index 352356ddbc5..41b61dc0763 100644
--- a/lisp/progmodes/etags.el
+++ b/lisp/progmodes/etags.el
@@ -1288,7 +1288,7 @@ etags-tags-completion-table
       ;; This regexp matches an explicit tag name or the place where
       ;; it would start.
       (while (re-search-forward
-              "[\f\t\n\r()=,; ]?\177\\(?:\\([^\n\001]+\\)\001\\)?"
+              "[\f\t\n\r()=,;
]?\177\\(?:\\([^\n\001]+?\\)\\(/[fpsbtk]\\)?\001\\)?"
              nil t)
        (push   (prog1 (if (match-beginning 1)
                           ;; There is an explicit tag name.
@@ -1645,7 +1645,10 @@ tag-exact-match-p
   (or (and (eq (char-after (point)) ?\001)
           (eq (char-after (- (point) (length tag) 1)) ?\177))
       ;; We are not on the explicit tag name, but perhaps it follows.
-      (looking-at (concat "[^\177\n]*\177" (regexp-quote tag) "\001"))))
+      (looking-at (concat "[^\177\n]*\177"
+                          (regexp-quote tag)
+                          ;; The optional "/x" part is for Ada tags.
+                          "\\(/[fpsbtk]\\)?\001"))))

 ;; t if point is at a tag line that has an implicit name.
 ;; point should be just after a string that matches TAG.

Message #20 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Troy Brown <brownts <at> troybrown.dev>
Cc: 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Tue, 27 May 2025 05:33:25 +0300

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

Thanks.

Message #23 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Troy Brown <brownts <at> troybrown.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Mon, 26 May 2025 23:15:57 -0400

On Mon, May 26, 2025 at 10:33 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > In the testing I've done, this patch works correctly and addresses the
> > original problem reported.  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?
 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?

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.

Message #26 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Troy Brown <brownts <at> troybrown.dev>
Cc: 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Tue, 27 May 2025 13:56:59 +0300

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

Message #29 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Troy Brown <brownts <at> troybrown.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Tue, 27 May 2025 07:43:33 -0400

On Tue, May 27, 2025 at 6:57 AM Eli Zaretskii <eliz <at> gnu.org> 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.

Message #32 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Troy Brown <brownts <at> troybrown.dev>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Tue, 27 May 2025 15:21:52 +0300

> From: Troy Brown <brownts <at> troybrown.dev>
> Date: Tue, 27 May 2025 07:43:33 -0400
> Cc: 78489 <at> debbugs.gnu.org
> 
> On Tue, May 27, 2025 at 6:57 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > 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.

It fixes Xref and M-. command, with or without TAB-completion of
candidates.  That was the regression you reported in your original
report.

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

"M-x completion-at-point" is a separate command, so this is basically
a separate issue, unrelated to our switch to Xref.  Trying this
command in Emacs 24.4, I see that it inserts "Display_Message/p" in
that version as well.  While I agree with you that it isn't
user-friendly to insert the "/p" part, I'm not sure the fix should be
in etags-tags-completion-table, because that function is called (via
tags-completion-table-function) in more than just this scenario, and
we could break some of those other scenarios.

Maybe Ada source files should have their own specialized value for
completion-at-point-functions?

Stefan, WDYT?

Message #35 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Troy Brown <brownts <at> troybrown.dev>, 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Tue, 27 May 2025 10:00:29 -0400

>> 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.
>
> "M-x completion-at-point" is a separate command, so this is basically
> a separate issue, unrelated to our switch to Xref.  Trying this
> command in Emacs 24.4, I see that it inserts "Display_Message/p" in
> that version as well.  While I agree with you that it isn't
> user-friendly to insert the "/p" part, I'm not sure the fix should be
> in etags-tags-completion-table, because that function is called (via
> tags-completion-table-function) in more than just this scenario, and
> we could break some of those other scenarios.
>
> Maybe Ada source files should have their own specialized value for
> completion-at-point-functions?
>
> Stefan, WDYT?

I haven't had time to look closely, but IIUC those `/p` aren't
reallypart of the completed names but only some meta-info about their
nature, so it sounds like a job for `:annotation-function` (in
`completion-at-point-function`) or `annotation-function` (in the
completion table's metadata).


        Sefan

Message #38 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: brownts <at> troybrown.dev, 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Tue, 27 May 2025 18:29:46 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Troy Brown <brownts <at> troybrown.dev>,  78489 <at> debbugs.gnu.org
> Date: Tue, 27 May 2025 10:00:29 -0400
> 
> I haven't had time to look closely, but IIUC those `/p` aren't
> reallypart of the completed names but only some meta-info about their
> nature, so it sounds like a job for `:annotation-function` (in
> `completion-at-point-function`) or `annotation-function` (in the
> completion table's metadata).

I'm not sure I follow: if you say that annotation-function should add
those "/p" qualifiers, then that's not really possible, since they are
appended by etags and are present in the TAGS file.  Ada tags always
worked like that, for some reason I cannot understand, but we cannot
easily change this now.

Message #41 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: brownts <at> troybrown.dev, 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Tue, 27 May 2025 12:13:04 -0400

>> I haven't had time to look closely, but IIUC those `/p` aren't
>> reallypart of the completed names but only some meta-info about their
>> nature, so it sounds like a job for `:annotation-function` (in
>> `completion-at-point-function`) or `annotation-function` (in the
>> completion table's metadata).
>
> I'm not sure I follow: if you say that annotation-function should add
> those "/p" qualifiers,

That's what I meant, yes.

> then that's not really possible, since they are appended by etags and
> are present in the TAGS file.

Yes, I saw that `etags.el` has special support for that.
Is that documented somewhere (and used/usable by other languages)?

> Ada tags always worked like that, for some reason I cannot understand,
> but we cannot easily change this now.

But we can remove those `/p` thingies from the completion text itself
and add them back (via annotation-function) when listing
the completions, no?


        Stefan

Message #44 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: brownts <at> troybrown.dev, 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Tue, 27 May 2025 12:17:12 -0400

>> I haven't had time to look closely, but IIUC those `/p` aren't
>> reallypart of the completed names but only some meta-info about their
>> nature, so it sounds like a job for `:annotation-function` (in
>> `completion-at-point-function`) or `annotation-function` (in the
>> completion table's metadata).
>
> I'm not sure I follow: if you say that annotation-function should add
> those "/p" qualifiers, then that's not really possible, since they are
> appended by etags and are present in the TAGS file.  Ada tags always
> worked like that, for some reason I cannot understand, but we cannot
> easily change this now.

BTW, a less-ideal solution would be to use an `:exit-function` that
removes the `/p`.  This is a lot more hackish because exit-functions are
kind of optional (different UIs run them in different circumstances or
not at all), plus there's the risk of removing a `/p` that was not
supposed to be removed.


        Stefan

Message #47 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: brownts <at> troybrown.dev, 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Tue, 27 May 2025 21:17:05 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: brownts <at> troybrown.dev,  78489 <at> debbugs.gnu.org
> Date: Tue, 27 May 2025 12:13:04 -0400
> 
> >> I haven't had time to look closely, but IIUC those `/p` aren't
> >> reallypart of the completed names but only some meta-info about their
> >> nature, so it sounds like a job for `:annotation-function` (in
> >> `completion-at-point-function`) or `annotation-function` (in the
> >> completion table's metadata).
> >
> > I'm not sure I follow: if you say that annotation-function should add
> > those "/p" qualifiers,
> 
> That's what I meant, yes.
> 
> > then that's not really possible, since they are appended by etags and
> > are present in the TAGS file.
> 
> Yes, I saw that `etags.el` has special support for that.
> Is that documented somewhere (and used/usable by other languages)?

It's documented in "etags --help --language=ada".  And no, I found no
other languages whose tags have such qualifiers.

> > Ada tags always worked like that, for some reason I cannot understand,
> > but we cannot easily change this now.
> 
> But we can remove those `/p` thingies from the completion text itself
> and add them back (via annotation-function) when listing
> the completions, no?

We could, I guess, so patches welcome.

Message #50 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Troy Brown <brownts <at> troybrown.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Tue, 27 May 2025 17:57:21 -0400

On Tue, May 27, 2025 at 8:22 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> Thanks, I've now installed the fix on the master branch.

Is it possible that this can be applied to the Emacs 30 branch too?

> > 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.
>
> It fixes Xref and M-. command, with or without TAB-completion of
> candidates.  That was the regression you reported in your original
> report.

Yes, you are correct, I expanded the scope when I was testing and
noticed that `completion-at-point` was also not working.  I apologize
if my wording didn't make that clear.

> "M-x completion-at-point" is a separate command, so this is basically
> a separate issue, unrelated to our switch to Xref.  Trying this
> command in Emacs 24.4, I see that it inserts "Display_Message/p" in
> that version as well.  While I agree with you that it isn't
> user-friendly to insert the "/p" part, I'm not sure the fix should be
> in etags-tags-completion-table, because that function is called (via
> tags-completion-table-function) in more than just this scenario, and
> we could break some of those other scenarios.
>
> Maybe Ada source files should have their own specialized value for
> completion-at-point-functions?

I think that might be a good idea, at least as a starting point.  I
like the idea of using a mode-specific completion-at-point function so
the mode can adjust this output accordingly, such as with an
annotation function that Stefan mentioned or even other appropriate
attributes (e.g., company-kind), etc.  I appreciate the advice and
ideas.  I think I can take the completion-at-point issue from here.
I'll file a new report if I have anything further along that avenue.


Thanks,

Troy.

Message #53 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: brownts <at> troybrown.dev, 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Sat, 31 May 2025 14:46:42 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: brownts <at> troybrown.dev,  78489 <at> debbugs.gnu.org
> Date: Tue, 27 May 2025 12:17:12 -0400
> 
> >> I haven't had time to look closely, but IIUC those `/p` aren't
> >> reallypart of the completed names but only some meta-info about their
> >> nature, so it sounds like a job for `:annotation-function` (in
> >> `completion-at-point-function`) or `annotation-function` (in the
> >> completion table's metadata).
> >
> > I'm not sure I follow: if you say that annotation-function should add
> > those "/p" qualifiers, then that's not really possible, since they are
> > appended by etags and are present in the TAGS file.  Ada tags always
> > worked like that, for some reason I cannot understand, but we cannot
> > easily change this now.
> 
> BTW, a less-ideal solution would be to use an `:exit-function` that
> removes the `/p`.  This is a lot more hackish because exit-functions are
> kind of optional (different UIs run them in different circumstances or
> not at all), plus there's the risk of removing a `/p` that was not
> supposed to be removed.

My problem is how to do this in a way that only affects "M-x
completion-at-point", but doesn't affect completion of tags in M-. or
other scenarios.  Can you suggest how to use the above so as to not
affret anything except completion-at-point?

Message #56 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Troy Brown <brownts <at> troybrown.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Sat, 31 May 2025 08:54:25 -0400

On Sat, May 31, 2025 at 7:46 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> > Cc: brownts <at> troybrown.dev,  78489 <at> debbugs.gnu.org
> > Date: Tue, 27 May 2025 12:17:12 -0400
> >
> > >> I haven't had time to look closely, but IIUC those `/p` aren't
> > >> reallypart of the completed names but only some meta-info about their
> > >> nature, so it sounds like a job for `:annotation-function` (in
> > >> `completion-at-point-function`) or `annotation-function` (in the
> > >> completion table's metadata).
> > >
> > > I'm not sure I follow: if you say that annotation-function should add
> > > those "/p" qualifiers, then that's not really possible, since they are
> > > appended by etags and are present in the TAGS file.  Ada tags always
> > > worked like that, for some reason I cannot understand, but we cannot
> > > easily change this now.
> >
> > BTW, a less-ideal solution would be to use an `:exit-function` that
> > removes the `/p`.  This is a lot more hackish because exit-functions are
> > kind of optional (different UIs run them in different circumstances or
> > not at all), plus there's the risk of removing a `/p` that was not
> > supposed to be removed.
>
> My problem is how to do this in a way that only affects "M-x
> completion-at-point", but doesn't affect completion of tags in M-. or
> other scenarios.  Can you suggest how to use the above so as to not
> affret anything except completion-at-point?

For a mode-specific solution, I'm currently using the following.  It
modifies the result of the completion table to remove the suffix, but
stores the suffix as a text property on the candidate.  Then the text
property is retrieved from within the annotation function to generate
the appropriate suffix.  In this example, I chose to use a more
descriptive suffix rather than reapplying the original one.  I'm also
using the text property to drive additional "company-kind" information
too.  This solution seems to be working well for me.

--8<---------------cut here---------------start------------->8---
(defconst ada-ts-tags--tag-regexp
  (rx (group (+ anychar))
      "/"
      (group (or "b" "f" "k" "p" "s" "t"))
      eos)
  "Regular expression matching Ada tag, including type suffix.")

(defun ada-ts-tags--adjust-completion-table (table)
  "Adjust completion TABLE to remove type suffixes from Ada tags."
  (lambda (string pred action)
    (let ((res (complete-with-action action table string pred)))
      (cond
       ;; like 'try-completion`
       ((stringp res)
        (if-let* (((string-match ada-ts-tags--tag-regexp res))
                  (mod-cand (match-string 1 res)))
            (or
             (string-equal-ignore-case mod-cand string) ; Exact match
             mod-cand) ; Longest substring, single match
          res)) ; Longest substring, multiple matches
       ;; like `all-completions`
       ((eq action t)
        (seq-map
         (lambda (cand)
           (if (string-match ada-ts-tags--tag-regexp cand)
               (let ((mod-cand (match-string 1 cand))
                     (type (match-string 2 cand)))
                 (put-text-property 0 1 'etags-ada-type type mod-cand)
                 mod-cand)
             cand))
         res))
       ;; Everything else
       (t res)))))

(defun ada-ts-tags-completion-at-point-function ()
  "Ada completion at point function for tags."
  (pcase (tags-completion-at-point-function)
    (`(,beg ,end ,table . ,plist)
     `(,beg ,end ,(ada-ts-tags--adjust-completion-table table)
            :annotation-function
            ,(lambda (cand)
               (when-let* ((type (get-text-property 0 'etags-ada-type cand)))
                 (pcase type
                   ("b" " Package Body")
                   ("f" " Function")
                   ("k" " Task")
                   ("p" " Procedure")
                   ("s" " Package Spec")
                   ("t" " Type"))))
            :company-kind
            ,(lambda (cand)
               (when-let* ((type (get-text-property 0 'etags-ada-type cand)))
                 (pcase type
                   ("b" 'module)
                   ("f" 'function)
                   ("k" 'interface)
                   ("p" 'function)
                   ("s" 'module)
                   ("t" 'interface))))
            ,@plist))))

(setq-local completion-at-point-functions
'(ada-ts-tags-completion-at-point-function))
--8<---------------cut here---------------end--------------->8---

Message #59 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: brownts <at> troybrown.dev, 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Sat, 31 May 2025 14:26:57 -0400

[Message part 1 (text/plain, inline)]

> My problem is how to do this in a way that only affects "M-x
> completion-at-point", but doesn't affect completion of tags in M-. or
> other scenarios.  Can you suggest how to use the above so as to not
> affret anything except completion-at-point?

To the extend that `M-.` could decide to use `completion-at-point`, I'm
not sure this is possible in general, but maybe a patch like the one below
can work well enough in practice?


        Stefan

[etags.patch (text/x-diff, inline)]

diff --git a/lisp/progmodes/etags.el b/lisp/progmodes/etags.el
index f14d91504af..2dd76341c64 100644
--- a/lisp/progmodes/etags.el
+++ b/lisp/progmodes/etags.el
@@ -59,7 +59,7 @@ tags-case-fold-search
 		 (const :tag "Case-insensitive" t)
 		 (other :tag "Use default" default))
   :version "21.1"
-  :safe 'symbolp)
+  :safe #'symbolp)
 
 ;;;###autoload
 ;; Use `visit-tags-table-buffer' to cycle through tags tables in this list.
@@ -808,6 +808,9 @@ tags-completion-table
           (quit (message "Tags completion table construction aborted.")
                 (setq tags-completion-table nil))))))
 
+(defvar tag--suffix-regexp "/[fpsbtk]"
+  "Suffix part of some tags.  Used in Ada tags to classify them by \"type\".")
+
 ;;;###autoload
 (defun tags-lazy-completion-table ()
   (let ((buf (current-buffer)))
@@ -842,7 +845,24 @@ tags-completion-at-point-function
           (when (search-backward pattern nil t)
             (setq beg (point))
             (forward-char (length pattern))
-            (list beg (point) (tags-lazy-completion-table) :exclusive 'no)))))))
+            (list beg (point) (tags-lazy-completion-table)
+                  :exclusive 'no
+                  :exit-function
+                  (lambda (str status)
+                    ;; Strip away any tag suffix, since they're not really
+                    ;; part of their names.
+                    ;; FIXME: Maybe it would be better to strip them from
+                    ;; the completion table entries (and re-add them for
+                    ;; display via an `annotation-function').
+                    (when (and (eq status 'finished)
+                               (string-match (concat tag--suffix-regexp "\\'")
+                                             str))
+                      (let ((suffix (match-string 0 str)))
+                        (when (equal suffix
+                                     (buffer-substring
+                                      (- (point) (length suffix)) (point)))
+                          (delete-region (- (point) (length suffix))
+                                         (point)))))))))))))
 
 (defun find-tag-tag (string)
   "Read a tag name, with defaulting and completion."
@@ -1635,6 +1655,7 @@ tag-file-name-match-p
        (save-excursion (backward-char (1+ (length tag)))
 		       (looking-at "/"))))
 
+;; FIXME: What does the comment below refer to?
 ;; this / to detect we are after a directory separator is ok for unix,
 ;; is there a variable that contains the regexp for directory separator
 ;; on whatever operating system ?
@@ -1651,8 +1672,7 @@ tag-exact-match-p
       ;; We are not on the explicit tag name, but perhaps it follows.
       (looking-at (concat "[^\177\n]*\177"
                           (regexp-quote tag)
-                          ;; The optional "/x" part is for Ada tags.
-                          "\\(/[fpsbtk]\\)?\001"))))
+                          "\\(" tag--suffix-regexp "\\)?\001"))))
 
 ;; t if point is at a tag line that has an implicit name.
 ;; point should be just after a string that matches TAG.

Message #62 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: brownts <at> troybrown.dev, 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Sun, 01 Jun 2025 08:15:11 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: brownts <at> troybrown.dev,  78489 <at> debbugs.gnu.org
> Date: Sat, 31 May 2025 14:26:57 -0400
> 
> > My problem is how to do this in a way that only affects "M-x
> > completion-at-point", but doesn't affect completion of tags in M-. or
> > other scenarios.  Can you suggest how to use the above so as to not
> > affret anything except completion-at-point?
> 
> To the extend that `M-.` could decide to use `completion-at-point`, I'm
> not sure this is possible in general, but maybe a patch like the one below
> can work well enough in practice?

Seems to do the job, thanks.  Maybe Troy could try this for a while
and report back.

Btw, maybe I don't understand what 'finished' means in the documentation
of :exit-function, but it's somewhat confusing:

                    ‘finished’ if text is now complete, ‘sole’ if the
          text cannot be further completed but completion is not
          finished, or ‘exact’ if the text is a valid completion but may
          be further completed.

This is confusing because the terms "text is complete", "cannot be
further completed", "may be further completed", and "valid completion"
are not explained, and the words themselves don't do that clearly
enough (except, perhaps, in the "valid completion" case).

What we want here is to "edit" the completion before it is passed to
the function that inserts it into the buffer.  The description of
:exit-function doesn't make it clear at what point in the completion
process will the function be called -- is that only when the user
"exits the completion", i.e. under the same conditions that
minibuffer-exit-hook is called (when completing in the minibuffer)?

Message #65 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: brownts <at> troybrown.dev, 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Sun, 01 Jun 2025 18:19:31 -0400

> Seems to do the job, thanks.  Maybe Troy could try this for a while
> and report back.

Yes, I'd like to hear confirmation that it fixes the concrete case that
Try was interested in.

> Btw, maybe I don't understand what 'finished' means in the documentation
> of :exit-function, but it's somewhat confusing:
>
>                     ‘finished’ if text is now complete, ‘sole’ if the
>           text cannot be further completed but completion is not
>           finished, or ‘exact’ if the text is a valid completion but may
>           be further completed.

Yes, I'm not sure how to write that (or even if those choices are
relevant).

IIRC `sole` is used for example when completing `/h` to `/home/` where
we expect that further completion will take place because we're
expecting an actual file.  `exact` is similar but when completing `M-x
dif` to `M-x diff`, where maybe this is the final completion but maybe
the user will continue to, say, `M-x diff-refine-hunk`.

In contrast `finished` is when the recently inserted completion seems to
be really "final".
In selection UIs, `M-x diff` would also be `finished`, since the user
presumably chose explicitly that entry instead of `diff-refine-hunk`.

> What we want here is to "edit" the completion before it is passed to
> the function that inserts it into the buffer.  The description of
> :exit-function doesn't make it clear at what point in the completion
> process will the function be called -- is that only when the user
> "exits the completion", i.e. under the same conditions that
> minibuffer-exit-hook is called (when completing in the minibuffer)?

For `finished` yes: the expectation is that user "exits" the completion.
This can be more or less difficult to formalize in the UI depending on
the UI.  E.g. for `completion-at-point` there is often no clear user
action that marks the "end" of a completion "session".

For `exact` and `sole`, on the other hand, the expectation is that the
completion session may not be over yet.


        Stefan

Message #68 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Troy Brown <brownts <at> troybrown.dev>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Mon, 2 Jun 2025 01:40:53 +0300

On 27/05/2025 14:43, Troy Brown via Bug reports for GNU Emacs, the Swiss 
army knife of text editors wrote:
> 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.

This sounds very similar to the "kind" field in the extended Vi tags 
format, as described here: 
https://github.com/universal-ctags/ctags/blob/master/docs/man/tags.5.rst

(But also see 'man tags'.)

Which suggests that etags could grow such a field as well - if we're not 
migrating to the ctags format yet.

Message #71 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: brownts <at> troybrown.dev, 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Mon, 02 Jun 2025 09:30:17 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: brownts <at> troybrown.dev,  78489 <at> debbugs.gnu.org
> Date: Sun, 01 Jun 2025 18:19:31 -0400
> 
> > Btw, maybe I don't understand what 'finished' means in the documentation
> > of :exit-function, but it's somewhat confusing:
> >
> >                     ‘finished’ if text is now complete, ‘sole’ if the
> >           text cannot be further completed but completion is not
> >           finished, or ‘exact’ if the text is a valid completion but may
> >           be further completed.
> 
> Yes, I'm not sure how to write that (or even if those choices are
> relevant).
> 
> IIRC `sole` is used for example when completing `/h` to `/home/` where
> we expect that further completion will take place because we're
> expecting an actual file.  `exact` is similar but when completing `M-x
> dif` to `M-x diff`, where maybe this is the final completion but maybe
> the user will continue to, say, `M-x diff-refine-hunk`.
> 
> In contrast `finished` is when the recently inserted completion seems to
> be really "final".
> In selection UIs, `M-x diff` would also be `finished`, since the user
> presumably chose explicitly that entry instead of `diff-refine-hunk`.

So 'finished' is when TAB will show "Sole completion"?

As for the other two, how does the completion distinguish between the
two cases?  Under the default completion, TAB shows "Complete, but no
unique" in both cases, and in both cases we expect additional input
from the user.  How is the distinction done?

Message #74 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: brownts <at> troybrown.dev, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Sat, 07 Jun 2025 12:27:30 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: brownts <at> troybrown.dev,  78489 <at> debbugs.gnu.org
> Date: Sun, 01 Jun 2025 18:19:31 -0400
> 
> > Seems to do the job, thanks.  Maybe Troy could try this for a while
> > and report back.
> 
> Yes, I'd like to hear confirmation that it fixes the concrete case that
> Troy was interested in.

Troy, please try the patch and tell us if it fixes the problem.

Message #77 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Troy Brown <brownts <at> troybrown.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Sun, 22 Jun 2025 18:35:02 -0400

On Sat, Jun 7, 2025 at 5:27 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> > Cc: brownts <at> troybrown.dev,  78489 <at> debbugs.gnu.org
> > Date: Sun, 01 Jun 2025 18:19:31 -0400
> >
> > > Seems to do the job, thanks.  Maybe Troy could try this for a while
> > > and report back.
> >
> > Yes, I'd like to hear confirmation that it fixes the concrete case that
> > Troy was interested in.
>
> Troy, please try the patch and tell us if it fixes the problem.

While I think using an exit-function technically solves the problem of
preventing the suffix from being added into the buffer, I don't think
it is the ideal solution and is likely to lead to confusion.
Furthermore, it doesn't address friction elsewhere.  Stefan's comments
in the patch hint at using a modified completion table and
annotation-function instead of using an exit-function, which I agree
is the better solution.

One nice thing about displaying the tag suffix as an annotation,
rather than leaving it as part of the candidate in the completion
table, is that there is a separate `completions-annotation` face used.
Thus, when it's displayed in the *Completions* buffer, it is
de-emphasised (at least with the Emacs default face configuration
where it's shadowed and italicized) from the actual candidate text.
Keeping it as part of the candidate makes it truly appear that it is
part of the candidate itself, rather than annotation.

Furthermore, only using an exit-function is likely to lead to
confusion for functionality outside of the "*Completions*" buffer.
Consider `completion-preview-mode`.  When a preview is overlaid on the
buffer, and only an exit-function is used, the tag suffix is also
displayed as part of this overlay.  Again this adds to the confusion
making the user think it is part of the completion, rather than
something which will be removed upon insertion.  This doesn't even
consider third party UIs, such as `company-mode`, `corfu-mode`, etc.
but I see this behavior being confusing there as well.

Something which I think that should be noted is that legacy ada-mode
used `gnatfind` and `gnatxref` for completion and cross-referencing,
but those tools were deprecated and finally removed in GCC 12...I
suspect due to the rise of LSP and the Ada Language Server.
Therefore, I think it's likely that people have not been relying on
Ada etags support in Emacs for a very long time.  This is further
evidenced by the fact that the etags `completion-at-point` support has
been broken for Ada tags for a long time and only now is being
discovered.  As a result, it's my belief that trying to preserve the
display of the Ada tag suffix as part of the completion process is
likely to hinder comprehension rather than add any amount of clarity.

The tag suffix could be considered an implementation detail of TAGS,
which I think is only useful for xref, to help jump to the desired
location.  I don't think it is helpful for completion, other than to
add embellishments to the UI (via annotation-function, company-kind,
etc).

For the above reasons, this is why I decided not to use the
exit-function in the example I previously provided, and instead used a
combination of modifying the completion table as well as the addition
of the annotation-function.  Furthermore, those unfamiliar with the
Ada etags suffix are likely to still be confused even if it were to be
turned into an annotation (since they likely haven't read the portion
of the Emacs manual describing those suffixes).  This is also why I
decided not to use the original suffix text in my example with an
annotation function and instead made the annotation more descriptive.

I believe to properly fix this, the suffix needs to be separated from
the candidate text (via a modified completion table).  I don't think
it's necessary to add an annotation-function to restore the suffix,
but I think the suffix information should at least be preserved
non-visually (e.g., text property on the candidate) so it's available
for use by annotation-function, company-kind, etc.

Message #80 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Troy Brown <brownts <at> troybrown.dev>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Tue, 24 Jun 2025 18:11:31 -0400

Hi Troy,

> For a mode-specific solution, I'm currently using the following.  It
> modifies the result of the completion table to remove the suffix, but
> stores the suffix as a text property on the candidate.  Then the text
> property is retrieved from within the annotation function to generate
> the appropriate suffix.  In this example, I chose to use a more
> descriptive suffix rather than reapplying the original one.  I'm also
> using the text property to drive additional "company-kind" information
> too.  This solution seems to be working well for me.

That seems like a much better solution than my exit-function, indeed.

I suggest adding it to `ada-mode` plus adding to `etag.el` a comment
pointing to that ada-mode` code.

The `etags.el` comment is because `etags.el` now has partial support for
those `/X` annotations.  This partial support is used only for Ada
currently, but the way it's implemented in `etags.el` it can be used for
any language, so it could make sense in the future to move your code
into `etags.el`.

Another option would be to put the code directly in `etags.el`, and make
it non-specific to Ada.  To reduce the cost of your wrapper, we could use
an `etags--found-slash-x-annotation` variable which is set whenever we
match the "/[...]" while reading the TAGS file, and then we only do the
extra dance when that var is non-nil.


        Stefan

Message #83 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: brownts <at> troybrown.dev, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Sat, 05 Jul 2025 10:59:00 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  78489 <at> debbugs.gnu.org
> Date: Tue, 24 Jun 2025 18:11:31 -0400
> 
> Hi Troy,
> 
> > For a mode-specific solution, I'm currently using the following.  It
> > modifies the result of the completion table to remove the suffix, but
> > stores the suffix as a text property on the candidate.  Then the text
> > property is retrieved from within the annotation function to generate
> > the appropriate suffix.  In this example, I chose to use a more
> > descriptive suffix rather than reapplying the original one.  I'm also
> > using the text property to drive additional "company-kind" information
> > too.  This solution seems to be working well for me.
> 
> That seems like a much better solution than my exit-function, indeed.
> 
> I suggest adding it to `ada-mode` plus adding to `etag.el` a comment
> pointing to that ada-mode` code.
> 
> The `etags.el` comment is because `etags.el` now has partial support for
> those `/X` annotations.  This partial support is used only for Ada
> currently, but the way it's implemented in `etags.el` it can be used for
> any language, so it could make sense in the future to move your code
> into `etags.el`.
> 
> Another option would be to put the code directly in `etags.el`, and make
> it non-specific to Ada.  To reduce the cost of your wrapper, we could use
> an `etags--found-slash-x-annotation` variable which is set whenever we
> match the "/[...]" while reading the TAGS file, and then we only do the
> extra dance when that var is non-nil.

Ping!  Any further comments, or should I close this bug?

Message #86 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Troy Brown <brownts <at> troybrown.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Thu, 10 Jul 2025 21:26:30 -0400

On Sat, Jul 5, 2025 at 3:59 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>,  78489 <at> debbugs.gnu.org
> > Date: Tue, 24 Jun 2025 18:11:31 -0400
> >
> > Hi Troy,
> >
> > > For a mode-specific solution, I'm currently using the following.  It
> > > modifies the result of the completion table to remove the suffix, but
> > > stores the suffix as a text property on the candidate.  Then the text
> > > property is retrieved from within the annotation function to generate
> > > the appropriate suffix.  In this example, I chose to use a more
> > > descriptive suffix rather than reapplying the original one.  I'm also
> > > using the text property to drive additional "company-kind" information
> > > too.  This solution seems to be working well for me.
> >
> > That seems like a much better solution than my exit-function, indeed.
> >
> > I suggest adding it to `ada-mode` plus adding to `etag.el` a comment
> > pointing to that ada-mode` code.
> >
> > The `etags.el` comment is because `etags.el` now has partial support for
> > those `/X` annotations.  This partial support is used only for Ada
> > currently, but the way it's implemented in `etags.el` it can be used for
> > any language, so it could make sense in the future to move your code
> > into `etags.el`.
> >
> > Another option would be to put the code directly in `etags.el`, and make
> > it non-specific to Ada.  To reduce the cost of your wrapper, we could use
> > an `etags--found-slash-x-annotation` variable which is set whenever we
> > match the "/[...]" while reading the TAGS file, and then we only do the
> > extra dance when that var is non-nil.
>
> Ping!  Any further comments, or should I close this bug?

I'd be fine if someone wanted to make it more general.  There are
actually multiple Ada major modes available.  The ada-mode in ELPA is
currently unmaintained, but there are at least 3 alternatives that I'm
aware of (including my own ada-ts-mode).  The ideal solution is likely
one where everyone can benefit, but barring someone wanting to drive
this to a generalized conclusion, I'm fine with a mode-specific
solution.

Message #89 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Troy Brown <brownts <at> troybrown.dev>
Cc: monnier <at> iro.umontreal.ca, 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Fri, 11 Jul 2025 09:49:44 +0300

> From: Troy Brown <brownts <at> troybrown.dev>
> Date: Thu, 10 Jul 2025 21:26:30 -0400
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 78489 <at> debbugs.gnu.org
> 
> On Sat, Jul 5, 2025 at 3:59 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> > > Cc: Eli Zaretskii <eliz <at> gnu.org>,  78489 <at> debbugs.gnu.org
> > > Date: Tue, 24 Jun 2025 18:11:31 -0400
> > >
> > > Hi Troy,
> > >
> > > > For a mode-specific solution, I'm currently using the following.  It
> > > > modifies the result of the completion table to remove the suffix, but
> > > > stores the suffix as a text property on the candidate.  Then the text
> > > > property is retrieved from within the annotation function to generate
> > > > the appropriate suffix.  In this example, I chose to use a more
> > > > descriptive suffix rather than reapplying the original one.  I'm also
> > > > using the text property to drive additional "company-kind" information
> > > > too.  This solution seems to be working well for me.
> > >
> > > That seems like a much better solution than my exit-function, indeed.
> > >
> > > I suggest adding it to `ada-mode` plus adding to `etag.el` a comment
> > > pointing to that ada-mode` code.
> > >
> > > The `etags.el` comment is because `etags.el` now has partial support for
> > > those `/X` annotations.  This partial support is used only for Ada
> > > currently, but the way it's implemented in `etags.el` it can be used for
> > > any language, so it could make sense in the future to move your code
> > > into `etags.el`.
> > >
> > > Another option would be to put the code directly in `etags.el`, and make
> > > it non-specific to Ada.  To reduce the cost of your wrapper, we could use
> > > an `etags--found-slash-x-annotation` variable which is set whenever we
> > > match the "/[...]" while reading the TAGS file, and then we only do the
> > > extra dance when that var is non-nil.
> >
> > Ping!  Any further comments, or should I close this bug?
> 
> I'd be fine if someone wanted to make it more general.  There are
> actually multiple Ada major modes available.  The ada-mode in ELPA is
> currently unmaintained, but there are at least 3 alternatives that I'm
> aware of (including my own ada-ts-mode).  The ideal solution is likely
> one where everyone can benefit, but barring someone wanting to drive
> this to a generalized conclusion, I'm fine with a mode-specific
> solution.

To have this in the Ada modes out there, we need to bring the
respective authors on board of this discussion.  Would someone like to
do that, please?

Message #92 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Troy Brown <brownts <at> troybrown.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Mon, 14 Jul 2025 07:52:50 -0400

On Fri, Jul 11, 2025 at 2:49 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Troy Brown <brownts <at> troybrown.dev>
> > Date: Thu, 10 Jul 2025 21:26:30 -0400
> > Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 78489 <at> debbugs.gnu.org
> >
> > On Sat, Jul 5, 2025 at 3:59 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > >
> > > > From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> > > > Cc: Eli Zaretskii <eliz <at> gnu.org>,  78489 <at> debbugs.gnu.org
> > > > Date: Tue, 24 Jun 2025 18:11:31 -0400
> > > >
> > > > Hi Troy,
> > > >
> > > > > For a mode-specific solution, I'm currently using the following.  It
> > > > > modifies the result of the completion table to remove the suffix, but
> > > > > stores the suffix as a text property on the candidate.  Then the text
> > > > > property is retrieved from within the annotation function to generate
> > > > > the appropriate suffix.  In this example, I chose to use a more
> > > > > descriptive suffix rather than reapplying the original one.  I'm also
> > > > > using the text property to drive additional "company-kind" information
> > > > > too.  This solution seems to be working well for me.
> > > >
> > > > That seems like a much better solution than my exit-function, indeed.
> > > >
> > > > I suggest adding it to `ada-mode` plus adding to `etag.el` a comment
> > > > pointing to that ada-mode` code.
> > > >
> > > > The `etags.el` comment is because `etags.el` now has partial support for
> > > > those `/X` annotations.  This partial support is used only for Ada
> > > > currently, but the way it's implemented in `etags.el` it can be used for
> > > > any language, so it could make sense in the future to move your code
> > > > into `etags.el`.
> > > >
> > > > Another option would be to put the code directly in `etags.el`, and make
> > > > it non-specific to Ada.  To reduce the cost of your wrapper, we could use
> > > > an `etags--found-slash-x-annotation` variable which is set whenever we
> > > > match the "/[...]" while reading the TAGS file, and then we only do the
> > > > extra dance when that var is non-nil.
> > >
> > > Ping!  Any further comments, or should I close this bug?
> >
> > I'd be fine if someone wanted to make it more general.  There are
> > actually multiple Ada major modes available.  The ada-mode in ELPA is
> > currently unmaintained, but there are at least 3 alternatives that I'm
> > aware of (including my own ada-ts-mode).  The ideal solution is likely
> > one where everyone can benefit, but barring someone wanting to drive
> > this to a generalized conclusion, I'm fine with a mode-specific
> > solution.
>
> To have this in the Ada modes out there, we need to bring the
> respective authors on board of this discussion.  Would someone like to
> do that, please?

Shouldn't this be an opt-in situation?  I suspect most alternative Ada
modes won't care about this.  How do you propose an unmaintained
ada-mode is addressed?  The original issue that caused this bug report
actually arose on the ada-mode-users mailing list since there was a
user attempting to use etags with ada-mode.  I was able to provide a
workaround for the user to address their needs.

The following are the major modes I'm aware of that support Ada:
- ada-mode (https://savannah.nongnu.org/projects/ada-mode/)
  - Available on ELPA and currently unmaintained.
- ada-ts-mode (https://github.com/brownts/ada-ts-mode)
  - Available on MELPA and Github, I am the author/maintainer.
  - I will be making the necessary changes to support etags.
- old-ada-mode (https://github.com/tkurtbond/old-ada-mode)
  - Available on Github.
  - This is the version of ada-mode which shipped with Emacs (until Emacs 27).
  - Some people prefer old-ada-mode over ada-mode due to the
complexity of installation of ELPA ada-mode.
  - It appears to be feature-locked and only incorporates bug fixes.
- ada-light-mode (https://github.com/sebastianpoeplau/ada-light-mode)
  - Available on Github.
  - Relies on Ada LSP for much of its capability, therefore I suspect
it's not interested in supporting etags.

Message #95 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Troy Brown <brownts <at> troybrown.dev>
Cc: monnier <at> iro.umontreal.ca, 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Mon, 14 Jul 2025 16:13:00 +0300

> From: Troy Brown <brownts <at> troybrown.dev>
> Date: Mon, 14 Jul 2025 07:52:50 -0400
> Cc: monnier <at> iro.umontreal.ca, 78489 <at> debbugs.gnu.org
> 
> On Fri, Jul 11, 2025 at 2:49 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > > Ping!  Any further comments, or should I close this bug?
> > >
> > > I'd be fine if someone wanted to make it more general.  There are
> > > actually multiple Ada major modes available.  The ada-mode in ELPA is
> > > currently unmaintained, but there are at least 3 alternatives that I'm
> > > aware of (including my own ada-ts-mode).  The ideal solution is likely
> > > one where everyone can benefit, but barring someone wanting to drive
> > > this to a generalized conclusion, I'm fine with a mode-specific
> > > solution.
> >
> > To have this in the Ada modes out there, we need to bring the
> > respective authors on board of this discussion.  Would someone like to
> > do that, please?
> 
> Shouldn't this be an opt-in situation?  I suspect most alternative Ada
> modes won't care about this.

Sorry, I don't understand what you are saying.  Whether this should be
opt-in or not is generally up to the respective mode maintainers.

> How do you propose an unmaintained ada-mode is addressed?

Either modify it in its repository or post a patch to the relevant
forum?

Anyway making this change in the modes was not my proposal, so I
cannot be responsible for resolving all the potential issues that this
proposal raises.

> The following are the major modes I'm aware of that support Ada:
> - ada-mode (https://savannah.nongnu.org/projects/ada-mode/)
>   - Available on ELPA and currently unmaintained.
> - ada-ts-mode (https://github.com/brownts/ada-ts-mode)
>   - Available on MELPA and Github, I am the author/maintainer.
>   - I will be making the necessary changes to support etags.
> - old-ada-mode (https://github.com/tkurtbond/old-ada-mode)
>   - Available on Github.
>   - This is the version of ada-mode which shipped with Emacs (until Emacs 27).
>   - Some people prefer old-ada-mode over ada-mode due to the
> complexity of installation of ELPA ada-mode.
>   - It appears to be feature-locked and only incorporates bug fixes.
> - ada-light-mode (https://github.com/sebastianpoeplau/ada-light-mode)
>   - Available on Github.
>   - Relies on Ada LSP for much of its capability, therefore I suspect
> it's not interested in supporting etags.

I hope someone will reach out to the respective developers and add
them to this discussion, so we could finalize the solutions.

Message #98 received at 78489 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Troy Brown <brownts <at> troybrown.dev>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78489 <at> debbugs.gnu.org
Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions
 doesn't find definitions
Date: Sat, 26 Jul 2025 15:11:38 -0400

>> Ping!  Any further comments, or should I close this bug?
> I'd be fine if someone wanted to make it more general.

It should be fairly easy, I could do that.
But we'd need paperwork for your code, because AFAICT you haven't signed
any copyright paperwork yet.

Would you be willing to do that?
If so, please fill the form below and email it to the FSF as instructed
so they can send you the appropriate paperwork to sign.


        Stefan


Please email the following information to assign <at> gnu.org, and we will send you
the assignment form for your past and future changes.

Please use your full legal name (in ASCII characters) as the subject line of
the message.
----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]
Emacs

[Did you copy any files or text written by someone else in these changes?
 Even if that material is free software, we need to know about it.]


[Do you have an employer who might have a basis to claim to own your changes?
 Do you attend a school which might make such a claim?]


[For the copyright registration, what country are you a citizen of?]


[What year were you born?]


[Please write your email address here.]


[Please write your postal address here.]





[Which files have you changed so far, and which new files have you written
so far?]


[Additional people we should notify about the progress of the assignment.]
Stefan Monnier <monnier <at> gnu.org>

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.