[Top][All Lists]
[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