Line numbering misbehaves on resize

[stacksmith]

During UI resizing, line numbers areas of newly exposed lines are never updated, leaving holes.

To reproduce:

1. Start lem in ncurses mode and load a file with many lines.
2. 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:

xcb:interface-print  (0 23) | 24 | attr:#<ATTRIBUTE {10047AC673}> 
xcb:interface-clear-eol view (4 23)
xcb:interface-print  (4 23) |A working 'toy' implementation provides a simple demo of the wrapper.| attr:NIL 
xcb:interface-clear-eol view  (0 23)
xcb:interface-clear-eol view  (0 24)
xcb:interface-clear-eol view  (4 25)  <----------  HERE!
xcb:interface-print (4 25) |```| attr:NIL 

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.

[t-cool]

UIのサイズを変えると、新たにでる行の行番号のエリアが、アップデートされずに穴があきます。

再現方法: ・lemをncurses-modeで起動して、行が多くあるファイルを読み込みます。 ・UIのwindowsを大きくしたときに、行番号がどうなるかを観察してください。 ・行番号は、次のキーボードイベント(カーソル移動等)が起こるまで生成されません。

問題: ・行番号のエリアが、リサイズ中、またリサイズ後に、再描画されていません。 ・行番号のエリアが描画されず、UIがスクリーンをクリアすることに依存しています。 ・このことが、リサイズの流れを複雑にしています。つまり、下位レベルのbitmap allocatorが、穴があいてしまわないように、スクリーンをクリアする必要が生じています。その結果、その処理をするために、redrawに依存してしまっています。

解決策の提案: Redrawは行番号を対処?(address)するべきであり、そうすることで、穴はあきません。 まずさしあたり、clear-to-eolは0から始めるべきです。

根拠(proof: 主張を裏付けるデータ): ログによると、テキストはlemに更新されていますが、行番号はlemによって更新されていません。 ログの一部を抜粋します。

xcb:interface-print  (0 23) | 24 | attr:#<ATTRIBUTE {10047AC673}> 
xcb:interface-clear-eol view (4 23)
xcb:interface-print  (4 23) |A working 'toy' implementation provides a simple demo of the wrapper.| attr:NIL 
xcb:interface-clear-eol view  (0 23)
xcb:interface-clear-eol view  (0 24)
xcb:interface-clear-eol view  (4 25)  <----------  HERE!
xcb:interface-print (4 25) |```| attr:NIL 

座標点(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が行番号のエリアを更新していないことを示します。