zsh-workers
 help / color / mirror / Atom feed
* Completion script for the ctags program
@ 2021-02-23  3:11 Jacob Gelbman
  2021-02-23 10:11 ` Peter Stephenson
  2021-02-23 21:39 ` Oliver Kiddle
  0 siblings, 2 replies; 38+ messages in thread
From: Jacob Gelbman @ 2021-02-23  3:11 UTC (permalink / raw)
  To: zsh-workers

I wrote a completion script for the ctags program. Someone might be able to use it:

#compdef ctags

local state

_arguments \
    "-?[help text]" \
    "-a[append the tags to an existing tag file]" \
    "-B[use backward searching patterns (?...?)]" \
    "-D[give definition for macro]:macro definition:" \
    "-e[output tag file for use with emacs]" \
    "-f[write tags to specified file. - is stdout]:file:_files" \
    "-F[use forward searching patterns]" \
    "-G[equivalent to --guess-language-eagerly]" \
    "-h[specify list of file extensions to be treated as include files]:" \
    "-I[a list of tokens to be specifically handled is read from either the command line or the specified file]:" \
    "-L[a list of input file names is read from the specified file. - is stdin]:file:_files" \
    "-n[equivalent to --excmd=number]" \
    "-N[equivalent to --excmd=pattern]" \
    "-o[alternative to -f]:file:_files" \
    "-R[equivalent to --recurse]" \
    "-u[equivalent to --sort=no]" \
    "-V[equivalent to --verbose]" \
    "-x[print a tabular cross reference file to stdout]" \
    "--alias-<lang>=[add a pattern detecting a name, can be used as an alt name for lang]:pattern" \
    "--append=[should tags be appended to existing tag file]:bool:(yes no)" \
    "--etags-include=[include reference to file in emacs style tag file]:file:_files" \
    "--exclude=[exclude files and directories matching pattern]:pattern" \
    "--exclude-exception=[don't exclude files and directories matching pattern even if they match the pattern specified with --exclude]:pattern" \
    "--excmd=[uses the specified type of ex command to locate tags]:ex command type:(number pattern mix combine)" \
    "--extras=[include extra tag entries for selected information (flags fFgpqrs)]:flags" \
    "--extras-<lang>=[include <lang> own extra tag entries for selected information]:flags" \
    "--fields=[include selected extension fields (flags aCeEfFikKlmnNpPrRsStxzZ)]:flags" \
    "--fields-<lang>=[include selected <lang> own extension fields]:flags" \
    "--filter=[behave as a filter, reading file names from stdin and writing tags to stdout]:bool:(yes no)" \
    "--filter-terminator=[specify string to print to stdout following the tags for each file parsed when --filter is enabled]:string" \
    "--format=[force output of specified tag file format]:level" \
    "--guess-language-eagerly[guess the language of input file more eagerly]" \
    "--help[help text]" \
    "--help-full[help text with experimental features]" \
    "--if0=[should code within #if 0 conditionals be parsed]:bool:(yes no)" \
    "--input-encoding=[specify encoding of all input files]:encoding" \
    "--input-encoding-<lang>=[specify encoding of the <lang> input files]:encoding" \
    "--kinddef-<lang>=[define new kind for <lang>]:kind" \
    "--kinds-<lang>=[enable/disable tag kinds for <lang>]:kind" \
    "--langdef=[define a new language to be parsed with regular expressions]:name" \
    "--langmap=[override default mapping of language to input file extension]:maps" \
    "--language-force=[force all files to be interpreted using specified language]:language:->language" \
    "--languages=[restrict files scanned to these comma-separated languages]:language:->languages" \
    "--license[print details of software license]" \
    "--line-directives=[should #line directives be processed]:bool:(yes no)" \
    "--links=[indicate whether symlinks should be followed]:bool:(yes no)" \
    "--list-aliases=[list of alias patterns]:language:->language" \
    "--list-excludes[list of exclude patterns for files/dirs]" \
    "--list-extras=[list of extra tag flags]:language:->language" \
    "--list-features[list of compiled features]" \
    "--list-fields=[list of fields]:language:->language" \
    "--list-kinds=[list of all tag kinds for lang]:language:->language" \
    "--list-kinds-full=[list details of all tag kinds for lang]:language:->language" \
    "--list-languages[list of supported languages]" \
    "--list-map-extensions=[list of language extensions in mapping]:language:->language" \
    "--list-map-patterns=[list of language patterns in mapping]:language:->language" \
    "--list-maps=[list of language mappings (both extensions and patterns)]:language:->language" \
    "--list-mline-regex-flags[list of flags which can be used in a multiline regex parser definition]" \
    "--list-params=[list of language parameters. works with --machinable]:language:->language" \
    "--list-pseudo-tags[list of pseudo tags]" \
    "--list-regex-flags[list of flags which can be used in a regex parser definition]" \
    "--list-roles=[list of all roles of tag kinds specified for langs]:language:->language" \
    "--list-subparsers=[list of subparsers for the base lang]:language:->language" \
    "--machinable=[use tab separated representation in --list-* output]:bool:(yes no)" \
    "--map-<lang>=[set, add(+), or remove(-) the map for <lang>]:pattern" \
    "--maxdepth=[specify maximum recursion depth]:depth" \
    "--mline-regex-<lang>=[define multiline regex for locating tags in <lang>]:pattern" \
    "--options=[specify file (or dir) from which command line options should be read]:file:_files" \
    "--options-maybe=[same as --options but doesn't error]:file:_files" \
    "--optlib-dir=[add or set dir to optlib search path]:dir:_files -/" \
    "--output-encoding=[the encoding to write the tag file in]:encoding" \
    "--output-format=[specify the output format]:format:(u-ctags e-ctags etags xref)" \
    "--param-<lang>=[set <lang> specific parameter]:argument" \
    "--pattern-length-limit=[cutoff patterns of tag entries after N characters]:number" \
    "--print-language[don't make tags file but just print the guessed lang name for input file]" \
    "--pseudo-tags=[enable/disable emitting pseudo tag named ptag. if *, enable emitting all pseudo tags]:ptag" \
    "--put-field-prefix[put UCTAGS as prefix for the name of fields newly introducted in universal ctags]" \
    "--quiet=[don't print notice class messages]:bool:(yes no)" \
    "--recurse=[recurse]:bool:(yes no)" \
    "--regex-<lang>=[define regex for locating tags in specific lang]:pattern" \
    "--roles-<lang>.<kind>=[enable/disable tag roles for kinds of <lang>]:role" \
    "--sort=[should tags be sorted]:argument:(yes no foldcase)" \
    "--tag-relative=[should paths be relative to location of tag file]:argument:(yes no always never)" \
    "--totals=[print stats about input and tag files]:arguments:(yes no extra)" \
    "--verbose=[enable verbose messages describing actions]:bool:(yes no)" \
    "--version[print version]" \
    "--with-list-header=[prepend the column descriptions in --list-* output]:bool:(yes no)" \
    "*:file:_files"

if [ "$state" = "language" ]; then
    compadd `ctags --list-languages | cut -d" " -f1`
elif [ "$state" = "languages" ]; then
    _values -s , "languages" `ctags --list-languages | cut -d" " -f1`
fi



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-02-23  3:11 Completion script for the ctags program Jacob Gelbman
@ 2021-02-23 10:11 ` Peter Stephenson
  2021-02-23 22:20   ` Oliver Kiddle
  2021-02-23 21:39 ` Oliver Kiddle
  1 sibling, 1 reply; 38+ messages in thread
From: Peter Stephenson @ 2021-02-23 10:11 UTC (permalink / raw)
  To: Jacob Gelbman, zsh-workers

> On 23 February 2021 at 03:11 Jacob Gelbman <gelbman@gmail.com> wrote:
> I wrote a completion script for the ctags program. Someone might be able to use it:

Thanks, I'm surprised we don't have one but it looks like we only have etags.  I've
submitted it.

pws


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-02-23  3:11 Completion script for the ctags program Jacob Gelbman
  2021-02-23 10:11 ` Peter Stephenson
@ 2021-02-23 21:39 ` Oliver Kiddle
  2021-02-24  4:45   ` Jacob Gelbman
  1 sibling, 1 reply; 38+ messages in thread
From: Oliver Kiddle @ 2021-02-23 21:39 UTC (permalink / raw)
  To: Jacob Gelbman; +Cc: zsh-workers

Jacob Gelbman wrote:
> I wrote a completion script for the ctags program. Someone might be able to use it:

Which ctags!?
This doesn't match what I have installed on any of my systems. There
are multiple implementations of ctags, with it often being just a link
to etags - for which there is a completion albeit not a well maintained
one. One of the main reasons, a completion doesn't already exist is
that it would ideally need to detect the variant and at least have sane
fallbacks for variants that aren't handled. It could be useful to check
what the existing _etags is handling - that might be the exhuberant or
emacs variant.

In general, please follow the conventions outlined in
Etc/completion-style-guide in the zsh source distribution. For example,
completion functions usually use just 2 spaces for indentation.

> #compdef ctags
>
> local state

If you use states, you need to also handle the context which means
either passing -C to _arguments and setting up $curcontext or declaring
context local and passing it to later functions like _values.

>     "--alias-<lang>=[add a pattern detecting a name, can be used as an alt name for lang]:pattern" \
>     "--input-encoding-<lang>=[specify encoding of the <lang> input files]:encoding" \
>     "--kinddef-<lang>=[define new kind for <lang>]:kind" \
>     "--kinds-<lang>=[enable/disable tag kinds for <lang>]:kind" \

These would not complete especially helpfully. I suspect that <lang> there is
supposed to be substituted.

> if [ "$state" = "language" ]; then
>     compadd `ctags --list-languages | cut -d" " -f1`

It would be nicer to use a description by calling for example, _wanted
here.

> elif [ "$state" = "languages" ]; then
>     _values -s , "languages" `ctags --list-languages | cut -d" " -f1`
> fi

I'd probably use _sequence here as it is smaller and simpler. But
_values is fine if none of the languages contain characters that need
quoting from it.

The return status from this function will not be correct in all cases.
This can have effects like approximate completion being activated
despite matches having been added by earlier completers. Where states
are needed, you nearly always need to either save the status from
_arguments, typically via a ret variable or check $compstate[nmatches]
on exit.

Oliver


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-02-23 10:11 ` Peter Stephenson
@ 2021-02-23 22:20   ` Oliver Kiddle
  2021-02-23 22:45     ` Bart Schaefer
  2021-02-23 23:05     ` Mikael Magnusson
  0 siblings, 2 replies; 38+ messages in thread
From: Oliver Kiddle @ 2021-02-23 22:20 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: Zsh workers

Peter Stephenson wrote:
> Thanks, I'm surprised we don't have one but it looks like we only have etags.  I've
> submitted it.

What you've committed looks garbled with the e-mail pasted into the
middle of the function.

Indentation can be corrected when committing new functions with minimal
effort and without need to note the alteration in ChangeLog etc. I hate
doing it later because it breaks the usefulness of git blame so would
appreciate if you could make a note to do that upfront.

That said, it is better that these get applied quickly rather than
missed and forgotten. Which leads me to reconsider that I never
applied the patch in 44804 to create a separate contrib directory for
completions. I would add "suppport for only some variants of a command"
to the criteria.

That patch mainly didn't get applied because of the outstanding question
of what the directory/configure option should be named. Greg Klanderman
replied favouring 'Unsupported' or 'Unmaintained'. I think I prefer
'Contrib' because they aren't necessarily "Unmaintained" and anything
beginning with U breaks my habit of expecting C/U/C<tab> to complete the
directories there with Unix. Any other suggestions/comments on that?

Given that we need to correct the file anyway, it is probably not too
late in this case. Do you want to fix it or shall I do it when moving it
across to the "Contrib" or whatever we call it directory?

Oliver


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-02-23 22:20   ` Oliver Kiddle
@ 2021-02-23 22:45     ` Bart Schaefer
  2021-02-23 23:51       ` Oliver Kiddle
  2021-02-23 23:05     ` Mikael Magnusson
  1 sibling, 1 reply; 38+ messages in thread
From: Bart Schaefer @ 2021-02-23 22:45 UTC (permalink / raw)
  To: Oliver Kiddle; +Cc: Peter Stephenson, Zsh workers

On Tue, Feb 23, 2021 at 2:20 PM Oliver Kiddle <opk@zsh.org> wrote:
>
> That said, it is better that these get applied quickly rather than
> missed and forgotten. Which leads me to reconsider that I never
> applied the patch in 44804 to create a separate contrib directory for
> completions. I would add "suppport for only some variants of a command"
> to the criteria.
>
> That patch mainly didn't get applied because of the outstanding question
> of what the directory/configure option should be named.

What's the parent directory, specifically?  Or is there a directory
called this underneath each of Unix, Darwin, etc.?

What about "Submitted" or "Volunteered" ?

I'd suggest "Proffered" except too many people would probably confuse
it with "preferred".


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-02-23 22:20   ` Oliver Kiddle
  2021-02-23 22:45     ` Bart Schaefer
@ 2021-02-23 23:05     ` Mikael Magnusson
  1 sibling, 0 replies; 38+ messages in thread
From: Mikael Magnusson @ 2021-02-23 23:05 UTC (permalink / raw)
  To: Oliver Kiddle; +Cc: Peter Stephenson, Zsh workers

On 2/23/21, Oliver Kiddle <opk@zsh.org> wrote:
> Peter Stephenson wrote:
>> Thanks, I'm surprised we don't have one but it looks like we only have
>> etags.  I've
>> submitted it.
>
> What you've committed looks garbled with the e-mail pasted into the
> middle of the function.
>
> Indentation can be corrected when committing new functions with minimal
> effort and without need to note the alteration in ChangeLog etc. I hate
> doing it later because it breaks the usefulness of git blame so would
> appreciate if you could make a note to do that upfront.

FWIW, git blame -w will usually succeed pretty well at ignoring
whitespace changes.

-- 
Mikael Magnusson


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-02-23 22:45     ` Bart Schaefer
@ 2021-02-23 23:51       ` Oliver Kiddle
  2021-02-24  0:52         ` Bart Schaefer
  0 siblings, 1 reply; 38+ messages in thread
From: Oliver Kiddle @ 2021-02-23 23:51 UTC (permalink / raw)
  To: Zsh workers

Bart Schaefer wrote:
> On Tue, Feb 23, 2021 at 2:20 PM Oliver Kiddle <opk@zsh.org> wrote:
> >
> > That said, it is better that these get applied quickly rather than
> > missed and forgotten. Which leads me to reconsider that I never
> > applied the patch in 44804 to create a separate contrib directory for
> > completions. I would add "suppport for only some variants of a command"
> > to the criteria.
> >
> > That patch mainly didn't get applied because of the outstanding question
> > of what the directory/configure option should be named.
>
> What's the parent directory, specifically?  Or is there a directory
> called this underneath each of Unix, Darwin, etc.?

What that patch adds is "Contrib" as a subdirectory of Completion
with identical make rules as for all the other directories at that
level (Unix, BSD, AIX, Zsh etc). So it'd need it's own subdirectories
for Type, Command (and perhaps Utility and Widget). The only
other difference is that installation was conditional upon a
--enable-contrib-completions option (which defaults to false).

That approach seemed simplest but that's not to say it has to be
done that way if you think it'd be better under each of the other
directories. A single directory may be easier if we wanted to do git
subtree merges from the zsh-completions project though that might need
hacking around anyway if it isn't named "src".

> What about "Submitted" or "Volunteered" ?

Maybe, though I'm not sure they are any more accurate a description
of the contents than "Contrib". Given a lax license constraint on the
contents we might theoretically pick up functions found on the wider
Internet and dump them in without them ever being explicitly contributed
or submitted.* I probably favour Contrib because I've seen it used
similarly elsewhere.

Other ideas include 'External', 'Independent', 'Extra', 'Supplemental',
'Annex', 'Additional', 'Scrap', 'Dump', 'Diverse', 'Sundry'.

For reference, the criteria for inclusion I suggested were:
    - differently licenced
    - low quality
    - poorly maintained
    - obscure command
    - dead upstream
    - incomplete/work in progress
    - major variants of the command not handled
The first of these is probably the most important, especially for some
downstream packagers but I can't think of a way to capture that
succinctly in one word that doesn't begin with U.

Any preferences?

Oliver

* Note that I would only do this where at least some sort of free
redistribution terms are clear.


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-02-23 23:51       ` Oliver Kiddle
@ 2021-02-24  0:52         ` Bart Schaefer
  2021-02-24 13:47           ` Daniel Shahaf
  0 siblings, 1 reply; 38+ messages in thread
From: Bart Schaefer @ 2021-02-24  0:52 UTC (permalink / raw)
  To: Zsh workers

On Tue, Feb 23, 2021 at 3:52 PM Oliver Kiddle <opk@zsh.org> wrote:
>
> What that patch adds is "Contrib" as a subdirectory of Completion
> with identical make rules as for all the other directories at that
> level (Unix, BSD, AIX, Zsh etc). So it'd need it's own subdirectories
> for Type, Command (and perhaps Utility and Widget). [...]
>
> That approach seemed simplest but that's not to say it has to be
> done that way if you think it'd be better under each of the other
> directories.

No, I think that's fine.

> I probably favour Contrib because I've seen it used
> similarly elsewhere.
>
> Other ideas include 'External', 'Independent', 'Extra', 'Supplemental',
> 'Annex', 'Additional', 'Scrap', 'Dump', 'Diverse', 'Sundry'.

Would "Accessory" imply too much approval?

"Extras" would avoid clashing with any of the existing subdirectories,
for people who have the same flavor of "C/U/C<TAB>" habit as you but
for one of the other operating systems.  It also has precedence in
some of the Linux repository names.  Similarly "External" that you
already mentioned, or "Extension" or "Extended".


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-02-23 21:39 ` Oliver Kiddle
@ 2021-02-24  4:45   ` Jacob Gelbman
  2021-02-24  7:20     ` Jacob Gelbman
  0 siblings, 1 reply; 38+ messages in thread
From: Jacob Gelbman @ 2021-02-24  4:45 UTC (permalink / raw)
  To: Oliver Kiddle; +Cc: zsh-workers

Hey, thanks for looking at the script and adding it to the repo, although I think some of got pasted in wrong. There’s a lot to writing completion functions and I’m still not 100% sure how to do it right.

> On Feb 23, 2021, at 3:39 PM, Oliver Kiddle <opk@zsh.org> wrote:
> 
> Jacob Gelbman wrote:
>> I wrote a completion script for the ctags program. Someone might be able to use it:
> 
> Which ctags!?

I have Universal Ctags 5.9.0

> This doesn't match what I have installed on any of my systems. There
> are multiple implementations of ctags, with it often being just a link
> to etags - for which there is a completion albeit not a well maintained
> one. One of the main reasons, a completion doesn't already exist is
> that it would ideally need to detect the variant and at least have sane
> fallbacks for variants that aren't handled. It could be useful to check
> what the existing _etags is handling - that might be the exhuberant or
> emacs variant.
> 

I located a few other ctags on my computers, I have BSD ctags that comes by default on the mac. Exuberant Ctags 5.8. and there’s etags that comes with emacs. I can probably add an if statement based on the output of ctags —version, and modify the function from that. If it’s etags, I’ll just:

_comps[ctags]=“_etags”; _etags

And exit.

> In general, please follow the conventions outlined in
> Etc/completion-style-guide in the zsh source distribution. For example,
> completion functions usually use just 2 spaces for indentation.
> 
>> #compdef ctags
>> 
>> local state
> 
> If you use states, you need to also handle the context which means
> either passing -C to _arguments and setting up $curcontext or declaring
> context local and passing it to later functions like _values.

The -C argument and the context/curcontext variables are confusing me, a lot.

