first stab at zsh completion

[Adam Spiers]

On Mon, Dec 26, 2011 at 7:15 PM, Joey Hess <joey at kitenet.net> wrote:
> Adam Spiers wrote:
>> there is a bigger cost - the risk of having a version of the completion
>> rules which does not match the version of mr installed.
>
> This is, in practice, not a large problem, and can be dealt with by
> distribution integrators.

Agreed.

>> There's also a converse argument.  Completion functions are not only
>> coupled to the thing they are completing for, but also to the shell's
>> completion API.  When the API changes, it's better to have completion
>> functions within the shell's distribution, because the shell's
>> developers can fix all completion functions to work with the new API
>> in one go.

Actually, (somewhat contradicting my own argument) the zsh completion
API is extremely stable these days.  Back around 1999--2000, I *used*
to be something very loosely approaching a zsh guru by normal people's
standards (though nowhere near the likes of Peter Stephenson, Bart
Schaefer, Zefram etc.), having contributed patches for various bits
and pieces ... and now, over 10 years later, while making a first stab
at completion for mr (see below), I have not noticed *any* significant
changes in the API since then.

> Which is why I would certianly not like to bundle zsh completion
> functions with the programs they complete. You have to be a zsh guru to
> write them, they have changed a *lot* over the years (I don't recognize
> anything in the current dpkg completion that's left from the one I
> originally wrote),

Perhaps you are referring to the change from the ancient system based
on compctl one-liners, to the all-singing all-dancing 'compsys' which
is based on complex shell functions and various built-ins from the
zsh/zle module?  That was a huge, one-off change.

> and upstream is very responsive, to keep the completions
> up-to-date.
>
> I suspect that bash completion will head in a similar direction, as they
> get reworked to support dynamically loading completions on demand, per
> http://thread.gmane.org/gmane.comp.shells.bash.completion.devel/3375

Yes, I suspect bash's completion is still light years behind zsh's,
and may require major changes to catch up.

> With that said, putting a bash completion in mr now just means a little
> probable pain later on, so I'm not strongly opposed.
>
> The real difficulty in completing mr is that it accepts an arbitrary set
> of subcommands, even depending on what repository it's run in.

Actually, that's pretty easy to deal with, albeit with a performance
penalty.  My first draft version automatically detects the available
actions by parsing the output of `mr thisisaninvalidcommand`:

  https://github.com/aspiers/kitenet-mr/commit/zsh

Currently it caches the result within the shell, but if as you point
out the output varies depending on which repository you're in, it
might make sense to remove that caching layer.

> In practice, I just type abbreviated things like "mr up" and "mr p"
> instead of reaching for the tab key; happily mr will accept any
> nonambiguous abbreviations and can be taught others. :)

Yeah, it's not a huge win.  Having completion for the options is quite
nice though :)