Setting 'which-key-dont-use-unicode'

Setting 'which-key-dont-use-unicode'

[Kévin Le Gouguec]

Hello!

Paging help-gnu-emacs before filing a bug because I'm not sure of the
intended behavior.  After seeing 2024-06-18 "Disable usage of unicode
for which-key by default" (cc0a3a5f65b), I promptly went to my .emacs to
opt in to Unicode symbols, and was surprised to meet some resistance.

In an Emacs built from 2024-06-23 "; Fix typos" (fb11294d415) on the
emacs-30 branch, I tried

  (a) this .emacs:

    (use-package which-key
      :custom
      (which-key-dont-use-unicode nil)
      (which-key-mode t))

  (b) this .emacs:

    (custom-set-variables
     '(which-key-dont-use-unicode nil)
     '(which-key-mode t))

  (c) an empty .emacs, then

    M-x which-key-mode
    M-x toggle-option which-key-dont-use-unicode

  (d) a combination of this .emacs:

    (use-package which-key
      :custom
      (which-key-mode t))

  with this .emacs.d/early-init.el:

    (setq which-key-dont-use-unicode nil)

and only attempt (d) yielded which-key messages with '→' instead of ':'
for the separator symbol (resp. '…' instead of '..'  for truncation).

Wondering if I am doing something wrong (a definite possibility, the
perils of juggling ${HOME}s for repro purposes), if (d) really is the
intended way to effectively unset which-key-dont-use-unicode, or if this
is a potential bug report or feature request?

Re: Setting 'which-key-dont-use-unicode'

[Justin Burkett]

Hi,

First, don't set which-key-mode as a custom variable. This is a
function that should be called after which-key is loaded.

For your original question, the important thing is that
which-key-dont-use-unicode is set before which-key is loaded. (c)
definitely won't work for this reason. The fact that (d) is working,
which takes this logic to the extreme, but the others are not suggests
that something is causing which-key to load before the variable is
set.

Combining the two ideas, try

(use-package which-key
  :custom
  (which-key-dont-use-unicode nil)
  :config
  (which-key-mode t))

If that doesn't work, look for another culprit that might be loading
which-key (perhaps because it depends on it) earlier.

Justin

On Sun, Jun 23, 2024 at 5:05 PM Kévin Le Gouguec
<kevin.legouguec@gmail.com> wrote:
>
> Hello!
>
> Paging help-gnu-emacs before filing a bug because I'm not sure of the
> intended behavior.  After seeing 2024-06-18 "Disable usage of unicode
> for which-key by default" (cc0a3a5f65b), I promptly went to my .emacs to
> opt in to Unicode symbols, and was surprised to meet some resistance.
>
> In an Emacs built from 2024-06-23 "; Fix typos" (fb11294d415) on the
> emacs-30 branch, I tried
>
>   (a) this .emacs:
>
>     (use-package which-key
>       :custom
>       (which-key-dont-use-unicode nil)
>       (which-key-mode t))
>
>   (b) this .emacs:
>
>     (custom-set-variables
>      '(which-key-dont-use-unicode nil)
>      '(which-key-mode t))
>
>   (c) an empty .emacs, then
>
>     M-x which-key-mode
>     M-x toggle-option which-key-dont-use-unicode
>
>   (d) a combination of this .emacs:
>
>     (use-package which-key
>       :custom
>       (which-key-mode t))
>
>   with this .emacs.d/early-init.el:
>
>     (setq which-key-dont-use-unicode nil)
>
> and only attempt (d) yielded which-key messages with '→' instead of ':'
> for the separator symbol (resp. '…' instead of '..'  for truncation).
>
> Wondering if I am doing something wrong (a definite possibility, the
> perils of juggling ${HOME}s for repro purposes), if (d) really is the
> intended way to effectively unset which-key-dont-use-unicode, or if this
> is a potential bug report or feature request?

Re: Setting 'which-key-dont-use-unicode'

[Philip Kaludercic]

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

Justin Burkett <justin@burkett.cc> writes:

> Hi,
>
> First, don't set which-key-mode as a custom variable. This is a
> function that should be called after which-key is loaded.

That is actually fine, since every minor mode is also a user option.

> For your original question, the important thing is that
> which-key-dont-use-unicode is set before which-key is loaded. 

We can easily fix this by adding a custom setter:


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

diff --git a/lisp/which-key.el b/lisp/which-key.el
index e9567d262c6..33fa67e9bac 100644
--- a/lisp/which-key.el
+++ b/lisp/which-key.el
@@ -128,6 +128,11 @@ which-key-dont-use-unicode
   "If non-nil, don't use any unicode characters in default setup.
 For affected settings, see `which-key-replacement-alist', `which-key-ellipsis'
 `which-key-separator'."
+  :set (lambda (sym val)
+         (prog1 (custom-set-default sym val)
+           (dolist (sym '(which-key-separator
+                          which-key-ellipsis))
+             (custom-set-default sym (custom-reevaluate-setting sym)))))
   :type 'boolean
   :package-version "1.0" :version "30.1")
 

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


Using Emacs -Q and

(setopt which-key-mode t        ;loads which-key.el
        which-key-dont-use-unicode nil)

I get the expected behaviour.

>                                                               (c)
> definitely won't work for this reason. The fact that (d) is working,
> which takes this logic to the extreme, but the others are not suggests
> that something is causing which-key to load before the variable is
> set.
>
> Combining the two ideas, try
>
> (use-package which-key
>   :custom
>   (which-key-dont-use-unicode nil)
>   :config
>   (which-key-mode t))
>
> If that doesn't work, look for another culprit that might be loading
> which-key (perhaps because it depends on it) earlier.
>
> Justin
>
> On Sun, Jun 23, 2024 at 5:05 PM Kévin Le Gouguec
> <kevin.legouguec@gmail.com> wrote:
>>
>> Hello!
>>
>> Paging help-gnu-emacs before filing a bug because I'm not sure of the
>> intended behavior.  After seeing 2024-06-18 "Disable usage of unicode
>> for which-key by default" (cc0a3a5f65b), I promptly went to my .emacs to
>> opt in to Unicode symbols, and was surprised to meet some resistance.
>>
>> In an Emacs built from 2024-06-23 "; Fix typos" (fb11294d415) on the
>> emacs-30 branch, I tried
>>
>>   (a) this .emacs:
>>
>>     (use-package which-key
>>       :custom
>>       (which-key-dont-use-unicode nil)
>>       (which-key-mode t))
>>
>>   (b) this .emacs:
>>
>>     (custom-set-variables
>>      '(which-key-dont-use-unicode nil)
>>      '(which-key-mode t))
>>
>>   (c) an empty .emacs, then
>>
>>     M-x which-key-mode
>>     M-x toggle-option which-key-dont-use-unicode
>>
>>   (d) a combination of this .emacs:
>>
>>     (use-package which-key
>>       :custom
>>       (which-key-mode t))
>>
>>   with this .emacs.d/early-init.el:
>>
>>     (setq which-key-dont-use-unicode nil)
>>
>> and only attempt (d) yielded which-key messages with '→' instead of ':'
>> for the separator symbol (resp. '…' instead of '..'  for truncation).
>>
>> Wondering if I am doing something wrong (a definite possibility, the
>> perils of juggling ${HOME}s for repro purposes), if (d) really is the
>> intended way to effectively unset which-key-dont-use-unicode, or if this
>> is a potential bug report or feature request?

-- 
	Philip Kaludercic on peregrine

Re: Setting 'which-key-dont-use-unicode'

[Kévin Le Gouguec]

Thank you both for the prompt responses!

Philip Kaludercic <philipk@posteo.net> writes:

>> For your original question, the important thing is that
>> which-key-dont-use-unicode is set before which-key is loaded. 
>
> We can easily fix this by adding a custom setter:
>
> diff --git a/lisp/which-key.el b/lisp/which-key.el
> index e9567d262c6..33fa67e9bac 100644
> --- a/lisp/which-key.el
> +++ b/lisp/which-key.el
> @@ -128,6 +128,11 @@ which-key-dont-use-unicode
>    "If non-nil, don't use any unicode characters in default setup.
>  For affected settings, see `which-key-replacement-alist', `which-key-ellipsis'
>  `which-key-separator'."
> +  :set (lambda (sym val)
> +         (prog1 (custom-set-default sym val)
> +           (dolist (sym '(which-key-separator
> +                          which-key-ellipsis))
> +             (custom-set-default sym (custom-reevaluate-setting sym)))))
>    :type 'boolean
>    :package-version "1.0" :version "30.1")
>  
>
>
> Using Emacs -Q and
>
> (setopt which-key-mode t        ;loads which-key.el
>         which-key-dont-use-unicode nil)
>
> I get the expected behaviour.

Thanks; I rebuilt emacs-30 (2024-06-24 "Fix omission of updates to child
frames on Android" (73a58329a69)) with this patch on top; AFAICT it lets
Emacs DTRT with all three "customization idioms", i.e.

  ;; Custom
  (custom-set-variables
   '(which-key-dont-use-unicode nil)
   '(which-key-mode t))

  ;; setopt
  (setopt which-key-mode t
          which-key-dont-use-unicode nil)

  ;; use-package
  (use-package which-key
    :custom
    (which-key-dont-use-unicode nil)
    (which-key-mode t))

And FWIW there does seem to be precedent for that approach:
e.g. ls-lisp-emulation's setter calls ls-lisp-set-options, which resets
all variables tagged :set-after '(ls-lisp-emulation)… except
ls-lisp-use-string-collate; wondering if that's intentional 🤔

(And now wondering if :set-after '(SYMS…) should make this pattern
easier by storing the reverse dependency, e.g. in a new
'custom-dependents property attached to each symbol in SYMS…  Could that
make these setters easier to maintain?)

Anyhoo; straying far from the original report.  Thanks again for
confirming & proposing a fix!

Re: Setting 'which-key-dont-use-unicode'

[Philip Kaludercic]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> Thank you both for the prompt responses!
>
> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> For your original question, the important thing is that
>>> which-key-dont-use-unicode is set before which-key is loaded. 
>>
>> We can easily fix this by adding a custom setter:
>>
>> diff --git a/lisp/which-key.el b/lisp/which-key.el
>> index e9567d262c6..33fa67e9bac 100644
>> --- a/lisp/which-key.el
>> +++ b/lisp/which-key.el
>> @@ -128,6 +128,11 @@ which-key-dont-use-unicode
>>    "If non-nil, don't use any unicode characters in default setup.
>>  For affected settings, see `which-key-replacement-alist', `which-key-ellipsis'
>>  `which-key-separator'."
>> +  :set (lambda (sym val)
>> +         (prog1 (custom-set-default sym val)
>> +           (dolist (sym '(which-key-separator
>> +                          which-key-ellipsis))
>> +             (custom-set-default sym (custom-reevaluate-setting sym)))))
>>    :type 'boolean
>>    :package-version "1.0" :version "30.1")
>>  
>>
>>
>> Using Emacs -Q and
>>
>> (setopt which-key-mode t        ;loads which-key.el
>>         which-key-dont-use-unicode nil)
>>
>> I get the expected behaviour.
>
> Thanks; I rebuilt emacs-30 (2024-06-24 "Fix omission of updates to child
> frames on Android" (73a58329a69)) with this patch on top; AFAICT it lets
> Emacs DTRT with all three "customization idioms", i.e.
>
>   ;; Custom
>   (custom-set-variables
>    '(which-key-dont-use-unicode nil)
>    '(which-key-mode t))
>
>   ;; setopt
>   (setopt which-key-mode t
>           which-key-dont-use-unicode nil)
>
>   ;; use-package
>   (use-package which-key
>     :custom
>     (which-key-dont-use-unicode nil)
>     (which-key-mode t))
>
> And FWIW there does seem to be precedent for that approach:
> e.g. ls-lisp-emulation's setter calls ls-lisp-set-options, which resets
> all variables tagged :set-after '(ls-lisp-emulation)… except
> ls-lisp-use-string-collate; wondering if that's intentional 🤔

I think that was a mistake. `ls-lisp-emulation' was added in 2010, where
all the options it reeevaluates already existed, and
`ls-lisp-use-string-collate' was added in 2014, and it was forgotten to
update `ls-lisp-set-options' as well.

> (And now wondering if :set-after '(SYMS…) should make this pattern
> easier by storing the reverse dependency, e.g. in a new
> 'custom-dependents property attached to each symbol in SYMS…  Could that
> make these setters easier to maintain?)
>
> Anyhoo; straying far from the original report.  Thanks again for
> confirming & proposing a fix!

I have a few ideas on this topic, and we can gladly discuss it in a bug
report.

Until then I'll push a variation on the fix I proposed in my previous
message, and close.... I just realised that this wasn't a bug report, so
never mind that ^^  But if we discuss generalising this fix, we should
do so in a proper bug report that is easy to link to.

-- 
	Philip Kaludercic on peregrine

Re: Setting 'which-key-dont-use-unicode'

[Robert Pluim]

>>>>> On Mon, 24 Jun 2024 07:12:27 +0000, Philip Kaludercic <philipk@posteo.net> said:
    >> And FWIW there does seem to be precedent for that approach:
    >> e.g. ls-lisp-emulation's setter calls ls-lisp-set-options, which resets
    >> all variables tagged :set-after '(ls-lisp-emulation)… except
    >> ls-lisp-use-string-collate; wondering if that's intentional 🤔

    Philip> I think that was a mistake. `ls-lisp-emulation' was added in 2010, where
    Philip> all the options it reeevaluates already existed, and
    Philip> `ls-lisp-use-string-collate' was added in 2014, and it was forgotten to
    Philip> update `ls-lisp-set-options' as well.

Fixed in emacs-30. (this is what happens when my simulations take a
long time to start 😀).

Robert
-- 

Re: Setting 'which-key-dont-use-unicode'

[Kévin Le Gouguec]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Mon, 24 Jun 2024 07:12:27 +0000, Philip Kaludercic <philipk@posteo.net> said:
>     >> And FWIW there does seem to be precedent for that approach:
>     >> e.g. ls-lisp-emulation's setter calls ls-lisp-set-options, which resets
>     >> all variables tagged :set-after '(ls-lisp-emulation)… except
>     >> ls-lisp-use-string-collate; wondering if that's intentional 🤔
>
>     Philip> I think that was a mistake. `ls-lisp-emulation' was added in 2010, where
>     Philip> all the options it reeevaluates already existed, and
>     Philip> `ls-lisp-use-string-collate' was added in 2014, and it was forgotten to
>     Philip> update `ls-lisp-set-options' as well.
>
> Fixed in emacs-30. (this is what happens when my simulations take a
> long time to start 😀).

Thank you both 🙇

Philip Kaludercic <philipk@posteo.net> writes:

>> (And now wondering if :set-after '(SYMS…) should make this pattern
>> easier by storing the reverse dependency, e.g. in a new
>> 'custom-dependents property attached to each symbol in SYMS…  Could that
>> make these setters easier to maintain?)
>>
>> Anyhoo; straying far from the original report.  Thanks again for
>> confirming & proposing a fix!
>
> I have a few ideas on this topic, and we can gladly discuss it in a bug
> report.

ACK; let me know if you'd like me to file that report - as a general
enhancement request for :set-after, IIUC?

Re: Setting 'which-key-dont-use-unicode'

[Philip Kaludercic]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>>>>>>> On Mon, 24 Jun 2024 07:12:27 +0000, Philip Kaludercic <philipk@posteo.net> said:
>>     >> And FWIW there does seem to be precedent for that approach:
>>     >> e.g. ls-lisp-emulation's setter calls ls-lisp-set-options, which resets
>>     >> all variables tagged :set-after '(ls-lisp-emulation)… except
>>     >> ls-lisp-use-string-collate; wondering if that's intentional 🤔
>>
>>     Philip> I think that was a mistake. `ls-lisp-emulation' was added in 2010, where
>>     Philip> all the options it reeevaluates already existed, and
>>     Philip> `ls-lisp-use-string-collate' was added in 2014, and it was forgotten to
>>     Philip> update `ls-lisp-set-options' as well.
>>
>> Fixed in emacs-30. (this is what happens when my simulations take a
>> long time to start 😀).
>
> Thank you both 🙇
>
> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> (And now wondering if :set-after '(SYMS…) should make this pattern
>>> easier by storing the reverse dependency, e.g. in a new
>>> 'custom-dependents property attached to each symbol in SYMS…  Could that
>>> make these setters easier to maintain?)
>>>
>>> Anyhoo; straying far from the original report.  Thanks again for
>>> confirming & proposing a fix!
>>
>> I have a few ideas on this topic, and we can gladly discuss it in a bug
>> report.
>
> ACK; let me know if you'd like me to file that report - as a general
> enhancement request for :set-after, IIUC?

A general enchantment sounds like the best idea.

-- 
	Philip Kaludercic on peregrine