From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6112 invoked by alias); 13 Jul 2016 05:06:30 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 21752 Received: (qmail 6629 invoked from network); 13 Jul 2016 05:06:30 -0000 X-Qmail-Scanner-Diagnostics: from hermes.apache.org by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(140.211.11.3):SA:0(-1.3/5.0):. Processed in 0.209132 secs); 13 Jul 2016 05:06:30 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: danielsh@apache.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at apache.org does not designate permitted sender hosts) Date: Wed, 13 Jul 2016 04:59:46 +0000 From: Daniel Shahaf To: zsh-users@zsh.org Subject: Re: ${(k)widgets} v. 'zle -la' Message-ID: <20160713045946.GA14500@tarsus.local2> References: <20160705045758.GA18441@tarsus.local2> <160705140120.ZM17175__36700.8317648017$1467752558$gmane$org@torch.brasslantern.com> <20160707020023.GA3859@tarsus.local2> <160707094921.ZM23499__38105.0642965876$1467910230$gmane$org@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <160707094921.ZM23499__38105.0642965876$1467910230$gmane$org@torch.brasslantern.com> User-Agent: Mutt/1.5.23 (2014-03-12) Bart Schaefer wrote on Thu, Jul 07, 2016 at 09:49:21 -0700: > On Jul 7, 2:00am, Daniel Shahaf wrote: > } > } Is the following behaviour also intentional? Testing a key's presence > } in the associative array in different ways gives different results: > } > } % bindkey foo bar > } % () { print $(( $argv[(I)bar] > 0 )) } ${(k)widgets} > } 1 > } % print ${+widgets[bar]} > } 0 > > It's intentional in that hash table entries are parameter values and > parameters can exist but be unset, like declaring something local and > then unsetting it; $widgets[bar] returns a "value" that is equivalent > to "unset" when the widget doesn't exist. > *nod* > It's not intentional in that for normal hash tables there's no way to > create such an entry, so the ramifications on e.g. ${+...} of having > a special hash where a key that is present is only a placeholder, were > not fully thought through. *nod* For future reference, attempting to creating such an entry generates the following error: % typeset -A h=(k1 v1 k2 v2) % () { local 'h[k1]' } (anon):local: h[k1]: can't create local array elements > On the other hand it's the only result that accurately represents the > situation. I've been wondering about a docs patch for this. Does the following make sense? Unidiff: diff --git a/Doc/Zsh/mod_zleparameter.yo b/Doc/Zsh/mod_zleparameter.yo index 03d5047..76d23ba 100644 --- a/Doc/Zsh/mod_zleparameter.yo +++ b/Doc/Zsh/mod_zleparameter.yo @@ -15,14 +15,16 @@ This array contains the names of the keymaps currently defined. ) vindex(widgets) item(tt(widgets))( -This associative array contains one entry per widget defined. The name +This associative array contains one entry per widget. The name of the widget is the key and the value gives information about the -widget. It is either the string `tt(builtin)' for builtin widgets, a -string of the form `tt(user:)var(name)' for user-defined widgets, -where var(name) is the name of the shell function implementing the -widget, or it is a string of the form -`tt(completion:)var(type)tt(:)var(name)', for completion widgets. In -the last case var(type) is the name of the builtin widgets the +widget. It is either + the string `tt(builtin)' for builtin widgets, + a string of the form `tt(user:)var(name)' for user-defined widgets, + where var(name) is the name of the shell function implementing the widget, + a string of the form `tt(completion:)var(type)tt(:)var(name)' + for completion widgets, + or a null value if the widget is not yet fully defined. +In the penultimate case, var(type) is the name of the builtin widget the completion widget imitates in its behavior and var(name) is the name of the shell function implementing the completion widget. ) That diff reindents, so here's an equivalent wdiff [should be easier to review]: @@ -15,14 +15,16 @@ This array contains the names of the keymaps currently defined. ) vindex(widgets) item(tt(widgets))( This associative array contains one entry per [-widget defined.-] {+widget.+} The name of the widget is the key and the value gives information about the widget. It is either the string `tt(builtin)' for builtin widgets, a string of the form `tt(user:)var(name)' for user-defined widgets, where var(name) is the name of the shell function implementing the widget, [-or it is-] a string of the form [-`tt(completion:)var(type)tt(:)var(name)',-] {+`tt(completion:)var(type)tt(:)var(name)'+} for completion [-widgets.-] {+widgets, or a null value if the widget is not yet fully defined.+} In the [-last case-] {+penultimate case,+} var(type) is the name of the builtin [-widgets-] {+widget+} the completion widget imitates in its behavior and var(name) is the name of the shell function implementing the completion widget. ) [syntax highlighting for that is ':setf wdiff' in vim; no idea about others]