vm team mailing list archive

["Tim Cross" <theophilusx@xxxxxxxxx>]

OK, my suggestion then would be to enable the thread operations to be easily
toggled on/off rather than setting via setting a variable. I think the benefits
of having this functionality would be more useful if you can quickly
enable/disable it.

Tim

Uday S Reddy writes:
 > Tim Cross writes:
 > 
 > > As noted by Uday, replying in the root message sends the reply to
 > > all recipients in the thread. This may have some undesirable
 > > consequences and may not be as intuitive as we would like. In
 > > addition to the issues mentioned by Uday, we also need to think
 > > about some of the corner cases. For example, is there any chance
 > > that a message could be incorrectly included in the thread -
 > > resulting in someone other than the user expecting getting a copy?
 > > Could there be unforseen problems with someone included in the
 > > thread via a Bcc then having their address exposed/revealed to
 > > others? I'm just shooting in the dark here - we would need to look
 > > at this more closely to verify exactly the possible combinations
 > > that may be involved. At the very least, I think the user needs to
 > > be vary aware of all recipients and given the opportunity to edit
 > > the list before it is sent.
 > 
 > Hi Tim, the user does get to see the list of recipients and has an
 > opportunity to edit them.  I don't see that as a problem.  If a
 > message gets incorrectly included in a thread, that is clearly a bug,
 > and we should fix such things.  Bcc is not an issue either.  Bcc
 > doesn't get included in the headers of messages received in the
 > thread.
 > 
 > The real question is whether "thread operations" are a good idea and,
 > if so, what operations are they appropriate for.  It is clear that
 > they are inappropriate for reply.  What else?
 > 
 > > I'm also not sure of the difference between operaitons when this
 > > feature is turned on and when it isn't. For example, delete and
 > > killing thread. To some extent, when this feature is enabled, delete
 > > works like kill thread. Maybe we need to consider what commands are
 > > included when operate on threads is enabled and which should be
 > > excluded.
 > 
 > There is no difference between `delete' used as a thread operation and
 > kill-thread-subtree.  At the moment thread operations only apply to
 > the overall root of a thread, but not to subroots.  On the other hand,
 > kill-thread-subtree does apply to subroots as well.  But, eventually,
 > when thread expand/collapse is beefed up for subthreads as well, this
 > difference will vanish.
 > 
 > > However, most of this I see as refinement of the basic
 > > concept. Possibly more of an issue is how we interface this
 > > functionality. Having this functionality either on or off doesn't
 > > quite work. Sometimes, I would like this feature when managing
 > > specific threads, but sometimes I don't. I wonder if another
 > > alternative way of enabling this functionality would be better. For
 > > example, maybe modifying commands so that if you provide a prefix
 > > argument and you have threading enabled, the command works on all
 > > messages in the thread, otherwise, it just works on the current
 > > message as normal.
 > 
 > Prefix arguments are already used up for numeric counts.  So, that
 > route is not available.
 > 
 > Perhaps, we could add an option of 'warn for
 > vm-enable-thread-operations which asks for a confirmation every time a
 > thread-opereation is invoked.  That will allow people to learn how it
 > works before they become proficient with it.
 > 
 > Cheers,
 > Uday

-- 
Tim Cross
tcross@xxxxxxxxxxxxxxx

There are two types of people in IT - those who do not manage what they 
understand and those who do not understand what they manage.