[Tutor] OT: Line wrap

[dn]

On 17/09/2022 06.54, Torbjörn Svensson Diaz wrote:
> On 2022-09-16 20:24, Jim Byrnes wrote:
>>
>> It's more complicated than I remembered. Settings-->General scroll
>> down to the bottom and click config editor. Then type wrap  in the
>> search box. The setting you want is mailnews.wraplength.
> 
> 
> I tried this and it seems as though it's in my display that there's
> something wrong. When I view source of emails that I sent to email
> lists, everything is working the way it should. But when I read then in
> the normal way, lines do not wrap the way I want them to. Instead I see
> very long lines. What to do?

Am impressed, even amazed, that you have taken the trouble to read 'the
manual' and other rules relating to our Discussion List. Thank you!


Like many conventions and regulations there are multiple dimensions to
the background reasons and considerations. The TLDR; is that the
80/79/75 is historical and largely does not apply today. So, most have
(actively or passively) ignored it and 'moved-on'. Please join our
community, ask your questions, mentor others, and generally make the
[?Python] world a better place...


The long form:

Simple text cf HTML
Writing cf Reading
Text cf Code
Email "reflectors"

Line-limits are a hold-over from the days of punched-cards and early
VDU-screens on mini-computers (of fond memory only to us grey-beards).
Now that higher-resolution screens are in popular-use,
considerably-longer lines can be displayed across a screen - even across
a sheet of paper (remember that technology?). Similarly, we no longer
use punched-cards as an input-device (despite their excellence for
re-cycling as book-marks and ToDo/shopping-lists).

When typing, it probably doesn't matter how wide the screen, or how far
it might allow the line to extend. Contrarily, when reading, width
matters. The established view is that speed-reading is best achieved by
keeping both head/neck relatively-still, and attempting to see as much
of a line of text at a time without extra effort. Accordingly, the width
or a line at reading-time is (?should be) limited by one's
field-of-view* and quality of eye-sight. (why are novels and text-books
produced in set formats? why are newspapers - particularly
"broad-sheets" divided into columns?)

* needing glasses/spectacles, I can't wear bi-focals because their 'dot'
of close-up focus is too narrow for reading, ie how to become sea-sick
without leaving port.

Originally email was limited to the characters in the 7-bit ASCII-code.
This meant that many languages/scripts were excluded. It even limited
'fancy features' such as the use of /italics/ or *bold-text* to make
points 'stand out', or underlines to identify URLs (for example). These
days are passed, with most OpSys and email-systems adopting UniCode.

Another 'new-development' now relegated to the distant-past has been
enabling different fonts. Not merely a matter of appearance, but with
"proportionally-spaced fonts". Suddenly the definition of line-length
had to change! Two lines which could fit into exactly the same
width/number of horizontal-pixels might contain quite different numbers
of characters by virtue of font-choice. Width became defined in pixels
or centimetres/inches. (on which point, maybe this essay should cease;
and the list-requirement defined in characters, be expunged!)

When Microsoft finally (and very late) climbed-aboard the
'Internet-bus', they had a mind to web-ify everything. (You can still
find web-pages which were built using MS-Word and are
horrendously-bloated as a result) This included their email-client
offerings, starting with Outlook Express and rapidly-thereafter,
full-fat Outlook.

Accordingly, they offered a choice of "HTML format" or "Simple text
format". At which point opportunity abounded or the downfall began -
depending upon your point-of-view. Marketing folk went 'nuts', and
started producing email-messages with all manner of 'bells and whistles'
- only to discover that many email-clients were incapable of displaying
same. Thus, giving rise to a veritable industry of people associated
with ascertaining what works, and what doesn't - and generations of
marketing-wonks who, to this day, haven't figured it out - because "I
don't 'do' technology" (yet still know how to choose flash cars,
offices, ... - can you detect any bias?).

Back to "bloat": much HTML-laden email is (still) sent as a
game-of-two-halves, with a "simple text version" as well (for the
benefit of 'simple' email-clients or email-users?). Thus, many
email-clients offer a choice of which to display (first). This all
contributed to the plaintive question amongst IT-specialists and
non-specialists alike: "why does it take so long for this message to
load?" I expect that as bandwidth-to-the-desktop has increased, we don't
hear this so-often. Although, many a SysAdmin will confirm that the
space-required on the backing-store for email has exploded (this only
one of many factors) - hence: 'please prune your archives...'!

