New patch attached.

(Also, I switched from macOS's Mail app back again to Gmail's web app.
Let's see how that goes for the line wrapping. I'm unable to reproduce it
when reading back my own emails in either app. I don't have to do any
horizontal scrolling when reading them.)

On Fri, Apr 23, 2021 at 2:27 AM Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Thu, Apr 22, 2021 at 3:55 AM Marlon Richert <marlon.richert@gmail.com>
> wrote:
> >
> > If I would use push-input instead of push-line-or-edit, the buffer would
> not get restored immediately after using the widget. You’d end up with a
> blank command line instead. I want it to work the same from PS2 as it does
> from PS1.
>
> I see.  (Also, I forgot that push-input is implemented via
> push-line-or-edit, not the other way around.)
>
> Then how about:
>
> execute-command() {
>   local finish="zle .reset-prompt"
>   case $CONTEXT in
>   (cont) finish="zle .push-line-or-edit"
>     ;&
>   (start)
>     print -S "${${(q-)@}}"
>     eval "${(q-)@}"
>     ;;
>   (*) return 75
>     ;;
>   esac
>   eval "$finish"
> }
>

I tried a similar approach with `eval` before, but that doesn't play nice
with all prompts, as I outlined in workers/48622:

On Tue, Apr 20, 2021 at 4:36 PM Marlon Richert <marlon.richert@gmail.com>
wrote:

> There was some discussion as to whether this should or shouldn’t leave the
> executed commands visible in the terminal and/or history. I tried a version
> of it that doesn’t put the commands in the buffer but executes them
> directly and then does zle .reset-prompt, but this can leave the prompt in
> an incorrect state if the prompt uses precmd hooks. I also tried “manually”
> running precmd_functions before zle .reset-prompt, but this causes problems
> when any precmd hook contains code that doesn’t work when executed inside a
> widget (for example, echoing an escape code that result in a response from
> the terminal). Therefore, I instead settled on pushing the current line,
> setting the buffer, and then accepting the line. This seems to me the least
> likely to break anything, but I’m open to alternatives.
>