Various vared problems with screen refresh, etc.

Various vared problems with screen refresh, etc.

[Bart Schaefer]

I'm encountering all the problems I'm about to describe while using PWS's
"zse" (zstyle edit) function.  Stripped down, it looks like:

zse() {
  emulate -L zsh
  local styles="$(zstyle -L)"
  vared styles && eval $styles
}

Use it with a small enough window that all the styles won't fit on one
screen, so you have to scroll up and down.  In fact it's probably best
if they require more than -two- screens, but I'm not sure.

First problem:  Display refresh when a "minibuffer" command is used.
Make sure the cursor is at the last line (do end-of-buffer-or-history).
Invoke history-incremental-search-backward or -forward and look closely
at the display.  In my case, I'm seeing some lines that should be off
the top of the screen appearing above the `bck-i-search:' prompt.  I
think a refresh computation somewhere is counting down N lines from the
first line in the whole buffer, rather than down N lines from the first
visible line.

Second problem:  Even though history is not supposed to be available
(no -h argument to vared), history-incremental-search-backward is able
to run off into the history if it doesn't find the search string in the
current buffer.  This is a bit inconvenient as the only way to get back
to the original contents is to history-incremental-search-forward for a
string that appears there.

Third problem:  After finding the desired word with incremental search,
forward-char or backward-char can be used (this is not the problem yet)
to break out of the search and move around.  However, the cursor doesn't
begin responding immediately -- in fact, it freezes until you stop typing
for a while, and then suddenly jumps.  Thereafter it behaves normally
again.  This seems to be a problem with 4.1.x-dev that is NOT a problem
with 4.0.1 (haven't tried it in 4.0.2), and it's also not restricted to
vared.  Input gets "sticky" and refresh gets "jumpy" when scrolling up
and down in the normal history, too, almost any time a line longer than
$COLUMNS scrolls past.  This is especially annoying because several whole
history lines may flash by unseen when the refresh finally "jumps" (I've
"missed" as many as a dozen that way).

That last one has me quite baffled; I don't see any differences between
the 4.0.1 and 4.1.0-dev sources that would explain it; I'm not using a
shell function instead of a builtin widget anywhere; both binaries were
compiled with the same debugging options.  Anyone have any ideas?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Various vared problems with screen refresh, etc.

[Geoff Wing]

Bart Schaefer <schaefer@brasslantern.com> typed:
:I'm encountering all the problems I'm about to describe while using PWS's
:"zse" (zstyle edit) function.  Stripped down, it looks like:
[...]
:Use it with a small enough window that all the styles won't fit on one
:screen, so you have to scroll up and down.  In fact it's probably best
:if they require more than -two- screens, but I'm not sure.
:
:First problem:  Display refresh when a "minibuffer" command is used.
:Make sure the cursor is at the last line (do end-of-buffer-or-history).
:Invoke history-incremental-search-backward or -forward and look closely
:at the display.  In my case, I'm seeing some lines that should be off
:the top of the screen appearing above the `bck-i-search:' prompt.  I
:think a refresh computation somewhere is counting down N lines from the
:first line in the whole buffer, rather than down N lines from the first
:visible line.

My problem.  I'll provide a patch for it.  It's duplicating a scroll
around zle_refresh.c:436+ and snextline define.

Regards,
-- 
Geoff Wing : <gcw@pobox.com>
Rxvt Stuff : <gcw@rxvt.org>
Zsh Stuff  : <gcw@zsh.org>

PATCH: Status line fixes (Was: Various vared problems with screen refresh, etc.)

[Geoff Wing]

