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

Previous Next

Full log

Message #61 received at 38992 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 38992 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 waah <at> yellowfrog.io
Subject: Re: bug#38992: 27.0.60;
 when enabled, fido-mode seems to break vc-git-grep
Date: Tue, 21 Jan 2020 08:12:08 +0000

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

On Mon, Jan 20, 2020, 23:56 Dmitry Gutov <dgutov <at> yandex.ru> wrote:

> On 21.01.2020 2:04, Stefan Monnier wrote,:
> > The `minibuffer-force-complete` call is the one which actually selects
> > the "first candidate" from the list of completions, so I do think it's
> necessary.
>
> Oh. Right. Somehow I hadn't tested a scenario where this would matter.
>

Phew! :)


> > IIUC the bug under discussion is related to the `required` argument of
> > `completing-read` (and to `minibuffer-completion-confirm`).
>
> Right.
>
> > If `required` was nil (as is the case in `grep-read-files` which
> > I believe is the relevant function here), then when `test-completion`
> > fails, we should probably just call `exit-minibuffer` (rather than tell
> > the user that they should do that).
>
> Ido added an extra prompt in situations like this, I think. What you're
> saying was my first suggestion, but it would require a more invasive
> change.
>

As I said, you can try it out, maybe with a new binding for RET. Please
don't add an extra prompt.

And icomplete-force-complete-and-exit, as implemented, calls
> minibuffer-force-complete-and-exit which doesn't seem to care (or know?)
> that REQUIRED was nil. If you have a particular change in mind, I'd
> happily try a patch.
>
> BTW, I now see that my patch changes a function belonging to icomplete,
> whileas the intention was only to fix fido-mode's behavior. Do you think
> the change fits icomplete-mode as well?
>
> > The problem here is probably caused by the fact that fido-mode arranges
> > for `minibuffer-force-complete` to choose the *default* rather than to
> > choose a candidate from the completion table.  It's rare for
> > a completion table to return candidates that don't pass
> > `test-completion` (tho it's by not impossible nor incorrect), but it's
> > much less rare for the default not to pass `test-completion`.
>
> Um, not sure I understand. The problem here is that typing 'all' (unless
> it matches some of the local files names) or '*.el' and typing RET
> doesn't work. minibuffer-force-complete tries to choose a completion
> from the table, and when it can't, we get the "Incomplete" message.
> Though if it can (there's a matching filename), it ends up worse for the
> user, in this particular situation.
>

Dmitry, I wrestled a lot with the the "default" case among others. I wish I
had written tests for it but it is quite hard. When experimenting with this
at least try:

- pressing ret quickly before the first completions appear, with a default,
like in c-h f. There should be no wait.
- same but slowly, the default should be on top.
- m-x man on an word that doesn't perfectly match the candidates, like
"read" (I think).

Observe differences before and after. Also sorting matters, obviously. Fido
mode does some sorting itself to move the default to the top position, I
think.

João

>

[Message part 2 (text/html, inline)]

Previous Next

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