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

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

[Robert Pluim]

>>>>> On Mon, 24 Jun 2024 03:46:37 -0400 (EDT), Philip Kaludercic <philipk@posteo.net> said:

    Philip> branch: emacs-30
    Philip> commit 768e92b9c0214a2aa1be2afbee48c455583d3110
    Philip> Author: Philip Kaludercic <philipk@posteo.net>
    Philip> Commit: Philip Kaludercic <philipk@posteo.net>

    Philip>     Update options that depend on 'which-key-dont-use-unicode'
    
    Philip>     * lisp/which-key.el (which-key-dont-use-unicode): Add a custom setter
    Philip>     that re-evaluates a manual list of options use
    Philip>     'which-key-dont-use-unicode' to determine their default value.
    
    Philip>     https://lists.gnu.org/archive/html/help-gnu-emacs/2024-06/msg00130.html

This commit causes `which-key-separator' and `which-key-ellipsis' to
be nil for me (after `which-key-mode'). Reverting this commit fixes it.

Robert
-- 

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

[Philip Kaludercic]

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

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Mon, 24 Jun 2024 03:46:37 -0400 (EDT), Philip Kaludercic
> <philipk@posteo.net> said:
>
>     Philip> branch: emacs-30
>     Philip> commit 768e92b9c0214a2aa1be2afbee48c455583d3110
>     Philip> Author: Philip Kaludercic <philipk@posteo.net>
>     Philip> Commit: Philip Kaludercic <philipk@posteo.net>
>
>     Philip>     Update options that depend on 'which-key-dont-use-unicode'
>     
>     Philip>     * lisp/which-key.el (which-key-dont-use-unicode): Add a custom setter
>     Philip>     that re-evaluates a manual list of options use
>     Philip>     'which-key-dont-use-unicode' to determine their default value.
>     
>     Philip>     https://lists.gnu.org/archive/html/help-gnu-emacs/2024-06/msg00130.html
>
> This commit causes `which-key-separator' and `which-key-ellipsis' to
> be nil for me (after `which-key-mode'). Reverting this commit fixes it.

Eh, that might be because `which-key-dont-use-unicode' is being
evaluated before the other two options, but the :set function is giving
them initial values (nil), even though we haven't determined their
default value yet.

Does


[-- Attachment #2: Type: text/plain, Size: 412 bytes --]

diff --git a/lisp/which-key.el b/lisp/which-key.el
index 91007ce4ada..8b78bfb2576 100644
--- a/lisp/which-key.el
+++ b/lisp/which-key.el
@@ -133,6 +133,7 @@ which-key-dont-use-unicode
          (mapc #'custom-reevaluate-setting
                '(which-key-separator
                  which-key-ellipsis)))
+  :initialize #'custom-initialize-changed
   :type 'boolean
   :package-version "1.0" :version "30.1")
 

[-- Attachment #3: Type: text/plain, Size: 115 bytes --]


make sense?  I am always uncertain which :initialize value to use.

> Robert

-- 
	Philip Kaludercic on peregrine

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

[Robert Pluim]

>>>>> 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 😀

Robert
-- 

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

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

[Robert Pluim]

>>>>> On Mon, 24 Jun 2024 18:49:43 +0000, Philip Kaludercic <philipk@posteo.net> said:
    >> That works for me, although I wonʼt claim to understand why 😀

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

I spoke too soon, or my testing was wrong, Iʼm still getting
`which-key-separator' as nil when I customize
`which-key-dont-use-unicode' to nil in emacs-30.

Do you want a M-x report-emacs-bug?

Robert
-- 

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 18:49:43 +0000, Philip Kaludercic <philipk@posteo.net> said:
>     >> That works for me, although I wonʼt claim to understand why 😀
>
>     Philip> My reasoning is that this will only run the setter if the value is
>     Philip> /changed/, right?  So if we set `which-key-dont-use-unicode' is set
>     Philip> before we load which-key, then the user option inherits the
>     Philip> configuration and the other two options use the current value to
>     Philip> determine their default value.  If on the other hand we change the user
>     Philip> option after which-key has been loaded, then the custom setter will take
>     Philip> effect, and will re-load the default value, which has previously been
>     Philip> set to the (if ...) expression, as was the case before.
>
> I spoke too soon, or my testing was wrong, Iʼm still getting
> `which-key-separator' as nil when I customize
> `which-key-dont-use-unicode' to nil in emacs-30.
>
> Do you want a M-x report-emacs-bug?

I think that would make sense.

> Robert

-- 
	Philip Kaludercic on peregrine

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

[Robert Pluim]

>>>>> On Fri, 12 Jul 2024 13:40:14 +0000, Philip Kaludercic <philipk@posteo.net> said:

    Philip> Robert Pluim <rpluim@gmail.com> writes:
    >>>>>>> On Mon, 24 Jun 2024 18:49:43 +0000, Philip Kaludercic <philipk@posteo.net> said:
    >> >> That works for me, although I wonʼt claim to understand why 😀
    >> 
    Philip> My reasoning is that this will only run the setter if the value is
    Philip> /changed/, right?  So if we set `which-key-dont-use-unicode' is set
    Philip> before we load which-key, then the user option inherits the
    Philip> configuration and the other two options use the current value to
    Philip> determine their default value.  If on the other hand we change the user
    Philip> option after which-key has been loaded, then the custom setter will take
    Philip> effect, and will re-load the default value, which has previously been
    Philip> set to the (if ...) expression, as was the case before.
    >> 
    >> I spoke too soon, or my testing was wrong, Iʼm still getting
    >> `which-key-separator' as nil when I customize
    >> `which-key-dont-use-unicode' to nil in emacs-30.
    >> 
    >> Do you want a M-x report-emacs-bug?

    Philip> I think that would make sense.

Bug#72077

Robert
--