Simulating ZLE_RPROMPT_INDENT=0

Simulating ZLE_RPROMPT_INDENT=0

[Bart Schaefer]

I wrote:
> Src/Zle/zle_refresh.c:moveto() knows that the last character that was
> output for the right-prompt was in the rightmost column.  What it does
> not know is whether that left the cursor AT the rightmost column, or
> whether it wrapped around to the next line.

For terminals like xterm where the line doesn't wrap until the *next*
character is output, one can do something like this:

zmodload zsh/terminfo
RPS1="${RPS1%?}%{${(M)RPS1%?}${terminfo[cub1]}%}"

What this does is:

- Tell ZLE that $RPS1 is one character shorter than it really is, by
  putting the last character inside %{ %}

- Include a "move back one" sequence after that last character; when
  this is output, the terminal will silently swallow it without moving
  the cursor.

Thus there's a way to create the ZLE_RPROMPT_INDENT=0 behavior in almost
any version of zsh, if your terminal works in the "right" way.

I believe we concluded some years ago that it's not possible to reliably
tell from termcap/terminfo descriptions whether this sort of trick will
work, which is why moveto() is written the way it is.  However, as we
have now made ZLE_RPROMPT_INDENT the user's responsibility, we could
simply assume that if ZLE_RPROMPT_INDENT=0, then printing the cub1
sequence will do the right thing.  (An extra check could be that the
cub1 sequence is not backspace or del.)

To do this would require that rprompt_off be available in moveto(), which
likely means it needs to become global like vln and vcs.  It's rather
inefficient anyway to be looking up the value of ZLE_RPROMPT_INDENT every
time zrefresh() is called; it ought to be handled like LINES/COLUMNS.

Re: Simulating ZLE_RPROMPT_INDENT=0

[Peter Stephenson]

On Tue, 17 Dec 2013 22:43:37 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> I believe we concluded some years ago that it's not possible to reliably
> tell from termcap/terminfo descriptions whether this sort of trick will
> work, which is why moveto() is written the way it is.  However, as we
> have now made ZLE_RPROMPT_INDENT the user's responsibility, we could
> simply assume that if ZLE_RPROMPT_INDENT=0, then printing the cub1
> sequence will do the right thing.  (An extra check could be that the
> cub1 sequence is not backspace or del.)
> 
> To do this would require that rprompt_off be available in moveto(), which
> likely means it needs to become global like vln and vcs.  It's rather
> inefficient anyway to be looking up the value of ZLE_RPROMPT_INDENT every
> time zrefresh() is called; it ought to be handled like LINES/COLUMNS.

That sounds reasonable.

pws

Re: Simulating ZLE_RPROMPT_INDENT=0

[Bart Schaefer]

On Dec 18,  9:27am, Peter Stephenson wrote:
} Subject: Re: Simulating ZLE_RPROMPT_INDENT=0
}
} On Tue, 17 Dec 2013 22:43:37 -0800
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > simply assume that if ZLE_RPROMPT_INDENT=0, then printing the cub1
} > sequence will do the right thing.  (An extra check could be that the
} > cub1 sequence is not backspace or del.)
} > 
} > To do this would require that rprompt_off be available in moveto(), which
} > likely means it needs to become global like vln and vcs.  It's rather
} > inefficient anyway to be looking up the value of ZLE_RPROMPT_INDENT every
} > time zrefresh() is called; it ought to be handled like LINES/COLUMNS.
} 
} That sounds reasonable.

OK, so various questions ...

Are we sticking with the name ZLE_RPROMPT_INDENT ?  None of the other
prompt-related variables have "ZLE_" stuck on the front of them, even
though a number of them are useless when zsh/zle is not loaded.

Is it OK to declare ZLE_RPROMPT_INDENT in params.c or should it go in a
Zle/*.c file?  zle_params.c is currently limited to parameters that are
pseudo-local to widget context so this would need special handling.

In the event that the terminal has no non-destructive move-left sequence,
should assigning ZLE_RPROMPT_INDENT=0 print a warning?  Should it also
(or instead) ignore the value and revert to 1 in that case?

I suppose it should also reset itself upon assignment to TERM.  This is
looking like a fairly large effort for a fairly tiny feature ...

Re: Simulating ZLE_RPROMPT_INDENT=0

[Peter Stephenson]

On Wed, 18 Dec 2013 09:26:11 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Are we sticking with the name ZLE_RPROMPT_INDENT ?  None of the other
> prompt-related variables have "ZLE_" stuck on the front of them, even
> though a number of them are useless when zsh/zle is not loaded.

As we don't have namespaces I think it's safest to use the ZLE_ prefix.

> Is it OK to declare ZLE_RPROMPT_INDENT in params.c or should it go in a
> Zle/*.c file?  zle_params.c is currently limited to parameters that are
> pseudo-local to widget context so this would need special handling.

It doesn't need to be declared at all; it doesn't need to be special.
It just needs to be read and the value used if it happens to be set.
There are plenty of other variables like this.

> In the event that the terminal has no non-destructive move-left sequence,
> should assigning ZLE_RPROMPT_INDENT=0 print a warning?  Should it also
> (or instead) ignore the value and revert to 1 in that case?

Would make more to have another more programmatically useful way of
testing this if we need to, e.g. with echotc or echoti.  See also
below.

> I suppose it should also reset itself upon assignment to TERM.

I'm not sure that's necessary.  The user controls assignment to TERM.
If they want to do something to change the indent at the same time it
can be done in shell code.  We can recommend some if necessary.  I don't
see why this needs to be internal.

pws

Re: Simulating ZLE_RPROMPT_INDENT=0

[Bart Schaefer]

On Dec 18,  5:38pm, Peter Stephenson wrote:
} Subject: Re: Simulating ZLE_RPROMPT_INDENT=0
}
} On Wed, 18 Dec 2013 09:26:11 -0800
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > Is it OK to declare ZLE_RPROMPT_INDENT in params.c or should it go in a
} > Zle/*.c file?
} 
} It doesn't need to be declared at all; it doesn't need to be special.

It does need to be declared if it's going to be "handled like LINES /
COLUMNS" as I mentioned in my previous message on this thread.  There
needs to be a global integer attached to the value so that it doesn't
have to be read with getvalue() on every call to moveto().

} It just needs to be read and the value used if it happens to be set.
} There are plenty of other variables like this.

Yes, but those others aren't referenced for every keystroke typed into
the line editor.

} > In the event that the terminal has no non-destructive move-left sequence,
} > should assigning ZLE_RPROMPT_INDENT=0 print a warning?  Should it also
} > (or instead) ignore the value and revert to 1 in that case?
} 
} Would make more to have another more programmatically useful way of
} testing this if we need to, e.g. with echotc or echoti.

I'm not sure what you mean by this.  Do you mean e.g. to just document
how a shell script would perform the test?

Here's what I had so far which does not include changing moveto() yet.

--- 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 = 1;	/* Offset of rprompt from right of screen    */
+    int rprompt_off;		/* Offset of rprompt from right of screen    */
     struct rparams rpms;
 #ifdef MULTIBYTE_SUPPORT
     int width;			/* width of wide character		     */
@@ -1579,16 +1579,12 @@ zrefresh(void)
 		!strchr(rpromptbuf, '\t');
 	    if (put_rpmpt)
 	    {
-		struct value vbuf;
-		char *name = "ZLE_RPROMPT_INDENT";
-		if (getvalue(&vbuf, &name, 1)) {
-		    rprompt_off = (int)getintvalue(&vbuf);
-		    /* sanity to avoid horrible things happening */
-		    if (rprompt_off < 0)
-			rprompt_off = 0;
-		}
-		put_rpmpt =
-		    (int)ZR_strlen(nbuf[0]) + rpromptw < winw - rprompt_off;
+	      rprompt_off = rprompt_indent;
+	      /* sanity to avoid horrible things happening */
+	      if (rprompt_off < 0)
+		rprompt_off = 0;
+	      put_rpmpt =
+		(int)ZR_strlen(nbuf[0]) + rpromptw < winw - rprompt_off;
 	    }
 	}
     } else {


--- a/Src/init.c
+++ b/Src/init.c
@@ -999,6 +999,15 @@ setupvals(void)
     setiparam("COLUMNS", zterm_columns);
     setiparam("LINES", zterm_lines);
 #endif
+    {
+	/* handle inherit from environment */
+	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++) {


--- a/Src/params.c
+++ b/Src/params.c
@@ -97,6 +97,7 @@ zlong lastval,		/* $?           */
      lastpid,		/* $!           */
      zterm_columns,	/* $COLUMNS     */
      zterm_lines,	/* $LINES       */
+     rprompt_indent,	/* $ZLE_RPROMPT_INDENT */
      ppid,		/* $PPID        */
      zsh_subshell;	/* $ZSH_SUBSHELL */
 /**/
@@ -316,8 +317,10 @@ IPDEF4("PPID", &ppid),
 IPDEF4("ZSH_SUBSHELL", &zsh_subshell),
 
 #define IPDEF5(A,B,F) {{NULL,A,PM_INTEGER|PM_SPECIAL},BR((void *)B),GSU(F),10,0,NULL,NULL,NULL,0}
+#define IPDEF5U(A,B,F) {{NULL,A,PM_INTEGER|PM_SPECIAL|PM_UNSET},BR((void *)B),GSU(F),10,0,NULL,NULL,NULL,0}
 IPDEF5("COLUMNS", &zterm_columns, zlevar_gsu),
 IPDEF5("LINES", &zterm_lines, zlevar_gsu),
+IPDEF5U("ZLE_RPROMPT_INDENT", &rprompt_indent, zlevar_gsu),
 IPDEF5("OPTIND", &zoptind, varinteger_gsu),
 IPDEF5("SHLVL", &shlvl, varinteger_gsu),
 IPDEF5("TRY_BLOCK_ERROR", &try_errflag, varinteger_gsu),

Re: Simulating ZLE_RPROMPT_INDENT=0

[Peter Stephenson]

On Wed, 18 Dec 2013 10:43:53 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> } > In the event that the terminal has no non-destructive move-left sequence,
> } > should assigning ZLE_RPROMPT_INDENT=0 print a warning?  Should it also
> } > (or instead) ignore the value and revert to 1 in that case?
> } 
> } Would make more to have another more programmatically useful way of
> } testing this if we need to, e.g. with echotc or echoti.
> 
> I'm not sure what you mean by this.  Do you mean e.g. to just document
> how a shell script would perform the test?

