Re: Possible bug to RPROMPT

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Aug 4,  1:50pm, Bart Schaefer wrote:
}
} That'd be interesting, but what's really needed is for %<...< and %>...>
} to have a truncation length that's relative to the number of columns
} remaining in the line.  Hmm, perhaps %12<...< means truncate at 12
} characters, and %-12<...< means to truncate at the remaining length of
} the current line minus twelve characters?

So, this works (patch below).  You can do for example

PS1="%-40<<$PS1"

and then you always have 40 characters in which to type.  It belatedly
occurs to me that you can *already* get this with

setopt promptsubst
PS1='%$((COLUMNS-40))<<'"$PS1"

but this seems a worthwhile shorthand and doesn't require promptsubst.

On the other hand, if $COLUMNS is less than 40 then the patch below
changes the behavior of the promptsubst variant for very narrow windows.

It's still tricky to get the leftmost part of the prompt to shrink from
the midde, because "remaining width" is always calculated left-to-right.

In the patch, I hav enot applied this to the older %[<...] syntax.  The
second hunks is for something I believe to be a bug, if anyone would
care to confirm or deny.

diff --git a/Src/prompt.c b/Src/prompt.c
index c16d781..c6624cc 100644
--- a/Src/prompt.c
+++ b/Src/prompt.c
@@ -560,6 +560,12 @@ putpromptchar(int doprint, int endchar, unsigned int *txtchangep)
 		break;
 	    case '<':
 	    case '>':
+		/* Test (minus) here so -0 means "at the right margin" */
+		if (minus) {
+		    *bv->bp = '\0';
+		    countprompt(bv->bufline, &t0, 0, 0);
+		    arg = zterm_columns - t0 + arg;
+		}
 		if (!prompttrunc(arg, *bv->fm, doprint, endchar, txtchangep))
 		    return *bv->fm;
 		break;
@@ -1475,7 +1481,7 @@ prompttrunc(int arg, int truncchar, int doprint, int endchar,
 	/* Now we have to trick it into matching endchar again */
 	bv->fm--;
     } else {
-	if (*bv->fm != ']')
+	if (*bv->fm != endchar)
 	    bv->fm++;
 	while(*bv->fm && *bv->fm != truncchar) {
 	    if (*bv->fm == '\\' && bv->fm[1])

-- 
Barton E. Schaefer