[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
- bug#19032: bug#43120: 28.0.50; fido-mode: M-j before completions appear selects wrong choice, (continued)
- bug#19032: bug#43120: 28.0.50; fido-mode: M-j before completions appear selects wrong choice, João Távora, 2020/09/09
- bug#19032: bug#43120: 28.0.50; fido-mode: M-j before completions appear selects wrong choice, Stefan Monnier, 2020/09/09
- bug#19032: bug#43120: 28.0.50; fido-mode: M-j before completions appear selects wrong choice, João Távora, 2020/09/09
- bug#19032: bug#43120: 28.0.50; fido-mode: M-j before completions appear selects wrong choice, Stefan Monnier, 2020/09/09
- bug#19032: bug#43120: 28.0.50; fido-mode: M-j before completions appear selects wrong choice, João Távora, 2020/09/09
- bug#19032: bug#43120: 28.0.50; fido-mode: M-j before completions appear selects wrong choice, João Távora, 2020/09/09
- bug#19032: bug#43120: 28.0.50; fido-mode: M-j before completions appear selects wrong choice, Stefan Monnier, 2020/09/09
- bug#43120: 28.0.50; fido-mode: M-j before completions appear selects wrong choice, João Távora, 2020/09/09
- bug#43120: 28.0.50; fido-mode: M-j before completions appear selects wrong choice, Stefan Monnier, 2020/09/10
- bug#19032: bug#43120: 28.0.50; fido-mode: M-j before completions appear selects wrong choice, Juri Linkov, 2020/09/10
- bug#19032: bug#43120: 28.0.50; fido-mode: M-j before completions appear selects wrong choice,
João Távora <=
- bug#43120: 28.0.50; fido-mode: M-j before completions appear selects wrong choice, Juri Linkov, 2020/09/09