Re: [Monotone-devel] Command aliases and removing command expansion from monotone

[Chad Walstrom]

Matthew Gregan <address@hidden>  wrote:
> While discussing the current behaviour of 'monotone revert' (see
> Alex's email about the possibility of losing work too easily) on
> #monotone, the idea of removing the automatic command expansion from
> monotone was discussed.

What?!  Why?

> 3. By guessing what the user wanted (command expansion)
>    % monotone com
>    monotone: warning: command 'com' has multiple ambiguous expansions:
>    monotone: comment
>    monotone: commit
>    monotone: complete
>    monotone: unknown command 'com'
> 
>    % monotone commi
>    monotone: beginning commit on branch 'net.venge.monotone'

Yep.  Very nice feature.  monotone shares this trait with such tried
and tested tools such as nmh.

> Note that the command expansion does not work for second level
> commands, so "monotone db inf" is not expanded to "monotone db
> info", and will error out by displaying the usage for the db
> command.

Sounds like an enhancement request.  Command expansion *should* work
for any argument passed to monotone.

> While convenient, command expansion does not lead to a stable UI
> that is safe for users to rely on (in fact, we have a bug[0] about
> this).

Not sure I agree here.

> For example, while "commi" will expand to "commit" today, it will
> fail to do so tomorrow when we add the much requested "commissar"
> appointment feature to monotone.

Then you get an error and learn that there's a new command available.
That's not so terrible of a feature.  "Hey, look at me!" says
commissar.

And what about command localization?  Why not "monotone anvertrauen"
for a German translation?  What logic would map "ci" to "anvertrauen"?
Perhaps I'm not being too serious, but then again, maybe I am.  I
don't think it's that far-fetched of a usability enhancement.  Command
expansion makes sense in this case, since the abbreviation isn't
easily mapped.  It might not make for terribly portable scripting, but
we've all heard that the "automate" command is where scripting should
interface anyway.  Besides, there's always environment variable
overloading to get back to the "C" environment, and you could add a
commandline switch to force C localization.

> The specific example given on IRC was that "monotone rev" is
> sufficient to expand to "monotone revert" and is potentially rather
> surprising to users.

What do you expect "monotone rev" to do if not revert?  I do not see
any other commands that start with the prefix "rev".  Are "users"
assuming this means "revision", not "revert"?  And if so, why wouldn't
a user try to use the "list" command to get that information?
"monotone list revision" (hypothetical command).

> Aliases, on the other hand, are explicitly defined.  This means that
> they're less likely to change tomorrow, and that any change that
> affected them is much more likely to be reflected in the
> documentation and the monotone release notes.

Command expansion is intended for 

> Given this, I suggest that we remove automatic command expansion
> behaviour from monotone, and ensure that any commonly used commands
> have sane and consistent aliases.

Well, I think my opinion is pretty obvious. ;-)  KEEP EXPANDING!

> Are there any command expansion you rely on today for which we
> should look at adding a static alias?

Chad stands at the corner with his bullhorn, "Don't let them take your
command expansion rights!"

> [0] http://savannah.nongnu.org/bugs/?func=detailitem&item_id=12907
-- 
Chad Walstrom <address@hidden>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */