Re: silly feature re: collapsed threads

[Peter Bloomfield <PeterBloomfield MindSpring com>]

On 2001.10.25 08:44 Reychman Felix wrote:
...
> Apparently. It may not have reached the list as a result of my 
> incompetence or some technical flaw.
> The way I see it, one of the ideas of threads is to have some kind of 
> tree-structure based on what is replies to what. I would like to be 
> able to delete a whole thread, by deleting the top element when the 
> thread is collapsed. For exaple, people on this list often discuss 
> technical detail of which I'm not all that interested, and a debate 
> might very well go on for 20 messages. I would like to be able to 
> note that the top message concerns something I'm not interested in, 
> and then simply delete it, along with all it's replies.
> I would not find it unreasonable that someone thought this 
> non-intuitive and didn't want to risk deleting a lot of mail by 
> accident, so perhaps this should not be the default action of the 
> "d"-key, but I would like the function.
> As for now, I don't find it very hard work to simply expand the 
> thread, select all messages in it, and the delete, so don't put this 
> issue on high priority for my sake.
> 
> Thankyou!

On 2001.10.25 08:33 Jules Bean wrote:
> On Thu, Oct 25, 2001 at 08:15:16AM -0400, Peter Bloomfield wrote:
>> On 2001.10.25 07:19 Reychman Felix wrote:
>> ...
>>> I would not like "open next" to open the next message in a 
>>> collapsed thread. That's why I collaps it. I don't want to work 
>>> with it.
>>> In an expanded thread, I would expect it to go to the next message 
>>> withing the thread, but that's different.
>> 
>> Fair enough.
> 
> Just to keep the argument warm:
> 
> I don't agree there.  I wouldn't expect any command[*] to behave
> differently depending on whether the thread was expanded or not. The
> way I see it, the underlying structure is the same.  Expanding/
> collapsing threads is something I do with the mouse as I browse; but
> commands which move to next-unread or similar should always select the
> same message, irrespective of whether I clicked a few 'open' or
> 'close' boxes.
> 
> [*] expect possibly the simple navigation cursor keys, which are
> 'like' mouse movement
> 
> Jules

I like warm arguments--they keep minds open!

Some thread-related commands would, as Felix suggests, be convenient, 
but as Jules points out, implementing them by changing the action of 
message-related commands based on the expanded/collapsed nature of the 
thread is probably a bad idea.  I'm not sure where this leaves us.

Do we at least agree that deleting/moving the head of a collapsed 
thread should leave the focus on the newly-viewable head of the 
remainder of it?

Peter