Geoff Wing <gcw@zsh.org> typed:
:Bart Schaefer <schaefer@brasslantern.com> typed:
::First problem:  Display refresh when a "minibuffer" command is used.
::Make sure the cursor is at the last line (do end-of-buffer-or-history).
::Invoke history-incremental-search-backward or -forward and look closely
::at the display.  In my case, I'm seeing some lines that should be off
::the top of the screen appearing above the `bck-i-search:' prompt.  I
::think a refresh computation somewhere is counting down N lines from the
::first line in the whole buffer, rather than down N lines from the first
::visible line.
:My problem.  I'll provide a patch for it.  It's duplicating a scroll
:around zle_refresh.c:436+ and snextline define.

Patch for three display things:
1) status line display was being mucked up
2) continuation marker "<...." for line extension off bottom right wasn't
   working properly
3) status line continuation marker "<....>" at end of first status line
   wasn't working properly

This slightly overloads "snextline" define in that one case should only
exist at the first usage however it's slightly tidier to do it this way
instead of making sure mostly duplicate code is synchronised.


Index: Src/Zle/zle_refresh.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_refresh.c,v
retrieving revision 1.1.1.19
diff -u -r1.1.1.19 zle_refresh.c
--- Src/Zle/zle_refresh.c	2000/03/25 00:22:06	1.1.1.19
+++ Src/Zle/zle_refresh.c	2001/08/14 11:45:09
@@ -223,16 +223,25 @@
     if (ln != winh - 1)					\
 	ln++;						\
     else						\
-	if (tosln < 3) {				\
+	if (tosln > ln) {				\
+	    tosln--;					\
+	    if (nvln > 1) {				\
+		scrollwindow(0);			\
+		nvln--;					\
+	    } else					\
+		more_end = 1;				\
+	} else if (tosln > 2 && nvln > 1) {		\
+	    tosln--;					\
+	    if (tosln <= nvln) {			\
+		scrollwindow(0);			\
+		nvln--;					\
+	    } else {					\
+		scrollwindow(tosln);			\
+		more_end = 1;				\
+	    }						\
+	} else {					\
 	    more_status = 1;				\
 	    scrollwindow(tosln + 1);			\
-	} else if (tosln - 1 <= nvln) {			\
-	    scrollwindow(0);				\
-	    if (nvln)					\
-		nvln--, tosln--;			\
-	} else {					\
-	    tosln--;					\
-	    scrollwindow(tosln);			\
 	}						\
     if (!nbuf[ln])					\
 	nbuf[ln] = (char *)zalloc(winw + 2);		\
@@ -435,13 +444,6 @@
 
     if (statusline) {
 	tosln = ln + 1;
-        if (ln == winh - 1) {
-	    if (nvln > 0) {
-		scrollwindow(0);
-		nvln--;
-	    }
-	    tosln--;
-	}
 	nbuf[ln][winw + 1] = '\0';	/* text not wrapped */
 	snextline
 	t = (unsigned char *)statusline;
@@ -460,23 +462,43 @@
 		snextline
 	    }
 	}
+	if (s == sen)
+	    snextline
     }
+    *s = '\0';
 
 /* insert <.... at end of last line if there is more text past end of screen */
     if (more_end) {
 	if (!statusline)
 	    tosln = winh;
-	strncpy(nbuf[tosln - 1] + winw - 7, " <.... ", 7);
+	s = nbuf[tosln - 1];
+	sen = s + winw - 7;
+	for (; s < sen; s++) {
+	    if (*s == '\0') {
+		for (; s < sen; )
+		    *s++ = ' ';
+		break;
+	    }
+	}
+	strncpy(sen, " <.... ", 7);
 	nbuf[tosln - 1][winw] = nbuf[tosln - 1][winw + 1] = '\0';
     }
 
 /* insert <....> at end of first status line if status is too big */
     if (more_status) {
-	strncpy(nbuf[tosln] + winw - 8, " <....> ", 8);
+	s = nbuf[tosln];
+	sen = s + winw - 8;
+	for (; s < sen; s++) {
+	    if (*s == '\0') {
+		for (; s < sen; )
+		    *s++ = ' ';
+		break;
+	    }
+	}
+	strncpy(sen, " <....> ", 8);
 	nbuf[tosln][winw] = nbuf[tosln][winw + 1] = '\0';
     }
 
-    *s = '\0';
     nlnct = ln + 1;
     for (ln = nlnct; ln < winh; ln++)
 	zfree(nbuf[ln], winw + 2), nbuf[ln] = NULL;

-- 
Geoff Wing : <gcw@pobox.com>
Rxvt Stuff : <gcw@rxvt.org>
Zsh Stuff  : <gcw@zsh.org>

Re: Various vared problems with screen refresh, etc.

[Bart Schaefer]

On Aug 14, I wrote:
}
} Third problem:  After finding the desired word with incremental search,
} forward-char or backward-char can be used (this is not the problem yet)
} to break out of the search and move around.  However, the cursor doesn't
} begin responding immediately -- in fact, it freezes until you stop typing
} for a while, and then suddenly jumps.  Thereafter it behaves normally
} again.  This seems to be a problem with 4.1.x-dev that is NOT a problem
} with 4.0.1 (haven't tried it in 4.0.2), and it's also not restricted to
} vared.

I've finally figured out what this is:  The BAUD parameter was set in my
4.1.0-dev shells but unset in 4.0.1.  This probably has to do with how I
started up the shells (4.0.1 is installed, 4.1.0-dev I'm running out of a
build tree, and I have conditional code to `unset BAUD' in startup files).
However:

