From: Daniel Shahaf <d.s@daniel.shahaf.name> To: Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> Cc: Zsh Users <zsh-users@zsh.org> Subject: Re: More-verbose tab-completion idiom? Date: Thu, 17 Mar 2022 16:30:12 +0000 [thread overview] Message-ID: <20220317163012.GT7687@tarpaulin.shahaf.local2> (raw) In-Reply-To: <YjKbOBHSJ++JZhH2@fullerene.field.pennock-tech.net> Phil Pennock wrote on Wed, Mar 16, 2022 at 22:21:44 -0400: > On 2022-03-16 at 18:20 -0700, Bart Schaefer wrote: > > but that assumes you don't have colons or commas or braces in the keys > > or descriptions. > > Alas, one of the fields is almost guaranteed to be a URL, thus > containing a colon, and all of those are fair game in the description > field. > > In case anyone is interested: while nats(1) (open-source, part of the > CNCF "NATS" project) is changing fast enough that we probably don't want > the completion shipping with zsh at this time, here's a copy of the > completion I'm using today: > > https://get-nats.io/zsh.complete.nats Review in unidiff form. Meant as suggestions to pick and choose from. I forgot to annotate a few other function definitions with the same "don't unconditionaly redefine" idiom. Cheers, Daniel [[[ --- https://get-nats.io/zsh.complete.nats +++ https://get-nats.io/zsh.complete.nats @@ -23,7 +23,7 @@ # extra-verbose is documented as for features which will slow completion speed. if zstyle -t ":completion:${curcontext}:" extra-verbose; then - if (( $+commands[jq] )); then + if type jq > /dev/null; then nats_everbose=1 else : # should we report this back as an error somehow? @@ -32,15 +32,16 @@ local -r nats_ctxdir="${XDG_CONFIG_HOME:-$HOME/.config}/nats/context" -nats_contexts=( "$nats_ctxdir"/*(:t:r) ) +nats_contexts=( "$nats_ctxdir"/*(N:t:r) ) # TODO: come up with a cache expiration strategy and integrate this with use-cache # or at least a global variable. +(( ${+functions[_nats_context_names]} )) || _nats_context_names() { if (( nats_everbose )); then described_contexts=() for nctx in "${nats_contexts[@]}"; do - described_contexts+=("${nctx//:/\\:}:$(jq -r .description < "$nats_ctxdir/$nctx.json")") + described_contexts+=("${nctx//:/\\:}:$(_call_program jq "jq -r .description < \"${(q)nats_ctxdir}/${(q)nctx}.json\"")") done _describe nats-contexts described_contexts else @@ -55,7 +56,7 @@ ;; esac -nats_decorate_flags_desc=( +nats_decorate_flags_desc=( # this assumes zsh is-at-least 5.5 [context]='NATS user context' [tlscert]='TLS client auth public certificate' [tlskey]='TLS client auth private key' @@ -86,12 +87,12 @@ # We populate a complete set first, so that even if we don't have more details below, # we can still tab-complete it; it will just be missing some data -nats_commands=( $(${words[1]} --completion-bash ${words[1]}) ) +nats_commands=( $(_call_program completion-bash "${words[1]} --completion-bash ${words[1]}") ) # Most flags can appear anywhere; this is not a git-style "top command flags" # vs "subcommand flags", but instead "one pool of flags which gains extra # entries for some subcommands". -nats_flags=( $(${words[1]} --completion-bash ${words[1]} --) ) +nats_flags=( $(${words[1]} --completion-bash ${words[1]} --) ) # TODO add _call_program _nats_decorate_flags() { #zle -M "decorating ..."; zle -R local flag directive @@ -135,7 +136,7 @@ ;; (after-command) curcontext=${curcontext%:*:*}:nats-$words[1]: - nats_sub=( $("$cmdword" --completion-bash "${words[@]}") ) + nats_sub=( $("$cmdword" --completion-bash "${words[@]}") ) # TODO add _call_program if [[ ${#nats_sub} -eq 0 ]]; then # terminal nats_flags=( $("$cmdword" --completion-bash "${words[@]}" --) ) ]]] > (I know that I'm misusing the per-flag description by listing it twice in > this way for the two different location but I haven't yet come up with > an easier-to-maintain approach) > > -Phil >
next prev parent reply other threads:[~2022-03-17 16:37 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-17 0:26 Phil Pennock 2022-03-17 0:50 ` Daniel Shahaf 2022-03-17 1:26 ` Phil Pennock 2022-03-17 1:20 ` Bart Schaefer 2022-03-17 1:24 ` Bart Schaefer 2022-03-17 2:21 ` Phil Pennock 2022-03-17 16:30 ` Daniel Shahaf [this message] 2022-03-17 20:44 ` Bart Schaefer 2022-03-17 21:38 ` Phil Pennock 2022-03-18 0:28 ` Daniel Shahaf 2022-03-18 1:16 ` Phil Pennock
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=20220317163012.GT7687@tarpaulin.shahaf.local2 \ --to=d.s@daniel.shahaf.name \ --cc=zsh-users@zsh.org \ --cc=zsh-workers+phil.pennock@spodhuis.org \ --subject='Re: More-verbose tab-completion idiom?' \ /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
Code repositories for project(s) associated with this 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).