Improving dt's UI

[David Wolever]

On 23-Jun-08, at 12:14 AM, Vlad Skvortsov wrote:
>> Ok, sounds good.  When I get into work today I'll tinker with it  
>> it a bit and see what I can do about a patch.
> ...so, am I understanding you correctly that you'd like to skip the  
> version selection menu altogether if there is only one version in  
> the "present" set? What if there are more than one? I'm talking  
> about the current dt UI (not about that you are proposing below).
I would like to skip as much interaction as possible, while still  
ensuring that all the required fields (category, version, etc) still  
exist.
Now that I've got a patch, just take a look at that and see how it  
does the defaults and such :)

>> Clearly I need to brush up on my RTFMing skills...
>> While that is much easier than I thought it was, I still (at least  
>> in theory) don't like the two steps -- it strikes me as a common  
>> use-case that should be simpler...
> And by "two steps" you mean that you have to invoke dt twice?  
> Actually, it's possible to do both actions with a single invocation  
> of dt:
> dt act $ISSUE -m "Some comment" -a change-header:header=value
Ah, so it is.

>> ... 'act'. We could make them optional, and if they are omitted,  
>> drop into
>> $EDITOR with "preset" headers. Would it work for you?
> After a second thought I think it's not a great idea: -a, -m and -F  
> are used for non-interactive work, so people used to that (myself  
> included) would find it surprising that an editor pops up when they  
> (mistakenly) omitted, say, -m.
Good point. Breaking muscle memory is defiantly a bad thing.

>> That wouldn't be bad, but is there any reason not to just add  
>> another command?
> I would prefer to keep the number of commands to minimum,  
> especially if there are ways to achieve the desired result using  
> the existing ones. By the way, if your preference is to have a  
> separate command for each logical action, this can be achieved by  
> shell aliases.
I agree that it's a good idea to keep the number of commands down  
(*glares at git*), but I think there is a benefit to making common  
actions built in commands (even if some sort of internal code just  
expands them as aliases).
There are three reasons for this:
0) Shell aliases don't work everywhere (eg, when I use `:!...` from  
Vim, aliases don't work)
1) They aren't standard -- when I go to my friend's machine, he  
doesn't have my aliases, so he either has to type a lot more (using  
the internal commands) or duplicate my aliases.
2) It's not very standard to require long commands for common  
actions.  For example, adding, moving, removing and copying are all  
separate commands in svn -- it doesn't use something like `svn shell  
--command=mv` (the exception, of course, is `propset`, but it's got  
`propedit` too, so it's not TOO bad)

BUT, you're probably much smarter than I am, and you've defiantly  
been using DI much longer than I have, so what I'm saying may be  
entirely true, but completely irrelevant in this case.

> As for the "drop me to an editor" functionality you mentioned, let  
> me first take a look at your patch to better understand what you  
> are looking for.
Ok, sounds good.  In my mind, it would be identical to my new  
implementation of `add`, just accepting a ticket number as as an  
argument (in fact, now that I think about it, they could probably use  
most of the same code too...)