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

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

bug#38992: 27.0.60; when enabled, fido-mode seems to break vc-git-grep


From: Dmitry Gutov
Subject: bug#38992: 27.0.60; when enabled, fido-mode seems to break vc-git-grep
Date: Thu, 5 Mar 2020 11:59:53 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 05.03.2020 10:46, João Távora wrote:
On Thu, Mar 5, 2020 at 8:36 AM Dmitry Gutov <address@hidden <mailto:address@hidden>> wrote:
 >
 > On 05.03.2020 10:01, João Távora wrote:
 >
> >  >  ido-mode users, however, like to use RET for arbitrary inputs as well.
 > >
 > > Let's first _not_ change the current fido-mode UI ok? At least
 > > for now.  Later (even before Emacs 27) could be fine.
 >
 > It only changed according to our previous discussion. E.g. RET can now
 > accept '*.c' as pattern to search for in 'M-x grep'.

Yes, that fine.  I meant, let's not change it _further_ (if that was indeed
what you were proposing).

Nope, just this.

Also, I think, for safety, that we still should have in the fido-mode-keymap
sth bound to the "atomic" give-me-whatever-is-in-minibuffer
command, maybe C-M-j or something like that.  Even if it
_does_ break the required-match semantics somewhere else,
it just seems like a good idea.

But why? REQUIRE-MATCH is there for a reason. The caller does not expect non-matching inputs, and is unlikely to handle them well.

If non-matching input can make sense, then the caller needs to be changed.

 > Of course, if there were any matches in the completion table for that
 > input, RET would choose the first match.
 >
 > Let me know if you see a problem there.

Hmmm, isn't that how ido-mode behaves already, and how fido-mode
behaves, at least to a large extent? If so it seems fine.

No, I meant a problem in overall behavior. But it seems fine to me as well.





reply via email to

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