Just testing out mailman.. ignore. :-)
Some HTML things.. - A bullet list. - Second item. A number list.. 1. Uno 2. Dos Some *different* *formatting* for *words* and such. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net
On Sat, Aug 30, 2025 at 6:48 AM Ted Lyngmo via Boost <boost@lists.boost.org> wrote:
Old netiquette: Send plain-text messages.
Old Boost list etiquette: * Don't top-post. * Don't overquote. ;-) -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net
On Sat, Aug 30, 2025 at 4:48 AM Ted Lyngmo via Boost <boost@lists.boost.org> wrote:
Old netiquette: Send plain-text messages. Especially to mailing lists.
Mailing lists are declining in popularity. This is not just a Boost problem; Alliance researchers have analyzed other development project mailing lists and they all show a steady decline in participation starting around 2010. We don't plan to remove the Boost mailing list and we do want to improve the web-based front end, it is called Postorius[1] and part of mailman3. I would like to see improvements in the quality of the posts mailing list and this includes being able to write code blocks, applying styles to text (e.g. italic, bold). The ability to add bulleted or numbered lists, proper tabs, monospaced type, and so on. In other words all of the features that we are accustomed to using on the web. It is not clear to me how restricting all messages to plain text is a sustainable choice. Is the goal to discourage new participation and drive the list into extinction? [1] https://docs.mailman3.org/projects/postorius/en/latest/
Anyway here is the web page for this discussion so you can see what Postorius looks like. We have not made any changes to the template or stylesheets, so the appearance is stock.
On 30 Aug 2025 16:54, Vinnie Falco via Boost wrote:
On Sat, Aug 30, 2025 at 4:48 AM Ted Lyngmo via Boost <boost@lists.boost.org> wrote:
Old netiquette: Send plain-text messages. Especially to mailing lists.
Mailing lists are declining in popularity. This is not just a Boost problem; Alliance researchers have analyzed other development project mailing lists and they all show a steady decline in participation starting around 2010. We don't plan to remove the Boost mailing list and we do want to improve the web-based front end, it is called Postorius[1] and part of mailman3. I would like to see improvements in the quality of the posts mailing list and this includes being able to write code blocks, applying styles to text (e.g. italic, bold). The ability to add bulleted or numbered lists, proper tabs, monospaced type, and so on. In other words all of the features that we are accustomed to using on the web.
It is not clear to me how restricting all messages to plain text is a sustainable choice. Is the goal to discourage new participation and drive the list into extinction?
Plain text is the only sustainable format for long-term online communication. It has lived for as long as digital communication existed and it continues to be the most portable and easy to work with format. Anything else is extremely dependent on the platform and/or client and can be a real PITA. Whatever you do on the web forum side of the ML, please make sure that all posts are sent (and perfectly viewable) as plain text over email to the ML subscribers.
On Sat, Aug 30, 2025 at 7:42 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
Plain text is the only sustainable format for long-term online communication
Rich‑text (Markdown/HTML) makes C++ mailing‑list discussions clearer than plain text. It preserves code exactly (indentation, tabs, long lines), highlights identifiers, and avoids smart‑quote breakage. Structured text—headings, lists, steps—lets people skim proposals; diagrams and benchmark figures remove guesswork; quoting exact lines stays stable. Archives become searchable documents and are easier for screen readers. There’s no downside: send multipart/alternative with a clean plaintext sibling and a sanitized HTML version; block remote images; keep patches in plain text; publish a tiny style guide. Result: fewer misunderstandings, faster reviews, better archives. We don’t allow undefined behavior in code; let’s avoid undefined meaning in email. And no Comic Sans.
On 2 Sep 2025 16:38, Vinnie Falco wrote:
On Sat, Aug 30, 2025 at 7:42 AM Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
Plain text is the only sustainable format for long-term online communication
Rich‑text (Markdown/HTML) makes C++ mailing‑list discussions clearer than plain text. It preserves code exactly (indentation, tabs, long lines),
Plain text also does.
highlights identifiers,
No, it doesn't, unless you manually mark them. Which you can also do in plain text, if needed.
and avoids smart‑quote breakage.
I don't know what this means. Decent email clients handle quotations, including nested ones, just fine.
Structured text—headings, lists, steps—lets people skim proposals;
All of these exist in plain text.
diagrams and benchmark figures remove guesswork;
Markdown and HTML don't support diagrams or other graphical figures. If you mean images, then yes, but I don't think this would be an actually desirable feature. First, they are not searchable, and second, they tend to be misused in various ways, like posting jokes and comics from the internet. No, thanks. When was the last time when you wanted to draw a graph, or heck, even a table, in a reply to the ML? I mean something actually useful, not the silly stuff from xkcd or demotivator. Personally, I have a hard time remembering if I even had such a need once.
quoting exact lines stays stable.
Again, I don't know what this means.
Archives become searchable documents and are easier for screen readers.
Markup and images do not improve searchability, quite the opposite.
There’s no downside: send multipart/alternative with a clean plaintext sibling and a sanitized HTML version; block remote images; keep patches in plain text; publish a tiny style guide. Result: fewer misunderstandings, faster reviews, better archives. We don’t allow undefined behavior in code; let’s avoid undefined meaning in email.
Multipart email is problematic because clients tend to try and display the HTML version, and then butcher the original message when one tries to reply, leaving it to the responder to deal with this mess manually. No HTML, please, plain text only.
And no Comic Sans.
Right, and that's a point in favor of plain text again. Everyone chooses the font they like to view messages.
Andrey Semashev wrote:
Multipart email is problematic because clients tend to try and display the HTML version, and then butcher the original message when one tries to reply, leaving it to the responder to deal with this mess manually. No HTML, please, plain text only.
Clients can be configured to display plain text. I've set mine to do exactly that.
El 02/09/2025 a las 18:14, Peter Dimov via Boost escribió:
Andrey Semashev wrote:
Multipart email is problematic because clients tend to try and display the HTML version, and then butcher the original message when one tries to reply, leaving it to the responder to deal with this mess manually. No HTML, please, plain text only. Clients can be configured to display plain text. I've set mine to do exactly that.
There, there. Joaquín M López Muñoz
On 2 Sep 2025 19:14, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
Multipart email is problematic because clients tend to try and display the HTML version, and then butcher the original message when one tries to reply, leaving it to the responder to deal with this mess manually. No HTML, please, plain text only.
Clients can be configured to display plain text. I've set mine to do exactly that.
This doesn't work well because some messages I receive are barely readable as plain text, if at all. Those are messages from various online services and stores, and some bug trackers (e.g. Jira from Qt). Those are usually messages that you aren't supposed to reply directly, so HTML doesn't pose a problem there. It would've helped if there was a way to set the preference on per-folder granularity, but I can't see such a way in the email clients I use.
Andrey Semashev wrote:
On 2 Sep 2025 19:14, Peter Dimov via Boost wrote:
Clients can be configured to display plain text. I've set mine to do exactly that.
This doesn't work well because some messages I receive are barely readable as plain text, if at all. Those are messages from various online services and stores, and some bug trackers (e.g. Jira from Qt).
Outlook has a "show original HTML" override for those cases, although my general experience is that if a mail is unreadable in plain text, I probably don't need to read it anyway.
On 2 Sep 2025 19:41, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
On 2 Sep 2025 19:14, Peter Dimov via Boost wrote:
Clients can be configured to display plain text. I've set mine to do exactly that.
This doesn't work well because some messages I receive are barely readable as plain text, if at all. Those are messages from various online services and stores, and some bug trackers (e.g. Jira from Qt).
Outlook has a "show original HTML" override for those cases, although my general experience is that if a mail is unreadable in plain text, I probably don't need to read it anyway.
Thunderbird only has a global option. I don't see an option in Aqua Mail. I wonder if it is possible to add an option to the ML subscription page to only receive messages in plain text.
On 2 Sep 2025 16:38, Vinnie Falco wrote:
On Sat, Aug 30, 2025 at 7:42 AM Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
Plain text is the only sustainable format for long-term online communication
Rich‑text (Markdown/HTML) makes C++ mailing‑list discussions clearer than plain text. It preserves code exactly (indentation, tabs, long lines), highlights identifiers, and avoids smart‑quote breakage. Structured text—headings, lists, steps—lets people skim proposals; diagrams and benchmark figures remove guesswork; quoting exact lines stays stable. Archives become searchable documents and are easier for screen readers. There’s no downside: send multipart/alternative with a clean plaintext sibling and a sanitized HTML version; block remote images; keep patches in plain text; publish a tiny style guide. Result: fewer misunderstandings, faster reviews, better archives. We don’t allow undefined behavior in code; let’s avoid undefined meaning in email. And no Comic Sans.
And by the way, to reinforce my point, this message from you was encoded in multipart, and it looked drastically different in my email client (Thunderbird) from the other correspondence, on this list or elsewhere. Specifically, it was rendered using a different (proportional) and smaller font from the other messages, and it used a different line length. This made reading the message more difficult than necessary.
On 2 Sep 2025 18:27, Andrey Semashev wrote:
On 2 Sep 2025 16:38, Vinnie Falco wrote:
On Sat, Aug 30, 2025 at 7:42 AM Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
Plain text is the only sustainable format for long-term online communication
Rich‑text (Markdown/HTML) makes C++ mailing‑list discussions clearer than plain text. It preserves code exactly (indentation, tabs, long lines), highlights identifiers, and avoids smart‑quote breakage. Structured text—headings, lists, steps—lets people skim proposals; diagrams and benchmark figures remove guesswork; quoting exact lines stays stable. Archives become searchable documents and are easier for screen readers. There’s no downside: send multipart/alternative with a clean plaintext sibling and a sanitized HTML version; block remote images; keep patches in plain text; publish a tiny style guide. Result: fewer misunderstandings, faster reviews, better archives. We don’t allow undefined behavior in code; let’s avoid undefined meaning in email. And no Comic Sans.
And by the way, to reinforce my point, this message from you was encoded in multipart, and it looked drastically different in my email client (Thunderbird) from the other correspondence, on this list or elsewhere. Specifically, it was rendered using a different (proportional) and smaller font from the other messages, and it used a different line length. This made reading the message more difficult than necessary.
It also broke nested quotation indication for my message at the top.
On 26 Aug 2025 20:31, René Ferdinand Rivera Morell via Boost wrote:
Some *different* *formatting* for *words* and such.
BTW, you would typically use ASCII formatting in plain text, such as *bold* or /italic/. Some clients are able to interpret this markup. For example, Thunderbird displays all three words in your quote in bold.
participants (6)
-
Andrey Semashev -
Joaquin M López Muñoz -
Peter Dimov -
René Ferdinand Rivera Morell -
Ted Lyngmo -
Vinnie Falco