New zed and refresh bug

New zed and refresh bug

[Zoltan Hidvegi]

The zed distributed with pre4 does not exit properli on ^C interrupt.
Below is a replacement for that.

It demonstrates a zle bug.  Just load this zed function, unset the BAUD
parameter (to get half-screen scrolls in zed), invoke zed -f zed, and use
the up-arrow to move to the top of the function.  On a 80x25 Linux console
with ncurses a bogous `if [[ -f $dir/$1 ]' appears on the 5th screen line
after the second half-screen scroll.

Zoltan


# zed():  Peter Stephenson <pws@s-a.amtp.liv.ac.uk>
# No other shell could do this.
# Edit small files with the command line editor.
# Use ^X^W to save, ^C to abort.
# Option -f: edit shell functions.  (Also if called as fned.)
#
# Completion: use
# compctl -f -x 'w[1,-f]' -F -- zed

local var fun ctrl_W_bind="$(bindkey '^W')"
integer tmout=TMOUT

[[ $1 = -f || $0 = fned ]] && fun=1
[[ $1 = -(|-|f) ]] && shift

[[ -z "$1" ]] && echo 'Usage: "zed filename" or "zed -f function"' && return 1

# catch interrupts
cleanup () {
  bindkey "^M" accept-line
  bindkey "^X^W" undefined-key
  bindkey "^W" "$ctrl_W_bind"
  trap - INT
  TMOUT=tmout
}

trap 'cleanup ; return 130' INT

# We do not want timeout while we are editing a file
TMOUT=0

# don't mangle !'s
setopt localoptions nobanghist

bindkey "^M" self-insert-unmeta
# Depending on your stty's, you may be able to use ^J as accept-line, else:
bindkey "^X^W" accept-line
bindkey "^W" kill-region

if ((fun)) then
  var="$(functions $1)"
  # If function is undefined but autoloadable, load it
  if [[ $var = undefined* ]] then
    local dir
    for dir in $fpath; do
      if [[ -f $dir/$1 ]] then
	var="$1() {
$(<$dir/$1)
}"
	break
      fi
    done
  elif [[ -z $var ]] then
    var="$1() {
}"
  fi
  vared var
  fun=$?
  cleanup
  (( fun == 0 )) && eval function "$var"
else
  [[ -f $1 ]] && var="$(<$1)"
  vared var
  fun=$?
  cleanup
  (( fun == 0 )) && print -r -- "$var" >| $1
fi

return 0

# End of zed

Re: New zed and refresh bug

[Peter Stephenson]

hzoli@cs.elte.hu wrote:
> The zed distributed with pre4 does not exit properli on ^C interrupt.
> ...
> integer tmout=TMOUT
> ...
>   TMOUT=tmout

I think some $ are wanted here.

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77330
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.

Re: New zed and refresh bug

[Zoltan Hidvegi]

> hzoli@cs.elte.hu wrote:
> > The zed distributed with pre4 does not exit properli on ^C interrupt.
                                                     ~~~ oops.
> > ...
> > integer tmout=TMOUT
> > ...
> >   TMOUT=tmout
> 
> I think some $ are wanted here.

The first is OK, and the second used to work because TMOUT was a special
integer parameter and $ is not necessary when assigning an integer
parameter.  But you are right that now TMOUT=$tmout or ((TMOUT=tmout))
should be used.  I'll fix it.

Zoltan

Re: New zed and refresh bug

[Zoltan Hidvegi]

> > hzoli@cs.elte.hu wrote:
> > > The zed distributed with pre4 does not exit properli on ^C interrupt.
>                                                      ~~~ oops.
> > > ...
> > > integer tmout=TMOUT
> > > ...
> > >   TMOUT=tmout
> > 
> > I think some $ are wanted here.
> 
> The first is OK, and the second used to work because TMOUT was a special
> integer parameter and $ is not necessary when assigning an integer
> parameter.  But you are right that now TMOUT=$tmout or ((TMOUT=tmout))
> should be used.  I'll fix it.

I's even simpler.  Since TMOUT is not special now, the patch below works.
Note that integer makes TMOUT local.

Zoltan


*** Functions/zed	1996/07/28 22:31:53	2.3
--- Functions/zed	1996/07/29 14:17:47
***************
*** 8,14 ****
  # compctl -f -x 'w[1,-f]' -F -- zed
  
  local var fun ctrl_W_bind="$(bindkey '^W')"
! integer tmout=TMOUT
  
  [[ $1 = -f || $0 = fned ]] && fun=1
  [[ $1 = -(|-|f) ]] && shift
--- 8,15 ----
  # compctl -f -x 'w[1,-f]' -F -- zed
  
  local var fun ctrl_W_bind="$(bindkey '^W')"
! # We do not want timeout while we are editing a file
! integer TMOUT=0
  
  [[ $1 = -f || $0 = fned ]] && fun=1
  [[ $1 = -(|-|f) ]] && shift
***************
*** 21,33 ****
    bindkey "^X^W" undefined-key
    bindkey "^W" "$ctrl_W_bind"
    trap - INT
-   TMOUT=tmout
  }
  
  trap 'cleanup ; return 130' INT
- 
- # We do not want timeout while we are editing a file
- TMOUT=0
  
  # don't mangle !'s
  setopt localoptions nobanghist
--- 22,30 ----

Re: New zed and refresh bug

[Geoff Wing]

Zoltan wrote:
:It demonstrates a zle bug.  Just load this zed function, unset the BAUD
:parameter (to get half-screen scrolls in zed), invoke zed -f zed, and use
:the up-arrow to move to the top of the function.  On a 80x25 Linux console
:with ncurses a bogous `if [[ -f $dir/$1 ]' appears on the 5th screen line
:after the second half-screen scroll.

This doesn't happen on any system I'm on.
Can anyone else reproduce this on any other systems?  I don't have access
to linux at the moment (a guy at work has got it but his computer's dead at
the moment :-(
-- 
Mason [G.C.W]  mason@werple.mira.net.au    "Hurt...Agony...Pain...LOVE-IT"

Re: New zed and refresh bug

[Zoltan Hidvegi]

> Zoltan wrote:
> :It demonstrates a zle bug.  Just load this zed function, unset the BAUD
> :parameter (to get half-screen scrolls in zed), invoke zed -f zed, and use
> :the up-arrow to move to the top of the function.  On a 80x25 Linux console
> :with ncurses a bogous `if [[ -f $dir/$1 ]' appears on the 5th screen line
> :after the second half-screen scroll.
> 
> This doesn't happen on any system I'm on.
> Can anyone else reproduce this on any other systems?  I don't have access
> to linux at the moment (a guy at work has got it but his computer's dead at
> the moment :-(

I can reproduce it in an xterm on Solaris 2.4, IBM AIX 3.2 and DEC OFS/1
V2.0, SunOS 4.1.2 and Ultrix 4.2.

I can not reproduce it on Linux with termcap (although I use a quite old
/etc/termcap) but with ncurses it is reproducible either in an xterm or on
the console.

The new contents of the line gets inserted before the bogous line so the
correct if ... which was on the screen before the scroll is shifted right
as the new contents of the line is printed.  Perhaps it happens only if the
terminal has some insert capability (I'm just guessing).

Zoltan

Re: New zed and refresh bug

[Geoff Wing]

Zoltan Hidvegi wrote:
:> Zoltan wrote:
:> :It demonstrates a zle bug.  Just load this zed function, unset the BAUD
:> :parameter (to get half-screen scrolls in zed), invoke zed -f zed, and use
:> :the up-arrow to move to the top of the function.  On a 80x25 Linux console
:> :with ncurses a bogous `if [[ -f $dir/$1 ]' appears on the 5th screen line
:> :after the second half-screen scroll.
:I can reproduce it in an xterm on Solaris 2.4, IBM AIX 3.2 and DEC OFS/1
:V2.0, SunOS 4.1.2 and Ultrix 4.2.

OK. I can repro it now - doesn't look good.  Yep, looks like an insert problem.
Will send a fix in soon (Should be today or tomorrow (Wednesday)).  Also will
change 9600 to 19200 as the minimum speed for single line scroll (unless anyone
thinks it should be 38400?)

:I can not reproduce it on Linux with termcap (although I use a quite old
:/etc/termcap) but with ncurses it is reproducible either in an xterm or on
:the console.
:
:The new contents of the line gets inserted before the bogous line so the
:correct if ... which was on the screen before the scroll is shifted right
:as the new contents of the line is printed.  Perhaps it happens only if the
:terminal has some insert capability (I'm just guessing).
-- 
Geoff Wing [mason@primenet.com.au] PrimeNet - Internet Consultancy

zle_refresh.c patch (Was: New zed and refresh bug)

[Geoff Wing]

I wrote:
:Zoltan Hidvegi wrote:
::> Zoltan wrote:
::> :It demonstrates a zle bug.  Just load this zed function, unset the BAUD
::> :parameter (to get half-screen scrolls in zed), invoke zed -f zed, and use
::> :the up-arrow to move to the top of the function.  On a 80x25 Linux console
::> :with ncurses a bogous `if [[ -f $dir/$1 ]' appears on the 5th screen line
::> :after the second half-screen scroll.
:OK. I can repro it now - doesn't look good.  Yep, looks like an insert problem.
:Will send a fix in soon (Should be today or tomorrow (Wednesday)).  Also will
:change 9600 to 19200 as the minimum speed for single line scroll (unless anyone
:thinks it should be 38400?)

I'll go over the logic for this again to confirm it but this should fix it.
I used the number of inserted characters twice in the calculations.

A couple of other matters: 
1) If you have a line with more than a screenful of stuff, then CTRL-U it
 (kill-whole-line), you don't always get your RPROMPT rewritten.  I haven't
 found an exact repro method yet (nor checked the code).  Will look into it
 a bit later.
2) testing "zed -f zed" lots of times and moving up and down between
 screenfuls twenty or more times, spewed out some allocation errors and
 coredumped.  This is with all the ZSH_MEM stuff compiled in.  The coredump
 didn't make sense (said it died during a putc() which was valid) and
 I've lost that coredump (overwritten by others) and I can't repro it.
 So unless someone else comes across it, nothing can be done.  Perhaps it was
 due to my OS (NetBSD 1.2_BETA).
 I'm just mentioning this to encourage testers to compile in ZSH_MEM stuff
 Perhaps we need an option in configure: --enable-zsh-debug-all  which enables
 all the zsh configure options? (Save me having to type in six --enable things
 every time :-)

Anyway, here's the patch:

*** zle_refresh.c	1996/07/19 17:04:33	2.9
--- zle_refresh.c	1996/07/30 05:45:42
***************
*** 122,128 ****
      int t0, hwinh;
      char *s;
  
!     if (tline || baudrate >= 9600) {	/* single line scroll */
  	hwinh = 1;
  	s = nbuf[tline];
  	for (t0 = tline; t0 < winh - 1; t0++)
--- 122,128 ----
      int t0, hwinh;
      char *s;
  
!     if (tline || baudrate >= 19200) {	/* single line scroll */
  	hwinh = 1;
  	s = nbuf[tline];
  	for (t0 = tline; t0 < winh - 1; t0++)
***************
*** 642,648 ****
  			nl = p1;
  			char_ins += i;
  		    /* if we've pushed off the right, trucate oldline */
! 			for (j = ccs, p1 = ol; *p1 && j + char_ins < winw;
  			     p1++, j++);
  			if (j + char_ins == winw)
  			    *p1 = '\0';
--- 642,648 ----
  			nl = p1;
  			char_ins += i;
  		    /* if we've pushed off the right, trucate oldline */
! 			for (j = ccs - i, p1 = ol; *p1 && j + char_ins < winw;
  			     p1++, j++);
  			if (j + char_ins == winw)
  			    *p1 = '\0';


-- 
Geoff Wing [mason@primenet.com.au] PrimeNet - Internet Consultancy

Re: New zed and refresh bug

[Bart Schaefer]

On Jul 29,  4:21pm, Zoltan Hidvegi wrote:
} Subject: Re: New zed and refresh bug
}
} I's even simpler.  Since TMOUT is not special now, the patch below works.
} Note that integer makes TMOUT local.

Yes; WHY???  This seems completely counterintuitive to me.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: New zed and refresh bug

[Zoltan Hidvegi]

> On Jul 29,  4:21pm, Zoltan Hidvegi wrote:
> } Subject: Re: New zed and refresh bug
> }
> } I's even simpler.  Since TMOUT is not special now, the patch below works.
> } Note that integer makes TMOUT local.
> 
> Yes; WHY???  This seems completely counterintuitive to me.

typeset creates local variables as in ksh.  integer is typeset -i.
I do not think it is counterintuitive.  ingeger bevaves similarily to
a local variable declaration in C.

Zoltan

Local variables and "typeset"

[Bart Schaefer]

On Aug 4,  2:42am, Zoltan Hidvegi wrote:
} Subject: Re: New zed and refresh bug
}
} > On Jul 29,  4:21pm, Zoltan Hidvegi wrote:
} > } Subject: Re: New zed and refresh bug
} > }
} > } I's even simpler.  Since TMOUT is not special now, the patch below works.
} > } Note that integer makes TMOUT local.
} > 
} > Yes; WHY???  This seems completely counterintuitive to me.
} 
} typeset creates local variables as in ksh.

Well, that's at least a reason, but it seems silly to have a special
variant of typeset called "local" which rejects certain flags like -x,
but then add "oh, by the way, typeset creates local variables too."

Is it even possible from inside a shell function to create a variable
which has a special property (such as integer, or right-justified) and
is NOT local to the function BUT is NOT exported into the environment?

It seems as though this *should* be possible, which (coupled with the
existence of "local") is why I say that it's counterintuitive to have
integer/typeset/etc. create locals.  It would make much more sense if
"typset -x" always created environment variables, "typeset" always
created shell global variables, and "local" always created locals.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"