[PATCH v4] zsh localedef completion

[PATCH v4] zsh localedef completion

[Marko Myllynen]

Hi,

Below is zsh completions for the localedef(1) command, I've tested this
on RHEL 7 against the glibc provided localedef command. Otherwise it
works nicely but I'm a bit wondering one thing here (not two anymore -
thanks to Daniel Shahaf for explaining the other one):

$ localedef -c<TAB>

offers also V/? although I hoped them to get excluded in that case.

As Eric Cook pointed out, there's life outside of GNU and this patch now
supports many non-GNU variants as well. Since I don't have access to a
Solaris system I didn't implement that yet, would be probably pretty
straightforward but would be good to actually test it.

Baptiste Daroussin informed that even though there's no FreeBSD man
page for localedef(1) yet, it will be based on the same code as the
Dragonfly BSD variant in FreeBSD 11.

As with locale(1) completion, I chose to duplicate few lines so that if
something needs to be changed for non-GNU which I haven't tested, it's
probably easier to tweak the already separate if-block then.

References:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/localedef.html
http://man7.org/linux/man-pages/man1/localedef.1.html
https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/localedef.1.html
https://docs.oracle.com/cd/E26502_01/html/E29030/localedef-1.html
https://www.freebsd.org/cgi/man.cgi?localedef
https://www.dragonflybsd.org/cgi/web-man?command=localedef&section=1

---
 Completion/Unix/Command/_localedef | 96 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 96 insertions(+)
 create mode 100644 Completion/Unix/Command/_localedef

diff --git a/Completion/Unix/Command/_localedef b/Completion/Unix/Command/_localedef
new file mode 100644
index 0000000..9fafe55
--- /dev/null
+++ b/Completion/Unix/Command/_localedef
@@ -0,0 +1,96 @@
+#compdef localedef
+
+local curcontext="$curcontext" state line expl ret=1
+typeset -A opt_args
+
+if _pick_variant gnu='(GNU|EGLIBC)' unix --version; then
+
+  local exargs="-? --help --usage -V --version"
+  _arguments -A "-*" -C -S -s \
+    '(- *)'{-\?,--help}'[display help information]' \
+    '(- *)--usage[display a short usage message]' \
+    '(- *)'{-V,--version}'[print program version]' \
+    "(-A --alias-file $exargs)"{-A+,--alias-file=}'[specify locale alias file]:alias file:_files' \
+    "($exargs)--prefix=[specify path prefix]:prefix:_files" \
+    "(-c --force $exargs)"{-c,--force}'[force write despite of warnings]' \
+    "(-v --verbose $exargs)"{-v,--verbose}'[display additional information]' \
+    "($exargs)--quiet[suppress messages and warnings]" \
+    - set1 \
+    "(-f --charmap $exargs)"{-f+,--charmap=}'[specify locale charmap file]:charmap:->charmap' \
+    "(-i --inputfile $exargs)"{-i+,--inputfile=}'[specify locale definition file]:locale file:_files' \
+    "(-u --repertoire-map $exargs)"{-u+,--repertoire-map=}'[specify repertoire map file]:repertoire map file:_files' \
+    '1:path:_files' \
+    - set2 \
+    "(--list-archive $exargs)--list-archive[list locales in archive]" \
+    - set3 \
+    "(--delete-from-archive $exargs)--delete-from-archive[delete locale from archive]" \
+    '*:locale:->locale' \
+    - set4 \
+    "(--add-to-archive $exargs)--add-to-archive[add locale to archive]" \
+    "(--replace $exargs)--replace[replace locale in archive]" \
+    "(--no-archive $exargs)--no-archive[use subdir not archive]" \
+    '*:compiled path:_files -/' \
+    && return 0
+
+  case "$state" in
+    charmap)
+      if [[ $words[-1] == */* ]]; then
+        _wanted values expl charmap _files && ret=0
+      else
+        typeset -a charmaps
+        charmaps=( ${(f)"$(locale -m)"} )
+        _wanted values expl charmap compadd "$@" \
+          -M 'm:{a-zA-Z}={A-Za-z} r:|-=* r:|=*' \
+          -a - charmaps && ret=0
+      fi
+    ;;
+    locale)
+      typeset -a locales
+      local pref=${opt_args[--prefix]}
+      local p=${pref:+--prefix}
+      locales=( ${(f)"$(localedef --list-archive $p $pref)"} )
+      _wanted values expl locale compadd "$@" -a - locales && ret=0
+    ;;
+  esac
+
+  return ret
+
+else
+
+  typeset -a u_opt bsd_opts
+  [[ $OSTYPE != darwin* ]] && u_opt=(
+      "(-u)"-u+'[specify target codeset]:codeset:_files'
+    )
+  [[ $OSTYPE == (freebsd*|dragonfly*) ]] && bsd_opts=(
+      "(-D)"-D'[create BSD-style output]' \
+      "(-U)"-U'[ignore undefined character symbols]' \
+      "(-v)"-v'[verbose deguggin output]' \
+      "(-w)"-w+'[specify width file]:width file:_files' \
+    )
+
+  _arguments -A "-*" -C \
+    "(-c)"-c'[force write despite of warnings]' \
+    "(-f)"-f+'[specify locale charmap file]:charmap:->charmap' \
+    "(-i)"-i+'[specify locale definition file]:locale file:_files' \
+    $u_opt \
+    $bsd_opts \
+    '1:path:_files' \
+    && return 0
+
+  case "$state" in
+    charmap)
+      if [[ $words[-1] == */* ]]; then
+        _wanted values expl charmap _files && ret=0
+      else
+        typeset -a charmaps
+        charmaps=( ${(f)"$(locale -m)"} )
+        _wanted values expl charmap compadd "$@" \
+          -M 'm:{a-zA-Z}={A-Za-z} r:|-=* r:|=*' \
+          -a - charmaps && ret=0
+      fi
+    ;;
+  esac
+
+  return ret
+
+fi