No, I mean have a builtin with an explicit test that tells the user if
the terminal supports the feature or not.  Then changing the terminal
and deciding whether to set a zero right-prompt indent can be done
entirely in shell code.

TERM=mymmodernpowerfulterminalemulator
if builtin-decides-the-terminal-supports-non-destructive-move-left
  ZLE_RPROMPT_INDENT=0
else
  ZLE_RPROMPT_INDENT=1
fi

Is anything likely to happen before I release 5.0.4?  I was planning to
produce it imminently, but maybe we don't want to disappoint the punters
with a half implemented feature.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Simulating ZLE_RPROMPT_INDENT=0

[Bart Schaefer]

On Dec 18,  7:37pm, Peter Stephenson wrote:
}
} No, I mean have a builtin with an explicit test that tells the user if
} the terminal supports the feature or not.  Then changing the terminal
} and deciding whether to set a zero right-prompt indent can be done
} entirely in shell code.
} 
} TERM=mymmodernpowerfulterminalemulator
} if builtin-decides-the-terminal-supports-non-destructive-move-left
}   ZLE_RPROMPT_INDENT=0
} else
}   ZLE_RPROMPT_INDENT=1
} fi

As predicted I have not attempted to implement this builtin, but the
test it would need is for more than non-destructive-move-left.  In the
course of fiddling with moveto() I looked more closely at the "YE"
(termcap) / "sam" (terminfo) capability, which might give us enough
information.

However, if the builtin is able to give an accurate result, then we
could just do the test internally and set the offset ourselves.

Anwway, there are probably other places in the code that could benefit
from knowing about YE/sam, so I've captured it in another global that
goes with hasam and hasxn.  I also included code that makes use of
that to initialize rprompt_indent, but wrapped it in "#if 0" so as
not to change that behavior until after 5.0.4, because I'm sure it's
going to need some field testing.

ASIDE:  While testing, I tried setting TERM to various values that do
not have very many capabilities, such as "dumb".  I discovered the the
regular PS1 prompt will always, eventually, get erased and not redrawn
if scrolling back through the history with such a terminal.  The buffer
is still in the correct place, just the prompt is gone.  This behavior
is neither caused nor affected by the patch below.

ASIDE #2:  Having introduced IPDEF5U(), I wonder if there aren't some
of the other special variables that should have the PM_UNSET flag by
default.  OPTIND, OPTARG, and TRY_BLOCK_ERROR come to mind.

Working on moveto(), I discovered that backspace *is* the non-destructive
move-left in e.g. xterm, so I limited the test to tccan(TCLEFT).  Most
of the rest of that hunk is just a change in indentation.


