tomas@tuxteam.de writes:
On Thu, Sep 09, 2021 at 07:45:43PM -0400, Jim Popovitch wrote: [...] > First, most folks on tech mailinglists despise HTML email. The original mail was a passable MIME multipart/alternative with a plain text part. I /think/ that is OK, what do others think?
Postel's principle applies, hence: OK :)
Perhaps you can teach you mailer to pick the text part for you :-) (I'm just asking, because I've seen this complaint a couple of times for a well-formed multipart message: personally, I'd be OK with it, but I'd like to know how the consensus is).
My mail client of choice (cone, not in Debian anymore) seems to prefer displaying the HTML part by default. It does this by converting it to a almost-text-only presentation retaining some things like bold and underline. It gets a little annoying with URLs because it displays link target and label which often leads to the same URL being displayed twice in the terminal.
AFAIK I cannot configure it to prefer the text version, but I have not checked that part of the source code to see how difficult it might be to implement such a choice. I can view both variants of the mail content on a case-by-case basis by opening them explicitly. This even works from inside the MUA, nice feature :) .
For my usage, it is easiest to have text-only e-mails because those always display nicely by default.
Additionally, in this C++ question thread, the source code was given in HTML and text parts of the e-mail and while the `#include` statements were all on separate lines in the HTML, they appear as one long line in the text part. IMHO it causes unnecessary confusion to have two slightly differently displayed parts of the same mail especially for questions with source code :)
Btw.: For C++ STL components such as `set` or `string` it is perfectly fine to not append a `.h`. In fact, it would seem not to be standards compliant to append the `.h`, cf. https://stackoverflow.com/questions/15680190
YMMV Linux-Fan öö
Attachment:
pgpHQJNrWs57x.pgp
Description: PGP signature