zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <pws@ibmth.df.unipi.it>
To: zsh-workers@math.gatech.edu
Subject: PATCH: 3.1.5: Bug with special vars in user-widgets
Date: Mon, 07 Dec 1998 14:35:46 +0100	[thread overview]
Message-ID: <9812071335.AA19473@ibmth.df.unipi.it> (raw)
In-Reply-To: "Sven Wischnowsky"'s message of "Fri, 04 Dec 1998 15:06:07 NFT." <199812041406.PAA16177@beta.informatik.hu-berlin.de>

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 <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy


      reply	other threads:[~1998-12-07 13:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-12-04 14:06 Sven Wischnowsky
1998-12-07 13:35 ` Peter Stephenson [this message]

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=9812071335.AA19473@ibmth.df.unipi.it \
    --to=pws@ibmth.df.unipi.it \
    --cc=zsh-workers@math.gatech.edu \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public 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).