[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Command aliases and removing command expansion from
Re: [Monotone-devel] Command aliases and removing command expansion from monotone
Tue, 13 Dec 2005 22:59:34 -0600
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.
> 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
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 about
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
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!"
>  http://savannah.nongnu.org/bugs/?func=detailitem&item_id=12907
Chad Walstrom <address@hidden> http://www.wookimus.net/
assert(expired(knowledge)); /* core dump */