Steven D'Aprano posted on Tue, 30 Apr 2013 15:32:47 +1000 as excerpted: > On Tue, Apr 30, 2013 at 05:07:45AM +0000, Duncan wrote: >> Jay posted on Tue, 30 Apr 2013 09:25:24 +0800 as excerpted: >> >> > I know this won't make it into version 1.0 at this late date >> >> FWIW, 1.0 has been at the top of the changelog for years, thru various >> lead developers and in fact a full rewrite from C into C++, so when/if >> 1.0 happens is more or less arbitrary, but from my perspective (as a >> user and list participant since the gnome-1-pan era, since 2002 so over >> a decade now), pan is now 1.0-feature-complete, having gotten in the >> last year or two both a replacement for the old-pan rules in the form >> of the auto-* actions (preferences, actions tab), and the last couple >> long- missing features to fill things out, binary posting and >> secure-connection ssl/tls support (along with several other less major >> features). So from my perspective, it's ready for a 1.0 as soon as the >> current devs deem it stable enough. =:^) > > Alas, I don't believe Pan is sufficiently mature for a 1.0 release in > 2013. Or even 2000 for that matter. > > - No Auto-save: messages being worked on are not automatically saved, so > if something kills Pan while you are editing a message, that message is > gone forever;
Version? The version (git-pan) I've been using has had that for awhile, now, altho after awhile running a git-version, you lose track of what's actually in current release, so I'm not sure whether it's in a release or not. New-pan (the C++ rewrite, starting with 0.90, so it's actually not so new any more) has long had a drafts folder feature, where it was possible to save an in-composition message, then open it again in ordered to finish editing it. However, that was a manual feature that naturally had "never" been used before a crash, making things rather frustrating, as you rightly mention. However, for some time now pan has had an auto-save timer that saves a copy to the autosave file every N minutes, with N being a settable preference appearing in pan preferences, on the misc. tab. There does remain a usability caveat -- since the same filename is reused, opening two compose windows at once will (I think) have them both saving to the same file... not ideal. Also, recovery is a bit of a hassle, since the only way to open the draft is to open a new compose window and use the open draft function from there, and opening the new compose window of course risks overwriting the autosave (I've never actually figured out whether you have those N minutes to recover the old one before it's overwritten or whether it saves immediately, as I've never wanted to actually risk the overwrite), so what one has to do to avoid the overwrite is manually open the drafts filesystem dir and copy/ move/rename the auto-save file to some other name, so it won't be overwritten. THEN one can open the compose window, hit open draft, find the file you save to, and go from there. But the autosave feature IS available and DOES work -- I've used it on a couple occasions. (I can also mention that in git-pan there's a drafts folder implemented as a "pseudo-newsgroup", that should eventually allow opening any message there as a draft, thus bypassing the manual filesystem rename hassle of the current autosave solution, but that seems to be a WIP, work-in- progress, and doesn't actually work just yet. So finishing that before a version 1.0 would be nice, but there IS an existing autosave functionality, permitting message recovery altho with some recovery-time hassle, and I've actually used it myself a few times, so I know THAT works.) > - No Sent Items: messages that you send are not kept anywhere, unless > you manually save them as a draft before sending, so if you post a > message and it gets eaten by the receiving news server, it is gone > forever; That's in git-pan too, implemented along with drafts as a "pseudo- group". However, unlike drafts, the sent pseudo-group actually works. (Or at least it has for several months, now. Just checking it, it seems the last couple messages I posted appear, but unlike previous messages aren't marked as cached, and clicking on them doesn't display them, so either there's a fresh bug of only a few days at most, or there's a perhaps longer existing bug whereby pan doesn't actually see them as cached until a restart, I don't know which... But the feature is there and /has/ been working.) > - Lousy default file names: saving drafts apparently defaults to > whatever file name you last used, regardless of the subject line of the > message you are working on; Agreed on this one. I've found it mildly irritating that the current subject isn't used as a default, but I could always create my own name and was glad enough just to have the feature, so didn't complain too much about it. > - Ignoring 30 year old UI guidelines, leading to data-loss: when saving > drafts, Pan does not warn you when you are about to override an existing > file, so it is trivially easy to override existing drafts; It always showed the drafts directory, so one could look before saving, if desired. Sometimes I WANT to overwrite an existing draft file. (Meanwhile, when the new drafts pseudo-group functionality gets fully functional, this complaint may no longer apply. I guess we'll see...) > - Poor handling of HTML attachments: HTML attachments are displayed > inline as raw text, instead of handled gracefully (e.g. shown as an > attachment). That could be handled a bit better, yes. Having the HTML appear as an attachment would be perfect. Meanwhile, there's some work on an HTML handling feature of some sort as well, too. I'm a firm no HTML messages guy so I haven't paid /that/ much attention to it, but I /believe/ the idea is to optionally pass it to a browser to open, much as pan already handles URLs when you click on them. > These issues are the difference between a polished and professional > product, and something with sharp corners and splinters that will catch > you if you're not constantly on your guard. > > > Oh, and I must admit that these issues may be fixed in the latest > version of Pan. I may be a tad behind the times. But the default version > of Pan provided by current Debian (if not others) still shows all these > issues. Although I suppose that moving to a 1.0 release might encourage > the Linux distros to use that 1.0 release instead of older versions... I guess you /are/ a bit behind if that's what you're running. I'd guess you have the first version released by the new team (maybe 0.135?), with a few bugfixes but without any of the new features yet... if you're lucky! "Current" (stable) Debian is well known to be anything /but/ "current", more like YEARS outdated... in a community that moves at Internet time, so in human-years or say car-model years that's like DECADES outdated (a car from the 80's anyone, maybe even the 70's?). Debian testing isn't quite as bad but is still bad, and even unstable is often outdated, especially during a freeze, the current one of which I guess has been going on for many months now. I'm not a Debianite but I guess you have to be running experimental to get true upstream-current... and even that's often behind what's in the live-VCS (normally git these days, as it is with pan) version. -- 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
