Re: 3.1.6-dev-22

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Apr 17, 10:58am, Geoff Wing wrote:
} Subject: Re: 3.1.6-dev-22
}
} Bart Schaefer wrote about Re: 3.1.6-dev-22:
} :On Apr 12,  6:30am, Geoff Wing wrote:
} :} Subject: Re: 3.1.6-dev-22
} :} We differ from other shells in that we have a clear workspace
} :} under the prompt line.  Apply [users/2973] and [...]
} :} My preference is for the current arrangement and I have
} :} noalwayslastprompt - adding the patch may spawn another setopt
} :} value: gimmeaclearworkspace :-)
} :I'll play with this a bit when I'm wider awake, but:
} 
} I've been waiting.  Are you wider awake yet?  :-)

I woke up and promptly left town.  (Pun?)

What I was supposed to try was:

% clear; ls; echo "\e[0H"; ls

If I replace those semicolons with RETs so that a new prompt is printed
between each pair of commands, then I begin to see what you mean.  (It
depends more than a little bit on the "ls" output -- if the output is
enough to scroll the screen, for example, no difference is discernable).

Nevertheless, this is only an issue if a command (the echo in the sample)
leaves the cursor above some portion of a screenful of output.  Does that
happen to you a lot?  The last time I can remember it happening to me, it
was because a curses-based program crashed.

I'm sure some test other than `&& isset(ALWAYSLASTPROMPT)' would be better;
if it's not clearing for the completion code's benefit then whether we've
returned to the previous prompt is irrelevant (e.g., if Geoff's arguments
aren't convincing then maybe we should remove that CLEAREOD entirely).

However, I don't feel very strongly about it either way; special-case code
for transparent terminals makes even less sense than for crashing commands.

} :Can't you get the same effect with 2973 applied by having %E as the last
} :thing in $PS1 ?
} 
} 1) %E is CLEAREOL (erase to end of line)

Oh, duh.

} :And what's the point of having the %E escape if zsh is always going to
} :clear the screen unconditionally?  Just for "print -P"?
} 
} 2) The display code doesn't know about %E.  The prompt code handles
}    that but doesn't pass that information through, leading to:
} 3) %E in prompts may be dangerous.

Maybe we should document this?

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