Show Reply-To header in message panel

[klement]

Co-Authored-By: Claude Opus 4.6 [email protected]

[The-Compiler]

Seems fine to me! I wonder if we should turn this into a setting though (similarly to what neomutt has, but in our case probably just the list of headers to show instead). What do you think?

[klement]

I like the configurable idea. How’s this for a simple solution? I don’t see much added value in the convoluted neomutt style.

[The-Compiler]

What's the point in the config option being a function, rather than just a list of headers to show? The only reason I could see is if you wanted to say "show header A if available, else show B" but that seems too convoluted to me as well.

[klement]

Yeah, exactly that. I don’t see a use case for it at the moment, but the code change is minimal and I don’t see it hurting performance or config readability. I think neomutt supports something like “ignore x-*” with “unignore x-mailer*” syntax. This should allow that I think.On 15 Mar 2026, at 21:41, Freya Bruhin ***@***.***> wrote:The-Compiler left a comment (akissinger/dodo#126) What's the point in the config option being a function, rather than just a list of headers to show? The only reason I could see is if you wanted to say "show header A if available, else show B" but that seems too convoluted to me as well. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[laarmen]

issue: this really should not be a callable. Look at the rest of the configuration options: almost none of them is callable, the only two exceptions are keybindings and the message2html_filters list of functions, both of which are natural fit for this. Here, the natural fit is just a plain list of headers, e.g.

message_headers = ['Subject', 'Date', 'From', 'To', 'Cc', 'Reply-To']

Think of it this way: what's the expected use case? AFAICT we're expecting people to add (or remove?) a couple of fields. Well, with the above, you can just do

dodo.settings.message_headers.append("List-ID")

whereas this simple operation becomes much more complex if you have to reimplement the entire function. The empty header filtering should be done in thread.py anyway.

---

nitpick: the field name is ambiguous, could also be about headers populated when writing a new email. Sadly I can't come up with anything better rn.

[klement]

My goal was to have it easily extensible and IMO the simple lambda function is still plenty readable, albeit not elegant as the .append(“XX”) syntax. I don’t really mind which it is for my use case (+Reply-To).

Would display_message_headers be a better name?

[klement]

Ah, the use case which I don’t see how a simple list could cover is something along the lines of “display [From, To, …] and all headers which [don’t] start with ‘x-‘“.

[The-Compiler]

To me this sounds like a case of premature generalization. If someone wanted to display all the X-Something-* headers (which is already kind of a stretch in my eyes, but might be valid), this could still be a list but matched with fnmatch (don't really see a downside to that, as the performance aspect is negligible and the special characters can't be in a header name anyways).

Then the only thing you couldn't do is really complex stuff, and IMHO, that's completely okay.

[klement]

Re naming, do you want to keep it as message_headers? Other names I can think of are already suggested display_message_headers or a shortened display_headers.