Hi,

I updated my packages—which include the modus-themes—today, and was
invariably hit by more than half of my customisation options being
undefined.  I've read through [1], but I still don't see a clear upgrade
path.  Say I, hypothetically, used to have

    (setq modus-themes-paren-match '(bold intense underline))

in my configuration.  I gather that now I'm supposed to associate
'bg-paren-match' to a colour, but... to which one?  Some colours seem to
have vanished; e.g., setting the above to just '(intense) used to change
the colour to "#c488ff", but I can't find that value anywhere in the new
version.  Is my only option to roll back to before the merge, see what
all my user options did, trace the colour renamings/deletions, and then
associate the new palette overrides to the right thing?  I'm probably
missing something much simpler here.

On a related note: you mentioned (in [1]) that this change was mostly
for cleaning up the code base and making it more maintainable.  If that
is so, and the new palette override system is strictly more powerful
than the old user options, would it perhaps make sense to not obsolete
all of them, but to instead make them change the '*-palette-overrides'
variables?  These options may even be deprecated and removed in a later
release—if the goal is to get rid of them—but it would at least make
sure that users have ample time to copy the relevant bits to their
configuration before anything breaks.

Thanks!
   Tony

[1]: https://protesilaos.com/codelog/2022-12-28-note-modus-themes-4-melpa/

-- 
Tony Zorman | https://tony-zorman.com/

> From: Tony Zorman <soliditsallgood@mailbox.org>
> Date: Thu, 29 Dec 2022 19:04:22 +0100
>
> Hi,

Good day Tony,

> I updated my packages—which include the modus-themes—today, and was
> invariably hit by more than half of my customisation options being
> undefined.  I've read through [1], but I still don't see a clear upgrade
> path.  Say I, hypothetically, used to have
>
>     (setq modus-themes-paren-match '(bold intense underline))
>
> in my configuration.  I gather that now I'm supposed to associate
> 'bg-paren-match' to a colour, but... to which one?

Here is an example:

    (setq modus-themes-common-palette-overrides
          '((bg-paren-match bg-magenta-intense)
            (underline-paren-match fg-main)))

Note that I just added the 'underline-paren-match', as I forgot to do it
earlier.  To preview the palette with the named colors use 'M-x
modus-themes-list-colors'.  If something starts with "bg-" then one of
the other "bg-" colours will be suitable.

With C-u M-x modus-themes-list-colors you can preview the semantic
colour mappings.

I remember in a past exchange you told me that you like all colours to
be faint, not just for syntax.  This is now possible.  Either use this
preset:

    (setq modus-themes-common-palette-overrides
          modus-themes-preset-overrides-faint)

Or adapt it to your liking, such as:

    (setq modus-themes-common-palette-overrides
          `((bg-paren-match bg-magenta-intense)
            (underline-paren-match fg-main)
            ,@modus-themes-preset-overrides-faint))

There are many mappings for prose and we can always cover more cases.
If I remember correctly, your request was about Org+LaTeX.

I admit that there is no clear upgrade path.  The new approach is
different.  I think it is easier to have a clean start.  It's just a
matter of getting the hang of it.  The documentation provides all the
information and I am always available to answer specific questions and
show concrete examples.

> Some colours seem to have vanished; e.g., setting the above to just
> '(intense) used to change the colour to "#c488ff", but I can't find
> that value anywhere in the new version.  Is my only option to roll
> back to before the merge, see what all my user options did, trace the
> colour renamings/deletions, and then associate the new palette
> overrides to the right thing?  I'm probably missing something much
> simpler here.

In the past, I had lots of special purpose colours.  Those were added on
an ad-hoc basis over time and there was no clear design behind them.
With this refactoring, I wanted to reduce those case and to re-use a
smaller set of colours.

> On a related note: you mentioned (in [1]) that this change was mostly
> for cleaning up the code base and making it more maintainable.  If that
> is so, and the new palette override system is strictly more powerful
> than the old user options, would it perhaps make sense to not obsolete
> all of them, but to instead make them change the '*-palette-overrides'
> variables?  These options may even be deprecated and removed in a later
> release—if the goal is to get rid of them—but it would at least make
> sure that users have ample time to copy the relevant bits to their
> configuration before anything breaks.

This is the constraint with the MELPA approach to packaging: it is
impossible to warn users that the next package update is a major
release.

I have announced version 4 since the start of December and then made a
video about it in the middle of the month.  I could keep version-4 as its
own branch for another month or two and keep warning users about it, but
this day would inevitably come and some user would still be surprised.

The previous publications:

- 2022-12-03 Emacs: breaking changes coming to 'modus-themes' version 4 
- 2022-12-07 Emacs: change colour values and mappings in Modus themes version 4
- 2022-12-17 Emacs: modus-themes version 4 demo [video]

Links:

- https://protesilaos.com/codelog/2022-12-03-modus-themes-v4-development/
- https://protesilaos.com/codelog/2022-12-07-modus-themes-4-colour-values-mappings/
- https://protesilaos.com/codelog/2022-12-17-modus-themes-v4-demo/

Again, I am here to help.  You are welcome to ask me anything about
this.  I think you will eventually like the new approach, especially
once you get to apply your preferred colours across all contexts (and
not just what I had hardcoded before via the user options).

All the best,
Protesilaos (or simply "Prot")

-- 
Protesilaos Stavrou
https://protesilaos.com

Hi,

On Fri, Dec 30 2022 05:55, Protesilaos Stavrou wrote:
> I remember in a past exchange you told me that you like all colours to
> be faint, not just for syntax.  This is now possible.  Either use this
> preset:
>
>     (setq modus-themes-common-palette-overrides
>           modus-themes-preset-overrides-faint)

this is pretty great, thanks!

> There are many mappings for prose and we can always cover more cases.
> If I remember correctly, your request was about Org+LaTeX.

Yes, and I've been meaning to get back to this (adding more faces for
LaTeX so that, e.g., special symbols in environments wouldn't have to
use 'font-latex-warning-face' anymore), but (predictably) life sort of
got in the way.  One day!

> I admit that there is no clear upgrade path.  The new approach is
> different.  I think it is easier to have a clean start.  It's just a
> matter of getting the hang of it.  The documentation provides all the
> information and I am always available to answer specific questions and
> show concrete examples.

The problem with documentation is that it show how things *are* and not
how things used to be.  If I wanted to recreate the exact colours used
by some previous user option, I would need to expend considerable
effort.  For example, 'modus-themes-preset-overrides-faint' specifies
the following for mail citations:

    (mail-cite-0 cyan-faint)
    (mail-cite-1 yellow-faint)
    (mail-cite-2 green-faint)
    (mail-cite-3 red-faint)

but this is *not* the same as one got when setting
'modus-themes-mail-citations' to 'faint' in the previous version!
Tracing the changes, one would have to set something like

    (mail-cite-0 "#093060")
    (mail-cite-1 "#5d5000")
    (mail-cite-2 "#61284f")
    (mail-cite-3 "#184034")

for modus-operandi.  This is surprising behaviour to me, and doesn't
necessarily have anything to do with getting used to the new way of
specifying things.

Now, this change in colours for mail citations is obviously not the end
of the world, and I don't really care whether 'bg-paren-match' is set to
"#c488ff" or "#dfa0f0", but from a user perspective it just seems like
unnecessary churn.  I'm now forced to track down all of the changes that
(i) don't work anymore (as some things silently fail, like giving now
non-existent options to 'modus-themes-headings'), and (ii) are important
enough to me to go through the old code in order to find out what that
option did.

I know how much more work this would've been from a documentation
perspective, but I would've really wished for something like

  + Deprecated 'modus-themes-mail-citations' in favour of the new
    palette approach.

    * To emulate the 'faint' option, add

        (mail-cite-0 "#093060")
        (mail-cite-1 "#5d5000")
        (mail-cite-2 "#61284f")
        (mail-cite-3 "#184034")

      to your palette overrides.

    * …

in the changelog.  This would've made updating as painless as
possible—considering the extend of the changes—and at least I would be
much more excited about new possibilities instead of demotivated by what
seems like work.

> This is the constraint with the MELPA approach to packaging: it is
> impossible to warn users that the next package update is a major
> release.

I don't think that this is a problem with how MELPA does packaging—it's
exactly what 'make-obsolete-variable' is supposed to solve, right?  Mark
a variable as obsolete and say that it will be removed in a later
release (crucially, don't remove it immediately), and then point towards
the new way of doing things (in a best-case scenario, give users as
close to a copy-pasteable alternative as possible).  After a few months,
when everyone has had a chance to update, remove the variables.  It'll
drag out the cleaning of the code base a bit, yes, but it's a much
better experience for everyone who's using the themes.

> I have announced version 4 since the start of December and then made a
> video about it in the middle of the month.  I could keep version-4 as its
> own branch for another month or two and keep warning users about it, but
> this day would inevitably come and some user would still be surprised.
>
> The previous publications:
>
> - 2022-12-03 Emacs: breaking changes coming to 'modus-themes' version 4 
> - 2022-12-07 Emacs: change colour values and mappings in Modus themes version 4
> - 2022-12-17 Emacs: modus-themes version 4 demo [video]
>
> Links:
>
> - https://protesilaos.com/codelog/2022-12-03-modus-themes-v4-development/
> - https://protesilaos.com/codelog/2022-12-07-modus-themes-4-colour-values-mappings/
> - https://protesilaos.com/codelog/2022-12-17-modus-themes-v4-demo/
>
> Again, I am here to help.  You are welcome to ask me anything about
> this.  I think you will eventually like the new approach, especially
> once you get to apply your preferred colours across all contexts (and
> not just what I had hardcoded before via the user options).

I think it's important to warn users via a channel that you know they
will notice.  The only one that will truly reach everyone who uses your
packages is via an update, clarifying the situation (case in point: I
saw exactly zero of those announcements).

You are right that the new approach seems to be more flexible and
powerful.  I'm also not trying to discredit your work here in any way!
It's just that for someone not as involved with the development of the
theme, this update came sort of out of the blue, and now presents one
with a lot of what feels like unnecessary work just to get back to the
previous state of things.

  Tony

-- 
Tony Zorman | https://tony-zorman.com/

> From: Tony Zorman <soliditsallgood@mailbox.org>
> Date: Fri, 30 Dec 2022 09:55:44 +0100
>
> Hi,
>
> On Fri, Dec 30 2022 05:55, Protesilaos Stavrou wrote:
>> I remember in a past exchange you told me that you like all colours to
>> be faint, not just for syntax.  This is now possible.  Either use this
>> preset:
>>
>>     (setq modus-themes-common-palette-overrides
>>           modus-themes-preset-overrides-faint)
>
> this is pretty great, thanks!

You are welcome!

>> There are many mappings for prose and we can always cover more cases.
>> If I remember correctly, your request was about Org+LaTeX.
>
> Yes, and I've been meaning to get back to this (adding more faces for
> LaTeX so that, e.g., special symbols in environments wouldn't have to
> use 'font-latex-warning-face' anymore), but (predictably) life sort of
> got in the way.  One day!

I see.  In the meantime, it is possible to change the 'warning' mapping
to some other value such as 'yellow-faint' or even a different hue (I
would experiment with 'magenta-faint').

>> I admit that there is no clear upgrade path.  The new approach is
>> different.  I think it is easier to have a clean start.  It's just a
>> matter of getting the hang of it.  The documentation provides all the
>> information and I am always available to answer specific questions and
>> show concrete examples.
>
> The problem with documentation is that it show how things *are* and not
> how things used to be.  If I wanted to recreate the exact colours used
> by some previous user option, I would need to expend considerable
> effort.  For example, 'modus-themes-preset-overrides-faint' specifies
> the following for mail citations:
>
>     (mail-cite-0 cyan-faint)
>     (mail-cite-1 yellow-faint)
>     (mail-cite-2 green-faint)
>     (mail-cite-3 red-faint)
>
> but this is *not* the same as one got when setting
> 'modus-themes-mail-citations' to 'faint' in the previous version!
> Tracing the changes, one would have to set something like
>
>     (mail-cite-0 "#093060")
>     (mail-cite-1 "#5d5000")
>     (mail-cite-2 "#61284f")
>     (mail-cite-3 "#184034")
>
> for modus-operandi.  This is surprising behaviour to me, and doesn't
> necessarily have anything to do with getting used to the new way of
> specifying things.

The reason here is that I removed the "special" subset of colours from
the palette (names like 'bg-special-cold', 'bg-special-mild-faint',
'fg-special-calm').  There was nothing special about them as their name
would suggest: it was just another subset that I added ad-hoc.  I then
had the path dependency for multiple versions, as I could not remove
those colours without making other major changes.

The point is that you would have lost the old style even if overrides
were not involved.  It is about simplifying the palette, making it more
predictable, and easier to use/test/maintain.

This rewrite has given me the opportunity to revise lots of interfaces
that had exaggerations/inconsistencies.  For emails, I did not want to
have magenta in the quoted lines as it is used in the message headers.

> Now, this change in colours for mail citations is obviously not the end
> of the world, and I don't really care whether 'bg-paren-match' is set to
> "#c488ff" or "#dfa0f0", but from a user perspective it just seems like
> unnecessary churn.  I'm now forced to track down all of the changes that
> (i) don't work anymore (as some things silently fail, like giving now
> non-existent options to 'modus-themes-headings'), and (ii) are important
> enough to me to go through the old code in order to find out what that
> option did.

I understand and am sorry for the inconvenience.  About the non-existent
options to 'modus-themes-headings' (and others), I do not know of a way
to inform the user about them.  The general rule: if it involves changes
to colours, it is done via overrides.

> I know how much more work this would've been from a documentation
> perspective, but I would've really wished for something like
>
>   + Deprecated 'modus-themes-mail-citations' in favour of the new
>     palette approach.
>
>     * To emulate the 'faint' option, add
>
>         (mail-cite-0 "#093060")
>         (mail-cite-1 "#5d5000")
>         (mail-cite-2 "#61284f")
>         (mail-cite-3 "#184034")
>
>       to your palette overrides.
>
>     * …
>
> in the changelog.  This would've made updating as painless as
> possible—considering the extend of the changes—and at least I would be
> much more excited about new possibilities instead of demotivated by what
> seems like work.

This will be done in the changelog.  It's just that version 4 is not out
yet: it will be this Sunday.  However, I had to merge the 'version-4'
branch into 'main' a few days in advance just to be sure that everything
is in order ahead of the release (hence why I mentioned MELPA).

>> This is the constraint with the MELPA approach to packaging: it is
>> impossible to warn users that the next package update is a major
>> release.
>
> I don't think that this is a problem with how MELPA does packaging—it's
> exactly what 'make-obsolete-variable' is supposed to solve, right?  Mark
> a variable as obsolete and say that it will be removed in a later
> release (crucially, don't remove it immediately), and then point towards
> the new way of doing things (in a best-case scenario, give users as
> close to a copy-pasteable alternative as possible).  After a few months,
> when everyone has had a chance to update, remove the variables.  It'll
> drag out the cleaning of the code base a bit, yes, but it's a much
> better experience for everyone who's using the themes.

The copy-pasteable alternatives will be the manual.  I am continuously
updating it.  It is a work-in-progress, though it will be ready before
Sunday.

I have had a bad experience with obsoleting variables and trying to ease
in a new version.  Users would get obscure byte compilation errors that
would be caused by changing some private function's number of arguments.
I thought doing so again would complicate the code further while
potentially increasing the number of such bug reports.

A clean start is annoying---I know.  The code is easier to maintain
though.  And, the most important of all, I can now support every user's
needs for colour adjustments.  More grey?  Sure.  Red comments?  There
you are.  Borderless active mode line but bordered inactive one?  No
problem.  The old user options were simply not good enough for everyone
while being harder for me to maintain.

>> I have announced version 4 since the start of December and then made a
>> video about it in the middle of the month.  I could keep version-4 as its
>> own branch for another month or two and keep warning users about it, but
>> this day would inevitably come and some user would still be surprised.
>>
>> The previous publications:
>>
>> - 2022-12-03 Emacs: breaking changes coming to 'modus-themes' version 4 
>> - 2022-12-07 Emacs: change colour values and mappings in Modus themes version 4
>> - 2022-12-17 Emacs: modus-themes version 4 demo [video]
>>
>> Links:
>>
>> - https://protesilaos.com/codelog/2022-12-03-modus-themes-v4-development/
>> - https://protesilaos.com/codelog/2022-12-07-modus-themes-4-colour-values-mappings/
>> - https://protesilaos.com/codelog/2022-12-17-modus-themes-v4-demo/
>>
>> Again, I am here to help.  You are welcome to ask me anything about
>> this.  I think you will eventually like the new approach, especially
>> once you get to apply your preferred colours across all contexts (and
>> not just what I had hardcoded before via the user options).
>
> I think it's important to warn users via a channel that you know they
> will notice.  The only one that will truly reach everyone who uses your
> packages is via an update, clarifying the situation (case in point: I
> saw exactly zero of those announcements).

Yes, this is the best approach.  Though as you can tell now, it is not
easy either.

> You are right that the new approach seems to be more flexible and
> powerful.  I'm also not trying to discredit your work here in any way!
> It's just that for someone not as involved with the development of the
> theme, this update came sort of out of the blue, and now presents one
> with a lot of what feels like unnecessary work just to get back to the
> previous state of things.

Again, I apologise for the inconvenience.  If it helps, show me your old
config and I will show you how to reproduce it (while acknowledging the
fact that some colours are gone forever).

-- 
Protesilaos Stavrou
https://protesilaos.com

On Fri, Dec 30 2022 11:38, Protesilaos Stavrou wrote:
> I understand and am sorry for the inconvenience.  About the non-existent
> options to 'modus-themes-headings' (and others), I do not know of a way
> to inform the user about them.

I reckon you could write a custom function for setting these variables
and then check whether the cdr of each entry only consists of the values
allowed in 'modus-themes--headings-widget'.

> This will be done in the changelog.  It's just that version 4 is not out
> yet: it will be this Sunday.  However, I had to merge the 'version-4'
> branch into 'main' a few days in advance just to be sure that everything
> is in order ahead of the release (hence why I mentioned MELPA).

Oh!  I suppose this is the part that I was still missing—the fact that I
just updated at the wrong time, a few days before the actual release.
Unlucky!  I guess one could have merged version-4 into yet another
branch, starting from main, but I now realise what you meant when you
said that MELPA was getting in the way.

> I have had a bad experience with obsoleting variables and trying to ease
> in a new version.  Users would get obscure byte compilation errors that
> would be caused by changing some private function's number of arguments.
> I thought doing so again would complicate the code further while
> potentially increasing the number of such bug reports.

It would definitely complicate the code (at least for a while), but it
would also allow for a smoother switch.  Such is the burden of having
users, I know it all too well :).  Instead of using
'make-obsolete-variable' I reckon one could also again write custom
setters that emit some kind of warning that variable X will go away in
the future, and which alternatives to use.

However, since you said that

> The copy-pasteable alternatives will be the manual.  I am continuously
> updating it.  It is a work-in-progress, though it will be ready before
> Sunday.

it is perhaps not as bad as I thought and I just updated my packages at
the wrong time.  

> Again, I apologise for the inconvenience.  If it helps, show me your old
> config and I will show you how to reproduce it (while acknowledging the
> fact that some colours are gone forever).

It's fine, I'm almost done crawling through the code and extracting my
preferences.  Since I only really use modus-operandi and thus have to
give no thought to the modus-vivendi colours, it's—after all—not as much
effort.  Just the heading have been given me a little bit of a headache,
as they have a lot of options that can be combined with each other.  I'm
sure I'll manage at some point though.

  Tony

-- 
Tony Zorman | https://tony-zorman.com/

To bring this to some sort of conclusion, I've now completed my
transition to the new version of the themes (the documentation helped
greatly, btw, thanks)!

Just in case anyone stumbles upon this, and with entirely too many
comments, (the relevant parts of) my configuration went from

    (use-package modus-themes    
      :init (modus-themes-load-operandi)
      :custom
      (modus-themes-hl-line '(accented))
      (modus-themes-paren-match '(intense))
      (modus-themes-syntax '(faint))
      (modus-themes-region '(accented))
      (modus-themes-mail-citations 'faint)
      (modus-themes-headings
       '((1 . (overline background 1.3))
         (2 . (overline rainbow 1.2))
         (3 . (1.1))
         (t . (monochrome)))))

to

    (use-package modus-themes
      :custom (modus-themes-headings '((1 . (1.3)) (2 . (1.2)) (3 . (1.1))))
      :init
      ;; Disable all other themes before loading, as was done by
      ;; 'modus-themes-load-operandi' previously.
      (advice-add 'modus-themes-load-theme :before
                  (lambda (_) (mapc #'disable-theme custom-enabled-themes)))
      ;; Colour overrides and how they correspond to older settings.  This
      ;; can't be in ':custom' because 'modus-themes-preset-overrides-faint'
      ;; is not in scope by that point.
      (require 'modus-themes)           ; bring *preset-overrides into scope
      (setq modus-themes-common-palette-overrides
            `((bg-paren-match bg-magenta-intense)     ; paren-match: intense
              (bg-region bg-blue-intense)             ; region: accented
              (bg-hl-line bg-blue-nuanced)            ; hl-line: accented
              (bg-heading-1 bg-magenta-nuanced)       ; h1: background
              (fg-heading-2 magenta-warmer)           ; h2: rainbow
              (fg-heading-3 fg-main)                  ; h3+: monochrome
              (fg-heading-4 fg-main)                  ; h3+: monochrome
              (fg-heading-5 fg-main)                  ; h3+: monochrome
              (fg-heading-6 fg-main)                  ; h3+: monochrome
              (fg-heading-7 fg-main)                  ; h3+: monochrome
              (fg-heading-8 fg-main)                  ; h3+: monochrome
              ;; Needs (?) to be hardcoded since `bg-region' is redefined above.
              (overline-heading-1 "#bcbcbc")          ; h1: overline
              (overline-heading-2 "#bcbcbc")          ; h2: overline
              ,@modus-themes-preset-overrides-faint)) ; let everything be faint!
      (modus-themes-select 'modus-operandi))

I think the only colours that don't match 100% are 'bg-paren-match' and
'bg-region', which were slightly different shades of magenta and blue,
respectively.  In practice I don't notice this at all, though.

I guess this was a good exercise after all, because it showed me that I
don't actually like how my org headings look.  All this new freedom will
surely make for a fun sunday afternoon, fiddling with colours :).  Plus,
it'll help me get rid of the hardcoded values for the heading overlines.

  Tony

-- 
Tony Zorman | https://tony-zorman.com/

> From: Tony Zorman <soliditsallgood@mailbox.org>
> Date: Tue,  3 Jan 2023 11:11:55 +0100
>
> To bring this to some sort of conclusion, I've now completed my
> transition to the new version of the themes (the documentation helped
> greatly, btw, thanks)!

Good to know!  You are welcome!  Please let me know if there is
something else I can help with and/or if there are any improvements we
can make.

> Just in case anyone stumbles upon this, and with entirely too many
> comments, (the relevant parts of) my configuration went from

> [... 15 lines elided]

> to

> [... 30 lines elided]


> I think the only colours that don't match 100% are 'bg-paren-match' and
> 'bg-region', which were slightly different shades of magenta and blue,
> respectively.  In practice I don't notice this at all, though.

You are right: those colours do not exist anymore.

> I guess this was a good exercise after all, because it showed me that I
> don't actually like how my org headings look.  All this new freedom will
> surely make for a fun sunday afternoon, fiddling with colours :).  Plus,
> it'll help me get rid of the hardcoded values for the heading overlines.

I think it will be worth experimenting with.  The preset with the faint
style already covers the need you had expressed many months ago for
faint colours everywhere (I remember it was on GitLab but forgot the
date and the specific discussion).

A note about your 'advice-add': what you do is what I would like to do.
However, I removed that because it disables all "themes".  For Emacs a
"theme" is a bundle of options, NOT just a set of colours/styles.  Put
concretely, recent versions of 'use-package' provide the option to store
':custom' configurations as a theme.  Check this from the
use-package-core.el file:

    (defcustom use-package-use-theme t
      "If non-nil, use a custom theme to avoid saving :custom
    variables twice (once in the Custom file, once in the use-package
    call)."
      :type 'boolean
      :group 'use-package)

Given this, I did not want a Modus theme switch to cause any undesired
side-effects.

-- 
Protesilaos Stavrou
https://protesilaos.com

On Tue, Jan 03 2023 17:38, Protesilaos Stavrou wrote:
> Good to know!  You are welcome!  Please let me know if there is
> something else I can help with and/or if there are any improvements we
> can make.

Will do!

> A note about your 'advice-add': what you do is what I would like to do.
> However, I removed that because it disables all "themes".  For Emacs a
> "theme" is a bundle of options, NOT just a set of colours/styles.  Put
> concretely, recent versions of 'use-package' provide the option to store
> ':custom' configurations as a theme.  Check this from the
> use-package-core.el file:
>
>     (defcustom use-package-use-theme t
>       "If non-nil, use a custom theme to avoid saving :custom
>     variables twice (once in the Custom file, once in the use-package
>     call)."
>       :type 'boolean
>       :group 'use-package)
>
> Given this, I did not want a Modus theme switch to cause any undesired
> side-effects.

It might be correct to err on the side of caution here, but for this
example in particular there already is a hack in place where the
use-package theme is immediately removed from 'custom-enabled-themes'
(lines 36–44 for me in 'use-package-core.el'):

    (eval-and-compile
      ;; Declare a synthetic theme for :custom variables.
      ;; Necessary in order to avoid having those variables saved by custom.el.
      (deftheme use-package))
    
    (enable-theme 'use-package)
    ;; Remove the synthetic use-package theme from the enabled themes, so
    ;; iterating over them to "disable all themes" won't disable it.
    (setq custom-enabled-themes (remq 'use-package custom-enabled-themes))

I've only ever seen use-package define a theme that's not related to a
colour-scheme in some way, so I don't know if there are any other
examples.

I think that, in general, disabling other themes is _really_ convenient,
and all theme-switching functions from completion packages that I'm
aware of ('consult-theme', 'counsel-load-theme', 'helm-themes') do this
as well.  I reckon that's how the above workaround came about: a theme
for ':custom' variables was created, people complained that things break
when switching themes, and just silently removing the use-package theme
from the list seemed like the easiest solution.

Now, none of the above completion frameworks are part of the Emacs core,
so perhaps the modus-themes need to be more careful here.  On the other
hand, if a user wants more fine-grained control over what's disabled,
there is always '(load-theme <<theme>> t)'.

  Tony

-- 
Tony Zorman | https://tony-zorman.com/

> From: Tony Zorman <soliditsallgood@mailbox.org>
> Date: Tue,  3 Jan 2023 17:17:17 +0100

> [... 8 lines elided]

>> A note about your 'advice-add': what you do is what I would like to do.
>> However, I removed that because it disables all "themes".  For Emacs a
>> "theme" is a bundle of options, NOT just a set of colours/styles.  Put
>> concretely, recent versions of 'use-package' provide the option to store
>> ':custom' configurations as a theme.  Check this from the
>> use-package-core.el file:
>>
>>     (defcustom use-package-use-theme t
>>       "If non-nil, use a custom theme to avoid saving :custom
>>     variables twice (once in the Custom file, once in the use-package
>>     call)."
>>       :type 'boolean
>>       :group 'use-package)
>>
>> Given this, I did not want a Modus theme switch to cause any undesired
>> side-effects.
>
> It might be correct to err on the side of caution here, but for this
> example in particular there already is a hack in place where the
> use-package theme is immediately removed from 'custom-enabled-themes'
> (lines 36–44 for me in 'use-package-core.el'):
>
>     (eval-and-compile
>       ;; Declare a synthetic theme for :custom variables.
>       ;; Necessary in order to avoid having those variables saved by custom.el.
>       (deftheme use-package))
>     
>     (enable-theme 'use-package)
>     ;; Remove the synthetic use-package theme from the enabled themes, so
>     ;; iterating over them to "disable all themes" won't disable it.
>     (setq custom-enabled-themes (remq 'use-package custom-enabled-themes))

Good to know!  I had not noticed this earlier.  Maybe it was there from
the start and I missed it, or it was added more recently.  Either way,
we don't have to worry about 'use-package' anymore.

However, this does not change things: we still have the case of users
setting their own themes.  It is less common, though I know cases where
it happens.

My opinion is that "themes" should not be diluted in this way and that
theme blending should not be allowed by default.  All this makes things
more complicated.

> I've only ever seen use-package define a theme that's not related to a
> colour-scheme in some way, so I don't know if there are any other
> examples.

We still have users who do this for (i) bundles of configurations, (ii)
to blend two colour themes.

I once had an exchange where there was this idea that my 'cursory' and
'fontaine' packages should be designed as "themes".

> I think that, in general, disabling other themes is _really_ convenient,
> and all theme-switching functions from completion packages that I'm
> aware of ('consult-theme', 'counsel-load-theme', 'helm-themes') do this
> as well.  I reckon that's how the above workaround came about: a theme
> for ':custom' variables was created, people complained that things break
> when switching themes, and just silently removing the use-package theme
> from the list seemed like the easiest solution.

I agree and consider this the best state of affairs.

> Now, none of the above completion frameworks are part of the Emacs core,
> so perhaps the modus-themes need to be more careful here.  On the other
> hand, if a user wants more fine-grained control over what's disabled,
> there is always '(load-theme <<theme>> t)'.

Yes, the inclusion in Emacs is part of the consideration here.  Perhaps
we could have an option like 'modus-themes-disable-other-themes'?  When
it is enabled, relevant functions like 'modus-themes-load-theme' and
'modus-themes-toggle' will disable all other themes.  Otherwise the
effect is limited to the Modus themes.

Does this make sense?

-- 
Protesilaos Stavrou
https://protesilaos.com

On Wed, Jan 04 2023 04:43, Protesilaos Stavrou wrote:
>> I've only ever seen use-package define a theme that's not related to a
>> colour-scheme in some way, so I don't know if there are any other
>> examples.
>
> We still have users who do this for (i) bundles of configurations, (ii)
> to blend two colour themes.

I see, fair enough.

> Yes, the inclusion in Emacs is part of the consideration here.  Perhaps
> we could have an option like 'modus-themes-disable-other-themes'?  When
> it is enabled, relevant functions like 'modus-themes-load-theme' and
> 'modus-themes-toggle' will disable all other themes.  Otherwise the
> effect is limited to the Modus themes.
>
> Does this make sense?

I think that, all things considered, this is the best option!  Since
people using more than one theme at a time in the way you described
above seem to be a minority (at least as far as I can tell), maybe the
option could even default to 't' (i.e., disabling all other themes).

-- 
Tony Zorman | https://tony-zorman.com/

> From: Tony Zorman <soliditsallgood@mailbox.org>
> Date: Wed,  4 Jan 2023 20:52:09 +0100

> [... 11 lines elided]

>> Yes, the inclusion in Emacs is part of the consideration here.  Perhaps
>> we could have an option like 'modus-themes-disable-other-themes'?  When
>> it is enabled, relevant functions like 'modus-themes-load-theme' and
>> 'modus-themes-toggle' will disable all other themes.  Otherwise the
>> effect is limited to the Modus themes.
>>
>> Does this make sense?
>
> I think that, all things considered, this is the best option!  Since
> people using more than one theme at a time in the way you described
> above seem to be a minority (at least as far as I can tell), maybe the
> option could even default to 't' (i.e., disabling all other themes).

Thank you and I agree!

I just installed the changes.  We now have the user option
'modus-themes-disable-other-themes': by default, we disable all other
themes when running the commands 'modus-themes-toggle' and
'modus-themes-select' as well as the function 'modus-themes-load-theme'.

-- 
Protesilaos Stavrou
https://protesilaos.com

On Thu, Jan 05 2023 05:06, Protesilaos Stavrou wrote:
> I just installed the changes.  We now have the user option
> 'modus-themes-disable-other-themes': by default, we disable all other
> themes when running the commands 'modus-themes-toggle' and
> 'modus-themes-select' as well as the function 'modus-themes-load-theme'.

This is great, thank you!

-- 
Tony Zorman | https://tony-zorman.com/

> From: Tony Zorman <soliditsallgood@mailbox.org>
> Date: Thu,  5 Jan 2023 21:06:14 +0100
>
> On Thu, Jan 05 2023 05:06, Protesilaos Stavrou wrote:
>> I just installed the changes.  We now have the user option
>> 'modus-themes-disable-other-themes': by default, we disable all other
>> themes when running the commands 'modus-themes-toggle' and
>> 'modus-themes-select' as well as the function 'modus-themes-load-theme'.
>
> This is great, thank you!

You are welcome and thanks for your feedback!  I think I will prepare
version 4.1.0 to wrap up those changes.

-- 
Protesilaos Stavrou
https://protesilaos.com