if the prompt is more than one line, deleting a text object moves the prompt up

[doy]

I use a multi-line prompt, and if i do something like "da(", the line above my prompt is deleted, and the entire prompt is moved up a line.

[hchbaw]

Thank you for your report.

I'm using multi-line prompt, too. But I cannot reproduce here.
Please show your zsh setup.

[doy]

So I also have RPS1 configured to show the current editing mode, and disabling that configuration fixes things. I can reproduce the issue with this bit of additional configuration:

function zle-keymap-select () {
    zle reset-prompt
}
zle -N zle-keymap-select

and then using c (not d, I was mistaken there) with a text object in the prompt.

[hchbaw]

Thank you very much reporting the detail! I confirmed.

Ugh... Some multi-line prompt + the zle reset-prompt yields that even the zsh's builtin vi-change causes this "line up" behavior. Sorry, I cannot find any workarounds at the moment.

[hchbaw]

Here is a workaround.

zle-keymap-select () {
  setopt localoptions no_ksharrays
  local old="${@[2]-main}"
  local new="$KEYMAP"
  { [[ "$old" == opp ]] || [[ "$new" == opp ]] } && return
  # TODO: please modify the prompt here!
  zle reset-prompt
}
zle -N zle-keymap-select

This cannot distinguish the "operator-pending-mode"-ish from the others by modifying the prompts though.
Sorry for the inconvenience.

[hchbaw]

Rezised version here.

zle-keymap-select () {
  setopt localoptions no_ksharrays
  [[ "${@[2]-}" == opp ]] && return
  # TODO: please modify the prompt here!
  zle reset-prompt
}
zle -N zle-keymap-select

It's able to distinguish the "opp" from the others for now.
Sorry for the inconveniences.

[doy]

That seems to work - thanks!

[haifengkao]

The above fix doesn't work for me. 'ciw' still deletes the line above

[danijar]

I was able to fix the same issue by getting rid of the \n that was unnecessary since I already filled the whole line.