Hi again,
I've been wondering why the default behaviour of 'ef-themes-toggle' is
to do nothing, when each theme in ef-themes has a dual theme in
principal. Wouldn't it make sense to "guess" that if someone is using
"ef-light" that toggling should change the theme to "ef-dark"? Sort of
something like this:
> From: Philip Kaludercic <philipk@posteo.net>> Date: Tue, 06 Sep 2022 15:21:21 +0000>>> Hi again,
Hello again, :)
> I've been wondering why the default behaviour of 'ef-themes-toggle' is> to do nothing, when each theme in ef-themes has a dual theme in> principal. Wouldn't it make sense to "guess" that if someone is using> "ef-light" that toggling should change the theme to "ef-dark"? Sort of> something like this:
This makes sense. I just thought it would be better for the user to
experiment a bit with the available themes before setting on a pair.
About the light/dark variants, some are like you say, though not all.
For example, ef-day and ef-autumn are the two red+yellow+green ones,
whereas ef-spring and ef-night are more blue+green. A user might prefer
them, in this regard, instead of going for opposites.
Perhaps we could invoke 'ef-themes-select' instead of throwing an error
or the DWIM you propose? I also notice that the error should mention
'ef-themes-to-toggle' to better inform the user.
> [... 36 lines elided]> Though it might also be a good idea to prepare an upstream patch for a> general 'toggle-theme' command (probably making use of symbol> properties) that wouldn't just be restricted to ef-themes, but could> also be used by the modus-themes, leuven, tango, etc.
Yes, this sounds good. Two more useful ideas for emacs.git:
+ A hook for the post 'load-theme' phase. What I now have in the manual
for a theme-agnostic approach:
(defvar after-enable-theme-hook nil
"Normal hook run after enabling a theme.")
(defun run-after-enable-theme-hook (&rest _args)
"Run `after-enable-theme-hook'."
(run-hooks 'after-enable-theme-hook))
(advice-add 'enable-theme :after #'run-after-enable-theme-hook)
+ Some user option or, generally, some better way to inform the user
that 'load-theme' does not disable other themes and that blending them
may not be desirable.
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
>> From: Philip Kaludercic <philipk@posteo.net>>> Date: Tue, 06 Sep 2022 15:21:21 +0000>>>>>> Hi again,>> Hello again, :)>>> I've been wondering why the default behaviour of 'ef-themes-toggle' is>> to do nothing, when each theme in ef-themes has a dual theme in>> principal. Wouldn't it make sense to "guess" that if someone is using>> "ef-light" that toggling should change the theme to "ef-dark"? Sort of>> something like this:>> This makes sense. I just thought it would be better for the user to> experiment a bit with the available themes before setting on a pair.>> About the light/dark variants, some are like you say, though not all.> For example, ef-day and ef-autumn are the two red+yellow+green ones,> whereas ef-spring and ef-night are more blue+green. A user might prefer> them, in this regard, instead of going for opposites.>> Perhaps we could invoke 'ef-themes-select' instead of throwing an error> or the DWIM you propose? I also notice that the error should mention> 'ef-themes-to-toggle' to better inform the user.
That would also be a good idea.
>> [... 36 lines elided]>>> Though it might also be a good idea to prepare an upstream patch for a>> general 'toggle-theme' command (probably making use of symbol>> properties) that wouldn't just be restricted to ef-themes, but could>> also be used by the modus-themes, leuven, tango, etc.>> Yes, this sounds good.
I'll prepare a patch.
> Two more useful ideas for emacs.git:>> + A hook for the post 'load-theme' phase. What I now have in the manual> for a theme-agnostic approach:>> (defvar after-enable-theme-hook nil> "Normal hook run after enabling a theme.")>> (defun run-after-enable-theme-hook (&rest _args)> "Run `after-enable-theme-hook'."> (run-hooks 'after-enable-theme-hook))>> (advice-add 'enable-theme :after #'run-after-enable-theme-hook)
Do you have any use-cases for this hook?
> + Some user option or, generally, some better way to inform the user> that 'load-theme' does not disable other themes and that blending them> may not be desirable.
So something like `custom-ensure-single-theme'?
> From: Philip Kaludercic <philipk@posteo.net>> Date: Tue, 06 Sep 2022 16:08:13 +0000> [... 25 lines elided]>> Perhaps we could invoke 'ef-themes-select' instead of throwing an error>> or the DWIM you propose? I also notice that the error should mention>> 'ef-themes-to-toggle' to better inform the user.>> That would also be a good idea.
Okay, I will review it. Unless you still prefer the DWIM, which I am
fine with as well.
>>> [... 36 lines elided]>>>>> Though it might also be a good idea to prepare an upstream patch for a>>> general 'toggle-theme' command (probably making use of symbol>>> properties) that wouldn't just be restricted to ef-themes, but could>>> also be used by the modus-themes, leuven, tango, etc.>>>> Yes, this sounds good. >> I'll prepare a patch.
I will keep an eye on the bug tracker.
>> Two more useful ideas for emacs.git:>>>> + A hook for the post 'load-theme' phase. What I now have in the manual>> for a theme-agnostic approach:>>>> (defvar after-enable-theme-hook nil>> "Normal hook run after enabling a theme.")>>>> (defun run-after-enable-theme-hook (&rest _args)>> "Run `after-enable-theme-hook'.">> (run-hooks 'after-enable-theme-hook))>>>> (advice-add 'enable-theme :after #'run-after-enable-theme-hook)>> Do you have any use-cases for this hook?
For example:
(defun my-ef-themes-hl-todo-faces ()
"Configure `hl-todo-keyword-faces' with Ef themes colors.
The exact color values are taken from the active Ef theme."
(ef-themes-with-colors
(setq hl-todo-keyword-faces
`(("HOLD" . ,yellow)
("TODO" . ,red)
("NEXT" . ,blue)
("THEM" . ,magenta)
("PROG" . ,cyan-warmer)
("OKAY" . ,green-warmer)
("DONT" . ,yellow-warmer)
("FAIL" . ,red-warmer)
("BUG" . ,red-warmer)
("DONE" . ,green)
("NOTE" . ,blue-warmer)
("KLUDGE" . ,cyan)
("HACK" . ,cyan)
("TEMP" . ,red)
("FIXME" . ,red-warmer)
("XXX+" . ,red-warmer)
("REVIEW" . ,red)
("DEPRECATED" . ,yellow)))))
(add-hook 'ef-themes-post-load-hook #'my-ef-themes-hl-todo-faces)
A post-load-theme hook is useful when we need to update colours/faces
based on the active theme.
>> + Some user option or, generally, some better way to inform the user>> that 'load-theme' does not disable other themes and that blending them>> may not be desirable.>> So something like `custom-ensure-single-theme'?
Indeed!
--
Protesilaos Stavrou
https://protesilaos.com
> From: Protesilaos Stavrou <info@protesilaos.com>> Date: Tue, 06 Sep 2022 19:15:04 +0300>>>> Perhaps we could invoke 'ef-themes-select' instead of throwing an error>>> or the DWIM you propose? I also notice that the error should mention>>> 'ef-themes-to-toggle' to better inform the user.>>>> That would also be a good idea.>> Okay, I will review it. Unless you still prefer the DWIM, which I am> fine with as well.
Just to note that I implemented the change in commit fd1bd35. I think
this is a better behaviour, though please do let me know if you want to
change it.
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
>> From: Protesilaos Stavrou <info@protesilaos.com>>> Date: Tue, 06 Sep 2022 19:15:04 +0300>>>>>> Perhaps we could invoke 'ef-themes-select' instead of throwing an error>>>> or the DWIM you propose? I also notice that the error should mention>>>> 'ef-themes-to-toggle' to better inform the user.>>>>>> That would also be a good idea.>>>> Okay, I will review it. Unless you still prefer the DWIM, which I am>> fine with as well.>> Just to note that I implemented the change in commit fd1bd35. I think> this is a better behaviour, though please do let me know if you want to> change it.
diff --git a/ef-themes.el b/ef-themes.el
index 2039ac3..5a7d962 100644
--- a/ef-themes.el
+++ b/ef-themes.el
@@ -336,12 +336,14 @@ sequence given SEQ-PRED, using SEQ-DEFAULT as a fallback."
(defvar ef-themes--select-theme-history nil)
-(defun ef-themes--select-prompt ()
- "Minibuffer prompt for `ef-themes-select'."
- (completing-read "Select Ef Theme: "
- (ef-themes--list-known-themes)
- nil t nil
- 'ef-themes--select-theme-history))
+(defun ef-themes--select-prompt (&optional prompt)
+ "Minibuffer prompt for `ef-themes-select'.
+With optional PROMPT string, use it. Else use a generic prompt."
+ (intern
+ (completing-read (or prompt "Select Ef Theme: ")
+ (ef-themes--list-known-themes)
+ nil t nil
+ 'ef-themes--select-theme-history)))
Would adding a default option make sense if there exists a dual theme?
(defun ef-themes--load-theme (theme)
"Load THEME while disabling other Ef themes.
@@ -354,7 +356,7 @@ Run `ef-themes-post-load-hook'."
(defun ef-themes-select (theme)
"Load an Ef THEME using minibuffer completion.
When called from Lisp, THEME is a symbol."
- (interactive (list (intern (ef-themes--select-prompt))))
+ (interactive (list (ef-themes--select-prompt)))
(ef-themes--load-theme theme))
(defun ef-themes--toggle-theme-p ()
@@ -367,16 +369,22 @@ When called from Lisp, THEME is a symbol."
;;;###autoload
(defun ef-themes-toggle ()
- "Toggle between the two `ef-themes-to-toggle'."
+ "Toggle between the two `ef-themes-to-toggle'.
+If `ef-themes-to-toggle' does not specify two Ef themes, inform
+the user about it while prompting with completion for a theme
+among our collection (this is practically the same as the
+`ef-themes-select' command)."
(interactive)
- (when-let* ((themes (ef-themes--toggle-theme-p))
- (one (car themes))
- (two (cadr themes)))
- (unless (eq (length themes) 2)
- (user-error "Can only toggle between two themes"))
I still think it is useful to check for the well-formedness of the list,
i.e. that it consists of two elements. Unless of course one would want
to generalise it and instead of this being a toggling function make it a
cycling function?
- (if (eq (car custom-enabled-themes) one)
- (ef-themes--load-theme two)
- (ef-themes--load-theme one))))
+ (if-let* ((themes (ef-themes--toggle-theme-p))
+ (one (car themes))
+ (two (cadr themes)))
+ (if (eq (car custom-enabled-themes) one)
+ (ef-themes--load-theme two)
+ (ef-themes--load-theme one))
+ (ef-themes--load-theme
+ (ef-themes--select-prompt
+ (concat (propertize "Set two `ef-themes-to-toggle';" 'face 'error)
Why is this highlighted? I found the prompt confusing at first, until I
realised what was going on in the background.
+ " switching to theme selection for now: ")))))
(defun ef-themes--minus-current (&optional variant)
"Return list of Ef themes minus the current one.
> From: Philip Kaludercic <philipk@posteo.net>> Date: Tue, 06 Sep 2022 17:47:01 +0000> [... 26 lines elided]> > -(defun ef-themes--select-prompt ()> - "Minibuffer prompt for `ef-themes-select'."> - (completing-read "Select Ef Theme: "> - (ef-themes--list-known-themes)> - nil t nil> - 'ef-themes--select-theme-history))> +(defun ef-themes--select-prompt (&optional prompt)> + "Minibuffer prompt for `ef-themes-select'.> +With optional PROMPT string, use it. Else use a generic prompt."> + (intern> + (completing-read (or prompt "Select Ef Theme: ")> + (ef-themes--list-known-themes)> + nil t nil> + 'ef-themes--select-theme-history)))>> Would adding a default option make sense if there exists a dual theme?
Good idea! Do you want to do it?
> [... 13 lines elided]> ;;;###autoload> (defun ef-themes-toggle ()> - "Toggle between the two `ef-themes-to-toggle'."> + "Toggle between the two `ef-themes-to-toggle'.> +If `ef-themes-to-toggle' does not specify two Ef themes, inform> +the user about it while prompting with completion for a theme> +among our collection (this is practically the same as the> +`ef-themes-select' command)."> (interactive)> - (when-let* ((themes (ef-themes--toggle-theme-p))> - (one (car themes))> - (two (cadr themes)))> - (unless (eq (length themes) 2)> - (user-error "Can only toggle between two themes"))>> I still think it is useful to check for the well-formedness of the list,> i.e. that it consists of two elements. Unless of course one would want> to generalise it and instead of this being a toggling function make it a> cycling function?
Now it only errors if an element in 'ef-themes-to-toggle' is not part of
the collection. If there are three elements, it just uses the first
two. Though yes, I am fine with making this more strict.
> - (if (eq (car custom-enabled-themes) one)> - (ef-themes--load-theme two)> - (ef-themes--load-theme one))))> + (if-let* ((themes (ef-themes--toggle-theme-p))> + (one (car themes))> + (two (cadr themes)))> + (if (eq (car custom-enabled-themes) one)> + (ef-themes--load-theme two)> + (ef-themes--load-theme one))> + (ef-themes--load-theme> + (ef-themes--select-prompt> + (concat (propertize "Set two `ef-themes-to-toggle';" 'face 'error)>> Why is this highlighted? I found the prompt confusing at first, until I> realised what was going on in the background.
I went over-the-top. Will remove the effect.
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
>>> Two more useful ideas for emacs.git:>>>>>> + A hook for the post 'load-theme' phase. What I now have in the manual>>> for a theme-agnostic approach:>>>>>> (defvar after-enable-theme-hook nil>>> "Normal hook run after enabling a theme.")>>>>>> (defun run-after-enable-theme-hook (&rest _args)>>> "Run `after-enable-theme-hook'.">>> (run-hooks 'after-enable-theme-hook))>>>>>> (advice-add 'enable-theme :after #'run-after-enable-theme-hook)>>>> Do you have any use-cases for this hook?>> For example:>> (defun my-ef-themes-hl-todo-faces ()> "Configure `hl-todo-keyword-faces' with Ef themes colors.> The exact color values are taken from the active Ef theme."> (ef-themes-with-colors> (setq hl-todo-keyword-faces> `(("HOLD" . ,yellow)> ("TODO" . ,red)> ("NEXT" . ,blue)> ("THEM" . ,magenta)> ("PROG" . ,cyan-warmer)> ("OKAY" . ,green-warmer)> ("DONT" . ,yellow-warmer)> ("FAIL" . ,red-warmer)> ("BUG" . ,red-warmer)> ("DONE" . ,green)> ("NOTE" . ,blue-warmer)> ("KLUDGE" . ,cyan)> ("HACK" . ,cyan)> ("TEMP" . ,red)> ("FIXME" . ,red-warmer)> ("XXX+" . ,red-warmer)> ("REVIEW" . ,red)> ("DEPRECATED" . ,yellow)))))>> (add-hook 'ef-themes-post-load-hook #'my-ef-themes-hl-todo-faces)>> A post-load-theme hook is useful when we need to update colours/faces> based on the active theme.
BTW it appears that this has been added with Emacs 29:
---
*** New hooks 'enable-theme-functions' and 'disable-theme-functions'.
These are run after enabling and disabling a theme, respectively.
> From: Philip Kaludercic <philipk@posteo.net>> Date: Tue, 06 Sep 2022 18:45:27 +0000> [... 50 lines elided]> BTW it appears that this has been added with Emacs 29:>> ---> *** New hooks 'enable-theme-functions' and 'disable-theme-functions'.> These are run after enabling and disabling a theme, respectively.
Ah good! I thought I saw it but was searching for "load theme" and
couldn't find it.
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
>> From: Philip Kaludercic <philipk@posteo.net>>> Date: Tue, 06 Sep 2022 17:47:01 +0000>>> [... 26 lines elided]>> >> -(defun ef-themes--select-prompt ()>> - "Minibuffer prompt for `ef-themes-select'.">> - (completing-read "Select Ef Theme: ">> - (ef-themes--list-known-themes)>> - nil t nil>> - 'ef-themes--select-theme-history))>> +(defun ef-themes--select-prompt (&optional prompt)>> + "Minibuffer prompt for `ef-themes-select'.>> +With optional PROMPT string, use it. Else use a generic prompt.">> + (intern>> + (completing-read (or prompt "Select Ef Theme: ")>> + (ef-themes--list-known-themes)>> + nil t nil>> + 'ef-themes--select-theme-history)))>>>> Would adding a default option make sense if there exists a dual theme?>> Good idea! Do you want to do it?
I think that it will first be necessary to define what themes are dual
to one another.
>> [... 13 lines elided]>>> ;;;###autoload>> (defun ef-themes-toggle ()>> - "Toggle between the two `ef-themes-to-toggle'.">> + "Toggle between the two `ef-themes-to-toggle'.>> +If `ef-themes-to-toggle' does not specify two Ef themes, inform>> +the user about it while prompting with completion for a theme>> +among our collection (this is practically the same as the>> +`ef-themes-select' command).">> (interactive)>> - (when-let* ((themes (ef-themes--toggle-theme-p))>> - (one (car themes))>> - (two (cadr themes)))>> - (unless (eq (length themes) 2)>> - (user-error "Can only toggle between two themes"))>>>> I still think it is useful to check for the well-formedness of the list,>> i.e. that it consists of two elements. Unless of course one would want>> to generalise it and instead of this being a toggling function make it a>> cycling function?>> Now it only errors if an element in 'ef-themes-to-toggle' is not part of> the collection. If there are three elements, it just uses the first> two. Though yes, I am fine with making this more strict.>> - (if (eq (car custom-enabled-themes) one)>> - (ef-themes--load-theme two)>> - (ef-themes--load-theme one))))>> + (if-let* ((themes (ef-themes--toggle-theme-p))>> + (one (car themes))>> + (two (cadr themes)))>> + (if (eq (car custom-enabled-themes) one)>> + (ef-themes--load-theme two)>> + (ef-themes--load-theme one))>> + (ef-themes--load-theme>> + (ef-themes--select-prompt>> + (concat (propertize "Set two `ef-themes-to-toggle';" 'face 'error)>>>> Why is this highlighted? I found the prompt confusing at first, until I>> realised what was going on in the background.>> I went over-the-top. Will remove the effect.
1+
> From: Philip Kaludercic <philipk@posteo.net>> Date: Wed, 07 Sep 2022 13:38:47 +0000>> [... 22 lines elided]>>> Would adding a default option make sense if there exists a dual theme?>>>> Good idea! Do you want to do it?>> I think that it will first be necessary to define what themes are dual> to one another.
How about what you suggested initially? Perhaps we just swap ef-autumn
and ef-night:
((ef-deuteranopia-dark ef-deuteranopia-light)
(ef-deuteranopia-light ef-deuteranopia-dark)
(ef-duo-dark ef-duo-light)
(ef-duo-light ef-duo-dark)
(ef-dark ef-light)
(ef-light ef-dark)
(ef-day ef-autumn)
(ef-autumn ef-day)
(ef-night ef-spring)
(ef-spring ef-night)
(ef-summer ef-winter)
(ef-winter ef-summer))
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
>> From: Philip Kaludercic <philipk@posteo.net>>> Date: Wed, 07 Sep 2022 13:38:47 +0000>>>>> [... 22 lines elided]>>>>> Would adding a default option make sense if there exists a dual theme?>>>>>> Good idea! Do you want to do it?>>>> I think that it will first be necessary to define what themes are dual>> to one another.>> How about what you suggested initially? Perhaps we just swap ef-autumn> and ef-night:
What would the point of swapping those two be?
> ((ef-deuteranopia-dark ef-deuteranopia-light)> (ef-deuteranopia-light ef-deuteranopia-dark)> (ef-duo-dark ef-duo-light)> (ef-duo-light ef-duo-dark)> (ef-dark ef-light)> (ef-light ef-dark)> (ef-day ef-autumn)> (ef-autumn ef-day)> (ef-night ef-spring)> (ef-spring ef-night)> (ef-summer ef-winter)> (ef-winter ef-summer))
> From: Philip Kaludercic <philipk@posteo.net>> Date: Thu, 08 Sep 2022 06:23:26 +0000> [... 16 lines elided]>> How about what you suggested initially? Perhaps we just swap ef-autumn>> and ef-night:>> What would the point of swapping those two be?
It's because ef-day <--> ef-autumn looks more consistent in terms of
overall feel. ef-spring <--> ef-night is also okay in this regard.
Though, strictly speaking, each of those themes was developed
independently without a true pair. Only those with the "light" or
"dark" in their name are pairs, even if some of their colour mappings
differ.
So the pairs are:
ef-{light,dark}
ef-deuteranopia-{light,dark}
ef-duo-{light,dark}
The rest are free-for-all, which was why 'ef-themes-to-toggle' did not
assume a light/dark binary (one might like toggling between two light
themes or two dark ones).
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
>> From: Philip Kaludercic <philipk@posteo.net>>> Date: Thu, 08 Sep 2022 06:23:26 +0000>>> [... 16 lines elided]>>>> How about what you suggested initially? Perhaps we just swap ef-autumn>>> and ef-night:>>>> What would the point of swapping those two be?>> It's because ef-day <--> ef-autumn looks more consistent in terms of> overall feel. ef-spring <--> ef-night is also okay in this regard.
I see, "day" and "autumn" do look nice, but "spring" and "night" appear
unrelated if you ask me :/
> Though, strictly speaking, each of those themes was developed> independently without a true pair. Only those with the "light" or> "dark" in their name are pairs, even if some of their colour mappings> differ.>> So the pairs are:>> ef-{light,dark}> ef-deuteranopia-{light,dark}> ef-duo-{light,dark}>> The rest are free-for-all, which was why 'ef-themes-to-toggle' did not> assume a light/dark binary (one might like toggling between two light> themes or two dark ones).
I guess it is too late to re-define the themes now, perhaps another
idea would might be to cycle through the seasons?
> From: Philip Kaludercic <philipk@posteo.net>> Date: Thu, 08 Sep 2022 07:20:32 +0000> [... 11 lines elided]>>> What would the point of swapping those two be?>>>> It's because ef-day <--> ef-autumn looks more consistent in terms of>> overall feel. ef-spring <--> ef-night is also okay in this regard.>> I see, "day" and "autumn" do look nice, but "spring" and "night" appear> unrelated if you ask me :/
You are right. It's just the closest they get, given they were designed
independent of each other.
>> Though, strictly speaking, each of those themes was developed>> independently without a true pair. Only those with the "light" or>> "dark" in their name are pairs, even if some of their colour mappings>> differ.>>>> So the pairs are:>>>> ef-{light,dark}>> ef-deuteranopia-{light,dark}>> ef-duo-{light,dark}>>>> The rest are free-for-all, which was why 'ef-themes-to-toggle' did not>> assume a light/dark binary (one might like toggling between two light>> themes or two dark ones).>> I guess it is too late to re-define the themes now, perhaps another> idea would might be to cycle through the seasons?
Changing the themes is not easy. Though not because it is too late, but
due to inherent constraints with colours. For example, ef-summer can
only work as a light theme. We cannot get a pinkish background in a
dark theme, as pink is very close to white. We thus have to switch to a
very dark purple which then affects all relevant foregrounds.
About cycling through the seasons, my concern is to not give new users
the wrong impression over what ef-themes-toggle actually does. I prefer
to set the pairs you had suggested, as those are more-or-less okay.
Cycling might give the impression that this is how the command normally
works.
Or did I misunderstand your proposal? Maybe you mean a separate
ef-themes-cycle command? It could work. Though maybe we can just tweak
ef-themes-load-random to only load what hasn't been loaded yet? I think
there was a recent change in tetris.el about a method like this...
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
>> From: Philip Kaludercic <philipk@posteo.net>>> Date: Thu, 08 Sep 2022 07:20:32 +0000>>> [... 11 lines elided]>>>>> What would the point of swapping those two be?>>>>>> It's because ef-day <--> ef-autumn looks more consistent in terms of>>> overall feel. ef-spring <--> ef-night is also okay in this regard.>>>> I see, "day" and "autumn" do look nice, but "spring" and "night" appear>> unrelated if you ask me :/>> You are right. It's just the closest they get, given they were designed> independent of each other.>>>> Though, strictly speaking, each of those themes was developed>>> independently without a true pair. Only those with the "light" or>>> "dark" in their name are pairs, even if some of their colour mappings>>> differ.>>>>>> So the pairs are:>>>>>> ef-{light,dark}>>> ef-deuteranopia-{light,dark}>>> ef-duo-{light,dark}>>>>>> The rest are free-for-all, which was why 'ef-themes-to-toggle' did not>>> assume a light/dark binary (one might like toggling between two light>>> themes or two dark ones).>>>> I guess it is too late to re-define the themes now, perhaps another>> idea would might be to cycle through the seasons?>> Changing the themes is not easy. Though not because it is too late, but> due to inherent constraints with colours. For example, ef-summer can> only work as a light theme. We cannot get a pinkish background in a> dark theme, as pink is very close to white. We thus have to switch to a> very dark purple which then affects all relevant foregrounds.
I see. It might be that we are overthinking it, and that having two
dual themes with different hues isn't that big of a deal. After all, if
the user disagrees with the DWIM defaults, they can just override the
option.
> About cycling through the seasons, my concern is to not give new users> the wrong impression over what ef-themes-toggle actually does. I prefer> to set the pairs you had suggested, as those are more-or-less okay.> Cycling might give the impression that this is how the command normally> works.>> Or did I misunderstand your proposal? Maybe you mean a separate> ef-themes-cycle command? It could work. Though maybe we can just tweak> ef-themes-load-random to only load what hasn't been loaded yet? I think> there was a recent change in tetris.el about a method like this...
My interest has now moved on to a generalised variant of
`ef-themes-toggle' that is being discussed in bug#57639. I think that
therefore my proposal here should be kept simple and we ought just to
add a defconst with DWIM theme associations that will be made use of if
the user hasn't configured anything, just so that `ef-themes-toggle'
doesn't do nothing when invoked.
> From: Philip Kaludercic <philipk@posteo.net>> Date: Sun, 11 Sep 2022 08:34:44 +0000>> [... 36 lines elided]>>> Changing the themes is not easy. Though not because it is too late, but>> due to inherent constraints with colours. For example, ef-summer can>> only work as a light theme. We cannot get a pinkish background in a>> dark theme, as pink is very close to white. We thus have to switch to a>> very dark purple which then affects all relevant foregrounds.>> I see. It might be that we are overthinking it, and that having two> dual themes with different hues isn't that big of a deal. After all, if> the user disagrees with the DWIM defaults, they can just override the> option.
Exactly! Though read below.
>> About cycling through the seasons, my concern is to not give new users>> the wrong impression over what ef-themes-toggle actually does. I prefer>> to set the pairs you had suggested, as those are more-or-less okay.>> Cycling might give the impression that this is how the command normally>> works.>>>> Or did I misunderstand your proposal? Maybe you mean a separate>> ef-themes-cycle command? It could work. Though maybe we can just tweak>> ef-themes-load-random to only load what hasn't been loaded yet? I think>> there was a recent change in tetris.el about a method like this...>> My interest has now moved on to a generalised variant of> `ef-themes-toggle' that is being discussed in bug#57639.
Okay, I just read it. I think this is a better solution for the
long-term. I will be monitoring the bug and make the requisite changes
for the modus-themes as well. Unless you want to prepare the relevant
patch.
> I think that therefore my proposal here should be kept simple and we> ought just to add a defconst with DWIM theme associations that will be> made use of if the user hasn't configured anything, just so that> `ef-themes-toggle' doesn't do nothing when invoked.
Yesterday I published the latest version of the ef-themes before reading
this. The current design is to fall back to minibuffer completion.
Perhaps we can just wait to see how your patch takes form in emacs.git
and then to the same with the themes here?
--
Protesilaos Stavrou
https://protesilaos.com