highlight: fix shifted error marks on delayed "core-syntax"

docs/ChangeLog.md

@@ -366,6 +366,7 @@
 - edit (`ble/textarea#render`): fix interleaving outputs to `_ble_util_buffer` and `DRAW_BUFF` `#D1987` 6d61388
 - keymap/vi (`expand-range-for-linewise-operator`): fix the end point being not extended `#D1994` bce2033
 - keymap/vi (`operator:filter`): do not append newline at the end of line `#D1994` bce2033
+- highlight: fix shifted error marks after delayed `core-syntax` `#D2000` xxxxxxx
 
 ## Documentation
 

lib/core-syntax.sh

@@ -7229,11 +7229,15 @@ _ble_highlight_layer_syntax_VARNAMES=(
   _ble_highlight_layer_syntax3_list
   _ble_highlight_layer_syntax3_table)
 function ble/highlight/layer:syntax/initialize-vars {
-  _ble_highlight_layer_syntax_buff=()
-  _ble_highlight_layer_syntax1_table=()
-  _ble_highlight_layer_syntax2_table=()
+  # Note (#D2000): core-syntax は遅延ロードされるので layter/update/shift 対象
+  # の配列は全て必要な要素数を備えている必要がある。
+  local prev_iN=${#_ble_highlight_layer_plain_buff[*]}
+  ble/array#reserve-prototype "$prev_iN"
+  _ble_highlight_layer_syntax_buff=("${_ble_array_prototype[@]::prev_iN}")
+  _ble_highlight_layer_syntax1_table=("${_ble_array_prototype[@]::prev_iN}")
+  _ble_highlight_layer_syntax2_table=("${_ble_array_prototype[@]::prev_iN}")
+  _ble_highlight_layer_syntax3_table=("${_ble_array_prototype[@]::prev_iN}") # errors
   _ble_highlight_layer_syntax3_list=()
-  _ble_highlight_layer_syntax3_table=() # errors
 }
 ble/highlight/layer:syntax/initialize-vars
 

note.txt

@@ -2285,34 +2285,6 @@ bash_tips
     bash-completion では function func [TAB] でこれに対応しているので。現在は
     function aaa の時 aaa には単語を設置していないが必要があれば登録しても良い。
 
-  * highlight: "function aaa bbb ccc" と素早く入力すると変なエラー着色の残り方をする
-
-    % function aaa bbb ccc として C-l すると描画の着色がおかしい。C-l としなく
-    % ても高速に入力するとこういう事が起こる様だ。
-
-    素早く入力した時などに発生し C-l で再描画しても残っている。
-
-    調べてみるとどうやらエラー着色が layer に残留してしまうのが原因の様である。
-
-    _ble_syntax_attr/tree/nest/stat?
-    06 a    000 'f' |  stat=(CMDX w=- n=- t=-:-)
-     | a    001 'u' |
-     | a    002 'n' |
-     | a    003 'c' |
-     | a    004 't' |
-     | a e  005 'i' |
-     | a    006 'o' |
-     | a    007 'n' +  word=CMDI:0-8/(wattr=d)
-     3 a    008 ' '
-    22 a    009 'f'
-
-    しかもこのエラーは単語着色のエラーではなくて文法的に閉じていない時に実施
-    されるエラー着色である。何故この様な中途半端な事が起こるのかよく分からな
-    い。うーん。起こる条件が分からない。滅多に起こらない。
-
-    これはなかなか再現しないので別項目にして後で考える事にする。
-    →どうも syntax.sh が遅延ロードされた時に発生する様である。
-
 2022-07-04
 
   * [保留] debug_xtrace を bash-4.0 以下でも対応する?
@@ -6658,6 +6630,99 @@ bash_tips
 
 2023-03-05
 
+  * 2022-07-06 highlight: "function aaa bbb ccc" と素早く入力すると変なエラー着色の残り方をする [#D2000]
+
+    % function aaa bbb ccc として C-l すると描画の着色がおかしい。C-l としなく
+    % ても高速に入力するとこういう事が起こる様だ。
+
+    素早く入力した時などに発生し C-l で再描画しても残っている。
+
+    調べてみるとどうやらエラー着色が layer に残留してしまうのが原因の様である。
+
+    _ble_syntax_attr/tree/nest/stat?
+    06 a    000 'f' |  stat=(CMDX w=- n=- t=-:-)
+     | a    001 'u' |
+     | a    002 'n' |
+     | a    003 'c' |
+     | a    004 't' |
+     | a e  005 'i' |
+     | a    006 'o' |
+     | a    007 'n' +  word=CMDI:0-8/(wattr=d)
+     3 a    008 ' '
+    22 a    009 'f'
+
+    しかもこのエラーは単語着色のエラーではなくて文法的に閉じていない時に実施
+    されるエラー着色である。何故この様な中途半端な事が起こるのかよく分からな
+    い。うーん。起こる条件が分からない。滅多に起こらない。
+
+    これはなかなか再現しないので別項目にして後で考える事にする。
+    →どうも syntax.sh が遅延ロードされた時に発生する様である。
+
+    2023-03-05 SIGWINCH 対策を行った時に改めてこれについて考えた
+
+    | * reject: 文法情報が初期化時に壊れるのは SIGWINCH などによって再描画が解
+    |   析の最中に発生するからではないか。その場合には SIGWINCH の処理を延期す
+    |   るべきである。というか、それは ble/application/render の時点で入れ子で
+    |   render が発生しない様に調整するべきである。→と思って実装を確認したら既
+    |   にその様な実装になっていた。
+    |
+    |   →というか初期化時に壊れるのは SIGWINCH とは関係ない。ウィンドウサイズ
+    |   を変更していなくても、文字列を素早く入力するだけで文法情報が破壊される
+    |   ので。やはり初期化時に function というのを素早く入力した時に壊れがちで
+    |   ある。特に入力し始めた時に未だ syntax がロードされておらず白黒の状態の
+    |   まま入力した後に発生する気がする。
+    |
+    | * reject: ble/syntax/parse の呼び出しを確認してみたが別に入れ子で呼び出さ
+    |   れる等の問題が起こっている訳でもない。
+    |
+    | ble/highlight/layer:syntax/update-error-table の実装が関係している気がす
+    | る。特にコメントアウトされている syntax3_table をクリアする行を入れる様に
+    | してみると問題は発生しない。うーん。_ble_highlight_layer_syntax3_list に
+    | 登録されているエラーを削除する事になっているが、この配列に登録されている
+    | データが壊れるか或いは失われるかずれているか、という事なのだろうか。
+    |
+    | どうも _ble_highlight_layer_syntax3_table の compaction が起こっている様
+    | な気がする。というか layer table は shift の対象だと考えると sparse になっ
+    | ているのが問題なのでは? うーん。shift の履歴を見ていて気づいた。どうも
+    | (DMIN,DMAX0,DMAX) の呼び出しが欠けてしまっている? なので本来挿入されるべ
+    | き要素が挿入されずに sparse になって変な事が起こっている。では何故
+    | (DMIN,DAMX0,DMAX) が欠けてしまうのだろうか。
+    |
+    | →つまり遅延して読み込まれているので、読み込まれた後の (DMIN,DMAX0,DMAX)
+    | しか受け取れていないという事。
+
+    [原因] core-syntax は遅延して読み込まれる。読み込まれる迄は syntax_buff や
+    その他の layer 固有の buffer は更新されない。そして読み込まれた時に空の配列
+    として初期化している。
+
+    一方で、これらのテーブルに対して layer/update/shift が呼び出される時、配列
+    は前回の更新時の文字列の長さと同じだけの要素を持つ dense な配列であることを
+    想定している。ここで実際に要素の足りない配列に対して layer/update/shift が
+    呼び出されると意図しない compaction 等が発生してエラーの設置位置がずれてし
+    まう。
+
+    [修正] 初期化時に要素の数が足りていない時にはちゃんと補う必要があるという事。
+    initialize-vars の時点でちゃんと要素を必要な数だけ入れておけば良い。
+
+    うーん。然し、どの長さを持っている事が期待されているのかは非自明である。
+
+    a initialize-vars の時点での要素数は直前の ble/highlight/layer/update の呼
+      び出し時における _ble_edit_str の文字数である。もし現在の _ble_edit_str
+      及び DMIN,DMAX,DMAX0 から遡って取得しようと思ったら DMIN,DMAX0,DMAX が記
+      録されている場所を知らなければならない。遡っていくと
+      ble/textarea#update-text-buffer で _ble_edit_dirty_draw_{beg,end,end0} を
+      拾っている。うーん。これを取得するのは複雑だし、edit.sh からの呼び出しを
+      仮定する事になる。モジュール外の呼び出し元の情報を参照しなければならない
+      のでカプセル化に失敗している。
+
+    b 或いは別の buffer の要素数をそのまま真似するのが良い様な気がする。という
+      か plain_buff は必ず存在する事になっているのでその要素数をそのまま真似れ
+      ば良いのではないか。
+
+    実際に plain buff の長さを確認してみたらちゃんと期待通りの要素数を持ってい
+    る。この要素数を真似て新しい配列を初期化する事にした。動いている。問題は解
+    決した様に見える。
+
   * term (mlterm), vim-airline: prompt_status_line がちゃんとレイアウトできていない [#D1999]
 
     * mlterm detection
@@ -9372,7 +9437,7 @@ bash_tips
         然し、ble/history/add で更に何かを出力する可能性があるのであれば、やは
         りそれより前に newline を実行しておく必要があるので使えない。現在の所は
         ble/history/add で直接何かを出力するという事はない様である。一方で、
-        ADDHISTORY を呼び出したら失敗があるという事。@@@@
+        ADDHISTORY を呼び出したら失敗があるという事。
 
       そもそもよく考えてみたら ADDHISTORY は文法情報等とは関係ない気がする。然
       し、一方で history の一環として登録するという意味においてやはり history