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