Re: emacs-30 768e92b9c02: Update options that depend on 'which-key-dont-use-unicode'

[Philip Kaludercic]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Mon, 24 Jun 2024 15:01:24 +0000, Philip Kaludercic 
>>>>>> <philipk@posteo.net> said:
>     >> This commit causes `which-key-separator' and `which-key-ellipsis' to
>     >> be nil for me (after `which-key-mode'). Reverting this commit fixes it.
>
>     Philip> Eh, that might be because `which-key-dont-use-unicode' is being
>     Philip> evaluated before the other two options, but the :set function is 
> giving
>     Philip> them initial values (nil), even though we haven't determined their
>     Philip> default value yet.
>
>     Philip> Does
>
>     Philip> diff --git a/lisp/which-key.el b/lisp/which-key.el
>     Philip> index 91007ce4ada..8b78bfb2576 100644
>     Philip> --- a/lisp/which-key.el
>     Philip> +++ b/lisp/which-key.el
>     Philip> @@ -133,6 +133,7 @@ which-key-dont-use-unicode
>     Philip>           (mapc #'custom-reevaluate-setting
>     Philip>                 '(which-key-separator
>     Philip>                   which-key-ellipsis)))
>     Philip> +  :initialize #'custom-initialize-changed
>     Philip>    :type 'boolean
>     Philip>    :package-version "1.0" :version "30.1")
>  
>
>
>     Philip> make sense?  I am always uncertain which :initialize value to use.
>
> That works for me, although I wonʼt claim to understand why 😀

My reasoning is that this will only run the setter if the value is
/changed/, right?  So if we set `which-key-dont-use-unicode' is set
before we load which-key, then the user option inherits the
configuration and the other two options use the current value to
determine their default value.  If on the other hand we change the user
option after which-key has been loaded, then the custom setter will take
effect, and will re-load the default value, which has previously been
set to the (if ...) expression, as was the case before.

> Robert

-- 
        Philip Kaludercic on peregrine