> 
>>    "--alias-<lang>=[add a pattern detecting a name, can be used as an alt name for lang]:pattern" \
>>    "--input-encoding-<lang>=[specify encoding of the <lang> input files]:encoding" \
>>    "--kinddef-<lang>=[define new kind for <lang>]:kind" \
>>    "--kinds-<lang>=[enable/disable tag kinds for <lang>]:kind" \
> 
> These would not complete especially helpfully. I suspect that <lang> there is
> supposed to be substituted.

They’d show up in the menu when you press tab, but if I filled in the actual values, the list would be too long.

> 
>> if [ "$state" = "language" ]; then
>>    compadd `ctags --list-languages | cut -d" " -f1`
> 
> It would be nicer to use a description by calling for example, _wanted
> here.

I can do that.

> 
>> elif [ "$state" = "languages" ]; then
>>    _values -s , "languages" `ctags --list-languages | cut -d" " -f1`
>> fi
> 
> I'd probably use _sequence here as it is smaller and simpler. But
> _values is fine if none of the languages contain characters that need
> quoting from it.

This too.

> 
> The return status from this function will not be correct in all cases.
> This can have effects like approximate completion being activated
> despite matches having been added by earlier completers. Where states
> are needed, you nearly always need to either save the status from
> _arguments, typically via a ret variable or check $compstate[nmatches]
> on exit.
> 
> Oliver



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-02-24  4:45   ` Jacob Gelbman
@ 2021-02-24  7:20     ` Jacob Gelbman
  2021-02-24  9:26       ` Peter Stephenson
                         ` (2 more replies)
  0 siblings, 3 replies; 38+ messages in thread
From: Jacob Gelbman @ 2021-02-24  7:20 UTC (permalink / raw)
  To: zsh-workers

Here’s the updated script. It's now is able to detect if it’s the new universal ctags, the older exuberant ctags, bsd ctags that comes with the Mac, or a symlink to etags:

#compdef ctags

local context state line expl
local -A opt_args

if [ -z "$_ctags_type" ]; then
  local output=`ctags --version 2>&1`
  if [[ "$output" = *Universal\ Ctags* ]]; then
    _ctags_type="universal"
  elif [[ "$output" = *Exuberant\ Ctags* ]]; then
    _ctags_type="exuberant"
  elif [[ "$output" = *usage:\ ctags* ]]; then
    _ctags_type="bsd"
  elif [[ "$output" = *Emacs* ]]; then
    _ctags_type="etags"
  else
    _ctags_type="universal"
  fi
fi

if [ "$_ctags_type" = "etags" ]; then
  _etags
  return $?
fi

local -a arguments

if [ "$_ctags_type" = "universal" ]; then
  arguments=(
    "-?[help text]"
    "-a[append to tags file]"
    "-B[use backward searching patterns (?...?)]"
    "-D[give definition for macro]:macro definition:"
    "-e[output tag file for use with emacs]"
    "-f[write tags to specified file. - is stdout]:file:_files"
    "-F[use forward searching patterns (/.../)]"
    "-G[equivalent to --guess-language-eagerly]"
    "-h[specify list of file extensions to be treated as include files]:"
    "-I[a list of tokens to be specifically handled is read from either the command line or the specified file]:"
    "-L[a list of input file names is read from the specified file. - is stdin]:file:_files"
    "-n[equivalent to --excmd=number]"
    "-N[equivalent to --excmd=pattern]"
    "-o[alternative to -f]:file:_files"
    "-R[equivalent to --recurse]"
    "-u[equivalent to --sort=no]"
    "-V[equivalent to --verbose]"
    "-x[print a tabular cross reference file to stdout]"
    "--alias-<lang>=[add a pattern detecting a name, can be used as an alt name for lang]:pattern"
    "--append=[should tags be appended to existing tag file]:bool:(yes no)"
    "--etags-include=[include reference to file in emacs style tag file]:file:_files"
    "--exclude=[exclude files and directories matching pattern]:pattern"
    "--exclude-exception=[don't exclude files and directories matching pattern even if they match the pattern specified with --exclude]:pattern"
    "--excmd=[uses the specified type of ex command to locate tags]:ex command type:(number pattern mix combine)"
    "--extras=[include extra tag entries for selected information (flags fFgpqrs)]:flags"
    "--extras-<lang>=[include <lang> own extra tag entries for selected information]:flags"
    "--fields=[include selected extension fields (flags aCeEfFikKlmnNpPrRsStxzZ)]:flags"
    "--fields-<lang>=[include selected <lang> own extension fields]:flags"
    "--filter=[behave as a filter, reading file names from stdin and writing tags to stdout]:bool:(yes no)"
    "--filter-terminator=[specify string to print to stdout following the tags for each file parsed when --filter is enabled]:string"
    "--format=[force output of specified tag file format]:level"
    "--guess-language-eagerly[guess the language of input file more eagerly]"
    "--help[help text]"
    "--help-full[help text with experimental features]"
    "--if0=[should code within #if 0 conditionals be parsed]:bool:(yes no)"
    "--input-encoding=[specify encoding of all input files]:encoding"
    "--input-encoding-<lang>=[specify encoding of the <lang> input files]:encoding"
    "--kinddef-<lang>=[define new kind for <lang>]:kind"
    "--kinds-<lang>=[enable/disable tag kinds for <lang>]:kind"
    "--langdef=[define a new language to be parsed with regular expressions]:name"
    "--langmap=[override default mapping of language to input file extension]:maps"
    "--language-force=[force all files to be interpreted using specified language]:language:->language"
    "--languages=[restrict files scanned to these comma-separated languages]:language:->languages"
    "--license[print details of software license]"
    "--line-directives=[should #line directives be processed]:bool:(yes no)"
    "--links=[indicate whether symlinks should be followed]:bool:(yes no)"
    "--list-aliases=[list of alias patterns]:language:->language"
    "--list-excludes[list of exclude patterns for files/dirs]"
    "--list-extras=[list of extra tag flags]:language:->language"
    "--list-features[list of compiled features]"
    "--list-fields=[list of fields]:language:->language"
    "--list-kinds=[list of all tag kinds for lang]:language:->language"
    "--list-kinds-full=[list details of all tag kinds for lang]:language:->language"
    "--list-languages[list of supported languages]"
    "--list-map-extensions=[list of language extensions in mapping]:language:->language"
    "--list-map-patterns=[list of language patterns in mapping]:language:->language"
    "--list-maps=[list of language mappings (both extensions and patterns)]:language:->language"
    "--list-mline-regex-flags[list of flags which can be used in a multiline regex parser definition]"
    "--list-params=[list of language parameters. works with --machinable]:language:->language"
    "--list-pseudo-tags[list of pseudo tags]"
    "--list-regex-flags[list of flags which can be used in a regex parser definition]"
    "--list-roles=[list of all roles of tag kinds specified for langs]:language:->language"
    "--list-subparsers=[list of subparsers for the base lang]:language:->language"
    "--machinable=[use tab separated representation in --list-* output]:bool:(yes no)"
    "--map-<lang>=[set, add(+), or remove(-) the map for <lang>]:pattern"
    "--maxdepth=[specify maximum recursion depth]:depth"
    "--mline-regex-<lang>=[define multiline regex for locating tags in <lang>]:pattern"
    "--options=[specify file (or dir) from which command line options should be read]:file:_files"
    "--options-maybe=[same as --options but doesn't error]:file:_files"
    "--optlib-dir=[add or set dir to optlib search path]:dir:_files -/"
    "--output-encoding=[the encoding to write the tag file in]:encoding"
    "--output-format=[specify the output format]:format:(u-ctags e-ctags etags xref)"
    "--param-<lang>=[set <lang> specific parameter]:argument"
    "--pattern-length-limit=[cutoff patterns of tag entries after N characters]:number"
    "--print-language[don't make tags file but just print the guessed lang name for input file]"
    "--pseudo-tags=[enable/disable emitting pseudo tag named ptag. if *, enable emitting all pseudo tags]:ptag"
    "--put-field-prefix[put UCTAGS as prefix for the name of fields newly introducted in universal ctags]"
    "--quiet=[don't print notice class messages]:bool:(yes no)"
    "--recurse=[recurse]:bool:(yes no)"
    "--regex-<lang>=[define regex for locating tags in specific lang]:pattern"
    "--roles-<lang>.<kind>=[enable/disable tag roles for kinds of <lang>]:role"
    "--sort=[should tags be sorted]:argument:(yes no foldcase)"
    "--tag-relative=[should paths be relative to location of tag file]:argument:(yes no always never)"
    "--totals=[print stats about input and tag files]:arguments:(yes no extra)"
    "--verbose=[enable verbose messages describing actions]:bool:(yes no)"
    "--version[print version]"
    "--with-list-header=[prepend the column descriptions in --list-* output]:bool:(yes no)"
    "*:file:_files"
  )
elif [ "$_ctags_type" = "exuberant" ]; then
  arguments=(
    "-a[append to tags file]"
    "-B[use backward searching patterns (?...?)]"
    "-e[output tag file for use with emacs]"
    "-f[write tags to specified file. - is stdout]:file:_files"
    "-F[use forward searching patterns (/.../)]"
    "-h[specify list of file extensions to be treated as include files]:"
    "-I[a list of tokens to be specifically handled is read from either the command line or the specified file]:"
    "-L[a list of input file names is read from the specified file. - is stdin]:file:_files"
    "-n[equivalent to --excmd=number]"
    "-N[equivalent to --excmd=pattern]"
    "-o[alternative to -f]:file:_files"
    "-R[equivalent to --recurse]"
    "-u[equivalent to --sort=no]"
    "-V[equivalent to --verbose]"
    "-x[print a tabular cross reference file to stdout]"
    "--append=[should tags be appended to existing tag file]:bool:(yes no)"
    "--etags-include=[include reference to file in emacs style tag file]:file:_files"
    "--exclude=[exclude files and directories matching pattern]:pattern"
    "--excmd=[uses the specified type of ex command to locate tags]:ex command type:(number pattern mix)"
    "--extra=[include extra tag entries for selected information (flags fq)]:flags"
    "--fields=[include selected extension fields (flags afmikKlnsStz)]:flags"
    "--file-scope=[should tags scoped only for a single file be included in output]:bool:(yes no)"
    "--filter=[behave as a filter, reading file names from stdin and writing tags to stdout]:bool:(yes no)"
    "--filter-terminator=[specify string to print to stdout following the tags for each file parsed when --filter is enabled]:string"
    "--format=[force output of specified tag file format]:level"
    "--help[help text]"
    "--if0=[should code within #if 0 conditionals be parsed]:bool:(yes no)"
    "--<lang>-kinds=[enable/disable tag kinds for <lang>]:kind"
    "--langdef=[define a new language to be parsed with regular expressions]:name"
    "--langmap=[override default mapping of language to input file extension]:maps"
    "--language-force=[force all files to be interpreted using specified language]:language:->language"
    "--languages=[restrict files scanned to these comma-separated languages]:language:->languages"
    "--license[print details of software license]"
    "--line-directives=[should #line directives be processed]:bool:(yes no)"
    "--links=[indicate whether symlinks should be followed]:bool:(yes no)"
    "--list-kinds=[list of all tag kinds for lang]:language:->language"
    "--list-languages[list of supported languages]"
    "--list-maps=[list of language mappings (both extensions and patterns)]:language:->language"
    "--options=[specify file (or dir) from which command line options should be read]:file:_files"
    "--recurse=[recurse]:bool:(yes no)"
    "--regex-<lang>=[define regex for locating tags in specific lang]:pattern"
    "--sort=[should tags be sorted]:argument:(yes no foldcase)"
    "--tag-relative=[should paths be relative to location of tag file]:argument:(yes no)"
    "--totals=[print stats about input and tag files]:arguments:(yes no)"
    "--verbose=[enable verbose messages describing actions]:bool:(yes no)"
    "--version[print version]”
    "*:file:_files"
  )
elif [ "$_ctags_type" = "bsd" ]; then
  arguments=(
    "-a[append to tags file]"
    "-B[use backward searching patterns (?...?)]"
    "-d[create tags for #defines that don't take arguments]"
    "-F[use forward searching patterns (/.../)]"
    "-f[write tags to specified file]:file:_files"
    "-t[create tags for typedefs, structs, unions, and enums]"
    "-u[update the specified files in the tags file]"
    "-v[an index of the form expected by vgrind(1) is produced]"
    "-w[suppress warning diagnostics]"
    "-x[ctags produces a simple function index]"
    "*:file:_files"
  )
fi

_arguments $arguments

if [[ "$state" = language* ]]; then
  local -a languages
  languages=(`ctags --list-languages | cut -d" " -f1`)
  if [ "$state" = "language" ]; then
    _wanted languages expl language compadd $languages
  elif [ "$state" = "languages" ]; then
    _values -s , languages $languages
  fi
fi

return $(( compstate[nmatches] > 0 ? 0 : 1 ))







> On Feb 23, 2021, at 10:45 PM, Jacob Gelbman <gelbman@gmail.com> wrote:
> 
> Hey, thanks for looking at the script and adding it to the repo, although I think some of got pasted in wrong. There’s a lot to writing completion functions and I’m still not 100% sure how to do it right.
> 
>> On Feb 23, 2021, at 3:39 PM, Oliver Kiddle <opk@zsh.org> wrote:
>> 
>> Jacob Gelbman wrote:
>>> I wrote a completion script for the ctags program. Someone might be able to use it:
>> 
>> Which ctags!?
> 
> I have Universal Ctags 5.9.0
> 
>> This doesn't match what I have installed on any of my systems. There
>> are multiple implementations of ctags, with it often being just a link
>> to etags - for which there is a completion albeit not a well maintained
>> one. One of the main reasons, a completion doesn't already exist is
>> that it would ideally need to detect the variant and at least have sane
>> fallbacks for variants that aren't handled. It could be useful to check
>> what the existing _etags is handling - that might be the exhuberant or
>> emacs variant.
>> 
> 
> I located a few other ctags on my computers, I have BSD ctags that comes by default on the mac. Exuberant Ctags 5.8. and there’s etags that comes with emacs. I can probably add an if statement based on the output of ctags —version, and modify the function from that. If it’s etags, I’ll just:
> 
> _comps[ctags]=“_etags”; _etags
> 
> And exit.
> 
>> In general, please follow the conventions outlined in
>> Etc/completion-style-guide in the zsh source distribution. For example,
>> completion functions usually use just 2 spaces for indentation.
>> 
>>> #compdef ctags
>>> 
>>> local state
>> 
>> If you use states, you need to also handle the context which means
>> either passing -C to _arguments and setting up $curcontext or declaring
>> context local and passing it to later functions like _values.
> 
> The -C argument and the context/curcontext variables are confusing me, a lot.
> 
>> 
>>>   "--alias-<lang>=[add a pattern detecting a name, can be used as an alt name for lang]:pattern" \
>>>   "--input-encoding-<lang>=[specify encoding of the <lang> input files]:encoding" \
>>>   "--kinddef-<lang>=[define new kind for <lang>]:kind" \
>>>   "--kinds-<lang>=[enable/disable tag kinds for <lang>]:kind" \
>> 
>> These would not complete especially helpfully. I suspect that <lang> there is
>> supposed to be substituted.
> 
> They’d show up in the menu when you press tab, but if I filled in the actual values, the list would be too long.
> 
>> 
>>> if [ "$state" = "language" ]; then
>>>   compadd `ctags --list-languages | cut -d" " -f1`
>> 
>> It would be nicer to use a description by calling for example, _wanted
>> here.
> 
> I can do that.
> 
>> 
>>> elif [ "$state" = "languages" ]; then
>>>   _values -s , "languages" `ctags --list-languages | cut -d" " -f1`
>>> fi
>> 
>> I'd probably use _sequence here as it is smaller and simpler. But
>> _values is fine if none of the languages contain characters that need
>> quoting from it.
> 
> This too.
> 
>> 
>> The return status from this function will not be correct in all cases.
>> This can have effects like approximate completion being activated
>> despite matches having been added by earlier completers. Where states
>> are needed, you nearly always need to either save the status from
>> _arguments, typically via a ret variable or check $compstate[nmatches]
>> on exit.
>> 
>> Oliver
> 



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-02-24  7:20     ` Jacob Gelbman
@ 2021-02-24  9:26       ` Peter Stephenson
  2021-02-24 14:24       ` Daniel Shahaf
  2021-02-24 21:54       ` Completion script for the ctags program dana
  2 siblings, 0 replies; 38+ messages in thread
From: Peter Stephenson @ 2021-02-24  9:26 UTC (permalink / raw)
  To: Jacob Gelbman, zsh-workers

> On 24 February 2021 at 07:20 Jacob Gelbman <gelbman@gmail.com> wrote:
> Here’s the updated script. It's now is able to detect if it’s the new
> universal ctags, the older exuberant ctags, bsd ctags that comes with
>the Mac, or a symlink to etags:

Thanks, I've updated it and hopefully the formatting is OK this time
(feel free to send an attachment or better still a patch which reduces
the amount of work by hand).

Cheers
pws


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-02-24  0:52         ` Bart Schaefer
@ 2021-02-24 13:47           ` Daniel Shahaf
  0 siblings, 0 replies; 38+ messages in thread
From: Daniel Shahaf @ 2021-02-24 13:47 UTC (permalink / raw)
  To: zsh-workers

Bart Schaefer wrote on Tue, Feb 23, 2021 at 16:52:51 -0800:
> On Tue, Feb 23, 2021 at 3:52 PM Oliver Kiddle <opk@zsh.org> wrote:
> >
> > What that patch adds is "Contrib" as a subdirectory of Completion
> > with identical make rules as for all the other directories at that
> > level (Unix, BSD, AIX, Zsh etc). So it'd need it's own subdirectories
> > for Type, Command (and perhaps Utility and Widget). [...]
> >
> > That approach seemed simplest but that's not to say it has to be
> > done that way if you think it'd be better under each of the other
> > directories.
> 
> No, I think that's fine.
> 
> > I probably favour Contrib because I've seen it used
> > similarly elsewhere.
> >
> > Other ideas include 'External', 'Independent', 'Extra', 'Supplemental',
> > 'Annex', 'Additional', 'Scrap', 'Dump', 'Diverse', 'Sundry'.
> 
> Would "Accessory" imply too much approval?
> 
> "Extras" would avoid clashing with any of the existing subdirectories,
> for people who have the same flavor of "C/U/C<TAB>" habit as you but
> for one of the other operating systems.  It also has precedence in
> some of the Linux repository names.  Similarly "External" that you
> already mentioned, or "Extension" or "Extended".

Bikeshed alert.

+1 to Contrib/.  As Oliver said, that name is used elsewhere with a similar meaning.


Oliver Kiddle wrote on Wed, Feb 24, 2021 at 00:51:36 +0100:
> For reference, the criteria for inclusion I suggested were:
>     - differently licenced
>     - low quality
>     - poorly maintained
>     - obscure command
>     - dead upstream
>     - incomplete/work in progress
>     - major variants of the command not handled
> The first of these is probably the most important, especially for some
> downstream packagers but I can't think of a way to capture that
> succinctly in one word that doesn't begin with U.

FWIW: DifferentlyLicensed, Copylefted, Non-3-clause-BSD, ByLicense/${license_short_name}/…


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-02-24  7:20     ` Jacob Gelbman
  2021-02-24  9:26       ` Peter Stephenson
@ 2021-02-24 14:24       ` Daniel Shahaf
  2021-02-24 18:58         ` Jacob Gelbman
                           ` (2 more replies)
  2021-02-24 21:54       ` Completion script for the ctags program dana
  2 siblings, 3 replies; 38+ messages in thread
From: Daniel Shahaf @ 2021-02-24 14:24 UTC (permalink / raw)
  To: Jacob Gelbman; +Cc: zsh-workers

Jacob Gelbman wrote on Wed, Feb 24, 2021 at 01:20:24 -0600:
> #compdef ctags

apt-file(1) on Debian stable shows a few more names:

