Keys that move the viewport and not change the selection ignore the draft context

[caksoylar]

Steps

Open a file more than a screen long, move the cursor to a different position, e.g. with gj, then call :exec -draft vv, or :exec -draft <c-d>.

Outcome

The window scrolls, as if the keys were executed in the client context.

Expected

The window does not move, no scrolling occurs.

To be fair, the docs in :doc execeval say

-draft
execute in a copy of the context of the selected client. Modifications to the selections or input state will not affect the client.

so it only mentions selections and input state (whatever that encapsulates). I think the spirit of the draft context should also extend to not affecting the client's viewport by scrolling.

[sidkshatriya]

This behavior of exec vv in a -draft mode is surprising.

It seems the logic behind this behavior is that "draft modes don't have a viewport, and if there is a command that refers to a viewport then it refers to the real viewport from which the draft mode was created".

Allowing draft modes to have their own "virtual" viewport could unlock some interesting functionality.

[mawww]

This is surprising, thanks for bumping that issue, this is a side effect of the window being preserved through draft context so that accessing window scope works. I am wondering if it really makes sense, maybe draft contexts should not have window available in the first place.

Having access to a window for options/hooks/mappings/aliases/faces/highlighters but not for scrolling it seems a bit weird as well, so I am not sure what the best approach is.

(EDIT: This feature was introduced due to #702)