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

[Thierry Volpiatto <thievol@posteo.net>]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]


Thierry Volpiatto <thievol@posteo.net> writes:

> 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 made a change in Helm to allow overriding require-match if needed, see
https://github.com/emacs-helm/helm/commit/4cfa25d930cf4084d46e58dc403c5a5b67782a23

Thanks.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]