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

Previous Next

Full log

View this message in rfc822 format

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

Hi Dmitry,

The second option looks pretty good, so you can just push that at will,
if no other objections.  Incidentally, I would also think it reasonable to
provide the same help text if there is a single partial match.

The first option I don't understand very well, but that's probably because
I haven't looked very closely at it, so if you can post an implementation of
your idea it would be ideal, because it doesn't sound absurd at all :-)

João


On Sat, Jan 18, 2020 at 1:38 AM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> On 11.01.2020 21:59, João Távora wrote:
> > rs due to fundamental changes in the problem others due
> > to opinion.  It "feels" nice for me now, but if you can come up with a better
> > binding for RET, shoot it over, I'll tell you what I think about it.  I think
> > you'll find it will have advantages and disadvantages.  But who knows:-)
>
> Without going far into changing its behavior, I think we have two
> options for this now. Since the only occurrence of "Incomplete" of
> minibuffer.el is in minibuffer-force-complete-and-exit, apparently one
> issue is that the glob input doesn't succeed the test-completion test in
> the read-file-name-internal completion table used by grep-read-files.
>
> So the options are:
>
> 1. Make sure that the table says globs are valid input (by adding a
> wrapper, probably). This should make RET silently accept the input in
> this case. This is a good way to proceed if we're reasonably confident
> we can deal with similar issues in the same way, and there won't be too
> many of them.
>
> 2. Make icomplete-force-complete-and-exit show a different message, so
> that the user knows what to do. Instead of just "Incomplete", add
> something like ", press \\[exit-minibuffer\\] to accept".
>
> Maybe do both.
>
> The second option can look like this:
>
> diff --git a/lisp/icomplete.el b/lisp/icomplete.el
> index a1a67e2330..d88ebca15d 100644
> --- a/lisp/icomplete.el
> +++ b/lisp/icomplete.el
> @@ -185,7 +185,15 @@ icomplete-force-complete-and-exit
>          ;; calculated, This causes the first cached completion to
>          ;; be taken (i.e. the one that the user sees highlighted)
>          completion-all-sorted-completions)
> -      (minibuffer-force-complete-and-exit)
> +      (progn
> +        (unless completion-cycling
> +          (minibuffer-force-complete nil nil 'dont-cycle))
> +        (completion--complete-and-exit
> +         (minibuffer-prompt-end) (point-max) #'exit-minibuffer
> +         ;; If the previous completion completed to an element which fails
> +         ;; test-completion, then we shouldn't exit, but that should be
> rare.
> +         (lambda () (minibuffer-message "Incomplete, press %s to accept"
> +                                   (substitute-command-keys
> "\\[exit-minibuffer]")))))
>       ;; Otherwise take the faster route...
>       (minibuffer-complete-and-exit)))
>
>
> (Or we can put the message into a global var which
> icomplete-force-complete-and-exit would bind to this message string).



--
João Távora

Previous Next

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