<div dir="ltr"><div>These discussions about top posting (which is the default in most mua now) seem quite frivolous...</div><div><br></div>Top posting is about providing an *over*view , what generally follows is the context of this overview (ie the previous mail). Some are also attaching this context. Bottom posting is about answering to a context. Some prefer to answer inline. Some are mixing top posting and inline content to provide a more accurate message (ie. giving an overview and answering in detail)<div><br></div><div>See all of these methods answers to different types of communications. Imposing one over the other is a nonsense imo... As for the 80 chars limit in mail I stopped since a long time to have it, since i had to do it manually and like Loic and others noticed it provides different results depending on the machine or mua. </div><div><br></div><div>Anyway we can have long debate about it but it seems weird to have it in a thread about a CoC which goals is to welcome others.</div><div><br></div><div>- benoit</div></div><br><div class="gmail_quote">On Thu, Mar 26, 2015 at 7:14 AM Vincent de Phily <<a href="mailto:vincent.dephily@mobile-devices.fr">vincent.dephily@mobile-devices.fr</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thursday 26 March 2015 12:09:12 Loïc Hoguin wrote:<br>
> You say this but you have the same problem as zxq9. In my client your<br>
> "properly formatted email" has line breaks about every 80 characters,<br>
> which results in every second line being exactly one word. It wouldn't<br>
> be like this if you or your client didn't put those line breaks.<br>
><br>
> It's interesting because you say the writer has to format his email<br>
> keeping in mind how people will read it, in an email that is actually<br>
> much harder to read for me than top posting.<br>
<br>
I'm sorry to hear that. I was aware of clients that couldn't display more<br>
than 80 chars, but it seems yours has a lower limit.<br>
<br>
The cut at 78 chars is indeed my MTU's doing. Having every second line<br>
consisting of just one word is your MTU's doing. See the archives :<br>
<a href="http://erlang.org/pipermail/erlang-questions/2015-March/084025.html" target="_blank">http://erlang.org/pipermail/<u></u>erlang-questions/2015-March/<u></u>084025.html</a><br>
<br>
I find such a receiver-side display limit anachronistic, but it seems that<br>
it can't be helped, so here's a mail reconfigured to cut at 74 chars for<br>
your viewing pleasure.<br>
<br>
I'm on record saying that 74 chars is a silly limit, and I'd prefer if<br>
word-wraping was only done at display time, but plaintext being what it<br>
is, wraping must still be done at writing time in some cases (for example<br>
when indenting bullet points). Html emails may be a solution, but they're<br>
a horrible one.<br>
<br>
So we still have to deal with write-time wraping at a lowest common<br>
denominator cutoff point. Thanks for reminding me that 78 chars was still<br>
too wide; are you sure you can't upgrade ? :p<br>
<br>
<br>
> Considering the very large number of clients and possible<br>
> configurations, I find it very odd to blame the one writing the email<br>
> instead of the client being used to read said email.<br>
<br>
There. I blamed your mail reader for pointlessly wraping my<br>
conservatively-sized lines. Sometimes it's the writer's MTU, sometimes the<br>
reader's, sometimes the MTA, sometimes the human... Let's deal with each<br>
separately.<br>
<br>
<br>
> An email isn't a PDF, it *will* display differently everywhere.<br>
<br>
Yes, I've mentioned that issue above.<br>
<br>
<br>
> Should I, as an email writer, be careful about using the ')' character<br>
> just because many clients will convert it to a smiley?<br>
<br>
You should, on any medium, be aware of your reader's general limitations.<br>
That doesn't mean that you absolutely must deal with every silly case.<br>
Accidental smileys are frequent enough, especially with computer code, so<br>
I hope that the reader has a way to turn them on and off. Like it should<br>
have a way to temporally use monospaced fonts when someone sends an ascii<br>
diagram.<br>
<br>
<br>
> Though I'm guessing your answer there is "no because my client doesn't<br>
> do it and my client is right and all others are wrong".<br>
<br>
I hope I don't sound that obnoxious ?<br>
<br>
<br>
> It is trivial to detect the rest of an email is just a quote and the<br>
> client should indicate that (it would also be useful for those who do<br>
> quote inline but leave a large quote unanswered at the end),<br>
<br>
All MTUs I know display quotes a bit differently, sometimes even<br>
collapsing them by default. That makes parsing them easy for the user<br>
(though there's still that gmail bug that puts the first line of the reply<br>
inside the quote...), but it's still be nice to avoid having to parse the<br>
quote if the quote wasn't necessary to begin with.<br>
<br>
<br>
> just like it should be trivial for my client to change the flow of text<br>
> to make it readable instead of the mess it makes right now.<br>
<br>
My client (kmail) happens to help with that by re-adding the proper quote<br>
markers when I hit enter inside a quote, but I'd say that the general case<br>
is not trivial. The only MTU that I remember being good at that is gnus<br>
(an emacs mode), most other MTUs I've seen don't help at all.<br>
<br>
<br>
> I find it fascinating that the code of conduct has only had the opposite<br>
> of the intended effect so far.<br>
<br>
The paragraphs about style have been removed from the CoC, so this thread<br>
is not really about CoC anymore. And as much as I dislike top posting,<br>
it's a trivial issue compared to verbal abuse.<br>
<br>
--<br>
Vincent de Phily<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</blockquote></div>