diff --git a/Doc/Zsh/params.yo b/Doc/Zsh/params.yo
index 37c79b2..935fd5d 100644
--- a/Doc/Zsh/params.yo
+++ b/Doc/Zsh/params.yo
@@ -1548,7 +1548,7 @@ ifzman(zmanref(zshcompsys))\
 ifnzman(noderef(Completion System)).
 )
 vindex(ZLE_RPROMPT_INDENT)
-item(tt(ZLE_RPROMPT_INDENT))(
+item(tt(ZLE_RPROMPT_INDENT <S>))(
 If set, used to give the indentation between the right hand side of
 the right prompt in the line editor as given by tt(RPS1) or tt(RPROMPT)
 and the right hand side of the screen.  If not set, the value 1 is used.
diff --git a/Src/Zle/zle_refresh.c b/Src/Zle/zle_refresh.c
index debb973..fd54857 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 = 1;	/* Offset of rprompt from right of screen    */
+    int rprompt_off;		/* Offset of rprompt from right of screen    */
     struct rparams rpms;
 #ifdef MULTIBYTE_SUPPORT
     int width;			/* width of wide character		     */
@@ -1579,16 +1579,12 @@ zrefresh(void)
 		!strchr(rpromptbuf, '\t');
 	    if (put_rpmpt)
 	    {
-		struct value vbuf;
-		char *name = "ZLE_RPROMPT_INDENT";
-		if (getvalue(&vbuf, &name, 1)) {
-		    rprompt_off = (int)getintvalue(&vbuf);
-		    /* sanity to avoid horrible things happening */
-		    if (rprompt_off < 0)
-			rprompt_off = 0;
-		}
-		put_rpmpt =
-		    (int)ZR_strlen(nbuf[0]) + rpromptw < winw - rprompt_off;
+	      rprompt_off = rprompt_indent;
+	      /* sanity to avoid horrible things happening */
+	      if (rprompt_off < 0)
+		rprompt_off = 0;
+	      put_rpmpt =
+		(int)ZR_strlen(nbuf[0]) + rpromptw < winw - rprompt_off;
 	    }
 	}
     } else {
@@ -2127,19 +2123,24 @@ moveto(int ln, int cl)
     const REFRESH_ELEMENT *rep;
 
     if (vcs == winw) {
-	vln++, vcs = 0;
-	if (!hasam) {
-	    zputc(&zr_cr);
-	    zputc(&zr_nl);
+	if (rprompt_indent == 0 && tccan(TCLEFT)) {
+	  tc_leftcurs(1);
+	  vcs--;
 	} else {
-	    if ((vln < nlnct) && nbuf[vln] && nbuf[vln]->chr)
-		rep = nbuf[vln];
-	    else
-		rep = &zr_sp;
-	    zputc(rep);
-	    zputc(&zr_cr);
-	    if ((vln < olnct) && obuf[vln] && obuf[vln]->chr)
-		*obuf[vln] = *rep;
+	    vln++, vcs = 0;
+	    if (!hasam) {
+		zputc(&zr_cr);
+		zputc(&zr_nl);
+	    } else {
+		if ((vln < nlnct) && nbuf[vln] && nbuf[vln]->chr)
+		    rep = nbuf[vln];
+		else
+		    rep = &zr_sp;
+		zputc(rep);
+		zputc(&zr_cr);
+		if ((vln < olnct) && obuf[vln] && obuf[vln]->chr)
+		    *obuf[vln] = *rep;
+	    }
 	}
     }
 
diff --git a/Src/init.c b/Src/init.c
index 53c4fbd..f5aae71 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;
+mod_export int hasam, hasxn, hasye;
 
 /* Value of the Co (max_colors) entry: may not be set */
 
@@ -699,6 +699,7 @@ init_term(void)
 	/* check whether terminal has automargin (wraparound) capability */
 	hasam = tgetflag("am");
 	hasxn = tgetflag("xn"); /* also check for newline wraparound glitch */
+	hasye = tgetflag("YE"); /* print in last column does carriage return */
 
 	tclines = tgetnum("li");
 	tccolumns = tgetnum("co");
@@ -748,6 +749,9 @@ init_term(void)
 	    tcstr[TCCLEARSCREEN] = ztrdup("\14");
 	    tclen[TCCLEARSCREEN] = 1;
 	}
+#if 0	/* This might work, but there may be more to it */
+	rprompt_indent = (hasye || !tccan(TCLEFT)) ? 1 : 0;
+#endif
     }
     return 1;
 }
