theming suggestions #49
Labels
No Label
IMAP
JMAP
Maildir
Retired
User Experience
User Interface
bsd
bug
contacts
currently worked on
documentation
duplicate
easy
enhancement
help wanted
invalid
linux-gnu
macos
mbox
notmuch
question
security
wishlist
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: meli/meli#49
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
I'm just trying to create a theme that fits my use-case. And I noticed two things that would be nice to have. Not sure how easy they are to implement.
It would be cool if it was possible to have italic text.
One issue I encountered the compact list view is, the ability to theme odd/even is very nice. However if there is a lot of unseen messages in the same view, the odd/even distinction is gone. It would be great if one could only specify a single attribute, i.e. bold font, and it would automatically inherit from what the view was before. So if I for example make the background white for odd and black for even, and then unseen messages I make bold. The backgrounds would all still alternate between black/white even for the unseen messages.
These are good suggestions!
While at it, there should also be dimmed, blink and hidden text. These are all in the xterm escape code sequences but may not be supported in all terminals.
The problem with this is that there's no distinction for a user-set value vs app-default in themes, so there's no way to know if for example the unseen even background should default to even background unless user has set the unseen even background value.
Instead the following is cleaner and easy to implement: Have separate theme keys for
even unseen
,odd unseen
,even highlighted
, etc. It's a bit verbose put provides more flexibility for custom themes.Here's a preview
Ok I understand. Maybe the option to avoid the verbosity is to have a keyword parent? And then make a bit more hierachy, i.e. have list.odd.unseen , list.even.unseen, list.even.selected ... if one would then set list.odd.unseen = {fg="parent", bg="white"} it takes the foreground value from the parent, i.e. list.odd?
Obviously what you did works as well I'm just thinking about a way to avoid having to repeat a lot of values.
I think this is essentially the same thing but with different key names, isn't it?
Actually, you're right it does not make a difference, because it does not really matter if you put in a color or the "parent" keyword. It would be nice to be able to define custom color names though, that way it's easier to reuse colors, without making mistakes.
That'd be useful indeed. TOML doesn't allow variables though so this would require some non-trivial rewrite, unless it can become a m4 macro and expand the colour names in preprocess. I'll look into it.