Re: [Pan-users] Feature request: multiple selections in task list

[Duncan]

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