Bug (?) in prompt expansion of %(l.t.f)

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

The patch is very short so I'm going to show it to you first and then
explain it; I've deliberately removed the file information because I don't
want anyone to apply this until we've discussed it:

@@ -265,7 +265,7 @@
 		    break;
 		case 'l':
 		    *bp = '\0';
-		    countprompt(bufline, &t0, 0, 0);
+		    countprompt(bufline, &t0, 0, -1);
 		    if (t0 >= arg)
 			test = 1;
 		    break;

The definition of %N(l.t.f) is to expand to `t' if the length of the
current prompt line is N or greater, and expand to `f' otherwise.  The
potential bug is with the definition of "current prompt line."

The fourth argument to countprompt() determines how it emulates autowrap
behavior.  I.e., when positive, a new line is considered to begin when the
computed length of the line so far exceeds COLUMNS; when zero, a new line
begins when the length equals COLUMNS (current %N(l.t.f) behavior); when
negative, autowrap is not emulated at all, so only '\n' starts a new line
(%N(l.t.f) with the patch above applied to prompt.c).

The possible bug is:  If you're attempting to use %$COLUMNS(l..f) to stop
something from being added to the prompt that might cause it to wrap the
line (note the empty true branch), the test becomes false when there are
exactly COLUMNS characters already in the prompt, and you get the opposite
effect of what you intended.  (Note that even if you use %1(l..f) the test
is false as soon as the line so far is COLUMNS chars long, so it's not a
simple matter of testing %$[COLUMNS-1](l..f) or the like.)

Prompt truncation syntax is a possible but unsatisfactory workaround (in
part unsatisfactory because of the patch in 9945); another workaround is
to change the %N(l..f) -and- everything that precedes it in the prompt to
treat a line as having COLUMNS-1 characters.  But my real question is,
what is a user most likely to want "the current line" to mean?

Perhaps a small documentation change to explain about the autowrap would
be preferable to changing the behavior of the `l' test in the C code.  Or
perhaps we need to pass 1 for the lprompt and 0 for the rprompt at the
line patched above, as is done in zle_refresh.c; but that gets strange
when handling `print -P` and ${(%)...}.  Other opinions/ideas?

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