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

[Doron Behar <doron.behar@gmail.com>]

Thank you Oliver for your guidance, The revised patch is ready I'll send
it shortly, here are some more questions / comments I had regarding your
last reply.

On Wed, May 30, 2018 at 12:00:49AM +0200, Oliver Kiddle wrote:
> 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.

It's great, thanks!

> 
> > 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.

Got it.

> 
> > 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.

I copied `__git_tags`s content straight from `_git`s definition and
added a comment stating so.

> 
> > > 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.
> 

Got it.

> > > 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.

This is what I chose:

	'--lib=[comma separated list of C library files to link to]:library files'

> 
> > 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".

O.K, I used `ret` instead yet currently I don't see any use in this
variable since I didn't structured the completion file with `return ret`
at the end of any of the functions as I've seen in other completion
functions I read.

> 
> 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

Jesus, using `zstyle` is complicated, I hope I'll master this skill one
day..  Where can I find in the documentation more explanations about the
relation between zstyle and completion functions?