GNU bug report logs - #76010
describe-face and minibuffer-next/previous-completion

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>, Eli Zaretskii <eliz <at> gnu.org>
Cc: Jake <jforst.mailman <at> gmail.com>, 76010 <at> debbugs.gnu.org
Subject: bug#76010: describe-face and minibuffer-next/previous-completion
Date: Tue, 11 Feb 2025 07:00:51 +0200

[Message part 1 (text/plain, inline)]

Hi Juri,

On 03/02/2025 09:44, Juri Linkov wrote:
>>> emacs -Q
>>> M-x describe-face RET
>>> M-<down> M-<down> M-<down>
>>>
>>> In the minibuffer prompt, I see the completions have accumulated.
>>> I.e. it appears as
>>> boldblink-matching-paren-offscreenabbrev-table-name
>>> instead of the expected
>>> bold
>>> which is the currently highlighted completion candidate.
>>> The same accumulation occurs when M-<up> (minibuffer-previous-completion) is used.
>> Thanks.
>>
>> Juri, this seems to be a regression since Emacs 29, so could you
>> please look into this soon?
> It seems that removal of completion-base-affixes
> and completion-use-base-affixes in bug#48356 broke
> completing-read-multiple.

Could you try this patch?

It seems to handle the described scenario well, but maybe I'm missing 
some other case.

E.g. when would the current implementation go down the "else" path, 
after (and (stringp start) (stringp end)) evaluating to nil?

[completing-read-multiple-bug-76010.diff (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.