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