From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.orgmode,gmane.emacs.devel Subject: Re: [FR] Allow flattened imenu index Date: Thu, 14 Dec 2023 18:11:14 -0500 Message-ID: References: <87plzgbalt.fsf@localhost> <87msujskxg.fsf@localhost> <835y17y5qu.fsf@gnu.org> <874jgrsiyy.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28613"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , Morgan.J.Smith@outlook.com, emacs-orgmode@gnu.org, 58131@debbugs.gnu.org, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Fri Dec 15 00:11:59 2023 Return-path: Envelope-to: geo-emacs-orgmode@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 1rDus3-0007Bh-Ht for geo-emacs-orgmode@m.gmane-mx.org; Fri, 15 Dec 2023 00:11:59 +0100 Original-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 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 1rDurN-0003nW-Hq for emacs-orgmode@gnu.org; Thu, 14 Dec 2023 18:11:17 -0500 Original-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 In-Reply-To: <874jgrsiyy.fsf@localhost> (Ihor Radchenko's message of "Sat, 09 Dec 2023 11:39:33 +0000") 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+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Original-Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.orgmode:158608 gmane.emacs.devel:313836 Archived-At: 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.