Shell completions

[dag]

You said it was planned, so why not have an issue filed for it? ☺

The cmdargs package supports Bash and ZSH completions and seems to do so by providing different "formats" to render help pages in: System.Console.CmdArgs.Explicit / Displaying help

[pcapriotti]

I have been looking at how cmdargs does this, and I think I understand how it works.

The only thing that I'm not sure about is how it handles (if at all) the generation and installation of the completion script.

My plan is to implement a combinator that adds two internal commands to a parser:

• bash-completion-query: that takes the completion parameters COMP_WORDS and COMP_CWORD, and returns the possible completions for a given parser
• bash-completion-script: that returns a completion script using the above option to implement completion

The author of a program using optparse-applicative would then have to generate the script using bash-completion-script (every time the parser changes) and include it in the package as a data file. Ideally, the process could be automated in cabal.

Does that look like a sensible plan? Any other suggestions?

[dag]

Sounds good. Not sure why you'd need to update the script with the parser though, if it's just calling to --bash-completion-query anyway?

[pcapriotti]

Yeah, you're right. The script would actually only depend on the name of the program, so maybe there's no need for the bash-completion-script command.

[dag]

That flag is still nice because you can have a bashrc like, eval $(foo --bash-completion-script) or pipe it to your bashrc to install.

[pcapriotti]

Bash completion is done. There are still a few missing details, but the basic functionality is there. Full details here.

[dag]

Cool stuff!

Would it be difficult to make it possible to pass in things to be accessible from a completer function? I'm using the dyre package for configuration and accessing the config from just an IO action isn't trivial to my knowledge. I'd need the config for connecting to acid-state which might be useful for completing some arguments.

I suppose in the worst case I could make a global IORef, but would be nice to be able to avoid such hacks.

[pcapriotti]

I'm not sure I understand what the problem is exactly.

Assuming your initialization code comes after execParser, you can freely run it again from any completer, since the program will exit before returning from execParser, when invoked by the completion mechanism. In fact, you can think of a completer as an alternative main.

If you're running the initialization code before execParser, then you can just pass the extra arguments in the closure of the completer.

[dag]

Uh, of course. Not sure what I was thinking there. ☺