Please support notmuch

[sten0]

Feature request

Support for Notmuch https://notmuchmail.org/notmuch-emacs/

Solarized ref

https://github.com/bbatsov/solarized-emacs/blob/0f0b1129cf51c85904f9e015da4fcca5f5f7a4ce/solarized-faces.el#L1394-L1408

[jasonm23]

notmuch faces

• notmuch-message-summary-face
• notmuch-search-date
• notmuch-search-count
• notmuch-search-subject
• notmuch-search-matching-authors
• notmuch-search-non-matching-authors
• notmuch-tag-face
• notmuch-tag-unread
• notmuch-search-flagged-face
• notmuch-search-unread-face
• notmuch-tree-match-author-face
• notmuch-tree-match-date-face
• notmuch-tree-match-tag-face
• notmuch-tree-no-match-face

@sten0 please add more or confim

[jasonm23]

please note https://github.com/aclements/notmuch/blob/master/emacs/notmuch.el#L250-L305

• notmuch-message-summary-face
• notmuch-search-date
• notmuch-search-count
• notmuch-search-subject
• notmuch-search-matching-authors
• notmuch-search-non-matching-authors
• notmuch-tag-face

[sten0]

Jason Milkins @.***> writes:

;;;;; notmuch
     `(notmuch-message-summary-face ((,class (:inherit highlight))))
     `(notmuch-search-date ((,class (:inherit default))))
     `(notmuch-search-count ((,class (:inherit default))))
     `(notmuch-search-subject ((,class (:inherit default))))
     `(notmuch-search-matching-authors ((,class (:inherit default))))
     `(notmuch-search-non-matching-authors ((,class (:inherit shadow))))
     `(notmuch-tag-face ((,class (:foreground ,yellow))))
     `(notmuch-tag-unread ((,class (:foreground ,magenta))))
     `(notmuch-search-flagged-face ((,class (:foreground ,blue))))
     `(notmuch-search-unread-face ((,class (:weight bold))))
     `(notmuch-tree-match-author-face ((,class (:foreground ,blue))))
     `(notmuch-tree-match-date-face ((,class (:foreground ,yellow))))
     `(notmuch-tree-match-tag-face ((,class (:foreground ,cyan))))
     `(notmuch-tree-no-match-face ((,class (:inherit font-lock-comment-face))))

I chose modus-themes rather than solarized in my screenshot example, because it uses all of these:

notmuch-crypto-decryption
notmuch-crypto-part-header
notmuch-crypto-signature-bad
notmuch-crypto-signature-good
notmuch-crypto-signature-good-key
notmuch-crypto-signature-unknown
notmuch-jump-key
notmuch-message-summary-face
notmuch-search-count
notmuch-search-date
notmuch-search-flagged-face
notmuch-search-matching-authors
notmuch-search-non-matching-authors
notmuch-search-subject
notmuch-search-unread-face
notmuch-tag-added
notmuch-tag-deleted
notmuch-tag-face
notmuch-tag-flagged
notmuch-tag-unread
notmuch-tree-match-author-face
notmuch-tree-match-date-face
notmuch-tree-match-face
notmuch-tree-match-tag-face
notmuch-tree-no-match-face
notmuch-tree-no-match-date-face
notmuch-wash-cited-text
notmuch-wash-toggle-button

The reason I included screenshots of my close-to-stock config is as a control, to show how the modeline is legible (when sensible mode is enabled). It's a bit wilder than expected with modus-themes, but I'm not sure where the red comes from with Gruvbox (with a high-contrast theme). If I had to guess, I'd guess that notmuch is poking autothemer in an unexpected way.

[jasonm23]

This is not just notmuch.el support, because a number of defface that are defined elsewhere. Can you identify the source of these defface?

Please note that code-fences do not work in Github issues when the comment is sent via email.

[jasonm23]

WRT to autothemer, it simply maps from one data representation of a theme to Emacs deftheme. It makes no changes to the content of a theme.

So I'm not sure how you're imagining it getting "poked" wrong.

[jasonm23]

Also sidenote: https://github.com/tjim/nevermore/ might be worth looking at.

nevermore defface

• nm-authors-face
• nm-date-face
• nm-header-face
• nm-query-face
• nm-read-face
• nm-separator-face
• nm-tags-face
• nm-unread-face

[jasonm23]

@sten0 Once you've settled on (and verified) the deffaces to theme, you can use the palette in the gruvbox-theme.el to assign color names. I'm happy to accept that as a markdown table or as csv style. If you aren't comfortable submitting a PR with the face styling.

example:

Markdown table:

| face                   | foreground          | background  |
|------------------------|---------------------|-------------|
| notmuch-search-subject | gruvbox-light4      | unspecified |

face	foreground	background
notmuch-search-subject	gruvbox-light4	unspecified

CSV

notmuch-search-subject,gruvbox-light4,unspecified

AutoThemer

For reference the autothemer style is much simpler than deftheme, and color classes are figured out automatically if not specified.

You'd add notmuch (and/or nevermore) face styling to gruvbox.el like so:

     ;;; notmuch 
     (notmuch-message-summary-face            (:foreground gruvbox-bright_blue))
     (notmuch-search-count                    (:foreground gruvbox-bright_red))

