auto-complete: limit the line length for auto-complete

docs/ChangeLog.md

@@ -244,6 +244,7 @@
 - keymap/vi (`decompose-meta`): translate <kbd>S-a</kbd> to <kbd>A</kbd> `#D1988` 600e845
 - sabbrev: apply sabbrev to right-hand sides of variable assignments `#D2006` xxxxxxxx
 - complete (`source:argument`): fallback to rhs completion also for `name+=rhs` `#D2006` xxxxxxxx
+- auto-complete: limit the line length for auto-complete `#D2009` xxxxxxxx
 
 ## Fixes
 

lib/core-complete.sh

@@ -7714,6 +7714,12 @@ _ble_complete_ac_suffix=
 function ble/complete/auto-complete/enter {
   local type=$1 COMP1=$2 suggest=$3 cand=$4 word=$5 insert1=${6-$5} suffix=${7-}
 
+  local limit=$((bleopt_line_limit_length))
+  if ((limit&&${#_ble_edit_str}+${#suggest}>limit)); then
+    # 文字数制限に引っかかる場合には単純に auto-complete は失敗する
+    return 1
+  fi
+
   # 提示
   local insert; ble-edit/content/replace-limited "$_ble_edit_ind" "$_ble_edit_ind" "$suggest" nobell
   ((_ble_edit_mark=_ble_edit_ind+${#suggest}))

note.txt

@@ -6630,6 +6630,57 @@ bash_tips
 
 2023-03-08
 
+  * complete: limit line length for auto-complete [#D2009]
+
+    "a @b" の時に @ に { を入力すると固まる
+
+    どうも a5b10e8 で問題が発生する様になっている。うーん
+    ble/application/render で固まっている。となるとやはり文法が関係しているので
+    はないか。という気がする。調べて行くと textmap#update で時間がかかっている。
+    どうも巨大な文字列が自動補完で挿入されてそれの解析で時間がかかっている様だ。
+    長さ 50170 になっている。
+
+    x fixed: 自動補完で limit が効いていないのは何故か? line_limit_length は
+      10000 の筈である。それの5倍の長さになっている。
+
+      →挿入の時点では replace-limited を使っている。然し、何故かそれをすり抜け
+      ている。うーん。line_limit_type が editor で、editor の場合には
+      replace-limited の時点では何も行わない。__line_limit__ という名前の特別な
+      キーが送信されてくる仕組みになっている。
+
+      誰が __line_limit__ を送っているのかというと ble/content/check-limit とい
+      う関数である。そしてこの関数はどうやら ble-decode/EPILOGUE から呼び出され
+      ている。丁度最後の render を呼び出す直前である。期待としては表示を試みる
+      前に editor が起動されるという事だが、auto_complete の中にいるので
+      __line_limit__ が単に無視されてそのまま描画ルーチンに入っているということ
+      の様だ。
+
+      うーん。そもそも auto-complete に入るのが間違いの気がするので
+      auto-complete/enter の時点で reject する様に修正した。
+
+    x この巨大な補完候補は何処から生成されているのか? histdb? → どうやら
+      histdb の様である。とても長い単語が登録されているのだろう。histdb の側で
+      余りに長い物は除外するべきだろう。登録する時点で保持する? それとも補完す
+      る時点で保持する?
+
+      取り敢えず今はテストの為にこの長い単語を保持しておく事にする。
+
+    x ok: 幾ら文字列が長かったとしても 50k 程度でフリーズするのは変な気がする。
+      何故?
+
+      →調べてみたら textmap#update で 20s かかって update-syntax (parse) で
+      39s かかっている。更に何処かで 20s ぐらいかかって最終的に表示される。
+      textmap#update は全ての文字の表示位置を計算しているので遅い。parse は勿論
+      時間がかかる。その他も何か一つずつ処理しているか何かなのだろう。つまり、
+      何処かが特別に時間がかかっているのではなくて、全体的に処理に時間がかかっ
+      ているということの様だ。
+
+      うーん。これは結局単に時間がかかっているというだけの事。
+
+    * histdb: もし巨大な単語が紛れ込んでいたとしても検索の時点で文字数に制限を
+      かける事はできないか→取り敢えず検索の時点で文字数に制限をかける事にした。
+      動いている。
+
   * edit: ~name による "named directory" 展開機能? [#D2008]
     https://github.com/akinomyoga/ble.sh/discussions/299