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: João Távora
Subject: bug#38992: 27.0.60; when enabled, fido-mode seems to break vc-git-grep
Date: Tue, 21 Jan 2020 08:12:08 +0000


On Mon, Jan 20, 2020, 23:56 Dmitry Gutov <address@hidden> 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

reply via email to

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