arduino-ctags: /usr/bin/arduino-ctags
emacs-bin-common: /usr/bin/ctags.emacs
emacs-bin-common: /usr/bin/etags.emacs
exuberant-ctags: /usr/bin/ctags-exuberant
universal-ctags: /usr/bin/ctags-universal
xemacs21-bin: /usr/bin/etags.xemacs21

I assume at least some of these should be added to the #compdef line.  Would
you do the honours?

>     "--alias-<lang>=[add a pattern detecting a name, can be used as an alt name for lang]:pattern"

As Oliver said, literal angle brackets in the option name to be
completed aren't especially helpful.  In fact, I'll go as far as to say
I don't want users to run into it in released code.  Please change them.

You can use _call_program with --list-languages to generate the right set of
option names dynamically.

> elif [ "$_ctags_type" = "exuberant" ]; then
>   arguments=(
>     "-a[append to tags file]"
>     "-B[use backward searching patterns (?...?)]"
>     "-e[output tag file for use with emacs]"
>     "-f[write tags to specified file. - is stdout]:file:_files"

Is the argument to the -f option allowed to be pasted to it?  If so, s/-f/-f+/.

Also, s/:file:/:output file:/.  That part of the string is a user-facing
message, so the extra detail is helpful.

Also, you can drop the "- is stdout" part.  The descriptions are only
a summary of the functionality; they aren't meant to be a complete copy of
the manual.

>     "-F[use forward searching patterns (/.../)]"
>     "-h[specify list of file extensions to be treated as include files]:"

Write something after the colon.

>     "-I[a list of tokens to be specifically handled is read from either the command line or the specified file]:"

The thing in brackets doesn't describe the action of the option.  Please edit.

>     "-L[a list of input file names is read from the specified file. - is stdin]:file:_files"

Rephrase in the imperative.

>     "-R[equivalent to --recurse]"

This is normally rendered as:

      '(-r --recurse)'{-R,--recurse}'[description]'

>     "--fields=[include selected extension fields (flags afmikKlnsStz)]:flags"

Recommend to move the afmikKlnsStz thing to after the colon, so it'll be
shown at a more appropriate point.  Also, it would be helpful to display
descriptions to the flags using, e.g., «compset» (for the leading plus
sign) followed by «_values -s ''».

>     "--file-scope=[should tags scoped only for a single file be included in output]:bool:(yes no)"
>     "--filter=[behave as a filter, reading file names from stdin and writing tags to stdout]:bool:(yes no)"
>     "--filter-terminator=[specify string to print to stdout following the tags for each file parsed when --filter is enabled]:string"
>     "--format=[force output of specified tag file format]:level"
>     "--help[help text]"

"help text" is just a noun phrase.  Please use complete decsriptions.

Please use exclusions if needed («'(--foo)--bar[baz]'»).

>     "--language-force=[force all files to be interpreted using specified language]:language:->language"
>     "--languages=[restrict files scanned to these comma-separated languages]:language:->languages"

Can't say I'm a fan of having two states that differ by a single letter,
but so be it.

>     "--recurse=[recurse]:bool:(yes no)"

Fix the bracketed description.

> _arguments $arguments

Pass any arguments to _arguments that may be needed (for
instance, -s).

> if [[ "$state" = language* ]]; then
>   local -a languages
>   languages=(`ctags --list-languages | cut -d" " -f1`)

Use _call_program and $service.

>   if [ "$state" = "language" ]; then
>     _wanted languages expl language compadd $languages

Don't pass unsanitized command output to a builtin.  In this case,
«compadd -a languages» would do.

>   elif [ "$state" = "languages" ]; then
>     _values -s , languages $languages

Don't pass unsanitized command output to a builtin.  I don't know the
fix off the top of my head.

Thanks for the patch, and especially for adding exubertant and BSD ctags
support!

Daniel


> 
> 
> 
> 
> > On Feb 23, 2021, at 10:45 PM, Jacob Gelbman <gelbman@gmail.com> wrote:
> > 
> > Hey, thanks for looking at the script and adding it to the repo, although I think some of got pasted in wrong. There’s a lot to writing completion functions and I’m still not 100% sure how to do it right.
> > 
> >> On Feb 23, 2021, at 3:39 PM, Oliver Kiddle <opk@zsh.org> wrote:
> >> 
> >> Jacob Gelbman wrote:
> >>> I wrote a completion script for the ctags program. Someone might be able to use it:
> >> 
> >> Which ctags!?
> > 
> > I have Universal Ctags 5.9.0
> > 
> >> This doesn't match what I have installed on any of my systems. There
> >> are multiple implementations of ctags, with it often being just a link
> >> to etags - for which there is a completion albeit not a well maintained
> >> one. One of the main reasons, a completion doesn't already exist is
> >> that it would ideally need to detect the variant and at least have sane
> >> fallbacks for variants that aren't handled. It could be useful to check
> >> what the existing _etags is handling - that might be the exhuberant or
> >> emacs variant.
> >> 
> > 
> > I located a few other ctags on my computers, I have BSD ctags that comes by default on the mac. Exuberant Ctags 5.8. and there’s etags that comes with emacs. I can probably add an if statement based on the output of ctags —version, and modify the function from that. If it’s etags, I’ll just:
> > 
> > _comps[ctags]=“_etags”; _etags
> > 
> > And exit.
> > 
> >> In general, please follow the conventions outlined in
> >> Etc/completion-style-guide in the zsh source distribution. For example,
> >> completion functions usually use just 2 spaces for indentation.
> >> 
> >>> #compdef ctags
> >>> 
> >>> local state
> >> 
> >> If you use states, you need to also handle the context which means
> >> either passing -C to _arguments and setting up $curcontext or declaring
> >> context local and passing it to later functions like _values.
> > 
> > The -C argument and the context/curcontext variables are confusing me, a lot.
> > 
> >> 
> >>>   "--alias-<lang>=[add a pattern detecting a name, can be used as an alt name for lang]:pattern" \
> >>>   "--input-encoding-<lang>=[specify encoding of the <lang> input files]:encoding" \
> >>>   "--kinddef-<lang>=[define new kind for <lang>]:kind" \
> >>>   "--kinds-<lang>=[enable/disable tag kinds for <lang>]:kind" \
> >> 
> >> These would not complete especially helpfully. I suspect that <lang> there is
> >> supposed to be substituted.
> > 
> > They’d show up in the menu when you press tab, but if I filled in the actual values, the list would be too long.
> > 
> >> 
> >>> if [ "$state" = "language" ]; then
> >>>   compadd `ctags --list-languages | cut -d" " -f1`
> >> 
> >> It would be nicer to use a description by calling for example, _wanted
> >> here.
> > 
> > I can do that.
> > 
> >> 
> >>> elif [ "$state" = "languages" ]; then
> >>>   _values -s , "languages" `ctags --list-languages | cut -d" " -f1`
> >>> fi
> >> 
> >> I'd probably use _sequence here as it is smaller and simpler. But
> >> _values is fine if none of the languages contain characters that need
> >> quoting from it.
> > 
> > This too.
> > 
> >> 
> >> The return status from this function will not be correct in all cases.
> >> This can have effects like approximate completion being activated
> >> despite matches having been added by earlier completers. Where states
> >> are needed, you nearly always need to either save the status from
> >> _arguments, typically via a ret variable or check $compstate[nmatches]
> >> on exit.
> >> 
> >> Oliver
> > 
> 
> 


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-02-24 14:24       ` Daniel Shahaf
@ 2021-02-24 18:58         ` Jacob Gelbman
  2021-02-24 19:01           ` Bart Schaefer
  2021-03-03 20:02         ` Daniel Shahaf
  2021-03-07 19:18         ` Jacob Gelbman
  2 siblings, 1 reply; 38+ messages in thread
From: Jacob Gelbman @ 2021-02-24 18:58 UTC (permalink / raw)
  To: zsh-workers

This is my fault, I submitted it by pasting into the Mac Mail app, so there is a ascii double quote that was changed to a unicode double quote, in the file that was added to the repo. Also the line endings are in dos, so that should probably be changed to unix line endings. What’s the best way to submit these changes? Attach a .patch file?

> On Feb 24, 2021, at 8:24 AM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> 
> Jacob Gelbman wrote on Wed, Feb 24, 2021 at 01:20:24 -0600:
>> #compdef ctags
> 
> apt-file(1) on Debian stable shows a few more names:
> 
> arduino-ctags: /usr/bin/arduino-ctags
> emacs-bin-common: /usr/bin/ctags.emacs
> emacs-bin-common: /usr/bin/etags.emacs
> exuberant-ctags: /usr/bin/ctags-exuberant
> universal-ctags: /usr/bin/ctags-universal
> xemacs21-bin: /usr/bin/etags.xemacs21
> 
> I assume at least some of these should be added to the #compdef line.  Would
> you do the honours?
> 
>>    "--alias-<lang>=[add a pattern detecting a name, can be used as an alt name for lang]:pattern"
> 
> As Oliver said, literal angle brackets in the option name to be
> completed aren't especially helpful.  In fact, I'll go as far as to say
> I don't want users to run into it in released code.  Please change them.
> 
> You can use _call_program with --list-languages to generate the right set of
> option names dynamically.
> 
>> elif [ "$_ctags_type" = "exuberant" ]; then
>>  arguments=(
>>    "-a[append to tags file]"
>>    "-B[use backward searching patterns (?...?)]"
>>    "-e[output tag file for use with emacs]"
>>    "-f[write tags to specified file. - is stdout]:file:_files"
> 
> Is the argument to the -f option allowed to be pasted to it?  If so, s/-f/-f+/.
> 
> Also, s/:file:/:output file:/.  That part of the string is a user-facing
> message, so the extra detail is helpful.
> 
> Also, you can drop the "- is stdout" part.  The descriptions are only
> a summary of the functionality; they aren't meant to be a complete copy of
> the manual.
> 
>>    "-F[use forward searching patterns (/.../)]"
>>    "-h[specify list of file extensions to be treated as include files]:"
> 
> Write something after the colon.
> 
>>    "-I[a list of tokens to be specifically handled is read from either the command line or the specified file]:"
> 
> The thing in brackets doesn't describe the action of the option.  Please edit.
> 
>>    "-L[a list of input file names is read from the specified file. - is stdin]:file:_files"
> 
> Rephrase in the imperative.
> 
>>    "-R[equivalent to --recurse]"
> 
> This is normally rendered as:
> 
>      '(-r --recurse)'{-R,--recurse}'[description]'
> 
>>    "--fields=[include selected extension fields (flags afmikKlnsStz)]:flags"
> 
> Recommend to move the afmikKlnsStz thing to after the colon, so it'll be
> shown at a more appropriate point.  Also, it would be helpful to display
> descriptions to the flags using, e.g., «compset» (for the leading plus
> sign) followed by «_values -s ''».
> 
>>    "--file-scope=[should tags scoped only for a single file be included in output]:bool:(yes no)"
>>    "--filter=[behave as a filter, reading file names from stdin and writing tags to stdout]:bool:(yes no)"
>>    "--filter-terminator=[specify string to print to stdout following the tags for each file parsed when --filter is enabled]:string"
>>    "--format=[force output of specified tag file format]:level"
>>    "--help[help text]"
> 
> "help text" is just a noun phrase.  Please use complete decsriptions.
> 
> Please use exclusions if needed («'(--foo)--bar[baz]'»).
> 
>>    "--language-force=[force all files to be interpreted using specified language]:language:->language"
>>    "--languages=[restrict files scanned to these comma-separated languages]:language:->languages"
> 
> Can't say I'm a fan of having two states that differ by a single letter,
> but so be it.
> 
>>    "--recurse=[recurse]:bool:(yes no)"
> 
> Fix the bracketed description.
> 
>> _arguments $arguments
> 
> Pass any arguments to _arguments that may be needed (for
> instance, -s).
> 
>> if [[ "$state" = language* ]]; then
>>  local -a languages
>>  languages=(`ctags --list-languages | cut -d" " -f1`)
> 
> Use _call_program and $service.
> 
>>  if [ "$state" = "language" ]; then
>>    _wanted languages expl language compadd $languages
> 
> Don't pass unsanitized command output to a builtin.  In this case,
> «compadd -a languages» would do.
> 
>>  elif [ "$state" = "languages" ]; then
>>    _values -s , languages $languages
> 
> Don't pass unsanitized command output to a builtin.  I don't know the
> fix off the top of my head.
> 
> Thanks for the patch, and especially for adding exubertant and BSD ctags
> support!
> 
> Daniel
> 
> 
>> 
>> 
>> 
>> 
>>> On Feb 23, 2021, at 10:45 PM, Jacob Gelbman <gelbman@gmail.com> wrote:
>>> 
>>> Hey, thanks for looking at the script and adding it to the repo, although I think some of got pasted in wrong. There’s a lot to writing completion functions and I’m still not 100% sure how to do it right.
>>> 
>>>> On Feb 23, 2021, at 3:39 PM, Oliver Kiddle <opk@zsh.org> wrote:
>>>> 
>>>> Jacob Gelbman wrote:
>>>>> I wrote a completion script for the ctags program. Someone might be able to use it:
>>>> 
>>>> Which ctags!?
>>> 
>>> I have Universal Ctags 5.9.0
>>> 
>>>> This doesn't match what I have installed on any of my systems. There
>>>> are multiple implementations of ctags, with it often being just a link
>>>> to etags - for which there is a completion albeit not a well maintained
>>>> one. One of the main reasons, a completion doesn't already exist is
>>>> that it would ideally need to detect the variant and at least have sane
>>>> fallbacks for variants that aren't handled. It could be useful to check
>>>> what the existing _etags is handling - that might be the exhuberant or
>>>> emacs variant.
>>>> 
>>> 
>>> I located a few other ctags on my computers, I have BSD ctags that comes by default on the mac. Exuberant Ctags 5.8. and there’s etags that comes with emacs. I can probably add an if statement based on the output of ctags —version, and modify the function from that. If it’s etags, I’ll just:
>>> 
>>> _comps[ctags]=“_etags”; _etags
>>> 
>>> And exit.
>>> 
>>>> In general, please follow the conventions outlined in
>>>> Etc/completion-style-guide in the zsh source distribution. For example,
>>>> completion functions usually use just 2 spaces for indentation.
>>>> 
>>>>> #compdef ctags
>>>>> 
>>>>> local state
>>>> 
>>>> If you use states, you need to also handle the context which means
>>>> either passing -C to _arguments and setting up $curcontext or declaring
>>>> context local and passing it to later functions like _values.
>>> 
>>> The -C argument and the context/curcontext variables are confusing me, a lot.
>>> 
>>>> 
>>>>>  "--alias-<lang>=[add a pattern detecting a name, can be used as an alt name for lang]:pattern" \
>>>>>  "--input-encoding-<lang>=[specify encoding of the <lang> input files]:encoding" \
>>>>>  "--kinddef-<lang>=[define new kind for <lang>]:kind" \
>>>>>  "--kinds-<lang>=[enable/disable tag kinds for <lang>]:kind" \
>>>> 
>>>> These would not complete especially helpfully. I suspect that <lang> there is
>>>> supposed to be substituted.
>>> 
>>> They’d show up in the menu when you press tab, but if I filled in the actual values, the list would be too long.
>>> 
>>>> 
>>>>> if [ "$state" = "language" ]; then
>>>>>  compadd `ctags --list-languages | cut -d" " -f1`
>>>> 
>>>> It would be nicer to use a description by calling for example, _wanted
>>>> here.
>>> 
>>> I can do that.
>>> 
>>>> 
>>>>> elif [ "$state" = "languages" ]; then
>>>>>  _values -s , "languages" `ctags --list-languages | cut -d" " -f1`
>>>>> fi
>>>> 
>>>> I'd probably use _sequence here as it is smaller and simpler. But
>>>> _values is fine if none of the languages contain characters that need
>>>> quoting from it.
>>> 
>>> This too.
>>> 
>>>> 
>>>> The return status from this function will not be correct in all cases.
>>>> This can have effects like approximate completion being activated
>>>> despite matches having been added by earlier completers. Where states
>>>> are needed, you nearly always need to either save the status from
>>>> _arguments, typically via a ret variable or check $compstate[nmatches]
>>>> on exit.
>>>> 
>>>> Oliver
>>> 
>> 
>> 



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-02-24 18:58         ` Jacob Gelbman
@ 2021-02-24 19:01           ` Bart Schaefer
  0 siblings, 0 replies; 38+ messages in thread
From: Bart Schaefer @ 2021-02-24 19:01 UTC (permalink / raw)
  To: Jacob Gelbman; +Cc: zsh-workers

On Wed, Feb 24, 2021 at 10:58 AM Jacob Gelbman <gelbman@gmail.com> wrote:
>
> What’s the best way to submit these changes? Attach a .patch file?

Attaching as a .txt file is best.  Don't use file extensions that
common browsers/email clients may not know how to interpret.  Thanks!


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-02-24  7:20     ` Jacob Gelbman
  2021-02-24  9:26       ` Peter Stephenson
  2021-02-24 14:24       ` Daniel Shahaf
@ 2021-02-24 21:54       ` dana
  2 siblings, 0 replies; 38+ messages in thread
From: dana @ 2021-02-24 21:54 UTC (permalink / raw)
  To: Jacob Gelbman; +Cc: zsh-workers

On 24 Feb 2021, at 01:20, Jacob Gelbman <gelbman@gmail.com> wrote:
> local output=`ctags --version 2>&1`

Sorry if this was mentioned, i only glanced at the thread, but this type of
check is what _pick_variant is for. It's documented in zshcompsys(1), or you
can grep for it in other completion files to see it in action. In this case,
i guess something like:

  local variant
  _pick_variant -r variant \
    universal='Universal Ctags' \
    exuberant='Exuberant Ctags' \
    emacs=Emacs \
    bsd='usage: ctags' \
    universal \
    --version

dana



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-02-24 14:24       ` Daniel Shahaf
  2021-02-24 18:58         ` Jacob Gelbman
@ 2021-03-03 20:02         ` Daniel Shahaf
  2021-03-03 20:39           ` Jacob Gelbman
  2021-03-03 22:08           ` Jacob Gelbman
  2021-03-07 19:18         ` Jacob Gelbman
  2 siblings, 2 replies; 38+ messages in thread
From: Daniel Shahaf @ 2021-03-03 20:02 UTC (permalink / raw)
  To: Jacob Gelbman; +Cc: zsh-workers

Jacob, ping?  Is a followup patch in the offing?

As already mentioned, I think some of the review points below are
release blockers.

Daniel


Daniel Shahaf wrote on Wed, Feb 24, 2021 at 14:24:37 +0000:
> Jacob Gelbman wrote on Wed, Feb 24, 2021 at 01:20:24 -0600:
> > #compdef ctags
> 
> apt-file(1) on Debian stable shows a few more names:
> 
> arduino-ctags: /usr/bin/arduino-ctags
> emacs-bin-common: /usr/bin/ctags.emacs
> emacs-bin-common: /usr/bin/etags.emacs
> exuberant-ctags: /usr/bin/ctags-exuberant
> universal-ctags: /usr/bin/ctags-universal
> xemacs21-bin: /usr/bin/etags.xemacs21
> 
> I assume at least some of these should be added to the #compdef line.  Would
> you do the honours?
> 
> >     "--alias-<lang>=[add a pattern detecting a name, can be used as an alt name for lang]:pattern"
> 
> As Oliver said, literal angle brackets in the option name to be
> completed aren't especially helpful.  In fact, I'll go as far as to say
> I don't want users to run into it in released code.  Please change them.
> 
> You can use _call_program with --list-languages to generate the right set of
> option names dynamically.
> 
> > elif [ "$_ctags_type" = "exuberant" ]; then
> >   arguments=(
> >     "-a[append to tags file]"
> >     "-B[use backward searching patterns (?...?)]"
> >     "-e[output tag file for use with emacs]"
> >     "-f[write tags to specified file. - is stdout]:file:_files"
> 
> Is the argument to the -f option allowed to be pasted to it?  If so, s/-f/-f+/.
> 
> Also, s/:file:/:output file:/.  That part of the string is a user-facing
> message, so the extra detail is helpful.
> 
> Also, you can drop the "- is stdout" part.  The descriptions are only
> a summary of the functionality; they aren't meant to be a complete copy of
> the manual.
> 
> >     "-F[use forward searching patterns (/.../)]"
> >     "-h[specify list of file extensions to be treated as include files]:"
> 
> Write something after the colon.
> 
> >     "-I[a list of tokens to be specifically handled is read from either the command line or the specified file]:"
> 
> The thing in brackets doesn't describe the action of the option.  Please edit.
> 
> >     "-L[a list of input file names is read from the specified file. - is stdin]:file:_files"
> 
> Rephrase in the imperative.
> 
> >     "-R[equivalent to --recurse]"
> 
> This is normally rendered as:
> 
>       '(-r --recurse)'{-R,--recurse}'[description]'
> 
> >     "--fields=[include selected extension fields (flags afmikKlnsStz)]:flags"
> 
> Recommend to move the afmikKlnsStz thing to after the colon, so it'll be
> shown at a more appropriate point.  Also, it would be helpful to display
> descriptions to the flags using, e.g., «compset» (for the leading plus
> sign) followed by «_values -s ''».
> 
> >     "--file-scope=[should tags scoped only for a single file be included in output]:bool:(yes no)"
> >     "--filter=[behave as a filter, reading file names from stdin and writing tags to stdout]:bool:(yes no)"
> >     "--filter-terminator=[specify string to print to stdout following the tags for each file parsed when --filter is enabled]:string"
> >     "--format=[force output of specified tag file format]:level"
> >     "--help[help text]"
> 
> "help text" is just a noun phrase.  Please use complete decsriptions.
> 
> Please use exclusions if needed («'(--foo)--bar[baz]'»).
> 
> >     "--language-force=[force all files to be interpreted using specified language]:language:->language"
> >     "--languages=[restrict files scanned to these comma-separated languages]:language:->languages"
> 
> Can't say I'm a fan of having two states that differ by a single letter,
> but so be it.
> 
> >     "--recurse=[recurse]:bool:(yes no)"
> 
> Fix the bracketed description.
> 
> > _arguments $arguments
> 
> Pass any arguments to _arguments that may be needed (for
> instance, -s).
> 
> > if [[ "$state" = language* ]]; then
> >   local -a languages
> >   languages=(`ctags --list-languages | cut -d" " -f1`)
> 
> Use _call_program and $service.
> 
> >   if [ "$state" = "language" ]; then
> >     _wanted languages expl language compadd $languages
> 
> Don't pass unsanitized command output to a builtin.  In this case,
> «compadd -a languages» would do.
> 
> >   elif [ "$state" = "languages" ]; then
> >     _values -s , languages $languages
> 
> Don't pass unsanitized command output to a builtin.  I don't know the
> fix off the top of my head.
> 
> Thanks for the patch, and especially for adding exubertant and BSD ctags
> support!
> 
> Daniel
> 
> 
> > 
> > 
> > 
> > 
> > > On Feb 23, 2021, at 10:45 PM, Jacob Gelbman <gelbman@gmail.com> wrote:
> > > 
> > > Hey, thanks for looking at the script and adding it to the repo, although I think some of got pasted in wrong. There’s a lot to writing completion functions and I’m still not 100% sure how to do it right.
> > > 
> > >> On Feb 23, 2021, at 3:39 PM, Oliver Kiddle <opk@zsh.org> wrote:
> > >> 
> > >> Jacob Gelbman wrote:
> > >>> I wrote a completion script for the ctags program. Someone might be able to use it:
> > >> 
> > >> Which ctags!?
> > > 
> > > I have Universal Ctags 5.9.0
> > > 
> > >> This doesn't match what I have installed on any of my systems. There
> > >> are multiple implementations of ctags, with it often being just a link
> > >> to etags - for which there is a completion albeit not a well maintained
> > >> one. One of the main reasons, a completion doesn't already exist is
> > >> that it would ideally need to detect the variant and at least have sane
> > >> fallbacks for variants that aren't handled. It could be useful to check
> > >> what the existing _etags is handling - that might be the exhuberant or
> > >> emacs variant.
> > >> 
> > > 
> > > I located a few other ctags on my computers, I have BSD ctags that comes by default on the mac. Exuberant Ctags 5.8. and there’s etags that comes with emacs. I can probably add an if statement based on the output of ctags —version, and modify the function from that. If it’s etags, I’ll just:
> > > 
> > > _comps[ctags]=“_etags”; _etags
> > > 
> > > And exit.
> > > 
> > >> In general, please follow the conventions outlined in
> > >> Etc/completion-style-guide in the zsh source distribution. For example,
> > >> completion functions usually use just 2 spaces for indentation.
> > >> 
> > >>> #compdef ctags
> > >>> 
> > >>> local state
> > >> 
> > >> If you use states, you need to also handle the context which means
> > >> either passing -C to _arguments and setting up $curcontext or declaring
> > >> context local and passing it to later functions like _values.
> > > 
> > > The -C argument and the context/curcontext variables are confusing me, a lot.
> > > 
> > >> 
> > >>>   "--alias-<lang>=[add a pattern detecting a name, can be used as an alt name for lang]:pattern" \
> > >>>   "--input-encoding-<lang>=[specify encoding of the <lang> input files]:encoding" \
> > >>>   "--kinddef-<lang>=[define new kind for <lang>]:kind" \
> > >>>   "--kinds-<lang>=[enable/disable tag kinds for <lang>]:kind" \
> > >> 
> > >> These would not complete especially helpfully. I suspect that <lang> there is
> > >> supposed to be substituted.
> > > 
> > > They’d show up in the menu when you press tab, but if I filled in the actual values, the list would be too long.
> > > 
> > >> 
> > >>> if [ "$state" = "language" ]; then
> > >>>   compadd `ctags --list-languages | cut -d" " -f1`
> > >> 
> > >> It would be nicer to use a description by calling for example, _wanted
> > >> here.
> > > 
> > > I can do that.
> > > 
> > >> 
> > >>> elif [ "$state" = "languages" ]; then
> > >>>   _values -s , "languages" `ctags --list-languages | cut -d" " -f1`
> > >>> fi
> > >> 
> > >> I'd probably use _sequence here as it is smaller and simpler. But
> > >> _values is fine if none of the languages contain characters that need
> > >> quoting from it.
> > > 
> > > This too.
> > > 
> > >> 
> > >> The return status from this function will not be correct in all cases.
> > >> This can have effects like approximate completion being activated
> > >> despite matches having been added by earlier completers. Where states
> > >> are needed, you nearly always need to either save the status from
> > >> _arguments, typically via a ret variable or check $compstate[nmatches]
> > >> on exit.
> > >> 
> > >> Oliver
> > > 
> > 
> > 
> 


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-03-03 20:02         ` Daniel Shahaf
@ 2021-03-03 20:39           ` Jacob Gelbman
  2021-03-03 21:40             ` Peter Stephenson
  2021-03-03 22:06             ` Daniel Shahaf
  2021-03-03 22:08           ` Jacob Gelbman
  1 sibling, 2 replies; 38+ messages in thread
From: Jacob Gelbman @ 2021-03-03 20:39 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: zsh-workers

I got a little bit hung up on one of the points, which was what to do about option names that can include the language such as —alias-<lang>, —extras-<lang>, —fields-<lang>, —input-encoding-<lang>, and many more. If I actually added what the <lang> could be, the listing would be too long to read. I like it to just show the format of the option, just so you can see it in the listing when you press tab, but not overwhelm the output.

I can do the other things though.

> On Mar 3, 2021, at 2:02 PM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> 
> Jacob, ping?  Is a followup patch in the offing?
> 
> As already mentioned, I think some of the review points below are
> release blockers.
> 
> Daniel
> 
> 
> Daniel Shahaf wrote on Wed, Feb 24, 2021 at 14:24:37 +0000:
>> Jacob Gelbman wrote on Wed, Feb 24, 2021 at 01:20:24 -0600:
>>> #compdef ctags
>> 
>> apt-file(1) on Debian stable shows a few more names:
>> 
>> arduino-ctags: /usr/bin/arduino-ctags
>> emacs-bin-common: /usr/bin/ctags.emacs
>> emacs-bin-common: /usr/bin/etags.emacs
>> exuberant-ctags: /usr/bin/ctags-exuberant
>> universal-ctags: /usr/bin/ctags-universal
>> xemacs21-bin: /usr/bin/etags.xemacs21
>> 
>> I assume at least some of these should be added to the #compdef line.  Would
>> you do the honours?
>> 
>>>    "--alias-<lang>=[add a pattern detecting a name, can be used as an alt name for lang]:pattern"
>> 
>> As Oliver said, literal angle brackets in the option name to be
>> completed aren't especially helpful.  In fact, I'll go as far as to say
>> I don't want users to run into it in released code.  Please change them.
>> 
>> You can use _call_program with --list-languages to generate the right set of
>> option names dynamically.
>> 
>>> elif [ "$_ctags_type" = "exuberant" ]; then
>>>  arguments=(
>>>    "-a[append to tags file]"
>>>    "-B[use backward searching patterns (?...?)]"
>>>    "-e[output tag file for use with emacs]"
>>>    "-f[write tags to specified file. - is stdout]:file:_files"
>> 
>> Is the argument to the -f option allowed to be pasted to it?  If so, s/-f/-f+/.
>> 
>> Also, s/:file:/:output file:/.  That part of the string is a user-facing
>> message, so the extra detail is helpful.
>> 
>> Also, you can drop the "- is stdout" part.  The descriptions are only
>> a summary of the functionality; they aren't meant to be a complete copy of
>> the manual.
>> 
>>>    "-F[use forward searching patterns (/.../)]"
>>>    "-h[specify list of file extensions to be treated as include files]:"
>> 
>> Write something after the colon.
>> 
>>>    "-I[a list of tokens to be specifically handled is read from either the command line or the specified file]:"
>> 
>> The thing in brackets doesn't describe the action of the option.  Please edit.
>> 
>>>    "-L[a list of input file names is read from the specified file. - is stdin]:file:_files"
>> 
>> Rephrase in the imperative.
>> 
>>>    "-R[equivalent to --recurse]"
>> 
>> This is normally rendered as:
>> 
>>      '(-r --recurse)'{-R,--recurse}'[description]'
>> 
>>>    "--fields=[include selected extension fields (flags afmikKlnsStz)]:flags"
>> 
>> Recommend to move the afmikKlnsStz thing to after the colon, so it'll be
>> shown at a more appropriate point.  Also, it would be helpful to display
>> descriptions to the flags using, e.g., «compset» (for the leading plus
>> sign) followed by «_values -s ''».
>> 
>>>    "--file-scope=[should tags scoped only for a single file be included in output]:bool:(yes no)"
>>>    "--filter=[behave as a filter, reading file names from stdin and writing tags to stdout]:bool:(yes no)"
>>>    "--filter-terminator=[specify string to print to stdout following the tags for each file parsed when --filter is enabled]:string"
>>>    "--format=[force output of specified tag file format]:level"
>>>    "--help[help text]"
>> 
>> "help text" is just a noun phrase.  Please use complete decsriptions.
>> 
>> Please use exclusions if needed («'(--foo)--bar[baz]'»).
>> 
>>>    "--language-force=[force all files to be interpreted using specified language]:language:->language"
>>>    "--languages=[restrict files scanned to these comma-separated languages]:language:->languages"
>> 
>> Can't say I'm a fan of having two states that differ by a single letter,
>> but so be it.
>> 
>>>    "--recurse=[recurse]:bool:(yes no)"
>> 
>> Fix the bracketed description.
>> 
>>> _arguments $arguments
>> 
>> Pass any arguments to _arguments that may be needed (for
>> instance, -s).
>> 
>>> if [[ "$state" = language* ]]; then
>>>  local -a languages
>>>  languages=(`ctags --list-languages | cut -d" " -f1`)
>> 
>> Use _call_program and $service.
>> 
>>>  if [ "$state" = "language" ]; then
>>>    _wanted languages expl language compadd $languages
>> 
>> Don't pass unsanitized command output to a builtin.  In this case,
>> «compadd -a languages» would do.
>> 
>>>  elif [ "$state" = "languages" ]; then
>>>    _values -s , languages $languages
>> 
>> Don't pass unsanitized command output to a builtin.  I don't know the
>> fix off the top of my head.
>> 
>> Thanks for the patch, and especially for adding exubertant and BSD ctags
>> support!
>> 
>> Daniel
>> 
>> 
>>> 
>>> 
>>> 
>>> 
>>>> On Feb 23, 2021, at 10:45 PM, Jacob Gelbman <gelbman@gmail.com> wrote:
>>>> 
>>>> Hey, thanks for looking at the script and adding it to the repo, although I think some of got pasted in wrong. There’s a lot to writing completion functions and I’m still not 100% sure how to do it right.
>>>> 
>>>>> On Feb 23, 2021, at 3:39 PM, Oliver Kiddle <opk@zsh.org> wrote:
>>>>> 
>>>>> Jacob Gelbman wrote:
>>>>>> I wrote a completion script for the ctags program. Someone might be able to use it:
>>>>> 
>>>>> Which ctags!?
>>>> 
>>>> I have Universal Ctags 5.9.0
>>>> 
>>>>> This doesn't match what I have installed on any of my systems. There
>>>>> are multiple implementations of ctags, with it often being just a link
>>>>> to etags - for which there is a completion albeit not a well maintained
>>>>> one. One of the main reasons, a completion doesn't already exist is
>>>>> that it would ideally need to detect the variant and at least have sane
>>>>> fallbacks for variants that aren't handled. It could be useful to check
>>>>> what the existing _etags is handling - that might be the exhuberant or
>>>>> emacs variant.
>>>>> 
>>>> 
>>>> I located a few other ctags on my computers, I have BSD ctags that comes by default on the mac. Exuberant Ctags 5.8. and there’s etags that comes with emacs. I can probably add an if statement based on the output of ctags —version, and modify the function from that. If it’s etags, I’ll just:
>>>> 
>>>> _comps[ctags]=“_etags”; _etags
>>>> 
>>>> And exit.
>>>> 
>>>>> In general, please follow the conventions outlined in
>>>>> Etc/completion-style-guide in the zsh source distribution. For example,
>>>>> completion functions usually use just 2 spaces for indentation.
>>>>> 
>>>>>> #compdef ctags
>>>>>> 
>>>>>> local state
>>>>> 
>>>>> If you use states, you need to also handle the context which means
>>>>> either passing -C to _arguments and setting up $curcontext or declaring
>>>>> context local and passing it to later functions like _values.
>>>> 
>>>> The -C argument and the context/curcontext variables are confusing me, a lot.
>>>> 
>>>>> 
>>>>>>  "--alias-<lang>=[add a pattern detecting a name, can be used as an alt name for lang]:pattern" \
>>>>>>  "--input-encoding-<lang>=[specify encoding of the <lang> input files]:encoding" \
>>>>>>  "--kinddef-<lang>=[define new kind for <lang>]:kind" \
>>>>>>  "--kinds-<lang>=[enable/disable tag kinds for <lang>]:kind" \
>>>>> 
>>>>> These would not complete especially helpfully. I suspect that <lang> there is
>>>>> supposed to be substituted.
>>>> 
>>>> They’d show up in the menu when you press tab, but if I filled in the actual values, the list would be too long.
>>>> 
>>>>> 
>>>>>> if [ "$state" = "language" ]; then
>>>>>>  compadd `ctags --list-languages | cut -d" " -f1`
>>>>> 
>>>>> It would be nicer to use a description by calling for example, _wanted
>>>>> here.
>>>> 
>>>> I can do that.
>>>> 
>>>>> 
>>>>>> elif [ "$state" = "languages" ]; then
>>>>>>  _values -s , "languages" `ctags --list-languages | cut -d" " -f1`
>>>>>> fi
>>>>> 
>>>>> I'd probably use _sequence here as it is smaller and simpler. But
>>>>> _values is fine if none of the languages contain characters that need
>>>>> quoting from it.
>>>> 
>>>> This too.
>>>> 
>>>>> 
>>>>> The return status from this function will not be correct in all cases.
>>>>> This can have effects like approximate completion being activated
>>>>> despite matches having been added by earlier completers. Where states
>>>>> are needed, you nearly always need to either save the status from
>>>>> _arguments, typically via a ret variable or check $compstate[nmatches]
>>>>> on exit.
>>>>> 
>>>>> Oliver
>>>> 
>>> 
>>> 
>> 



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-03-03 20:39           ` Jacob Gelbman
@ 2021-03-03 21:40             ` Peter Stephenson
  2021-03-03 22:06             ` Daniel Shahaf
  1 sibling, 0 replies; 38+ messages in thread
From: Peter Stephenson @ 2021-03-03 21:40 UTC (permalink / raw)
  To: Jacob Gelbman, zsh-workers

On Wed, 2021-03-03 at 14:39 -0600, Jacob Gelbman wrote:
> I got a little bit hung up on one of the points, which was what to do
> about option names that can include the language such as
> —alias-<lang>, —extras-<lang>, —fields-<lang>, —input-encoding-<lang>,
> and many more. If I actually added what the <lang> could be, the
> listing would be too long to read. I like it to just show the format
> of the option, just so you can see it in the listing when you press
> tab, but not overwhelm the output.

I suspect this is over the over the top, but I'll send it anyway in case
there are some hints here...

It's starting to get complicated, but you could treat the <lang> as an
argument to complete until there's a non-zero string there, then
treat -alias-blah matched from the command line as the option.  That's
significantly more work, though, well beyond just a first pass using
_arguments, but it is doable.

With the version I have (Emacs), you can generate a list by running a
function like the one below.  That would need a version guard and also
combining with the usual _call_program set up you'll see in a lot of existing
functions.  It doesn't work directly for the case you're after (though it
could complete the language for the Emacs version) because you're talking
about a different version of ctags, but it might give some ideas.

pws

_ctags_languages() {
  integer found
  local -a match mbegin mend
  ctags --help | while IFS= read -r line; do
    [[ $line = *"supported languages"* ]] && found=1
    if (( found )); then
      if [[ $line = (#b)[[:space:]]##([^[:space:]]##)* ]]; then
        print $match[1]
        found=2
      elif (( found == 2 )); then
        found=0
      fi
    fi
 done
}




^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-03-03 20:39           ` Jacob Gelbman
  2021-03-03 21:40             ` Peter Stephenson
@ 2021-03-03 22:06             ` Daniel Shahaf
  1 sibling, 0 replies; 38+ messages in thread
From: Daniel Shahaf @ 2021-03-03 22:06 UTC (permalink / raw)
  To: Jacob Gelbman; +Cc: zsh-workers

Jacob Gelbman wrote on Wed, 03 Mar 2021 20:39 +00:00:
> I got a little bit hung up on one of the points, which was what to do 
> about option names that can include the language such as —alias-<lang>, 
> —extras-<lang>, —fields-<lang>, —input-encoding-<lang>, and many more. 
> If I actually added what the <lang> could be, the listing would be too 
> long to read.

If all the --extras-{foo,bar,baz} options have the same description,
they'll be grouped in the output, which would make it easier to read.

Could those options be put in a different group than the other options?
Compare the output of «git <TAB>» with «zstyle ':completion:*' group-name '' &&
zstyle ':completion:*' format '> %d'» in effect.  (That output can also
be "paged" by setting the tag-order style appropriately.)

Should setting the «verbose»/«extra-verbose» styles count as opting in
to "too long to read" listings?  (I wouldn't normally propose knobs, but
these two already exist.)

How about declaring a repeatable option called «--extras-» that takes
a pasted argument in the same word:

_f() {
  if compset -P '(#b)--extras-([^-]*)=*' ; then
    compadd - "extras for $match[1]";
  else
    _arguments : '*--extras--[foo]:bar: compadd -S "" C= python= zsh='
  fi
}
compdef _f f

The else branch uses «-S ""» to avoid auto-adding a space (works with
menu selection, at least).  The if branch could parse `ctags --list-kinds`,
etc., to offer completions specific to the language.

The snippet above doesn't handle the case «ctags --extras-C <TAB>».

> I like it to just show the format of the option, just so you can see
> it in the listing when you press tab, but not overwhelm the output.

I see your point, but it means the command-line after tabbing will read
«ctags --extras-\<lang\>=<CURSOR>».  That doesn't seem user friendly at all.

> I can do the other things though.

Wonderful.  Looking forward to the patch, then.  (You needn't wait until
the --foo-<lang> question is decided on.)

Cheers,

Daniel

> > On Mar 3, 2021, at 2:02 PM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > 
> > Jacob, ping?  Is a followup patch in the offing?
> > 
> > As already mentioned, I think some of the review points below are
> > release blockers.
> > 
> > Daniel
> > 
> > 
> > Daniel Shahaf wrote on Wed, Feb 24, 2021 at 14:24:37 +0000:
> >> Jacob Gelbman wrote on Wed, Feb 24, 2021 at 01:20:24 -0600:
> >>> #compdef ctags
> >> 
> >> apt-file(1) on Debian stable shows a few more names:
> >> 
> >> arduino-ctags: /usr/bin/arduino-ctags
> >> emacs-bin-common: /usr/bin/ctags.emacs
> >> emacs-bin-common: /usr/bin/etags.emacs
> >> exuberant-ctags: /usr/bin/ctags-exuberant
> >> universal-ctags: /usr/bin/ctags-universal
> >> xemacs21-bin: /usr/bin/etags.xemacs21
> >> 
> >> I assume at least some of these should be added to the #compdef line.  Would
> >> you do the honours?
> >> 
> >>>    "--alias-<lang>=[add a pattern detecting a name, can be used as an alt name for lang]:pattern"
> >> 
> >> As Oliver said, literal angle brackets in the option name to be
> >> completed aren't especially helpful.  In fact, I'll go as far as to say
> >> I don't want users to run into it in released code.  Please change them.
> >> 
> >> You can use _call_program with --list-languages to generate the right set of
> >> option names dynamically.
> >> 
> >>> elif [ "$_ctags_type" = "exuberant" ]; then
> >>>  arguments=(
> >>>    "-a[append to tags file]"
> >>>    "-B[use backward searching patterns (?...?)]"
> >>>    "-e[output tag file for use with emacs]"
> >>>    "-f[write tags to specified file. - is stdout]:file:_files"
> >> 
> >> Is the argument to the -f option allowed to be pasted to it?  If so, s/-f/-f+/.
> >> 
> >> Also, s/:file:/:output file:/.  That part of the string is a user-facing
> >> message, so the extra detail is helpful.
> >> 
> >> Also, you can drop the "- is stdout" part.  The descriptions are only
> >> a summary of the functionality; they aren't meant to be a complete copy of
> >> the manual.
> >> 
> >>>    "-F[use forward searching patterns (/.../)]"
> >>>    "-h[specify list of file extensions to be treated as include files]:"
> >> 
> >> Write something after the colon.
> >> 
> >>>    "-I[a list of tokens to be specifically handled is read from either the command line or the specified file]:"
> >> 
> >> The thing in brackets doesn't describe the action of the option.  Please edit.
> >> 
> >>>    "-L[a list of input file names is read from the specified file. - is stdin]:file:_files"
> >> 
> >> Rephrase in the imperative.
> >> 
> >>>    "-R[equivalent to --recurse]"
> >> 
> >> This is normally rendered as:
> >> 
> >>      '(-r --recurse)'{-R,--recurse}'[description]'
> >> 
> >>>    "--fields=[include selected extension fields (flags afmikKlnsStz)]:flags"
> >> 
> >> Recommend to move the afmikKlnsStz thing to after the colon, so it'll be
> >> shown at a more appropriate point.  Also, it would be helpful to display
> >> descriptions to the flags using, e.g., «compset» (for the leading plus
> >> sign) followed by «_values -s ''».
> >> 
> >>>    "--file-scope=[should tags scoped only for a single file be included in output]:bool:(yes no)"
> >>>    "--filter=[behave as a filter, reading file names from stdin and writing tags to stdout]:bool:(yes no)"
> >>>    "--filter-terminator=[specify string to print to stdout following the tags for each file parsed when --filter is enabled]:string"
> >>>    "--format=[force output of specified tag file format]:level"
> >>>    "--help[help text]"
> >> 
> >> "help text" is just a noun phrase.  Please use complete decsriptions.
> >> 
> >> Please use exclusions if needed («'(--foo)--bar[baz]'»).
> >> 
> >>>    "--language-force=[force all files to be interpreted using specified language]:language:->language"
> >>>    "--languages=[restrict files scanned to these comma-separated languages]:language:->languages"
> >> 
> >> Can't say I'm a fan of having two states that differ by a single letter,
> >> but so be it.
> >> 
> >>>    "--recurse=[recurse]:bool:(yes no)"
> >> 
> >> Fix the bracketed description.
> >> 
> >>> _arguments $arguments
> >> 
> >> Pass any arguments to _arguments that may be needed (for
> >> instance, -s).
> >> 
> >>> if [[ "$state" = language* ]]; then
> >>>  local -a languages
> >>>  languages=(`ctags --list-languages | cut -d" " -f1`)
> >> 
> >> Use _call_program and $service.
> >> 
> >>>  if [ "$state" = "language" ]; then
> >>>    _wanted languages expl language compadd $languages
> >> 
> >> Don't pass unsanitized command output to a builtin.  In this case,
> >> «compadd -a languages» would do.
> >> 
> >>>  elif [ "$state" = "languages" ]; then
> >>>    _values -s , languages $languages
> >> 
> >> Don't pass unsanitized command output to a builtin.  I don't know the
> >> fix off the top of my head.
> >> 
> >> Thanks for the patch, and especially for adding exubertant and BSD ctags
> >> support!
> >> 
> >> Daniel
> >> 
> >> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>>> On Feb 23, 2021, at 10:45 PM, Jacob Gelbman <gelbman@gmail.com> wrote:
> >>>> 
> >>>> Hey, thanks for looking at the script and adding it to the repo, although I think some of got pasted in wrong. There’s a lot to writing completion functions and I’m still not 100% sure how to do it right.
> >>>> 
> >>>>> On Feb 23, 2021, at 3:39 PM, Oliver Kiddle <opk@zsh.org> wrote:
> >>>>> 
> >>>>> Jacob Gelbman wrote:
> >>>>>> I wrote a completion script for the ctags program. Someone might be able to use it:
> >>>>> 
> >>>>> Which ctags!?
> >>>> 
> >>>> I have Universal Ctags 5.9.0
> >>>> 
> >>>>> This doesn't match what I have installed on any of my systems. There
> >>>>> are multiple implementations of ctags, with it often being just a link
> >>>>> to etags - for which there is a completion albeit not a well maintained
> >>>>> one. One of the main reasons, a completion doesn't already exist is
> >>>>> that it would ideally need to detect the variant and at least have sane
> >>>>> fallbacks for variants that aren't handled. It could be useful to check
> >>>>> what the existing _etags is handling - that might be the exhuberant or
> >>>>> emacs variant.
> >>>>> 
> >>>> 
> >>>> I located a few other ctags on my computers, I have BSD ctags that comes by default on the mac. Exuberant Ctags 5.8. and there’s etags that comes with emacs. I can probably add an if statement based on the output of ctags —version, and modify the function from that. If it’s etags, I’ll just:
> >>>> 
> >>>> _comps[ctags]=“_etags”; _etags
> >>>> 
> >>>> And exit.
> >>>> 
> >>>>> In general, please follow the conventions outlined in
> >>>>> Etc/completion-style-guide in the zsh source distribution. For example,
> >>>>> completion functions usually use just 2 spaces for indentation.
> >>>>> 
> >>>>>> #compdef ctags
> >>>>>> 
> >>>>>> local state
> >>>>> 
> >>>>> If you use states, you need to also handle the context which means
> >>>>> either passing -C to _arguments and setting up $curcontext or declaring
> >>>>> context local and passing it to later functions like _values.
> >>>> 
> >>>> The -C argument and the context/curcontext variables are confusing me, a lot.
> >>>> 
> >>>>> 
> >>>>>>  "--alias-<lang>=[add a pattern detecting a name, can be used as an alt name for lang]:pattern" \
> >>>>>>  "--input-encoding-<lang>=[specify encoding of the <lang> input files]:encoding" \
> >>>>>>  "--kinddef-<lang>=[define new kind for <lang>]:kind" \
> >>>>>>  "--kinds-<lang>=[enable/disable tag kinds for <lang>]:kind" \
> >>>>> 
> >>>>> These would not complete especially helpfully. I suspect that <lang> there is
> >>>>> supposed to be substituted.
> >>>> 
> >>>> They’d show up in the menu when you press tab, but if I filled in the actual values, the list would be too long.
> >>>> 
> >>>>> 
> >>>>>> if [ "$state" = "language" ]; then
> >>>>>>  compadd `ctags --list-languages | cut -d" " -f1`
> >>>>> 
> >>>>> It would be nicer to use a description by calling for example, _wanted
> >>>>> here.
> >>>> 
> >>>> I can do that.
> >>>> 
> >>>>> 
> >>>>>> elif [ "$state" = "languages" ]; then
> >>>>>>  _values -s , "languages" `ctags --list-languages | cut -d" " -f1`
> >>>>>> fi
> >>>>> 
> >>>>> I'd probably use _sequence here as it is smaller and simpler. But
> >>>>> _values is fine if none of the languages contain characters that need
> >>>>> quoting from it.
> >>>> 
> >>>> This too.
> >>>> 
> >>>>> 
> >>>>> The return status from this function will not be correct in all cases.
> >>>>> This can have effects like approximate completion being activated
> >>>>> despite matches having been added by earlier completers. Where states
> >>>>> are needed, you nearly always need to either save the status from
> >>>>> _arguments, typically via a ret variable or check $compstate[nmatches]
> >>>>> on exit.
> >>>>> 
> >>>>> Oliver
> >>>> 
> >>> 
> >>> 
> >> 
> 
> 
>


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-03-03 20:02         ` Daniel Shahaf
  2021-03-03 20:39           ` Jacob Gelbman
@ 2021-03-03 22:08           ` Jacob Gelbman
  2021-03-03 23:28             ` Aaron Schrab
  2021-03-03 23:35             ` Daniel Shahaf
  1 sibling, 2 replies; 38+ messages in thread
From: Jacob Gelbman @ 2021-03-03 22:08 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: zsh-workers

I don’t want to get too fancy or complicated with this completion script, I just want to provide something helpful for 90% of the time, and I don’t mind it showing a completion for an option that is meant to be modified. That said, if someone else wants to make it better in some way, that’s all good. Just I don’t think it should add all the options that it could be because it would make the output too long to read. I can’t think of another command that has options like this, maybe head or tail, which take an option like -<number>, like -5, the completion script just ignores options like this, because the command has a -n <number>, so that’s just as good. kill -<signal>, like kill -INT, is kind of similar, but listing all those options doesn’t result in output that’s too long.

> On Mar 3, 2021, at 2:02 PM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> 
> Jacob, ping?  Is a followup patch in the offing?
> 
> As already mentioned, I think some of the review points below are
> release blockers.
> 
> Daniel
> 
> 
> Daniel Shahaf wrote on Wed, Feb 24, 2021 at 14:24:37 +0000:
>> Jacob Gelbman wrote on Wed, Feb 24, 2021 at 01:20:24 -0600:
>>> #compdef ctags
>> 
>> apt-file(1) on Debian stable shows a few more names:
>> 
>> arduino-ctags: /usr/bin/arduino-ctags
>> emacs-bin-common: /usr/bin/ctags.emacs
>> emacs-bin-common: /usr/bin/etags.emacs
>> exuberant-ctags: /usr/bin/ctags-exuberant
>> universal-ctags: /usr/bin/ctags-universal
>> xemacs21-bin: /usr/bin/etags.xemacs21
>> 
>> I assume at least some of these should be added to the #compdef line.  Would
>> you do the honours?
>> 
>>>    "--alias-<lang>=[add a pattern detecting a name, can be used as an alt name for lang]:pattern"
>> 
>> As Oliver said, literal angle brackets in the option name to be
>> completed aren't especially helpful.  In fact, I'll go as far as to say
>> I don't want users to run into it in released code.  Please change them.
>> 
>> You can use _call_program with --list-languages to generate the right set of
>> option names dynamically.
>> 
>>> elif [ "$_ctags_type" = "exuberant" ]; then
>>>  arguments=(
>>>    "-a[append to tags file]"
>>>    "-B[use backward searching patterns (?...?)]"
>>>    "-e[output tag file for use with emacs]"
>>>    "-f[write tags to specified file. - is stdout]:file:_files"
>> 
>> Is the argument to the -f option allowed to be pasted to it?  If so, s/-f/-f+/.
>> 
>> Also, s/:file:/:output file:/.  That part of the string is a user-facing
>> message, so the extra detail is helpful.
>> 
>> Also, you can drop the "- is stdout" part.  The descriptions are only
>> a summary of the functionality; they aren't meant to be a complete copy of
>> the manual.
>> 
>>>    "-F[use forward searching patterns (/.../)]"
>>>    "-h[specify list of file extensions to be treated as include files]:"
>> 
>> Write something after the colon.
>> 
>>>    "-I[a list of tokens to be specifically handled is read from either the command line or the specified file]:"
>> 
>> The thing in brackets doesn't describe the action of the option.  Please edit.
>> 
>>>    "-L[a list of input file names is read from the specified file. - is stdin]:file:_files"
>> 
>> Rephrase in the imperative.
>> 
>>>    "-R[equivalent to --recurse]"
>> 
>> This is normally rendered as:
>> 
>>      '(-r --recurse)'{-R,--recurse}'[description]'
>> 
>>>    "--fields=[include selected extension fields (flags afmikKlnsStz)]:flags"
>> 
>> Recommend to move the afmikKlnsStz thing to after the colon, so it'll be
>> shown at a more appropriate point.  Also, it would be helpful to display
>> descriptions to the flags using, e.g., «compset» (for the leading plus
>> sign) followed by «_values -s ''».
>> 
>>>    "--file-scope=[should tags scoped only for a single file be included in output]:bool:(yes no)"
>>>    "--filter=[behave as a filter, reading file names from stdin and writing tags to stdout]:bool:(yes no)"
>>>    "--filter-terminator=[specify string to print to stdout following the tags for each file parsed when --filter is enabled]:string"
>>>    "--format=[force output of specified tag file format]:level"
>>>    "--help[help text]"
>> 
>> "help text" is just a noun phrase.  Please use complete decsriptions.
>> 
>> Please use exclusions if needed («'(--foo)--bar[baz]'»).
>> 
>>>    "--language-force=[force all files to be interpreted using specified language]:language:->language"
>>>    "--languages=[restrict files scanned to these comma-separated languages]:language:->languages"
>> 
>> Can't say I'm a fan of having two states that differ by a single letter,
>> but so be it.
>> 
>>>    "--recurse=[recurse]:bool:(yes no)"
>> 
>> Fix the bracketed description.
>> 
>>> _arguments $arguments
>> 
>> Pass any arguments to _arguments that may be needed (for
>> instance, -s).
>> 
>>> if [[ "$state" = language* ]]; then
>>>  local -a languages
>>>  languages=(`ctags --list-languages | cut -d" " -f1`)
>> 
>> Use _call_program and $service.
>> 
>>>  if [ "$state" = "language" ]; then
>>>    _wanted languages expl language compadd $languages
>> 
>> Don't pass unsanitized command output to a builtin.  In this case,
>> «compadd -a languages» would do.
>> 
>>>  elif [ "$state" = "languages" ]; then
>>>    _values -s , languages $languages
>> 
>> Don't pass unsanitized command output to a builtin.  I don't know the
>> fix off the top of my head.
>> 
>> Thanks for the patch, and especially for adding exubertant and BSD ctags
>> support!
>> 
>> Daniel
>> 
>> 
>>> 
>>> 
>>> 
>>> 
>>>> On Feb 23, 2021, at 10:45 PM, Jacob Gelbman <gelbman@gmail.com> wrote:
>>>> 
>>>> Hey, thanks for looking at the script and adding it to the repo, although I think some of got pasted in wrong. There’s a lot to writing completion functions and I’m still not 100% sure how to do it right.
>>>> 
>>>>> On Feb 23, 2021, at 3:39 PM, Oliver Kiddle <opk@zsh.org> wrote:
>>>>> 
>>>>> Jacob Gelbman wrote:
>>>>>> I wrote a completion script for the ctags program. Someone might be able to use it:
>>>>> 
>>>>> Which ctags!?
>>>> 
>>>> I have Universal Ctags 5.9.0
>>>> 
>>>>> This doesn't match what I have installed on any of my systems. There
>>>>> are multiple implementations of ctags, with it often being just a link
>>>>> to etags - for which there is a completion albeit not a well maintained
>>>>> one. One of the main reasons, a completion doesn't already exist is
>>>>> that it would ideally need to detect the variant and at least have sane
>>>>> fallbacks for variants that aren't handled. It could be useful to check
>>>>> what the existing _etags is handling - that might be the exhuberant or
>>>>> emacs variant.
>>>>> 
>>>> 
>>>> I located a few other ctags on my computers, I have BSD ctags that comes by default on the mac. Exuberant Ctags 5.8. and there’s etags that comes with emacs. I can probably add an if statement based on the output of ctags —version, and modify the function from that. If it’s etags, I’ll just:
>>>> 
>>>> _comps[ctags]=“_etags”; _etags
>>>> 
>>>> And exit.
>>>> 
>>>>> In general, please follow the conventions outlined in
>>>>> Etc/completion-style-guide in the zsh source distribution. For example,
>>>>> completion functions usually use just 2 spaces for indentation.
>>>>> 
>>>>>> #compdef ctags
>>>>>> 
>>>>>> local state
>>>>> 
>>>>> If you use states, you need to also handle the context which means
>>>>> either passing -C to _arguments and setting up $curcontext or declaring
>>>>> context local and passing it to later functions like _values.
>>>> 
>>>> The -C argument and the context/curcontext variables are confusing me, a lot.
>>>> 
>>>>> 
>>>>>>  "--alias-<lang>=[add a pattern detecting a name, can be used as an alt name for lang]:pattern" \
>>>>>>  "--input-encoding-<lang>=[specify encoding of the <lang> input files]:encoding" \
>>>>>>  "--kinddef-<lang>=[define new kind for <lang>]:kind" \
>>>>>>  "--kinds-<lang>=[enable/disable tag kinds for <lang>]:kind" \
>>>>> 
>>>>> These would not complete especially helpfully. I suspect that <lang> there is
>>>>> supposed to be substituted.
>>>> 
>>>> They’d show up in the menu when you press tab, but if I filled in the actual values, the list would be too long.
>>>> 
>>>>> 
>>>>>> if [ "$state" = "language" ]; then
>>>>>>  compadd `ctags --list-languages | cut -d" " -f1`
>>>>> 
>>>>> It would be nicer to use a description by calling for example, _wanted
>>>>> here.
>>>> 
>>>> I can do that.
>>>> 
>>>>> 
>>>>>> elif [ "$state" = "languages" ]; then
>>>>>>  _values -s , "languages" `ctags --list-languages | cut -d" " -f1`
>>>>>> fi
>>>>> 
>>>>> I'd probably use _sequence here as it is smaller and simpler. But
>>>>> _values is fine if none of the languages contain characters that need
>>>>> quoting from it.
>>>> 
>>>> This too.
>>>> 
>>>>> 
>>>>> The return status from this function will not be correct in all cases.
>>>>> This can have effects like approximate completion being activated
>>>>> despite matches having been added by earlier completers. Where states
>>>>> are needed, you nearly always need to either save the status from
>>>>> _arguments, typically via a ret variable or check $compstate[nmatches]
>>>>> on exit.
>>>>> 
>>>>> Oliver
>>>> 
>>> 
>>> 
>> 



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-03-03 22:08           ` Jacob Gelbman
@ 2021-03-03 23:28             ` Aaron Schrab
  2021-03-03 23:43               ` Daniel Shahaf
  2021-03-03 23:35             ` Daniel Shahaf
  1 sibling, 1 reply; 38+ messages in thread
From: Aaron Schrab @ 2021-03-03 23:28 UTC (permalink / raw)
  To: Jacob Gelbman; +Cc: Daniel Shahaf, zsh-workers

At 16:08 -0600 03 Mar 2021, Jacob Gelbman <gelbman@gmail.com> wrote:
>Just I don’t think it should add all the options that it could be 
>because it would make the output too long to read. I can’t think of 
>another command that has options like this,

One example would be ack (AKA ack-grep) which also has options for quite 
a few programming languages.  Although in its case there isn't any 
common prefix for the options to turn on a language; it's just options 
like `ack --python`.  It also supports options like `ack --nopython` to 
disable languages.

The completion for that *does* include all of those options. Yes, all of 
that does make it quite verbose, but that can also be the case even 
without that type of dynamic option names (I'm mainly thinking of curl 
here).  I still think that having the completion options actually usable 
as-is is still better than requiring the user to edit the completion 
results. It would likely be even better in this case if the language 
portion could be treated more as the argument to an option, and so the 
language list would only be presented after the prefix was already 
selected.

But I'd also say that even a completion script which generates those 
options in need of editing would still be an improvement over nothing.


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-03-03 22:08           ` Jacob Gelbman
  2021-03-03 23:28             ` Aaron Schrab
@ 2021-03-03 23:35             ` Daniel Shahaf
  1 sibling, 0 replies; 38+ messages in thread
From: Daniel Shahaf @ 2021-03-03 23:35 UTC (permalink / raw)
  To: Jacob Gelbman; +Cc: zsh-workers

Jacob Gelbman wrote on Wed, 03 Mar 2021 22:08 +00:00:
> That said, if someone else wants to make it better in some 
> way, that’s all good. Just I don’t think it should add all the options 
> that it could be because it would make the output too long to read.

You already made this argument in a previous email and pws and I replied
to it there.


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-03-03 23:28             ` Aaron Schrab
@ 2021-03-03 23:43               ` Daniel Shahaf
  0 siblings, 0 replies; 38+ messages in thread
From: Daniel Shahaf @ 2021-03-03 23:43 UTC (permalink / raw)
  To: Aaron Schrab, Jacob Gelbman; +Cc: zsh-workers

Aaron Schrab wrote on Wed, 03 Mar 2021 23:28 +00:00:
> The completion for that *does* include all of those options. Yes, all of 
> that does make it quite verbose, but that can also be the case even 
> without that type of dynamic option names (I'm mainly thinking of curl 
> here).

FWIW:


% git -c <TAB>
zsh: do you wish to see all 288 possibilities (73 lines)? 

That's basicaly a hardcoded list, though I think it does look in `git
config --list` too for wildcard instances and in-house options.


% rsync --<TAB>
zsh: do you wish to see all 450 possibilities (151 lines)? 

Static list.


% git co <TAB>
zsh: do you wish to see all 605 possibilities (165 lines)? 

Based on repository contents.  Uses tags for sectioning.


% curl -<TAB>
zsh: do you wish to see all 661 possibilities (221 lines)? 

Static list.


% gcc -<TAB>
zsh: do you wish to see all 2495 possibilities (833 lines)? 

Static list.  It's long because all -Wfoo/-fbar/-mbaz arguments are
treated as first-class options.  I suppose that may want to be changed.

> I still think that having the completion options actually usable 
> as-is is still better than requiring the user to edit the completion 
> results. It would likely be even better in this case if the language 
> portion could be treated more as the argument to an option, and so the 
> language list would only be presented after the prefix was already 
> selected.

That's what pws proposed and I independently implemented.  Try the _f
function I posted.

There's --<lang>-foo options too (with the replaceable part first), and
there's «--foo-<lang> bar» as two words, but that's solvable.

> But I'd also say that even a completion script which generates those 
> options in need of editing would still be an improvement over nothing.

*nod*

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-02-24 14:24       ` Daniel Shahaf
  2021-02-24 18:58         ` Jacob Gelbman
  2021-03-03 20:02         ` Daniel Shahaf
@ 2021-03-07 19:18         ` Jacob Gelbman
  2021-03-07 21:42           ` Daniel Shahaf
  2 siblings, 1 reply; 38+ messages in thread
From: Jacob Gelbman @ 2021-03-07 19:18 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: zsh-workers

[-- Attachment #1: Type: text/plain, Size: 26 bytes --]

I attached the new script.

[-- Attachment #2: ctags.txt --]
[-- Type: text/plain, Size: 13143 bytes --]

#compdef ctags arduino-ctags ctags-exuberant ctags-universal

local context state line expl
local -A opt_args
local -a arguments

if [ -z "$_ctags_type" ]; then
  local output=`ctags --version 2>&1`
  if [[ "$output" = *Universal\ Ctags* ]]; then
    _ctags_type="universal"
  elif [[ "$output" = *Exuberant\ Ctags* ]]; then
    _ctags_type="exuberant"
  elif [[ "$output" = *usage:\ ctags* ]]; then
    _ctags_type="bsd"
  elif [[ "$output" = *Emacs* ]]; then
    _ctags_type="etags"
  else
    _ctags_type="universal"
  fi
fi

if [ "$_ctags_type" = "etags" ]; then
  _etags
  return $?
fi

_ctags_languages() {
  _call_program languages $service --list-languages | cut -d" " -f1
}

if [[ "$PREFIX" = --alias-*=* ]]; then
  _message pattern
  return 1
elif [[ "$PREFIX" = --extras-*=* ]]; then
  _message flags
  return 1
elif [[ "$PREFIX" = --fields-*=* ]]; then
  _message flags
  return 1
elif [[ "$PREFIX" = --input-encoding-*=* ]]; then
  _message encoding
  return 1
elif [[ "$PREFIX" = --kinddef-*=* ]]; then
  _message kind
  return 1
elif [[ "$PREFIX" = --kinds-*=* ]]; then
  _message kind
  return 1
elif [[ "$PREFIX" = --map-*=* ]]; then
  _message pattern
  return 1
elif [[ "$PREFIX" = --mline-regex-*=* ]]; then
  _message pattern
  return 1
elif [[ "$PREFIX" = --param-*=* ]]; then
  _message argument
  return 1
elif [[ "$PREFIX" = --regex-*=* ]]; then
  _message pattern
  return 1
elif [[ "$PREFIX" = --roles-*.*=* ]] then
  _message role
  return 1
elif [[ "$PREFIX" = --roles-*.* ]] then
  _message kind
  return 1
fi

if [ "$_ctags_type" = "universal" ]; then
  arguments=(
    "-a[append to tags file]"
    "-B[use backward searching patterns (?...?)]"
    "-D[give definition for macro]:macro definition:"
    "-e[output tag file for use with emacs]"
    {-f+,-o+}"[write tags to specified file]:output file:_files"
    "-F[use forward searching patterns (/.../)]"
    "-h[specify a list of file extensions to be treated as include files]:extensions"
    "-I[specify a list of tokens to be specially handled]:identifier list"
    "-L[read a list of input file names from the specified file]:input file:_files"
    "-n[equivalent to --excmd=number]"
    "-N[equivalent to --excmd=pattern]"
    "(--recurse -R)--recurse=-[search files recursively]::bool:(yes no)"
    "(--recurse -R)-R[search files recursively]"
    "-u[equivalent to --sort=no]"
    "-x[print a tabular cross reference file to stdout]"
    "--alias--[add a pattern detecting a name, can be used as an alt name for lang]:language:->languageequals"
    "--append=-[should tags be appended to existing tag file]:bool:(yes no)"
    "--etags-include=-[include reference to file in emacs style tag file]:file:_files"
    "--exclude=-[exclude files and directories matching pattern]:pattern"
    "--exclude-exception=-[don't exclude files and directories matching pattern even if they match the pattern specified with --exclude]:pattern"
    "--excmd=-[uses the specified type of ex command to locate tags]:ex command type:(number pattern mix combine)"
    "--extras=-[include extra tag entries for selected information]:flags (fFgpqrs)"
    "--extras--[include <lang> own extra tag entries for selected information]:language:->languageequals"
    "--fields=-[include selected extension fields]:flags (aCeEfFikKlmnNpPrRsStxzZ)"
    "--fields--[include selected <lang> own extension fields]:language:->languageequals"
    "--filter=-[behave as a filter, reading file names from stdin and writing tags to stdout]:bool:(yes no)"
    "--filter-terminator=-[specify string to print to stdout following the tags for each file parsed when --filter is enabled]:string"
    "--format=-[force output of specified tag file format]:level"
    "(--guess-language-eagerly -G)"{--guess-language-eagerly,-G}"[guess the language of input file more eagerly]"
    {--help,-?}"[display help text]"
    "--help-full[display help text with experimental features]"
    "--if0=-[should code within #if 0 conditionals be parsed]:bool:(yes no)"
    "--input-encoding=-[specify encoding of all input files]:encoding"
    "--input-encoding--[specify encoding of the <lang> input files]:language:->languageequals"
    "--kinddef--[define new kind for <lang>]:language:->languageequals"
    "--kinds--[enable/disable tag kinds for <lang>]:language:->languageequals"
    "--langdef=-[define a new language to be parsed with regular expressions]:name"
    "--langmap=-[override default mapping of language to input file extension]:maps"
    "--language-force=-[force all files to be interpreted using specified language]:language:->language"
    "--languages=-[restrict files scanned to these comma-separated languages]:language:->languages"
    "--license[print details of software license]"
    "--line-directives=-[should #line directives be processed]:bool:(yes no)"
    "--links=-[indicate whether symlinks should be followed]:bool:(yes no)"
    "--list-aliases=-[list of alias patterns]:language:->language"
    "--list-excludes[list of exclude patterns for files/dirs]"
    "--list-extras=-[list of extra tag flags]:language:->language"
    "--list-features[list of compiled features]"
    "--list-fields=-[list of fields]:language:->language"
    "--list-kinds=-[list of all tag kinds for lang]:language:->language"
    "--list-kinds-full=-[list details of all tag kinds for lang]:language:->language"
    "--list-languages[list of supported languages]"
    "--list-map-extensions=-[list of language extensions in mapping]:language:->language"
    "--list-map-patterns=-[list of language patterns in mapping]:language:->language"
    "--list-maps=-[list of language mappings (both extensions and patterns)]:language:->language"
    "--list-mline-regex-flags[list of flags which can be used in a multiline regex parser definition]"
    "--list-params=-[list of language parameters. works with --machinable]:language:->language"
    "--list-pseudo-tags[list of pseudo tags]"
    "--list-regex-flags[list of flags which can be used in a regex parser definition]"
    "--list-roles=-[list of all roles of tag kinds specified for langs]:language:->language"
    "--list-subparsers=-[list of subparsers for the base lang]:language:->language"
    "--machinable=-[use tab separated representation in --list-* output]:bool:(yes no)"
    "--map--[set, add(+), or remove(-) the map for <lang>]:language:->languageequals"
    "--maxdepth=-[specify maximum recursion depth]:depth"
    "--mline-regex--[define multiline regex for locating tags in <lang>]:language:->languageequals"
    "--options=-[specify file (or dir) from which command line options should be read]:file:_files"
    "--options-maybe=-[same as --options but doesn't error]:file:_files"
    "--optlib-dir=-[add or set dir to optlib search path]:dir:_files -/"
    "--output-encoding=-[the encoding to write the tag file in]:encoding"
    "--output-format=-[specify the output format]:format:(u-ctags e-ctags etags xref)"
    "--param--[set <lang> specific parameter]:language:->languageequals"
    "--pattern-length-limit=-[cutoff patterns of tag entries after N characters]:number"
    "--print-language[don't make tags file but just print the guessed lang name for input file]"
    "--pseudo-tags=-[enable/disable emitting pseudo tag named ptag. if *, enable emitting all pseudo tags]:ptag"
    "--put-field-prefix[put UCTAGS as prefix for the name of fields newly introducted in universal ctags]"
    "--quiet=-[don't print notice class messages]:bool:(yes no)"
    "--regex--[define regex for locating tags in specific lang]:language:->languageequals"
    "--roles--[enable/disable tag roles for kinds of <lang>]:language:->languagedot"
    "--sort=-[should tags be sorted]:argument:(yes no foldcase)"
    "--tag-relative=-[should paths be relative to location of tag file]:argument:(yes no always never)"
    "--totals=-[print stats about input and tag files]:arguments:(yes no extra)"
    "(--verbose -V)--verbose=-[enable verbose messages describing actions]:bool:(yes no)"
    "(--verbose -V)-V[enable verbose messages describing actions]"
    "--version[print version]"
    "--with-list-header=-[prepend the column descriptions in --list-* output]:bool:(yes no)"
    "*:file:_files"
  )
elif [ "$_ctags_type" = "exuberant" ]; then
  arguments=(
    "-a[append to tags file]"
    "-B[use backward searching patterns (?...?)]"
    "-e[output tag file for use with emacs]"
    {-f+,-o+}"[write tags to specified file]:output file:_files"
    "-F[use forward searching patterns (/.../)]"
    "-h[specify a list of file extensions to be treated as include files]:extensions"
    "-I[specify a list of tokens to be specially handled]:identifier list"
    "-L[read a list of input file names from the specified file]:input file:_files"
    "-n[equivalent to --excmd=number]"
    "-N[equivalent to --excmd=pattern]"
    "(--recurse -R)--recurse=-[search files recursively]::bool:(yes no)"
    "(--recurse -R)-R[search files recursively]"
    "-u[equivalent to --sort=no]"
    "-x[print a tabular cross reference file to stdout]"
    "--append=-[should tags be appended to existing tag file]:bool:(yes no)"
    "--etags-include=-[include reference to file in emacs style tag file]:file:_files"
    "--exclude=-[exclude files and directories matching pattern]:pattern"
    "--excmd=-[uses the specified type of ex command to locate tags]:ex command type:(number pattern mix)"
    "--extra=-[include extra tag entries for selected information]:flags (fg)"
    "--fields=-[include selected extension fields]:flags (afmikKlnsStz)"
    "--file-scope=-[should tags scoped only for a single file be included in output]:bool:(yes no)"
    "--filter=-[behave as a filter, reading file names from stdin and writing tags to stdout]:bool:(yes no)"
    "--filter-terminator=-[specify string to print to stdout following the tags for each file parsed when --filter is enabled]:string"
    "--format=-[force output of specified tag file format]:level"
    "--help[display help text]"
    "--if0=-[should code within #if 0 conditionals be parsed]:bool:(yes no)"
    "--langdef=-[define a new language to be parsed with regular expressions]:name"
    "--langmap=-[override default mapping of language to input file extension]:maps"
    "--language-force=-[force all files to be interpreted using specified language]:language:->language"
    "--languages=-[restrict files scanned to these comma-separated languages]:language:->languages"
    "--license[print details of software license]"
    "--line-directives=-[should #line directives be processed]:bool:(yes no)"
    "--links=-[indicate whether symlinks should be followed]:bool:(yes no)"
    "--list-kinds=-[list of all tag kinds for lang]:language:->language"
    "--list-languages[list of supported languages]"
    "--list-maps=-[list of language mappings (both extensions and patterns)]:language:->language"
    "--options=-[specify file (or dir) from which command line options should be read]:file:_files"
    "--regex--[define regex for locating tags in specific lang]:language:->language"
    "--sort=-[should tags be sorted]:argument:(yes no foldcase)"
    "--tag-relative=-[should paths be relative to location of tag file]:argument:(yes no)"
    "--totals=-[print stats about input and tag files]:arguments:(yes no)"
    "(--verbose -V)--verbose=-[enable verbose messages describing actions]:bool:(yes no)"
    "(--verbose -V)-V[enable verbose messages describing actions]"
    "--version[print version]"
    "*:file:_files"
  )
  if [[ "$PREFIX" = -* ]]; then
    local -a languages=(`_ctags_languages`)
    local -a languages2
    for language in $languages; do
      arguments+=("--$language-kinds=-:kinds")
    done
  fi
elif [ "$_ctags_type" = "bsd" ]; then
  arguments=(
    "-a[append to tags file]"
    "-B[use backward searching patterns (?...?)]"
    "-d[create tags for #defines that don't take arguments]"
    "-F[use forward searching patterns (/.../)]"
    "-f+[write tags to specified file]:output file:_files"
    "-t[create tags for typedefs, structs, unions, and enums]"
    "-u[update the specified files in the tags file]"
    "-v[an index of the form expected by vgrind(1) is produced]"
    "-w[suppress warning diagnostics]"
    "-x[ctags produces a simple function index]"
    "*:file:_files"
  )
fi

_arguments -s $arguments

if [ "$state" = "language" ]; then
  local -a languages=(`_ctags_languages`)
  _wanted languages expl language compadd -a languages
elif [ "$state" = "languageequals" ]; then
  local -a languages=(`_ctags_languages`)
  _wanted languages expl language compadd -S = -a languages
elif [ "$state" = "languagedot" ]; then
  local -a languages=(`_ctags_languages`)
  _wanted languages expl language compadd -S . -a languages
elif [ "$state" = "languages" ]; then
  local -a languages=(`_ctags_languages`)
  _values -s , languages $languages
fi

return $(( compstate[nmatches] > 0 ? 0 : 1 ))


[-- Attachment #3: Type: text/plain, Size: 5726 bytes --]



> On Feb 24, 2021, at 8:24 AM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> 
> Jacob Gelbman wrote on Wed, Feb 24, 2021 at 01:20:24 -0600:
>> #compdef ctags
> 
> apt-file(1) on Debian stable shows a few more names:
> 
> arduino-ctags: /usr/bin/arduino-ctags
> emacs-bin-common: /usr/bin/ctags.emacs
> emacs-bin-common: /usr/bin/etags.emacs
> exuberant-ctags: /usr/bin/ctags-exuberant
> universal-ctags: /usr/bin/ctags-universal
> xemacs21-bin: /usr/bin/etags.xemacs21
> 
> I assume at least some of these should be added to the #compdef line.  Would
> you do the honours?

I added arduinio-ctags, ctags-exuberant, and ctags-universal to the #compdef line. I did not put ctags.emacs, etags.emacs, etags.xemacs21 because they probably belong at the top of the _etags script.

> 
>>    "--alias-<lang>=[add a pattern detecting a name, can be used as an alt name for lang]:pattern"
> 
> As Oliver said, literal angle brackets in the option name to be
> completed aren't especially helpful.  In fact, I'll go as far as to say
> I don't want users to run into it in released code.  Please change them.
> 
> You can use _call_program with --list-languages to generate the right set of
> option names dynamically.
> 

I made it so they are now shown --alias-, if they press tab again, they can complete the option name further with the language (--alias-ObjectiveC or --alias-Perl etc). So unless they enter the prefix, they won't be shown too many options.

For exuberant ctags, there's one option like --<lang>-kinds, which doesn't have a unique prefix, like --alias-<lang> (--alias- is the prefix), so I added all these options to the main _aguments call.


>> elif [ "$_ctags_type" = "exuberant" ]; then
>>  arguments=(
>>    "-a[append to tags file]"
>>    "-B[use backward searching patterns (?...?)]"
>>    "-e[output tag file for use with emacs]"
>>    "-f[write tags to specified file. - is stdout]:file:_files"
> 
> Is the argument to the -f option allowed to be pasted to it?  If so, s/-f/-f+/.

It can. I changed it.

> 
> Also, s/:file:/:output file:/.  That part of the string is a user-facing
> message, so the extra detail is helpful.
> 
> Also, you can drop the "- is stdout" part.  The descriptions are only
> a summary of the functionality; they aren't meant to be a complete copy of
> the manual.

Done.

> 
>>    "-F[use forward searching patterns (/.../)]"
>>    "-h[specify list of file extensions to be treated as include files]:"
> 
> Write something after the colon.

> 
>>    "-I[a list of tokens to be specifically handled is read from either the command line or the specified file]:"
> 
> The thing in brackets doesn't describe the action of the option.  Please edit.
> 
>>    "-L[a list of input file names is read from the specified file. - is stdin]:file:_files"
> 
> Rephrase in the imperative.

All done.

> 
>>    "-R[equivalent to --recurse]"
> 
> This is normally rendered as:
> 
>      '(-r --recurse)'{-R,--recurse}'[description]'

I couldn't quite combine -R and --recurse like that since --recurse takes an argument like --recurse=yes and -R doesn't. -R=yes is an error. But I gave them the same description, so they'll appear on the same line. I did the same for --verbose and -V, and --guess-language-eagerly and -G.

> 
>>    "--fields=[include selected extension fields (flags afmikKlnsStz)]:flags"
> 
> Recommend to move the afmikKlnsStz thing to after the colon, so it'll be
> shown at a more appropriate point.  Also, it would be helpful to display
> descriptions to the flags using, e.g., «compset» (for the leading plus
> sign) followed by «_values -s ''».

I moved the possible values to the argument description, but I don’t have enough time to figure out how to complete them automatically right now.

> 
>>    "--file-scope=[should tags scoped only for a single file be included in output]:bool:(yes no)"
>>    "--filter=[behave as a filter, reading file names from stdin and writing tags to stdout]:bool:(yes no)"
>>    "--filter-terminator=[specify string to print to stdout following the tags for each file parsed when --filter is enabled]:string"
>>    "--format=[force output of specified tag file format]:level"
>>    "--help[help text]"
> 
> "help text" is just a noun phrase.  Please use complete decsriptions.
> 
> Please use exclusions if needed («'(--foo)--bar[baz]'»).

Done.

> 
>>    "--language-force=[force all files to be interpreted using specified language]:language:->language"
>>    "--languages=[restrict files scanned to these comma-separated languages]:language:->languages"
> 
> Can't say I'm a fan of having two states that differ by a single letter,
> but so be it.
> 
>>    "--recurse=[recurse]:bool:(yes no)"
> 
> Fix the bracketed description.

It’s now “search files recursively”.
> 
>> _arguments $arguments
> 
> Pass any arguments to _arguments that may be needed (for
> instance, -s).
> 
Done.

>> if [[ "$state" = language* ]]; then
>>  local -a languages
>>  languages=(`ctags --list-languages | cut -d" " -f1`)
> 
> Use _call_program and $service.

Done.

> 
>>  if [ "$state" = "language" ]; then
>>    _wanted languages expl language compadd $languages
> 
> Don't pass unsanitized command output to a builtin.  In this case,
> «compadd -a languages» would do.

Done.

> 
>>  elif [ "$state" = "languages" ]; then
>>    _values -s , languages $languages
> 
> Don't pass unsanitized command output to a builtin.  I don't know the
> fix off the top of my head.
> 
> Thanks for the patch, and especially for adding exubertant and BSD ctags
> support!
> 
> Daniel
> 


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-03-07 19:18         ` Jacob Gelbman
@ 2021-03-07 21:42           ` Daniel Shahaf
  2021-03-07 21:57             ` Jacob Gelbman
  0 siblings, 1 reply; 38+ messages in thread
From: Daniel Shahaf @ 2021-03-07 21:42 UTC (permalink / raw)
  To: Jacob Gelbman; +Cc: zsh-workers

Thanks for the revision.  Not a full review; just two points:

Jacob Gelbman wrote on Sun, 07 Mar 2021 19:18 +00:00:
> > On Feb 24, 2021, at 8:24 AM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > Jacob Gelbman wrote on Wed, Feb 24, 2021 at 01:20:24 -0600:
> >>    "--fields=[include selected extension fields (flags afmikKlnsStz)]:flags"
> > 
> > Recommend to move the afmikKlnsStz thing to after the colon, so it'll be
> > shown at a more appropriate point.  Also, it would be helpful to display
> > descriptions to the flags using, e.g., «compset» (for the leading plus
> > sign) followed by «_values -s ''».
> 
> I moved the possible values to the argument description, but I don’t 
> have enough time to figure out how to complete them automatically right 
> now.

Like this:

_f() { _arguments : '--foo:bar: _values -s "" baz "a[access]" "f[file]" "i[inheritance]"' }

> >>  elif [ "$state" = "languages" ]; then
> >>    _values -s , languages $languages
> > 
> > Don't pass unsanitized command output to a builtin.  I don't know the
> > fix off the top of my head.

This point has been neither responded to nor implemented.

Daniel


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-03-07 21:42           ` Daniel Shahaf
@ 2021-03-07 21:57             ` Jacob Gelbman
  2021-03-07 22:10               ` Daniel Shahaf
  0 siblings, 1 reply; 38+ messages in thread
From: Jacob Gelbman @ 2021-03-07 21:57 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: zsh-workers



> On Mar 7, 2021, at 3:42 PM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> 
> Thanks for the revision.  Not a full review; just two points:
> 
> Jacob Gelbman wrote on Sun, 07 Mar 2021 19:18 +00:00:
>>> On Feb 24, 2021, at 8:24 AM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>>> Jacob Gelbman wrote on Wed, Feb 24, 2021 at 01:20:24 -0600:
>>>>   "--fields=[include selected extension fields (flags afmikKlnsStz)]:flags"
>>> 
>>> Recommend to move the afmikKlnsStz thing to after the colon, so it'll be
>>> shown at a more appropriate point.  Also, it would be helpful to display
>>> descriptions to the flags using, e.g., «compset» (for the leading plus
>>> sign) followed by «_values -s ''».
>> 
>> I moved the possible values to the argument description, but I don’t 
>> have enough time to figure out how to complete them automatically right 
>> now.
> 
> Like this:
> 
> _f() { _arguments : '--foo:bar: _values -s "" baz "a[access]" "f[file]" "i[inheritance]"' }

Right, I can do that. I wasn’t sure if the extra + and - symbols would make it complicated.
> 
>>>> elif [ "$state" = "languages" ]; then
>>>>   _values -s , languages $languages
>>> 
>>> Don't pass unsanitized command output to a builtin.  I don't know the
>>> fix off the top of my head.
> 
> This point has been neither responded to nor implemented.

I sanitize the output a little bit, by cutting just the first word from the list that’s returned. That fixes lines like "OldC++ [disabled]" And I’m not that worried about possibly feeding in incorrectly formatted data. What’s the worst that could happen? The listing will look messed up?

> 
> Daniel



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-03-07 21:57             ` Jacob Gelbman
@ 2021-03-07 22:10               ` Daniel Shahaf
  2021-03-11 16:15                 ` Daniel Shahaf
  0 siblings, 1 reply; 38+ messages in thread
From: Daniel Shahaf @ 2021-03-07 22:10 UTC (permalink / raw)
  To: Jacob Gelbman; +Cc: zsh-workers

Jacob Gelbman wrote on Sun, 07 Mar 2021 21:57 +00:00:
> 
> 
> > On Mar 7, 2021, at 3:42 PM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > 
> > Thanks for the revision.  Not a full review; just two points:
> > 
> > Jacob Gelbman wrote on Sun, 07 Mar 2021 19:18 +00:00:
> >>> On Feb 24, 2021, at 8:24 AM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >>> Jacob Gelbman wrote on Wed, Feb 24, 2021 at 01:20:24 -0600:
> >>>>   "--fields=[include selected extension fields (flags afmikKlnsStz)]:flags"
> >>> 
> >>> Recommend to move the afmikKlnsStz thing to after the colon, so it'll be
> >>> shown at a more appropriate point.  Also, it would be helpful to display
> >>> descriptions to the flags using, e.g., «compset» (for the leading plus
> >>> sign) followed by «_values -s ''».
> >> 
> >> I moved the possible values to the argument description, but I don’t 
> >> have enough time to figure out how to complete them automatically right 
> >> now.
> > 
> > Like this:
> > 
> > _f() { _arguments : '--foo:bar: _values -s "" baz "a[access]" "f[file]" "i[inheritance]"' }
> 
> Right, I can do that. I wasn’t sure if the extra + and - symbols would 
> make it complicated.

Oh, sorry.  I forgot about those.  In that case, something like this:

_f() { _arguments : '--foo:bar:_g' }
_g() { compset -P '[-+]'; _values -s "" baz "a[access]" "f[file]" "i[inheritance]" }

Plus or minus some code to offer «+» and «-» when there's nothing to the
left of the cursor.

Also, I suspect --fields should be declared repeatable.

> >>>> elif [ "$state" = "languages" ]; then
> >>>>   _values -s , languages $languages
> >>> 
> >>> Don't pass unsanitized command output to a builtin.  I don't know the
> >>> fix off the top of my head.
> > 
> > This point has been neither responded to nor implemented.
> 
> I sanitize the output a little bit, by cutting just the first word from 
> the list that’s returned. That fixes lines like "OldC++ [disabled]" And 
> I’m not that worried about possibly feeding in incorrectly formatted 
> data. What’s the worst that could happen? The listing will look messed 
> up?

An option flag could be injected from an external command into compadd.
You don't know in advance what flag that would be and what it would mean
in compadd (you need to consider future compadd too), so this is
essentially undefined behaviour.


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-03-07 22:10               ` Daniel Shahaf
@ 2021-03-11 16:15                 ` Daniel Shahaf
  2021-03-11 17:08                   ` Jacob Gelbman
  0 siblings, 1 reply; 38+ messages in thread
From: Daniel Shahaf @ 2021-03-11 16:15 UTC (permalink / raw)
  To: Jacob Gelbman; +Cc: zsh-workers

Daniel Shahaf wrote on Sun, Mar 07, 2021 at 22:10:56 +0000:
> Jacob Gelbman wrote on Sun, 07 Mar 2021 21:57 +00:00:
> > > On Mar 7, 2021, at 3:42 PM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > > Jacob Gelbman wrote on Sun, 07 Mar 2021 19:18 +00:00:
> > >>>> elif [ "$state" = "languages" ]; then
> > >>>>   _values -s , languages $languages
> > >>> 
> > >>> Don't pass unsanitized command output to a builtin.  I don't know the
> > >>> fix off the top of my head.
> > > 
> > > This point has been neither responded to nor implemented.
> > 
> > I sanitize the output a little bit, by cutting just the first word from 
> > the list that’s returned. That fixes lines like "OldC++ [disabled]" And 
> > I’m not that worried about possibly feeding in incorrectly formatted 
> > data. What’s the worst that could happen? The listing will look messed 
> > up?
> 
> An option flag could be injected from an external command into compadd. [...]

Do you intend to send a revised patch to address this?

> You don't know in advance what flag that would be and what it would mean
> in compadd (you need to consider future compadd too), so this is
> essentially undefined behaviour.


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-03-11 16:15                 ` Daniel Shahaf
@ 2021-03-11 17:08                   ` Jacob Gelbman
  2021-03-20  1:43                     ` Lawrence Velázquez
  2021-03-28 23:29                     ` Oliver Kiddle
  0 siblings, 2 replies; 38+ messages in thread
From: Jacob Gelbman @ 2021-03-11 17:08 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: zsh-workers

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]



> On Mar 11, 2021, at 10:15 AM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> 
> Daniel Shahaf wrote on Sun, Mar 07, 2021 at 22:10:56 +0000:
>> Jacob Gelbman wrote on Sun, 07 Mar 2021 21:57 +00:00:
>>>> On Mar 7, 2021, at 3:42 PM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>>>> Jacob Gelbman wrote on Sun, 07 Mar 2021 19:18 +00:00:
>>>>>>> elif [ "$state" = "languages" ]; then
>>>>>>>  _values -s , languages $languages
>>>>>> 
>>>>>> Don't pass unsanitized command output to a builtin.  I don't know the
>>>>>> fix off the top of my head.
>>>> 
>>>> This point has been neither responded to nor implemented.
>>> 
>>> I sanitize the output a little bit, by cutting just the first word from 
>>> the list that’s returned. That fixes lines like "OldC++ [disabled]" And 
>>> I’m not that worried about possibly feeding in incorrectly formatted 
>>> data. What’s the worst that could happen? The listing will look messed 
>>> up?
>> 
>> An option flag could be injected from an external command into compadd. [...]
> 
> Do you intend to send a revised patch to address this?

Yes, here it is: 

[-- Attachment #2: ctags.txt --]
[-- Type: text/plain, Size: 13176 bytes --]

#compdef ctags arduino-ctags ctags-exuberant ctags-universal

local context state line expl
local -A opt_args
local -a arguments

if [ -z "$_ctags_type" ]; then
  local output=`ctags --version 2>&1`
  if [[ "$output" = *Universal\ Ctags* ]]; then
    _ctags_type="universal"
  elif [[ "$output" = *Exuberant\ Ctags* ]]; then
    _ctags_type="exuberant"
  elif [[ "$output" = *usage:\ ctags* ]]; then
    _ctags_type="bsd"
  elif [[ "$output" = *Emacs* ]]; then
    _ctags_type="etags"
  else
    _ctags_type="universal"
  fi
fi

if [ "$_ctags_type" = "etags" ]; then
  _etags
  return $?
fi

_ctags_languages() {
  _call_program languages $service --list-languages | sed -n 's/^\([A-Za-z][A-Za-z0-9#_+]*\).*/\1/p'
}

if [[ "$PREFIX" = --alias-*=* ]]; then
  _message pattern
  return 1
elif [[ "$PREFIX" = --extras-*=* ]]; then
  _message flags
  return 1
elif [[ "$PREFIX" = --fields-*=* ]]; then
  _message flags
  return 1
elif [[ "$PREFIX" = --input-encoding-*=* ]]; then
  _message encoding
  return 1
elif [[ "$PREFIX" = --kinddef-*=* ]]; then
  _message kind
  return 1
elif [[ "$PREFIX" = --kinds-*=* ]]; then
  _message kind
  return 1
elif [[ "$PREFIX" = --map-*=* ]]; then
  _message pattern
  return 1
elif [[ "$PREFIX" = --mline-regex-*=* ]]; then
  _message pattern
  return 1
elif [[ "$PREFIX" = --param-*=* ]]; then
  _message argument
  return 1
elif [[ "$PREFIX" = --regex-*=* ]]; then
  _message pattern
  return 1
elif [[ "$PREFIX" = --roles-*.*=* ]] then
  _message role
  return 1
elif [[ "$PREFIX" = --roles-*.* ]] then
  _message kind
  return 1
fi

if [ "$_ctags_type" = "universal" ]; then
  arguments=(
    "-a[append to tags file]"
    "-B[use backward searching patterns (?...?)]"
    "-D[give definition for macro]:macro definition:"
    "-e[output tag file for use with emacs]"
    {-f+,-o+}"[write tags to specified file]:output file:_files"
    "-F[use forward searching patterns (/.../)]"
    "-h[specify a list of file extensions to be treated as include files]:extensions"
    "-I[specify a list of tokens to be specially handled]:identifier list"
    "-L[read a list of input file names from the specified file]:input file:_files"
    "-n[equivalent to --excmd=number]"
    "-N[equivalent to --excmd=pattern]"
    "(--recurse -R)--recurse=-[search files recursively]::bool:(yes no)"
    "(--recurse -R)-R[search files recursively]"
    "-u[equivalent to --sort=no]"
    "-x[print a tabular cross reference file to stdout]"
    "--alias--[add a pattern detecting a name, can be used as an alt name for lang]:language:->languageequals"
    "--append=-[should tags be appended to existing tag file]:bool:(yes no)"
    "--etags-include=-[include reference to file in emacs style tag file]:file:_files"
    "--exclude=-[exclude files and directories matching pattern]:pattern"
    "--exclude-exception=-[don't exclude files and directories matching pattern even if they match the pattern specified with --exclude]:pattern"
    "--excmd=-[uses the specified type of ex command to locate tags]:ex command type:(number pattern mix combine)"
    "--extras=-[include extra tag entries for selected information]:flags (fFgpqrs)"
    "--extras--[include <lang> own extra tag entries for selected information]:language:->languageequals"
    "--fields=-[include selected extension fields]:flags (aCeEfFikKlmnNpPrRsStxzZ)"
    "--fields--[include selected <lang> own extension fields]:language:->languageequals"
    "--filter=-[behave as a filter, reading file names from stdin and writing tags to stdout]:bool:(yes no)"
    "--filter-terminator=-[specify string to print to stdout following the tags for each file parsed when --filter is enabled]:string"
    "--format=-[force output of specified tag file format]:level"
    "(--guess-language-eagerly -G)"{--guess-language-eagerly,-G}"[guess the language of input file more eagerly]"
    {--help,-?}"[display help text]"
    "--help-full[display help text with experimental features]"
    "--if0=-[should code within #if 0 conditionals be parsed]:bool:(yes no)"
    "--input-encoding=-[specify encoding of all input files]:encoding"
    "--input-encoding--[specify encoding of the <lang> input files]:language:->languageequals"
    "--kinddef--[define new kind for <lang>]:language:->languageequals"
    "--kinds--[enable/disable tag kinds for <lang>]:language:->languageequals"
    "--langdef=-[define a new language to be parsed with regular expressions]:name"
    "--langmap=-[override default mapping of language to input file extension]:maps"
    "--language-force=-[force all files to be interpreted using specified language]:language:->language"
    "--languages=-[restrict files scanned to these comma-separated languages]:language:->languages"
    "--license[print details of software license]"
    "--line-directives=-[should #line directives be processed]:bool:(yes no)"
    "--links=-[indicate whether symlinks should be followed]:bool:(yes no)"
    "--list-aliases=-[list of alias patterns]:language:->language"
    "--list-excludes[list of exclude patterns for files/dirs]"
    "--list-extras=-[list of extra tag flags]:language:->language"
    "--list-features[list of compiled features]"
    "--list-fields=-[list of fields]:language:->language"
    "--list-kinds=-[list of all tag kinds for lang]:language:->language"
    "--list-kinds-full=-[list details of all tag kinds for lang]:language:->language"
    "--list-languages[list of supported languages]"
    "--list-map-extensions=-[list of language extensions in mapping]:language:->language"
    "--list-map-patterns=-[list of language patterns in mapping]:language:->language"
    "--list-maps=-[list of language mappings (both extensions and patterns)]:language:->language"
    "--list-mline-regex-flags[list of flags which can be used in a multiline regex parser definition]"
    "--list-params=-[list of language parameters. works with --machinable]:language:->language"
    "--list-pseudo-tags[list of pseudo tags]"
    "--list-regex-flags[list of flags which can be used in a regex parser definition]"
    "--list-roles=-[list of all roles of tag kinds specified for langs]:language:->language"
    "--list-subparsers=-[list of subparsers for the base lang]:language:->language"
    "--machinable=-[use tab separated representation in --list-* output]:bool:(yes no)"
    "--map--[set, add(+), or remove(-) the map for <lang>]:language:->languageequals"
    "--maxdepth=-[specify maximum recursion depth]:depth"
    "--mline-regex--[define multiline regex for locating tags in <lang>]:language:->languageequals"
    "--options=-[specify file (or dir) from which command line options should be read]:file:_files"
    "--options-maybe=-[same as --options but doesn't error]:file:_files"
    "--optlib-dir=-[add or set dir to optlib search path]:dir:_files -/"
    "--output-encoding=-[the encoding to write the tag file in]:encoding"
    "--output-format=-[specify the output format]:format:(u-ctags e-ctags etags xref)"
    "--param--[set <lang> specific parameter]:language:->languageequals"
    "--pattern-length-limit=-[cutoff patterns of tag entries after N characters]:number"
    "--print-language[don't make tags file but just print the guessed lang name for input file]"
    "--pseudo-tags=-[enable/disable emitting pseudo tag named ptag. if *, enable emitting all pseudo tags]:ptag"
    "--put-field-prefix[put UCTAGS as prefix for the name of fields newly introducted in universal ctags]"
    "--quiet=-[don't print notice class messages]:bool:(yes no)"
    "--regex--[define regex for locating tags in specific lang]:language:->languageequals"
    "--roles--[enable/disable tag roles for kinds of <lang>]:language:->languagedot"
    "--sort=-[should tags be sorted]:argument:(yes no foldcase)"
    "--tag-relative=-[should paths be relative to location of tag file]:argument:(yes no always never)"
    "--totals=-[print stats about input and tag files]:arguments:(yes no extra)"
    "(--verbose -V)--verbose=-[enable verbose messages describing actions]:bool:(yes no)"
    "(--verbose -V)-V[enable verbose messages describing actions]"
    "--version[print version]"
    "--with-list-header=-[prepend the column descriptions in --list-* output]:bool:(yes no)"
    "*:file:_files"
  )
elif [ "$_ctags_type" = "exuberant" ]; then
  arguments=(
    "-a[append to tags file]"
    "-B[use backward searching patterns (?...?)]"
    "-e[output tag file for use with emacs]"
    {-f+,-o+}"[write tags to specified file]:output file:_files"
    "-F[use forward searching patterns (/.../)]"
    "-h[specify a list of file extensions to be treated as include files]:extensions"
    "-I[specify a list of tokens to be specially handled]:identifier list"
    "-L[read a list of input file names from the specified file]:input file:_files"
    "-n[equivalent to --excmd=number]"
    "-N[equivalent to --excmd=pattern]"
    "(--recurse -R)--recurse=-[search files recursively]::bool:(yes no)"
    "(--recurse -R)-R[search files recursively]"
    "-u[equivalent to --sort=no]"
    "-x[print a tabular cross reference file to stdout]"
    "--append=-[should tags be appended to existing tag file]:bool:(yes no)"
    "--etags-include=-[include reference to file in emacs style tag file]:file:_files"
    "--exclude=-[exclude files and directories matching pattern]:pattern"
    "--excmd=-[uses the specified type of ex command to locate tags]:ex command type:(number pattern mix)"
    "--extra=-[include extra tag entries for selected information]:flags (fg)"
    "--fields=-[include selected extension fields]:flags (afmikKlnsStz)"
    "--file-scope=-[should tags scoped only for a single file be included in output]:bool:(yes no)"
    "--filter=-[behave as a filter, reading file names from stdin and writing tags to stdout]:bool:(yes no)"
    "--filter-terminator=-[specify string to print to stdout following the tags for each file parsed when --filter is enabled]:string"
    "--format=-[force output of specified tag file format]:level"
    "--help[display help text]"
    "--if0=-[should code within #if 0 conditionals be parsed]:bool:(yes no)"
    "--langdef=-[define a new language to be parsed with regular expressions]:name"
    "--langmap=-[override default mapping of language to input file extension]:maps"
    "--language-force=-[force all files to be interpreted using specified language]:language:->language"
    "--languages=-[restrict files scanned to these comma-separated languages]:language:->languages"
    "--license[print details of software license]"
    "--line-directives=-[should #line directives be processed]:bool:(yes no)"
    "--links=-[indicate whether symlinks should be followed]:bool:(yes no)"
    "--list-kinds=-[list of all tag kinds for lang]:language:->language"
    "--list-languages[list of supported languages]"
    "--list-maps=-[list of language mappings (both extensions and patterns)]:language:->language"
    "--options=-[specify file (or dir) from which command line options should be read]:file:_files"
    "--regex--[define regex for locating tags in specific lang]:language:->language"
    "--sort=-[should tags be sorted]:argument:(yes no foldcase)"
    "--tag-relative=-[should paths be relative to location of tag file]:argument:(yes no)"
    "--totals=-[print stats about input and tag files]:arguments:(yes no)"
    "(--verbose -V)--verbose=-[enable verbose messages describing actions]:bool:(yes no)"
    "(--verbose -V)-V[enable verbose messages describing actions]"
    "--version[print version]"
    "*:file:_files"
  )
  if [[ "$PREFIX" = -* ]]; then
    local -a languages=(`_ctags_languages`)
    local -a languages2
    for language in $languages; do
      arguments+=("--$language-kinds=-:kinds")
    done
  fi
elif [ "$_ctags_type" = "bsd" ]; then
  arguments=(
    "-a[append to tags file]"
    "-B[use backward searching patterns (?...?)]"
    "-d[create tags for #defines that don't take arguments]"
    "-F[use forward searching patterns (/.../)]"
    "-f+[write tags to specified file]:output file:_files"
    "-t[create tags for typedefs, structs, unions, and enums]"
    "-u[update the specified files in the tags file]"
    "-v[an index of the form expected by vgrind(1) is produced]"
    "-w[suppress warning diagnostics]"
    "-x[ctags produces a simple function index]"
    "*:file:_files"
  )
fi

_arguments -s $arguments

if [ "$state" = "language" ]; then
  local -a languages=(`_ctags_languages`)
  _wanted languages expl language compadd -a languages
elif [ "$state" = "languageequals" ]; then
  local -a languages=(`_ctags_languages`)
  _wanted languages expl language compadd -S = -a languages
elif [ "$state" = "languagedot" ]; then
  local -a languages=(`_ctags_languages`)
  _wanted languages expl language compadd -S . -a languages
elif [ "$state" = "languages" ]; then
  local -a languages=(`_ctags_languages`)
  _values -s , languages $languages
fi

return $(( compstate[nmatches] > 0 ? 0 : 1 ))


[-- Attachment #3: Type: text/plain, Size: 387 bytes --]



It will make sure the language names start with an alphabetic character, followed by any number of [A-za-z0-9#_+] using the sed program. The # is for C# and + for C++ and _ for good measure.

> 
>> You don't know in advance what flag that would be and what it would mean
>> in compadd (you need to consider future compadd too), so this is
>> essentially undefined behaviour.


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-03-11 17:08                   ` Jacob Gelbman
@ 2021-03-20  1:43                     ` Lawrence Velázquez
  2021-03-27 16:14                       ` Lawrence Velázquez
  2021-03-28 23:29                     ` Oliver Kiddle
  1 sibling, 1 reply; 38+ messages in thread
From: Lawrence Velázquez @ 2021-03-20  1:43 UTC (permalink / raw)
  To: zsh-workers; +Cc: Jacob Gelbman

On Thu, Mar 11, 2021, at 12:08 PM, Jacob Gelbman wrote:
> 
> 
> > On Mar 11, 2021, at 10:15 AM, Daniel Shahaf <d.s@daniel.shahaf.name <mailto:d.s%40daniel.shahaf.name>> wrote:
> > 
> > Do you intend to send a revised patch to address this?
> 
> Yes, here it is: 

ping

vq


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-03-20  1:43                     ` Lawrence Velázquez
@ 2021-03-27 16:14                       ` Lawrence Velázquez
  2021-03-27 20:43                         ` Daniel Shahaf
  0 siblings, 1 reply; 38+ messages in thread
From: Lawrence Velázquez @ 2021-03-27 16:14 UTC (permalink / raw)
  To: zsh-workers; +Cc: Jacob Gelbman

On Fri, Mar 19, 2021, at 9:43 PM, Lawrence Velázquez wrote:
> On Thu, Mar 11, 2021, at 12:08 PM, Jacob Gelbman wrote:
> > 
> > 
> > > On Mar 11, 2021, at 10:15 AM, Daniel Shahaf <d.s@daniel.shahaf.name <mailto:d.s%40daniel.shahaf.name>> wrote:
> > > 
> > > Do you intend to send a revised patch to address this?
> > 
> > Yes, here it is: 
> 
> ping

ping for review 2.0

vq


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-03-27 16:14                       ` Lawrence Velázquez
@ 2021-03-27 20:43                         ` Daniel Shahaf
  0 siblings, 0 replies; 38+ messages in thread
From: Daniel Shahaf @ 2021-03-27 20:43 UTC (permalink / raw)
  To: Lawrence Velázquez; +Cc: zsh-workers, Jacob Gelbman

Lawrence Velázquez wrote on Sat, Mar 27, 2021 at 12:14:44 -0400:
> On Fri, Mar 19, 2021, at 9:43 PM, Lawrence Velázquez wrote:
> > On Thu, Mar 11, 2021, at 12:08 PM, Jacob Gelbman wrote:
> > > 
> > > 
> > > > On Mar 11, 2021, at 10:15 AM, Daniel Shahaf <d.s@daniel.shahaf.name <mailto:d.s%40daniel.shahaf.name>> wrote:
> > > > 
> > > > Do you intend to send a revised patch to address this?
> > > 
> > > Yes, here it is: 
> > 
> > ping
> 
> ping for review 2.0

Thanks.  It's on my list, but I would love to be beaten to it if anyone
has cycles.


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-03-11 17:08                   ` Jacob Gelbman
  2021-03-20  1:43                     ` Lawrence Velázquez
@ 2021-03-28 23:29                     ` Oliver Kiddle
  2021-03-29  8:54                       ` Peter Stephenson
  1 sibling, 1 reply; 38+ messages in thread
From: Oliver Kiddle @ 2021-03-28 23:29 UTC (permalink / raw)
  To: Jacob Gelbman; +Cc: zsh-workers

On 11 Mar, Jacob Gelbman wrote:
> Yes, here it is: 

Thanks for sending the update. I've committed it as-is to the repository
because it is a definite improvement on the earlier file and that
doesn't prevent us from further iterating on it. It is easier if you can
send changes as patches. Use the diff -u, or git diff commands to create
patches rather than posting full files. The previous files also had DOS
line endings - if someone other than me pushes any updates, please
ensure we only have Unix line endings.

> #compdef ctags arduino-ctags ctags-exuberant ctags-universal

exuberant is installed as exctags on my system so that name could be
added.

> local context state line expl
> local -A opt_args
> local -a arguments
>
> if [ -z "$_ctags_type" ]; then
>   local output=`ctags --version 2>&1`
>   if [[ "$output" = *Universal\ Ctags* ]]; then
>     _ctags_type="universal"
>   elif [[ "$output" = *Exuberant\ Ctags* ]]; then
>     _ctags_type="exuberant"
>   elif [[ "$output" = *usage:\ ctags* ]]; then
>     _ctags_type="bsd"
>   elif [[ "$output" = *Emacs* ]]; then
>     _ctags_type="etags"
>   else
>     _ctags_type="universal"
>   fi
> fi

As was mentioned in a previous review, use _pick_variant for this. It
does exactly this in a generic manner and handles things like caching
results. This code above will cache one result even if the user has both
ctags and ctags-exuberant installed.

> if [ "$_ctags_type" = "etags" ]; then
>   _etags
>   return $?
> fi

WE should perhaps pull the contents of _etags into this function and
handle them all together.

>   if [[ "$PREFIX" = -* ]]; then

If the prefix-needed style is set to false, that condition is not
applicable. If generating the list of languages is fast enough, I would
generate it unconditionally and store the result in an array so that it
can be used from a variety of places.

>     local -a languages=(`_ctags_languages`)

In general, I would recommend using $(...) instead of `...` because it
is simple to nest. That doesn't matter here as such.

>     local -a languages2

That variable isn't used.

>     for language in $languages; do
>       arguments+=("--$language-kinds=-:kinds")

The latter kinds should be singular - kind. You can actually avoid the
need for a for loop by using --${^languages}"-kinds=-:kind"

If you keep the for loop, language does need to be declared local.

> if [ "$state" = "language" ]; then

The [[ ... ]] condition form is usually preferable to [ ... ] because
the parser handles it and avoids certain tricky issues. A case statement
would work here though. Or even better, make _ctags_languages a proper
completion function so that you can call it directly with options such
as -S = or with _sequence for the comma-separated list.

Thanks,

Oliver


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Completion script for the ctags program
  2021-03-28 23:29                     ` Oliver Kiddle
@ 2021-03-29  8:54                       ` Peter Stephenson
  2021-03-29 15:07                         ` EOL normalization? (Was: Completion script for the ctags program) Lawrence Velázquez
  0 siblings, 1 reply; 38+ messages in thread
From: Peter Stephenson @ 2021-03-29  8:54 UTC (permalink / raw)
  To: zsh-workers


> On 29 March 2021 at 00:29 Oliver Kiddle <opk@zsh.org> wrote:
> On 11 Mar, Jacob Gelbman wrote:
> Thanks for sending the update. I've committed it as-is to the repository
> because it is a definite improvement on the earlier file and that
> doesn't prevent us from further iterating on it. It is easier if you can
> send changes as patches. Use the diff -u, or git diff commands to create
> patches rather than posting full files. The previous files also had DOS
> line endings - if someone other than me pushes any updates, please
> ensure we only have Unix line endings.

That would likely be my fault because on that occasion I extracted the script
from the original email in a somewhat clumsy cross-platform way.  It was
inconvenient and bug-prone enough I'm likely to be leaving anything like
this in future until I'm back on a proper Linux system...

pws


^ permalink raw reply	[flat|nested] 38+ messages in thread

* EOL normalization? (Was: Completion script for the ctags program)
  2021-03-29  8:54                       ` Peter Stephenson
@ 2021-03-29 15:07                         ` Lawrence Velázquez
  2021-03-29 15:34                           ` Daniel Shahaf
  0 siblings, 1 reply; 38+ messages in thread
From: Lawrence Velázquez @ 2021-03-29 15:07 UTC (permalink / raw)
  To: zsh-workers

On Mon, Mar 29, 2021, at 4:54 AM, Peter Stephenson wrote:
> 
> > On 29 March 2021 at 00:29 Oliver Kiddle <opk@zsh.org> wrote:
> > The previous files also had DOS
> > line endings - if someone other than me pushes any updates, please
> > ensure we only have Unix line endings.
> 
> That would likely be my fault because on that occasion I extracted the script
> from the original email in a somewhat clumsy cross-platform way.  It was
> inconvenient and bug-prone enough I'm likely to be leaving anything like
> this in future until I'm back on a proper Linux system...

Would it be desirable to normalize line endings on commit (see
https://git-scm.com/docs/gitattributes#_end_of_line_conversion)?

vq



diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 000000000..0a192b762
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1,2 @@
+# Normalize EOLs to LF in files that look like text.
+* text=auto


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: EOL normalization? (Was: Completion script for the ctags program)
  2021-03-29 15:07                         ` EOL normalization? (Was: Completion script for the ctags program) Lawrence Velázquez
@ 2021-03-29 15:34                           ` Daniel Shahaf
  2021-03-29 15:41                             ` Lawrence Velázquez
  0 siblings, 1 reply; 38+ messages in thread
From: Daniel Shahaf @ 2021-03-29 15:34 UTC (permalink / raw)
  To: Lawrence Velázquez, zsh-workers

Lawrence Velázquez wrote on Mon, 29 Mar 2021 15:07 +00:00:
> On Mon, Mar 29, 2021, at 4:54 AM, Peter Stephenson wrote:
> > 
> > > On 29 March 2021 at 00:29 Oliver Kiddle <opk@zsh.org> wrote:
> > > The previous files also had DOS
> > > line endings - if someone other than me pushes any updates, please
> > > ensure we only have Unix line endings.
> > 
> > That would likely be my fault because on that occasion I extracted the script
> > from the original email in a somewhat clumsy cross-platform way.  It was
> > inconvenient and bug-prone enough I'm likely to be leaving anything like
> > this in future until I'm back on a proper Linux system...
> 
> Would it be desirable to normalize line endings on commit (see
> https://git-scm.com/docs/gitattributes#_end_of_line_conversion)?

I for one would rather Git treated file contents as opaque binary blobs
and didn't munge them in any way.  That tends to be a lot easier if we
ever need to surgery the repository, or if we want to add CRLF or binary
test data, or if somebody uses a Windows Git client to build zsh on
Cygwin — and as to downsides, it's not as though CRLF in the completion
files are a common problem, or one that's hard to notice/fix when it
does occur.

Cheers,

Daniel

> 
> 
> 
> diff --git a/.gitattributes b/.gitattributes
> new file mode 100644
> index 000000000..0a192b762
> --- /dev/null
> +++ b/.gitattributes
> @@ -0,0 +1,2 @@
> +# Normalize EOLs to LF in files that look like text.
> +* text=auto
> 
>


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: EOL normalization? (Was: Completion script for the ctags program)
  2021-03-29 15:34                           ` Daniel Shahaf
@ 2021-03-29 15:41                             ` Lawrence Velázquez
  0 siblings, 0 replies; 38+ messages in thread
From: Lawrence Velázquez @ 2021-03-29 15:41 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: zsh-workers

On Mon, Mar 29, 2021, at 11:34 AM, Daniel Shahaf wrote:
> it's not as though CRLF in the completion files are a common problem

That's true; after creating that .gitattributes, not a single file
in the entire repository needed renormalizing. This might just not
be a problem that we need to solve.

vq


^ permalink raw reply	[flat|nested] 38+ messages in thread

end of thread, other threads:[~2021-03-29 15:41 UTC | newest]

Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-23  3:11 Completion script for the ctags program Jacob Gelbman
2021-02-23 10:11 ` Peter Stephenson
2021-02-23 22:20   ` Oliver Kiddle
2021-02-23 22:45     ` Bart Schaefer
2021-02-23 23:51       ` Oliver Kiddle
2021-02-24  0:52         ` Bart Schaefer
2021-02-24 13:47           ` Daniel Shahaf
2021-02-23 23:05     ` Mikael Magnusson
2021-02-23 21:39 ` Oliver Kiddle
2021-02-24  4:45   ` Jacob Gelbman
2021-02-24  7:20     ` Jacob Gelbman
2021-02-24  9:26       ` Peter Stephenson
2021-02-24 14:24       ` Daniel Shahaf
2021-02-24 18:58         ` Jacob Gelbman
2021-02-24 19:01           ` Bart Schaefer
2021-03-03 20:02         ` Daniel Shahaf
2021-03-03 20:39           ` Jacob Gelbman
2021-03-03 21:40             ` Peter Stephenson
2021-03-03 22:06             ` Daniel Shahaf
2021-03-03 22:08           ` Jacob Gelbman
2021-03-03 23:28             ` Aaron Schrab
2021-03-03 23:43               ` Daniel Shahaf
2021-03-03 23:35             ` Daniel Shahaf
2021-03-07 19:18         ` Jacob Gelbman
2021-03-07 21:42           ` Daniel Shahaf
2021-03-07 21:57             ` Jacob Gelbman
2021-03-07 22:10               ` Daniel Shahaf
2021-03-11 16:15                 ` Daniel Shahaf
2021-03-11 17:08                   ` Jacob Gelbman
2021-03-20  1:43                     ` Lawrence Velázquez
2021-03-27 16:14                       ` Lawrence Velázquez
2021-03-27 20:43                         ` Daniel Shahaf
2021-03-28 23:29                     ` Oliver Kiddle
2021-03-29  8:54                       ` Peter Stephenson
2021-03-29 15:07                         ` EOL normalization? (Was: Completion script for the ctags program) Lawrence Velázquez
2021-03-29 15:34                           ` Daniel Shahaf
2021-03-29 15:41                             ` Lawrence Velázquez
2021-02-24 21:54       ` Completion script for the ctags program dana

zsh-workers

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/zsh-workers

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 zsh-workers zsh-workers/ http://inbox.vuxu.org/zsh-workers \
		zsh-workers@zsh.org
	public-inbox-index zsh-workers

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/zsh/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git