GNU bug report logs - #43120
28.0.50; fido-mode: M-j before completions appear selects wrong choice

Previous Next

Package: emacs;

Reported by: Sean Whitton <spwhitton <at> spwhitton.name>

Date: Sun, 30 Aug 2020 21:01:01 UTC

Severity: normal

Tags: fixed

Merged with 43083

Found in version 28.0.50

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 19032 <at> debbugs.gnu.org, 43120 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>, Lars Ingebrigtsen <larsi <at> gnus.org>, OGAWA Hirofumi <hirofumi <at> mail.parknet.co.jp>, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: bug#43120: 28.0.50; fido-mode: M-j before completions appear selects wrong choice
Date: Thu, 10 Sep 2020 20:15:25 +0100
Juri Linkov <juri <at> 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




This bug report was last modified 4 years and 312 days ago.

Previous Next


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