From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: dana <dana@dana.is>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: [PATCH] Completion: Add _log_priorities, _logger
Date: Sat, 2 Nov 2019 05:54:23 +0000 [thread overview]
Message-ID: <20191102055423.5gzbipni3vnjo4k3@tarpaulin.shahaf.local2> (raw)
In-Reply-To: <E00A62F9-627E-4C0C-A3FD-3A0C1F00D666@dana.is>
dana wrote on Fri, Nov 01, 2019 at 21:14:46 -0500:
> (The strange option letters were, as with _bind_addresses, chosen to avoid
> conflicting with compadd. Daniel once suggested that we come up with some
> standard calling convention that resolves this head ache, but i haven't
> personally given it much further thought)
The first idea that comes to mind here is to use one of these conventions:
.
_log_priorities "${compadd_options[@]}" -Y --foo=lorem -Y --foo -Y lorem
.
or
.
_log_priorities "${compadd_options[@]}" -Y '--foo=lorem --foo lorem'
That is: use up _one_ top-level option letter and stuff all the not-compadd
--options and their arguments into the argument(s) of that top-level option
letter.
We can also do:
.
_log_priorities "${compadd_options[@]}" -- "${compadd_positional_arguments[@]}" -- "${log_priorities_argv[@]}"
.
which is similar to what zargs does. Normally there would be a question here
of how to escape a literal "--" in $compadd_positional_arguments, but for
compadd specifically, I think the following is a satisfactory workaround:
.
_log_priorities -a compadd_positional_arguments "${compadd_options[@]}" -- -- "${log_priorities_argv[@]}"
I'll leave it to you to decide whether it's worthwhile to change
_log_priorities from the version you posted.
Which reminds me: Shouldn't we mention _log_priorities in the manual, it being
a new Type/ function?
Cheers,
Daniel
> --- /dev/null
> +++ b/Completion/Unix/Type/_log_priorities
> @@ -0,0 +1,70 @@
> +#autoload
> +
> +# Complete syslog-style priorities/facilities/levels
> +#
> +# Note: 'Priority' according to syslog(3) refers to a severity level optionally
> +# ORed with a facility. We use it here in a somewhat similar manner, as this
> +# seems to cover the most ground, though we also support completing facilities
> +# alone.
> +#
> +# By default, a case-insensitive facility.level pair is completed.
> +#
> +# Some tools that accept symbolic facility/level names also accept numbers
> +# corresponding to their associated values defined in syslog.h. Since these
> +# numbers vary across systems, we don't attempt to complete them.
> +#
> +# Options:
> +# -y Complete only facilities
> +# -Y Complete only severity levels
> +# -z Complete only lower-case names
> +# -Z Complete only upper-case names
next prev parent reply other threads:[~2019-11-02 5:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-02 2:14 dana
2019-11-02 5:54 ` Daniel Shahaf [this message]
2019-11-02 6:45 ` dana
2019-11-02 6:58 ` dana
2019-11-02 7:45 ` Daniel Shahaf
2019-11-02 8:20 ` dana
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191102055423.5gzbipni3vnjo4k3@tarpaulin.shahaf.local2 \
--to=d.s@daniel.shahaf.name \
--cc=dana@dana.is \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).