* Re: emacs-30 768e92b9c02: Update options that depend on 'which-key-dont-use-unicode' [not found] ` <20240624074638.294E1C1FB6E@vcs2.savannah.gnu.org> @ 2024-06-24 14:32 ` Robert Pluim 2024-06-24 15:01 ` Philip Kaludercic 0 siblings, 1 reply; 7+ messages in thread From: Robert Pluim @ 2024-06-24 14:32 UTC (permalink / raw) To: Philip Kaludercic; +Cc: emacs-devel >>>>> 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 -- ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: emacs-30 768e92b9c02: Update options that depend on 'which-key-dont-use-unicode' 2024-06-24 14:32 ` emacs-30 768e92b9c02: Update options that depend on 'which-key-dont-use-unicode' Robert Pluim @ 2024-06-24 15:01 ` Philip Kaludercic 2024-06-24 17:14 ` Robert Pluim 0 siblings, 1 reply; 7+ messages in thread From: Philip Kaludercic @ 2024-06-24 15:01 UTC (permalink / raw) To: Robert Pluim; +Cc: emacs-devel [-- 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: emacs-30 768e92b9c02: Update options that depend on 'which-key-dont-use-unicode' 2024-06-24 15:01 ` Philip Kaludercic @ 2024-06-24 17:14 ` Robert Pluim 2024-06-24 18:49 ` Philip Kaludercic 0 siblings, 1 reply; 7+ messages in thread From: Robert Pluim @ 2024-06-24 17:14 UTC (permalink / raw) To: Philip Kaludercic; +Cc: emacs-devel >>>>> 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 -- ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: emacs-30 768e92b9c02: Update options that depend on 'which-key-dont-use-unicode' 2024-06-24 17:14 ` Robert Pluim @ 2024-06-24 18:49 ` Philip Kaludercic 2024-07-11 9:40 ` Robert Pluim 0 siblings, 1 reply; 7+ messages in thread From: Philip Kaludercic @ 2024-06-24 18:49 UTC (permalink / raw) To: Robert Pluim; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: emacs-30 768e92b9c02: Update options that depend on 'which-key-dont-use-unicode' 2024-06-24 18:49 ` Philip Kaludercic @ 2024-07-11 9:40 ` Robert Pluim 2024-07-12 13:40 ` Philip Kaludercic 0 siblings, 1 reply; 7+ messages in thread From: Robert Pluim @ 2024-07-11 9:40 UTC (permalink / raw) To: Philip Kaludercic; +Cc: emacs-devel >>>>> 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 -- ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: emacs-30 768e92b9c02: Update options that depend on 'which-key-dont-use-unicode' 2024-07-11 9:40 ` Robert Pluim @ 2024-07-12 13:40 ` Philip Kaludercic 2024-07-12 14:38 ` Robert Pluim 0 siblings, 1 reply; 7+ messages in thread From: Philip Kaludercic @ 2024-07-12 13:40 UTC (permalink / raw) To: Robert Pluim; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: emacs-30 768e92b9c02: Update options that depend on 'which-key-dont-use-unicode' 2024-07-12 13:40 ` Philip Kaludercic @ 2024-07-12 14:38 ` Robert Pluim 0 siblings, 0 replies; 7+ messages in thread From: Robert Pluim @ 2024-07-12 14:38 UTC (permalink / raw) To: Philip Kaludercic; +Cc: emacs-devel >>>>> 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 -- ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-07-12 14:38 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <171921519771.16563.15139426619834982564@vcs2.savannah.gnu.org>
[not found] ` <20240624074638.294E1C1FB6E@vcs2.savannah.gnu.org>
2024-06-24 14:32 ` emacs-30 768e92b9c02: Update options that depend on 'which-key-dont-use-unicode' Robert Pluim
2024-06-24 15:01 ` Philip Kaludercic
2024-06-24 17:14 ` Robert Pluim
2024-06-24 18:49 ` Philip Kaludercic
2024-07-11 9:40 ` Robert Pluim
2024-07-12 13:40 ` Philip Kaludercic
2024-07-12 14:38 ` Robert Pluim
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).