Graceful hiding of $RPROMPT

Graceful hiding of $RPROMPT

[Richard Hartmann]

Hi all,

as everyone will know, $RPROMPT will be hidden automagically if
the command you type becomes too long.

I am looking for a way to fall back gracefully, i.e. remove more and more
of $RPROMPT when needed instead of the all or nothing mechanism
which is in place, now. Ideally, I could define seperate sections and
just put the least interesting bits left-most.


Thanks,
Richard

Re: Graceful hiding of $RPROMPT

[Thorsten Kampe]

* Richard Hartmann (Sun, 20 Dec 2009 10:33:01 +0100)
> as everyone will know, $RPROMPT will be hidden automagically if
> the command you type becomes too long.
> 
> I am looking for a way to fall back gracefully, i.e. remove more and more
> of $RPROMPT when needed instead of the all or nothing mechanism
> which is in place, now. Ideally, I could define seperate sections and
> just put the least interesting bits left-most.

Can't give you any direct help but I had the same desire. Let's see who 
comes up with anwers or ideas...

Thorsten

Re: Graceful hiding of $RPROMPT

[Bart Schaefer]

On Dec 20, 10:33am, Richard Hartmann wrote:
}
} I am looking for a way to fall back gracefully, i.e. remove more and
} more of $RPROMPT when needed instead of the all or nothing mechanism
} which is in place, now.

This may not be impossible to do in shell code, but I think it's going
to be prohibitively difficult.

Look at Functions/Prompts/prompt_bart_setup.  From "prompt -h bart":

    The "upper right prompt" looks like:
	date time
    The fourth color is used for the date, and the first again for the
    time.  As with RPS1, first the date and then the time disappear as
    the upper left prompt grows too wide.

The prompt_bart_precmd function is where the computation of widths is
handled in order to set up the upper right prompt.  The complication
you're faced with is computing the width of left prompt plus the width
of the first line of input (which might be in $BUFFER or might be in
$PREBUFFER) *and* doing so every time the contents of $BUFFER change.

There's no single place to intercept buffer changes, so you'll have to
at least override the self-insert widget and probably any other widget
that might insert or delete (e.g., the entire completion suite).  Or
set an extremely short TMOUT and have the shell effectively busy-wait
on TRAPARLM to watch for changes, but I can't recommend that.

Another possibility is to embed the right prompt in PS1 rather than
using RPS1 at all.  The same width computations in prompt_bart_precmd
would apply; you would use save/restore cursor position escapes in PS1
and wrap output of the right prompt in %{...%} so that the line editor
can't "see" that a right prompt exists at all.

In this scenario you simply type over the right prompt as the input
extends far enough, which might not be visually appealing.

A final possibility is to do something like this:

zle-line-init() { POSTDISPLAY="${(%%):-  %D  %@}"; zle -R }
zle -N zle-line-init

This puts a prompt-like string at the end of the buffer and scrolls
it away to the right as you type.  A drawback here is that you can't
embed any terminal control sequences in POSTDISPLAY, zsh converts them
all to literal characters before output.

So to really get what you want, it'll require hacking the C code in
Src/Zle/zle_refresh.c, function zrefresh.  Look for references to
"rpmpt" e.g. the variable "put_rpmpt".  A nice touch would be if the
%(l...) mechansim was intelligent about being used in RPS1 and counted
the ZLE buffer as part of "at least N characters have already been
printed".

-- 

Re: Graceful hiding of $RPROMPT

[Richard Hartmann]

On Sun, Dec 20, 2009 at 19:17, Bart Schaefer <schaefer@brasslantern.com> wrote:

> So to really get what you want, it'll require hacking the C code in
> Src/Zle/zle_refresh.c, function zrefresh.  Look for references to
> "rpmpt" e.g. the variable "put_rpmpt".  A nice touch would be if the
> %(l...) mechansim was intelligent about being used in RPS1 and counted
> the ZLE buffer as part of "at least N characters have already been
> printed".

Would if I could, seriously. As it is, I am limited to asking if anyone is kind,
and interested, enough to do this for me (us).


Richard