vm team mailing list archive

[Uday S Reddy <u.s.reddy@xxxxxxxxxxxxx>]

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