From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:1008:1e59::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 0GxtLb+Le2WrYQEAkFu2QA (envelope-from ) for ; Fri, 15 Dec 2023 00:11:59 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id eOjaKL+Le2UkcwAA62LTzQ (envelope-from ) for ; Fri, 15 Dec 2023 00:11:59 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=janestreet.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1702595519; h=from:from:sender:sender: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:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=fuMI0qP8cwqXYMDhL+BnNeQ1HuWuIQVG37fX7leNApU=; b=fZoD+PLTllDufY4hxqkyo4xEvArOgMU5uJ9AnW4WDL3730VaICCJwMraSNHfDOv8z8EAmH mOXeXOJv7nGoETO4dKZ1Mcdmq/4zJhe1deAJfV/Y6BY9R/1hu2mCLXMvHJaTxyL+qii1C9 PdGj49AXVCbG04xLa0aoYacOey2hfz8HpbPIMzd64ItPremjpBEhGprMbkdMkDqdhwHe4w zPM/0HKOMC4EnroV9OOHbEh7o5H+JfrpxS4FDwCz21aLSPlKONTFK6w9Iyh2V6gOjxrdI/ OQCviePA2eKJvYQOF8m6RXHxVY4TZjfT4FCglyvwMARge34MtXm7MWgTgF0Bow== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1702595519; a=rsa-sha256; cv=none; b=FmAzxtP3QyJ6GzgjiTBcKLqjJsVPVeVK9IKCwAyb+IcnOAvfP+d3zeGA17QwWFxzgif+A0 EysqwQPbF/xD4+HzJ4Q/1LTDOSLow70bGWbtRA/wMgwIZ9geWIi0iFnxb7jz4ANlGpWU84 Kgf/tomFrT1VD2m8yNt7sCF0FdeUTGXJbPlEWjnZLdCBTTeJKRqDa0iNIP2rKEMjIepDdl 1SesBHxZHG1Zl8r36FbHqa4vLR3i6wyZ21OEMGRUK0FcjWm0wHiogBr3ZQxF/DkEd2Uxt9 xP+XZ9jwH5WSAeo7VoJ9EB7CFdDJUoUWSyP1vEMddatZLDi/FocDqELED2jLEQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=janestreet.com (policy=none) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 6D91E10FB0 for ; Fri, 15 Dec 2023 00:11:59 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rDurO-0003nh-BM; Thu, 14 Dec 2023 18:11:18 -0500 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 1rDurN-0003nW-Hq for emacs-orgmode@gnu.org; Thu, 14 Dec 2023 18:11:17 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rDurL-0007rn-Vs for emacs-orgmode@gnu.org; Thu, 14 Dec 2023 18:11:17 -0500 From: Spencer Baugh To: Ihor Radchenko Cc: Eli Zaretskii , Morgan.J.Smith@outlook.com, emacs-orgmode@gnu.org, 58131@debbugs.gnu.org, emacs-devel@gnu.org Subject: Re: [FR] Allow flattened imenu index In-Reply-To: <874jgrsiyy.fsf@localhost> (Ihor Radchenko's message of "Sat, 09 Dec 2023 11:39:33 +0000") References: <87plzgbalt.fsf@localhost> <87msujskxg.fsf@localhost> <835y17y5qu.fsf@gnu.org> <874jgrsiyy.fsf@localhost> Date: Thu, 14 Dec 2023 18:11:14 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@janestreet.com; helo=mxout5.mail.janestreet.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -3.10 X-Spam-Score: -3.10 X-Migadu-Queue-Id: 6D91E10FB0 X-Migadu-Scanner: mx11.migadu.com X-TUID: ArJtrNbjbMda Ihor Radchenko writes: > Eli Zaretskii writes: > >>> I am wondering if it makes more sense to add this "flatten" option >>> globally into imenu instead. >> >> I'm not sure I understand what you are asking. As we don't seem to >> have an active maintainer of imenu on board, more details are needed >> to understand the request. Of course, patches are even more welcome. > > Normally, `imenu' supports nested menus, when users select the target > location in steps, like item3 -> item3.1 -> ... > > What is proposed is to list all the sub-menus together, as an option, so > that the users can choose, for example, item.3.1 directly, without going > through parent item3. I would love to have this feature. I have wanted this for OCaml, where the default imenu index produced by the "merlin" tool is annoyingly deeply nested, which makes it awkward to use. I have an alternative proposal though, which might be better: We could enhance the imenu completion table to understand completion boundaries. Then the imenu hierarchy could be completed over in a single completing-read instead of a sequence of multiple completing-reads. It would work the same way as read-file-name. So, for example, if the completion boundary was /, and we had a hierarchy containing these elements: aaa/bbb/ddd aaa/bbb/eee aaa/ccc/eee aaa/ccc/fff You could choose aaa/bbb/ddd with this sequence of minibuffer contents: (input in [brackets], point at |) [a] a| [] aaa/| ; completion now shows bbb and ccc as options [b] aaa/b/d| [TAB] aaa/bbb/ddd| [RET] Alternatively, you could choose aaa/bbb/eee with this sequence: [*/*/e] */*/e| [TAB] aaa/|/eee ; completion now shows bbb and ccc as options, point is at | [b] aaa/b|/eee [TAB] aaa/bbb/eee| [RET] To be very clear, these completion features already exist (and are enabled by default!), all we would need to do is enhance the imenu completion table to understand completion boundaries, and then imenu would have access to these features too. This new completion table could be turned on by default, since it would be strictly more powerful than the current imenu UI. Plus, if some alternative completion UI wanted to flatten the hierarchy anyway, this more advanced imenu completion table would allow that.