From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Sebastian Poeplau via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#69657: Missing imenu entries with eglot Date: Sun, 17 Mar 2024 12:04:07 +0100 Message-ID: <87bk7dt858.fsf@mailbox.org> References: <87frx0ze5n.fsf@mailbox.org> <87a5n8s8jw.fsf@betli.tmit.bme.hu> <87bk7oz6vc.fsf@mailbox.org> <87v85v1io3.fsf@betli.tmit.bme.hu> <87jzmat5qe.fsf@mailbox.org> <87frwxuc1w.fsf@mailbox.org> Reply-To: Sebastian Poeplau Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30584"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 69657@debbugs.gnu.org, Felician Nemeth To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 17 12:40:44 2024 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 1rlose-0007ni-HC for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 Mar 2024 12:40:44 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rlosR-0000LF-FA; Sun, 17 Mar 2024 07:40:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rlosO-0000Kz-6L for bug-gnu-emacs@gnu.org; Sun, 17 Mar 2024 07:40:28 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rlosK-00036l-7i for bug-gnu-emacs@gnu.org; Sun, 17 Mar 2024 07:40:27 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rlosv-0004qT-Lf for bug-gnu-emacs@gnu.org; Sun, 17 Mar 2024 07:41:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Sebastian Poeplau Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Mar 2024 11:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69657 X-GNU-PR-Package: emacs Original-Received: via spool by 69657-submit@debbugs.gnu.org id=B69657.171067561418559 (code B ref 69657); Sun, 17 Mar 2024 11:41:01 +0000 Original-Received: (at 69657) by debbugs.gnu.org; 17 Mar 2024 11:40:14 +0000 Original-Received: from localhost ([127.0.0.1]:57703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rlos9-0004pG-De for submit@debbugs.gnu.org; Sun, 17 Mar 2024 07:40:14 -0400 Original-Received: from mout-p-201.mailbox.org ([80.241.56.171]:60638) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rlobz-0001f1-Jr for 69657@debbugs.gnu.org; Sun, 17 Mar 2024 07:23:32 -0400 Original-Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4TyFvn5LgFz9srv; Sun, 17 Mar 2024 12:22:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1710674565; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ylmcWX2xfdPCOMZfyOd1Kfi8yImkpUz8rFulKP4MtOg=; b=ElbW03L2Q0tWV6r8K7jV/jqIXOZsZ0JYYDb6BwAbYv3jw+VkvYwC6n9md2MulZiiID9/NU tByQ0Xm2wfAd4sP268S9tsxsmLbmQ0y7x8E34DCsscPp1pOkiVkJznmFwMqT6Ug60u2RgZ BVWMWT2E3obFq3AR/3d/w7GxLPIzWEJjAbpZBaoDKxvR/HC99HPiWHvJnLM1004Iq/Cmsf yg9wZ+omkGx/wBDkukCHjoxXIlKuEt2cFPKNAZvgNf3+xiBSxgUZiXvLirtj92bw9wrc1Y vKLHSQK52BhYRxDZSyxletOv7ADNX9OKfN79RYl+KlE8n3ai1kpwnEIv/eEYvg== In-reply-to: X-MBO-RS-META: yupqooe5rq3qtyf7n8ndmzudhbnqu5hd X-MBO-RS-ID: 665cb7b48bd606ac1a6 X-Mailman-Approved-At: Sun, 17 Mar 2024 07:40:11 -0400 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:281760 Archived-At: > The problems are in Imenu. > > You should rather lobby for a better imenu structure (which will be > hard to do fully backward compatibly will all existing UIs -- except if > you use the string properties trick that Eglot/breadcrumb use as > I explained) You could also lobby for a brand new imenu replacement > in Emacs. I've been thinking about this. A "brand new imenu replacement" sounds like something that would be hard to get adoption for. So, assuming that we wanted to change the imenu structure to something that works better for representing ASTs, I think there are two somewhat related problems: (1) how to represent the AST internally, and (2) how to show it to the user. 1. The current representation in `imenu--index-alist', as you said, has the problem that it doesn't allow position information on inner nodes; also, additional metadata like the category has to be tagged on with text properties or other tricks. One could extend the existing structure. For example, leaves could become lists (name beg end category) with everything but NAME and BEG being optional, or something like that; inner nodes could optionally have the same format instead of being just strings. I don't see how to much such a change in a way that wouldn't break existing UIs, but maybe one could find a way that at least makes it easy for them to support the new structure (e.g., by providing helper functions in imenu.el, which could also facilitate future changes in `imenu--index-alist'). I guess while changing the structure one could try to optimize it for the use cases of existing UIs. Breadcrumb, for example, probably needs an efficient means of computing the most specific node corresponding to a buffer position, as well as the path down from the root to that node, and the list of its sibling nodes. 2. A menu structure like the one offered by M-x imenu or `imenu-add-menubar-index' makes it difficult to jump to inner nodes. The best I can think of is an entry labeled "(top)" or something like that underneath each leave node with a position; in my earlier example, the "Foo" menu entry would then expand to a list of two sub-entries, "(top)" and "bar". Alternative UIs probably have much better ways to display the information (such as the entry in consult-imenu that I was originally looking for). Even if this sounds like a nice improvement, I wonder about the compatibility issue. Do you think such a patch would even be considered?