bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Thierry Volpiatto
Subject: bug#64902: 30.0.50; REQUIRE-MATCH completing-read arg in describe-* commands
Date: Sat, 29 Jul 2023 05:28:29 +0000

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: signature.asc
Description: PGP signature


reply via email to

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