On Tuesday 25 October 2005 14:24, Ben Clifford wrote:
hi. I'm interested in playing with the stg/git commandline completion code
- are you still actively working on it?
Well, yes, I've been still tuning it - but actually I'm not _maintaining_ it,
I'm using stgit on the Linux kernel so when on a command I don't have tab
completion I add the needed one (having the time and feeling to do it).
However, it's still done with enough care and polish to be shippable.
if so, do you have any more
formalised distribution process (like a git repo!) rather than grabbing
code out of email list postings? I can't seem to find much on google...
Well, Catalin's TODO included "bash completions", so I assume the thing could
be merged by him. Anyway,
I'm attaching the current version.
Btw, it's under GPL v2.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
I'm using stgit on the Linux kernel so when on a command I don't have tab
completion I add the needed one (having the time and feeling to do
it).
You can have a look at the tlacontrib project scripts (I can forward
them to you since you would need tla/baz to clone/checkout the project
and this procedure is a combination of 'tag' and 'get' commands). They
automatically generate the commands together with the options and are
later used in completion.
Of course, your approach would work as well but it requires more
maintance.
quoted
if so, do you have any more formalised distribution process (like a
git repo!) rather than grabbing code out of email list postings? I
can't seem to find much on google...
Well, Catalin's TODO included "bash completions", so I assume the
thing could be merged by him. Anyway, I'm attaching the current
version.
When you think it is ready, I'm happy to include it (though I would
prefer a more dynamic approach like the tla one but since I don't have
time for it I'll just use yours).
Thanks.
--
Catalin
On Tuesday 25 October 2005 17:18, Catalin Marinas wrote:
Blaisorblade [off-list ref] wrote:
quoted
I'm using stgit on the Linux kernel so when on a command I don't have tab
completion I add the needed one (having the time and feeling to do
it).
You can have a look at the tlacontrib project scripts (I can forward
them to you since you would need tla/baz to clone/checkout the project
and this procedure is a combination of 'tag' and 'get' commands). They
automatically generate the commands together with the options and are
later used in completion.
Of course, your approach would work as well but it requires more
maintance.
_Yes_, it wasn't ever intended to be published, and the help output doesn't
seem, at a quick look, trivially parsable (the source is better to parse but
I refuse that. Also, some options require still a special handling.
The best idea seems to write a Python script sourcing the Stgit source
(stgit/main.py to get commands, and then loading each class and iterating
over the "options" module member). I'm not fluent in Python enough currently,
but when I'll find time I'll probably study a bit reflection and write this
down (my Python experience amounts to some random readings on reviews and a
couple of days with Python docs).
quoted
quoted
if so, do you have any more formalised distribution process (like a
git repo!) rather than grabbing code out of email list postings? I
can't seem to find much on google...
quoted
Well, Catalin's TODO included "bash completions", so I assume the
thing could be merged by him. Anyway, I'm attaching the current
version.
When you think it is ready, I'm happy to include it (though I would
prefer a more dynamic approach like the tla one but since I don't have
time for it I'll just use yours).
Btw, what do you think about speeding up completions by reimplementing things
like "stg applied" or "stg unapplied" via cat (as noted in the comments at
the beginning of the script)? Tab completions can easily livelock a shell on
a busy system, so it's worthy speeding the thing up.
Thanks.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
The best idea seems to write a Python script sourcing the Stgit source
(stgit/main.py to get commands, and then loading each class and iterating
over the "options" module member).
I can add a function in stgit/main.py which would list the options.
The tla-completion generates a file listing a command with its option
on every line:
push -a -all -n --number -t --to --reverse --undo -h --help
...
Since I don't know much about the bash completion, let me know of the
format you'd prefer.
Btw, what do you think about speeding up completions by reimplementing things
like "stg applied" or "stg unapplied" via cat (as noted in the comments at
the beginning of the script)? Tab completions can easily livelock a shell on
a busy system, so it's worthy speeding the thing up.
In general, it is better to use the stg commands but the repository
structure won't probably change for a long time and it's OK to
optimise (if the speed improvement is visible). Anyway, these
particular commands are pretty fast (they behave like cat) but there
are others which are slower (usually the commands involving calls to
the GIT tool).
--
Catalin
On Tuesday 25 October 2005 18:24, Catalin Marinas wrote:
On 25/10/05, Blaisorblade [off-list ref] wrote:
quoted
The best idea seems to write a Python script sourcing the Stgit source
(stgit/main.py to get commands, and then loading each class and iterating
over the "options" module member).
I can add a function in stgit/main.py which would list the options.
The tla-completion generates a file listing a command with its option
on every line:
Since I don't know much about the bash completion, let me know of the
format you'd prefer.
Ok, I'll look into that. Probably it'll be around "opts_push="-a --all -n
--number...", i.e. this one works fine, through name indirection, i.e. you
say "expand the var which name is given by this expr".
quoted
Btw, what do you think about speeding up completions by reimplementing
things like "stg applied" or "stg unapplied" via cat (as noted in the
comments at the beginning of the script)? Tab completions can easily
livelock a shell on a busy system, so it's worthy speeding the thing up.
In general, it is better to use the stg commands but the repository
structure won't probably change for a long time
Ok.
and it's OK to
optimise (if the speed improvement is visible).
I believe it is, yes.
Anyway, these
particular commands are pretty fast (they behave like cat) but there
are others which are slower (usually the commands involving calls to
the GIT tool).
They _would_ behave like cat, except that Python is slow enough. Half a second
on a (almost) idle system means seconds and seconds on a busy system, and
it's pretty frequent that when I don't wait enough for an op. to complete I
get a traceback from the import statements, which haven't been completed.
And let's leave Gentoo's emerge alone - I'd say imports can take up to a
minute.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
They _would_ behave like cat, except that Python is slow enough. Half a second
on a (almost) idle system means seconds and seconds on a busy system, and
it's pretty frequent that when I don't wait enough for an op. to complete I
get a traceback from the import statements, which haven't been completed.
That's a thing I should fix in StGIT - trapping the exception
generated by SIGTERM and exiting silently.
And let's leave Gentoo's emerge alone - I'd say imports can take up to a
minute.
That's probably because it checks the status of the tree before
importing but this command wouldn't be used to generate the
completion.
--
Catalin
On Wednesday 26 October 2005 13:34, Catalin Marinas wrote:
On 25/10/05, Blaisorblade [off-list ref] wrote:
quoted
They _would_ behave like cat, except that Python is slow enough. Half a
second on a (almost) idle system means seconds and seconds on a busy
system, and it's pretty frequent that when I don't wait enough for an op.
to complete I get a traceback from the import statements, which haven't
been completed.
That's a thing I should fix in StGIT - trapping the exception
generated by SIGTERM and exiting silently.
Yep.
quoted
And let's leave Gentoo's emerge alone - I'd say imports can take up to a
With imports I mean Python import statement, in the case of the Gentoo
"emerge" command (which is written in Python).
Not the import command (and checking the state of the tree can take tens of
minutes, here - with a non-idle machine, though).
quoted
minute.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
From: Ben Clifford <hidden> Date: 2016-06-15 22:42:11
I'm using stgit on the Linux kernel so when on a command I don't
have tab
completion I add the needed one (having the time and feeling to do
it).
However, it's still done with enough care and polish to be shippable.
I've added some stuff to this to do a few cogito, gitk and (one) git
completions, split into different files. I thought I might as well
toss what I have out for anyone interested to play with.
I tried to put it in a new git repo online, but I'm having
difficulties - the poor link I'm on makes it not so much fun to
experiment. So I've tarred up my local repo warts and all and put it at:
http://www.hawaga.org.uk/ben/tech/gitcompletion-
a108bdc110dad770ec5c092759a8bc511790d21f.tar
Ben
--
Ben Clifford
http://www.hawaga.org.uk/ben/
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:11
Dear diary, on Tue, Nov 08, 2005 at 11:16:28AM CET, I got a letter
where Ben Clifford [off-list ref] told me that...
I've added some stuff to this to do a few cogito, gitk and (one) git
completions, split into different files. I thought I might as well
toss what I have out for anyone interested to play with.
I tried to put it in a new git repo online, but I'm having
difficulties - the poor link I'm on makes it not so much fun to
experiment. So I've tarred up my local repo warts and all and put it at:
http://www.hawaga.org.uk/ben/tech/gitcompletion-
a108bdc110dad770ec5c092759a8bc511790d21f.tar
Nice, I would like to add cg completion to Cogito's contrib/ - could you
please add some header to it with (c) information and stuff? (And make
it available somewhere just as a plain file.)
Besides, it would be probably best to just autogenerate the
auto-completion code - the usage information in Cogito is supposed to be
100% consistent and correct, so it should be a reliable source for that.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
From: Ben Clifford <hidden> Date: 2016-06-15 22:42:11
On 10 Nov 2005, at 09:23, Petr Baudis wrote:
Nice, I would like to add cg completion to Cogito's contrib/ -
could you
please add some header to it with (c) information and stuff? (And make
it available somewhere just as a plain file.)
OK, will do.
Besides, it would be probably best to just autogenerate the
auto-completion code - the usage information in Cogito is supposed
to be
100% consistent and correct, so it should be a reliable source for
that.
yeah, I was thinking about that this morning -- maybe I'll be in the
mood to implement...
There are a few small common functions that are used by all the git
completions, though. I suppose for going into cogito's contrib/ I
should include them directly in cogito completion code, but that
seems a little messy, as it would be nice to keep them in-sync with
what is used in the other completion files. hmm.
Ben
--
Ben ベン Бэн
http://www.hawaga.org.uk/ben/
From: Ben Clifford <hidden> Date: 2016-06-15 22:42:11
On 10 Nov 2005, at 09:23, Petr Baudis wrote:
Dear diary, on Tue, Nov 08, 2005 at 11:16:28AM CET, I got a letter
where Ben Clifford [off-list ref] told me that...
quoted
I've added some stuff to this to do a few cogito, gitk and (one) git
completions, split into different files. I thought I might as well
toss what I have out for anyone interested to play with.
From: Ben Clifford <hidden> Date: 2016-06-15 22:42:11
On 10 Nov 2005, at 09:23, Petr Baudis wrote:
Besides, it would be probably best to just autogenerate the
auto-completion code - the usage information in Cogito is supposed
to be
100% consistent and correct, so it should be a reliable source for
that.
Maybe reliable and consistent but I think that info would need a bit
of augmentation to use for specifying autocompletion - for example,
in the case of:
> Usage: cg-branch-add BRANCH_NAME LOCATION
BRANCH_NAME should *not* exist so it doesn't make sense to
autocomplete from the branch list, but in the case of:
> Usage: cg-fetch [-f] [-v] [BRANCH_NAME]
BRANCH_NAME *must* exist so it makes sense to autocomplete from the
branch list.
The amount of augmentation is probably not too much - probably
sufficient to specify for each parameter a completion-source(s)
(heads, branches, filenames, blah) that doesn't get displayed in --
help. But this is more information to maintain and get out of date...
I wonder if Nikolai has had thoughts about that for zsh completion?
Hopefully if anything gets added, it would be useful for both zsh and
bash
(I confess to having pretty much no idea how zsh completion works...)
Ben
--
Ben ベン Бэн
http://www.hawaga.org.uk/ben/
My email is high latency but best way to contact me. Alternatively,
SMS numbers at above URL.