RFC: Generalized transient_rprompt

[Roman Perepelitsa <roman.perepelitsa@xxxxxxxxx>]

I've mentioned in workers/44905 that I was looking for a way to
implement generalized transient_rprompt. The goal is to not only hide
right prompt when accepting a command line (like transient_rprompt
does) but to shorten left prompt, too.

Regular behavior with PROMPT='%~%# ' and RPROMPT='%n@%m':

    /tmp% echo hello         romka@adam
    hello
    /tmp% true               romka@adam
    /tmp%                    romka@adam

With transient_rprompt option set:

    /tmp% echo hello
    hello
    /tmp% true
    /tmp%                    romka@adam

With left prompt shortened down to `%#`:

    % echo hello
    hello
    % true
    /tmp%                    romka@adam

I've found what appears to be a robust implementation that achieves
this effect and am looking for feedback. Here it is:

    zle-line-init() {
      emulate -L zsh

      [[ $CONTEXT == start ]] || return 0

      while true; do
        zle .recursive-edit
        local -i ret=$?
        [[ $ret == 0 && $KEYS == $'\4' ]] || break
        [[ -o ignore_eof ]] || exit 0
      done

      local saved_prompt=$PROMPT
      local saved_rprompt=$RPROMPT
      PROMPT='%# '
      RPROMPT=''
      zle .reset-prompt
      PROMPT=$saved_prompt
      RPROMPT=$saved_rprompt

      if (( ret )); then
        zle .send-break
      else
        zle .accept-line
      fi
      return ret
    }

    zle -N zle-line-init

I've found one case where this implementation behaves differently from
transient_rprompt. When a background job completes, normally a
notification would appear right away and prompt together with the
current command line would be reprinted. My implementation will
prevent the notification from being shown until the current line is
finished.

Is there a way to fix this discrepancy? Are there other cases where
this implementation behaves differently from transient_rprompt?

Roman.