Re: [Monotone-devel] enhancements to monotone auto-completion modules

[Nathaniel Smith]

On Mon, May 30, 2005 at 11:21:23PM -0400, Joel Reed wrote:
> I'm thinking thru some enhancements to monotone's zsh auto-complete module,
> and wanted to bounce a few ideas around on the mailing list.
> 
> When completing "mt dropkey ...", we can present a somewhat helpful
> list of keys and the corresponding owners, by using "monotone ls keys"
> 
> 70a0f283898a18815a83df37c902e5f1492e9aa2 address@hidden
> 0d607d8724f015664fa0ca0e1a282fe708f2674b address@hidden
> ca09aeca875237679c4bb193d5b2d02747da9ead address@hidden
> d9e7a76879a99dad705f058e24299a7b289f03d8 address@hidden
> 367e100f480a7345783051788f37447381a0774f address@hidden
> a58fe1c0786c74d536bfd58c2139130a4b7377fd address@hidden
> 919607f11569c0fc0a4e232628c7c18868017757 address@hidden
> 
> However, we don't have a "mt complete key ..." command to use
> once the user starts typing a key. Can I add such a subcommand?

Don't see why not.

Don't the various shell completion libraries already have ways to deal
with this, though?  zsh's CVS completion, for instance, is quite happy
to do things like complete partially typed filenames after "cvs drop",
which it's figuring out candidates for by peeking in CVS/Entries
for...

> Secondly, "monotone ls keys" shows one way completion could be more
> helpful for things like revision ids: by showing some human readable 
> data along with the list of hashes to help the user decide which hash 
> they're looking for.
> 
> Currently, for example when a user types "mt update 0f", the completion
> list looks something like this:
> 
> 0f38758e62f8e42828f64bda2a6d6e8c0ebff053
> 0f686b12985260ec9fa1d95034f3dbc0ed3299b7
> 0f755d97cbc5913c597da357d59dd6dbb2cca9a0
> 0f8260b573bf3aa0e1213719814f2dcea69d2921
> 
> How to choose? The following output might help a bit more:
> 
> 0f38758e62f8e42828f64bda2a6d6e8c0ebff053 - 2004-04-23 13:30:11
> 0f686b12985260ec9fa1d95034f3dbc0ed3299b7 - 2004-12-24 10:50:55
> 0fd1e57fda300f1794e0ff60b05ca7034e9db22a - 2004-11-18 16:13:15
> 0fdb15a6f90a61ec0ab5b0c99c3c2b3726cf6f6b - 2004-11-01 21:40:45
> 
> or perhaps better still (addresses slightly munged):
> 
> 0f38758e62f8e42828f64bda2a6d6e8c0ebff053 - 2004-04-23 13:30:11 address@hidden
> 0f686b12985260ec9fa1d95034f3dbc0ed3299b7 - 2004-12-24 10:50:55 address@hidden
> 0fd1e57fda300f1794e0ff60b05ca7034e9db22a - 2004-11-18 16:13:15 address@hidden
> 0fdb15a6f90a61ec0ab5b0c99c3c2b3726cf6f6b - 2004-11-01 21:40:45 address@hidden
> 
> Do others agree this might be more helpful? What extra bits of info
> would you like to see? Should this be added as an option to "mt complete"?
> Maybe current behavior would be "--brief" otherwise more detailed info?

There is a "describe_revision" function that's used to generate the
output for things like "update" with ambiguous heads.

This sounds like an excellent use for --format, currently in
development on a branch... "automate select i:0f --format="%i %D %A"
or whatever...

> By the way, I got the above using:
> 
>   mt db execute "select A.id, unbase64(B.value) as value from revisions A left
>   outer join revision_certs B on A.id=B.id and A.id GLOB '0f*' and B.name in
>   ('author', 'date')"
> 
> Hmm, I though I could do something similiar with manifest_certs, but my 
> manifest_certs table is empty. It seems refining revision id completion
> probably most helpful, but anyway to do something similiar for files and
> manifests?

Manifest certs are going away as soon as someone gets around to saying
it's okay to break direct upgrading from pre-0.15 databases.  I'd
recommend ignoring them entirely.

-- Nathaniel

-- 
"...All of this suggests that if we wished to find a modern-day model
for British and American speech of the late eighteenth century, we could
probably do no better than Yosemite Sam."