bug#64902: 30.0.50; REQUIRE-MATCH completing-read arg in describe-* commands

[Eli Zaretskii]

> From: Thierry Volpiatto <thievol@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, 64902@debbugs.gnu.org
> Date: Fri, 28 Jul 2023 16:16:42 +0000
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >>> I suspect it might have been when a function is advised but not yet 
> >>> defined.
> >> Hmm, how could this happen?
> >
> > It happens all the time: just call `advice-add` before the function is 
> > defined.
> 
> I hardly see how one would do this, sorry.
> 
> >> The problem is that with Helm completion I have an extra unknown
> >> symbol on top of list when I start typing (this is expected when
> >> require-match is non-nil),
> >
> > Could you characterize this "unknown symbol" a bit more?  I'm having
> > trouble guessing why/how/where `confirm` would have such an effect.
> 
> In Helm, if require-match is 'confirm, when you write in minibuffer something
> that doesn't match one of the candidates this string is appended on top
> of list and is prefixed (with display prop) with [?]. By contrast when
> require-match is nil nothing is appended on top of list and pressing RET
> doesn't exit minibuffer (helm-buffer is empty in such case).
> IOW the behavior of require-match is the same than with vanilla Emacs.
> 
> > Maybe we can fix that without preventing the use of "not quite
> > defined" functions.
> 
> Sorry, as said above I don't understand what you want to achieve here.

I've now added a comment to that particular call to completing-read,
and I'm therefore closing this bug.