> The reason is that the preset remaps 'bg-hl-line' to 'bg-cyan-subtle',
> thus undoing the original named colour and introducing recursion.
>
> Maybe there is a smart way to guard against this but I need to think
> more about it.  Any ideas are most welcome!

Oh, that makes sense!

Is there a way for you to detect this and emit a warning? Could be a compilation warning, or also a simple message during theme loading. That'd help debug issues like that because then users at least know why it's not working, and can fall back to copy-pasting the hex codes and leave a comment.

Cheers,
Christian

Seems to work fine, thanks!

-- Christian

> Your proposal is correct.  Though we also need to deprecate
> 'modus-themes-region' and then remove the 'bg-region-subtle' entries
> from the palettes.
>
> This means that the function 'modus-themes--region' will also be
> removed.
>
> I will do it later today.
>
> [ The case of the 'region' face shows the kind of complexity we had
>   before.  For one face, we had one user option, one private function,
>   and two different background colours per theme palette.  In some
>   cases, like 'modus-themes-syntax', this was more egregious. ]

> I still have not documented this.  Will do it a bit later as I still
> need to tweak some things.  In general, overrides only concern colours.

Alright 👍


> Your code works, though you don't need ct/modus-themes-color as you can
> wrap the face definitions around modus-themes-with-colors.  The above
> can be written thus:
>
>     (defun ct/modus-themes-customize-mode-line ()
>       "Apply padding to mode-line via box that has the background color"
>       (modus-themes-with-colors
>         (custom-set-faces

Hi Prot :)

The common palette overrides and changing how color "pointers" work is
great. I got to a point where I tweaked the mode-line to be borderless
and notices that inheriting the colors doesn't work as I expected after
reading the docs.

Here's a mimimal example:

First, re-wire the 'bg-mode-line-active' color reference for all themes:

  (customize-set-variable 'modus-themes-common-palette-overrides
                          `((bg-mode-line-active bg-inactive)))

Hi Prot,

While documenting the migration process from my old modus-themes
settings to the new v4 format, I found that the mode-line face was
declared thus:

    `(mode-line ((,c :inherit modus-themes-ui-variable-pitch
                     :box ,border-mode-line-active
                     :background ,bg-mode-line-active
                     :foreground ,fg-mode-line-active)))

So the value of the 'border-mode-line-active' variable would be inserted
here during evaluation. Yet I couldn't get anything but simple color
literals to work.

Hi Prot,

After dabbling with the current MELPA version for a while, I found my
way around the new palettes. Nice!

I was looking for a way to try macOS like selection (region) colors with
v4 again, but noticed that there's no named 'fg-region' color in any
palette.

My suggestion would be to replace:

    `(region ((,c ,@(modus-themes--region bg-region fg-main bg-region-subtle))))

with:

That message doesn't display well because of the inline attachment. So here's the full text for reference

> Hi Prot,
>
> Just an FYI to show an odd quirk.
>
> I am trying out larger org-heading-1 faces. I also use
> `org-agenda-to-appt' to display system notifications before
> appointments.
>
> I noticed that the `list-processes' list shows the notification display
> command -- and the message text that's passed-in apparently is copied by
> `org-agenda-to-appt' including its face properties.
>

Hi Prot,

Just an FYI to show an odd quirk.

I am trying out larger org-heading-1 faces. I also use
`org-agenda-to-appt' to display system notifications before
appointments.

I noticed that the `list-processes' list shows the notification display
command -- and the message text that's passed-in apparently is copied by
`org-agenda-to-appt' including its face properties.

Thanks for all the hints. I'll use a quick-fix like this to get hl-line to update properly after a refresh and experiment:

(defun ct/notmuch--reset-selection ()
  "Refresh line highlight when refreshing search buffers"
  (when (not (derived-mode-p 'notmuch-show-mode 'notmuch-message-mode 'notmuch-hello-mode))
    (forward-char +1)
    (forward-char -1)))
(advice-add #'notmuch-refresh-this-buffer :after #'ct/notmuch--reset-selection)

Cheers,
Christian