Keys that move the viewport and not change the selection ignore the draft context
caksoylar opened this issue · 2 comments
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.
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.
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)