vm team mailing list archive

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

Hi Arik, thanks for your feedback!

Arik Mitschang writes:

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

As I said before, prefix arguments are already used up for for numeric
arguments.  But I guess we could reuse them for thread operations if
we say that numeric counts and thread operations cannot be combined.
(Come to think of it, I don't know whether they can be combined.
I never checked that!)

The other possibility is to bind a key to toggle
vm-enable-thread-operations so that people can easily turn it on or
off.  This might be Tim's idea.  But I don't think this won't solve
the surprise element in the firing of thread operations.

Cheers,
Uday