A great example of the HN use of the word "just".
text/html; firefox '%s' &; test=test -n "$DISPLAY"; needsterminal;
The argument GP was making is that what is obvious to one reader may not be obvious to another. So using the words “simply” or “just” or “obviously” does not add information, except to signal that you feel the reader is ignorant if they are not aware of what you’re explaining.
My PhD advisor always crossed these words out of my scientific writing, and I think it was a good change to make.
I do want to point out that I didn't use those words fully consciously and I most certainly did not mean to imply the reader was ignorant. The only thing those words were signalling is that the action in question does not take much effort (once you know it).
Regardless of the argument, it's not obvious to anyone unless they've taken the time to read the documentation and possibly read through some examples. While there are those who may feel that it's simple and/or obvious after they have gained that knowledge, it shouldn't relieve anyone of the responsibility to read documentation and figure these things out for any tool that they use.
My point is that if you don't have those two constraints, it's trivial to do and it works perfectly.
And then map a separate key when you are sure...
On a related note, while I love the UX of mutt, I do find proportional fonts to be significantly more readable than fixed-width fonts for paragraphs of natural-language text.
Given the near ubiquitous use of top-posting and quoting the entire message that's being replied to, it stands to reason that others are not really reading the quoted material and are just reading the response on top.
> and the inability to have inline images
I wonder when email clients like Outlook would start rendering images based on a URL included in the message, similar to what Slack does. That could allow one to effectively include an inline image, which would be seen as a URL in other clients.
Given the proliferation of rendering a thread of messages and showing them as a conversation (i.e., conversation view), reading the quoted material within the same message is not really necessary.
> Technical (and also nontechnical) exchanges often consist of a dozen messages about a particular topic spread over weeks or sometimes months, where at almost each step you want to go back in the conversation to look at details of the previous discussion or to refresh your memory.
While I have seen this done in threads where people follow the conventions of a typical mailing list or usenet newsgroup by replying inline and quoting only parts of the text they're responding to, I have not seen the equivalent in a threaded conversation in outlook. And, as you note:
> Outlook also doesn't have a great UX for that.
While they have addressed the UX issue to some extent with the conversation view, it still doesn't really lend itself to easily following the discussion amongst multiple people due to the fact that they don't typically use different subthreads under the same email chain.
For sending emails with formatting (italics, headings), I use Markdown in Vim then press H in Mutt before sending, which pipes it through an appropriate filter:
set send_multipart_alternative_filter=html_alternative send-hook . 'set send_multipart_alternative=no' macro compose H ':set send_multipart_alternative=yes<Enter><view-alt-mailcap>' 'add HTML alternative'