Re: [PATCH 1/1] Squashed commit of the following:

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Doron Behar wrote:
>
> I find that extremely useful when I write completions since it's super
> comfortable with my editor (Vim). Do you have any suggestions? Perhaps
> using EditorConfig?

I don't think editorconfig supports much beyond basic definitions of
indent style. In the case of vim, it supports a variety of foldmethods.
'set foldmethod=syntax' doesn't do such a bad job and if you don't like
it you can define custom expressions.

> Done, used this:
>
> 	local option_deps_modes='--deps-mode=[specify how to handle dependencies]:mode:__luarocks_deps_modes'

That looks fine.

> Besides removing the curly brackets, what is the difference when I use
> '(-.)' in the glob and when I don't? I tried to test this in directories
> where I had files ending with `.rockspec` and in directories where I
> hadn't had files like these and I couldn't tell the difference in
> behaviour. What am I missing?

It can make a difference if you have directories ending in .rockspec.
That perhaps isn't common but in some contexts it can matter.
It is common to setup the file-patterns style to mix directories in with
matched files in which case it is less apparent.
For reference, see the old discussion around workers/19292.

> I couldn't think of a better way of doing this other then just copying
> manually `__git_tags` or using this hack.

Duplicating __git_tags' functionality is just as few lines of code and
less likely to break. This looks rather fragile.

> > In this spec, you already have already specified a message - "LICENSE"
> > so calling _message is superfluous. "LICENSE" can be improved on as a
> > message but I'd avoid constructs like "write a" and use something like
> > 'license (e.g. MIT/X11 or "GNU GPL v3")'
>
> That's a good description, cool. I've come up with this options
> specifications:
>
> 	'--license=[a license string]:license:{_message -e license "(e.g. \"MIT/X11\" or \"GNU GPL v3\")"}'

My point about calling _message being superfluous perhaps wasn't clear.
The second part of the colon-delimited spec IS a message. So you can
just use:

  '--license=[specify a license string]:license (e.g. "MIT/X11" or "GNU GPL v3")'

Note that I also added an initial verb in the description which was a
suggestion I had made earlier but not repeated.

> > Your description, looks like the message for the matches:
> >   '--lib[specify libraries to link against C files]:libraries (comma-separated)'
> > 
> > Or use _sequence or _values if you generate matches.
> > 
>
> I've no idea if this is possible to complete matches for this option. I
> don't have any experience in using this option as well so I'll leave it
> this way. Perhaps it'll be better for the specification to be this:
>
> 	'--lib=[C library files to link to]:'

At least include a message after the colon.

> I'm not sure I understand yet what tags are used for generally in
> completions (RTFD I know but forgive me I'm lazy :/) but anyway the tag
> I chose as the 1st argument for `_call_function` is `subcmd`. Is that
> cool? It looks like that:
>
> 	_call_function subcmd _luarocks_${words[1]}

The first argument to _call_function is not a tag but a variable name.
The return status from the function is assigned to it. Normally, you'll
see "ret".

Tags are used with the zstyle mechanism. zstyle gives you
context-sensitive options where a bunch of information is stuffed into a
context string. For completion,
    :completion:<function>:<completer>:<command>:<arg>:<tag>
Note that the last component is the tag for the current matches.
This is a much more succinct and convenient way to configure things than
if you needed lots of nested if statements.

Taking an example from one of your messages we have:
    zstyle ':completion:*:kill:*' command 'ps -u $USER -o pid,%cpu,tty,cputime,cmd'

As it happens, for kill completion the command style is only looked up
when completing processes but it'd be wise to put the processes tag
into the context there. If you want the style to work for all commands
and not just kill, that'd be essential. Otherwise, it might run ps when
generating some other entirely different sort of matches:

    zstyle ':completion:*:processes' command 'ps -u $USER -o pid,%cpu,tty,cputime,cmd'

(To answer the question in that other post, don't try to emulate that,
just use _pids and leave process selection to the user. ps defaulting to
the current tty made more sense a couple of decades ago.) 

The other thing tags are often used for is for grouping completion
matches. Groups are separate but it is common to use the tag as the
group name which is what you get with:
    zstyle ':completion:*' group-name ''

Finally, tags can be used with the tag-order style to allow users to
try some matches before others.

Oliver