-
Notifications
You must be signed in to change notification settings - Fork 708
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
Multi-line replace ranges end up cutting off visible lines from the buffer #3644
Comments
Any update on that issue? I think it is the only one block the development of folding inside kakoune. Folding would unlock a lot of great feature! |
Hey all, I don't have any experience with the kakoune codebase (or c++ for that matter), but wanted to look into this bug. My hypothesis was that kakoune buffers exactly M lines, where M is the number of lines needed to fill the screen with lines. The content of the screen is calculated by Highlighters can modify the DisplaySetup (here). Initially I thought that the ReplaceRangesHighlighter does not account for lines it removes, but it does. After the ReplaceRangesHighlighter accounts for the number of lines it removes, the WrapHighlighter (which wraps text-lines that are too long to display in one output-line into multiple output-lines) recalculates the number of lines in the buffer This means turning of the WrapHighlighter is a workaround for this specific bug. One way to potentially fix this bug is to turn around in which order the highlighters modify the DisplaySetup. This would mean that first the effect of Wrapping is taken into account and then the effect of Ranges Replaced, by modyfing window.cc line 243 in the following way:
to
this is also the order in which the actuall highlighting is executed in line 166:
Potentially there are other incompatibilities between the ReplaceRangesHighlighter and the WrapHighlighter, so this might not be enough. Also I'm not sure if there is a reason for first having the Another solution would be to change the WrapHighlighter to be less invasive about the number of buffered lines Best, |
Thanks for doing this investigation!
This helps, but does not completely work around the bug. I have a test plugin I wrote that replaces the saved selection ( I haven't tried messing with the order of highlighters. |
Changing the order of Move and Wrap Highlighters messes up the column calculation and leads to weird visual artifacts when the wrap highlighter is activated. But the wrap highlighter can be changed to take the length of the buffer needed from the DisplaySetup instead of directly from the screen, by changing line highlighters.cc:L804: from
to
This still has problems when the removed range includes long lines which are line wrapped. I don't think there is a way to implement ReplaceRangesHighlighter and WrapHighlighter independently from each other: The WrapHighlighter needs to know which lines are removed. Removed Lines are then ignored when calculating how many lines are added due to wrapping. The ReplaceRangesHighlighter needs to know how many "visual-lines" one buffer-line is representing to properly calculate how many more lines are needed.
Because the newline is part of the previous line it needs to be accounted additionally. One can check whether the last character in the replaced range is a newline and increase the number of removed_lines accordingly. Can the replacement of the ReplaceRangesHighlighter be multiline? I don't think that's currently accounted for. Additionally the WrapHighlighter cannot calculate how many lines are added due to wrapping if it doesn't know the replacement. So I don't think calculating how many more/less lines are needed due to replacing/wrapping can be calculated independently of the replacement at all. |
indentation is the key . as soon as the selection is not indented and using the above example from the op, that selection jumps to the beginning of line (file, whatever in use) e.g, with number-lines marker set, if no indentation is selected it jumps to the beginning of line so it would go from the current line (say line n to line 1 of the file) any piece of code or text or whatever as long as itss' indented gets folding , or else doesn't. That piece of code must be indented |
Steps
Create a multi-line replace-range. I used the following command:
See https://asciinema.org/a/LToZQAJwLsPiFxAA68Qa439HE to see this in action
Outcome
The bottom
n
lines visible in the window are blank, wheren
is the number of lines currently on the screenhidden by the replace ranges.
Expected
There should be no blank lines.
The text was updated successfully, but these errors were encountered: