From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13258 invoked from network); 7 Dec 1998 13:57:45 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 7 Dec 1998 13:57:45 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id IAA07863; Mon, 7 Dec 1998 08:52:26 -0500 (EST) Resent-Date: Mon, 7 Dec 1998 08:52:26 -0500 (EST) Message-Id: <9812071335.AA19473@ibmth.df.unipi.it> To: zsh-workers@math.gatech.edu Subject: PATCH: 3.1.5: Bug with special vars in user-widgets In-Reply-To: "Sven Wischnowsky"'s message of "Fri, 04 Dec 1998 15:06:07 NFT." <199812041406.PAA16177@beta.informatik.hu-berlin.de> Date: Mon, 07 Dec 1998 14:35:46 +0100 From: Peter Stephenson Resent-Message-ID: <"H0YgZ2.0.ow1.QszQs"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4709 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Sven Wischnowsky wrote: > do-addx () { > LBUFFER="${LBUFFER}x" > } > > zle -N do-addx > > bindkey x do-addx > > Then type `x' twice. This gives a segmentation fault because the > definitions of the widget special parameters from the first invocation > weren't deleted, so that createparam() returns zero in > makezleparams(). > Removing the `| PM_SPECIAL' in line 74 in zle_params.c fixes this, but > I don't know if this is correct, so I won't produce a patch for this. The PM_SPECIAL needs to be set because the get/set functions for the variables are non-standard. I resurrected this behaviour in 4662 because it's important for some special parameters that they don't get deleted. However, the zle_params code seems to assume that unsetparam() will delete such parameters, because if it doesn't the existing value of LBUFFER, if any, will be stomped on, so the idea of having the zle parameters as local fails in an odd way --- the old value is permanently hidden. Goodness knows what subsequent assignments to LBUFFER from outside zle will do. I don't understand quite what's supposed to be happening so I haven't changed that. I think, however, that what is needed is avoid either the use of unsetparam() and remove the zle special parameters by hand, or add a flag to remove specials in some circumstances. There are some other changes to the parameter I code I don't understand, but for some reason createparam() has been set to return NULL if the parameter was unset but in the parameter table, even though it clears the unset flag. Given that behaviour this patch will work. *** Src/Zle/zle_params.c.pm Wed Apr 29 23:42:44 1998 --- Src/Zle/zle_params.c Mon Dec 7 14:09:33 1998 *************** *** 72,77 **** --- 72,80 ---- for(zp = zleparams; zp->name; zp++) { Param pm = createparam(zp->name, zp->type | PM_SPECIAL); + if (!pm) + pm = (Param) paramtab->getnode(paramtab, zp->name); + DPUTS(!pm, "param not set in makezleparams"); pm->level = locallevel; pm->u.data = zp->data; -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy