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] %val{window_range} isn't working as expected #5017

Open
caksoylar opened this issue Nov 5, 2023 · 3 comments
Open

[BUG] %val{window_range} isn't working as expected #5017

caksoylar opened this issue Nov 5, 2023 · 3 comments
Labels

Comments

@caksoylar
Copy link

caksoylar commented Nov 5, 2023

Version of Kakoune

v2023.08.05-95-g1da8952e

Reproducer

Create a long text file:

> seq 100 >100.txt

Repro script:

> cat <<EOF >test_window_range.kak
echo -debug "window_height: %val{window_height}"
echo -debug "scroll_window before: %val{window_range}"
execute-keys <c-f>
echo -debug "scroll_window after:  %val{window_range}"
buffer *debug*
EOF

Run script:

> kak -n -e 'source test_window_range.kak' 100.txt

Outcome

*** This is the debug buffer, where debug info will be written ***
window_height: 32
scroll_window before: 0 0 0 0
scroll_window after:  0 0 0 0

Expectations

*** This is the debug buffer, where debug info will be written ***
window_height: 32
scroll_window before: 0 0 32 0
scroll_window after:  30 0 32 0

Additional information

Might be related to #4975 , since reverting 9787756 on top of tested HEAD 1da8952 returns the expected result.

Not sure what operations exactly lead to incorrect results, but at least <c-f> in the repro above, gj and vj all seem to give the wrong result.

For context, I noticed the issue because it breaks my plugin kakoune-smooth-scroll. It depends on executing a given key in a draft context and checking whether the window_range changed before and after it to determine whether there was a window scroll.

@caksoylar
Copy link
Author

It seems like the window_range update can be forced via a <c-l>, but that doesn't seem to work in a draft context (which is what the plugin currently does). Does anyone have a recommendation of how else I could detect a window range change resulting from an action, without actually performing the action on a non-draft client?

@sidkshatriya
Copy link
Contributor

*** This is the debug buffer, where debug info will be written ***
window_height: 26
scroll_window before: 0 0 1552 0
scroll_window after:  0 0 1552 0

I can reproduce this error with kakoune on a42aa1e .

@krobelus
Copy link
Contributor

yes it's #4975
there is some more commentary but no conclusion on #4994

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

3 participants