Re: bindkey <whatever> history-beginning-search-backwards; echo $widgts = crash

[Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx>]

On 2007-05-21 at 18:46 -0700, Phil Pennock wrote:
> This is a bug when there is no widget with the supplied name; the value
> for the type can't be calculated.  The code which loops over the widgets
> doesn't notice that the widget doesn't really exist and the code which
> produces a stringification doesn't handle it.

Is it better for the $widgets associative array to pretend that such a
key doesn't exist, or to acknowledge that it does exist with undefined
value?

Previous patch implemented the latter.

This patch implements the former, keeping the "undefined" fallback
around just in case there's another bug.

Intuitively, the $widgets array shouldn't pretend that nodes don't
exist, but then there's conflicting behaviour with getpmwidgets() which
returns an empty string.

I leave the decision to those with more experience.
-Phil

diff -urp zsh-head/Src/Zle/zleparameter.c zsh-bindkey-crash/Src/Zle/zleparameter.c
--- zsh-head/Src/Zle/zleparameter.c	Tue Mar  7 13:31:44 2006
+++ zsh-bindkey-crash/Src/Zle/zleparameter.c	Mon May 21 18:52:20 2007
@@ -75,6 +75,8 @@ createspecialhash(char *name, GetNodeFun
 static char *
 widgetstr(Widget w)
 {
+    if (!w)
+	return dupstring("undefined");
     if (w->flags & WIDGET_INT)
 	return dupstring("builtin");
     if (w->flags & WIDGET_NCOMP) {
@@ -127,6 +129,8 @@ scanpmwidgets(UNUSED(HashTable ht), Scan
 
     for (i = 0; i < thingytab->hsize; i++)
 	for (hn = thingytab->nodes[i]; hn; hn = hn->next) {
+	    if (!((Thingy) hn)->widget)
+		continue;
 	    pm.node.nam = hn->nam;
 	    if (func != scancountparams &&
 		((flags & (SCANPM_WANTVALS|SCANPM_MATCHVAL)) ||