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