vm team mailing list archive

[Arik Mitschang <arik.mitschang@xxxxxxxxx>]

Hi All,

I just wanted to chime in on this slightly old thread. I have been using the
thread ops for a while now and definitely have come to the same conclusion
regarding replies. It is not only not very obvious or useful in replying, it can
also potentially cause harm when the user is just slightly inattentive to the
subject and quoted text.

For all other ops I can think of now, though, it is very useful for me
not to have
to think/do to much. Just for completeness the operations that come to mind
are labeling, saving, altering attributes, writing to a file. If I
want to save just
a single message I can easily open the thread and go to it.

> 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.

I'm wondering what sort of form this would take. If it required some
sort of action
(typing to enable) prior to the desired operation then a prefix arg
strikes me as
sufficient since I can just use the prefix for the number of messages
in the thread,
which I either know because the number is displayed as part of the
thread features
or because It is collapsed and I can do some basic arithmetic based on
the number
of the next message. Or alternatively if thread ops were enabled and I want to
temporarily disable them, then simply "T" to expand the thread
accomplishes exactly
that - the desired operation now only applies to the root message.

In such a case, then, it would be either use the feature or not, and
perhaps point
out in the docs some of these caveats. This, of course, is provided
that we deal with
the issue of "reply", which I think we all agree is not appropriate.

>  > 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.

Seems like a reasonable idea. It doesn't get in the way when turned off
and would allow cautious individuals to get to understand better the
behavior.

Thanks,
~Arik

>
> 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.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~vm
> Post to     : vm@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~vm
> More help   : https://help.launchpad.net/ListHelp
>