@@ -999,6 +1003,15 @@ 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++) {
diff --git a/Src/params.c b/Src/params.c
index d6711e4..26ad6b2 100644
--- a/Src/params.c
+++ b/Src/params.c
@@ -97,6 +97,7 @@ zlong lastval,		/* $?           */
      lastpid,		/* $!           */
      zterm_columns,	/* $COLUMNS     */
      zterm_lines,	/* $LINES       */
+     rprompt_indent,	/* $ZLE_RPROMPT_INDENT */
      ppid,		/* $PPID        */
      zsh_subshell;	/* $ZSH_SUBSHELL */
 /**/
@@ -316,8 +317,10 @@ IPDEF4("PPID", &ppid),
 IPDEF4("ZSH_SUBSHELL", &zsh_subshell),
 
 #define IPDEF5(A,B,F) {{NULL,A,PM_INTEGER|PM_SPECIAL},BR((void *)B),GSU(F),10,0,NULL,NULL,NULL,0}
+#define IPDEF5U(A,B,F) {{NULL,A,PM_INTEGER|PM_SPECIAL|PM_UNSET},BR((void *)B),GSU(F),10,0,NULL,NULL,NULL,0}
 IPDEF5("COLUMNS", &zterm_columns, zlevar_gsu),
 IPDEF5("LINES", &zterm_lines, zlevar_gsu),
+IPDEF5U("ZLE_RPROMPT_INDENT", &rprompt_indent, zlevar_gsu),
 IPDEF5("OPTIND", &zoptind, varinteger_gsu),
 IPDEF5("SHLVL", &shlvl, varinteger_gsu),
 IPDEF5("TRY_BLOCK_ERROR", &try_errflag, varinteger_gsu),

Re: Simulating ZLE_RPROMPT_INDENT=0

[Bart Schaefer]

On Dec 18, 11:33pm, Bart Schaefer wrote:
}
} Anwway, there are probably other places in the code that could benefit
} from knowing about YE/sam, so I've captured it in another global that
} goes with hasam and hasxn.  I also included code that makes use of
} that to initialize rprompt_indent, but wrapped it in "#if 0" so as
} not to change that behavior until after 5.0.4, because I'm sure it's
} going to need some field testing.

The code is actually simpler that way because we can fall back on the
default import-from-the-environment in createparamtable() rather than
having to do a special case in setupvals().

Re: Simulating ZLE_RPROMPT_INDENT=0

[Peter Stephenson]

On Wed, 18 Dec 2013 23:33:25 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Anwway, there are probably other places in the code that could benefit
> from knowing about YE/sam, so I've captured it in another global that
> goes with hasam and hasxn.  I also included code that makes use of
> that to initialize rprompt_indent, but wrapped it in "#if 0" so as
> not to change that behavior until after 5.0.4, because I'm sure it's
> going to need some field testing.

Thanks.  I had some weird behaviour with some older terminals (konsole
and gnome-terminal from a Fedora distribution a few years ago) but
trying it out on a more recent system at home the inconsistencies have
gone (apart from the fact that gnome-terminal seems to self destruct in
my desktop environment, but that's an entirely different matter that
could be related to the fact I've been accumulating Xdefaults for two
decades) and I'm left with some terminals that behave consistently one
way and some the other, as expected.  So I'm not inclined to pursue this
further.

> ASIDE:  While testing, I tried setting TERM to various values that do
> not have very many capabilities, such as "dumb".  I discovered the the
> regular PS1 prompt will always, eventually, get erased and not redrawn
> if scrolling back through the history with such a terminal.  The buffer
> is still in the correct place, just the prompt is gone.  This behavior
> is neither caused nor affected by the patch below.

I don't think "dumb" has ever been particularly well supported.

> ASIDE #2:  Having introduced IPDEF5U(), I wonder if there aren't some
> of the other special variables that should have the PM_UNSET flag by
> default.  OPTIND, OPTARG, and TRY_BLOCK_ERROR come to mind.

Yes, probably.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

IPDEF5U [was Re: Simulating ZLE_RPROMPT_INDENT=0]

[Bart Schaefer]

On Dec 19,  8:36pm, Peter Stephenson wrote:
}
} > ASIDE #2:  Having introduced IPDEF5U(), I wonder if there aren't some
} > of the other special variables that should have the PM_UNSET flag by
} > default.  OPTIND, OPTARG, and TRY_BLOCK_ERROR come to mind.
} 
} Yes, probably.

Fiddled with this a bit.  It's less trivial than it should be because
the code that manipulates the underlying C globals doesn't actually
set those variables, so if initialized to unset, they always appear so.
Unforutnately, this is probably not worth untangling.