Re: [Pan-users] message formatting

[Duncan]

Hendrik Boom posted on Sun, 30 Oct 2011 17:25:41 +0000 as excerpted:

> On Sat, 29 Oct 2011 09:32:30 +0000, Duncan wrote:
> 
>> Hendrik Boom posted on Fri, 28 Oct 2011 20:01:21 +0000 as excerpted:
>> 
>>> [A]fter I post it and it gets back to me, the formatting is
>>> completely screwed up, with newlines appearing at random places

>> pan posts as it displays.
>> 
>> However, on the receiving side, pan has two wrap modes[.] What you
>> want is unwrapped [mode,] view, body pane, wrap article body.  By
>> default, the "w" hotkey

> 'w' worked; it's a lot better.  There's still an issue with tab spacing,
> but I should know better than to post tabs anyway.  Who knows what the
> recipient's newsreader will do with them!
> 
> It there a way of seeing tabs in messages being posted so I can choose
> to do something about them?

Not in pan itself.  You can use pan's external editor feature or paste in 
from a pre-edited external source.

While I do normally use pan's internal post composition window, it has 
always seemed to me that the author (presumably Charles, back then, tho 
he might have inherited the philosophy and simply retained it thru the 
rewrite) probably deliberately kept it quite simple and bare-bones, 
enough to do the job, but using the external editor feature to let users 
pick the more advanced editor of their choice if they wanted/needed 
something more advanced.  This has at least three advantages.

First, it fits the traditional Unix philosophy of tools picking one thing 
to do and doing it well, with good interoperability so the user can mix 
and match tools for the best results with the least effort based on 
personal preferences and what they're familiar with.  PAN originally 
stood for Pimp-Ass Newsreader -- it wasn't PAE, Pimp-Ass Editor, but if 
the user wanted a better editor, the external editing (and simple copy/
paste) functionality provided the necessary interoperability to support 
it.

Second, Charles had a definite "trim the fat" programming philosophy that 
fit well with #1.  At least twice in the years I used pan while he was 
primary developer, he trimmed a bunch of previous arguably unnecessary 
features and let user protests and requests guide what features returned, 
thus keeping pan comparatively "lean and mean", in comparison to the 
bloat it would have otherwise developed, features that few users actually 
used.  This helped keep pan far simpler both to use (and support, a fact 
I appreciate as I've been active on this list helping with just that for 
nearing a decade, now) and to maintain.  Less "fat" meant less complex 
bugs potentially interacting with that "fat".

Third, pan's a GNOME family app (requiring gnome back in the gtk/gnome-1 
days, and pan's official sources repo and bug database remain hosted at 
gnome.org, which also provides l10n/localization/translation services for 
those who prefer a UI in other than English, tho since gtk2, pan has only 
required gtk2, not a full gnome install), and gnome has a rather power-
user unfriendly HIG that disdains of choice and "advanced user" 
functionality while favoring "our users are idiots that get confused by 
choice and power-user type functionality, and any objection they may have 
to /our/ choices only emphasizes that they're idiots."  Basically, they 
do what Charles did, removing all the "fat" every few years, but by 
policy, they choose to blame the "user too dumb to see that our choice is 
best" instead of, at least initially, putting the functionality that the 
users actually want and use back in place, as Charles generally did.

Fortunately, pan's not a very good gnome app in that regard, since 
Charles /did/ put the functionality back that users actually used and 
thus requested.  That's why it has all those "power user" individual 
color prefs (gnome's solution is themes, exposing individual color prefs 
only via direct file-or-registry edit), "confusing" scoring, hotkeys that 
can actually be reassigned, etc.  Arguably, no "good" gnome app would 
have any of that.  But certainly, that pressure had its effect in other 
ways, the primary reason, I'd argue, for a number of pan's choices only 
being available to those willing to directly edit its text-based config 
files.

Together, I'd argue that these three (related but different) factors 
combined with others to help make pan what it is today.  They go quite 
some way toward explaining the absence of a number of features that I'd 
suggest many users would consider essential to a true "pimp-ass 
newsreader".  Given how long some of them (like binary posting, now in 
HMueller's leading-edge/experimental development tree) were planned, but 
never implemented until Charles had turned over development to someone 
else, a good argument can be made that they held back pan's development 
over the years, as well.  (Again using the binary posting example, a non-
functional UI for at least single-part binary posting actually appeared 
years ago in a beta, but it was quickly yanked in the next beta, as 
Charles apparently decided the single-part restriction simply wasn't 
appropriate to an app calling itself the pimp-ass newsreader, but at the 
same time, he was unsatisfied with the complexity of any UI he could 
figure out for multi-part binary posting, apparently believing it 
inappropriate for pan as well.)

-- 
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