Pre-5.0.5 part 3: Heuristic for ZLE_RPROMPT_INDENT

Pre-5.0.5 part 3: Heuristic for ZLE_RPROMPT_INDENT

[Bart Schaefer]

Another one we agreed to leave for after a stable release.  This takes a
best guess at whether the terminal can handle having a character written
to the lower right corner, and removes an unnecessary import from the
environment [it is already handled correctly by the generic environment
import in createparamtable()].

diff --git a/Src/init.c b/Src/init.c
index bd871cb..da2a1bf 100644
--- a/Src/init.c
+++ b/Src/init.c
@@ -749,9 +749,8 @@ init_term(void)
 	    tcstr[TCCLEARSCREEN] = ztrdup("\14");
 	    tclen[TCCLEARSCREEN] = 1;
 	}
-#if 0	/* This might work, but there may be more to it */
+	/* This might work, but there may be more to it */
 	rprompt_indent = (hasye || !tccan(TCLEFT)) ? 1 : 0;
-#endif
     }
     return 1;
 }
@@ -1003,15 +1002,6 @@ setupvals(void)
     setiparam("COLUMNS", zterm_columns);
     setiparam("LINES", zterm_lines);
 #endif
-    {
-	/* Import from environment, overrides init_term() */
-	struct value vbuf;
-	char *name = "ZLE_RPROMPT_INDENT";
-	if (getvalue(&vbuf, &name, 1) && !(vbuf.flags & PM_UNSET))
-	    rprompt_indent = getintvalue(&vbuf);
-	else
-	    rprompt_indent = 1;
-    }
 
 #ifdef HAVE_GETRLIMIT
     for (i = 0; i != RLIM_NLIMITS; i++) {

Re: Pre-5.0.5 part 3: Heuristic for ZLE_RPROMPT_INDENT

[Oliver Kiddle]

On 2 Feb, Bart wrote:
> Another one we agreed to leave for after a stable release.  This takes a
> best guess at whether the terminal can handle having a character written
> to the lower right corner, and removes an unnecessary import from the
> environment [it is already handled correctly by the generic environment
> import in createparamtable()].

This is resulting in my cursor appearing one column more to the left
than it should. Actually, ZLE_RPROMPT_INDENT=0 with 5.0.5
is enough for that to occur. This effect seems to occur only on some
terminals but may be version specific because I get different results
for the same terminal on different systems.

None of the terminals I have are attempting to scroll when writing to
the bottom right corner. The ones that work are ignoring a subsequent
backward cursor movement – as if the cursor had really moved beyond the
edge of terminal.

The output of the following demonstrates: 
  print -lrn ${(l:$COLUMNS:):-x};echoti cub1;echoti cub1;sleep 1

On a working terminal, the cursor is just to the left of the x for the 1
second delay. On those that fail, it is two back. Is it perhaps possible
to fix this by changing from a relative to an absolute cursor movement
after the RPROMPT is displayed?

Oliver

Re: Pre-5.0.5 part 3: Heuristic for ZLE_RPROMPT_INDENT

[Bart Schaefer]

On Feb 7, 10:45am, Oliver Kiddle wrote:
}
} On 2 Feb, Bart wrote:
} > Another one we agreed to leave for after a stable release.  This takes a
} > best guess at whether the terminal can handle having a character written
} > to the lower right corner
} 
} This is resulting in my cursor appearing one column more to the left
} than it should.

This is one of the expected bad behaviors which is the reason we left
out the hueristic.

} Actually, ZLE_RPROMPT_INDENT=0 with 5.0.5 is enough for that to occur.

That would be expected; the heuristic doesn't do anything other than
set an initial value for ZLE_RPROMPT_INDENT.

} This effect seems to occur only on some terminals but may be version
} specific because I get different results for the same terminal on
} different systems.

More likely it's termcap/terminfo database version specific.  Can you
compare the terminfo settings for two cases of the same terminal giving
different behavior and report the difference?

If it's not terminfo, it may be some kind of emulation option that has
a different setting in the Xdefaults etc.

} None of the terminals I have are attempting to scroll when writing to
} the bottom right corner. The ones that work are ignoring a subsequent
} backward cursor movement - as if the cursor had really moved beyond the
} edge of terminal.

This is exactly the thing that terminfo reports unreliably, which is why
the default for years has been to keep the right prompt indented one
space from the right margin.  I was hoping the newer sam/YE terminfo/cap
value would provide the right clue, and be widespread enough now to be
reliable.