The sad part was that MSFT chose to trumpet their HTML-offerings in the
style of recent-converts proselytising (aka "feature creep",
"marketing", and "give us more of your money"), and by denigrating 'the
old ways'. Thus, calling it "Simple text format". What they failed to
foresee was how the HTML-option would become a vehicle whereby viruses
and other security risks could become embedded within email messages (cf
.doc, .PDF, etc, viruses embedded in "attachments"). Not too 'smart'
then? Accordingly, a good reason many of us chose to stick with "Simple
text format"!

Rather than equating "simple" with 'brainless', 'stupid', or
'unintelligent'; please review what "The Zen of Python" has to say on
the subject.

In relation to line-length, Thunderbird is currently limiting these
typed-lines to something less than 80-characters, and auto-magically
performing a word-wrap when (it deems) necessary. I have no recollection
of setting this myself - however, this Tb-profile probably dates-back
decades; having migrated from machine-to-machine, OpSys-to-OpSys, and
version-to-version (even country-to-country) over the period.

When it comes to reading, the OP's didn't, but @Avi's and @Jim's replies
featured paragraphs (text between Enter-keying*) longer than 'the
limit'. Thunderbird presents these according to the width of the
containing-panel. Displaying the message in its own window will
(potentially) extend line-length to the width of the screen/resolution
of the display (etc). Keeping it within a panel sharing the screen with
'folders' and 'headers' panels restricts display-width.

Accordingly, upon display, both HTML and 'Simple text' will "flow"
according to the width of the application-window (HTML may be subject to
other formatting-factors). Thus, control is the hands of the
email-recipient, ie "beauty is in the eye of the beholder" and "suit
yourself".

* there's another issue: different OpSys terminate a line/paragraph with
either an LF-character or a CR+LF combination. What joy when one's work
has to move-between/work for both!

Matters of style in Python are frequently driven by PEP-008 (even though
it does not necessarily apply). This also refers to a line-limit. The
justification there comes back to 'reading'.

We often need to see code reproduced in messages to this list. Thus,
there could be two 'line limits' to face! In some cases (and some
first-time post-ers) the OpSys line-ending differences become apparent,
or indentation is 'lost'. Again, this is less-likely to happen when
using "simple text" (but not impossible)!

OTOH if the author is committed to HTML-format, adjusting
code-presentation to use a fixed-width (mono) font would be a great
favor to the reader(s) - but, in-turn assumes that the reader's computer
offers the same or some compatible font!

The nature of this list is to develop conversations (just as 'here').
Accordingly, messages start-out neatly-formatted. As replies develop
into "threads" of replies-to-replies, most email-clients differentiate
the stages of the conversation by color-coding (HTML-format) and/or
indenting older-text with a prefix/marker. Inevitably, longer lines will
thus exceed a line-length limit and will be 'wrapped' and then
're-wrapped' creating little 'stubby' part-lines. This becomes ugly,
very quickly! Probably most adapt to the situation and accept it. If
code is to remain readable, then life becomes difficult!

Sometimes code is mis-represented in the original post. The Python
Console or REPL prefixes code-lines with three right angle-brackets
(">"). If such code is copied from the terminal into an email-message,
the recipient's email-client may mis-interpret the prefix-characters in
a non-Pythonic fashion. Sad to say...

This leads to a social (rather than technical) call (of many Discussion
Lists), that replies be "interposed", "top-posted", or "bottom-posted".
The latter avoid the issue of replies being auto-indented and lines of
text being re-wrapped as a result. The former reproduces the flow of
normal human conversation: you ask a question, and I (subsequently)
answer it, point-by-point.

Finally, we come to the underlying technology of the list itself. A
"reflector" is a specialised email-server which accepts a single-message
(from a member) and broadcasts ("reflects") it 'out' to all of
list-members. There are options relating to how such servers are
configured, which affect messaging - and with which we must all live.
This is the point at which only certain formats are accepted, and (a
frequent error by first-time post-ers) specific attachments are
unceremoniously and "silently" stripped (eg "Tutor" will not accept
graphics). Interestingly some such restrictive ideas relate to
'security' (eg viruses) but others date-back to a time when message-size
and 'bandwidth' considerations were rated more-important (perhaps a
trend re-emerging as mobile-users become impatient with long-load times,
excessive memory demands, and paying over-the-odds traffic-fees).

Am closing in appreciation of the concern-raised, and expressing hope
that you will bring much value to the community through attention to
detail and consideration of others...
-- 
Regards,
=dn