Re: [Pan-users] Quirks with ignored authors or posts

[Duncan]

Heinrich Mueller posted on Tue, 19 Jul 2011 11:28:30 +0000 as excerpted:

> On Tue, 19 Jul 2011 05:40:01 +0000, Heinrich Mueller wrote:
> 
>> Working on it ;)
>> It's working, but not fully automatic yet.
>> I can delete and mark articles unread at will now.
>> Stay tuned.
> 
> Done, except for the "autosave-to-disk"-feature, which as of now just
> copies all bodies into $PAN_HOME/downloaded-attachments.
> Feel free to test it ;)
> It's a little hacked-together, but I think I'll improve it anyway - just
> for the time being here it is (on master)

Wow!  You have any idea how long /both/ the attachment posting and this 
feature have been on the to-do list?  (Rhetorical question.)

What you may or may /not/ know, as I don't believe I've had occasion to 
mention it recently and I never really updated it, and I don't know how 
long you had followed this list, was that despite the fact that I only 
know bash scripting, I had done what I could with the tools I knew how to 
use, to get pan attachments.

Years ago, with old-pan, it was known on the list that if one wanted to 
do post binaries with pan it was indeed possible.  One simply had to use 
a separate encoder utility to UUE or yEnc the binary, then open the 
encoded file in a text editor, select-all, and select/paste or copy/paste 
into pan's composer window as text.  It worked the same way as manual 
encoding had always worked, since the days it was first practiced with UUE 
and its predecessors.

Somebody then mentioned, in quite a different context, that it was 
possible to gpg-sign messages sent using pan by using the external editor 
feature, by setting the external editor command to a script that would 
take the previously composed content it was handed and return both it and 
the gpg signature.

While I understand signing, that wasn't something I was particularly 
interested in on its own, but it DID trigger an idea to do basically the 
same thing with a script that automated the whole multi-step process of 
selecting a file, running it thru the external encoder, and returning the 
results as the output from the "external editor".

I mentioned the idea a number of times over probably 18 months, hoping 
someone that knew python or the like would do it, as I wasn't really 
looking forward to trying to handle the UI in bash script.

When that didn't happen, I upped it a notch, writing an /extremely/ crude 
no-UI proof-of-concept that scanned for and interpretted the existence of 
magic strings in the pre-composed content handed to the external editor, 
as the path to the file you wanted to attach, etc.

I posted that as pan-attach and mentioned it several times over the next 
year to 18 months, still hoping someone would pick up my proof of concept 
and run with the idea, to no avail.

But by this time I had connected the previous two ideas with a third one, 
that of using xdialog/kdialog/gdialog (the last now called zenity, I 
believe) for the filepicker, etc.

I'm a kde user and had come across a kdialog intro article at some point, 
which I saved a link to, so kdialog became the UI for my next try, which 
I named pan-attach-kd.

*THIS* one actually had a number of users for awhile, and I still have a 
couple of mails with patches for improvements, if I had decided to 
integrate them.  Apparently, it took a GUI to get people interested 
enough to contribute.

But it worked well enough for me and I never was much of a binary poster 
anyway, tho it was nice to be able to attach the occasional screen shot 
or image, so I never did get around to integrating those patches and 
doing a followup release.

I really still expected that a gnome user would not like having to 
install kde just to run the script and would curse me out, at which point 
I'd invite them to port it to zenity or xdialog or whatever.  And I 
invited people to port it too, but nobody ever did, that I'm aware of, at 
least.  For all I know it ran or would have run with only minimal 
changes, basically switching the kdialog name to zenity/xdialog.  But 
apparently, kdialog was either enough of a barrier to keep those away 
that might have done the porting, or not a problem for those who already 
had it installed so could run my script as it was.

Meanwhile, new-pan was released.  Along with the loss of rules that was 
never replaced (until just now when you did it), new-pan used a different 
gtk widget as the compose window text-edit box.  Unfortunately this new 
widget could handle UTF-8 input just fine, but it could NOT handle the
8-bit ASCII that yEnc depends on, so it broke the yenc choice for my pan-
attach tools.  And base64 had never been supported since as part of MIME, 
it really needed more control, of mime-headers, etc, than pan made 
available to the external text editor function.  So with new-pan, only 
the UUE and identity encoding (basically appending text files in-line) 
choices worked.  I asked Charles about that, but either it wasn't 
possible to set the widget for that or he was unwilling to do so as it'd 
break UTF-8, etc, support and it was too narrow a use case to expose that 
as an option.  Plus I think Charles was still hoping to do binary posting 
support in pan itself at the time, but it never got implemented (until 
you came along).  So with new-pan, only UUE (and identity) encoding 
worked.

Actually, that's probably why I never was motivated to do another pan-
attach-kde release, too.  With yenc broken and only UUE for binary 
posting, it just wasn't worth it.  There's a good chance I'd have 
eventually done that update, had it still been possible to do yenc 
encoding using the script, in new-pan.

If anyone happens to be interested, both the extremely crude no-gui 
original pan-attach proof of concept (which I kept up as I already had it 
so might as well, and because it didn't have the kdialog dependency of 
pan-attach-kd) and the kdialog based pan-attach-kd, remain available on 
my (ISP-hosted) web space, such as it is.  (THe whole thing is dated and 
badly needs an update.  If anyone's interested in archiving those 
scripts, now might be a good time, as I expect they'll ultimately come 
down given that pan's now getting /proper/ posting attachment support.)

http://members.cox.net/pu61ic.1inux.dunc4n/

Anyway, as that should demonstrate, if I had been able to do either the C 
or C++ code for proper pan patches to add posting, etc, myself, I'd have 
certainly done so, even tho as I said I've never been much of a binary 
poster and I don't expect having the ability to do so in pan would have 
changed that much, because I believed and STILL believe that it's a 
necessary feature of an app having the stones to call itself "Pimp-Ass 
Newsreader!"

So I'm glad that /someone/ with the necessary skill has finally had it 
rise to a high enough priority to do it.

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