Thanks,

-- 
Marko Myllynen

Re: [PATCH v4] zsh localedef completion

[Eric Cook]

Two minor things about this


> +      "(-u)"-u+'[specify target codeset]:codeset:_files'
> +    )
> +  [[ $OSTYPE == (freebsd*|dragonfly*) ]] && bsd_opts=(
> +      "(-D)"-D'[create BSD-style output]' \
> +      "(-U)"-U'[ignore undefined character symbols]' \
> +      "(-v)"-v'[verbose deguggin output]' \
> +      "(-w)"-w+'[specify width file]:width file:_files' \
> +    )
> +
> +  _arguments -A "-*" -C \
> +    "(-c)"-c'[force write despite of warnings]' \
> +    "(-f)"-f+'[specify locale charmap file]:charmap:->charmap' \
> +    "(-i)"-i+'[specify locale definition file]:locale file:_files' \

You don't have to specify the option itself in the exclusion list of the optspec,
compsys only completes an option once (normally).

A person normally includes the option in the exclusion list with a trick like
"(-v --verbose $exargs)"{-v,--verbose}'[display additional information]'

Because brace expansion will expand into two (shell) words
(-v --verbose $exargs)--verbose[display additional information] # and
(-v --verbose $exargs)-v[display additional information]

Which saves a bit of typing.


> +        _wanted values expl charmap compadd "$@" \
> +          -M 'm:{a-zA-Z}={A-Za-z} r:|-=* r:|=*' \
> +          -a - charmaps && ret=0


Also, what is the list's opinion of an completer forcing case insensitivity?
Its a option the user normally have control over but after checking Completion/,
i notice a few non-utility functions also do so.

Some examples being _git, _imagemagick, _graphicsmagick, _mtools, _whois
_mozilla, _netscape

Re: [PATCH v4] zsh localedef completion

[Oliver Kiddle]

Eric Cook wrote:
>
> > +        _wanted values expl charmap compadd "$@" \

The tag should probably be charmaps rather than values and "$@" is
superfluous given this is function is not intended to be called from
others.

> > +          -M 'm:{a-zA-Z}={A-Za-z} r:|-=* r:|=*' \
> > +          -a - charmaps && ret=0
>
>
> Also, what is the list's opinion of an completer forcing case insensitivity?
> Its a option the user normally have control over but after checking Completion/,
> i notice a few non-utility functions also do so.

If whatever is being completed is treated case-insensitively by whatever
program recieves it then it makes sense for the completion to also be
case-sensitive. So as long as localedef is as happy with utF-8 as with
UTF-8 then this would seem good.

The same argument doesn't quite apply to the r: specs: localedef isn't
going to accept U-8 as a shorthand for UTF-8. I would still include it
in cases where the matches are composed of - separated components,
however, even if for no other reason than to preserve and convey that
information in the function definitions.

It could perhaps be made easier to disable hard coded match specs with
a style. Currently it isn't too easy: compadd will accept multiple -M
options and concatenate them so that all apply. In the _wanted example
above, you get specs from the matcher style first, then matcher-list,
then anything in "$@" and finally the hard coded list. Perhaps we could
allow a special token in match specs that would cause subsequent specs
to be ignored or filtered?

Oliver

Re: [PATCH v4] zsh localedef completion

[Eric Cook]

