GNU logs - #28407, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#28407: 26.0.50; xref should use imenu
Resent-From: Tom Tromey <tom@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 10 Sep 2017 16:25:01 +0000
Resent-Message-ID: <handler.28407.B.150506064912621 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 28407 <at> debbugs.gnu.org
From: Tom Tromey <tom@HIDDEN>
Date: Sun, 10 Sep 2017 10:23:35 -0600
Message-ID: <87h8wa8quw.fsf@bapiya>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>


It would be nice if imenu were a back end for xref.
Then M-. could also use symbols found by imenu.

A further wrinkle on this would be if xref, project, and imenu worked
together, so that M-. would automatically know to look at imenu results
for other buffers in the same project.

Tom



In GNU Emacs 26.0.50 (build 18, x86_64-pc-linux-gnu, GTK+ Version 3.22.17)
 of 2017-09-09 built on bapiya
Repository revision: 4131f9785e30f2a31745125c714e922892113c62
Windowing system distributor 'Fedora Project', version 11.0.11903000
System Description:	Fedora release 25 (Twenty Five)

Recent messages:
Hunk already applied [3 times]
Mark saved where search started
user-error: No definitions found for: funlike_invocation_p
Quit
M-. runs the command xref-find-definitions
Type "q" in help window to restore its previous buffer.
uncompressing xref.el.gz...done
Mark saved where search started
uncompressing imenu.el.gz...done
Mark saved where search started [2 times]

Configured using:
 'configure --prefix=/home/tromey/Emacs/install'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LANG: en_US.utf8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
  shell-dirtrack-mode: t
  diff-auto-refine-mode: t
  flyspell-mode: t
  which-function-mode: t
  erc-services-mode: t
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-match-mode: t
  erc-netsplit-mode: t
  erc-hl-nicks-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  savehist-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  auto-fill-function: do-auto-fill
  transient-mark-mode: t

Load-path shadows:
/home/tromey/.emacs.d/elpa/bubbles-0.5/bubbles hides /home/tromey/Emacs/install/share/emacs/26.0.50/lisp/play/bubbles

Features:
(shadow emacsbug make-mode cc-awk texinfo log-edit cl-print debug nndoc
gnus-dup debbugs-gnu debbugs soap-client url-http url-auth url-gw
rng-xsd rng-dt rng-util xsd-regexp smerge-mode whitespace gnus-html
url-queue help-fns radix-tree url-cache mm-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf goto-addr
log-view pcvs-util term/xterm xterm shell find-file copyright pulse
etags xref project vc-mtn vc-hg vc-bzr vc-src vc-sccs vc-svn vc-cvs
vc-rcs jka-compr shr-color url-util shr svg xml dom browse-url
find-dired add-log misearch multi-isearch bug-reference vc-git diff-mode
map cc-mode cc-fonts cc-guess cc-menus cc-cmds dabbrev supercite
easy-mmode regi mail-hist nnir flow-fill mm-archive mailalias sort
smiley gnus-cite gnus-async gnus-bcklg mail-extr gnus-ml disp-table
gnus-topic nndraft nnmh nnfolder utf-7 network-stream nsm starttls
gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg nntp
gnus-cache gnus-registry registry ebdb-gnus gnus-art mm-uu mml2015
mm-view mml-smime smime dig mailcap gnus-sum gnus-group gnus-undo
smtpmail gnus-start gnus-cloud nnimap nnmail mail-source tls gnutls utf7
netrc nnoo parse-time gnus-spec gnus-int gnus-range gnus-win gnus
nnheader elec-pair flyspell ispell diminish edmacro kmacro projectile
grep compile ibuf-ext ibuffer ibuffer-loaddefs dash appt diary-lib
diary-loaddefs which-func imenu minimap autorevert filenotify cus-start
cus-load status erc-services erc-list erc-menu erc-join erc-ring
erc-networks erc-pcomplete pcomplete erc-track erc-match erc-netsplit
erc-hl-nicks color erc-button erc-fill erc-stamp wid-edit erc-goodies
erc erc-backend erc-compat thingatpt pp warnings advice vc-dir ewoc vc
vc-dispatcher cc-styles cc-align cc-engine cc-vars cc-defs ebdb-complete
ebdb-message sendmail message puny dired dired-loaddefs format-spec
rfc822 mml mml-sec epa derived epg gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mail-utils gmm-utils mailheader ebdb-mua ebdb-com
crm mailabbrev ebdb-format qp ebdb cl-extra help-mode eieio-opt speedbar
sb-image ezimage dframe find-func eieio-base pcase subr-x cal-menu
calendar cal-loaddefs timezone ange-ftp comint ansi-color ring server
savehist finder-inf dwarf-mode-autoloads gdb-shell-autoloads
lisppaste-autoloads pydoc-info-autoloads info-look cl
weblogger-autoloads info package easymenu epg-config url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache url-vars seq byte-opt gv bytecomp byte-compile cconv
cl-loaddefs cl-lib time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind inotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 2205844 699201)
 (symbols 48 58822 76)
 (miscs 40 16108 11738)
 (strings 32 597642 63371)
 (string-bytes 1 15642233)
 (vectors 16 252143)
 (vector-slots 8 3921716 191337)
 (floats 8 4806 1815)
 (intervals 56 142400 1766)
 (buffers 992 191))

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Tom Tromey <tom@HIDDEN>
Subject: bug#28407: Acknowledgement (26.0.50; xref should use imenu)
Message-ID: <handler.28407.B.150506064912621.ack <at> debbugs.gnu.org>
References: <87h8wa8quw.fsf@bapiya>
X-Gnu-PR-Message: ack 28407
X-Gnu-PR-Package: emacs
Reply-To: 28407 <at> debbugs.gnu.org
Date: Sun, 10 Sep 2017 16:25:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 28407 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
28407: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D28407
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#28407: 26.0.50; xref should use imenu
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 10 Sep 2017 21:37:02 +0000
Resent-Message-ID: <handler.28407.B28407.15050793658182 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Tom Tromey <tom@HIDDEN>, 28407 <at> debbugs.gnu.org
References: <87h8wa8quw.fsf@bapiya>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN>
Date: Mon, 11 Sep 2017 00:35:56 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101
 Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: <87h8wa8quw.fsf@bapiya>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
 
 Content preview:  On 9/10/17 7:23 PM, Tom Tromey wrote: > > It would be nice
    if imenu were a back end for xref. > Then M-. could also use symbols found
    by imenu. > > A further wrinkle on this would be if xref, project, and imenu
    worked > together, so that M-. would automatically know to look at imenu
   results > for other buffers in the same project. [...] 
 
 Content analysis details:   (2.2 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  1.5 RCVD_IN_SORBS_WEB      RBL: SORBS: sender is an abusable web server
                             [178.252.127.239 listed in dnsbl.sorbs.net]
  0.5 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
                             [209.85.215.41 listed in dnsbl.sorbs.net]
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
                             [209.85.215.41 listed in wl.mailspike.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
                             trust
                             [209.85.215.41 listed in list.dnswl.org]
  0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail
                             domains are different
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail provider
                             (dgutov[at]yandex.ru)
  0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid
  0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom
                              freemail headers are different
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders

On 9/10/17 7:23 PM, Tom Tromey wrote:
> 
> It would be nice if imenu were a back end for xref.
> Then M-. could also use symbols found by imenu.
> 
> A further wrinkle on this would be if xref, project, and imenu worked
> together, so that M-. would automatically know to look at imenu results
> for other buffers in the same project.

Agreed. It could be a nice default for when no tags table is currently 
visited.

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#28407: 26.0.50; xref should use imenu
Resent-From: Visuwesh <visuweshm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 15 May 2022 12:34:01 +0000
Resent-Message-ID: <handler.28407.B28407.16526179953811 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Tom Tromey <tom@HIDDEN>, 28407 <at> debbugs.gnu.org
From: Visuwesh <visuweshm@HIDDEN>
In-Reply-To: <3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN> (Dmitry Gutov's
 message of "Mon, 11 Sep 2017 00:35:56 +0300")
Date: Sun, 15 May 2022 18:02:14 +0530
Lines: 151
References: <87h8wa8quw.fsf@bapiya>
 <3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
Message-ID: <87y1z35630.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[=E0=AE=A4=E0=AE=BF=E0=AE=99=E0=AF=8D=E0=AE=95=E0=AE=B3=E0=AF=8D =E0=AE=9A=
=E0=AF=86=E0=AE=AA=E0=AF=8D=E0=AE=9F=E0=AE=AE=E0=AF=8D=E0=AE=AA=E0=AE=B0=E0=
=AF=8D 11, 2017] Dmitry Gutov wrote:

> On 9/10/17 7:23 PM, Tom Tromey wrote:
>> It would be nice if imenu were a back end for xref.
>> Then M-. could also use symbols found by imenu.
>> A further wrinkle on this would be if xref, project, and imenu
>> worked
>> together, so that M-. would automatically know to look at imenu results
>> for other buffers in the same project.
>
> Agreed. It could be a nice default for when no tags table is currently
> visited.

I tried to write a general imenu backend in attached file (extracted
from my init.el) but I hit quite a few roadblocks,

  1. I activate the imenu backend iff there are no tags table defined
     for the buffer but this means that one cannot use the imenu
     backend to jump to definitions for symbols that TAGS do not know
     of currently.  I can think of two ways to solve this problem,

     (a) Check if the symbol is in TAGS table.
     (b) Modify the etags backend so that the user can say "I have no
     TAGS table for this file/project/whatever."

     (a) is definitely not clean, and (b) sounds feasible but similar
     situation can also exist with other backends (like elisp).

     I'm lost on how to solve this problem.

  2. I have not defined all the methods and the completion-table does
     not handle the nested case of the index alist.  AFAIU from `(elisp)
     Programmed Completion', completion "ends" when `try-completion'
     returns t but I seem to be mistaken.  I have to rewrite
     completion-table to be like `imenu--completion-buffer' but I don't
     know how to pull that off.

  3. `imenu-xref--in-alist' is mostly a 1-1 copy of `imenu--in-alist'
     with the only difference being my function returns all matches of
     the symbol instead of just the first one.  This should be easy
     enough to fix by adding an optional argument INCLUDE-ALL to
     `imenu--in-alist'.

I'm testing in python-mode with the following settings,

    (setq imenu-name-lookup-function (lambda (symbol item) (string-prefix-p=
 symbol item))
          python-imenu-format-parent-item-jump-label-function (lambda (_ na=
me) name))


--=-=-=
Content-Type: application/emacs-lisp
Content-Disposition: attachment; filename=imenu-xref.el
Content-Transfer-Encoding: quoted-printable

(defun imenu-xref-backend ()
  (when (not tags-table-files)
    'imenu))

(cl-defmethod xref-backend-identifier-at-point ((_backend (eql 'imenu)))
  (or (thing-at-point 'symbol)
      (find-tag--default)))

(defun imenu-xref--in-alist (symbol alist)
  "Find all positions that match SYMBOL in the imenu index ALIST."
  (let (elt head tail res)
    (while alist
      (setq elt (car alist)
	        tail (cdr elt)
	        alist (cdr alist)
	        head (car elt))
      ;; A nested ALIST element looks like
      ;;   (INDEX-NAME (INDEX-NAME . INDEX-POSITION) ...)
      ;; while a bottom-level element looks like
      ;;   (INDEX-NAME . INDEX-POSITION)
      ;; or
      ;;   (INDEX-NAME INDEX-POSITION FUNCTION ARGUMENTS...)
      ;; We are only interested in the bottom-level elements, so we need to
      ;; recurse if TAIL is a nested ALIST.
      (cond ((imenu--subalist-p elt)
	         (when-let ((item (imenu-xref--in-alist symbol tail)))
               (if (listp item)
                   (setq res (append res item))
                 (push item res))))
	        ((if imenu-name-lookup-function
                 (funcall imenu-name-lookup-function symbol head)
               (equal symbol head))
	         (push elt res))))
    res))

(defun imenu-xref--make-summary (sym marker)
  (with-current-buffer (marker-buffer marker)
    (save-excursion
      (goto-char marker)
      (back-to-indentation)
      (buffer-substring (point) (point-at-eol)))))

(cl-defmethod xref-backend-definitions ((_backend (eql 'imenu)) symbol)
  (unless imenu--index-alist
    (imenu--make-index-alist))
  (let ((res (imenu-xref--in-alist symbol imenu--index-alist))
        defs)
    (pcase-dolist (`(,sym . ,m) res)
      (push (xref-make (imenu-xref--make-summary sym m)
                       (xref-make-buffer-location (marker-buffer m) (marker=
-position m)))
            defs))
    defs))

