[erlang-questions] Announcing Erlang.org Code of Conduct

[Anthony Ramine]

Le 19 mars 2015 à 22:38, Richard A. O'Keefe <ok@REDACTED> a écrit :

> 
> On 20/03/2015, at 2:22 am, Anthony Ramine <n.oxyde@REDACTED> wrote:
>> 
>> Why is your window so large that my message is uncomfortable? Why waste the screen estate if you want it to show short lines? Want short lines? Have a narrow window.
> 
> My eyesight is not what it used to be.
> Sometimes I have to make things bigger to see details.
> It's a pain in the arse to have to keep changing the
> window size.
> (This is also why I find reading e-mail on a phone
> unimaginable, no matter what the length of the lines.)

Sure, but that doesn't mean the mailing-list should follow conventions that makes the experience bad for those with a better eyesight.

> If I am looking at mail, I could use the *whole* of
> the screen and it would not be in any sense "wasted".
> 
>>> Especially tables.
>> 
>> Eh? Prose will look good when reflowed under LaTeX algorithms. Why mention tables when I'm comparing LaTeX to mails in the context of reading prose?
> 
> You don't sound as if you have much experience with TeX.
> The big difference between TeX and Word is that when TeX
> is about to produce poor output, it *tells* you.  That's
> what "underfull box" and "overfull box" are about.
> If your prose has long technical terms or embedded chunks
> of code you can expect a problem every few pages.
> Fix it for A4, and you WILL have to fix it again for US.
> 
> Why mention tables?  Because this is the first time
> anyone has mentioned 'prose'.  I thought we were talking
> about e-mail.  I've often received e-mail containing
> tables, and I've sent e-mail containing tables.
> 
> Just today in a lecture I reflowed something for the
> sake of a student with worse eyesight than mine, and
> the line breaks were *horrible*.
> 
> Above all, e-mail in a group devoted to a programming
> language will often contain "text" lines that are
> actually code.

Given the state of emails, there will always be cases where it's hard to read on some MUAs, that doesn't mean the most common case, i.e. prose, should be badly handled. Just like how most flowing of plain prose is not a problem in LaTeX.

>> No, your own mail client doesn't use any combination of encoding and content type that let the text reflow, hence why it looks bad on my phone, and just losing screen estate on my computer. [2]
> 
> No, my own e-mail client *does* reflow, all the time.
> It's listed in the format=flowed FAQ as ones of the
> ones that supports f=f.

From a quick reading of RFC2646, the format=flowed parameter was introduced because of the problem I described, it even talks about an "Embarrassing Line Wrap". The parameter was introduced to distinguish reflowing text from other text/plain contents because MUAs should not be expected to reflow plain old emails as the ones you send.

>> Yes there is something that stops my mobile mail reader from re-breaking your paragraphs: your very email forbids it through its Content-Transfer-Encoding and Content-Type. Just look at the raw email you sent.
> 
> I'm seeing
> 
> Content-Type: text/plain;
> 	charset=windows-1252
> ...
> Content-Transfer-Encoding: 7bit
> 
> The character set I use is in fact *NOT* Windows-1252.
> "7bit" means that what I'm sending
> "is all represented as short lines of US-ASCII data".
> It says NOTHING about whether the receiver may reflow it.
> 
> As for Content-Type: text/plain,
> "The primary subtype, "plain", indicates plain (unformatted)
> text.  No special software is required to get the full
> meaning of the text, aside from support for the indicated
> character set."
> Again, this says that fancy formatting is not REQUIRED
> "to get the full meaning"; it says NOTHING about whether
> reflowing is ALLOWED.

Note that your Content-Type doesn't include format=flowed. I mentioned Content-Transfer-Encoding because if you look at my own emails, they don't include format=flowed either. Instead, they send the mails as quoted-printable and all return lines required to be a valid email are escaped with an equal sign; then the recipient MUA reflows the text to make my actual long lines fit. I would rather have format=flowed but at least most MUAs can still properly render it, including the more modern (and as usual, worse, I agree) ones.

> If your MUA doesn't reflow to fit your phone,
> that's a choice of its designers, NOT something
> forced by these headers.

It doesn't reflow because your mail doesn't include format=flowed, that is not a choice of its designers in my book.