From debbugs-submit-bounces@debbugs.gnu.org Sun May 18 21:38:06 2025 Received: (at submit) by debbugs.gnu.org; 19 May 2025 01:38:06 +0000 Received: from localhost ([127.0.0.1]:34508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uGpS7-0005gl-Cr for submit@debbugs.gnu.org; Sun, 18 May 2025 21:38:05 -0400 Received: from lists.gnu.org ([2001:470:142::17]:49678) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uGpRy-0005g1-Lw for submit@debbugs.gnu.org; Sun, 18 May 2025 21:37:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uGpRm-0002KM-Qb for bug-gnu-emacs@gnu.org; Sun, 18 May 2025 21:37:44 -0400 Received: from mail-ej1-f53.google.com ([209.85.218.53]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1uGpRe-0002FV-Tv for bug-gnu-emacs@gnu.org; Sun, 18 May 2025 21:37:42 -0400 Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-acb39c45b4eso554134966b.1 for ; Sun, 18 May 2025 18:37:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747618651; x=1748223451; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=AV3Z81sGdlciTL+6WMCt2cGQHnW29ipxu3DE/byycrw=; b=fzEFkqvQE9Z6IfsiezYOy6N49lHCvcX8tDnKb7XcfhTXJo8WRB6c91ozvzqstZY46g IoRzoPJ1qejec/gQ4PA0CLcVzPrYcbWXpUsyY3yarqXK6kuYohPdBmXKvT9p5CrYGZyR uKfXv8jqxB0f93ghjffXTDvctmO2oczQBXTzUIs5++U/5XtKf5Alrz4dYfoPpPNv+7pe 3nBDZZVhZdYqXVfRg1hA3Hb3IiSu+xm+ds/SttGs6nXnH9FgDN67SFPCYyOHfcE0aHiM j7erf+QzC3qEITh9dgvAKRMyOX4A08MAIsSEmEEE4B5yuF5oF9gtDbfv66swnty9ume6 VL8A== X-Gm-Message-State: AOJu0YwYze/JR2cqJ1AwT03d+Ukl0xGOLqrR2pJsV0GbqhsBS9J1GOl+ dcg88RD8+5nCaVMQqBJ8BgIYoiLz9EQZga/5wKsLJmMUD9R6EspvgyAtEBD4u2sy X-Gm-Gg: ASbGncvHppLxGVrBhHyrjqF8Kez0VLWu9d3+VZkw2eqlFxxhM+GgZzY1aSeQE+DjzXv xKO06bxkGVefU0XvWxEj/1aNY9sdV8ELw5Wby+CxTjY+h8XuCllmT6fMySPZ+VP2nKKLF/ObRkP icP47pnONnEQr+uNKpuuhZU2pNGkIRSkmbeWQOau/MMtf+hn7mghFipbsSI5nE7xkQmj/Wrm6VJ P10YmiHN+suaYRgfbucAgdELcp93Km7FqHSOTvmBkHinHDlSpUuovrXh05andzh/vfSyr4sD1uA pwejdZDfYBna5T0l2x0xNAUQtsrq3oWi39nNVgmaTjAlON89Hj+Di/VodxwyU1qgwptbO0imytk lWlKQPask4QOWvw0= X-Google-Smtp-Source: AGHT+IE/JtiLihq/Syg33Td/R5ND2PF8u3tQ7R1tnut5S1UzHN0dVv1XFuGch9JRUXRbPhfGntHlhQ== X-Received: by 2002:a17:907:9728:b0:ad5:5302:4023 with SMTP id a640c23a62f3a-ad55302638cmr520020166b.44.1747618650779; Sun, 18 May 2025 18:37:30 -0700 (PDT) Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com. [209.85.208.49]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad52d498909sm511696266b.126.2025.05.18.18.37.30 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 18 May 2025 18:37:30 -0700 (PDT) Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-6019b564d0bso3123747a12.2 for ; Sun, 18 May 2025 18:37:30 -0700 (PDT) X-Received: by 2002:a05:6402:34cd:b0:601:89d4:968e with SMTP id 4fb4d7f45d1cf-60189d49a3emr8388622a12.27.1747618650177; Sun, 18 May 2025 18:37:30 -0700 (PDT) MIME-Version: 1.0 From: Troy Brown Date: Sun, 18 May 2025 21:37:19 -0400 X-Gmail-Original-Message-ID: X-Gm-Features: AX0GCFuznbIbHSqS23l_wkKSz-0zyddBV5nmfmefs1nvWmi-ud8aYotVhU62Mww Message-ID: Subject: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions To: "simon254--- via Bug reports for GNU Emacs, the Swiss army knife of text editors" Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=209.85.218.53; envelope-from=troy.s.brown@gmail.com; helo=mail-ej1-f53.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Thu May 22 07:31:17 2025 Received: (at 78489) by debbugs.gnu.org; 22 May 2025 11:31:17 +0000 Received: from localhost ([127.0.0.1]:32768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uI48q-0005tA-Tf for submit@debbugs.gnu.org; Thu, 22 May 2025 07:31:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41016) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uI48n-0005dB-IG for 78489@debbugs.gnu.org; Thu, 22 May 2025 07:31:14 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uI48h-000820-J0; Thu, 22 May 2025 07:31:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=bn+SRtjgxEGRdSqQm/8EWjJxFb+qVV/StcEqXNcz6xA=; b=ghTo7I8aMmcF MYOGSli2WrTcMsDjgKvZxFsIa7/dJ3OLT0BSV2tlVo/Co25Ve45uzEr4Sx2jN+XaTK8IG7gugWevg K+ndujNRW0uPmKOInnYbpobnV0lwFNxu8XnEtYvUzEU0BYLjfEqW7o6a6O7yYF5G7af3FLDPLNt4v +JPkErPgf+SnHlP9JG+HBNah3Eh3sObl2aFLKV2Ea96NBttlearP9vBsjN4eeVxIjJ/lGASCRjovG XriBFGBNK3OlO1BPRGyB+B/dgusruYkmfRawa81B8HbfVnKBcxTcJYwUF82qLqUEQ9wTisVrqzzOj u0+Lqe5aQBuByySxRh+Z0A==; Date: Thu, 22 May 2025 14:31:04 +0300 Message-Id: <861psg7uh3.fsf@gnu.org> From: Eli Zaretskii To: Troy Brown In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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" > > 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? From debbugs-submit-bounces@debbugs.gnu.org Thu May 22 07:31:37 2025 Received: (at 78489) by debbugs.gnu.org; 22 May 2025 11:31:37 +0000 Received: from localhost ([127.0.0.1]:32779 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uI49B-0006Bu-5C for submit@debbugs.gnu.org; Thu, 22 May 2025 07:31:37 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33402) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uI496-00068L-8b for 78489@debbugs.gnu.org; Thu, 22 May 2025 07:31:32 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uI48z-000837-Oe; Thu, 22 May 2025 07:31:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=7vYQ3futuu4IG8iaTtcNHrlXFxezSbnrzQ0Uys5b7yQ=; b=fNZQiFMpxAun afdyRX6Xjfy9LI3VrRsJfXig+4GnV7PlD1Z6KDaZvs8mgQasC+z0YYJcXGoRs8hjpJFrY2KFYHuZf fF9wnYqMBTs7enEV8oQt4RSEf1p0ejnOR7C9p6nPv8fKhrWc0qUfqwizg7Key1ry968Id/oxHesA8 h3ppx6QokZh4PNXCcWLt4wjkbjTkzXhV2slax12hSCm8rsf6GGsTEdxFBH2Bm+AlRX300vA/V23Qi J4yKnY/lcYmE/4Y7N0UZV2GTg60OOkzGpEfzknScO2PlCLB6RMrMs4aSXTCPao10CjNfBDWtWmm9c q3LWl3UbWOPEkWsHR9AG0Q==; Date: Thu, 22 May 2025 14:31:22 +0300 Message-Id: <86zff46fw5.fsf@gnu.org> From: Eli Zaretskii To: Troy Brown In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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" > > 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. From debbugs-submit-bounces@debbugs.gnu.org Mon May 26 16:13:46 2025 Received: (at 78489) by debbugs.gnu.org; 26 May 2025 20:13:46 +0000 Received: from localhost ([127.0.0.1]:60385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uJeCf-0004mz-L8 for submit@debbugs.gnu.org; Mon, 26 May 2025 16:13:46 -0400 Received: from m228-15.mailgun.net ([159.135.228.15]:47604) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uJeCd-0004mh-Co for 78489@debbugs.gnu.org; Mon, 26 May 2025 16:13:44 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.troybrown.dev; q=dns/txt; s=mx; t=1748290411; x=1748297611; h=Content-Transfer-Encoding: Content-Type: Cc: To: To: Subject: Subject: Message-ID: Date: From: From: In-Reply-To: References: MIME-Version: Sender: Sender; bh=MYCfqLA7mW0C5/dwt4vcMdMM1hpfTRqC0mUivMZK2JA=; b=ImjWonm4iYOMSJBQUsO1Ke76jYsjEmbm6agbNfnJYb6/e9CKiagobyb9l8hoPAhA3RNwwa+f2jRCBxfRQPHX15ug2wYyFY/JnnQAPXpVZo6PXoEauK03iGNGeVyIrQpR4YNELM6gM1JrXRyXdrrwo/u6SbnKyoMQwHwRR7n0V7k= X-Mailgun-Sid: WyJiOTYxMCIsIjc4NDg5QGRlYmJ1Z3MuZ251Lm9yZyIsIjVmZDVkMiJd Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by 8ae5160bb82d with SMTP id 6834cb6b93b9589b86ff44d4 (version=TLS1.3, cipher=TLS_AES_128_GCM_SHA256); Mon, 26 May 2025 20:13:31 GMT X-Mailgun-Sending-Ip-Pool-Name: X-Mailgun-Sending-Ip-Pool: X-Mailgun-Sending-Ip: 159.135.228.15 Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-604533a2f62so3959802a12.3 for <78489@debbugs.gnu.org>; Mon, 26 May 2025 13:13:31 -0700 (PDT) X-Gm-Message-State: AOJu0Yx7zycdrozr6AekSj0MGmPQ8/nb1goRDljdzGrAn7uK4Q5TsYrh lx4p3Y+T6QpzJFXmfuX7YBkck5KEtm5hO4/HCVtj04tfCbm6HIsvthOakuhv4rPV/cxpQor6i4G 1blKB1raVulxeet3DURIOpvrQwJa3ub0= X-Google-Smtp-Source: AGHT+IGmLtoaMxD211Q4vl/FlPxe7UDMAEpNAI4caiHcrYTohpwsTW0PsXyJ/EUDvcmi8CrqzIASYTb2GHE7qoqhu4o= X-Received: by 2002:a17:907:c12:b0:ad1:fa48:da0a with SMTP id a640c23a62f3a-ad85b1c2cfamr920697466b.35.1748290410722; Mon, 26 May 2025 13:13:30 -0700 (PDT) MIME-Version: 1.0 References: <86zff46fw5.fsf@gnu.org> In-Reply-To: <86zff46fw5.fsf@gnu.org> From: Troy Brown Date: Mon, 26 May 2025 16:13:19 -0400 X-Gmail-Original-Message-ID: X-Gm-Features: AX0GCFt6oGlrDjFrf6l0exRpGFcCbYHGi01K9jk-n3AZXzagO3J5WiDRGy439ig Message-ID: Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78489 Cc: 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, May 22, 2025 at 7:31=E2=80=AFAM Eli Zaretskii 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"). From debbugs-submit-bounces@debbugs.gnu.org Mon May 26 22:28:50 2025 Received: (at 78489) by debbugs.gnu.org; 27 May 2025 02:28:50 +0000 Received: from localhost ([127.0.0.1]:34880 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uJk3d-0001wX-S2 for submit@debbugs.gnu.org; Mon, 26 May 2025 22:28:50 -0400 Received: from m228-14.mailgun.net ([159.135.228.14]:47848) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uJk3b-0001wC-6V for 78489@debbugs.gnu.org; Mon, 26 May 2025 22:28:47 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.troybrown.dev; q=dns/txt; s=mx; t=1748312914; x=1748320114; h=Content-Transfer-Encoding: Content-Type: Cc: To: To: Subject: Subject: Message-ID: Date: From: From: In-Reply-To: References: MIME-Version: Sender: Sender; bh=6WJpuuCenAHvdPqK4eLl8uvAP3XHhL0wdg48X8MIhyE=; b=dNqisxQih5PiLJWpG3pW8olFCAWnNjYFNY6PQ1PFamDejSCB8vDXKSqhfGDvtg/EURqHvW38hJRHbzuL6hluLXx4T9ATcBmvWJf0JfsTOwCer+Qawns6ihejgW5Jhvuej0degHzCNwfE97Y0qa+ZGluGWl22GoxYGJyJNlCtWl4= X-Mailgun-Sid: WyJiOTYxMCIsIjc4NDg5QGRlYmJ1Z3MuZ251Lm9yZyIsIjVmZDVkMiJd Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by e43cea95fef7 with SMTP id 68352352c953711e148a3a8e (version=TLS1.3, cipher=TLS_AES_128_GCM_SHA256); Tue, 27 May 2025 02:28:34 GMT X-Mailgun-Sending-Ip-Pool-Name: X-Mailgun-Sending-Ip-Pool: X-Mailgun-Sending-Ip: 159.135.228.14 Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-6020ff8d54bso4556650a12.2 for <78489@debbugs.gnu.org>; Mon, 26 May 2025 19:28:34 -0700 (PDT) X-Gm-Message-State: AOJu0YwnMXKKRdnoCfKxvFzuAIM0HqGz/Jbi7qydfFYozLI6g99vvv9n zsiYMr/w/iavdk9EpKALd2ZKzkekTfBOWwb/9DYOa89s0grN5xxNyZl4pRxUUaXHrIyqNA/2IHp PdvdTXU0lfigBqzEENsVY9XadIa6rAgI= X-Google-Smtp-Source: AGHT+IE9zyJjcU6JU/i5iVRdxns13a6a/UZI6YwFYz9ui9gOXtQDVqETKHOnh4UaDeRmEVkOYlRT/UQUdYLkHyoYlrA= X-Received: by 2002:a17:906:15d7:b0:ad8:728b:9ffe with SMTP id a640c23a62f3a-ad8728ba154mr492961066b.38.1748312913435; Mon, 26 May 2025 19:28:33 -0700 (PDT) MIME-Version: 1.0 References: <86zff46fw5.fsf@gnu.org> In-Reply-To: From: Troy Brown Date: Mon, 26 May 2025 22:28:22 -0400 X-Gmail-Original-Message-ID: X-Gm-Features: AX0GCFs3dpYV_x7SczgTP2s1RltBjG1PFR8YjNtYgUuADPZYt5rzPnjpIeKMjs4 Message-ID: Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78489 Cc: 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, May 26, 2025 at 4:13=E2=80=AFPM Troy Brown = 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()=3D,; ]?\177\\(?:\\([^\n\001]+\\)\001\\)?" + "[\f\t\n\r()=3D,; ]?\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. From debbugs-submit-bounces@debbugs.gnu.org Mon May 26 22:33:37 2025 Received: (at 78489) by debbugs.gnu.org; 27 May 2025 02:33:37 +0000 Received: from localhost ([127.0.0.1]:34913 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uJk8G-0002J6-Tn for submit@debbugs.gnu.org; Mon, 26 May 2025 22:33:37 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47636) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uJk8D-0002Ie-TE for 78489@debbugs.gnu.org; Mon, 26 May 2025 22:33:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uJk88-0007lp-C0; Mon, 26 May 2025 22:33:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=P4zb4yp94TkKNKLDki81cvbBro/BryCWFWf2UEEjrTM=; b=L4fqoSKtlraJKXcgP/L4 mzFcL4DKkXfa5sCnHlmmZiwgLqUwyIlBnpzLxbW24weG8T152Fn40PIbaa1j5W3YbRkIKNG3oHAad f+YQoMDPaND5CXSjMS5q/RqPbOnZBDvZD8SDOsqYzXlduC4m+sS1HCg4S6ZGKUaFTNFuSU0GAddXy JjGa6czFp+q+CDmHwGt6woBQjgCgLsl/cjLaZYQG98Y1AN8xq6IU+eKA2bcizQM7UcL7zyzFHOwIg Jw+zsKeOJc1XwS0hKjpxg2dFueKeOCVG9JPkQ8ho+ZT4wCqGtFf6WU06eElna7GiyL1A33uGa3j1f 0h4ga0G6MzPTdA==; Date: Tue, 27 May 2025 05:33:25 +0300 Message-Id: <86o6veye8a.fsf@gnu.org> From: Eli Zaretskii To: Troy Brown In-Reply-To: (message from Troy Brown on Mon, 26 May 2025 16:13:19 -0400) Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions References: <86zff46fw5.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Troy Brown > Date: Mon, 26 May 2025 16:13:19 -0400 > Cc: 78489@debbugs.gnu.org > > On Thu, May 22, 2025 at 7:31 AM Eli Zaretskii 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. From debbugs-submit-bounces@debbugs.gnu.org Mon May 26 23:16:23 2025 Received: (at 78489) by debbugs.gnu.org; 27 May 2025 03:16:23 +0000 Received: from localhost ([127.0.0.1]:35190 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uJknf-0005M3-1N for submit@debbugs.gnu.org; Mon, 26 May 2025 23:16:23 -0400 Received: from m228-15.mailgun.net ([159.135.228.15]:43164) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uJknc-0005LT-PP for 78489@debbugs.gnu.org; Mon, 26 May 2025 23:16:21 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.troybrown.dev; q=dns/txt; s=mx; t=1748315769; x=1748322969; h=Content-Transfer-Encoding: Content-Type: Cc: To: To: Subject: Subject: Message-ID: Date: From: From: In-Reply-To: References: MIME-Version: Sender: Sender; bh=/Vv7uQ82W7eaO4HYP4YMNiWQi6g44E0xjvgvcdsyLAk=; b=lMq1yrsZZDZL4EzLNkDO0dzOoSOv+ta1k41zBsW09HPhmEnQPmE0P+DsGpMxUZdzUwgetP6nsrFZIJWmaLQb6GNl5eD0hL4UBNXCj8FUhL7BlNlBeP9yWao1qK6qxqBfSv1bhfl2qItIZVf6L2NlwQ0XS+ua6cbslzYh5jwF5ek= X-Mailgun-Sid: WyJiOTYxMCIsIjc4NDg5QGRlYmJ1Z3MuZ251Lm9yZyIsIjVmZDVkMiJd Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by b937afeedd9e with SMTP id 68352e79c8ee7f70986d6235 (version=TLS1.3, cipher=TLS_AES_128_GCM_SHA256); Tue, 27 May 2025 03:16:09 GMT X-Mailgun-Sending-Ip-Pool-Name: X-Mailgun-Sending-Ip-Pool: X-Mailgun-Sending-Ip: 159.135.228.15 Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-ac34257295dso565615666b.2 for <78489@debbugs.gnu.org>; Mon, 26 May 2025 20:16:09 -0700 (PDT) X-Gm-Message-State: AOJu0YxZYD2EaL3X9axV8ux8x5cf4lVeDbIb3ZmdZx663eoDaT3ahtq0 ebLVOjoKOh/kDJFUdm6zqGXobighF2hy0V8GSP95Q+rrMjNVTEh0LtyV7xnTskwHSLF0HYZnlVW g84pSJZ1t0zcahm7WGVGThKJGcWoZ8pg= X-Google-Smtp-Source: AGHT+IGTZytduVnLsH9os/bMS8rdKYAikBPmzv6xFdXgkbBGzZNQKL+B/1fobsWVHyaZ2hk4l/fqpbKr/U/KWSXKpGQ= X-Received: by 2002:a17:907:86a7:b0:ad2:409f:fe6f with SMTP id a640c23a62f3a-ad85b2c684amr920797266b.44.1748315768121; Mon, 26 May 2025 20:16:08 -0700 (PDT) MIME-Version: 1.0 References: <86zff46fw5.fsf@gnu.org> <86o6veye8a.fsf@gnu.org> In-Reply-To: <86o6veye8a.fsf@gnu.org> From: Troy Brown Date: Mon, 26 May 2025 23:15:57 -0400 X-Gmail-Original-Message-ID: X-Gm-Features: AX0GCFv6q0F4bZgNUKdOvyFNo2OEQ3N4EGi4Ja9UQ-usufS0VNvL5IlpC4hWxVI Message-ID: Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78489 Cc: 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, May 26, 2025 at 10:33=E2=80=AFPM Eli Zaretskii 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. From debbugs-submit-bounces@debbugs.gnu.org Tue May 27 06:57:12 2025 Received: (at 78489) by debbugs.gnu.org; 27 May 2025 10:57:12 +0000 Received: from localhost ([127.0.0.1]:39162 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uJrzb-0001zw-HY for submit@debbugs.gnu.org; Tue, 27 May 2025 06:57:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41172) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uJrzZ-0001zI-35 for 78489@debbugs.gnu.org; Tue, 27 May 2025 06:57:09 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uJrzT-0004iE-Bv; Tue, 27 May 2025 06:57:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=I4fnOJ7eBWej7GRjL48VEdiRL2ZuDGyuWXu30V6rXd0=; b=LZsAMba2af26wJG0S6bb 5+M3vRrYTv5kPz2do70xk0MLQy7fhGT19BJt2sBE8FCGXZvPJwzkVCwfPtQyPylf7kepgazPa7FXE SEs+eqYjmOedyJ3SrCiFGSlxWRUKGCj9C9WRsyG2R7mm/vqkr5BhRXOft5UBgoDcgVo10kQbqIeA6 oEE/hvN5DGTOV9+kEmeyCNTJYA8WWjfyB6P20y9IKfOXHXxxV/SMYZpy6ZWaX81c2j+lWrbmZL4+P r4K0lSzaJ1cbp7Ub3CfSbcZERUFpN4wmCZHfyMYUjzdsSNygtzCAzXqZP4BaLFvpa9V6XgfYpYmvY clTXVHmmwAWcPQ==; Date: Tue, 27 May 2025 13:56:59 +0300 Message-Id: <86msayxqx0.fsf@gnu.org> From: Eli Zaretskii To: Troy Brown In-Reply-To: (message from Troy Brown on Mon, 26 May 2025 16:13:19 -0400) Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions References: <86zff46fw5.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Troy Brown > Date: Mon, 26 May 2025 16:13:19 -0400 > Cc: 78489@debbugs.gnu.org > > On Thu, May 22, 2025 at 7:31 AM Eli Zaretskii 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. From debbugs-submit-bounces@debbugs.gnu.org Tue May 27 07:44:03 2025 Received: (at 78489) by debbugs.gnu.org; 27 May 2025 11:44:03 +0000 Received: from localhost ([127.0.0.1]:39489 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uJsiw-0008J3-0z for submit@debbugs.gnu.org; Tue, 27 May 2025 07:44:02 -0400 Received: from m228-15.mailgun.net ([159.135.228.15]:34774) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uJsis-0008I7-N1 for 78489@debbugs.gnu.org; Tue, 27 May 2025 07:44:00 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.troybrown.dev; q=dns/txt; s=mx; t=1748346225; x=1748353425; h=Content-Transfer-Encoding: Content-Type: Cc: To: To: Subject: Subject: Message-ID: Date: From: From: In-Reply-To: References: MIME-Version: Sender: Sender; bh=gUgRE3b72NdAAxbzrau3Y9hkzEwrKVo1GRnPxKyBpFY=; b=BAae/6OMjXrjEZi8E+w8+6Y3Xqos/zyc9JkSEsvbKuCp+h0OrPYLyaT4izU+lvZkuGztiGjEZHHmbFvtWXHxP71XLUt4FvM2ylgdLJz3XS1z5F7r9hfF9mAaRCuKH4MW6yXTtEVaic0VVovF/ZD2OMdKdIUETTarQmmRLojdBqE= X-Mailgun-Sid: WyJiOTYxMCIsIjc4NDg5QGRlYmJ1Z3MuZ251Lm9yZyIsIjVmZDVkMiJd Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by 6618b4fe455a with SMTP id 6835a571103a6517253e40c2 (version=TLS1.3, cipher=TLS_AES_128_GCM_SHA256); Tue, 27 May 2025 11:43:45 GMT X-Mailgun-Sending-Ip-Pool-Name: X-Mailgun-Sending-Ip-Pool: X-Mailgun-Sending-Ip: 159.135.228.15 Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-603fdd728ccso4694824a12.2 for <78489@debbugs.gnu.org>; Tue, 27 May 2025 04:43:45 -0700 (PDT) X-Gm-Message-State: AOJu0Yxh6m2GxpM5EGhrP6S4xvLgxXiJOoKuULoRo66Qin2nLanVeYoy bxg4T7RIggqUefUj2yVyQFuMJNr4312Tu9PMaSZR2uRpp+laommjkAl3R+cdaoRDxEpMXi+B7p9 xnjDJmOWeDy9B4Ai/ubhkk9k50aMtNiU= X-Google-Smtp-Source: AGHT+IHGOmVpVkuJk4CmzsLFe0W/71vitBcRxzywMkJmxZ2G+rvILKQuOlvXudadMVCXbQcLqLhGftLsYVKUDsF0otI= X-Received: by 2002:a05:6402:1d55:b0:5f4:d4a7:dab1 with SMTP id 4fb4d7f45d1cf-602d9cf2857mr10454778a12.18.1748346224556; Tue, 27 May 2025 04:43:44 -0700 (PDT) MIME-Version: 1.0 References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> In-Reply-To: <86msayxqx0.fsf@gnu.org> From: Troy Brown Date: Tue, 27 May 2025 07:43:33 -0400 X-Gmail-Original-Message-ID: X-Gm-Features: AX0GCFsAukA9i-9YFDuA9A7M-mM1FwZPEEDNPMUkle1S2hNl_cIC3GE-c_gczgA Message-ID: Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78489 Cc: 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Tue, May 27, 2025 at 6:57=E2=80=AFAM Eli Zaretskii 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. From debbugs-submit-bounces@debbugs.gnu.org Tue May 27 08:22:12 2025 Received: (at 78489) by debbugs.gnu.org; 27 May 2025 12:22:12 +0000 Received: from localhost ([127.0.0.1]:39775 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uJtJs-0002gT-4l for submit@debbugs.gnu.org; Tue, 27 May 2025 08:22:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43460) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uJtJo-0002fv-Ll for 78489@debbugs.gnu.org; Tue, 27 May 2025 08:22:09 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uJtJe-0008Fx-Hl; Tue, 27 May 2025 08:21:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=vxt9/Iz4uOJsuRUNDIAO7cUzX/ENNFeZg+rs706q4uk=; b=BjeIF2euHEPEJhm9rfRN M62+OI9FMWUf88GjljLP6ATMMAaIVzGPV/qokqQy41XqFBonlu0F9ucgJyvw0rzyqy+cXX75Gqb00 G8u8ZpmuSkPKMDYIHsLgcWRIfTZoqhhT5B0dtkfSOjW608hBrMK9NzO1KUDYSqeV8Q4A7T02NTNFY mvUqDaKPeaAudM9KVTFkcW3yu0sHIWS2FMs5j83UVJq8pr5MhjseMa3NgHrRxl4QhWEchEuBH4gRq ZtZfhyEzf7VtSM+2Zop9uCEpAwjGBHc1T1aqLptUtOWpo6k6E35n7k2ffMWTsQOk+BbNxpyALqciV VRMqVwlLbytBlA==; Date: Tue, 27 May 2025 15:21:52 +0300 Message-Id: <86bjrexmzj.fsf@gnu.org> From: Eli Zaretskii To: Troy Brown , Stefan Monnier In-Reply-To: (message from Troy Brown on Tue, 27 May 2025 07:43:33 -0400) Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Troy Brown > Date: Tue, 27 May 2025 07:43:33 -0400 > Cc: 78489@debbugs.gnu.org > > On Tue, May 27, 2025 at 6:57 AM Eli Zaretskii 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? From debbugs-submit-bounces@debbugs.gnu.org Tue May 27 10:00:41 2025 Received: (at 78489) by debbugs.gnu.org; 27 May 2025 14:00:42 +0000 Received: from localhost ([127.0.0.1]:41953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uJurB-0001lS-EV for submit@debbugs.gnu.org; Tue, 27 May 2025 10:00:41 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:34606) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uJur7-0001l3-86 for 78489@debbugs.gnu.org; Tue, 27 May 2025 10:00:38 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id BD632808B5; Tue, 27 May 2025 10:00:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1748354430; bh=+FPM3wY+yb40066bvinkW+1HsRMFg5K4gNNsjlxgxrA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=j7YiJg4YBPVzGBB/jyyOqb30rBRyLqQB3k+0U4JSMSe6nfH9PV2xxzQIif9Gmzc8i OwrJLf8mdvM0TiFHoEzv3dEMh8zfN87wiWlW2Emdu/7fGvAQlDZ4KNBpCzqnihpeqg pAmjNrSt8VxKiFtDAQja/yDf/+QdCXk3NRrPTMN7ADkBQZC+DTAyWZOsNkEN/IYWnp 5RNShP0kwTfdPzLu2E9a6vrGVIEKoc32BLMA9tL/1vCwiGEwg6Uie5lMcAYkPMtwKl RbFHC9gO8SgkTnn5u0Duf7S5BXkL8w4WQanu9DhK4S0BYHoUFQOGCdr/ql5ugxHB74 PndSyAabdrAxw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D120B801F6; Tue, 27 May 2025 10:00:30 -0400 (EDT) Received: from pastel (unknown [104.247.225.139]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7FC961203A5; Tue, 27 May 2025 10:00:30 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions In-Reply-To: <86bjrexmzj.fsf@gnu.org> Message-ID: References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> Date: Tue, 27 May 2025 10:00:29 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.377 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: Troy Brown , 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> 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 From debbugs-submit-bounces@debbugs.gnu.org Tue May 27 11:30:05 2025 Received: (at 78489) by debbugs.gnu.org; 27 May 2025 15:30:05 +0000 Received: from localhost ([127.0.0.1]:42606 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uJwFg-0008RL-4d for submit@debbugs.gnu.org; Tue, 27 May 2025 11:30:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38226) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uJwFc-0008M5-Rl for 78489@debbugs.gnu.org; Tue, 27 May 2025 11:30:02 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uJwFV-0001PK-0j; Tue, 27 May 2025 11:29:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=BFV41SlaT8+F/raQd2Sssmu2nnfM1qTQEOaOa3tmCHQ=; b=JoOXuPut4T6k CeR1X1ozlYDWDuuCOHUwxxzI0uDjJgw9RHKmc4f+o4K+XPPEKeTwUWUTFUcDG6bbG1D03LkUJgcZQ vLeEcYLCKsWADySTtLeFXDC0Qnm2lcddvScRoV/OcHj/3omeArCutoELxQqZhni9Q2mPKc+6JIqjd Cp0EzeNIZYMqbYCJ7uokKPxi9WEja29Kyyy6DT4pMN3OdJimsT7NaFg9IzqS3PBFCUdviUZ4JmS3Y IYFcs+5L0yyjbQBqZZby6kF7PXzkzRg2qeWY52xmsVAU1FMTTrz82/Km3gnpj/FV4Bjc4HyTVSt9P tfGXOrgKW6tonUlB/SHlAQ==; Date: Tue, 27 May 2025 18:29:46 +0300 Message-Id: <868qmixead.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Tue, 27 May 2025 10:00:29 -0400) Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: brownts@troybrown.dev, 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Troy Brown , 78489@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. From debbugs-submit-bounces@debbugs.gnu.org Tue May 27 12:13:16 2025 Received: (at 78489) by debbugs.gnu.org; 27 May 2025 16:13:16 +0000 Received: from localhost ([127.0.0.1]:42911 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uJwvT-00069s-UA for submit@debbugs.gnu.org; Tue, 27 May 2025 12:13:16 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:32596) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uJwvR-00069R-ES for 78489@debbugs.gnu.org; Tue, 27 May 2025 12:13:14 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DE9AB441485; Tue, 27 May 2025 12:13:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1748362385; bh=dLQ06NgaIeyFRPbfpds7eo6X7VNIpM+4wtJSechOWjo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=gmU/bAoRiLhiDe0jYYXhqKmdhIU5oSxLSr0yMAqHNDvzASBHFKNuBldzk/vGZvjsn Hdo2faSfJbveD/u40jpdKr73Heg0Kp1KeE97b7vnh9/Z+GK1M8iPF6kLZkT6wWgAoJ X2zZekkKZwfOpz2xq7tS1sWi/8zV+KE6KgcfFcO6PgK4Lo+/dShJGC7jUUtG83muSt 1/fBKyM6BfZrHzdEN9HSZb4oowNdX8O4qQPkr14OZdNjJdfr7RXXJw5xaomc9GwNX6 QT4TZpIyeD0U5EQWC4OfHFEpsgQlsJP7lxTTLN7/w5NhrOFAcNJpqX7f7ve2lW/oRc gLN7RrOjSfoDQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BC12C44106E; Tue, 27 May 2025 12:13:05 -0400 (EDT) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AB9F51204B4; Tue, 27 May 2025 12:13:05 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions In-Reply-To: <868qmixead.fsf@gnu.org> Message-ID: References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> <868qmixead.fsf@gnu.org> Date: Tue, 27 May 2025 12:13:04 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.163 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: brownts@troybrown.dev, 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> 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 From debbugs-submit-bounces@debbugs.gnu.org Tue May 27 12:17:25 2025 Received: (at 78489) by debbugs.gnu.org; 27 May 2025 16:17:25 +0000 Received: from localhost ([127.0.0.1]:42951 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uJwzV-0006Tl-A4 for submit@debbugs.gnu.org; Tue, 27 May 2025 12:17:25 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10452) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uJwzR-0006T1-Gm for 78489@debbugs.gnu.org; Tue, 27 May 2025 12:17:22 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E9A98441091; Tue, 27 May 2025 12:17:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1748362634; bh=VCcvTwChGlWWmUogsvypAwiosPzIVtaBchL0Y4F3i8A=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=BrLVUwgdukJ5dzn4iURx+R8zVoFQWy0QnC6zCdogXV7X3Z/FyWlIGBkIG7irI93AL yo6yLT3srIiHQUFKWFmc35egkPQu2HspNMjSgWhD5e/KSMJ8XcUUpdXvvc7n2wZFrs 6vq0jjAw4SqD7EU+juEZoW4j8M+EeJ+Qlkw9YWbrXAj60RsymxNUDuc330Ld5Pru0+ iT9JOQFupnWnWgxrQZvL1qXpvPwGHlYII83C9f+GatxVY8SYw991VVQBzUbn46EKuh tHNmVZRiWY4+D5FwnItF1JtmyfH8t5WL0hNeL51cOnPsb7zNuS786n0S5U0qLSbjB6 jHOHVkRcvaFpg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 33F684410C8; Tue, 27 May 2025 12:17:14 -0400 (EDT) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2109F120352; Tue, 27 May 2025 12:17:14 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions In-Reply-To: <868qmixead.fsf@gnu.org> Message-ID: References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> <868qmixead.fsf@gnu.org> Date: Tue, 27 May 2025 12:17:12 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.162 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: brownts@troybrown.dev, 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> 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 From debbugs-submit-bounces@debbugs.gnu.org Tue May 27 14:17:39 2025 Received: (at 78489) by debbugs.gnu.org; 27 May 2025 18:17:40 +0000 Received: from localhost ([127.0.0.1]:43956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uJyrq-0008A5-QT for submit@debbugs.gnu.org; Tue, 27 May 2025 14:17:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38790) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uJyrg-00088u-Eq for 78489@debbugs.gnu.org; Tue, 27 May 2025 14:17:35 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uJyrP-00082E-JR; Tue, 27 May 2025 14:17:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=qYV1PTJB/iJ+I9tYi3rkGXTTug+NhaMj8zdY1B3HlJI=; b=RmJdkDxPXu6Y NR5rY/hRnxRGleeWynshx383i/o/5EZRzkZkxT1GrGnb5oPhdwkBSyNadEKKx5DYxaKXXEp4DNHre J6GoMk+M8ER5xSSiCt4TFfBoZ1POnUsjL0QsDq/x77iXhfYAufnMyzRZyq5VDDutMfG6ganCtz47U f/OF8pzbXDyjHN9GSiMy7A5pHDXl4D76Qznetm+P2mjLF2pgRmLX++Lh5d5vR4/xgy08SgGQjjnfc Avvz0UMe7H/6MaEbMR+at04s7/Rum5HuwKHi7kllm7X30GqgslbHeubnxLyvE8LML2pQSAbxaib4e Rm5/2Job9K2qFbFTDUlLcA==; Date: Tue, 27 May 2025 21:17:05 +0300 Message-Id: <864ix5yl3y.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Tue, 27 May 2025 12:13:04 -0400) Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> <868qmixead.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: brownts@troybrown.dev, 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: brownts@troybrown.dev, 78489@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. From debbugs-submit-bounces@debbugs.gnu.org Tue May 27 17:57:47 2025 Received: (at 78489) by debbugs.gnu.org; 27 May 2025 21:57:47 +0000 Received: from localhost ([127.0.0.1]:45552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uK2It-0007uG-B5 for submit@debbugs.gnu.org; Tue, 27 May 2025 17:57:47 -0400 Received: from m228-14.mailgun.net ([159.135.228.14]:53350) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uK2Iq-0007tT-PK for 78489@debbugs.gnu.org; Tue, 27 May 2025 17:57:45 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.troybrown.dev; q=dns/txt; s=mx; t=1748383052; x=1748390252; h=Content-Transfer-Encoding: Content-Type: Cc: To: To: Subject: Subject: Message-ID: Date: From: From: In-Reply-To: References: MIME-Version: Sender: Sender; bh=QsKiOF1i3XW9Y6qq5FlVxGlClUKdocpBCK1udN9ZZNA=; b=kudqNg+8eiQWE7DXm10iR9Me0tkqyL835f0IUvxxGJxZB2loPpTNEO2MmAj9yG5j6AabhGwtax67LE2ynp29NmALP9icxnnLhXonDQaWMfrPm8dSpXNIGRp6yL94OnDiqPy4mXHVTshqi/KRuT6y4S8OB90MwsOCDWKNOtioNGs= X-Mailgun-Sid: WyJiOTYxMCIsIjc4NDg5QGRlYmJ1Z3MuZ251Lm9yZyIsIjVmZDVkMiJd Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) by 59946ea0bbe8 with SMTP id 6836354c5c898d6dba03e77c (version=TLS1.3, cipher=TLS_AES_128_GCM_SHA256); Tue, 27 May 2025 21:57:32 GMT X-Mailgun-Sending-Ip-Pool-Name: X-Mailgun-Sending-Ip-Pool: X-Mailgun-Sending-Ip: 159.135.228.14 Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-5fbfdf7d353so5100970a12.0 for <78489@debbugs.gnu.org>; Tue, 27 May 2025 14:57:32 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVueWGVFQdBSsmJGG9vW8nsi4FZeKGbIKZAHiGcTh7xAj7XdEsekF9eCnwCTbr3tbDriWNgVg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxAI8DQ5Wcud1T7HHnfNFnb/705mBk3avqitSgdielAk9QXlV5Q bQHSM/tjajvhsnRtoXJApeVF6lBVJZtAzGwk9wcY1Sz7YJvDtNuc4wSG65TIsn6Cv0H7XETYSvj 49CH89TAKXjxNFbDxV5RMgMygTh1ESGM= X-Google-Smtp-Source: AGHT+IFUvmXOqG7J/tkQ5YoKSbbAZ0zBZhKCXaNYuHbrL6rleLDWgvtT0DnEREiMFsigI4SPAFyZrijR+XOv07D/RiU= X-Received: by 2002:a17:907:60cb:b0:ad8:8b77:ab61 with SMTP id a640c23a62f3a-ad88b77ace1mr359994466b.19.1748383052134; Tue, 27 May 2025 14:57:32 -0700 (PDT) MIME-Version: 1.0 References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> In-Reply-To: <86bjrexmzj.fsf@gnu.org> From: Troy Brown Date: Tue, 27 May 2025 17:57:21 -0400 X-Gmail-Original-Message-ID: X-Gm-Features: AX0GCFvRuGaC8xE6r4_nWgnrdrpwHCoMfB_mfYc1NhBFnd3w__nlLNAP7FDM0xU Message-ID: Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78489 Cc: Stefan Monnier , 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Tue, May 27, 2025 at 8:22=E2=80=AFAM Eli Zaretskii 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. From debbugs-submit-bounces@debbugs.gnu.org Sat May 31 07:46:59 2025 Received: (at 78489) by debbugs.gnu.org; 31 May 2025 11:47:00 +0000 Received: from localhost ([127.0.0.1]:56437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLKfw-0006Uw-Vd for submit@debbugs.gnu.org; Sat, 31 May 2025 07:46:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42766) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uLKfr-0006TI-Ua for 78489@debbugs.gnu.org; Sat, 31 May 2025 07:46:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uLKfl-0000ln-KJ; Sat, 31 May 2025 07:46:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=wCAETQ0fTPShIl2PMJuyGx/s05cBkeZMNxwGIxZQnP0=; b=rFnHdqp7O1w/ Y1TTMYjUR6oUdUlQ+UQ9GqGpHqfvuei2UsFeLPGHlpN6wwMT99UC3LonxDtlQBAaLQJanSbm8Zhs6 tlvTyAWYfOXKpxQKFavggZ5UZk+tV8QXmgRNX3tJJlBhFTMBmeWbLTMUbsoMOPu9T6q63YV2dTmm5 MmXU9MVHvjr/NUt5D4yUffuGgWz5BhUDuNffy1J/nmuOCLi/tiVXdRM7vAAQonahxReYfaizzPado 9ygwKnCxZHado7Fblyc9nHkVN5AFhe/68xPC9yMAZ6jYhrVVNvZ2HhOi7jtXPtiU2Q7WWi1gCQbbW NF0TBGXM9fCTjU0cAh578A==; Date: Sat, 31 May 2025 14:46:42 +0300 Message-Id: <867c1xroil.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Tue, 27 May 2025 12:17:12 -0400) Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> <868qmixead.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: brownts@troybrown.dev, 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: brownts@troybrown.dev, 78489@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? From debbugs-submit-bounces@debbugs.gnu.org Sat May 31 08:54:57 2025 Received: (at 78489) by debbugs.gnu.org; 31 May 2025 12:54:58 +0000 Received: from localhost ([127.0.0.1]:56844 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLLjj-0006ph-CP for submit@debbugs.gnu.org; Sat, 31 May 2025 08:54:57 -0400 Received: from m228-14.mailgun.net ([159.135.228.14]:56038) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uLLje-0006nl-EE for 78489@debbugs.gnu.org; Sat, 31 May 2025 08:54:53 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.troybrown.dev; q=dns/txt; s=mx; t=1748696078; x=1748703278; h=Content-Transfer-Encoding: Content-Type: Cc: To: To: Subject: Subject: Message-ID: Date: From: From: In-Reply-To: References: MIME-Version: Sender: Sender; bh=5v+V6ItgIL2IuqormNr+ebL6fTlW+nFqqf77sbsk3q8=; b=TMW3YG6yO6Cg4ApM+x8QY9SzEfAmXcJyFeWvp50utO8uJWu6Ld0z8kgIJFl5OdVIwEUO+woIbVix8re2SJ8z6T/r1OUpKPAnZdxwl/WCaQoSw3psHLPdO4OhwEZq0poSr/uNDcYhAMuN7LDnOu55m3OvQ2DMMNggEI2k/8PRmXw= X-Mailgun-Sid: WyJiOTYxMCIsIjc4NDg5QGRlYmJ1Z3MuZ251Lm9yZyIsIjVmZDVkMiJd Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) by 1493c812ccba with SMTP id 683afc0e2a5fd996599c3d7f (version=TLS1.3, cipher=TLS_AES_128_GCM_SHA256); Sat, 31 May 2025 12:54:38 GMT X-Mailgun-Sending-Ip-Pool-Name: X-Mailgun-Sending-Ip-Pool: X-Mailgun-Sending-Ip: 159.135.228.14 Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-602e203db66so4950315a12.1 for <78489@debbugs.gnu.org>; Sat, 31 May 2025 05:54:38 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVVtT1uYEoGkaRb/J0B/K5dZIa2YU3tARmiHp/q1vsz0qrIKUovcalVTjXZVSxsWRF2WpMJwQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwIR77jyqQG5PWQEVQgnohAtW1v+X+Ie0hEVeCm0h9oofUzIOLh m9gQSG+jrRFG0mORQ12to5VtDg6zEeWxiQ2Yr6yeEceodFH4SJMT8zodFEcgXQNFqLHpRYQLrvb wS9Y8KF630O948t/7Bj43UFPZ/pGPkH4= X-Google-Smtp-Source: AGHT+IHHXSmUn8t8cvShQPA+77ke7XEz/FQZH98k4trJ09K6FekYnVQsQ/moMK2t5tebGJErR2Yfaacg8we2skCla6c= X-Received: by 2002:a05:6402:1e89:b0:5f6:2758:149e with SMTP id 4fb4d7f45d1cf-605b7735e30mr1548782a12.11.1748696077163; Sat, 31 May 2025 05:54:37 -0700 (PDT) MIME-Version: 1.0 References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> <868qmixead.fsf@gnu.org> <867c1xroil.fsf@gnu.org> In-Reply-To: <867c1xroil.fsf@gnu.org> From: Troy Brown Date: Sat, 31 May 2025 08:54:25 -0400 X-Gmail-Original-Message-ID: X-Gm-Features: AX0GCFuCW3lzglLkeeHyrIKbM3Y9xYBij4ydlZT3v3GnJ4kv0TEiGm-78QL825M Message-ID: Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78489 Cc: Stefan Monnier , 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, May 31, 2025 at 7:46=E2=80=AFAM Eli Zaretskii wrote: > > > From: Stefan Monnier > > Cc: brownts@troybrown.dev, 78489@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 thei= r > > >> 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 ar= e > > > 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 ar= e > > 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--- From debbugs-submit-bounces@debbugs.gnu.org Sat May 31 14:27:14 2025 Received: (at 78489) by debbugs.gnu.org; 31 May 2025 18:27:15 +0000 Received: from localhost ([127.0.0.1]:59832 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLQvJ-00078k-0X for submit@debbugs.gnu.org; Sat, 31 May 2025 14:27:14 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:1058) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uLQvG-00077o-8F for 78489@debbugs.gnu.org; Sat, 31 May 2025 14:27:11 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B21EA80919; Sat, 31 May 2025 14:27:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1748716018; bh=fwouawe/mgLkiH7Nl2erP0r3EYsiJZyIPVNn/ViAm/E=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=U/T3cX9x7Dt0x+eRhSbGDALEjYaxU1+GtF1xIYkS8hZv27w5Cz6Nkrlu3vjAKMu2a mYTia6Zr/U9BJM5/uJZpX6kUnp9/P/NStGSICttPJSWfMNEHm9Y+7mMz+RxEzVN621 PDoK+CVlZLvSJqtSighrMhoLjRWRbjKQ43b9aPyOJc83CYt9/dD+RbjiCV4vmPVC+d aCPoXHCxNfVKk2I10KO56l3dTUG1qzqo+dkgxmDLVLMZ+083/ZKl4LU2QUcwI00gMQ VBvoyjshpkhk/tJG3sEVbt2M/qY1Dv0hHzQ4bz7A/SkeBxjP8BrNc0yCIrRBtI2Wkg QDACoF2p7Ohew== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7243D801C7; Sat, 31 May 2025 14:26:58 -0400 (EDT) Received: from alfajor (unknown [104.247.225.139]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3F31D1201E8; Sat, 31 May 2025 14:26:58 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions In-Reply-To: <867c1xroil.fsf@gnu.org> Message-ID: References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> <868qmixead.fsf@gnu.org> <867c1xroil.fsf@gnu.org> Date: Sat, 31 May 2025 14:26:57 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.370 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: brownts@troybrown.dev, 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain > 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 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=etags.patch 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. --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 01 01:15:37 2025 Received: (at 78489) by debbugs.gnu.org; 1 Jun 2025 05:15:38 +0000 Received: from localhost ([127.0.0.1]:35230 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLb2l-0006Iv-2O for submit@debbugs.gnu.org; Sun, 01 Jun 2025 01:15:37 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43214) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uLb2e-0006GK-8u for 78489@debbugs.gnu.org; Sun, 01 Jun 2025 01:15:32 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uLb2Y-0004S9-3c; Sun, 01 Jun 2025 01:15:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Ru1CXUzRpi7pKt1Z/hxPOVYaO3tPQBrhx/3Ehiul6xs=; b=iEjTFol+4FtV692HwRkp ua/wIwCn5PNT5iZc7urjENRiwBghX9+LBn40n+vPzpEHbFFUD5SDxZmTo/kLOdIwgcmi9nWXSZ4kt tPIsqHZPlSPHLZyX+EbCy9NG6WKrw5IZR+B/3F3cmyG24ynbI0eF6pRthRna/7hRVnkWFRcsESAYc Q+B86WopGo0HW7GsLdez4RnKouLJmEXRJDvS5rS/+k6v6wacdKbMwvHUhtjd8y2+Vyxu67p5gAcS6 MLBozq8Runi4y54uyGtGhh+NwF07b4iIDcIrBdrdzdv3KjuZX+77131V9IsCoc7jAUzlr+Lqj9uZt 8e99LkPrLFTkgA==; Date: Sun, 01 Jun 2025 08:15:11 +0300 Message-Id: <86jz5wqbz4.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sat, 31 May 2025 14:26:57 -0400) Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> <868qmixead.fsf@gnu.org> <867c1xroil.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: brownts@troybrown.dev, 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: brownts@troybrown.dev, 78489@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)? From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 01 18:19:44 2025 Received: (at 78489) by debbugs.gnu.org; 1 Jun 2025 22:19:44 +0000 Received: from localhost ([127.0.0.1]:42896 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLr1r-0004Pr-TO for submit@debbugs.gnu.org; Sun, 01 Jun 2025 18:19:44 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:26402) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uLr1o-0004Oa-Oq for 78489@debbugs.gnu.org; Sun, 01 Jun 2025 18:19:41 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4F9BC1002EC; Sun, 1 Jun 2025 18:19:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1748816372; bh=exqBmORe4KRYwuKfxUu3vm12Dwg9Re2cVKZcedSiTK8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Ui8S5OPDFfKUcDYiU82pbP1Q2zdGLYZFFRpw0HEH7kvRH7XViIAmUo1Q1U0h9aE3d sBYcdVz0lxh58jPb7VVq0xpku9iwzc1t95YzFD7SfOC6D/6raebWCweYpIeHJDSSNy laHdbYEB7lKOP70t22JOvme82fQC8IVAgtzFFeJtQofZF506QwoLwdCGYF4LZrXS92 qlXAyDBukkPZelVQt+0nu+2w7jJh3ssPK/EGOEOT3o5l9dILTGcFWArZISKPkGHHLW NumfBeS3oM5QrO/PNvQjEND7KRSzDi4Q0MFMJ/Yjku7d+Cj8SVqIjmPphMRq74jd0B 51jGalG2pyHLA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5E016100034; Sun, 1 Jun 2025 18:19:32 -0400 (EDT) Received: from alfajor (unknown [104.247.225.139]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2C6F41204C9; Sun, 1 Jun 2025 18:19:32 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions In-Reply-To: <86jz5wqbz4.fsf@gnu.org> Message-ID: References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> <868qmixead.fsf@gnu.org> <867c1xroil.fsf@gnu.org> <86jz5wqbz4.fsf@gnu.org> Date: Sun, 01 Jun 2025 18:19:31 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.334 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: brownts@troybrown.dev, 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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: > > =E2=80=98finished=E2=80=99 if text is now complete, = =E2=80=98sole=E2=80=99 if the > text cannot be further completed but completion is not > finished, or =E2=80=98exact=E2=80=99 if the text is a valid com= pletion 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 From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 01 18:41:05 2025 Received: (at 78489) by debbugs.gnu.org; 1 Jun 2025 22:41:05 +0000 Received: from localhost ([127.0.0.1]:43013 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLrMW-0007TO-GR for submit@debbugs.gnu.org; Sun, 01 Jun 2025 18:41:05 -0400 Received: from fhigh-a8-smtp.messagingengine.com ([103.168.172.159]:45401) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uLrMT-0007SJ-VI for 78489@debbugs.gnu.org; Sun, 01 Jun 2025 18:41:02 -0400 Received: from phl-compute-06.internal (phl-compute-06.phl.internal [10.202.2.46]) by mailfhigh.phl.internal (Postfix) with ESMTP id C35B0114014F; Sun, 1 Jun 2025 18:40:56 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Sun, 01 Jun 2025 18:40:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1748817656; x=1748904056; bh=puuCh4pZ37AqIXjJLy1yLsswvzo075SoLpn6geeUk/w=; b= gbVnMAgNSIkfntgtwsnmxY90i44mc3LiOC9KVtS7P5eG/86Dt1/6MZI0RNGRd+QK NQaGdSL0QkB9OEp6glkjlE8fXXTHVb+L92rkw+y6ZgRL9Jx2j6qPa4eML2MqMJPI Ks3H0BaGgltE9y3EMNrIo4Dt8Z5EQf5YQhyVL5lfiKCFFvB9v5hTJCp/cVI8XAHz obocidVxYoxic7ab//AJr37lpri+QZjrvwDdXCYpyJpI6QISmS/65AoRyJbpcvKn QSKihT1ToiYEchhED5Ha8pRs1wEXXgzS2uZ2bp+AuVoRQN7gWbQQ2qpSQhSoSv3i 7/B0jLsqCJj05ObDeFVo3g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1748817656; x= 1748904056; bh=puuCh4pZ37AqIXjJLy1yLsswvzo075SoLpn6geeUk/w=; b=B 7B3wbHnRYDOH/lt/geWznoNcfsYvo8A2loK+yXtssqhiIAAMv2MP8ochpL++Vpv2 mot3ngn/1d1nStg/mUIfDia1pw34214XfrQBBBgvSmniH5h44G+Qn/lMlf2cGJlV jebrnjddLr1vJZwbNxyYeatTWbz3y/GIx6VUrN+2RcQ0qkgwgoUJHaWUbirSM54S 9f0csiFgshQqmWb07WB8xmKp1ETjOwZnrfv0HXJs03q70O7edR8zLiKvAowETlz2 ZhGh/yJsE+P7jVtpw8XSScQnVCcQ2bY+VlOoSU/8a3dKKv6TdQ86XcWUF/Irbony MZRYIXtRUgSY+k7U1aVDg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdefiedtvdculddtuddrgeefvddrtd dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd dtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkffggfgfuvfev fhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoug hmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtthgvrhhnpeefkeehueetieeg veeltdejfeehfeehheejheekuefhfeefleevffelheefhfdvveenucffohhmrghinhepgh hithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthhopeefpd hmohguvgepshhmthhpohhuthdprhgtphhtthhopegsrhhofihnthhssehtrhhohigsrhho fihnrdguvghvpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohepje ekgeekleesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 1 Jun 2025 18:40:54 -0400 (EDT) Message-ID: Date: Mon, 2 Jun 2025 01:40:53 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions To: Troy Brown , Eli Zaretskii References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78489 Cc: 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 02:30:50 2025 Received: (at 78489) by debbugs.gnu.org; 2 Jun 2025 06:30:51 +0000 Received: from localhost ([127.0.0.1]:46553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLyh8-0008Cy-Gv for submit@debbugs.gnu.org; Mon, 02 Jun 2025 02:30:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59806) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uLyh5-0008CP-5g for 78489@debbugs.gnu.org; Mon, 02 Jun 2025 02:30:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uLygv-00059g-Hm; Mon, 02 Jun 2025 02:30:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=/q/8Ob+Q5SriczNMgqWHOLCIUlryH2vtV9PYxLtCqPU=; b=NnyGU2l5RRRgTcGAxNK7 ry2j8yCQN2xK1PPgYrN00S1ozGg4YA5vNuRW75EC5g9RJCjLGFsWabjVtBU5EdrxFyG4MSsFqhZPg UechzHxsHDOGFpOBCrCR0uVbbRBBWGvyGxJ1LK3HsHqskWEAyWQgqvkIuFfSuBJ/7TRT8pfdI4223 0Wa/m/QdP4x/qlgO6Jgm+j/DFObPZ9QIZxCWdyAPmC9qngQax8lfEt1CphCwSR4bcF77z22IcPAak WsOXZLeszmd2eJbIwD4xq7BbzpSchIqma9Xd0mrVM8ihokSnUY5PVcHcHAHCGJI6iTLwtm/I1d5xe 6a2pwG5pEq66tw==; Date: Mon, 02 Jun 2025 09:30:17 +0300 Message-Id: <86plfmpsee.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sun, 01 Jun 2025 18:19:31 -0400) Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> <868qmixead.fsf@gnu.org> <867c1xroil.fsf@gnu.org> <86jz5wqbz4.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: brownts@troybrown.dev, 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: brownts@troybrown.dev, 78489@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? From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 07 05:27:40 2025 Received: (at 78489) by debbugs.gnu.org; 7 Jun 2025 09:27:40 +0000 Received: from localhost ([127.0.0.1]:46941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uNpq0-0002WJ-2I for submit@debbugs.gnu.org; Sat, 07 Jun 2025 05:27:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44138) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uNppx-0002W0-E5 for 78489@debbugs.gnu.org; Sat, 07 Jun 2025 05:27:38 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uNppr-0001ac-Oy; Sat, 07 Jun 2025 05:27:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=InWG6kph3oJ36sbPI9bvz/5exc9Lw2pKVs6nDIfS6Vw=; b=B8qRa0X5BTu3 lhnH55/uoDaGuLa3sXRKyAKwLi0PxT04fW7C0ylEiUsb03gxumkOom055THzrOwrMniSnEeugS3gn BybCLOME1oa1cI2cPWJwwOYjVUIXoq0A3Q6WvHzvQxZXB3XjlsnQj5PFGfJ29yrc2pJDF4B+xQ0nP oUjkIc890DwYreyWiE49GSkwOcF0xtaSz5oQgz9KTkgHpH7yYMaBtME78OiHRQV39n3DMBIzorHwC BDuNP38A36WnFC6jxEyuz4hA0FCKzrjd7gdvnJxU8RW7Dm6uAHUMKkxKi1pJAQOreB9abPpnoQzHG 5z7wf2djqLCB8USUS5tVdw==; Date: Sat, 07 Jun 2025 12:27:30 +0300 Message-Id: <86cybfj3zx.fsf@gnu.org> From: Eli Zaretskii To: brownts@troybrown.dev, Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sun, 01 Jun 2025 18:19:31 -0400) Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> <868qmixead.fsf@gnu.org> <867c1xroil.fsf@gnu.org> <86jz5wqbz4.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: brownts@troybrown.dev, 78489@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. From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 22 18:35:31 2025 Received: (at 78489) by debbugs.gnu.org; 22 Jun 2025 22:35:31 +0000 Received: from localhost ([127.0.0.1]:49986 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uTTHd-0001Ur-Oi for submit@debbugs.gnu.org; Sun, 22 Jun 2025 18:35:31 -0400 Received: from m228-14.mailgun.net ([159.135.228.14]:36710) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uTTHa-0001Qf-0M for 78489@debbugs.gnu.org; Sun, 22 Jun 2025 18:35:27 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.troybrown.dev; q=dns/txt; s=mx; t=1750631714; x=1750638914; h=Content-Transfer-Encoding: Content-Type: Cc: To: To: Subject: Subject: Message-ID: Date: From: From: In-Reply-To: References: MIME-Version: Sender: Sender; bh=Nn+cA71nTkWgAFZ4gcTVAqPbi6KaHy+xl12o5fBe2jo=; b=OQPguINp+WtjyDv2ZigSfuuDU7q4qMAgeJPVxPhvLT1s2zWHt8ZtgC7YODh5Mqevfu1aTuEvpsFdYa/k0PoKL5GG3SNdkeTYYNq6mO51FkP2gykkqU27xmmRj5TQ7qF/TH+LayB5TjX9dcc5odOw5lcbK6G7Y0emsHTRNcXQ8RA= X-Mailgun-Sid: WyJiOTYxMCIsIjc4NDg5QGRlYmJ1Z3MuZ251Lm9yZyIsIjVmZDVkMiJd Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by 8146d92a4a3a with SMTP id 685885224ce52476f818a069 (version=TLS1.3, cipher=TLS_AES_128_GCM_SHA256); Sun, 22 Jun 2025 22:35:14 GMT X-Mailgun-Sending-Ip: 159.135.228.14 Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-606fdbd20afso6829560a12.1 for <78489@debbugs.gnu.org>; Sun, 22 Jun 2025 15:35:14 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUdltO0/VJmTvkNcdlbBd8rmswZBh3vx7zMvErgStBemSOz80RDkxl5oO1Wel7K3d/Eq24sVw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyNgN1OaMSD+fqSLO6szfvaQk2368a+KP1pUec3/cguQfTVSVAh 4a9pDb8LmBZD8uP3T1u9BAYbAyfSgArMBD9H7B8AtXqrGqOjvCJVHvQWuJFLVCIkUNcv3M6/kjb 3ACNYuvcTuVhp95gZaWlXcwlRKnboOVQ= X-Google-Smtp-Source: AGHT+IHarzuP7JRyO2M1IFp9DSXTdyU6XT5jyo8k4MLNtbXFSh/XmKcm/wEiMvpqHrmlgGm0mSA7eBMx/QtRBtJ22jo= X-Received: by 2002:a05:6402:5215:b0:609:7e19:f12a with SMTP id 4fb4d7f45d1cf-60a1cd1ce00mr9550336a12.18.1750631713200; Sun, 22 Jun 2025 15:35:13 -0700 (PDT) MIME-Version: 1.0 References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> <868qmixead.fsf@gnu.org> <867c1xroil.fsf@gnu.org> <86jz5wqbz4.fsf@gnu.org> <86cybfj3zx.fsf@gnu.org> In-Reply-To: <86cybfj3zx.fsf@gnu.org> From: Troy Brown Date: Sun, 22 Jun 2025 18:35:02 -0400 X-Gmail-Original-Message-ID: X-Gm-Features: AX0GCFv9ID0ekgQ4vHFUyucdVg3elemm0nQxdd9kEqQEY7HPU0t1vxqWKi7cs-0 Message-ID: Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78489 Cc: Stefan Monnier , 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Jun 7, 2025 at 5:27=E2=80=AFAM Eli Zaretskii wrote: > > > From: Stefan Monnier > > Cc: brownts@troybrown.dev, 78489@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. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 24 18:11:42 2025 Received: (at 78489) by debbugs.gnu.org; 24 Jun 2025 22:11:42 +0000 Received: from localhost ([127.0.0.1]:51890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUBri-0002XE-26 for submit@debbugs.gnu.org; Tue, 24 Jun 2025 18:11:42 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:27946) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uUBrf-0002WX-Nh for 78489@debbugs.gnu.org; Tue, 24 Jun 2025 18:11:40 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D5EBA1000BC; Tue, 24 Jun 2025 18:11:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1750803092; bh=BIgLgd/0EZ1ClghYX/KGv41uRaHSBgrWTPfGb7vh3PU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=f6ogMddCP/zNLMIzlhboGykeemKw2Tm1V9G3UZuYqywjq4s/qHNLMgoqiXecvZQaP StuHzICLJWxrMdiHH1DloycHFHA1/Cya0K6WQvrsg6qVTyiHoLET60Ck2HYDSCyH3O QsZYEEUqJjBDJM7wvOtG7voe6vR7gFNYyOyHNgIjqodJmOiyIIgYAS5g18JwIdjQE2 UdR0iRNWG5WIjz+xFz3On3XSGv6O6AamqH6pZgp+Ff0yk7YfN4fZ3IdLDvNp/MDVd6 DoXUTC8765WqVsMDmKChv96bf+nRw4EWWHyH7gVUxl3wwcaN/QtOh2/unqeby+EyLd Jdbs2GZlBuFvw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D4847100029; Tue, 24 Jun 2025 18:11:32 -0400 (EDT) Received: from pastel (unknown [104.247.225.139]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A2E0C120406; Tue, 24 Jun 2025 18:11:32 -0400 (EDT) From: Stefan Monnier To: Troy Brown Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions In-Reply-To: Message-ID: References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> <868qmixead.fsf@gnu.org> <867c1xroil.fsf@gnu.org> Date: Tue, 24 Jun 2025 18:11:31 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.313 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: Eli Zaretskii , 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 05 03:59:15 2025 Received: (at 78489) by debbugs.gnu.org; 5 Jul 2025 07:59:15 +0000 Received: from localhost ([127.0.0.1]:39352 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uXxnm-0005um-J5 for submit@debbugs.gnu.org; Sat, 05 Jul 2025 03:59:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44802) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uXxnj-0005ta-P7 for 78489@debbugs.gnu.org; Sat, 05 Jul 2025 03:59:12 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uXxnc-0003y0-Ct; Sat, 05 Jul 2025 03:59:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Em0Oi7Fk0S3ftbWgCW5/w/SHREdTdYlIKygM30vpfg8=; b=GP8XLsGEThda 0AgEruPRwvhYffVrVXeEuqy4T9B5eboNniduwzpNpV9FaOJmMjgJSWAUjSyjPR/bm+K+WlFH9s5yy /OKShzdXIQjyp4TiV5KgeZMIvKWLz5fWbZOpYGgOOanydi5Sxa33IWTQoovRPUetV3O66bwgY7h3l LSf4VfDFkmpak80H/YbaKW8NbDzN8MD71SB+Khf6HsRwAyGkdjVnKqEhPm6HnqT+haCDAsCXgqzOQ DqbGVqd9e/m+lP748sNwHpTS1Xn/VPkWWlDv9e++yxtHYFlGHqBy21xPqzMbK0VdvGfp2EXAI1T89 2UeS3gowp2VINRL/DN56jA==; Date: Sat, 05 Jul 2025 10:59:00 +0300 Message-Id: <86plefvzjv.fsf@gnu.org> From: Eli Zaretskii To: brownts@troybrown.dev, Stefan Monnier In-Reply-To: (message from Stefan Monnier on Tue, 24 Jun 2025 18:11:31 -0400) Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> <868qmixead.fsf@gnu.org> <867c1xroil.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Eli Zaretskii , 78489@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? From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 10 21:26:59 2025 Received: (at 78489) by debbugs.gnu.org; 11 Jul 2025 01:26:59 +0000 Received: from localhost ([127.0.0.1]:60824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ua2XR-0002f4-C8 for submit@debbugs.gnu.org; Thu, 10 Jul 2025 21:26:59 -0400 Received: from k3.kb8c70eb.use4.send.mailgun.net ([204.220.184.3]:32082) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ua2XN-0002dx-V8 for 78489@debbugs.gnu.org; Thu, 10 Jul 2025 21:26:55 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.troybrown.dev; q=dns/txt; s=mx; t=1752197202; x=1752204402; h=Content-Transfer-Encoding: Content-Type: Cc: To: To: Subject: Subject: Message-ID: Date: From: From: In-Reply-To: References: MIME-Version: Sender: Sender; bh=9TESYckCnDzNKcKVDFcODEiZADuQi6qVZUWVhUQ/dmE=; b=Ks86nfL0pNckUCQFNIYz4+EzuWTC0mdYBy4cXSAPvnfoDe8tcIoe3zpcZxiVHnLvH41U67FV1zSx/eFuP+qlcjwNXjSObss/7DVbtP7R7+VL3feMe1pwYsN3XwaeYWdamJu2P7dwRyrznLGcFcWg65ttUbOljV5lA/v+pMFwOdo= X-Mailgun-Sid: WyJiOTYxMCIsIjc4NDg5QGRlYmJ1Z3MuZ251Lm9yZyIsIjVmZDVkMiJd Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by ac4e9463350b with SMTP id 68706852d92a29dcea4faa69 (version=TLS1.3, cipher=TLS_AES_128_GCM_SHA256); Fri, 11 Jul 2025 01:26:42 GMT X-Mailgun-Sending-Ip: 204.220.184.3 Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-606b58241c9so2542454a12.3 for <78489@debbugs.gnu.org>; Thu, 10 Jul 2025 18:26:42 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVJme/AFIVNT8cZVxVQfJS8YqRdAKSFMJC57BYoUcUjySIHvRoh378W7tMKQ2+zKSU35LiJRg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxkVzYGkxcSSVQa6Ii6GtxFbXWB9wzjxjbBZnHFb60PdfSXj6O0 pJd8YbVE0drnek5sF7pVo+TuSeDVjMj8eODMfs6z1pr/BnoFkGmpjame8N8e1pzjpNOKqr37LNd 32Wr3fCDCzp8jlBrS9ODRUc17Oo1SJUY= X-Google-Smtp-Source: AGHT+IGQkiSyh8zAAZILT7jxUGZ/XEOQxvP2TlKDvXu8B7AT0UFtMJE7Gm3aOAo9/EVQbIcjp3ygpcNwkxbIvXp0z1U= X-Received: by 2002:a05:6402:5243:b0:607:7851:33b4 with SMTP id 4fb4d7f45d1cf-611e760dee6mr1104086a12.7.1752197201302; Thu, 10 Jul 2025 18:26:41 -0700 (PDT) MIME-Version: 1.0 References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> <868qmixead.fsf@gnu.org> <867c1xroil.fsf@gnu.org> <86plefvzjv.fsf@gnu.org> In-Reply-To: <86plefvzjv.fsf@gnu.org> From: Troy Brown Date: Thu, 10 Jul 2025 21:26:30 -0400 X-Gmail-Original-Message-ID: X-Gm-Features: Ac12FXyh17ZImeM-4yv3vG44gattnMRNvhGWBP1rBk2ff56ua8Qto8ySekzae2U Message-ID: Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78489 Cc: Stefan Monnier , 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Jul 5, 2025 at 3:59=E2=80=AFAM Eli Zaretskii wrote: > > > From: Stefan Monnier > > Cc: Eli Zaretskii , 78489@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" informatio= n > > > 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 fo= r > > 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 fo= r > > 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 mak= e > > it non-specific to Ada. To reduce the cost of your wrapper, we could u= se > > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 11 02:49:57 2025 Received: (at 78489) by debbugs.gnu.org; 11 Jul 2025 06:49:57 +0000 Received: from localhost ([127.0.0.1]:34122 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ua7a1-0008I6-66 for submit@debbugs.gnu.org; Fri, 11 Jul 2025 02:49:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58714) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ua7Zw-0008Hm-QD for 78489@debbugs.gnu.org; Fri, 11 Jul 2025 02:49:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ua7Zq-0007Xf-Lq; Fri, 11 Jul 2025 02:49:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=I5BpIKqcuP+vwXAysa6TDRxc4uh7dWrCohShEZMJN78=; b=LfWsbTKh34MZhq1FzGad /5qZHjpcfDJV1qrOEYr/QpayuRjSMwzz9KQ5L23wYP0Lk15L9o1N36us+0qboiIlXLmIjqdr18RBo Eylt62gfDwEnsvfofQ/oukM0wtI7LnxITUkO86HIlYcTdwCKtHKCH07pW2Q88YoagqPufDZ0ObuzV no2Gjg5nufYOJmMWaAFQe1qKSAOjE+nal7OaRGAytNBieKqH0XSYQKG+sMoquKoIkL5RDTtcZG9Zj ZIUwVifVR4g2UZCu6A7C3y7cHxb2UvB4eIK07jpKq8t+kCcOWYvj8TVf1KhNSMcPCWpUgS8fuTzrF cW8/E5RmiahAiA==; Date: Fri, 11 Jul 2025 09:49:44 +0300 Message-Id: <86bjprgr1z.fsf@gnu.org> From: Eli Zaretskii To: Troy Brown In-Reply-To: (message from Troy Brown on Thu, 10 Jul 2025 21:26:30 -0400) Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> <868qmixead.fsf@gnu.org> <867c1xroil.fsf@gnu.org> <86plefvzjv.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: monnier@iro.umontreal.ca, 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Troy Brown > Date: Thu, 10 Jul 2025 21:26:30 -0400 > Cc: Stefan Monnier , 78489@debbugs.gnu.org > > On Sat, Jul 5, 2025 at 3:59 AM Eli Zaretskii wrote: > > > > > From: Stefan Monnier > > > Cc: Eli Zaretskii , 78489@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? From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 14 07:53:21 2025 Received: (at 78489) by debbugs.gnu.org; 14 Jul 2025 11:53:21 +0000 Received: from localhost ([127.0.0.1]:60287 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ubHkG-0006m1-Pe for submit@debbugs.gnu.org; Mon, 14 Jul 2025 07:53:21 -0400 Received: from k45.kb8c70eb.use4.send.mailgun.net ([204.220.184.45]:58164) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ubHkB-0006lG-TM for 78489@debbugs.gnu.org; Mon, 14 Jul 2025 07:53:17 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.troybrown.dev; q=dns/txt; s=mx; t=1752493983; x=1752501183; h=Content-Transfer-Encoding: Content-Type: Cc: To: To: Subject: Subject: Message-ID: Date: From: From: In-Reply-To: References: MIME-Version: Sender: Sender; bh=oRqidB8KM2w0Iox701qZLNxeOtsxWbhQ3wf9Z4V8ubs=; b=i9L/bVtK04rauWlhq1n0bQ9smzSTTQV5qFGlQS5PcpTafnrFPcslMh3202jyk27NraOVpQhTF1zTZ+EcG6YyLIV//WSktbkT11ckeg3/HawaDjScvQhAJvaZjIv3+WrS/zPX39abYz9aLqbBFVwv/xLBWGlKII3A0pUSEvr4M90= X-Mailgun-Sid: WyJiOTYxMCIsIjc4NDg5QGRlYmJ1Z3MuZ251Lm9yZyIsIjVmZDVkMiJd Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) by c413be73c221 with SMTP id 6874ef9fbb7e0feeda884ca0 (version=TLS1.3, cipher=TLS_AES_128_GCM_SHA256); Mon, 14 Jul 2025 11:53:03 GMT X-Mailgun-Sending-Ip: 204.220.184.45 Received: by mail-ej1-f54.google.com with SMTP id a640c23a62f3a-ae36dc91dc7so730859766b.2 for <78489@debbugs.gnu.org>; Mon, 14 Jul 2025 04:53:03 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCX4Wg48rncmDYGYTkTq3CNMaKQAQ1CMl6PquH7emCkLoXcag3esdXwRMzrl/PHQPqGHVgeSUA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwnYkReyTDRSnQi2XfFzr4lrUZfQGy7E2dNjnxfGoJHKTNXKMKK sB8fK+/wWZQnmAXC6gbw5TBZPDa3a5k3EIBNLAk5wNSxFL4EnPlFXxAkf2gucMiuVrqwEjlZMNz uYVr/aV2lBQTaEcnJeVl6AT6m1HJGzgM= X-Google-Smtp-Source: AGHT+IEIXbB/A4SH/UOp3vfZBL8vOcTQ7rC4oIze+nZFixqH181M80Cs8JfrOzsAOG+GjwVVMtPbYKrPbQ8ncgI2MMY= X-Received: by 2002:a17:906:f59f:b0:ae3:5be2:d9e8 with SMTP id a640c23a62f3a-ae6fc6f5e4amr1454959366b.18.1752493982417; Mon, 14 Jul 2025 04:53:02 -0700 (PDT) MIME-Version: 1.0 References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> <868qmixead.fsf@gnu.org> <867c1xroil.fsf@gnu.org> <86plefvzjv.fsf@gnu.org> <86bjprgr1z.fsf@gnu.org> In-Reply-To: <86bjprgr1z.fsf@gnu.org> From: Troy Brown Date: Mon, 14 Jul 2025 07:52:50 -0400 X-Gmail-Original-Message-ID: X-Gm-Features: Ac12FXzbEPi9H-oPKAXNga2olzwWJo1YmyzJuV0Ccy5shWuWNZ7gyIWtvoHohUw Message-ID: Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78489 Cc: monnier@iro.umontreal.ca, 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Jul 11, 2025 at 2:49=E2=80=AFAM Eli Zaretskii wrote: > > > From: Troy Brown > > Date: Thu, 10 Jul 2025 21:26:30 -0400 > > Cc: Stefan Monnier , 78489@debbugs.gnu.org > > > > On Sat, Jul 5, 2025 at 3:59=E2=80=AFAM Eli Zaretskii wro= te: > > > > > > > From: Stefan Monnier > > > > Cc: Eli Zaretskii , 78489@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 gene= rate > > > > > 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" inform= ation > > > > > too. This solution seems to be working well for me. > > > > > > > > That seems like a much better solution than my exit-function, indee= d. > > > > > > > > I suggest adding it to `ada-mode` plus adding to `etag.el` a commen= t > > > > pointing to that ada-mode` code. > > > > > > > > The `etags.el` comment is because `etags.el` now has partial suppor= t 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 use= d for > > > > any language, so it could make sense in the future to move your cod= e > > > > 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 cou= ld 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 2= 7). - 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 14 09:13:41 2025 Received: (at 78489) by debbugs.gnu.org; 14 Jul 2025 13:13:41 +0000 Received: from localhost ([127.0.0.1]:60572 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ubJ00-0003MT-RI for submit@debbugs.gnu.org; Mon, 14 Jul 2025 09:13:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34292) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ubIzx-0003Ld-RW for 78489@debbugs.gnu.org; Mon, 14 Jul 2025 09:13:38 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ubIzr-0006FY-IR; Mon, 14 Jul 2025 09:13:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=nqNdiKlkIIvA1yFZPxYeUE4ZJ2ox0XQ/ZTCgjQ6WPK4=; b=WrOfY1fc0RGruIGCgD73 0EJVP4OXhLif1NdoXuoLcsy/4MhId+rPSAxp+BE0ownY+zChMsX5+hr1d1kw+n6kmz+UM4RIqhF4F vFOZ6NktHyljHHFDn6Sqgzo5wgAyMsf0w6XvICrTGwmPpzsXmpiwnC34QrIQbqylTfNl1Xf5TcUnb K5VmtZWC85SMcgBi2ZtBE0Iw8IPCo1aYRAuSu/a9GqrdX1RG7jLam7e/OyhT2Tgd1+SyByrt6u/qh fKLkcxW2Men2iF0JuwiXNst240usyMkX1ly6L695SUVnapZ86HA0LeaNaZ7qyqldFEx1Ey/kd0AOL qXtI0PD8kPqTpQ==; Date: Mon, 14 Jul 2025 16:13:00 +0300 Message-Id: <86wm8ac3vn.fsf@gnu.org> From: Eli Zaretskii To: Troy Brown In-Reply-To: (message from Troy Brown on Mon, 14 Jul 2025 07:52:50 -0400) Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> <868qmixead.fsf@gnu.org> <867c1xroil.fsf@gnu.org> <86plefvzjv.fsf@gnu.org> <86bjprgr1z.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: monnier@iro.umontreal.ca, 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Troy Brown > Date: Mon, 14 Jul 2025 07:52:50 -0400 > Cc: monnier@iro.umontreal.ca, 78489@debbugs.gnu.org > > On Fri, Jul 11, 2025 at 2:49 AM Eli Zaretskii 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 26 15:11:49 2025 Received: (at 78489) by debbugs.gnu.org; 26 Jul 2025 19:11:49 +0000 Received: from localhost ([127.0.0.1]:45110 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ufkJA-0000Uo-Oa for submit@debbugs.gnu.org; Sat, 26 Jul 2025 15:11:49 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7987) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ufkJ8-0000UJ-QM for 78489@debbugs.gnu.org; Sat, 26 Jul 2025 15:11:47 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0160E44130B; Sat, 26 Jul 2025 15:11:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1753557099; bh=MNz5OHOA44opwT6xFfrFCmsljlvHBW23Pe49pjk0Uks=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=leLKpscLpaU6OA+fiQL+CIrxusyKSgR+164S+b0r+KLNpOZrwB3syBr9TGqoKDzGr 3JvImO56qTxYdzcXQkNtJ2hGC66xEtCh9BgV69GkU3ZcLgvR3pk3mc0+d4dfFF+3JE pLs/KvshstjDii2j0qVoIz/q3MdvXdor3OA+RWkcK6OBE8e5/xC7HYTIAJuWJtGQE6 NSz3ofuW9VcZ9abNT9kwQkYZ9LH2IPKfEa8DP18gRzbO8zqs5WiT6+eWdPxG0J9d+t B7aCcJkw6nJ2qJjFpDOb0plwDnBeYuSi0N8lfe2rvwRDTRZVuUAT7M+ajfTJvhO4vv j0yT0d039MDFQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 89D084411BE; Sat, 26 Jul 2025 15:11:39 -0400 (EDT) Received: from pastel (unknown [104.247.225.139]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 57A5C120B01; Sat, 26 Jul 2025 15:11:39 -0400 (EDT) From: Stefan Monnier To: Troy Brown Subject: Re: bug#78489: 30.1.50; Using etags, Ada and xref-find-definitions doesn't find definitions In-Reply-To: Message-ID: References: <86zff46fw5.fsf@gnu.org> <86msayxqx0.fsf@gnu.org> <86bjrexmzj.fsf@gnu.org> <868qmixead.fsf@gnu.org> <867c1xroil.fsf@gnu.org> <86plefvzjv.fsf@gnu.org> Date: Sat, 26 Jul 2025 15:11:38 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.269 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78489 Cc: Eli Zaretskii , 78489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> 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@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