bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19032: bug#43120: 28.0.50; fido-mode: M-j before completions appear


From: João Távora
Subject: bug#19032: bug#43120: 28.0.50; fido-mode: M-j before completions appear selects wrong choice
Date: Thu, 10 Sep 2020 20:15:25 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Juri Linkov <juri@linkov.net> writes:

>> Though I'm starting to think that when require-match is nil, an
>> icomplete user wouldn't want the new icomplete-show-matches-on-no-input
>> behaviour anyway.
>
> This is confusing, I don't understand why behaviour of
> icomplete-show-matches-on-no-input should depend on require-match.
>
> Here are two examples that produce a different result.



>
> The first example is from hi-lock-read-face-name:
>
> (defvar hi-history nil)
> (icomplete-mode)
> (let ((icomplete-show-matches-on-no-input t)
>       (defaults '("hi-yellow" "hi-green"))
>       (hi-history '("hi-blue")))
>   (completing-read
>    (format-prompt "Highlight using face" (car defaults))
>    obarray 'facep t nil 'hi-history defaults))
>
> displays this prompt:
>
>   Highlight using face (default hi-yellow): {link | menu | bold ...
>
> Typing RET returns "link" (and sometimes returns "hi-blue" from the history),
> but never returns the expected default value "hi-yellow".
>
> Whereas the second example from tab-bar-switch-to-tab
> works correctly since its arg require-match is nil:
>
> (let ((icomplete-show-matches-on-no-input t)
>       (defaults '("yellow" "green"))
>       (hi-history '("blue")))
>   (completing-read
>    (format-prompt "Switch to tab by name" (car defaults))
>    defaults nil nil nil 'hi-history defaults))
>
> displays this prompt:
>
>   Switch to tab by name (default yellow): {green | yellow}
>
> Typing RET returns the default value "yellow", not the first candidate 
> "green".
>
> This makes the behaviour of icomplete-show-matches-on-no-input
> unpredictable, and thus in some cases dangerous.

I think I agree, but I've just tested this with the version of
icomplete.el before I started messing with this stuff (commit
c8472cc69d4bce7f53c9a62966245a4de3d99fbd) and I get exactly the same
results as you.  So I'd leave my work here for someone else to pick up
on: To be clear, I just wanted to simplify/refactor the code to be less
intrusive on minibuffer.el.

I'm not much of an icomplete-mode user, more of a fido-mode user where
these discrepancies are "fixed" by copying ido-mode's behaviour.

João





reply via email to

[Prev in Thread] Current Thread [Next in Thread]