This is at least a bug in the documentation.  BAUD is listed as a parameter
used by the shell, not one set by the shell, and I'm not assigning to it.

Looking at Src/params.c, I see BAUD gets set when HAVE_SELECT is defined.
Nowadays this is probably the case more often than it is not.

Would anyone object to moving the BAUD doc into the "set by" section?  It
probably ought to get at least a cross-reference somewhere in the ZLE
section as well.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

History and vared

[Bart Schaefer]

Hey, Wayne, as long as you're listening and thinking about history fixes,
do you have any ideas about this one?

On Aug 14, I wrote:
}
} Second problem:  Even though history is not supposed to be available
} (no -h argument to vared), history-incremental-search-backward is able
} to run off into the history if it doesn't find the search string in the
} current buffer.  This is a bit inconvenient as the only way to get back
} to the original contents is to history-incremental-search-forward for a
} string that appears there.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

PATCH: ZLE doc xref to BAUD, fix doc build error

[Bart Schaefer]

On Sep 15,  6:43pm, Bart Schaefer wrote:
}
} Would anyone object to moving the BAUD doc into the "set by" section?  It
} probably ought to get at least a cross-reference somewhere in the ZLE
} section as well.

Hmm, LINES and COLUMNS would appear to have similar issues.

This adds the cross reference without (yet) moving anything to a new
section.  It also fixes the recently-reported problem with the reference
to the zsh/net/tcp module doc.

Index: Doc/Makefile.in
===================================================================
diff -u -r1.7 Makefile.in
--- Doc/Makefile.in	2001/09/05 15:22:30	1.7
+++ Doc/Makefile.in	2001/09/15 20:18:39
@@ -61,7 +61,7 @@
 Zsh/mod_mapfile.yo Zsh/mod_mathfunc.yo Zsh/mod_parameter.yo Zsh/mod_pcre.yo \
 Zsh/mod_sched.yo Zsh/mod_stat.yo Zsh/mod_termcap.yo Zsh/mod_terminfo.yo \
 Zsh/mod_zftp.yo Zsh/mod_zle.yo Zsh/mod_zleparameter.yo \
-Zsh/mod_zprof.yo Zsh/mod_zpty.yo Zsh/mod_zutil.yo
+Zsh/mod_zprof.yo Zsh/mod_zpty.yo Zsh/mod_zutil.yo Zsh/mod_tcp.yo
 
 YODLSRC = zmacros.yo zman.yo ztexi.yo Zsh/arith.yo Zsh/builtins.yo \
 Zsh/compat.yo Zsh/compctl.yo Zsh/compsys.yo Zsh/compwid.yo Zsh/cond.yo \
