~rjarry/aerc#18: 
style: allow styling individual message list fields

For now, one line in the message list is styled as a whole. It is not possible to give different styles to message elements: Subject, From, Date, flags, etc.

It would be nice to allow giving specific styles to certain elements. This will require a rework of how messages are displayed however:

https://git.sr.ht/~rjarry/aerc/tree/0.7.1/item/widgets/msglist.go#L259

Status
RESOLVED IMPLEMENTED
Submitter
~rjarry
Assigned to
Submitted
1 year, 7 months ago
Updated
5 months ago
Labels
breaking feature ui

~rjarry 1 year, 1 month ago*

I think this would be an opportunity to redesign this message list formatting. Here are some other ideas:

  • "columns" with percentage width instead of absolute.
  • use "template" formatting instead of obscure printf-like format
  • allow message coloring based on header contents (Content-Type, X-SourceHut-Patchset-Status, etc.)
  • add missing possible "columns": message size, attachments, signature status, etc.

~poldi1405 1 year, 1 month ago

This may require adding a msglist.format file… When wielding the full power of text/template these format strings can easily get hundreds of bytes long. Take for example what is currently the default:

{{ .Date | DateFormat}} {{.Sender | Pad 17}} {{.Flags}} {{{.Subject}}

Adding some ifs, loops, function calls and so on would easily inflate that significantly.

~rjarry 1 year, 1 month ago

probably a new section in aerc.conf that would look something like this:

[message-list]
columns=date:20%,sender:30%,flags:3,subject
date={{.Date | DateFormat}}
sender={{.Sender}}
flags={{.Flags}}
subject={{.Subject}}

~rjarry 1 year, 1 month ago*

And to go along with this, this kind of stuff could be added in the styleset:

msglist_*.sender.bold=true
msglist_*.sender.fg=#005f87

To style based on message headers, I'm not sure if this could be done:

msglist_*.From,~John.sender.fg=#ff0000

~poldi1405 1 year, 1 month ago

Another idea: custom formatting based on non-standard headers. There are uncountable custom or otherwise non-standardised headers such as X-Priority for a priority scoring. Which would be useful to allow highlighting critical mail.

~rjarry 1 year, 1 month ago

Something like this?

msglist_*.X-Priority,1.fg=#ff0000

~konimarti 1 year, 1 month ago

On Mon Aug 1, 2022 at 11:59 AM CEST, ~rjarry wrote:

probably a new section in aerc.conf that would look something like this:

[message-list]
columns=date:20%,sender:30%,flags:3,subject
date={{.Date | DateFormat}}
sender={{.Sender}}
flags={{.Flags}}
subject={{.Subject}}

Such a change would break all existing aerc configs out there.

I kind of like the current index-format since it is very expressive and easily customizable by the user but I also see the shortcomings in terms of formatting.

Couldn't we improve the index-format parser so that each format specifier lives in its own ui grid column with its own styleset?

~rjarry 1 year, 1 month ago

I don't see how we can change this and preserve backward compatibility at the same time. Even if you would modify index-format syntax, it would break existing configs.

However, by adding a completely different configuration section, if index-format is specified and the [message-list] section is undefined, then, fallback to the old formatting. This will force us to preserve both code paths for a while but I don't see any alternative.

~poldi1405 (edited) 1 year, 1 month ago*

Something like this?

msglist_*.X-Priority,1.fg=#ff0000

Well yes, but no. Some clients like Thunderbird add an explanation (just a text like " (Highest)" to explain it. But I like the idea of putting the theme config inside the theme definitions.

Such a change would break all existing aerc configs out there.

Maybe using a different key for it would be an option that only overrides it if set

I kind of like the current index-format since it is very expressive and easily customizable by the user but I also see the shortcomings in terms of formatting.

I also quite like it, and would prefer to put most of it into the theme options (like in Robin's example)

Couldn't we improve the index-format parser so that each format specifier lives in its own ui grid column with its own styleset?

The formatter is full of TODOs as is, so I think a full rewrite might be a good first step.

~rjarry 1 year, 1 month ago

~konimarti, Aug 01, 2022 at 12:19:

Couldn't we improve the index-format parser so that each format specifier lives in its own ui grid column with its own styleset?

About "ui grid column". In my previous example, I thought exactly the same. Each element in the message-list.columns setting would live in its own column with an optional width specifier.

[message-list]
#    20% of the total width of the message list block
#            /     30% of the total width of the message list block
#            |          /    exactly 3 characters
#            |          |         /    automatic width
#            |          |         |        /
#            |          |         |        |
#            v          v         v        v
columns=date:20%,sender:30%,flags:3,subject

~konimarti 1 year, 1 month ago

On Mon Aug 1, 2022 at 12:33 PM CEST, ~rjarry wrote:

~konimarti, Aug 01, 2022 at 12:19:

Couldn't we improve the index-format parser so that each format specifier lives in its own ui grid column with its own styleset?

About "ui grid column". In my previous example, I thought exactly the same. Each element in the message-list.columns setting would live in its own column with an optional width specifier.

[message-list]
#    20% of the total width of the message list block
#            /     30% of the total width of the message list block
#            |          /    exactly 3 characters
#            |          |         /    automatic width
#            |          |         |        /
#            |          |         |        |
#            v          v         v        v
columns=date:20%,sender:30%,flags:3,subject

Exactly. I would just try to parse the existing index-format field to your column design (if no width/precision is specified, then the column width is set to ui.SIZE_WEIGHT otherwise to ui.SIZE_EXACT with the width given in the fmt specifier. Wouldn't that work? This means of course a complete rewrite internally but we could preserve the current configs.

~rjarry 1 year, 1 month ago

Exactly. I would just try to parse the existing index-format field to your column design (if no width/precision is specified, then the column width is set to ui.SIZE_WEIGHT otherwise to ui.SIZE_EXACT with the width given in the fmt specifier. Wouldn't that work? This means of course a complete rewrite internally but we could preserve the current configs.

I don't know the internals enough. But yes, adding a new message-list section would require translating index-format for older configs and avoid maintaining two completely separate code bases.

~rjarry referenced this from #113 9 months ago

~inwit 6 months ago

This is mostly solved, yay! However, it might be nice to have a way to template the full line conditionally, instead of having to configure each part. For example, say I want to apply a conditional format to mails from "builds.sr.ht". I would need to write the conditional for every column field:

index-columns = date>12,name<17,flags>4,subject<*
column-date = {{if (and (match (index .From 0).Name `builds.sr.ht`) (eq .Folder "INBOX"))}}{{else}}{{.DateAutoFormat .Date.Local}}{{end}}
column-name = {{if (and (match (index .From 0).Name `builds.sr.ht`) (eq .Folder "INBOX"))}}{{else}}{{index (.From | names) 0}}{{end}}
column-flags = {{if (and (match (index .From 0).Name `builds.sr.ht`) (eq .Folder "INBOX"))}}{{else}}{{.Flags | join ""}}{{end}}
column-subject = {{if (and (match (index .From 0).Name `builds.sr.ht`) (eq .Folder "INBOX")) -}}{{- .Style (print .ThreadPrefix .Subject) "msglist_dim" -}}{{- else -}}{{- .ThreadPrefix}}{{.Subject -}}{{- end}}

It'd be nice if I could do this in a single place.

~rjarry REPORTED IMPLEMENTED 5 months ago

Robin Jarry referenced this ticket in commit 2f46f64.

Register here or Log in to comment, or comment via email.