From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eshel Yaron Newsgroups: gmane.emacs.devel Subject: Re: master 431f8ff1e38: * lisp/imenu.el: Support more values for imenu-flatten (bug#70846) Date: Wed, 15 May 2024 20:30:47 +0200 Message-ID: References: <171558357066.26019.9766615061719600757@vcs2.savannah.gnu.org> <20240513065931.0D83AC12C31@vcs2.savannah.gnu.org> <86v83hwxjs.fsf@mail.linkov.net> <86ikzhq6ja.fsf@mail.linkov.net> <86o798x5hz.fsf@gnu.org> <86bk572e6a.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14938"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , Stefan Monnier , emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 15 20:31:44 2024 Return-path: Envelope-to: ged-emacs-devel@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 1s7JPi-0003gV-Rb for ged-emacs-devel@m.gmane-mx.org; Wed, 15 May 2024 20:31:42 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s7JP9-0005zD-T8; Wed, 15 May 2024 14:31:08 -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 1s7JOw-0005uT-Cy for emacs-devel@gnu.org; Wed, 15 May 2024 14:30:58 -0400 Original-Received: from mail.eshelyaron.com ([107.175.124.16] helo=eshelyaron.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s7JOu-0003Xg-Ks; Wed, 15 May 2024 14:30:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1715797850; bh=NjQJQlr/MO98qYhCw17cYhdCvoS6RZFyebZSGm6vTO0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=tucWSsvtbS9dbD+0x6SUdYedKARn/FGNFsk5LmV5hozNQLmMW2P8E2Eo3fB1wsRCH w3i+IWdutRlvx1G70GQGW0zweaIMXXHSskBIPoESlNk8jTUS/OF6l9p+Tz6wcItN37 3+5RZO7uawcqeQ4Kozr9tQhezfcURqPE/Ty88fpayvzGZOWwTLbuwkjccMCDzNaO8B AzdzMcOun8svU27/M0i4j2kwTfgZgVIJ6ST+TvdNttwa4j3Ixo9RuoHCYtjQyfJAPl m3NxZ4biHcbmD7IFb1oz0NIGSVQ2i3orJ/9gNejwgxMF/u5Dki5rPaCN7pBqAAzzQr fOOtmGxFU+uYQ== In-Reply-To: <86bk572e6a.fsf@mail.linkov.net> (Juri Linkov's message of "Wed, 15 May 2024 19:51:25 +0300") Received-SPF: pass client-ip=107.175.124.16; envelope-from=me@eshelyaron.com; helo=eshelyaron.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:319265 Archived-At: Hi Juri, Juri Linkov writes: >>> +(defcustom completion-allow-text-properties nil >>> + "Non-nil means `choose-completion' should not discard text properties. >>> +This also affects `completing-read' and any of the functions that do >>> +minibuffer input with completion." >> >> This new user option should be announced in NEWS. >> >> I also wonder whether it should be a user option > > So here it's a variable, that will later help to select Imenu > completion candidates with same names from different groups. > > diff --git a/etc/NEWS b/etc/NEWS > index 34052764f5f..0db85410ebe 100644 > --- a/etc/NEWS > +++ b/etc/NEWS > @@ -1784,6 +1784,13 @@ A major mode based on the tree-sitter library for editing Lua files. > > ** Minibuffer and Completions > > +*** New variable 'completion-allow-text-properties'. > +Like non-nil 'minibuffer-allow-text-properties' that doesn't discard > +text properties, it does the same by keeping text properties > +on the selected completion candidate. So when these two variables > +both are non-nil then 'completing-read' returns a selected completion > +with the initial text properties kept intact. Note that when minibuffer-allow-text-properties is non-nil, you can already get the same original text properties from completing-read if you "select" your candidate by cycling, since that doesn't go through choose-completion which strips text properties. It feels a bit surprising to have this separate variable that affects one kind of selection ("choosing") and not other kinds ("cycling", "expanding"). IMO, it'd be better, if possible, to just cease stripping text properties in choose-completion altogether. Note that choose-completion calls completion--replace to do the actual insertion, and that function already respects minibuffer-allow-text-properties. > --- a/lisp/imenu.el > +++ b/lisp/imenu.el > @@ -732,6 +732,8 @@ imenu--completion-buffer > ;; Create a list for this buffer only when needed. > (let ((name (thing-at-point 'symbol)) > choice > + (minibuffer-allow-text-properties t) > + (completion-allow-text-properties t) IIUC, these let-bindings around completing-read will affect all recursive minibuffers too, and even completion-at-point completions if you start editing another buffer before exiting the minibuffer. Perhaps we can use buffer-local bindings in the minibuffer and propagate them to the completions list buffer when populating it instead of let-binding? Best, Eshel