Re: [Pan-users] Pan glues lines together when 'wrap article body' is enabled

[Duncan]

Mateusz Viste posted on Wed, 01 Nov 2017 08:54:37 +0000 as excerpted:

> Hello, there is this "wrap article body" button in Pan, that I use a lot
> (I keep it on by default in fact). Problem is, that it often misbehaves
> when there are some lines that are already short, one after another. In
> such case Pan glues these lines together. Example:
> 
>   this is line one; this is line two; this is line three;
>   this is line four;
> 
> The above lines are likely to get glued together by Pan when "wrap
> article body" is enabled...
> 
> Am I the only one battling with this?

I believe that's a feature, not a bug. =:^)

Agreed it can sometimes be irritating, but that's why there's a hotkey to 
quickly toggle it. =:^)

The problem it's attempting to solve is rooted in the default behavior of 
many older news and/or mail clients, especially when quoting lines just 
longer than their line-wrap trigger, as commonly happened when the 
quoting got more than a couple levels deep, or when someone decided they 
were going to be the oddball posting with lines wrapped at say 100 
characters, instead of the standard 80 characters max (including 
terminating two-character CRLF sequence), originally wrapped at 72-75 
characters to allow for a few levels of quote marks without exceeding the 
allowed 78 characters of actual content.

So suppose you did have 82-100 character lines for whatever reason and 
needed to wrap them to the usual 72-78 characters.  That often lead to 
the infamous "jaggies", full length lines of the standard 72-78 
characters, each one followed by a much shorter line of 5-20 characters, 
with line length regularly alternating for the entire message body, with 
the exception of blank-line paragraph breaks, of course.

Then of course there's the folks that insisted on taking advantage of the 
full 1000 character (998 plus terminating CRLF sequence) MUST-break limit 
of the SMTP RFCs, and the ones at the opposite end, who composed on half-
width (40 char) or even quarter-width (20-char) displays and insisted on 
wrapping at that.

Plus the folks (developers and the users who used their products) that 
invented soft-wrap, but then let their soft-wrapped lines continue well 
past even the 1000 character maximum limit, because the raw format was 
hard-wrapped to the recommended 80-char-max, and the devs and users 
thought that meant they could continue their soft-wrapped lines for 
thousands of characters without a break!

Pan's solution to all this was togglable line wrap, both for display, and 
separately, for posting.  

* In wrap mode it combines lines until it finds a blank line paragraph 
break, and reflows them with its own breaks inserted at the standard 
72-80 character line width.

* In unwrapped mode it uses the hard (tho not necessarily entirely raw) 
line breaks as originally posted.

* For most posts, one or the other will work reasonably well, and 
actually in /many/ groups either mode will work for most posts, and 
you'll only occasionally need to hit the hotkey or toolbar button to 
toggle it to the other mode, when you're either in wrapping mode and hit 
a hard-wrapped table like you posted and you need to toggle it to get the 
table, or in unwrapped mode and hit someone posting lines hundreds of 
characters long without any hard line breaks, and you need to toggle it 
to avoid horizontal scrolling back and forth to read the long lines, 
often each a paragraph of content, one at a time.

* Occasionally you'll hit the post that has *BOTH* of these qualities, 
lines hundreds of characters line that need rewrapped, *AND* tabular 
content that needs hard-wrapped.  Still, for relatively short posts this 
isn't /that/ bad, but because pan rehomes (starts at the top again) each 
time the wrapping is toggled, long posts with a toggle needed several 
pages into the post can be quite frustrating indeed!

But it's worth noting that these posts, while likely RFC compliant with 
the MUSTs, break the SHOULDs, and thus fail GNKSA (Good Net-Keeping Seal 
of Approval) as well, thus providing a rather effective demonstration of 
why Charles, pan's long-time lead dev, put so much work into making pan 
100% GNKSA compliant, so pan users weren't the ones being impolite, which 
in turn attracted users favoring that sort of policy as well, such that 
even now long after Charles moved on, when a newer dev wanted to bend the 
GNKSA connection rules (which most agree are indeed outdated), after a 
discussion here, the user consensus was that it wasn't worth the risk of 
a slippery GNKSA slope, and the change in conflict with GNKSA was 
ultimately reverted.

Meanwhile, by now I suspect that most long time pan users, including me, 
have gotten used to this quirk of pan, and are resigned to toggling line-
wrap every so often.  After all it's trivial once you know the hotkey (or 
configure your own if it's easier to remember, but "w" for "wrap" isn't 
/that/ difficult), and you normally only need to toggle once in awhile, 
and it's only a long enough post to make that really frustrating a 
relative minority of /those/ times, so I guess most learn to live with it 
after awhile.

Tho I can certainly add that were I a coder, I'm sure the frustration of 
needing a toggle or three on the occasional longer post would have likely 
had me trying to come up with something better.  But the fact that it 
hasn't happened yet probably means it's not all that simple, either, so...

Still, I use the similarly gtk-based claws-mail for mail and feeds, and 
it seems to have wrapping code that works a bit better than pan's, such 
that I'm not even sure if it /has/ a wrap-toggle functionality, because I 
don't recall ever /needing/ it.  And I've always thought if I were I 
coder, I could certainly look there for some hints at a hopefully better 
algorithm.  They're both free software, after all, tho claws-mail is 
GPLv3, so were someone to do that they'd need to go find an earlier, GPLv2 
or compatible version, since pan is GPLv2 and that's unlikely to change 
because it would require chasing down a lot of people to get their 
permission to change it.  Even then I'm sure the code would need adapted, 
but surely the algorithm could be used even if it had to be recoded.

All that said, as I said up top, it's a feature, if a slightly 
frustrating one. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman