From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#28407: 26.0.50; xref should use imenu Date: Mon, 30 May 2022 01:13:18 +0300 Message-ID: <2a6aec56-4f72-5064-c001-e7aa46144f9d@yandex.ru> References: <87h8wa8quw.fsf@bapiya> <3238a206-240a-aa76-87c0-bcb3bdfa00dc@yandex.ru> <87y1z35630.fsf@gmail.com> <87zgjic68h.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9959"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Cc: Tom Tromey , 28407@debbugs.gnu.org To: Visuwesh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 30 00:14:16 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 1nvRAt-0002TQ-76 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 30 May 2022 00:14:15 +0200 Original-Received: from localhost ([::1]:44512 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nvRAr-0002u9-TD for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 29 May 2022 18:14:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54314) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nvRAg-0002tu-JI for bug-gnu-emacs@gnu.org; Sun, 29 May 2022 18:14:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48240) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nvRAg-0005Hz-5L for bug-gnu-emacs@gnu.org; Sun, 29 May 2022 18:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nvRAf-0001q8-Vu for bug-gnu-emacs@gnu.org; Sun, 29 May 2022 18:14:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 May 2022 22:14:01 +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.16538624077004 (code B ref 28407); Sun, 29 May 2022 22:14:01 +0000 Original-Received: (at 28407) by debbugs.gnu.org; 29 May 2022 22:13:27 +0000 Original-Received: from localhost ([127.0.0.1]:42137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nvRA7-0001ou-FX for submit@debbugs.gnu.org; Sun, 29 May 2022 18:13:27 -0400 Original-Received: from mail-wr1-f48.google.com ([209.85.221.48]:45806) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nvRA6-0001oi-FT for 28407@debbugs.gnu.org; Sun, 29 May 2022 18:13:26 -0400 Original-Received: by mail-wr1-f48.google.com with SMTP id p10so12347343wrg.12 for <28407@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) Original-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) Content-Language: en-US In-Reply-To: <87zgjic68h.fsf@gmail.com> 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:233351 Archived-At: 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.