If we can't improve the heuristic we should just remove it again.

} Is it perhaps possible to fix this by changing from a relative to an
} absolute cursor movement after the RPROMPT is displayed?

Unfortunately, no; once completion listings and other stuff that is
displayed below the prompt become involved, ZLE no longer knows what
its absolute cursor position ought to be.  It would need a really big
rewrite to do real full-screen management for absolute positioning to
work.

Re: Pre-5.0.5 part 3: Heuristic for ZLE_RPROMPT_INDENT

[Bart Schaefer]

} } This effect seems to occur only on some terminals but may be version
} } specific because I get different results for the same terminal on
} } different systems.
} 
} More likely it's termcap/terminfo database version specific.  Can you
} compare the terminfo settings for two cases of the same terminal giving
} different behavior and report the difference?
} 
} If it's not terminfo, it may be some kind of emulation option that has
} a different setting in the Xdefaults etc.

I've just compared xterm on my old CentOS box (which does not show the
off-by-one effect) with xterm on my much newer Ubuntu box (where I *do*
see the effect).  Except for some keypad definitions, the terminfo are
identical.

However, on CentOS, my settings for class XTerm include ReverseWrap:true
whereas on Ubuntu I'm using the defaults.  Normally this would mean that
terminfo/cap should have the "bw" capability, but it's false in both
cases because of course it has to describe the default settings.

So perhaps the following patch ...?  (The change to zle_refresh.c is to
silence a spurious "may be used uninitialized" warning.)


diff --git a/Src/Zle/zle_refresh.c b/Src/Zle/zle_refresh.c
index fd54857..2bedbc4 100644
--- a/Src/Zle/zle_refresh.c
+++ b/Src/Zle/zle_refresh.c
@@ -977,7 +977,7 @@ zrefresh(void)
     int tmpalloced;		/* flag to free tmpline when finished	     */
     int remetafy;		/* flag that zle line is metafied	     */
     int txtchange;		/* attributes set after prompts              */
-    int rprompt_off;		/* Offset of rprompt from right of screen    */
+    int rprompt_off = 1;	/* Offset of rprompt from right of screen    */
     struct rparams rpms;
 #ifdef MULTIBYTE_SUPPORT
     int width;			/* width of wide character		     */
diff --git a/Src/init.c b/Src/init.c
index da2a1bf..fd12412 100644
--- a/Src/init.c
+++ b/Src/init.c
@@ -77,7 +77,7 @@ mod_export int tclen[TC_COUNT];
 /**/
 int tclines, tccolumns;
 /**/
-mod_export int hasam, hasxn, hasye;
+mod_export int hasam, hasbw, hasxn, hasye;
 
 /* Value of the Co (max_colors) entry: may not be set */
 
@@ -698,6 +698,7 @@ init_term(void)
 
 	/* check whether terminal has automargin (wraparound) capability */
 	hasam = tgetflag("am");
+	hasbw = tgetflag("bw");
 	hasxn = tgetflag("xn"); /* also check for newline wraparound glitch */
 	hasye = tgetflag("YE"); /* print in last column does carriage return */
 
@@ -750,7 +751,7 @@ init_term(void)
 	    tclen[TCCLEARSCREEN] = 1;
 	}
 	/* This might work, but there may be more to it */
-	rprompt_indent = (hasye || !tccan(TCLEFT)) ? 1 : 0;
+	rprompt_indent = ((hasam && !hasbw) || hasye || !tccan(TCLEFT));
     }
     return 1;
 }

Re: Pre-5.0.5 part 3: Heuristic for ZLE_RPROMPT_INDENT

[Mikael Magnusson]

On 8 February 2014 20:58, Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> } } This effect seems to occur only on some terminals but may be version
> } } specific because I get different results for the same terminal on
> } } different systems.
> }
> } More likely it's termcap/terminfo database version specific.  Can you
> } compare the terminfo settings for two cases of the same terminal giving
> } different behavior and report the difference?
> }
> } If it's not terminfo, it may be some kind of emulation option that has
> } a different setting in the Xdefaults etc.
>
> I've just compared xterm on my old CentOS box (which does not show the
> off-by-one effect) with xterm on my much newer Ubuntu box (where I *do*
> see the effect).  Except for some keypad definitions, the terminfo are
> identical.
>
> However, on CentOS, my settings for class XTerm include ReverseWrap:true
> whereas on Ubuntu I'm using the defaults.  Normally this would mean that
> terminfo/cap should have the "bw" capability, but it's false in both
> cases because of course it has to describe the default settings.
>
> So perhaps the following patch ...?  (The change to zle_refresh.c is to
> silence a spurious "may be used uninitialized" warning.)

