Hi Mouse, At Z-0500=2025-12-04Thu09:48:13, Mouse sent: > >>> What I'd like to be able to do is to browse, but as I am browsing, to > >>> ke$ > >> It would help readability if you'd avoid paragraph-length lines. > > I love plaintext email aside from just this one issue. But if u > > insist. > > Oh, I don't insist. If you don't care how easy it is for people to > read your mail, don't bother. But then don't be surprised if people > drop your mail instead of going to the trouble needed to read it. > (Depending on the reader's mail setup, that could be anything from zero > to substantial.)
While I comply with most demands of netiquette,
such as not top-posting, not using HTML email, & various others,
this is the one issue that substantially causes me a lot more trouble than
what non-hard-wrapped lines cause other people, I'm sure,
because tools to hard-wrap are almost trivial,
whereas removing hard-wrapping is met with ambiguity
as to whether line breaks are intentional or not.
This issue was actually the main reason why, for some years nearly 2
decades ago, I preferred HTML email over plaintext email.
The default settings for plaintext email generally caused me trouble,
whereas HTML worked quite nicely until I started using LUG mailing lists,
and being told-off for all these netiquette details that I was gettng wrong.
I think it's only fair to grumble about HTML email if plaintext is given the
freedom to be used to its full potential -- not limited by hard-wrapping.
In other words, I'm suggesting that to promote plaintext over HTML email,
or even to avoid demoting it further, let's let the reader choose their soft
-wrapping line length, & stop asking people to hard-wrap upon compose/send.
I certainly prefer soft-wrapped plaintext email over HTML email,
but between hard-wrapped email and HTML email, I'm not so sure!
HTML email does handle reflow, and even reflow of quotations very gracefully
because it does this softly, as part of its rendering. HTML email does make
it easy to extract the plaintext in the non-hard-wrapped form that I prefer.
But this advantage of HTML only exists bcos plaintext is being hard-wrapped!
I wouldn't go as far as saying that this is the only thing that puts
people off plaintext, but I think it is a big one. I think a lot of people
who are not technically-literate, perhaps are adverse to plaintext because
of their only exposure of it these days is through junk mail.
That is an ignorance that is unfair, but unfair doesn't mean it's not the
case, & I think it is the case for some people.
I remember when I first startd using email about 22 years ago on Windows XP,
I didn't like plaintext emails because of the serif font. I later realised
that plaintext emails do not specify a font,& that I get to choose the font,
the serif font just being the default on that system. A few years later,
I further realised that plaintext is often assumed to b viewed in monospace.
On the one hand, systems that view plaintext in Times New Roman by
default are a bad idea and unhelpful to beginners, but equally systems that
impose hard-wrapping, a one-size-fits-all, on everyone else are not helpful
either. I observe that while HTML allows the reader to choose the width,
but specifies the font (and loads of other stuff); hard-wrapped plaintext
allows the reader to choose the font, but enforced the width -- but in a way
that is not trivial to override. It's easy to override fonts specified via
HTML, whereas it's often ambiguous to unpick a hard-wrapping.
There's nothing much that HTML has that I can't do in plaintxt if allowd
to, so this is why, overall, I do prefer plaintext -- but really do wish
that the wrapping is to b done by the reader & never by the composer/sender,
except for semigraphics.
> > For me, readability is about not breaking sentences at arbitrary
> > places. :-(
>
> I can understand that. But breaking sentences at arbitrary places is
> not what I'm talking about; doing that would also lead to (a different
> flavour of) unreadability. The traditional thing is to break somewhere
> shortly before 80 characters - not arbitrary, but chosen to fit
> traditional terminal sizes and, more recently, default window sizes.
I would actually argue that the tradition was chosen for the typewriter.
And that early teletypes simply propagated this earlier tradition of width.
My 1980s typewriter has a width of exactly 80,also propag8ing this standard.
Its bell rings upon striking the 72nd position, with 8 characters remaining.
While this choice of tradition makes such sense for mechanics so limitd,
I don't see the point of hard-wrapping on the more sophisticated machines
that we're using, except for semigraphics such as ASCII art or tables.
Note also that, as well as making it more difficult for the reader to
choose the width of their wrapping, hard-wrapping --
at places arbitrary relative to the sentence structure --
also complicates searching back using phrases as search terms.
Soft-wrapping does not have this issue, as the wrapping is temporary,
whereas searches apply on the original text before being wrapped & rendered.
> > Screen real-estate too. My line length is a whopping 256 characters!
> > :-D
>
> I can get 320 characters width if I want it. I don't. I've tried it
> and find that finding the correct line to continue reading at after a
> line break is troublesome enough to break the flow of reading; 80
> columns is long enough to be reasonably space-efficient but short
> enough that I (and, I gather, most people) can visually jump from the
> end of each line to the beginning of the next with little-to-no
> trouble.
I make use of limit on my paragraph length,1024|1000, being 4 lines max.
It's easy to locate the start of the paragraph, & the start of its 2nd line.
Likewise, it's easy to locate the start of its last line & its 2nd-to-last.
With fewer, easier returns, I still find this more readable than 80 wide.
At 80 characters wide, paragraphs can be many physical lines long,
which I find hinders my ability to locate the start of the next phys line.
I have, however, thought of a solution to this -- serpentine text flow --
but I do not have the programming ability to implement this system-wide on
GNU+Linux. But I do plan to implement it in some boot-sector code that I
started writing a few years ago, an attempt at my own operating system. :-D
Also should b able to implement it in my code for driving a thermal printer.
The idea is to simply horizontally-mirror the graphical rendering of altern8
lines. I can read mirrored (& rotated) text almost as easily as normal txt,
and this would improve with practice. :-)
> It also is roughly the line length of normal typeset text, too. I just
> now picked up a handy book and counted characters; while it's not
> totally comparable, because it's set in a proportional font instead of
> a fixed-width font, the sample line I picked had about 70 characters.
I have also noticed that most modern books are 80 wide,or just short of.
I speculate that this standard may have arisen from typewritten manuscripts.
Whereas old hand-written books I think were often much denser, paper dearer.
> (I speculate that characters are not the whole story; angle subtended
> may be important too. At least with the font I use, the lines I
> generate subtend about the same angle for me as a typical book line.)
Yep.
> > This arises from using a 5x8px bitmap font on a 1280x800px display.
> > ;-)
>
> 6x13 and 1920x1080 in my case. But I don't usually use windows
> spanning the full width of the display.
I love to optimise screen real-estate,so my default is maximisd windows.
Tiling is useful when I want to compare things, but only for that duration.
When done comparing,I soon prefer to hit a key chord to return to maximised.
> (I've got a 5x8 font, but it's
> just hard enough for me to read that I find I prefer the 6x13 one.)
Is it called Fixed, from X11? This is the bitmap font series that I use.
> > Yes, reflow is what I'm after! I've heard there was that other way.
>
> Other? Other than what?
Other than not hard-wrapping in the first place.
> > Sadly,my plaintext-loving email client does not seem to support
> > RFC3676. :-(
>
> Surely it can be configured to add arbitrary user-specified headers?
> That should be enough to use 3676 format=flowed.
I can add arbitrary headers, and preset drafts with such.
I have a header preset to BCC myself so that I can quickly detect outage.
But even if I added a header,
how would that mean I could edit as long lines if my client doesn't convert?
> Or you could ignore the issue and write off anyone for whom reading
> long lines is difficult.
I'm not writing anyone off. People can choose their window width.
As you said yourself, floating terminal emulator windows default to 80 wide.
I use tiling window manager I3WM, mainly full-width,but often also 1/2, 1/3,
1/4, etc.. When tiling at 1/4 width, text hard-wrapped at 80 is extra crap:
the tiled width is 64|63 characters, so lines altern8 with hard & soft wrap.
> > At least I don't see how to enable it. For now, I'll reflow manually
> > for you. Like this!
>
> Thank you!
:-) And yet in return,
I notice that even though I manually limited my previous email to 76,
taking great care to give enough room for a prepended "> > ",
you are still managing to break my lines a word or 2 prematurely! :-P
It does also, however, reveal that you have this capability all along,
so really, I needn't put the effort in at my end. :-P
But nonetheless, I will for now for you, while we discuss this. :-)
> > Even though I know email can support line lengths of upto 1024B.
>
> Yes and no. What "email" can support depends on what layer you're
> talking about. For SMTP, RFC 5321 says
>
> 4.5.3.1.6. Text Line
>
> The maximum total length of a text line including the <CRLF> is 1000
> octets (not counting the leading dot duplicated for transparency).
Oh right, I didn't realise that variation at different layers!
I'm mor than happy 2 reign-in my max line/paragraph length from 1KiB to 1kB!
Only 24 octets less from my paragraph limit is a tolerable change. :-)
> This number may be increased by the use of SMTP Service Extensions.
>
> But (a) as that says, the limit may be increased by certain extensions
> and (b) arbitrary-length lines may be transferred by encoding them
> suitably (but if you're using MIME, which you normally will be if
> you're encoding mail bodies, see the MIME specs; there may be line
> length limits on text portions even when encoded - I can't recall
> offhand what, if anything, the MIME specs say about that).
Claws Mail does not let me set higher than 1024. I did try,
but when I couldn't, I was okay with it, because usually paragraphs longer
than 1024 octets (or even 1000 octets) could do with being split anyway,
for readability. So I don't mind this limit at all.
> > I limit my paragraph length to just short of this,allowing 4 some
> > quotation. There's widespread support for rewrapping this, so what's
> > the problem? :-/
>
> The problem is that not everybody wants to have to tell their UA to
> override the sender's lack of "please reflow" marking. (Email is used
> for more than just running text, including various things for which
> reflowing constitutes horrible mangling; always reflowing is a Bad Idea
> for general-purpose use.)
This is why I prefer the way I normally do it, which is to not hard-wrap to
80 (or 76), but then if I want to include a little monospace semigraphic, like
this,...
___ ___ ⋅┃ a │ b ┃
/ _ \ / _ \ ━╋━━━┿━━━┫
( (_) ) | // | a┃ a²│ ab┃
> _ < | ~ _ | ...or even... ─╂───┼───┨
( (_) ) | // | b┃ ab│ b²┃
\___/ \___/ ━┻━━━┷━━━┛
(ASCII-art) (Unicode table)
... it still works! ;-)
This is not a one-size-fits-all approach for general text, only assuming a
width of 80 or less for the semigraphics.
> >> For the archiving, the simplest thing that comes to mind is to set
> >> yourself up with a local proxy [...]
> > It has crossed my mind but I don't know how to, or which proxy is
> > best.
>
> I don't either. I don't use the Web enough to have had occasion to set
> up a proxy, nor have I had occasion to want a proxy that does that.
Okay, well it's probably more trouble than it's worth.
Even if I put the time in and suss this out, it's hard for others to follow.
A script is much easier to share.
What I will probably do is to prototype it with Uzbl and go from there.
Orchestrated by my script running in a terminal, and at the touch of a key,
I'll always be able to open the archived hypertext with either Lynx or W3M.
> >> For breadth-first browsing (the queue-of-URLs thing),
> > Oh cool, you've identified this exactly the same way that I have! :-D
>
> :-)
>
> > That Breadth-First Search can cope with infinite trees, & is
> > queue-based.
>
> Well, _can be_ queue-based. I've done breadth-first search often
> enough in ways that do not constrain visit order within a depth, but do
> ensure that each depth is finished before starting on the next.
Oh yes, true. :-) I guess depth-first can deviate from stack-based too.
I would even be inclined to be slightly laxxer than this.
What I was thinking of is a queue with oldest-by-default,
but then allow skipping forward. Especially if by a TUI menu.
I'm exploring a way of using Less as this TUI menu.
Other candidates are MC, W3M,or Lynx -- each with their own set of issues.
If GUI is permitted, then it's dead easy: Dmenu or Rofi! :-D
> > Don't get me wrong - I love stacks too!
>
> Sure. Use the data structure appropriate for the task.
:-)
> My wrapper - tablynx, I call it - runs lynx. If I have a link I want
> to look at later, I use = to display the link-to, copy it, type ^P (^Z
> for most people, but for historical reasons I use ^P) to suspend lynx,
> tell tablynx to record the URL, paste, and resume the lynx.
This is very much my level; I've implementd many very similar scripts.
I tend to use XClip to automate the copy and/or the paste if possible. :-)
I didn't think of suspending back to my wrapper script -- I'll try it. :-)
> As I said, rather more work than would be ideal, but workable for
> low-volume workflows.
It's still a partial automation that is better than completely manual.
I therefore appreciate the merit of using suboptimal workflows like this.
> Could be improved by hacking on lynx to add both
> integration with tablynx and a new keystroke command.
Uzbl really is the ideal in this case with its follow.sh hook script.
If only Lynx or W3M had hooks like Uzbl. Here's a list of them:-
$ printf %s\\n /usr/share/uzbl/examples/data/scripts{,/util}/*
/usr/share/uzbl/examples/data/scripts/auth.py
/usr/share/uzbl/examples/data/scripts/auth.pyc
/usr/share/uzbl/examples/data/scripts/download.sh
/usr/share/uzbl/examples/data/scripts/follow.js
/usr/share/uzbl/examples/data/scripts/follow.sh
/usr/share/uzbl/examples/data/scripts/formfiller.js
/usr/share/uzbl/examples/data/scripts/formfiller.sh
/usr/share/uzbl/examples/data/scripts/go_input.js
/usr/share/uzbl/examples/data/scripts/go_input.sh
/usr/share/uzbl/examples/data/scripts/history.sh
/usr/share/uzbl/examples/data/scripts/insert_bookmark.sh
/usr/share/uzbl/examples/data/scripts/insert_temp.sh
/usr/share/uzbl/examples/data/scripts/instance-select-wmii.sh
/usr/share/uzbl/examples/data/scripts/load_cookies.sh
/usr/share/uzbl/examples/data/scripts/load_url_from_bookmarks.sh
/usr/share/uzbl/examples/data/scripts/load_url_from_history.sh
/usr/share/uzbl/examples/data/scripts/load_url_from_temps.sh
/usr/share/uzbl/examples/data/scripts/per-site-settings.py
/usr/share/uzbl/examples/data/scripts/per-site-settings.pyc
/usr/share/uzbl/examples/data/scripts/pipermail.js
/usr/share/uzbl/examples/data/scripts/scheme.py
/usr/share/uzbl/examples/data/scripts/scheme.pyc
/usr/share/uzbl/examples/data/scripts/session.sh
/usr/share/uzbl/examples/data/scripts/util
/usr/share/uzbl/examples/data/scripts/uzblcat
/usr/share/uzbl/examples/data/scripts/util/dmenu.sh
/usr/share/uzbl/examples/data/scripts/util/editor.sh
/usr/share/uzbl/examples/data/scripts/util/uzbl-dir.sh
/usr/share/uzbl/examples/data/scripts/util/uzbl-window.sh
Feast your eyes on that! :-D If only Lynx or W3M had hooks like these!
I already use load_url_from_history.sh directly to pick without visiting.
I plan to heavily modify download.sh & follow.sh to implement these ideas.
I'd like to be able to do the same in Lynx or W3M, & integrate history.sh .
> > It is the hackery on Lynx where I'd be wholely out of my depth. :-/
> > If you could do that part it would greatly enable my script-based
> > hackery.
>
> Well, I probably could. But I use a rather old lynx (2.8rel.2) and use
> the Web so seldom I see little-to-no reason to either switch or put
> effort into adding things to it.
Not even a simple hook that would allow me to do the rest?
> >> about the time I might have, the Web collectively decided to insist
> >> everyone speak HTTPS, which I refuse to put up with, so I don't use
> >> the Web much any longer.
> > I'm in 2 minds about HTTPS. :-/ On one hand I see the benefits.
>
> Oh, I see nothing wrong with supporting HTTPS if you want to sink the
> resources into it. What bothers me is refusing to serve content over
> HTTP. These days, most webservers seem to refuse to serve anything
> over HTTP except redirects to HTTPS.
Unfortunately, mandatory redirects to HTTPS are the recommendation.
I can see that this is as annoying for you as hard-wrapping is to me. :-P
> > I also know how to configure a website that passes 100% at
> > Internet.NL .
>
> Dunno what that is; http://www.internet.nl/ hands me a redirect to
> HTTPS, and these days I doubt there's anything anywhere _except_ the
> Web describing what it does.
Okay, can I introduce you to FrogFind? I think you'll really like it!:-
http://frogfind.com/
Not only does it support HTTP, it does not even really support HTTPS.
It exists entirely for vintage computers, so is bound to stay that way.
It opens results in its own viewer proxy, such that most results also work.
Its backend is DuckDuckGo, which is what I used to use before FrogFind.
I just hope that FrogFind stays around, at least until my local archive's
pool of URLs reduces my dependence on remote search engines enough to cope
with a complete absence of tolerable search engines online, as we so often
teeter on the edge of.
For example, you can search for "Internet.NL" using...
http://frogfind.com/?q=Internet.NL
...and its very 1st hit is /labelled/ as...
"https://internet.nl/";
...but actually following it (its href), it is actually proxied as:-
http://frogfind.com/read.php?a=https://internet.nl/ .
So I think that you should be able to read that now. :-)
I was not happy to see that to gain 100% in this test,
one has to force a redirect to HTTPS. Although I did achieve 100% for a
few little websites, I was very keen to ensure that I supported DNSSEC &
DANE /before/ supporting HTTPS, and thus also before making it mandatory.
This is because, at no point whatsoever did I want to make my sites mandate
the use of certificate authorities, which I do not agree with in principle.
The way that I have implemented my use of SSL is somewhat resistant to
the obsolescence introduced by the certificate authority chains - as long as
browsers instead support DNSSEC & DANE, which is now widespread. :-)
The good thing about DNSSEC & DANE is that it adds no additional
centralisation than the domain name system that the Web uses already is.
In other words,it uses th existing infrastructure of the Web,but secures it.
CAs don't get a look-in, so they can't meddle with things or cause failures.
Now that you know this, does it enable you to tolerate HTTPS?
I suspect not, but would like to know why. Is it bcause u can't use telnet?
You may like to know that OpenSSH s_client is th equivalent for SSL|TLS. :-)
Is it because your software is out-of-date? We've had SSL for decades now,
surely you are running software new enough to handle it.
Is it purely a moral stance? Is your boycott of the Web achieving anything?
Is it something else entirely? Is it some combination of these?
> Anti-HTML-email has nothing to do with browsers; that's kind of the
> point of it: plain email shouldn't need an HTML renderer. [...]
I just mentioned a couple of other campaigns of similar nature.
Indeed it was actually JSfree.org that introduced me to FrogFind. :-)
I submitted a few things to it -- including W3M, Lynx,& Links, actually! ;-)
> Indeed, my SMTP server is supposed to reject HTML-only mail, and it
> mostly does ("mostly" because I think I have seen reason to think
> there's a bug or two).
D'you know, for that degree of configuration effort,
it's easy enough to just exact the text from it.
> > Relatedly,I tried 2 start th counterpart 2 HTML email Wikipedia
> > article. But sadly my page on plaintext email got shot-down and
> > disposed-of. :-(
>
> I am not going to try to defend Wikipedia on that (or any other) point.
> I use Wikipedia only rarely and (since they have drunk the "force HTTPS
> on everyone" koolaid) only from work machines.
Maybe FrogFind can help you here too. :-)
Kind regards,
James.
--
Wealth doesn't bring happiness, but poverty brings sadness.
Sent from Debian with Claws Mail, using email subaddressing as an AI-free
alternative to error-prone heuristical spam filtering.
pgpzxfAsZ_gFC.pgp
Description: OpenPGP digital signature
