monotone-devel
[Top][All Lists]
Advanced

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

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


From: Joel Reed
Subject: [Monotone-devel] enhancements to monotone auto-completion modules
Date: Mon, 30 May 2005 23:21:23 -0400
User-agent: Mutt/1.5.5.1i

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?

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?

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?

Now, for one crazy idea. As you can see above the 40 character hashes 
don't leave a lot of room on screen for other completion info.
What if monotone used base64 encoded ids instead of hexadecimal? Then we'd have
something like:

MGYzODc1OGU2MmY4ZTQyODI4ZjYK - 2004-04-23T13:30:11 address@hidden
MGZmODc1OGVkZmY4ZTQ3ODI4ZjYK - 2004-12-24T10:50:55 address@hidden
MGZlZTc1OGVkZmY4ZTQ4ODI4ZjYK - 2004-11-18T16:13:15 address@hidden
MGZlZTc1OGVkZmY4ZTQzODI4ZjYK - 2004-11-01T21:40:45 address@hidden

Perhaps in general shorter id's might be less intimidating? I'm not sure.

jr




reply via email to

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