On 06/14/2016 05:31 AM, Oliver Kiddle wrote:

> 
> It could perhaps be made easier to disable hard coded match specs with
> a style. Currently it isn't too easy: compadd will accept multiple -M
> options and concatenate them so that all apply. In the _wanted example
> above, you get specs from the matcher style first, then matcher-list,
> then anything in "$@" and finally the hard coded list. Perhaps we could
> allow a special token in match specs that would cause subsequent specs
> to be ignored or filtered?

If it isn't hard to do, sure; i wouldn't mind it. I was originally thinking about
adding a few lines to Etc/completion-style-guide mentioning why this shouldn't be
blindly cargo culted into completers.

PATCH: allow default match specs to be disabled (was Re: [PATCH v4] zsh localedef completion)

[Oliver Kiddle]

On 15 Jun, Eric Cook wrote:
>
> > Perhaps we could
> > allow a special token in match specs that would cause subsequent specs
> > to be ignored or filtered?
>
> If it isn't hard to do, sure; i wouldn't mind it.

Turns out it isn't hard to do.

This patch uses x: as the token. Any thoughts on that or alternative
suggestions?

There's nothing in the documentation to suggest that the ordering of
matching specifications has any effect. Is anyone aware of whether it
perhaps does?

The documentation of the matcher style was perhaps deceptive in
indicating that it is tried before matcher-list. The value is merely
placed before those from matcher-list.

Oliver

diff --git a/Doc/Zsh/compsys.yo b/Doc/Zsh/compsys.yo
index c97f80f..fb0abce 100644
--- a/Doc/Zsh/compsys.yo
+++ b/Doc/Zsh/compsys.yo
@@ -2023,8 +2023,9 @@ only be performed with the `tt(*)' inserted.
 kindex(matcher, completion style)
 item(tt(matcher))(
 This style is tested separately for each tag valid in the current
-context.  Its value is tried before any match specifications given by the 
-tt(matcher-list) style.  It should be in the form described in
+context.  Its value is placed before any match specifications given by the
+tt(matcher-list) style so can override them via the use of an tt(x:)
+specification.  The value should be in the form described in
 ifzman(the section `Completion Matching Control' in zmanref(zshcompwid))\
 ifnzman(noderef(Completion Matching Control))\
 .  For examples of this, see the description of the tt(tag-order) style.
diff --git a/Doc/Zsh/compwid.yo b/Doc/Zsh/compwid.yo
index c017633..1cc94bf 100644
--- a/Doc/Zsh/compwid.yo
+++ b/Doc/Zsh/compwid.yo
@@ -913,6 +913,13 @@ line and trial completion patterns are anchored on the right side.
 Here an empty var(ranchor) and the tt(e) and tt(E) forms force the
 match to the end of the command line or trial completion string.
 )
+item(tt(x:))(
+This form is used to mark the end of matching specifications:
+subsequent specifications are ignored. In a single standalone list
+of specifications this has no use but where matching specifications
+are accumulated, such as from nested function calls, it can allow one
+function to override another.
+)
 enditem()
 
 Each var(lpat), var(tpat) or var(anchor) is either an empty string or
diff --git a/Src/Zle/complete.c b/Src/Zle/complete.c
index 30fab54..0c14d86 100644
--- a/Src/Zle/complete.c
+++ b/Src/Zle/complete.c
@@ -241,6 +241,7 @@ parse_cmatcher(char *name, char *s)
 	case 'E': fl2 = CMF_INTER;
 	case 'R': fl = CMF_RIGHT | CMF_LINE; break;
 	case 'M': fl = CMF_LINE; break;
+	case 'x': break;
 	default:
 	    if (name)
 		zwarnnam(name, "unknown match specification character `%c'",
@@ -252,6 +253,15 @@ parse_cmatcher(char *name, char *s)
 		zwarnnam(name, "missing `:'");
 	    return pcm_err;
 	}
+	if (*s == 'x') {
+	    if (s[2] && !inblank(s[2])) {
+		if (name)
+		    zwarnnam(name,
+			"unexpected pattern following x: specification");
+		return pcm_err;
+	    }
+	    return ret;
+	}
 	s += 2;
 	if (!*s) {
 	    if (name)

Re: PATCH: allow default match specs to be disabled (was Re: [PATCH v4] zsh localedef completion)

[Bart Schaefer]

On Jun 18, 11:17pm, Oliver Kiddle wrote:
}
} Turns out it isn't hard to do.
} 
} This patch uses x: as the token. Any thoughts on that or alternative
} suggestions?

My only other thought would be a single hyphen or a single exclamation
point, for similarity with the tag-order style, 
 
} There's nothing in the documentation to suggest that the ordering of
} matching specifications has any effect. Is anyone aware of whether it
} perhaps does?

