> If you're not arguing that, you're arguing that despite most email not being formatted to 78 character displays, email clients which can't parse most email are acceptable and not poor, which seems even more ridiculous.
First of all, I didn't make any claims about what most emails look like. Just because I don't believe what you claim, doesn't mean I believe the opposite. I don't know, and as far as I can tell, you don't either. And it's irrelevant anyhow, as people might just not be receiving a representative sample of the emails out there, so it would be idiotic to give up advantages of your own mailer because it would not be able to parse mails that you don't even receive.
Other than that, your thinking seems to be pretty one-dimensional. Email clients have more qualities than their ability to parse emails with lines longer than 78 characters (obviously, this is not really about them being unable to parse those lines, as in crashing or not displaying the mail at all, but about suboptimal handling), and some of those qualities might outweigh any disadvantage due to that. Also, it might just be that 78 character plain text mails are actually inherently superior to all the alternatives, in which case, even if the majority of emails today does not fit into that category, the sensible solution still would be to improve MUAs that send other formats rather than to make the older MUA support the inferior formats that are being widely used.
> The presence of specific mailing list client guidelines indicate that most email is not formatted to 78 character displays, a notion which you were challenging earlier.
Maybe you want to read the LKML's actual FAQ? Those "client guidelines" have very little to do with a 78 character limit, and all with how one can efficiently communicate using email, how some of the more well-known bugs in various MUAs hinder that, and how one can work around those problems. Some of that is specific to software development, but most of it really isn't at all. It just so happens that many newer MUAs tend to not support efficient work flows that have stood the test of time very well, and don't really offer any sensible alternatives either, and also tend to lack in interoperability with those (mostly older) MUAs that do support those well-working workflows.
> Just because I don't believe what you claim, doesn't mean I believe the opposite.
Do you still not believe most email is formatted at 78 characters? Really? I've stated my reasoning, you haven't refuted that or explained any alternative.
> it might just be that 78 character plain text mails are actually inherently superior to all the alternatives
No, we've already discussed why they're worse and you haven't even attempted to rebut it.
> Maybe you want to read the LKML's actual FAQ?
Yes, I have, and I'm aware that Linux kernel developers have other ideas about email workflows, eg, not 'top posting', again, they not representative of common email use cases, for the same reasons I have mentioned earlier, which you have not refuted in any way.
> Email clients have more qualities than their ability to parse emails with lines longer than 78 chars
They do, but displaying email is a critical part of email clients.
> Other than that, your thinking seems to be pretty one-dimensional.
> Do you still not believe most email is formatted at 78 characters? Really? I've stated my reasoning, you haven't refuted that or explained any alternative.
You've essentially stated that you don't know either (you haven't really read your users' emails, have you?), and I have explained why it doesn't matter anyhow, so I don't see any need to refute anything.
> No, we've already discussed why they're worse and you haven't even attempted to rebut it.
No, we haven't.
> they not representative of common email use cases
(a) Yes, they are - are you maybe confusing use cases (what it's for) with workflows (how it's applied to that use case)?
(b) How exactly is that even relevant? Because linux kernel developers are not representative of email users, it's fine to break email in a way that doesn't work for linux kernel developers? I mean, kinda my whole initial point was that exactly that is terrible engineering.
> for the same reasons I have mentioned earlier
Actually, you haven't.
> which you have not refuted in any way.
As such, there is little to refute.
> They do, but displaying email is a critical part of email clients.
so?
> Another part of email list etiquette:
Part of that is that you sincerely try to understand the other side's position, don't quote out of context, don't misrepresent, don't just repeat talking points without actually considering and addressing the other side's arguments, question your own implicit assumptions, ... - that avoids the frustration that you are seeing there.
Which is relevant how?
> If you're not arguing that, you're arguing that despite most email not being formatted to 78 character displays, email clients which can't parse most email are acceptable and not poor, which seems even more ridiculous.
First of all, I didn't make any claims about what most emails look like. Just because I don't believe what you claim, doesn't mean I believe the opposite. I don't know, and as far as I can tell, you don't either. And it's irrelevant anyhow, as people might just not be receiving a representative sample of the emails out there, so it would be idiotic to give up advantages of your own mailer because it would not be able to parse mails that you don't even receive.
Other than that, your thinking seems to be pretty one-dimensional. Email clients have more qualities than their ability to parse emails with lines longer than 78 characters (obviously, this is not really about them being unable to parse those lines, as in crashing or not displaying the mail at all, but about suboptimal handling), and some of those qualities might outweigh any disadvantage due to that. Also, it might just be that 78 character plain text mails are actually inherently superior to all the alternatives, in which case, even if the majority of emails today does not fit into that category, the sensible solution still would be to improve MUAs that send other formats rather than to make the older MUA support the inferior formats that are being widely used.
> The presence of specific mailing list client guidelines indicate that most email is not formatted to 78 character displays, a notion which you were challenging earlier.
Maybe you want to read the LKML's actual FAQ? Those "client guidelines" have very little to do with a 78 character limit, and all with how one can efficiently communicate using email, how some of the more well-known bugs in various MUAs hinder that, and how one can work around those problems. Some of that is specific to software development, but most of it really isn't at all. It just so happens that many newer MUAs tend to not support efficient work flows that have stood the test of time very well, and don't really offer any sensible alternatives either, and also tend to lack in interoperability with those (mostly older) MUAs that do support those well-working workflows.