pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-users] questions about a couple of features


From: Duncan
Subject: Re: [Pan-users] questions about a couple of features
Date: Sun, 22 Dec 2002 02:39:13 -0700
User-agent: KMail/1.5

On Sat 21 Dec 2002 22:26, Kevin posted as excerpted below:
> I was just wondering if there was still an issue floating around about the
> fact that if you delete articles in one group, it deletes them from all
> other subscribed groups as well.  I thought I saw some discussion about
> this a while back.  Is this a desirable feature for some to cut down on
> volume as you traverse subscribed groups?  What about those that don't like
> this feature? Can it be made an option as to how to handle it?

No matter how many groups a message was x-posted to, it is only a single 
message, with a single message-id, and a single copy of the message in the 
cache.  If you delete that message, it deletes the single copy in the cache, 
therefore deletes it from all groups.  If the message is marked read, again, 
it's marked read in all groups, because it's only one message, showing up in 
multiple groups.

Of course, multi-posted (as compared to x-posted) messages are actually 
entirely separate messages, with different message-ids, even if the content 
is exactly the same save for a couple headers (the msg-id and the newsgroups 
line, of course).  These do tend to get real irritating seeing the same 
stupid message in a bunch of different groups, but it's actually different 
messages, with the same content, so you have to mark each one read and/or 
delete each one individually.

I suppose it might be possible to arrange things in the news reader to delete 
only the reference to the message, in the specific group index, and leave the 
message itself actually in the cache, with a reference count of how many 
subscribed groups it was x-posted to, so the cache copy could be deleted when 
the message was deleted from the last group.  However, besides not being what 
SOME folks want, this sort of approach adds needless complexity, which means 
that many MORE places for things to potentially go wrong, making the software 
as a whole less reliable and harder to maintain.  I'm not one of the 
developers, yet, but if it WERE my project here, I'd say no unless there was 
an overwhelming demand for the feature/option, because I wouldn't consider it 
worth the maintenance work for the little added usability.  Again, I'm not 
them, but if they think similarly, I'd be surprised to see this feature 
except possibly targeted at "blue-sky", meaning when all the other big 
features are implimented and the software is essentially bug-free, so there's 
little left to add but what could be considered bloat.

> Secondly, is the "delete thread" option ever coming back?  :)

I don't know on that, but it's simple enough to make it a two-keystroke 
sequence, if desired.  There's already the delete key for delete, and it's 
simple enough to set a custom hotkey for Edit, Add thread to selection.  
However, here, I'm more apt to click/shift-click the range, then hit M or 
delete as desired.  (I'd sure like to be able to extend the selection with 
the keyboard, but that won't work, currently, due to a workaround they are 
having to do, because the control the really SHOULD be using is simply not 
fast enough in gtk2 yet to deal with displaying tens of thousands of 
overviews at times, so they have to use a second choice that's faster, and 
deal with it's limitations.  This according to posts in the devel group, 
which I also subscribe to.)

-- 
Duncan
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]