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
During UI resizing, line numbers areas of newly exposed lines are never updated, leaving holes.
To reproduce:
Start lem in ncurses mode and load a file with many lines.
Resize the UI window bigger, slowly, and observe what happens to line numbers.
Line numbers are not generated until the next keyboard event (such as cursor move).
Issue: Line number area is never redrawn during and after resizing.
The line number area is never drawn, relying on UI to clear the screen. This complicates the resize logic: low-level bitmap allocator now needs to clear the screen (to the theme's background color) to avoid holes showing instead of relying on the redraw to take care of it.
Proposed solution:
Redraw should address the line-number cells and not leave holes.
At the very least, clear-to-eol should start at 0.
Proof:
Logs show that the line number area is simply not updated by Lem, while the text is. Here is a portion of a log with noise removed for convenience:
Here you can see that at coordinates (0 23) line number "24" is printed, followed by text at (4 23).
At (0 24), the first line in newly exposed area, is cleared to EOL.
After that, we go straight to (4 25), never addressing the line number area. This pattern continues.
This shows that Lem never updates the line number area.
The text was updated successfully, but these errors were encountered:
座標点(0 23)で、行番号は"24"と印字されて、その後、座標点(4 23)でtextが伴います。
座標点(0 24)は、新しく出されるエリアの初めの行ですが、EOLにclearされます。
After that, we go straight to (4 25), never addressing the line number area.
その後、座標点(4 23)にいきますが、その行番号のエリアを対処(adreess)しません。
このパターンが続きます。
この流れは、lemが行番号のエリアを更新していないことを示します。
During UI resizing, line numbers areas of newly exposed lines are never updated, leaving holes.
To reproduce:
Line numbers are not generated until the next keyboard event (such as cursor move).
Issue: Line number area is never redrawn during and after resizing.
The line number area is never drawn, relying on UI to clear the screen. This complicates the resize logic: low-level bitmap allocator now needs to clear the screen (to the theme's background color) to avoid holes showing instead of relying on the redraw to take care of it.
Proposed solution:
Redraw should address the line-number cells and not leave holes.
At the very least, clear-to-eol should start at 0.
Proof:
Logs show that the line number area is simply not updated by Lem, while the text is. Here is a portion of a log with noise removed for convenience:
Here you can see that at coordinates (0 23) line number "24" is printed, followed by text at (4 23).
At (0 24), the first line in newly exposed area, is cleared to EOL.
After that, we go straight to (4 25), never addressing the line number area. This pattern continues.
This shows that Lem never updates the line number area.
The text was updated successfully, but these errors were encountered: