Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Commands relying on viewport don’t work in non-interactive mode #5221

Open
lobre opened this issue Aug 20, 2024 · 0 comments
Open

[BUG] Commands relying on viewport don’t work in non-interactive mode #5221

lobre opened this issue Aug 20, 2024 · 0 comments
Labels

Comments

@lobre
Copy link
Contributor

lobre commented Aug 20, 2024

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.

kak_gjgcxd

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

@lobre lobre added the bug label Aug 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant