You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let’s say I want to delete the line in my buffer which is at the center of the viewport after having scrolled down the buffer. The commands to execute would be: gjgcxd.
I created a file to showcase that behavior, with a line named "line to change 48" exactly at that location (considering my current terminal height). If I open Kakoune and do this interactively, I exactly manage to do that.
However, if I use a non-interactive filter: cat test.txt | kak -f 'gjgcxd', it would delete the last line of the buffer instead. I guess this is expected because I suppose the non-interactive filter does not have a "viewport". So "go to the middle displayed line" does not mean anything. The cursor then stays at the last line and that line gets deleted.
This already raises a point: some commands depend on the viewport while others don't, while they are all part of a "text editing language". This means the language is not exactly "universal" and it is up to the user to know what to use and when according to the context.
Now let’s take an example with :exec being launched manually with the prompt in an interactive session. Here, we could try to predict what it would do when executing :exec gjgcxd.
The first option is that Kakoune could realise that we are in an interactive editing session, and so it could act as if the user was exactly hitting those keys.
If that is not the case, we could otherwise think that :exec would be considered a non-interactive functionality. So the result would be the same as the filter demonstrated earlier, meaning that the last line would be deleted.
It happens that the result is again different. It would delete the middle displayed line but at the top of the buffer instead of at the bottom! I don't know what makes Kakoune do that.
Here is a screencast demonstrating the 3 above scenarios.
Outcome
I don’t know exactly what should be the outcome.
Expectations
I think those concerns should be addressed to at least predictively state what Kakoune is supposed to do when we are in non-interactive or in :exec.
I don’t know enough of Kakoune internals to know where the "viewport" concept is defined. But if it is at the "client" level, we could expect that :exec commands executed in the current client would result in the same behavior as when the user is executing them manually. This seems important for the scripting capabilities in plugins at least.
When asked on Discord, @Screwtapello gave this answer, trying to guess what Kakoune did:
I think :exec batches keys together? So if you gj interactively, it redraws the screen and updates its idea of where the "top" of the screen is, but if you :exec gjgc it doesn't do that redraw and so it still thinks it's at the top of the buffer?
So in the end, I don’t know the current reasons for the inconsistencies, but I think there is room for improvement, even if it is at the documentation level, stating exactly what is supposed to happen when Kakoune is used non-interactively, or when :exec is used on a client.
Additional information
No response
The text was updated successfully, but these errors were encountered:
Version of Kakoune
29d0596
Reproducer
Let’s say I want to delete the line in my buffer which is at the center of the viewport after having scrolled down the buffer. The commands to execute would be:
gjgcxd
.I created a file to showcase that behavior, with a line named "line to change 48" exactly at that location (considering my current terminal height). If I open Kakoune and do this interactively, I exactly manage to do that.
However, if I use a non-interactive filter:
cat test.txt | kak -f 'gjgcxd'
, it would delete the last line of the buffer instead. I guess this is expected because I suppose the non-interactive filter does not have a "viewport". So "go to the middle displayed line" does not mean anything. The cursor then stays at the last line and that line gets deleted.This already raises a point: some commands depend on the viewport while others don't, while they are all part of a "text editing language". This means the language is not exactly "universal" and it is up to the user to know what to use and when according to the context.
Now let’s take an example with
:exec
being launched manually with the prompt in an interactive session. Here, we could try to predict what it would do when executing:exec gjgcxd
.The first option is that Kakoune could realise that we are in an interactive editing session, and so it could act as if the user was exactly hitting those keys.
If that is not the case, we could otherwise think that
:exec
would be considered a non-interactive functionality. So the result would be the same as the filter demonstrated earlier, meaning that the last line would be deleted.It happens that the result is again different. It would delete the middle displayed line but at the top of the buffer instead of at the bottom! I don't know what makes Kakoune do that.
Here is a screencast demonstrating the 3 above scenarios.
Outcome
I don’t know exactly what should be the outcome.
Expectations
I think those concerns should be addressed to at least predictively state what Kakoune is supposed to do when we are in non-interactive or in
:exec
.I don’t know enough of Kakoune internals to know where the "viewport" concept is defined. But if it is at the "client" level, we could expect that
:exec
commands executed in the current client would result in the same behavior as when the user is executing them manually. This seems important for the scripting capabilities in plugins at least.When asked on Discord, @Screwtapello gave this answer, trying to guess what Kakoune did:
So in the end, I don’t know the current reasons for the inconsistencies, but I think there is room for improvement, even if it is at the documentation level, stating exactly what is supposed to happen when Kakoune is used non-interactively, or when
:exec
is used on a client.Additional information
No response
The text was updated successfully, but these errors were encountered: