[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: More descriptive help summary

From: Julio M. Merino Vidal
Subject: Re: [Monotone-devel] Re: More descriptive help summary
Date: Sat, 14 Apr 2007 09:04:24 +0200

On 12/04/2007, at 22:36, Thomas Keller wrote:

IMHO having multi-word commands would be more consistent and I'd happily
implement that, but I guess nobody would use it actually =). I
absolutely dislike command names with dashes or even underscores in it,
they are long and naturally hard to type.

But what about the following: Let us put all commands into appropriate
groups, but allow shorthands, in the way

  mtn commit

is actually resolved to

  mtn workspace commit

just because there is no other command group which also has a "commit"
command. Now if we would introduce a "commit" command in some other
group, there could be the output

mtn: "commit" resolves to multiple commands, which one did you mean?
mtn:   workspace commit   Commit workspace to database
mtn:   foo commit         Commit foo to somewhere

This would also resolve the "mtn heads" <> "mtn list heads" issue.
Logically (for the help output) the heads command would be listed under list (ls), but mtn heads would also work (as before) because there is no
other command with the same name (yet).

You know what... I actually like your proposal, very much. And as it concerns implementation, it'd simplify a bunch of things.

I think I may give it a try and reorganize commands as a tree, making "command groups" a first-level command (with no way to "execute" them, that is). Obviously, existing subcommands could become children of some other command, and they'd be defined in the same way. Result: a programmatic interface to define those subcommands and a way to query their help! :-)

Julio M. Merino Vidal <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]