${(k)widgets} v. 'zle -la'

${(k)widgets} v. 'zle -la'

[Daniel Shahaf]

$ zsh -f
% bindkey zzzzzz foobar
% zle -la | grep foobar                   
% print -rl -- ${(k)widgets} | grep foobar 
foobar
% 

Is it intentional that 'foobar' is listed by 'zle -la' but not by
${(k)widgets}?  I'd expected those two to enumerate the same set of
widgets.

Observations:

- The manual speaks of "all existing widgets" for the former and of "all
  defined widgets" for the latter.

- The thingy has the 'DISABLED' flag:

  (gdb) p *(Thingy)thingytab->getnode2(thingytab, "foobar") 
  $1 = {next = 0x7ffff5e73688 <thingies+5640>, nam = 0x6fb210 "foobar", flags = 1, rc = 1, widget = 0x0, samew = 0x0}

Re: ${(k)widgets} v. 'zle -la'

[Bart Schaefer]

On Jul 5,  4:57am, Daniel Shahaf wrote:
} Subject: ${(k)widgets} v. 'zle -la'
}
} $ zsh -f
} % bindkey zzzzzz foobar
} % zle -la | grep foobar                   
} % print -rl -- ${(k)widgets} | grep foobar 
} foobar
} % 
} 
} Is it intentional that 'foobar' is listed by 'zle -la' but not by
} ${(k)widgets}?  I'd expected those two to enumerate the same set of
} widgets.

It's actually the other way around, yes?  It's in $widgets but not in
"zle -la"?  

} Observations:
} 
} - The manual speaks of "all existing widgets" for the former and of "all
}   defined widgets" for the latter.

("the former" == zle, "the latter" == $widgets) That's not quite what the
doc for $widgets says, but in any case you're missing the crucial bit:
"zle -la" lists only USER-DEFINED widgets, wheras $widgets includes ALL
widgets.  In your example the "foobar" widget doesn't exist yet, so it
isn't user-defined, so "zle -la" doesn't show it.

Now you might argue that any widget that isn't a builtin must be user-
defined, so naming a widget that doesn't exist should cause that widget
to be listed by "zle -la".  However, you'd be forgetting that zmodload
may pull in additional builtin widgets, so there's no reason for zle to
presume that "foobar" will eventually become user-defined as opposed to
becoming a module-defined builtin.

Re: ${(k)widgets} v. 'zle -la'

[Daniel Shahaf]

Bart Schaefer wrote on Tue, Jul 05, 2016 at 14:01:20 -0700:
> On Jul 5,  4:57am, Daniel Shahaf wrote:
> } $ zsh -f
> } % bindkey zzzzzz foobar
> } % zle -la | grep foobar                   
> } % print -rl -- ${(k)widgets} | grep foobar 
> } foobar
> } % 
> 
> "zle -la" lists only USER-DEFINED widgets, wheras $widgets includes ALL
> widgets.  In your example the "foobar" widget doesn't exist yet, so it
> isn't user-defined, so "zle -la" doesn't show it.

Thanks for the explanation.

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

I ran into this while trying to clarify the docs of $widgets in line
with your answer.

Thanks again,

Daniel

Re: ${(k)widgets} v. 'zle -la'

[Bart Schaefer]

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.

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.

On the other hand it's the only result that accurately represents the
situation.

-- 
Barton E. Schaefer

Re: ${(k)widgets} v. 'zle -la'

[Daniel Shahaf]

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]

Re: ${(k)widgets} v. 'zle -la'

[Peter Stephenson]

On Wed, 13 Jul 2016 04:59:46 +0000
Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> I've been wondering about a docs patch for this.  Does the following make
> sense?

I think so.

pws