(cl-defmethod xref-backend-identifier-completion-ignore-case ((_backend (eq=
l 'imenu)))
  completion-ignore-case)

(defun imenu-xref--flatten (alist &optional prefix)
  (let (res)
    (dolist (item alist)
      (if (imenu--subalist-p (cdr item))
          (setq res (append res (imenu-xref--flatten
                                 (cdr item)
                                 (concat prefix (when prefix imenu-level-se=
parator) (car item)))))
        (push (cons (concat prefix (when prefix imenu-level-separator) (car=
 item))
                    (cdr item))
              res)))
    res))

(cl-defmethod xref-backend-identifier-completion-table ((_backend (eql 'ime=
nu)))
  (unless imenu--index-alist
    (imenu--make-index-alist))
  (let ((collection (imenu-xref--flatten imenu--index-alist)))
    (lambda (string pred action)
      (cond
       ((null action)
        (if-let* ((completion (try-completion string collection pred))
                  ((eq t completion)))
            (string-trim-left string ".+:")
          completion))
       (t (complete-with-action action collection string pred))))))

(add-hook 'xref-backend-functions #'imenu-xref-backend)

--=-=-=--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#28407: 26.0.50; xref should use imenu
Resent-From: Visuwesh <visuweshm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 16 May 2022 07:01:01 +0000
Resent-Message-ID: <handler.28407.B28407.165268443727537 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 28407
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Tom Tromey <tom@HIDDEN>, 28407 <at> debbugs.gnu.org
Received: via spool by 28407-submit <at> debbugs.gnu.org id=B28407.165268443727537
          (code B ref 28407); Mon, 16 May 2022 07:01:01 +0000
Received: (at 28407) by debbugs.gnu.org; 16 May 2022 07:00:37 +0000
Received: from localhost ([127.0.0.1]:51521 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nqUia-0007A5-IE
	for submit <at> debbugs.gnu.org; Mon, 16 May 2022 03:00:36 -0400
Received: from mail-pj1-f68.google.com ([209.85.216.68]:38428)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <visuweshm@HIDDEN>) id 1nqUiY-00079m-9V
 for 28407 <at> debbugs.gnu.org; Mon, 16 May 2022 03:00:34 -0400
Received: by mail-pj1-f68.google.com with SMTP id
 o13-20020a17090a9f8d00b001df3fc52ea7so2589584pjp.3
 for <28407 <at> debbugs.gnu.org>; Mon, 16 May 2022 00:00:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version;
 bh=PA8gUUXaHjJ9Hw3bhPOtVi3/LL3wEkIjYiz1x+TYNyc=;
 b=CjZIEAxu+3wskmq+XkNJ/MwEm8qN6l3BusYu255XsHtFCzrzLOcxArgeZEWdJZOL7i
 1+G6SvzxfZ2DUycDe3uD+2ZdRaFCb2BvaUic28GZLmzMzxw/VR3P7As4CSzG0qK9aa75
 uFGwj9TMLAuvxzKHOmKeYbRuiBxGWMh/2anjBS1SNidfW+Yq4icZOovjasoqD5grINva
 kPaTo60MUmbJwllmYusZPejsTnNZkKSGTHasvCgflCPgbWJxumTPwBMvDJJUCzkgIKPe
 +kMaDNwOVUS0u22xhhy4MS6BRMfn19KbtMN9bD+oovvqluoCouP549AOlnQIlCt2Ajwq
 p+SQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version;
 bh=PA8gUUXaHjJ9Hw3bhPOtVi3/LL3wEkIjYiz1x+TYNyc=;
 b=N5q6UCTZl0m6URY3YjK0mvSYWd2oc5pWEksxFsVv8s0WR5/f78OAARIZUv/ViIyfk+
 Ts+JDfiXVQYWq+tSq90QOgPib3xzx21vJvmZpefnA5AHQl4/b2uszhbQP0chgh0eS77G
 7LCEoKlCtU0ZhXoNq17KE0FJCxjybT+5T7vuDy02Qq65pUIHKS67bcUNzmgo49c0KaRK
 t039P0u7Yh2CP+XaI+FvESsf0FB0F/Yg9j7fU3Z3ZD1dmgjEdZrWdpyeqkzYHLbUegZT
 fN2YHbjzbfwS8FRVeh2WpycSEbMbKMqDvQ/HzLzE2uagVfHO9zEMtR0lBtdgFMUQLeWF
 NbCg==
X-Gm-Message-State: AOAM530YmETZqogtPfsJMfeLIeiBlYufkRSmsZ13/SAWVshplgXrkrGq
 TGCZ6EzjzxXYJkyhKXX2Sjs=
X-Google-Smtp-Source: ABdhPJyS3+bJXlDaTuAvWLBsBdSrBQDctPJV0vwVarfK81Cg5yXFdlXyB/lv9ReCwP7/ror1Q8cOxQ==
X-Received: by 2002:a17:903:124a:b0:154:c7a4:9374 with SMTP id
 u10-20020a170903124a00b00154c7a49374mr16178227plh.68.1652684428154; 
 Mon, 16 May 2022 00:00:28 -0700 (PDT)
Received: from localhost ([49.205.85.27]) by smtp.gmail.com with ESMTPSA id
 cs14-20020a17090af50e00b001d75aabe050sm5735441pjb.34.2022.05.16.00.00.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 16 May 2022 00:00:27 -0700 (PDT)
From: Visuwesh <visuweshm@HIDDEN>
References: <87h8wa8quw.fsf@bapiya>
 <3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN>
 <87y1z35630.fsf@HIDDEN>
Date: Mon, 16 May 2022 12:29:58 +0530
In-Reply-To: <87y1z35630.fsf@HIDDEN> (Visuwesh's message of "Sun, 15 May
 2022 18:02:14 +0530")
Message-ID: <87zgjic68h.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

[=E0=AE=9E=E0=AE=BE=E0=AE=AF=E0=AE=BF=E0=AE=B1=E0=AF=81 =E0=AE=AE=E0=AF=87 =
15, 2022] Visuwesh wrote:

> [=E0=AE=A4=E0=AE=BF=E0=AE=99=E0=AF=8D=E0=AE=95=E0=AE=B3=E0=AF=8D =E0=AE=
=9A=E0=AF=86=E0=AE=AA=E0=AF=8D=E0=AE=9F=E0=AE=AE=E0=AF=8D=E0=AE=AA=E0=AE=B0=
=E0=AF=8D 11, 2017] Dmitry Gutov wrote:
>
>> On 9/10/17 7:23 PM, Tom Tromey wrote:
>>> It would be nice if imenu were a back end for xref.
>>> Then M-. could also use symbols found by imenu.
>>> A further wrinkle on this would be if xref, project, and imenu
>>> worked
>>> together, so that M-. would automatically know to look at imenu results
>>> for other buffers in the same project.
>>
>> Agreed. It could be a nice default for when no tags table is currently
>> visited.
>
> I tried to write a general imenu backend in attached file (extracted
> from my init.el) but I hit quite a few roadblocks,
>
>   1. I activate the imenu backend iff there are no tags table defined
>      for the buffer but this means that one cannot use the imenu
>      backend to jump to definitions for symbols that TAGS do not know
>      of currently.  I can think of two ways to solve this problem,
>
>      (a) Check if the symbol is in TAGS table.
>      (b) Modify the etags backend so that the user can say "I have no
>      TAGS table for this file/project/whatever."
>
>      (a) is definitely not clean, and (b) sounds feasible but similar
>      situation can also exist with other backends (like elisp).
>
>      I'm lost on how to solve this problem.
>
>   2. I have not defined all the methods and the completion-table does
>      not handle the nested case of the index alist.  AFAIU from `(elisp)
>      Programmed Completion', completion "ends" when `try-completion'
>      returns t but I seem to be mistaken.  I have to rewrite
>      completion-table to be like `imenu--completion-buffer' but I don't
>      know how to pull that off.
>
>   3. `imenu-xref--in-alist' is mostly a 1-1 copy of `imenu--in-alist'
>      with the only difference being my function returns all matches of
>      the symbol instead of just the first one.  This should be easy
>      enough to fix by adding an optional argument INCLUDE-ALL to
>      `imenu--in-alist'.
>
> I'm testing in python-mode with the following settings,
>
>     (setq imenu-name-lookup-function (lambda (symbol item) (string-prefix=
-p symbol item))
>           python-imenu-format-parent-item-jump-label-function (lambda (_ =
name) name))

I solved (2) by using an affixation function.  I did (3) as well, and
I'm attaching my work as a patch against imenu.el.


--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment; filename=imenu-xref.patch

diff --git a/lisp/imenu.el b/lisp/imenu.el
index 2636e77d08..69338d216a 100644
--- a/lisp/imenu.el
+++ b/lisp/imenu.el
@@ -52,6 +52,7 @@
 ;;; Code:

 (require 'cl-lib)
+(require 'xref)

 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ;;;
@@ -473,8 +474,10 @@ imenu--create-keymap
                         (if cmd (funcall cmd item) item))))))
               alist)))

-(defun imenu--in-alist (str alist)
-  "Check whether the string STR is contained in multi-level ALIST."
+(defun imenu--in-alist (str alist &optional all)
+  "Check whether the string STR is contained in multi-level ALIST.
+If the optional argument ALL is non-nil, then return all matches
+of STR in ALIST."
   (let (elt head tail res)
     (setq res nil)
     (while alist
@@ -491,12 +494,18 @@ imenu--in-alist
       ;; We are only interested in the bottom-level elements, so we need to
       ;; recurse if TAIL is a nested ALIST.
       (cond ((imenu--subalist-p elt)
-	     (if (setq res (imenu--in-alist str tail))
-		 (setq alist nil)))
+             (let ((r (imenu--in-alist str tail all)))
+               (if all
+                   (setq res (append res (if (listp (cdr r)) r (list r))))
+                 (setq res r)
+                 (when r
+                   (setq alist nil)))))
 	    ((if imenu-name-lookup-function
                  (funcall imenu-name-lookup-function str head)
                (string= str head))
-	     (setq alist nil res elt))))
+             (if all
+                 (push elt res)
+               (setq alist nil res elt)))))
     res))

 ;;;###autoload
@@ -550,6 +559,61 @@ imenu-default-create-index-function
 	(t
          (imenu-unavailable-error "This buffer cannot use `imenu-default-create-index-function'"))))

+;;;
+;;; Xref backend
+;;;
+
+;;;###autoload
+(defun imenu-xref-backend ()
+  (unless imenu--index-alist
+    (imenu--make-index-alist))
+  (when (and imenu--index-alist
+             (not (progn (require 'etags) tags-table-files)))
+    'imenu))
+
+(cl-defmethod xref-backend-identifier-at-point ((_backend (eql 'imenu)))
+  (thing-at-point 'symbol))
+
+(defun imenu-xref--make-summary (marker)
+  (with-current-buffer (marker-buffer marker)
+    (save-excursion
+      (goto-char marker)
+      (back-to-indentation)
+      (buffer-substring (point) (point-at-eol)))))
+
+(cl-defmethod xref-backend-definitions ((_backend (eql 'imenu)) symbol)
+  (let ((res (imenu--in-alist symbol imenu--index-alist t))
+        defs)
+    (dolist (item res)
+      (push (xref-make (imenu-xref--make-summary (cdr item))
+                       (xref-make-buffer-location (marker-buffer (cdr item))
+                                                  (marker-position (cdr item))))
+            defs))
+    defs))
+
+(cl-defmethod xref-backend-identifier-completion-ignore-case ((_backend (eql 'imenu)))
+  imenu-case-fold-search)
+
+(defun imenu-xref--make-affixations (alist &optional prefix)
+  (let (res)
+    (dolist (item alist)
+      (if (imenu--subalist-p item)
+          (setq res (append res (imenu-xref--make-affixations
+                                 (cdr item)
+                                 (concat prefix (when prefix imenu-level-separator) (car item)))))
+        (push (list (car item) (concat prefix (when prefix imenu-level-separator)) "") res)))
+    res))
+
+(cl-defmethod xref-backend-identifier-completion-table ((_backend (eql 'imenu)))
+  (let ((affixations (imenu-xref--make-affixations imenu--index-alist)))
+    (lambda (string pred action)
+      (if (eq action 'metadata)
+          `(metadata (affixation-function
+                      . ,(lambda (cmp) (mapcar (lambda (c) (assoc c affixations #'equal)) cmp))))
+        ;; This works since (car AFFIXATIONS) is the completion
+        ;; candidate.
+        (complete-with-action action affixations string pred)))))
+
 ;;;
 ;;; Generic index gathering function.
 ;;;

--=-=-=--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#28407: 26.0.50; xref should use imenu
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 29 May 2022 22:14:01 +0000
Resent-Message-ID: <handler.28407.B28407.16538624077004 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 28407
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Visuwesh <visuweshm@HIDDEN>
Cc: Tom Tromey <tom@HIDDEN>, 28407 <at> debbugs.gnu.org
Received: via spool by 28407-submit <at> debbugs.gnu.org id=B28407.16538624077004
          (code B ref 28407); Sun, 29 May 2022 22:14:01 +0000
Received: (at 28407) by debbugs.gnu.org; 29 May 2022 22:13:27 +0000
Received: from localhost ([127.0.0.1]:42137 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nvRA7-0001ou-FX
	for submit <at> debbugs.gnu.org; Sun, 29 May 2022 18:13:27 -0400
Received: from mail-wr1-f48.google.com ([209.85.221.48]:45806)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1nvRA6-0001oi-FT
 for 28407 <at> debbugs.gnu.org; Sun, 29 May 2022 18:13:26 -0400
Received: by mail-wr1-f48.google.com with SMTP id p10so12347343wrg.12
 for <28407 <at> debbugs.gnu.org>; Sun, 29 May 2022 15:13:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=sender:message-id:date:mime-version:user-agent:subject
 :content-language:to:cc:references:from:in-reply-to
 :content-transfer-encoding;
 bh=8f+zGc9Q9Ix8XvDz2VXdVC8c6aw6/2eC1CsqBpjWBfA=;
 b=P9UorENZDrLTneB8PIBVF242FmsE4IIw2lBIHJmey4S6aLhPniUsqlKSE4qF0qmrxC
 PZVHI3gcQBY4MSFfUUyhse5XruGRTgzPE/fvlDrhHIdwSvMrg+GqiynlUoJ3/cS+4iQp
 /xlk9xmgFDHVkLbDNHSEr9lRhvMU70xTySw9CeHPGeZih3Mi99IfZ3yuUbZuktbEU400
 MBxTBb5t+WBLlWFngQ21fFc6xQObdBB5yL4fhGLkbEASlLA7r3ZFS9mT/4s3R1L9CWgj
 37ZcBUUkqbGH9EAxdH2rf2hsBsuRMTpw0j+e0cMU9636YsHZ1v5JJLFEA+6u93OvJTWn
 EKUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:sender:message-id:date:mime-version:user-agent
 :subject:content-language:to:cc:references:from:in-reply-to
 :content-transfer-encoding;
 bh=8f+zGc9Q9Ix8XvDz2VXdVC8c6aw6/2eC1CsqBpjWBfA=;
 b=qLFfkRrPi12ZgoAeRG5X0SqD6xXBZzlvGPphZRNZKPN+BUCBM4sKDtHYHc/r2aWXVM
 489JK4rtkxUggroYPGhX57Iz4zg4SOza7N3YhszOu8+bTbQry0iAq8qJ2arufAhuS4b5
 +NMkgHqF3x7FV6l4gjLEGYVHam0vivEFXdPtyD7lyz/xuefKQ8wXBWeJgJch8KjMnQup
 ftWNKlwQCGbj0ejCgmZhr0yfD2pTSuoG5LCwF9uoSikEz0OUeCxsD1PhcO9nLKGwqh66
 D/L7/CGDPB9JoiuiUE+d57fmkogwxlc9ch6G+HuwS8HSJ/6B3FGFWPq7Z7zSQeS8N9Cq
 1ZEw==
X-Gm-Message-State: AOAM531YUwtwFXoHutr3tPHCTzl8LsMEx6fe8jUGYij0suhvs6vemH5q
 0xNI4Ws7Axu/PYP1ipO6lN8=
X-Google-Smtp-Source: ABdhPJxPASV8MStyyN6L+dgzb4/AqtuMY1s2kzUhz5GTgcelJETvq6S1DZMltPRIhud3QQ5V4jnUgw==
X-Received: by 2002:a05:6000:1ac8:b0:20f:d4e7:b814 with SMTP id
 i8-20020a0560001ac800b0020fd4e7b814mr30711845wry.678.1653862400521; 
 Sun, 29 May 2022 15:13:20 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 f7-20020a1c3807000000b003942a244f53sm8335814wma.44.2022.05.29.15.13.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 29 May 2022 15:13:20 -0700 (PDT)
Message-ID: <2a6aec56-4f72-5064-c001-e7aa46144f9d@HIDDEN>
Date: Mon, 30 May 2022 01:13:18 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Content-Language: en-US
References: <87h8wa8quw.fsf@bapiya>
 <3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN> <87y1z35630.fsf@HIDDEN>
 <87zgjic68h.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87zgjic68h.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

Hi Visuwesh,

On 16.05.2022 09:59, Visuwesh wrote:
> [ஞாயிறு மே 15, 2022] Visuwesh wrote:
> 
>> [திங்கள் செப்டம்பர் 11, 2017] Dmitry Gutov wrote:
>>
>>> On 9/10/17 7:23 PM, Tom Tromey wrote:
>>>> It would be nice if imenu were a back end for xref.
>>>> Then M-. could also use symbols found by imenu.
>>>> A further wrinkle on this would be if xref, project, and imenu
>>>> worked
>>>> together, so that M-. would automatically know to look at imenu results
>>>> for other buffers in the same project.
>>>
>>> Agreed. It could be a nice default for when no tags table is currently
>>> visited.
>>
>> I tried to write a general imenu backend in attached file (extracted
>> from my init.el) but I hit quite a few roadblocks,
>>
>>    1. I activate the imenu backend iff there are no tags table defined
>>       for the buffer but this means that one cannot use the imenu
>>       backend to jump to definitions for symbols that TAGS do not know
>>       of currently.  I can think of two ways to solve this problem,
>>
>>       (a) Check if the symbol is in TAGS table.
>>       (b) Modify the etags backend so that the user can say "I have no
>>       TAGS table for this file/project/whatever."
>>
>>       (a) is definitely not clean, and (b) sounds feasible but similar
>>       situation can also exist with other backends (like elisp).
>>
>>       I'm lost on how to solve this problem.
>>
>>    2. I have not defined all the methods and the completion-table does
>>       not handle the nested case of the index alist.  AFAIU from `(elisp)
>>       Programmed Completion', completion "ends" when `try-completion'
>>       returns t but I seem to be mistaken.  I have to rewrite
>>       completion-table to be like `imenu--completion-buffer' but I don't
>>       know how to pull that off.
>>
>>    3. `imenu-xref--in-alist' is mostly a 1-1 copy of `imenu--in-alist'
>>       with the only difference being my function returns all matches of
>>       the symbol instead of just the first one.  This should be easy
>>       enough to fix by adding an optional argument INCLUDE-ALL to
>>       `imenu--in-alist'.
>>
>> I'm testing in python-mode with the following settings,
>>
>>      (setq imenu-name-lookup-function (lambda (symbol item) (string-prefix-p symbol item))
>>            python-imenu-format-parent-item-jump-label-function (lambda (_ name) name))
> 
> I solved (2) by using an affixation function.  I did (3) as well, and
> I'm attaching my work as a patch against imenu.el.

(1) sounds reasonable because the reference might easily be in another 
file. If you wanted to add extra customizations (for the user to be able 
to indicated things like "use imenu for xref in these files"), maybe add 
it to this backend's options. As long as it comes before etags in 
xref-backend-functions, it should have all the power. Another possible 
direction for its development would be to always try to combine the 
locations coming from both etags and imenu (in the current file).

I would leave that to a later revision, though. Some testing for 
performance regressions in large projects would be nice too.

(2) Could you try to explain the problem that you were solving here? 
affixation-function is normally about how the completions look (I 
think). Would 'completion-table-with-predicate' help? Or maybe you just 
need to pre-process the nested structure into a "flat" completion table 
first.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#28407: 26.0.50; xref should use imenu
Resent-From: Visuwesh <visuweshm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 30 May 2022 04:19:02 +0000
Resent-Message-ID: <handler.28407.B28407.16538842949219 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 28407
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Tom Tromey <tom@HIDDEN>, 28407 <at> debbugs.gnu.org
Received: via spool by 28407-submit <at> debbugs.gnu.org id=B28407.16538842949219
          (code B ref 28407); Mon, 30 May 2022 04:19:02 +0000
Received: (at 28407) by debbugs.gnu.org; 30 May 2022 04:18:14 +0000
Received: from localhost ([127.0.0.1]:42377 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nvWr7-0002Od-Gd
	for submit <at> debbugs.gnu.org; Mon, 30 May 2022 00:18:13 -0400
Received: from mail-pj1-f67.google.com ([209.85.216.67]:44563)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <visuweshm@HIDDEN>) id 1nvWr6-0002OQ-BJ
 for 28407 <at> debbugs.gnu.org; Mon, 30 May 2022 00:18:12 -0400
Received: by mail-pj1-f67.google.com with SMTP id
 pq9-20020a17090b3d8900b001df622bf81dso9561646pjb.3
 for <28407 <at> debbugs.gnu.org>; Sun, 29 May 2022 21:18:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=5Vm87OpA49B5ljJCjvcN/R8RrXpGt1gfFKW5ah/9kqs=;
 b=ACPZRGIS1ykJPHR0PHylmghqBSFvKX2xCzvdJOTsjvQsU8t0GhyAqWKdIabTf1MQoj
 MGn9En1RqWfjPe3EfjGjhRqks5zyUq84MThkgxCnJJuD4VuT7vll5w9AP935JfsbvI8O
 CaKkp02wM62NZ8WkpLPlKKXqFcl5+qyZlh1ItBnVRfFBqqCNpu+wr2iaXmhgqv8duwFr
 WDwFCmWwoawlh28DCMD5WfbMRNIrpzQCsf8nkJ7XNH5GEzklxuSEordjDYNxbYfG4EuQ
 U//OcJ7+vtS+Enu8/5gnoH4XNSG/bj6vw0Vyd0+l6RoWGdvS1XdCcyj1zX3R2oLb/RfG
 lphA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=5Vm87OpA49B5ljJCjvcN/R8RrXpGt1gfFKW5ah/9kqs=;
 b=nZuCuib0QZE2oTTsl9nXukUfImCo3T5kPMJmC8i7M3Vr6uJ9nfoFE3z9WXt+6guAGp
 NcNso5EGIMXVsHw5cGPyo7jZHHh82OJfVS/XhSuHjUBiKboavJwF2iQw87qcxpAk9dEe
 t5BIKh/R/4NwXHbqyYhpVVukXjNdWM44UE4VQfMtuMLpI1o7V+8H9Xd2I7N3p14NWFfb
 RX7tYUeqpyZy6p41JOR7mmlGyy5wuaW8xCAnC9/paRI7WNYNi9F337AGFm+dh6NqcPg+
 oObKa+kSe8pJd2bH2VncO36WVPdn01bxR1PV52GrZ412yEeL4ZyKy7JuupQooj01CNV9
 1roQ==
X-Gm-Message-State: AOAM532PCFzcVOA+4iwydSfSPWtVihjP/7QDPL3LSvH5qCl171dYDHkg
 KRIRx/6wXMk4f18QiY3LjDk=
X-Google-Smtp-Source: ABdhPJz2D9oPnP47ciXB9d90Aoppuj56foASKLA/hSelLb6sdOzo+sWO2FHpVMb1VVALfiMkIoO9ug==
X-Received: by 2002:a17:90b:3ecc:b0:1e0:5eba:e79a with SMTP id
 rm12-20020a17090b3ecc00b001e05ebae79amr20723041pjb.57.1653884286416; 
 Sun, 29 May 2022 21:18:06 -0700 (PDT)
Received: from localhost ([49.204.142.91]) by smtp.gmail.com with ESMTPSA id
 b2-20020aa78ec2000000b0051868418b06sm7565017pfr.35.2022.05.29.21.18.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 29 May 2022 21:18:05 -0700 (PDT)
From: Visuwesh <visuweshm@HIDDEN>
References: <87h8wa8quw.fsf@bapiya>
 <3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN>
 <87y1z35630.fsf@HIDDEN> <87zgjic68h.fsf@HIDDEN>
 <2a6aec56-4f72-5064-c001-e7aa46144f9d@HIDDEN>
Date: Mon, 30 May 2022 09:48:02 +0530
In-Reply-To: <2a6aec56-4f72-5064-c001-e7aa46144f9d@HIDDEN> (Dmitry Gutov's
 message of "Mon, 30 May 2022 01:13:18 +0300")
Message-ID: <87mtez1wn9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

[=E0=AE=A4=E0=AE=BF=E0=AE=99=E0=AF=8D=E0=AE=95=E0=AE=B3=E0=AF=8D =E0=AE=AE=
=E0=AF=87 30, 2022] Dmitry Gutov wrote:

> Hi Visuwesh,
>

Hi Dmitry!

> On 16.05.2022 09:59, Visuwesh wrote:
>> [=E0=AE=9E=E0=AE=BE=E0=AE=AF=E0=AE=BF=E0=AE=B1=E0=AF=81 =E0=AE=AE=E0=AF=
=87 15, 2022] Visuwesh wrote:
>>=20
>>> [=E0=AE=A4=E0=AE=BF=E0=AE=99=E0=AF=8D=E0=AE=95=E0=AE=B3=E0=AF=8D =E0=AE=
=9A=E0=AF=86=E0=AE=AA=E0=AF=8D=E0=AE=9F=E0=AE=AE=E0=AF=8D=E0=AE=AA=E0=AE=B0=
=E0=AF=8D 11, 2017] Dmitry Gutov wrote:
>>>
>>>> On 9/10/17 7:23 PM, Tom Tromey wrote:
>>>>> It would be nice if imenu were a back end for xref.
>>>>> Then M-. could also use symbols found by imenu.
>>>>> A further wrinkle on this would be if xref, project, and imenu
>>>>> worked
>>>>> together, so that M-. would automatically know to look at imenu resul=
ts
>>>>> for other buffers in the same project.
>>>>
>>>> Agreed. It could be a nice default for when no tags table is currently
>>>> visited.
>>>
>>> I tried to write a general imenu backend in attached file (extracted
>>> from my init.el) but I hit quite a few roadblocks,
>>>
>>>    1. I activate the imenu backend iff there are no tags table defined
>>>       for the buffer but this means that one cannot use the imenu
>>>       backend to jump to definitions for symbols that TAGS do not know
>>>       of currently.  I can think of two ways to solve this problem,
>>>
>>>       (a) Check if the symbol is in TAGS table.
>>>       (b) Modify the etags backend so that the user can say "I have no
>>>       TAGS table for this file/project/whatever."
>>>
>>>       (a) is definitely not clean, and (b) sounds feasible but similar
>>>       situation can also exist with other backends (like elisp).
>>>
>>>       I'm lost on how to solve this problem.
>>>
>>>    2. I have not defined all the methods and the completion-table does
>>>       not handle the nested case of the index alist.  AFAIU from `(elis=
p)
>>>       Programmed Completion', completion "ends" when `try-completion'
>>>       returns t but I seem to be mistaken.  I have to rewrite
>>>       completion-table to be like `imenu--completion-buffer' but I don't
>>>       know how to pull that off.
>>>
>>>    3. `imenu-xref--in-alist' is mostly a 1-1 copy of `imenu--in-alist'
>>>       with the only difference being my function returns all matches of
>>>       the symbol instead of just the first one.  This should be easy
>>>       enough to fix by adding an optional argument INCLUDE-ALL to
>>>       `imenu--in-alist'.
>>>
>>> I'm testing in python-mode with the following settings,
>>>
>>>      (setq imenu-name-lookup-function (lambda (symbol item) (string-pre=
fix-p symbol item))
>>>            python-imenu-format-parent-item-jump-label-function (lambda =
(_ name) name))
>> I solved (2) by using an affixation function.  I did (3) as well,
>> and
>> I'm attaching my work as a patch against imenu.el.
>
> (1) sounds reasonable because the reference might easily be in another
> file. If you wanted to add extra customizations (for the user to be
> able to indicated things like "use imenu for xref in these files"),
> maybe add it to this backend's options.=20

Do we really need something like this?  Can we not let the user handle
it themselves by adding/removing the imenu backend in .dir-locals.el?

Also what's the right way to check if a TAGS table is defined for the
current buffer?  I currently have,

    (or tags-table-files tags-file-name)

> As long as it comes before etags in xref-backend-functions, it should
> have all the power. Another possible direction for its development
> would be to always try to combine the locations coming from both etags
> and imenu (in the current file).

Yes, this sounds attractive but then we would be limiting ourselves to
etags.  IMO, xref trying another backend when one fails to produce a
match would be a better solution in the long term.
[ I, for one, would like to have imenu and elisp backends working at the
  same time.  ]

> I would leave that to a later revision, though. Some testing for
> performance regressions in large projects would be nice too.

Indeed.  Unfortunately, I don't have any large projects on hand.  All
the testing I did was in a small python script of mine.

> (2) Could you try to explain the problem that you were solving here?
> affixation-function is normally about how the completions look (I
> think). Would 'completion-table-with-predicate' help? Or maybe you
> just need to pre-process the nested structure into a "flat" completion
> table first.

I did the pre-processing but I hit a block wrt how the
xref-backend-definitions method worked.  To illustrate, in the test file
that I had I have a function that goes like

    def do1():
        ...
=20=20=20=20=20=20=20=20
        def checkforlink1():
        ...

        def checkforlink2():
        ...

        def sortlinks():
        ...
            def weight():
            ...

        def checkforlink():
        ...

and the imenu--index-alist for this part looks like

    ("do1 (def)"
      ("do1" . #<marker at 2413 in rdscrape.py>)
      ("checkforlink1 (def)" . #<marker at 2850 in rdscrape.py>)
      ("checkforlink2 (def)" . #<marker at 3363 in rdscrape.py>)
      ("sortlinks (def)"
       ("sortlinks" . #<marker at 3721 in rdscrape.py>)
       ("weight (def)" . #<marker at 3747 in rdscrape.py>))
      ("checkforlink (def)" . #<marker at 4121 in rdscrape.py>))

I wrote the flatten function so that it would produce completion
candidates like

"do1:do1" "do1:checkforlink1 (def)" "do1:checkforlink2 (def)" ... and so
on.

But the xref-backend-definitions method can only handle the last part of
it (i.e., "do1" "checkforlink1 (def)").  Since I didn't feel like
parsing this "path-tree" (for a lack of a better word) would be
appropriate for xref-backend-definitions, I slapped this "path-tree" as
cosmetics in the affixation-function instead.  Hopefully, this makes
sense.

But perhaps handling this "path-tree" in xref-backend-definitions would
not hurt after all.  I can spin this up if you think this is better
moving forward.

Some other questions follow:

    1. I was thinking about adding a buffer-local function for the
       identifier-at-point instead of hard-coding (thing-at-point 'symbol)
       to let major-modes like org-mode and auctex-mode behave more=20
       smartly. WDYT?

    2. When implementing the apropos method for the backend, should we
       let pattern match against the whole "path-tree" or just the last
       part of it?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#28407: 26.0.50; xref should use imenu
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 04 Jun 2022 00:58:01 +0000
Resent-Message-ID: <handler.28407.B28407.165430422114020 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 28407
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Visuwesh <visuweshm@HIDDEN>
Cc: Tom Tromey <tom@HIDDEN>, 28407 <at> debbugs.gnu.org
Received: via spool by 28407-submit <at> debbugs.gnu.org id=B28407.165430422114020
          (code B ref 28407); Sat, 04 Jun 2022 00:58:01 +0000
Received: (at 28407) by debbugs.gnu.org; 4 Jun 2022 00:57:01 +0000
Received: from localhost ([127.0.0.1]:57257 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nxI68-0003dx-W3
	for submit <at> debbugs.gnu.org; Fri, 03 Jun 2022 20:57:01 -0400
Received: from mail-wr1-f53.google.com ([209.85.221.53]:35466)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1nxI67-0003dk-An
 for 28407 <at> debbugs.gnu.org; Fri, 03 Jun 2022 20:57:00 -0400
Received: by mail-wr1-f53.google.com with SMTP id a15so3785756wrh.2
 for <28407 <at> debbugs.gnu.org>; Fri, 03 Jun 2022 17:56:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=sender:message-id:date:mime-version:user-agent:subject
 :content-language:to:cc:references:from:in-reply-to
 :content-transfer-encoding;
 bh=1dVtKTSYd0Odb6qj83iHXW4Fwq0JmDePI5mO9M0rsIE=;
 b=jFtSzzuJu3lC8V5tIqUJNbqISbAtG1tFjDNHiwNtUr+j554hhjCHY4Wl89H8qixKFs
 YLXKqvhQ8ppsHsPEJh13jcERYx1VVsJiftoWCrKm2A6ja0tNVUFpirKtUcQPp7xIwrr9
 LgkBSZ3OmlR65jQ/WhXEd7ipONfhTybasabUUKkhZQJEVr+HaE/pI20wAdQ7Pd8IBSs8
 5eHHRezMkP2em6v7dXUUg+53wMvnpNbisuFKL/Z8INEdUF/nEHTjjX0k292+TexnwKmP
 A2pQqleEhYZW+KgrBRVLcnDRQIOWizFb7yZgJepCAznjxhahEfr5R8ijw3GV+CC/nUL6
 iksQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:sender:message-id:date:mime-version:user-agent
 :subject:content-language:to:cc:references:from:in-reply-to
 :content-transfer-encoding;
 bh=1dVtKTSYd0Odb6qj83iHXW4Fwq0JmDePI5mO9M0rsIE=;
 b=4hZx/QcnvYxRqkpZBNpdRt6joGkO8U78mw7VFGlcUvidkEpB4ZlFYjFjaX9UBVwIIQ
 ntpCvAcfJ+BxWhucn9A6Fz3TgpKRnldKY6UjsWimWM7wAf8GAjHRCw4iaMHM8aTFj2Do
 jDqIFm75GieZPPk3G3JIoGVikvz2HWo2G7S63vVzzjH0i2RLBoGACO1vnmXGH3qOqNXz
 wYA5I1H9Rjn0k168QvKDDgJVIV85G1W/zIG5GkGE340Cy4u0EGfFksgCW+0LK5q6qly0
 1EcWBcpjwM7mF+Xp80cgMad4J3+7uWGDvKxn6lGK1ECB378YuuYNowt6XzTTPkQ5VR3p
 fXPg==
X-Gm-Message-State: AOAM533W9/1iEmPcqf7i7WiyVJHey14VQ7P4b24MAzOVaCTTOdaU6cHA
 pO8I2EOcJhrnM8XlFfjrWM8=
X-Google-Smtp-Source: ABdhPJzIfreFhu/qvGJGPuwFYYCc/aXB0yPEKbWsw1GSVEUmsZbjupcmgBkDE5QIUvTNGSvCk2ZEdw==
X-Received: by 2002:a5d:4601:0:b0:20d:53a:2f39 with SMTP id
 t1-20020a5d4601000000b0020d053a2f39mr10147097wrq.347.1654304213236; 
 Fri, 03 Jun 2022 17:56:53 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 h4-20020adffd44000000b002102d4ed579sm8566608wrs.39.2022.06.03.17.56.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 03 Jun 2022 17:56:52 -0700 (PDT)
Message-ID: <9c56d537-fe2c-a9ea-686a-aa9ff110f1ab@HIDDEN>
Date: Sat, 4 Jun 2022 03:56:51 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Content-Language: en-US
References: <87h8wa8quw.fsf@bapiya>
 <3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN> <87y1z35630.fsf@HIDDEN>
 <87zgjic68h.fsf@HIDDEN> <2a6aec56-4f72-5064-c001-e7aa46144f9d@HIDDEN>
 <87mtez1wn9.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87mtez1wn9.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

On 30.05.2022 07:18, Visuwesh wrote:
> [திங்கள் மே 30, 2022] Dmitry Gutov wrote:
> 
>> Hi Visuwesh,
>>
> 
> Hi Dmitry!
> 
>> On 16.05.2022 09:59, Visuwesh wrote:
>>> [ஞாயிறு மே 15, 2022] Visuwesh wrote:
>>>
>>>> [திங்கள் செப்டம்பர் 11, 2017] Dmitry Gutov wrote:
>>>>
>>>>> On 9/10/17 7:23 PM, Tom Tromey wrote:
>>>>>> It would be nice if imenu were a back end for xref.
>>>>>> Then M-. could also use symbols found by imenu.
>>>>>> A further wrinkle on this would be if xref, project, and imenu
>>>>>> worked
>>>>>> together, so that M-. would automatically know to look at imenu results
>>>>>> for other buffers in the same project.
>>>>>
>>>>> Agreed. It could be a nice default for when no tags table is currently
>>>>> visited.
>>>>
>>>> I tried to write a general imenu backend in attached file (extracted
>>>> from my init.el) but I hit quite a few roadblocks,
>>>>
>>>>     1. I activate the imenu backend iff there are no tags table defined
>>>>        for the buffer but this means that one cannot use the imenu
>>>>        backend to jump to definitions for symbols that TAGS do not know
>>>>        of currently.  I can think of two ways to solve this problem,
>>>>
>>>>        (a) Check if the symbol is in TAGS table.
>>>>        (b) Modify the etags backend so that the user can say "I have no
>>>>        TAGS table for this file/project/whatever."
>>>>
>>>>        (a) is definitely not clean, and (b) sounds feasible but similar
>>>>        situation can also exist with other backends (like elisp).
>>>>
>>>>        I'm lost on how to solve this problem.
>>>>
>>>>     2. I have not defined all the methods and the completion-table does
>>>>        not handle the nested case of the index alist.  AFAIU from `(elisp)
>>>>        Programmed Completion', completion "ends" when `try-completion'
>>>>        returns t but I seem to be mistaken.  I have to rewrite
>>>>        completion-table to be like `imenu--completion-buffer' but I don't
>>>>        know how to pull that off.
>>>>
>>>>     3. `imenu-xref--in-alist' is mostly a 1-1 copy of `imenu--in-alist'
>>>>        with the only difference being my function returns all matches of
>>>>        the symbol instead of just the first one.  This should be easy
>>>>        enough to fix by adding an optional argument INCLUDE-ALL to
>>>>        `imenu--in-alist'.
>>>>
>>>> I'm testing in python-mode with the following settings,
>>>>
>>>>       (setq imenu-name-lookup-function (lambda (symbol item) (string-prefix-p symbol item))
>>>>             python-imenu-format-parent-item-jump-label-function (lambda (_ name) name))
>>> I solved (2) by using an affixation function.  I did (3) as well,
>>> and
>>> I'm attaching my work as a patch against imenu.el.
>>
>> (1) sounds reasonable because the reference might easily be in another
>> file. If you wanted to add extra customizations (for the user to be
>> able to indicated things like "use imenu for xref in these files"),
>> maybe add it to this backend's options.
> 
> Do we really need something like this?  Can we not let the user handle
> it themselves by adding/removing the imenu backend in .dir-locals.el?

IDK, .dir-locals.el is per-directory. To have per-file effect one would 
need to use the file-locals section inside the file, which some might 
find undesirable.

Anyway, the kind of defcustoms I was talking about are something to be 
considered for a later addition.

> Also what's the right way to check if a TAGS table is defined for the
> current buffer?  I currently have,
> 
>      (or tags-table-files tags-file-name)

Seems okay.

>> As long as it comes before etags in xref-backend-functions, it should
>> have all the power. Another possible direction for its development
>> would be to always try to combine the locations coming from both etags
>> and imenu (in the current file).
> 
> Yes, this sounds attractive but then we would be limiting ourselves to
> etags.  IMO, xref trying another backend when one fails to produce a
> match would be a better solution in the long term.
> [ I, for one, would like to have imenu and elisp backends working at the
>    same time.  ]

As an alternative, the IMenu backend could look inside the list of 
backends that follow it and try to combine itself with the next one 
manually.

A feature like "always use the next one" has been requested before, but 
so far no implementation that everybody would like has been proposed.

Also note that such approach is difficult to make behave consistently. 
E.g. we have identifier completion -- and it would (probably) only work 
for the first backend, but then navigation, somehow, would still be able 
to jump to the symbols indexed by the following backends. No matter 
which one comes first (etags or imenu), that doesn't sound ideal.

Yes another approach, would be to program a "backend combinator" 
function. Then people would be able to slap together a bunch of 
backends, but all of them would be queried together eagerly, so it's not 
a failover-like solution.

>> I would leave that to a later revision, though. Some testing for
>> performance regressions in large projects would be nice too.
> 
> Indeed.  Unfortunately, I don't have any large projects on hand.  All
> the testing I did was in a small python script of mine.
> 
>> (2) Could you try to explain the problem that you were solving here?
>> affixation-function is normally about how the completions look (I
>> think). Would 'completion-table-with-predicate' help? Or maybe you
>> just need to pre-process the nested structure into a "flat" completion
>> table first.
> 
> I did the pre-processing but I hit a block wrt how the
> xref-backend-definitions method worked.  To illustrate, in the test file
> that I had I have a function that goes like
> 
>      def do1():
>          ...
>          
>          def checkforlink1():
>          ...
> 
>          def checkforlink2():
>          ...
> 
>          def sortlinks():
>          ...
>              def weight():
>              ...
> 
>          def checkforlink():
>          ...
> 
> and the imenu--index-alist for this part looks like
> 
>      ("do1 (def)"
>        ("do1" . #<marker at 2413 in rdscrape.py>)
>        ("checkforlink1 (def)" . #<marker at 2850 in rdscrape.py>)
>        ("checkforlink2 (def)" . #<marker at 3363 in rdscrape.py>)
>        ("sortlinks (def)"
>         ("sortlinks" . #<marker at 3721 in rdscrape.py>)
>         ("weight (def)" . #<marker at 3747 in rdscrape.py>))
>        ("checkforlink (def)" . #<marker at 4121 in rdscrape.py>))
> 
> I wrote the flatten function so that it would produce completion
> candidates like
> 
> "do1:do1" "do1:checkforlink1 (def)" "do1:checkforlink2 (def)" ... and so
> on.
> 
> But the xref-backend-definitions method can only handle the last part of
> it (i.e., "do1" "checkforlink1 (def)").  Since I didn't feel like
> parsing this "path-tree" (for a lack of a better word) would be
> appropriate for xref-backend-definitions, I slapped this "path-tree" as
> cosmetics in the affixation-function instead.  Hopefully, this makes
> sense.

I think converting it to a simpler structure would indeed be a better 
choice. I am concerned about this code being to stay language-agnostic, 
though.

If you have entries like "checkforlink (def)", how do you reliably 
extract the actual method name from it? Or if you don't it wouldn't 
match what xref-backend-identifier-at-point returns.

> But perhaps handling this "path-tree" in xref-backend-definitions would
> not hurt after all.  I can spin this up if you think this is better
> moving forward.

Thanks.

> Some other questions follow:
> 
>      1. I was thinking about adding a buffer-local function for the
>         identifier-at-point instead of hard-coding (thing-at-point 'symbol)
>         to let major-modes like org-mode and auctex-mode behave more
>         smartly. WDYT?

See what etags does in find-tag--default. Maybe you could just delegate 
to it, just like etags's xref-backend-identifier-at-point override does.

>      2. When implementing the apropos method for the backend, should we
>         let pattern match against the whole "path-tree" or just the last
>         part of it?

Can't say for sure. Depends on how hard that would be to implement, I guess.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#28407: 26.0.50; xref should use imenu
Resent-From: Visuwesh <visuweshm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 25 Jun 2022 14:06:01 +0000
Resent-Message-ID: <handler.28407.B28407.165616591014148 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 28407
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Tom Tromey <tom@HIDDEN>, 28407 <at> debbugs.gnu.org
Received: via spool by 28407-submit <at> debbugs.gnu.org id=B28407.165616591014148
          (code B ref 28407); Sat, 25 Jun 2022 14:06:01 +0000
Received: (at 28407) by debbugs.gnu.org; 25 Jun 2022 14:05:10 +0000
Received: from localhost ([127.0.0.1]:45943 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1o56PN-0003g5-7I
	for submit <at> debbugs.gnu.org; Sat, 25 Jun 2022 10:05:10 -0400
Received: from mail-pj1-f65.google.com ([209.85.216.65]:39463)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <visuweshm@HIDDEN>) id 1o56PI-0003fU-Qa
 for 28407 <at> debbugs.gnu.org; Sat, 25 Jun 2022 10:05:07 -0400
Received: by mail-pj1-f65.google.com with SMTP id
 b12-20020a17090a6acc00b001ec2b181c98so8225747pjm.4
 for <28407 <at> debbugs.gnu.org>; Sat, 25 Jun 2022 07:05:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version;
 bh=zr1x1QgMXd3KTVqULKsQ464fyMkqX+i2J3kltA9AYY4=;
 b=Ay1tut3B6YNyjoR7sgZPgPZYQ+T6dB1+RJIWdjLmxVFkT3aWRrPlP1BJ3ce3JS4ncK
 aZctdw7FHZ23D5FdyK9fLbetYqICKtvguxliTsquSwvNbv9SYqFX8brtxoXbg+01GQZe
 jblYkU4SubLFawNe1a2uWo5IAulUa1GjrCioz79nrawrEGCyuXp0UCD1hBM4P5aMFT9b
 lS7fq+mr2m0xFE8+l9vB9EOePefg/f+OfzrtmnmcPGwhZChOHeIxT7rs/kob39g1SMBQ
 sfr74KxE3N9SHJKZ5KkrBra964jC8OxgiPaps4LadZ3rTXp3g+r7KyGVDaMopeOfIb7e
 Q5Zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version;
 bh=zr1x1QgMXd3KTVqULKsQ464fyMkqX+i2J3kltA9AYY4=;
 b=rnR4egVtkAmtftstSxiNz1FVsUIl45E34Y1xVHdkBYGjZwiqXpHLgOgdNK104j+tY6
 wV7QjvNnDrskWYBQRzyUUaKhAxqa1JiOB51TD0MpRwvHGwUzlNqfYg/AV4vsN8BI8Rfp
 ZyRblhg9hygHAlwgAXnAx/SL7wbgFjfJfdPFtzXiYOxPNxwGgc+8rSUZuCwoxLrc+k+e
 2/wRrRYfYTJcTbhI6m1zT+k7hfGCN8jsc/h0UXhpiSKrOTjtCBL1peLVVnuFkZvS0VGU
 mTKxTWqoLE1dPIzIRMScAOpQSUQ66Sw/8cFsjxKWQtip/Uw3C2BFiynbmfED5En6HSYQ
 RItA==
X-Gm-Message-State: AJIora+N4OUvVCmndeeJ5VbMJiCquwxK/RPul0bHoRVlfvYzwCFGzTSA
 i22TaaTIVuFuAQCUqUQx/dk=
X-Google-Smtp-Source: AGRyM1v/7F485G+MCazYWDI8zGAZCTPlIFpy6+AkoT5AeumkhMG5VvKGXfVCsos6GCtqjEo7RZZDkA==
X-Received: by 2002:a17:902:ea02:b0:16a:57bb:d344 with SMTP id
 s2-20020a170902ea0200b0016a57bbd344mr4494455plg.150.1656165898928; 
 Sat, 25 Jun 2022 07:04:58 -0700 (PDT)
Received: from localhost ([49.204.119.36]) by smtp.gmail.com with ESMTPSA id
 t19-20020a63dd13000000b00401a9bc0f33sm3508532pgg.85.2022.06.25.07.04.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 25 Jun 2022 07:04:57 -0700 (PDT)
From: Visuwesh <visuweshm@HIDDEN>
References: <87h8wa8quw.fsf@bapiya>
 <3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN>
 <87y1z35630.fsf@HIDDEN> <87zgjic68h.fsf@HIDDEN>
 <2a6aec56-4f72-5064-c001-e7aa46144f9d@HIDDEN>
 <87mtez1wn9.fsf@HIDDEN>
 <9c56d537-fe2c-a9ea-686a-aa9ff110f1ab@HIDDEN>
Date: Sat, 25 Jun 2022 19:34:48 +0530
In-Reply-To: <9c56d537-fe2c-a9ea-686a-aa9ff110f1ab@HIDDEN> (Dmitry Gutov's
 message of "Sat, 4 Jun 2022 03:56:51 +0300")
Message-ID: <87o7yg3klb.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

[=E0=AE=9A=E0=AE=A9=E0=AE=BF =E0=AE=9C=E0=AF=82=E0=AE=A9=E0=AF=8D 04, 2022]=
 Dmitry Gutov wrote:

Hello Dmitry,

It took me too long to reply since I did not have the immediate need of
this backend and so wasn't too interested in writing it.  Sorry about
that.

>> Do we really need something like this?  Can we not let the user
>> handle
>> it themselves by adding/removing the imenu backend in .dir-locals.el?
>
> IDK, .dir-locals.el is per-directory. To have per-file effect one
> would need to use the file-locals section inside the file, which some
> might find undesirable.
>
> Anyway, the kind of defcustoms I was talking about are something to be
> considered for a later addition.
>

OK, I will leave it for the future.

>> Also what's the right way to check if a TAGS table is defined for the
>> current buffer?  I currently have,
>>      (or tags-table-files tags-file-name)
>
> Seems okay.
>
>>> As long as it comes before etags in xref-backend-functions, it should
>>> have all the power. Another possible direction for its development
>>> would be to always try to combine the locations coming from both etags
>>> and imenu (in the current file).
>> Yes, this sounds attractive but then we would be limiting ourselves
>> to
>> etags.  IMO, xref trying another backend when one fails to produce a
>> match would be a better solution in the long term.
>> [ I, for one, would like to have imenu and elisp backends working at the
>>    same time.  ]
>
> As an alternative, the IMenu backend could look inside the list of
> backends that follow it and try to combine itself with the next one
> manually.
>

I tried this and the results really depend on the imenu indices.  As for
example, python-mode really loves to add junk to the index name so this
combine-all thingy does not place too nicely but, it is still usable.

> A feature like "always use the next one" has been requested before,
> but so far no implementation that everybody would like has been
> proposed.
>

My combination thingy works along these lines.  Currently, if the
identifier is not found in imenu indices, then I check the backends
following the imenu one.  It works satisfactorily.  Although, there
might be a problem with deleting duplicates: a simple `delete-dups' does
not work.  I'm not sure how to compare two xref items independently of
their type (type as in buffer location, etc.).

One problem right now though is the TAGS table used by the etags backend
and the one actually corresponding to the focused file might be
different.  Maybe I should specially handle the etags backend?  WDYT?

[ To elaborate, say that I visited the TAGS residing in Emacs' src/
  directory then switched to another project.  Now, if I do C-u
  M-. Fplist_get RET, then it will take me to the Emacs project!!  This
  seems to be a general problem with the etags backend tho.  ]

> Also note that such approach is difficult to make behave
> consistently. E.g. we have identifier completion -- and it would
> (probably) only work for the first backend, but then navigation,
> somehow, would still be able to jump to the symbols indexed by the
> following backends. No matter which one comes first (etags or imenu),
> that doesn't sound ideal.
>

Looks like my logic can handle this case just fine.  In xdisp.c, I tried
C-u M-. Fplist_get RET and the imenu backend used the etags backend to
jump to the definition.=20=20

>
> I think converting it to a simpler structure would indeed be a better
> choice. I am concerned about this code being to stay
> language-agnostic, though.
>
> If you have entries like "checkforlink (def)", how do you reliably
> extract the actual method name from it? Or if you don't it wouldn't
> match what xref-backend-identifier-at-point returns.
>

I don't think you have to worry about the backend staying language
agnostic.  In the case of python, I have a few imenu customisations:

    (defun vz/python-imenu-hook ()
      (setq imenu-name-lookup-function (lambda (symbol item) (string-prefix=
-p symbol item))
            python-imenu-format-parent-item-jump-label-function (lambda (_ =
name) name)
            imenu-create-index-function
            (lambda () (vz/imenu-create-index-function #'python-imenu-creat=
e-index))))

The `string-prefix-p' ensures that the imenu xref backend does not choke
on the " (def)" part.

>> But perhaps handling this "path-tree" in xref-backend-definitions would
>> not hurt after all.  I can spin this up if you think this is better
>> moving forward.
>
> Thanks.
>

Now done.

>> Some other questions follow:
>>      1. I was thinking about adding a buffer-local function for the
>>         identifier-at-point instead of hard-coding (thing-at-point 'symb=
ol)
>>         to let major-modes like org-mode and auctex-mode behave more
>>         smartly. WDYT?
>
> See what etags does in find-tag--default. Maybe you could just
> delegate to it, just like etags's xref-backend-identifier-at-point
> override does.
>

I added a variable `imenu-xref-identifier-function'.  If this is not
what you had in mind, do tell.


>>      2. When implementing the apropos method for the backend, should we
>>         let pattern match against the whole "path-tree" or just the last
>>         part of it?
>
> Can't say for sure. Depends on how hard that would be to implement, I gue=
ss.

I'm leaving the apropos bit to the future=E2=84=A2 as well.

On the performance part, it does not seem to be too bad but the only
large file I tested it on was xdisp.c: the imenu backend performed
really well once the initial hiccup of generating the imenu index alist
was done.

Hopefully, I covered everything that needed to be addressed.

Attaching updated patch.


--=-=-=
Content-Type: text/x-diff
Content-Disposition: attachment; filename=0001-Add-imenu-xref-backend.patch

From 43779948d064453942dc97cacd3e8a4be8048f19 Mon Sep 17 00:00:00 2001
From: Visuwesh <visuweshm@HIDDEN>
Date: Sat, 25 Jun 2022 19:32:49 +0530
Subject: [PATCH] Add imenu xref backend

* imenu.el (imenu--in-alist): Add new optional argument.
(imenu-xref-backend): New xref backend.
(imenu-xref-identifier-function, imenu-xref--following-backends): Add.
(imenu-xref--make-summary, imenu-xref--make-location)
(imenu-xref--flatten): Add helper functions.
(xref-backend-identifier-at-point, xref-backend-definitions)
(xref-backend-identifier-completion-ignore-case)
(xref-backend-identifier-completion-table): Add 'imenu' method.

(bug#28407)
---
 lisp/imenu.el | 101 +++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 96 insertions(+), 5 deletions(-)

diff --git a/lisp/imenu.el b/lisp/imenu.el
index 4393c6ed6c..9820de54e3 100644
--- a/lisp/imenu.el
+++ b/lisp/imenu.el
@@ -52,6 +52,7 @@
 ;;; Code:
 
 (require 'cl-lib)
+(require 'xref)
 
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ;;;
@@ -473,8 +474,10 @@ imenu--create-keymap
                         (if cmd (funcall cmd item) item))))))
               alist)))
 
-(defun imenu--in-alist (str alist)
-  "Check whether the string STR is contained in multi-level ALIST."
+(defun imenu--in-alist (str alist &optional all)
+  "Check whether the string STR is contained in multi-level ALIST.
+If the optional argument ALL is non-nil, then return all matches
+of STR in ALIST."
   (let (elt head tail res)
     (setq res nil)
     (while alist
@@ -491,12 +494,18 @@ imenu--in-alist
       ;; We are only interested in the bottom-level elements, so we need to
       ;; recurse if TAIL is a nested ALIST.
       (cond ((imenu--subalist-p elt)
-	     (if (setq res (imenu--in-alist str tail))
-		 (setq alist nil)))
+             (let ((r (imenu--in-alist str tail all)))
+               (if all
+                   (setq res (append res (if (listp (cdr r)) r (list r))))
+                 (setq res r)
+                 (when r
+                   (setq alist nil)))))
 	    ((if imenu-name-lookup-function
                  (funcall imenu-name-lookup-function str head)
                (string= str head))
-	     (setq alist nil res elt))))
+             (if all
+                 (push elt res)
+               (setq alist nil res elt)))))
     res))
 
 ;;;###autoload
@@ -550,6 +559,88 @@ imenu-default-create-index-function
 	(t
          (imenu-unavailable-error "This buffer cannot use `imenu-default-create-index-function'"))))
 
+;;;
+;;; Xref backend
+;;;
+
+(defvar-local imenu-xref-identifier-function nil
+  "Function to fetch the identifier for xref.")
+
+;;;###autoload
+(defun imenu-xref-backend ()
+  (unless imenu--index-alist
+    (imenu--make-index-alist))
+  (and imenu--index-alist 'imenu))
+
+(defun imenu-xref--following-backends ()
+  "Return the xref backends following the imenu one."
+  (let (backends)
+    (dolist (b (cdr (memq 'imenu-xref-backend xref-backend-functions)))
+      (when-let ((backend (and (functionp b) (funcall b))))
+        (push backend backends)))
+    (setq backends (nreverse backends))
+    backends))
+
+(cl-defmethod xref-backend-identifier-at-point ((_backend (eql 'imenu)))
+  (or (and imenu-xref-identifier-function
+           (funcall imenu-xref-identifier-function))
+      (thing-at-point 'symbol)))
+
+(defun imenu-xref--make-summary (marker)
+  (with-current-buffer (marker-buffer marker)
+    (save-excursion
+      (goto-char marker)
+      (back-to-indentation)
+      (buffer-substring (point) (point-at-eol)))))
+
+(defun imenu-xref--make-location (item)
+  (xref-make (imenu-xref--make-summary (cdr item))
+             (xref-make-buffer-location (marker-buffer (cdr item))
+                                        (marker-position (cdr item)))))
+
+(cl-defmethod xref-backend-definitions ((_backend (eql 'imenu)) identifier)
+  (if-let ((pos (string-search imenu-level-separator identifier)))
+      ;; We only care about the exact match here so ALL is nil.
+      (let ((alist (imenu--in-alist (substring identifier 0 pos) imenu--index-alist)))
+        (while (and (listp alist) (listp (cdr alist)))
+          (setq identifier (substring identifier (1+ pos))
+                pos (string-search imenu-level-separator identifier)
+                alist (imenu--in-alist (substring identifier 0 pos) imenu--index-alist)))
+        (list (imenu-xref--make-location alist)))
+    (let ((res (imenu--in-alist identifier imenu--index-alist t))
+          defs)
+      (dolist (item res)
+        (push (imenu-xref--make-location item) defs))
+      (unless defs
+        (dolist (b (imenu-xref--following-backends))
+          (ignore-errors
+            ;; FIXME: This does not catch duplicates!
+            (setq defs (append defs (xref-backend-definitions b identifier))))))
+      defs)))
+
+(cl-defmethod xref-backend-identifier-completion-ignore-case ((_backend (eql 'imenu)))
+  imenu-case-fold-search)
+
+(defun imenu-xref--flatten (alist &optional prefix)
+  (let (res)
+    (dolist (item alist)
+      (if (imenu--subalist-p item)
+          (setq res (append res (imenu-xref--flatten
+                                 (cdr item)
+                                 (concat prefix (when prefix imenu-level-separator) (car item)))))
+        (push (cons (concat prefix (when prefix imenu-level-separator) (car item))
+                    (cdr item))
+              res)))
+    res))
+
+(cl-defmethod xref-backend-identifier-completion-table ((_backend (eql 'imenu)))
+  (let ((collection (imenu-xref--flatten imenu--index-alist)))
+    (apply #'completion-table-merge
+           (append (list (lambda (string pred action)
+                           (complete-with-action action collection string pred)))
+                   (mapcar #'xref-backend-identifier-completion-table
+                           (imenu-xref--following-backends))))))
+
 ;;;
 ;;; Generic index gathering function.
 ;;;
-- 
2.35.1


--=-=-=--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#28407: 26.0.50; xref should use imenu
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 25 Jun 2022 14:21:02 +0000
Resent-Message-ID: <handler.28407.B28407.165616682315558 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 28407
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Visuwesh <visuweshm@HIDDEN>
Cc: tom@HIDDEN, 28407 <at> debbugs.gnu.org, dgutov@HIDDEN
Received: via spool by 28407-submit <at> debbugs.gnu.org id=B28407.165616682315558
          (code B ref 28407); Sat, 25 Jun 2022 14:21:02 +0000
Received: (at 28407) by debbugs.gnu.org; 25 Jun 2022 14:20:23 +0000
Received: from localhost ([127.0.0.1]:45971 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1o56e7-00042r-97
	for submit <at> debbugs.gnu.org; Sat, 25 Jun 2022 10:20:23 -0400
Received: from eggs.gnu.org ([209.51.188.92]:60518)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1o56dq-00041t-2M
 for 28407 <at> debbugs.gnu.org; Sat, 25 Jun 2022 10:20:21 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:32906)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1o56dk-000899-Ml; Sat, 25 Jun 2022 10:20:00 -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=c6cs+YNiAJKrY+7544FlOx6sB0Qhe/DMAdfQCwmGDsw=; b=ebZNmQNIg3K+
 kIEIHct1aX26BZMo+BwJ4emPBXJ59byGhQMRfkaidnd2c6wC3Y/OItFoMwvxhV+YDQsfgm/vKtHGt
 i+2xdeIojAYU0aaZtKDGzY8fKkVNdvpYhD39ZW06Yo1KHdx1dk/TdHcKVYnbROX9yLD0HNPHk8bcL
 J+8oKrZm/nYifnmg1Yc2PsBSPX01qwSbrsKtvqaFFUuTbVhNg8VCfhT1/IaSnHc0m9QuCGVX91PYs
 O4xOd5raAoBQvmMEoqyVsxHmVYMDH1W/EyFBshwEyK9KgebJgw6f277fvlY7wEpDQ9s4qnMW1op79
 NFn+1zDRuhi4vUGnKLgCkA==;
Received: from [87.69.77.57] (port=4073 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1o56dk-0001H1-41; Sat, 25 Jun 2022 10:20:00 -0400
Date: Sat, 25 Jun 2022 17:19:57 +0300
Message-Id: <83wnd4akqa.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87o7yg3klb.fsf@HIDDEN> (message from Visuwesh on Sat, 25 Jun
 2022 19:34:48 +0530)
References: <87h8wa8quw.fsf@bapiya>
 <3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN>
 <87y1z35630.fsf@HIDDEN> <87zgjic68h.fsf@HIDDEN>
 <2a6aec56-4f72-5064-c001-e7aa46144f9d@HIDDEN>
 <87mtez1wn9.fsf@HIDDEN>
 <9c56d537-fe2c-a9ea-686a-aa9ff110f1ab@HIDDEN> <87o7yg3klb.fsf@HIDDEN>
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: Tom Tromey <tom@HIDDEN>, 28407 <at> debbugs.gnu.org
> From: Visuwesh <visuweshm@HIDDEN>
> Date: Sat, 25 Jun 2022 19:34:48 +0530
> 
> [ To elaborate, say that I visited the TAGS residing in Emacs' src/
>   directory then switched to another project.  Now, if I do C-u
>   M-. Fplist_get RET, then it will take me to the Emacs project!!  This
>   seems to be a general problem with the etags backend tho.  ]

In general, when you visit a new TAGS file, etags asks you whether to
replace the previous one or to keep them both.  Maybe the way you
"switch to another project" somehow hides that prompt/decision?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#28407: 26.0.50; xref should use imenu
Resent-From: Visuwesh <visuweshm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 25 Jun 2022 14:38:02 +0000
Resent-Message-ID: <handler.28407.B28407.165616786217281 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 28407
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: tom@HIDDEN, 28407 <at> debbugs.gnu.org, dgutov@HIDDEN
Received: via spool by 28407-submit <at> debbugs.gnu.org id=B28407.165616786217281
          (code B ref 28407); Sat, 25 Jun 2022 14:38:02 +0000
Received: (at 28407) by debbugs.gnu.org; 25 Jun 2022 14:37:42 +0000
Received: from localhost ([127.0.0.1]:45994 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1o56ur-0004Uf-OG
	for submit <at> debbugs.gnu.org; Sat, 25 Jun 2022 10:37:41 -0400
Received: from mail-pl1-f195.google.com ([209.85.214.195]:33334)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <visuweshm@HIDDEN>) id 1o56um-0004UN-Nx
 for 28407 <at> debbugs.gnu.org; Sat, 25 Jun 2022 10:37:39 -0400
Received: by mail-pl1-f195.google.com with SMTP id n10so4560829plp.0
 for <28407 <at> debbugs.gnu.org>; Sat, 25 Jun 2022 07:37:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=IksTOXwFG4ImIOqov9gBm3yxMMB5Ul+d/+lWJpfdiB0=;
 b=HearfT4ytlTdtlV5/IoiYQCG1xjgv+gn/9NZt82K0TYOdCEYOR+La3JQ7BtbOQmA9A
 L84C6YUWXBUj/6nTZ617DPeD6JesvJtG9ZSBy2ycueuS21zymyLEY74oMp6tospofxLd
 7ROTT1MilDb3xui/EEV60ixileZX/ktVahTk4c13Pbl7c9QeTE6vTwjocEcjZ0Byr4u3
 LQvyAnDWA3GEgnsO8OayIXyxDVLlmhX2Be0/PUOevwdPs4zifGsKTCd60yvUFDjN2HEX
 mWyGMvvUe2hiQ+rDWEss/NiW/l5wy2V25M5wuDcFtrzjk8Dv1R+axaA4hYdPQc6480Ag
 qv0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=IksTOXwFG4ImIOqov9gBm3yxMMB5Ul+d/+lWJpfdiB0=;
 b=s8PMHFfS4l9Sog5EbULPuOHOUTvoNovFtUPxOkXKsQtarpzQ9530FrSs2pvKIBIro+
 OGFimBDy4AQ18bLUToRbdqwNijZicXm7A7Fv2OaUC3GQ31lRswqaLCRvEMSWQCZ0BqYU
 0+XnQw3Kxy3m+XHviY+yTBcnG8ux9ylhmZchAuzN9QOG0m3K539wtTUcw3pQ8EoK6o+6
 emaHAWDul2bU+AFe6UwtBlEe9BsbgOMs8sA91kFs/zjbUrgzgV8tgxwNu/AxnodCTwlW
 8EJW6zOMafvcEjnIxmeHEStsfHF8xVL0LxZaoy67IN/41nZH/wuDFWHEEkC2KMB03T24
 utxw==
X-Gm-Message-State: AJIora9kOjSc/fr6zFaTa9I6s79FTw99Ubi/j+7RKLvo6SqOEe7ff6YO
 tlwkb7TrUZwsOkTCnTKMMf8=
X-Google-Smtp-Source: AGRyM1sRVU4yntS36z8F+zYGHQG4J4W2zje4+IjwodjJr2xkbb6jyweyK1YtiMwXqV+v20saV5x8ug==
X-Received: by 2002:a17:902:bb8d:b0:168:e48d:86bc with SMTP id
 m13-20020a170902bb8d00b00168e48d86bcmr4748039pls.93.1656167850871; 
 Sat, 25 Jun 2022 07:37:30 -0700 (PDT)
Received: from localhost ([49.204.119.36]) by smtp.gmail.com with ESMTPSA id
 l127-20020a632585000000b0040c4f60f649sm3514038pgl.13.2022.06.25.07.37.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 25 Jun 2022 07:37:30 -0700 (PDT)
From: Visuwesh <visuweshm@HIDDEN>
References: <87h8wa8quw.fsf@bapiya>
 <3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN>
 <87y1z35630.fsf@HIDDEN> <87zgjic68h.fsf@HIDDEN>
 <2a6aec56-4f72-5064-c001-e7aa46144f9d@HIDDEN>
 <87mtez1wn9.fsf@HIDDEN>
 <9c56d537-fe2c-a9ea-686a-aa9ff110f1ab@HIDDEN>
 <87o7yg3klb.fsf@HIDDEN> <83wnd4akqa.fsf@HIDDEN>
Date: Sat, 25 Jun 2022 20:07:25 +0530
In-Reply-To: <83wnd4akqa.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 25 Jun
 2022 17:19:57 +0300")
Message-ID: <87fsjs3j2y.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

[=E0=AE=9A=E0=AE=A9=E0=AE=BF =E0=AE=9C=E0=AF=82=E0=AE=A9=E0=AF=8D 25, 2022]=
 Eli Zaretskii wrote:

>> Cc: Tom Tromey <tom@HIDDEN>, 28407 <at> debbugs.gnu.org
>> From: Visuwesh <visuweshm@HIDDEN>
>> Date: Sat, 25 Jun 2022 19:34:48 +0530
>>=20
>> [ To elaborate, say that I visited the TAGS residing in Emacs' src/
>>   directory then switched to another project.  Now, if I do C-u
>>   M-. Fplist_get RET, then it will take me to the Emacs project!!  This
>>   seems to be a general problem with the etags backend tho.  ]
>
> In general, when you visit a new TAGS file, etags asks you whether to
> replace the previous one or to keep them both.  Maybe the way you
> "switch to another project" somehow hides that prompt/decision?

It does ask me to replace the previous one but I expected Emacs to
restrict the TAGS file to the buffer I selected it from, mostly because
I was mislead to believe the check (or tags-table-files tags-file-name)
would work that way.
[ The check is from a previous revision of my patch.  ]

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#28407: 26.0.50; xref should use imenu
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 25 Jun 2022 15:15:02 +0000
Resent-Message-ID: <handler.28407.B28407.165617006829203 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 28407
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Visuwesh <visuweshm@HIDDEN>
Cc: tom@HIDDEN, 28407 <at> debbugs.gnu.org, dgutov@HIDDEN
Received: via spool by 28407-submit <at> debbugs.gnu.org id=B28407.165617006829203
          (code B ref 28407); Sat, 25 Jun 2022 15:15:02 +0000
Received: (at 28407) by debbugs.gnu.org; 25 Jun 2022 15:14:28 +0000
Received: from localhost ([127.0.0.1]:46035 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1o57US-0007ax-FV
	for submit <at> debbugs.gnu.org; Sat, 25 Jun 2022 11:14:28 -0400
Received: from eggs.gnu.org ([209.51.188.92]:41278)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1o57UP-0007aj-QV
 for 28407 <at> debbugs.gnu.org; Sat, 25 Jun 2022 11:14:26 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:33374)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1o57UJ-0002sF-Bf; Sat, 25 Jun 2022 11:14:19 -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=JhF3r64XGq5Ql5XAwtQuP62Bwi4ZYmDbhY2Xnn5kmfE=; b=qUqSleXog4nhNdHy+0i8
 mqqaVTTQBcIkBWIYq52Dpx8Ca3I7qUUSKsf3psUaA0KNd/0EbZBx0/Gci9JwoomtmKuju8yIL8P4D
 ZHiaj2fgBQmn/LQAjEPRSEV0NtQ9vnDyEFgIJiK/JJAv0tLTMFi7NyTtlzILOdMKpFb0SjgVTQFUj
 x1BfHoPGoJo7nfkIHMbw8fXyLhoz9K01AX7BNZ+risROffdn1crMiRUD7zMMqeIZY1Nju4OYcoO4v
 ZcjYlHjgcmNhsgaUfxsFRNo/jenl87SOzjOa8+6+0Qv13Ddkxh/u2qSKA/pyQA+HDuHRAOkoLmTdC
 QKIcq5nlEtiR6g==;
Received: from [87.69.77.57] (port=3415 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1o57UI-0002nV-9q; Sat, 25 Jun 2022 11:14:19 -0400
Date: Sat, 25 Jun 2022 18:14:15 +0300
Message-Id: <83v8soai7s.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87fsjs3j2y.fsf@HIDDEN> (message from Visuwesh on Sat, 25 Jun
 2022 20:07:25 +0530)
References: <87h8wa8quw.fsf@bapiya>
 <3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN>
 <87y1z35630.fsf@HIDDEN> <87zgjic68h.fsf@HIDDEN>
 <2a6aec56-4f72-5064-c001-e7aa46144f9d@HIDDEN>
 <87mtez1wn9.fsf@HIDDEN>
 <9c56d537-fe2c-a9ea-686a-aa9ff110f1ab@HIDDEN>
 <87o7yg3klb.fsf@HIDDEN> <83wnd4akqa.fsf@HIDDEN> <87fsjs3j2y.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Visuwesh <visuweshm@HIDDEN>
> Cc: tom@HIDDEN,  28407 <at> debbugs.gnu.org,  dgutov@HIDDEN
> Date: Sat, 25 Jun 2022 20:07:25 +0530
> 
> [சனி ஜூன் 25, 2022] Eli Zaretskii wrote:
> 
> > In general, when you visit a new TAGS file, etags asks you whether to
> > replace the previous one or to keep them both.  Maybe the way you
> > "switch to another project" somehow hides that prompt/decision?
> 
> It does ask me to replace the previous one but I expected Emacs to
> restrict the TAGS file to the buffer I selected it from

That'd be against the purpose of TAGS tables: their explicit purpose
is to allow you to find definitions in _other_ files.  And Emacs
cannot know whether the fact that you loaded another TAGS table means
that you want to "forget" about the previous one, as long as you keep
it loaded.

Last modified: Sat, 25 Jun 2022 15:30:01 UTC

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