On Wed, Feb 5, 2020 at 5:55 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 05.02.2020 17:27, João Távora wrote:
> > With the original problem fixed, Dmitry came to what can be seen as a
> > UI deficiency in fido-mode.
>
> Not exactly. There have been several issues discussed in this report,
> and it's really a problem that the user can't easily input something
> that completing-read would allow.
>

So isn't that a UI deficiency in fido-mode?  Mind you I'm calling it
a deficiency because it can't by definition be a bug.  fido-mode is a new
thing and I _made_ the spec for it.  Of course, I like your suggestions
for improvement (as I have showed here).


> A new bug report has arrived since:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39407 It is now
> erroneously marked as fixed because it has been merged with this one. We
> should undo that.
>
> The proposed workaround (using M-j) is itself problematic since it
> allows you to input whatever even when a match is required. So there are
> bug here.
>

Not sure that is a problem with fido-mode.  I think it's reasonable
for a completer to bind exit-minibuffer, or to have something that
allows it to exit with whatever.  exit-minibuffer doesn't honour
require-match (maybe it shouldn't) but it is the only such thing
that allows any kind of workaround, as far as I am aware.
So this isn't a problem with fido-mode. When there is something
else to fill this gap -- respect require-match and still allow to exit
easily with arbitrary input when that is nil -- then fido-mode will use
it.


> > After analysing this with Stefan, we arrived
> > at the conclusion that it was actually a problem in some longstanding
> > minibuffer.el workings.
>
> Not exactly. At least, icomplete-mode seems to work okay in both of
> these respects (please correct me if I'm wrong).
>

Doesn't icomplete-force-complete-and-exit have a problem, too?  I
was under the impression that it did, from reading the above thread.


> > Maybe, Dmitry, we could revert to the earlier proposal with the new
> > variable and somehow deprecate/discourage use of the one you're
> > trying to change?  That should be safe and bring all the benefits of
> > your change, right?
>
> Yes, we can do that. I'll make the new variable private, so we can rid
> of it quickly on master.
>

Great!   Disregard the previous discussion if you want, just do this,
and move on.

João