> This would be the ideal, but dired.el doesn't notify "interested parties"
> when the selected line changes. There's no hook, for some reason. This
> could be a useful addition upstream in the Emacs source code, but at the
> moment, we're stuck with key rebindings.

One more thing:

`dired-move-to-filename' is apparently called after most (all?)
selection and movement commands, so maybe we could figure out to advise
this function instead. Doing it right now will result in a stack
overflow of sorts because the preview calls `dired-move-to-filename',
too.

Another suggestion would be to grep for all callers of this function in

Hi Prot & Ed!

>> I'm Just an end-user so I don't understand Christian's explanation, but 
>> that is the first thing I noticed - that it doesn't work with the up and 
>> down arrow keys.
>
> What Christian suggests is that instead of triggering the effect via a
> command bound to a key, we do it automatically after the 'dired-mark' is
> set.

This would be the ideal, but dired.el doesn't notify "interested parties"
when the selected line changes. There's no hook, for some reason. This
could be a useful addition upstream in the Emacs source code, but at the
moment, we're stuck with key rebindings.

Hi Prot,

Great to hear to iterate on the peep-dired package! (I'm a happy user.)

I found that rebinding the dired keys composed worse than hooks; with
hooks, you can preview whichever file point is on easily. With rebinding
keys, you would need to account for a lot of special cases.

I documented the issue here in 2020:
https://github.com/asok/Peep-dired/issues/18

So my suggestion would be to make similar adjustments to:
https://git.sr.ht/~protesilaos/dired-preview/tree/main/item/dired-preview.el#L283-288

In accordance with the renaming introduced in 1ee4c9576f22320c23573e98cd6ac2b59a17ab3a
---
 doc/modus-themes.info | 6 +++---
 doc/modus-themes.org  | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/doc/modus-themes.info b/doc/modus-themes.info
index fd81732b..d3f9c738 100644
--- a/doc/modus-themes.info
+++ b/doc/modus-themes.info
@@ -4213,9 +4213,9 @@ length elsewhere in this manual:
           ;; Doom should not be implementing such hacks because themes
           ;; cannot support them:
           ;; <https://protesilaos.com/codelog/2022-08-04-doom-git-gutter-modus-themes/>.
[message trimmed]

> 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.