From Christian Tietze to ~protesilaos/modus-themes
> 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
From Christian Tietze to ~protesilaos/modus-themes
Seems to work fine, thanks! -- Christian
From Christian Tietze to ~protesilaos/modus-themes
> 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. ]
From Christian Tietze to ~protesilaos/modus-themes
> 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
From Christian Tietze to ~protesilaos/modus-themes
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)))
From Christian Tietze to ~protesilaos/modus-themes
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.
From Christian Tietze to ~protesilaos/modus-themes
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:
From Christian Tietze to ~protesilaos/modus-themes
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. >
From Christian Tietze to ~protesilaos/modus-themes
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.
From Christian Tietze to ~protesilaos/lin
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