I just updated zsh for the first time since before all this, and
setting ZLE_RPROMPT_INDENT=0 breaks the display for me (or with the
heuristics, not setting it to 1). I'm using urxvt and it does seem to
somewhat work if I just set RPS1=hello, but not with my actual
rprompt.
RPS1=%B%b ZLE_RPROMPT_INDENT=0 is enough to trigger the erroneous
display here, which causes the cursor to be offset one step to the
left. The same problem occurs in xterm.

-- 
Mikael Magnusson

Re: Pre-5.0.5 part 3: Heuristic for ZLE_RPROMPT_INDENT

[Bart Schaefer]

On Feb 17,  5:12pm, Mikael Magnusson wrote:
}
} I just updated zsh for the first time since before all this, and
} setting ZLE_RPROMPT_INDENT=0 breaks the display for me (or with the
} heuristics, not setting it to 1).

With xterm (and I presume with urxvt) you need ReverseWrap: true for
a zero indent to work correctly.  The default is false, at least for
xterm (I don't use/have installed urxvt to check).  This default
ought to be reported correctly by terminfo, but it's quite possible
that it is not, in which case the heuristic would get it wrong.  It is
after all a heuristic, not a perfect test.

A dump of the key/value pairs in $terminfo might be instructive.

} I'm using urxvt and it does seem to somewhat work if I just set
} RPS1=hello, but not with my actual rprompt.

I don't can't reproduce any difference between having a plain string
prompt and having one with bold/nobold etc., but it's not beyond the
realm of imagination that an emulator would (incorrectly) treat such
controls as "printing beyond the margin".

Re: Pre-5.0.5 part 3: Heuristic for ZLE_RPROMPT_INDENT

[Mikael Magnusson]

On Mon, Feb 17, 2014 at 7:34 PM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> On Feb 17,  5:12pm, Mikael Magnusson wrote:
> }
> } I just updated zsh for the first time since before all this, and
> } setting ZLE_RPROMPT_INDENT=0 breaks the display for me (or with the
> } heuristics, not setting it to 1).
>
> With xterm (and I presume with urxvt) you need ReverseWrap: true for
> a zero indent to work correctly.  The default is false, at least for
> xterm (I don't use/have installed urxvt to check).  This default
> ought to be reported correctly by terminfo, but it's quite possible
> that it is not, in which case the heuristic would get it wrong.  It is
> after all a heuristic, not a perfect test.
>
> A dump of the key/value pairs in $terminfo might be instructive.
>
> } I'm using urxvt and it does seem to somewhat work if I just set
> } RPS1=hello, but not with my actual rprompt.
>
> I don't can't reproduce any difference between having a plain string
> prompt and having one with bold/nobold etc., but it's not beyond the
> realm of imagination that an emulator would (incorrectly) treat such
> controls as "printing beyond the margin".

I get the glitch when the resulting string is empty, but still prints
something. Eg,
RPS1=%b
RPS1=%f
RPS1=$'\0'
produce the error while
RPS1=' %b'
RPS1='%f '
don't.

-- 
Mikael Magnusson

Re: Pre-5.0.5 part 3: Heuristic for ZLE_RPROMPT_INDENT

[Bart Schaefer]

On Dec 8,  1:46am, Mikael Magnusson wrote:
}
} I get the glitch when the resulting string is empty, but still prints
} something. Eg,
} RPS1=%b
} RPS1=%f
} RPS1=$'\0'
} produce the error while
} RPS1=' %b'
} RPS1='%f '
} don't.

I can confirm with xterm and examining the output of typescript that
printing a "visible" character (even a space) into column 80 followed
by printing a backspace leaves the cursor in column 80; whereas moving
the cursor to column 80 and then printing a nul or a control sequence
followed by a backspace moves the cursor back to column 79.

ZLE is printing the backspace because the auto-margin value reported
by the terminfo description says that printing into or beyond column
80 will wrap the line, so ZLE believes it needs to back up onto the
original line before continuing.  xterm is faking it by ignoring the
backspace when it's the first thing that is output after column 80,
but if anything else precedes the backspace, xterm loses state and
the backspace is processed even though the cursor didn't move.

I'm not sure there's any way for ZLE to deal with this without having
a lot more knowledge/control over what may appear in the prompt at
the rightmost column.  It also somehow needs to know whether the
terminal actually did wrap, or is just pretending; maybe we have
that much already.