Index: Doc/Zsh/zle.yo
===================================================================
diff -u -r1.3 zle.yo
--- Doc/Zsh/zle.yo	2001/09/05 15:22:31	1.3
+++ Doc/Zsh/zle.yo	2001/09/15 20:30:01
@@ -21,6 +21,14 @@
 is similar to bf(ksh), and uses no termcap sequences.  If tt(TERM) is
 "emacs", the tt(ZLE) option will be unset by default.
 
+vindex(BAUD, use of)
+vindex(COLUMNS, use of)
+vindex(LINES, use of)
+The parameters tt(BAUD), tt(COLUMNS), and tt(LINES) are also used by the
+line editor.
+ifzman(See em(Parameters Used By The Shell) in zmanref(zshparam))\
+ifnzman(noderef(Parameters Used By The Shell)).
+
 startmenu()
 menu(Keymaps)
 menu(Zle Builtins)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Various vared problems with screen refresh, etc.

[Peter Stephenson]

Bart Schaefer wrote:
> Would anyone object to moving the BAUD doc into the "set by" section?

If it *is* set by the shell, that would seem to me pretty logical.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk

Re: Various vared problems with screen refresh, etc.

[Bart Schaefer]

On Sep 16, 12:21am, Peter Stephenson wrote:
} Subject: Re: Various vared problems with screen refresh, etc.
}
} Bart Schaefer wrote:
} > Would anyone object to moving the BAUD doc into the "set by" section?
} 
} If it *is* set by the shell, that would seem to me pretty logical.

Well, you'd think so, but ... the following parameters are all set by
the shell, yet described in the "used by" section:

BAUD        IFS          module_path  PROMPT3   PS3          TMPPREFIX
COLUMNS     KEYTIMEOUT   NULLCMD      PROMPT4   PS4          WATCHFMT
fpath       LINES        path         prompt    READNULLCMD  WORDCHARS
histchars   LOGCHECK     PROMPT       PS1       SPROMPT
HISTCHARS   MAILCHECK    PROMPT2      PS2       TIMEFMT

So you'd think the distinction might be that "used by" are parameters
to which assignment changes the behavior of the shell, regardless of
whether the shell supplies a default value; but in that case, what are
argv, EGID, EUID, GID, OPTARG, OPTIND, SECONDS, and UID doing in the
"set by" section?

Also in "used by" are REPLY and reply, which sometimes are set and other
times are used, but _ (underscore), which is similar, is in "set by".

There also doesn't seem to be any sort of ordering in the first page or
so of "set by".  I suppose status and pipestatus are out of order to be
closer to ?, but then what's 0 doing in between them?  (OK, I'll stop
ranting now.)

So perhaps we need either more or fewer categories.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: History and vared

[Wayne Davison]

On Sat, 15 Sep 2001, Bart Schaefer wrote:
> On Aug 14, I wrote:
> } (no -h argument to vared), history-incremental-search-backward is able
> } to run off into the history if it doesn't find the search string in the
> } current buffer.

Thanks for the reminder -- I must have missed that comment the first
time around.  Here's the fix.

..wayne..

---8<------8<------8<------8<---cut here--->8------>8------>8------>8---
Index: Src/Zle/zle_hist.c
--- Src/Zle/zle_hist.c	2001/09/03 01:39:20	1.5
+++ Src/Zle/zle_hist.c	2001/09/17 18:06:25
@@ -720,7 +720,8 @@
 		    statusline = ibuf + NORM_PROMPT_POS;
 		    break;
 		}
-		if (!(he = movehistent(he, dir, hist_skip_flags))) {
+		if (!(zlereadflags & ZLRF_HISTORY)
+		 || !(he = movehistent(he, dir, hist_skip_flags))) {
 		    if (sbptr == (int)isrch_spots[top_spot-1].len
 		     && (isrch_spots[top_spot-1].flags & ISS_FAILING))
 			top_spot--;
---8<------8<------8<------8<---cut here--->8------>8------>8------>8---