Line numbering misbehaves on resize

[lem-project]

Line numbering misbehaves on resize

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