I would expect that it does, for a number of reasons:
  * you can group specs to be tried "all the same time" together in
    a single quoted string, or have several strings that are to be
    tried separately
  * specs can begin with a "+" to append them to an existing spec
  * it matters that the global matcher is prepended to matcher-list
    rather than appended

What is it that leads you to think it's order-independent?

} The documentation of the matcher style was perhaps deceptive in
} indicating that it is tried before matcher-list. The value is merely
} placed before those from matcher-list.

I have this comment in my .zshrc:

# Matching
# 1. Try completion with no alterations (i.e., literal match is best)
# 2. Match substrings separated by dashes, dots, underscores, commas
# 3. As (2) but case-insensitively
# 4. As (2) but allow arbitrary stuff at the beginning of the result
zstyle ':completion:*' matcher-list '' 'r:|[-._,]=** r:|=**' \
    'm:{[:lower:][:upper:]}={[:upper:][:lower:]} r:|[-._,]=** r:|=**' \
    'r:|[-._,]=** r:|=** l:|=*'

The behavior I see from completion leads me to believe that later
matchers are not tried if earlier matchers generate a result, e.g.,
"literal match is best" => put empty matcher first.

Maybe I'm misunderstanding your question.

Re: PATCH: allow default match specs to be disabled (was Re: [PATCH v4] zsh localedef completion)

[Oliver Kiddle]

Bart wrote:
> } This patch uses x: as the token. Any thoughts on that or alternative
> } suggestions?
>
> My only other thought would be a single hyphen or a single exclamation
> point, for similarity with the tag-order style, 

A single hyphen wouldn't be a good idea because _wanted and similar
helpers look for a single hyphen to indicate where they should insert
the explanation options. The way ! is used in tag-order is somewhat
different. Do you have a preference for it as such?

>   * it matters that the global matcher is prepended to matcher-list
>      rather than appended

By global matcher do you mean the "matcher" style; it is only global
if specified with a very general context. What is your source for that
statement? The only line of documentation I've found that implies that
comes from a clarification patch in users/18550. It originally used
the wording "added to".

> What is it that leads you to think it's order-independent?

Well the word "order" is absent from the "Completion Matching Control"
section of the manual. And I can't think of a way for one matching spec
to affect another.

> I have this comment in my .zshrc:
>
> zstyle ':completion:*' matcher-list '' 'r:|[-._,]=** r:|=**' \
>     'm:{[:lower:][:upper:]}={[:upper:][:lower:]} r:|[-._,]=** r:|=**' \
>     'r:|[-._,]=** r:|=** l:|=*'

> Maybe I'm misunderstanding your question.

Yes, my question concerned only the order of match specifications as they
are passed to compadd -M within a single string. So is there, for example,
any difference between
  -M 'r:|[-._,]=** r:|=**' and
  -M 'r:|=** r:|[-._,]=**'

The order of matcher-list arguments clearly does matter - _main_complete
(or _prefix) looks them up and tries them one after the other in order.
But within an argument, can the order of the various r: and m: specs
matter? I'm fairly sure the answer is no.

Oliver

Re: PATCH: allow default match specs to be disabled (was Re: [PATCH v4] zsh localedef completion)

[Peter Stephenson]

On Mon, 20 Jun 2016 16:13:27 +0200
Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> But within an argument, can the order of the various r: and m: specs
> matter? I'm fairly sure the answer is no.

I think this is well into undocumented behaviour that a user might be
well advised not to find out about by creating specs where it matters.

pws

Re: PATCH: allow default match specs to be disabled (was Re: [PATCH v4] zsh localedef completion)

[Bart Schaefer]

On Jun 20,  4:13pm, Oliver Kiddle wrote:
}
} A single hyphen wouldn't be a good idea because _wanted and similar
} helpers look for a single hyphen to indicate where they should insert
} the explanation options. The way ! is used in tag-order is somewhat
} different. Do you have a preference for it as such?

I do not have a preference.

} Yes, my question concerned only the order of match specifications as they
} are passed to compadd -M within a single string.

Ah!  OK, in that case the answer is that the order does not matter; all
the controls in a single string are supposed to apply "at the same time"
describing a single matching operation.

I'm quite surprised the doc doesn't come right out and say this anywhere, 
but the examples referring to "both left and right anchor" etc. make it
reasonably plain.

On Jun 20,  4:10pm, Peter Stephenson wrote:
}
} I think this is well into undocumented behaviour that a user might be
} well advised not to find out about by creating specs where it matters.

I can't think of any way to create a spec where it would matter ...