Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not seem correct, from the code we should have the new value in those.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nevertheless, that seems to be how it works. Using the current version (5c793a6), I launched Kakoune with:
In the
*debug*
buffer, I saw:...which matches the expected dimensions of my terminal. If I hit the "toggle fullscreen" shortcut, I get:
...where the
hook_param
is the new dimensions, andwindow_range
is the old dimensions. If I toggle fullscreen again:...once again
hook_param
is the new dimensions, andwindow_range
is the old.I figured this out while investigating #4975
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is specific to window_range though, if you do:
You will see window_width and window_height match the hook parameter.
window_range is different because it gives you what range of the buffer is currently displayed. It used to compute this on demand and mostly matched what the next redraw would look like, it now accesses the range from last redraw and hence might not match the next redraw.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see!
How should I document this? Should this interaction between
WinResize
andwindow_range
be documented here, or in thewindow_range
docs?Alternatively, should
WinResize
be modified to run after the first redraw with the new dimensions, so that all the values are up-to-date?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm it seems to me that window_range should match the next redraw. That would be more correct though I don't know if there is a practical difference besides the initialization. Maybe that's awkward to implement.
I guess as a stop-gap solution we could throw an error if window_range is not initialized.
Then users could do
try %{ set-register r %val{window_range} }
.It's still ugly because it's such a special case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feels wrong but I wonder if it works for practical uses