Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Jun 2020 16:47:51 +0200
From:      Polytropon <>
To:        Chris Knipe <>
Cc:        Aryeh Friedman <>, "Steve O'Hara-Smith" <>, Polytropon <>, FreeBSD - <>
Subject:   Re: Mailing List Etiquette was freebsd vs. netbsd
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <> <> <> <> <> <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Tue, 16 Jun 2020 16:04:21 +0200, Chris Knipe wrote:
> On Tue, Jun 16, 2020 at 4:01 PM Aryeh Friedman <>
> wrote:
> >
> >
> > On Tue, Jun 16, 2020 at 9:54 AM Chris Knipe <> wrote:
> >
> >>
> >> Why can't your MUA be intelligent enough to wrap emails with > 74
> >> characters on a line?
> >>
> >
> > Because programs that try to be "smart" about things are often "too smart
> > for their own good".   For example what is to stop it from wrapping
> > something that for various reasons *HAS* to be longer than 74 chars (like
> > code) when such wrapping destroys the ability to cut and paste from the MUA
> > into another file for testing?
> >
> > Here goes a good example:
> >
> >
> Simple - don't email it.

Why not?

> If you do, attach it as an attachment (MIME is
> there for a reason)...
> There's GIT / CVS / Take your pick for a reason... :-)

Those are external resources that can vanish for some reason.
The goal of the mailing list is that messages can be processed
off-line, and they are perfectly allowed (!) to contain things
like source code, ASCII tables, even simple networking diagrams
or even formulas. Incornporating "external technology" for
something the medium can do in its own doesn't sound very
convenient (even though it sounds "modern", so it could probably
appeal to certain users just due to this fact). Some mailing
lists, such as this one, do not use binary attachments.
Using text attachments for code is probably possible.
However, this is a _discussion_ mailing list, not primarily
intended for sharing code. That doesn't stop users from
presenting code in the context of questions (and when I say
code, I also mean scripts, logs, sometimes ASCII diagrams,
or configuration files).

In an earlier message I presented an example for a MUA/MTA
construct that was "too smart" - in fact: stupid, which therefore
collapsed everything into one single line, and it doesn't matter
if another MUA displays that single line as one line, requiring
you to scroll, or rensers it as a paragraph (ragged right or
justified). The result was an unusable message. I also presented
the workaround the users became friends with. :-)

Visual presentation of data is a different "layer" than
the data itself. And there is no 1:1 relation. Things like
font size and displaying should not be a matter of the
mail message itself, except... yes, it's not that easy!

As a programmer, you will surely agree that there is:

a) text that should be presented as it was written,

b) text that the MUA is free to (and should) arrange, and

c) text where it simply doesn't matter what the MUA does.

Making this choice isn't always easy. Multipart-MIME can be
helpful. Even though a mailing list is, by no means, a "one size
fits all" solution, so there is a certain consensus about what
is useful and what is rather not. This consensus changes over
time, and within this consensus, there are many ways a user can
express his questions, answers, suggestions and thoughts in a
mailing list message.

Physical things like display size can have significant influence,
as well as the kind of device in use, and the way that device is
configured. Screens have lots of parameters: { physical size in cm,
physical size in px, giving resolution / density } x { software
graphics resolution, font face, font size, magnification applied }.
It's just not easy to predict - from _your_ point of view -, how
a message will be displayed to someone else. You can hope their
setting matches what works for you, but you cannot expect that.
Coming from a multi-OS background, interoperability, compatibility
and "must work everywhere" is something that I consider important,
while being cautious that it doesn't become a "race to the bottom"
where only the most basic things work everywhere, while things
break as soon as you add something simple or obvious. Mailing
lists are such a versatile medium: They can be used with plenty
of MUAs, processed and used (!) in many different ways, that's
what makes them so valuable for technical people, but also for
novices who have started understanding _what_ they're using.

Oh, and don't get me wrong: Mail is no replacement for a source
control system, but we're not talking about source control, we're
talking about mailing list etiquette, in a polite, humble, often
technical and sometimes funny way. :-)

< I ate your 80 column punched cards! >
  \     .    _  .    
   \    |\_|/__/|    
       / / \/ \  \  
      /__|O||O|__ \ 
     |/_ \_/\_/ _\ |  
     | | (____) | ||  
     \/\___/\__/  // 
     (_/         ||
      |          ||
      |          ||\   
       \        //_/  
       __ || __||

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

Want to link to this message? Use this URL: <>