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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users