Re: Update _twisted completion

["Eric P. Mangold" <eric@xxxxxxxxxxxx>]

Hi Phil,

On Sun, Feb 03, 2013 at 11:26:09PM -0500, Phil Pennock wrote:
> On 2013-02-03 at 12:53 -0500, Eric P. Mangold wrote:
> > Twisted ships a large number of commands, and e.g. `twistd' sub-commands are dynamically generated at runtime via plugin loading. As such, a static completion function is innappropriate for Twisted, and would be instantly out of date. So, the stub function just asks Twisted to send it a
> > completion function on stdout, which if well formed can be eval'd inside the stub function (_twisted) to produce results.
> 
> Wait what, a function to be eval'd, so can do anything in the shell
> environment, which runs because I press tab when seeing what options
> this "command the user is not familiar with" might offer?

Well, this is what we do, and it's what we've been doing. Getting the code
dynamically over stdin isn't much different than locating arbitrary completion
functions inside the Twisted directory and executing them.

Other completions parse GNU --help output *shrug*. So I'm not really seeing
much of a difference here..

> Is there no way to rationalize the options for expansion down to a
> schema with "global options, sub-commands, sub-command options, tags for
> known contexts" and have the _twisted function interpret those
> accordingly?

There would be a way, with a lot of extra work, I suppose. Coming up with
a safe-data-only schema to represent completley arbitrary completion functionality
seems like a lot of work to me :)

If it were that easy, perhaps we would already have "completion descriptors"
instead of "completion functions" ;)

I think it's kind of a stretch to imagine a situation where the user is typing a
command-line and preparing to execute it, but hasn't decided to trust the
software in question yet.

Software often times will install its own zsh completion functions in to a
"site-functions" directory, and so arbitrary completion behavior (including
access to the user's shell environment) is already part of the game.

I am also planning on adding some caching to speed things up (it's a little
slow right now to load and import the various python modules and generate
the function), and storing cached data (as the current "old" completion stub
 does) in to the user's shell env is one option I am exploring. I guess the
other options is to write cache data to $HOME, somewhere.

> 
> There's a difference between running an unknown command and having your
> shell execute, in its own context, any evaluable code supplied by that
> command because the user hit _tab_, not _enter_.

Im glad my little innovations have raised these questions. I
would like very much for there to be a system whereby software authors
could more easily take charge of supplying their own shell-completion
functionality as part of the software distribution, instead of relying on
static functions shipped with zsh. I've seen several other projcts in the
past that ship/generate their own functions, and we could probably all
benefit from using an officially supported protocol.

Our ad-hoc "protocol" is to call the command-line and append
"--_shell-completion zsh:${CURRENT}" - this tells our options-parsing
subsystem (twisted.python.usage) to generate a completion function
on stdout appropriate for the given command-line.

I really do wish there was a better way for commands to supply completions
at run-time. More feedback would be much appreciated.

Cheers,
-E