4 ms·

First of all, you might not have noticed, but I said that breaking backward compatibility [...] is a sign of incompetence. format=flowed was invented specifical

First of all, you might not have noticed, but I said that breaking backward compatibility [...] is a sign of incompetence. format=flowed was invented specifically because it doesn't break backward compatibility. And that is why it is good. That it might also meet the definition of "works for most users" is somewhat incidental. As you might also not have noticed, I didn't claim that something working for most users was bad, it just isn't sufficient. Then, your "for the tiny portion of unmaintained email software" mostly says something about how little you know about email software. You might be surprised, but there is a lot of email software out there that is very actively maintained and that has many active users that still expects and produces 78-column hard-wrapped plaintext bodies. It tends to be some of the most mature and powerful email software as well. Plus, there is not just "old" email software, but also old emails. My general expectation of good software is that my data stays readable without any deterioration, and I think many people with many million emails think the same. Removing presentation from content is completely orthogonal to staying backward compatible to an existing distributed system. That might be an oversight of the original design, but that's water under the bridge, we'll have to work with what we have. Incidentally, I also think that removing presentation from content is a bad idea for most uses of email, as it makes things hugely more complex without any real benefit that would be worth the additional effort (both in the implementation and for the user), at least when it goes beyond reflowable paragraphs as provided by format=flowed, that seems simple enough to me. As I said elsewhere in this thread, just because TeX and DTP are a good idea for the layout of books, doesn't mean a pencil is the wrong tool for a shopping list. Contrary to what you claim, it's not really all that fundamental a principle - it's a methodology software engineers should be aware of, including its dis- and advantages, and that has huge benefits when you need to maintain(!) tons of similar or particularly large, regular, documents, but emails mostly just don't fall into that category, so the additional effort is mostly counterproductive.

deleted 12y ago
[deleted]
nailer 12y ago
> software that is very actively maintained that still expects and produces 78-column hard-wrapped plaintext bodies... some of the most mature and powerful email software as well. It sounds incredibly powerful if it can't handle the vast majority of email produced currently.
- zAy0LfpBZLC8mAC 12y ago
  What does the vast majority of email produced currently look like and how do you know? Also, surprisingly, I, for one, don't have to read the majority of email produced. It's perfectly sufficient if I can read those emails that I receive, and the vast majority of those fit within those limitations without any problems. Hell, my guess is that the LKML (https://lkml.org/ https://lkml.org/) alone probably is the majority of my incoming mail, and that one essentially runs on "old" email clients. Though I guess that in your eyes that's a sign that the majority of kernel developers just are too stupid to know what a powerful MUA looks like ...
  - nailer 12y ago
    LKML has very strict rules as it's primarily used for patches the Linux kernel. Other mailing lists, as you may be aware, are not primarily used for software patches, since most human beings, as I would hope you realise but perhaps don't, are not software developers. > What does the vast majority of email produced currently look like and how do you know? I don't think anyone has access to the majority of the world's email, so the best we can do is take a sample of general purpose mail servers and mailing lists, of which I've run many. However: you're arguing that the vast majority of email conforms to your rules (after all, we wouldn't consider email software maintained unless it could actually handle most email - I hope you agree but at this point I wouldn't be surprised if you didn't). This is a pretty fantastical claim, and the only proof you've been able to provide is personal experience of a mailing list with single specialist audience. Which seems much weaker. In fact, that that mailing list needs to tell people what mail clients to use seems to prove my point rather than your own. I didn't say kernel developers don't know what a powerful MTA is. I didn't say anyone was stupid. You're new here and you keep breaking the HN guidelines. Perhaps you'd be better suited to a different website?

deleted 12y ago

[deleted]

nailer 12y ago

> software that is very actively maintained that still expects and produces 78-column hard-wrapped plaintext bodies... some of the most mature and powerful email software as well. It sounds incredibly powerful if it can't handle the vast majority of email produced currently.

zAy0LfpBZLC8mAC 12y ago
What does the vast majority of email produced currently look like and how do you know? Also, surprisingly, I, for one, don't have to read the majority of email produced. It's perfectly sufficient if I can read those emails that I receive, and the vast majority of those fit within those limitations without any problems. Hell, my guess is that the LKML (https://lkml.org/ https://lkml.org/) alone probably is the majority of my incoming mail, and that one essentially runs on "old" email clients. Though I guess that in your eyes that's a sign that the majority of kernel developers just are too stupid to know what a powerful MUA looks like ...
- nailer 12y ago
  LKML has very strict rules as it's primarily used for patches the Linux kernel. Other mailing lists, as you may be aware, are not primarily used for software patches, since most human beings, as I would hope you realise but perhaps don't, are not software developers. > What does the vast majority of email produced currently look like and how do you know? I don't think anyone has access to the majority of the world's email, so the best we can do is take a sample of general purpose mail servers and mailing lists, of which I've run many. However: you're arguing that the vast majority of email conforms to your rules (after all, we wouldn't consider email software maintained unless it could actually handle most email - I hope you agree but at this point I wouldn't be surprised if you didn't). This is a pretty fantastical claim, and the only proof you've been able to provide is personal experience of a mailing list with single specialist audience. Which seems much weaker. In fact, that that mailing list needs to tell people what mail clients to use seems to prove my point rather than your own. I didn't say kernel developers don't know what a powerful MTA is. I didn't say anyone was stupid. You're new here and you keep breaking the HN guidelines. Perhaps you'd be better suited to a different website?