(inserted into the rest of the mode support lines, you'll see where.)

I recommend you do it this way, for the added benefit of being able to test it on your setup.

[sten0]

Hi Jason,

Clearly this is not just notmuch.el support, but a number of defface that are defined elsewhere. Can you identify the source of these defface?

Notmuch has 23 files, and the list provided (from modus-themes) is still just a subset of the available deffaces--probably some inherit faces from others. Zenburn also has faces for notmuch.

WRT to autothemer, it simply maps from one data representation of a theme to Emacs deftheme. It makes no changes to the content of a theme.

So I'm not sure how you're imagining it getting "poked" wrong.

Something is causing a faulty mapping, because the buffer name should not receive what looks like #fb4934 or #fb4933, and I chose to believe that it was an unhandled notmuch-related case that may have been mucking with what I supposed what the autothemer's path logic. That's not the case, because it occurs with the following minimal reproducer:

(load-theme 'gruvbox-dark-hard) ;; or just 'gruvbox (require 'smart-mode-line) (sml/setup)

Only overwriting gruvbox's schema with the dark or light themes made the orange/red text go away. (setq sml/theme 'nil) and 'respectful produce no effect, unlike other themes. I also tried the following:

emacs -q --eval "(progn (load-theme 'gruvbox-dark-hard) (require 'smart-mode-line) (sml/setup))" emacs -q --eval "(progn (require 'gruvbox) (load-theme 'gruvbox-dark-hard) (require 'smart-mode-line) (sml/setup))" emacs -q --eval "(progn (require 'smart-mode-line) (sml/setup) (require 'gruvbox) (load-theme 'gruvbox-dark-hard))"

and all produced an orange/red buffer name, but:

emacs -q --eval "(progn (require 'gruvbox) (load-theme 'gruvbox-dark-hard))"

is fine. Buffer name is a nicer colour for beige, as designed.

So whatever is going on is a poor interaction between smart-mode-line and gruvbox (latest tagged releases of both, as noted in OP), specifically, it seems the nil and respectful are what cause the issue, which is a shame, because the modeline doesn't use Gruvbox's colour scheme without this.

... I guess that means there are two unrelated bugs. The notmuch wishlist one, and this smart-mode-line bug. Sorry for mixing them up. Would you like to clone this issue, or shall I?

Sorry, I don't know the first thing about theme design (which colours go where and why), and I truly appreciate consideration goes into making them. I like how Gruvbox uses warmer tones rather than making everything blue! :)

Kind regards, Nicholas

[jasonm23]

WRT to AutoThemer, I did forget that it does change colors in un-styled faces. Based on the predefined color, it'll do a nearest match to colors in the theme palette.

If the color changes are using palette color values, that'll probably be what's going on. However your tests (emacs -Q) don't seem to indicate this... I can't draw a concrete diagnosis.

In any case, wrt to developing support let me make a few things plain:

• You'll need to compose a defnitive list of deffaces (I'd grep the files you know to be notmuch official for defface) as one of the previously mentioned formats.
• You will need to make a suggested theme, don't rush, use it, be happy with it, if you concentrate on the upper theme palette as your main source of colors, it'll be fine.
• Avoid using the lower section of the palette unless it's for a few very specific accents/highlights.
• Remember GruvBox is user supported, I will help you get the result you want, but I won't be installing notmuch etc locally to test it.
• You are a good enough designer to know what you don't like, remember that too. Solarised etc will have you believe that this is all science of optics. I'll tell you something different, does it feel nice to look at, ok then you're lookng at something good. KISS.

[jasonm23]

@sten0 just checking in to see if you have made any progress?

[jasonm23]

Please note closing on 2023-07-22 if no further activity.

[sten0]

WRT to AutoThemer, I did forget that it does change colors in un-styled faces. Based on the predefined color, it'll do a nearest match to colors in the theme palette.

If the color changes are using palette color values, that'll probably be what's going on. However your tests (emacs -Q) don't seem to indicate this... I can't draw a concrete diagnosis.

Screenshots that demonstrate the issue exists are available in my original post (edited versions are not deleted. See the dropdown menu). If you'd like I can test user-installed rather than system-installed packages. Or maybe it's fixed in HEAD and is only present in the latest tagged release? Honestly, I'm surprised you weren't able to easily reproduce it. I used Emacs 28.2 with native compilation enabled, latest tagged versions of smart-mode-line, autothemer-el, and gruvbox, under X11, on Debian 12. What stack are you using to attempt to reproduce?

In any case, wrt to developing support let me make a few things plain:

• You'll need to compose a defnitive list of deffaces (I'd grep the files you know to be notmuch official for defface) as one of the previously mentioned formats.

I don't mind doing this.

• You will need to make a suggested theme, don't rush, use it, be happy with it, if you concentrate on the upper theme palette as your main source of colors, it'll be fine.
• Avoid using the lower section of the palette unless it's for a few very specific accents/highlights.

I'm sorry, I don't understand, because aren't all the bright colours that would be suitable for unambiguous accents/highlights in the upper palette?

• Remember GruvBox is user supported, I will help you get the result you want, but I won't be installing notmuch etc locally to test it.

That's totally reasonable :) Would you keep these bits up-to-date when potential future breaking changes are introduced?

• You are a good enough designer to know what you don't like, remember that too.

Thank you for these tips and encouragement!

@sten0 https://github.com/sten0 just checking in to see if you have made any progress?

I have to confess that I'm demotivated by the poor interaction that I've observed between smart-mode-line and the autothemer and/or Gruvbox.

P.S. I can file a separate bug if you prefer, because this one appears to be more theming-related than bug-related.

Message ID: @.***>

[jasonm23]

Thanks for the response. Firstly always open a new issue for anything not specific to the current one.

Wrt to next steps on this issue, provide the notmuch faces to support along with color names from the palette.

Use the autothemer format so you can actually test it on your machine before posting, and so you can include screenshots for the issue and it'll be easy to add a PR.

[jasonm23]

Closing in 24hrs.

[jasonm23]

Closing due to lack of proposer's interest.