From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Visuwesh Newsgroups: gmane.emacs.bugs Subject: bug#28407: 26.0.50; xref should use imenu Date: Mon, 30 May 2022 09:48:02 +0530 Message-ID: <87mtez1wn9.fsf@gmail.com> References: <87h8wa8quw.fsf@bapiya> <3238a206-240a-aa76-87c0-bcb3bdfa00dc@yandex.ru> <87y1z35630.fsf@gmail.com> <87zgjic68h.fsf@gmail.com> <2a6aec56-4f72-5064-c001-e7aa46144f9d@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="423"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Tom Tromey , 28407@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 30 06:19:34 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nvWsQ-000ASW-8I for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 30 May 2022 06:19:34 +0200 Original-Received: from localhost ([::1]:40178 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nvWsO-0002ne-Oi for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 30 May 2022 00:19:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45582) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nvWrw-0002nI-Tu for bug-gnu-emacs@gnu.org; Mon, 30 May 2022 00:19:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48480) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nvWru-0003YS-Mn for bug-gnu-emacs@gnu.org; Mon, 30 May 2022 00:19:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nvWru-0002Pg-Hy for bug-gnu-emacs@gnu.org; Mon, 30 May 2022 00:19:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Visuwesh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 May 2022 04:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28407 X-GNU-PR-Package: emacs Original-Received: via spool by 28407-submit@debbugs.gnu.org id=B28407.16538842949219 (code B ref 28407); Mon, 30 May 2022 04:19:02 +0000 Original-Received: (at 28407) by debbugs.gnu.org; 30 May 2022 04:18:14 +0000 Original-Received: from localhost ([127.0.0.1]:42377 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nvWr7-0002Od-Gd for submit@debbugs.gnu.org; Mon, 30 May 2022 00:18:13 -0400 Original-Received: from mail-pj1-f67.google.com ([209.85.216.67]:44563) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nvWr6-0002OQ-BJ for 28407@debbugs.gnu.org; Mon, 30 May 2022 00:18:12 -0400 Original-Received: by mail-pj1-f67.google.com with SMTP id pq9-20020a17090b3d8900b001df622bf81dso9561646pjb.3 for <28407@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) Original-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) In-Reply-To: <2a6aec56-4f72-5064-c001-e7aa46144f9d@yandex.ru> (Dmitry Gutov's message of "Mon, 30 May 2022 01:13:18 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:233356 Archived-At: [=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" . #) ("checkforlink1 (def)" . #) ("checkforlink2 (def)" . #) ("sortlinks (def)" ("sortlinks" . #) ("weight (def)" . #)) ("checkforlink (def)" . #)) 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?