sistema_progs

note.txt (536010B)

---

 # -*- coding:utf-8 -*-
 
 拡張
 
   * compopt -o ble/filter-by-prefix
     プログラム補完に於いて補完関数内で指定した場合、
     生成される候補を接頭辞が一致するものだけに絞り込む。
 
   * compopt -o ble/syntax-raw
   * compopt -o ble/no-mark-directories
   * compopt -o ble/prog-trim
   * compopt -o ble/no-default
   * HISTCONTROL=strip
 
 制限
 
   * ble.sh を attach しているとき builtin read -e は動かない。
     代わりに ble.sh が定義したシェル関数 read (組み込みコマンドを上書き)
     を用いて read -e を呼び出す必要がある。
 
   * bash-3 C-d について
 
     今は何とか C-d を処理する事に成功しているが完全ではない。
 
     1 C-d を押した時に bash が出力するエラーメッセージを使って捕捉している。
       このエラーメッセージは言語や設定によって異なると思われる。
       現在は以下のメッセージを調べている。
       - 'Use "exit" to leave the shell.'
       - 'ログアウトする為には exit を入力して下さい'
       - 'シェルから脱出するには "exit" を使用してください。'
       自分の bash が異なるメッセージを出力する時は
       それを bleopt_ignoreeof_message に設定する。
     2 連続で沢山 C-d を押すと "^D" が echo されて表示が乱れるかもしれない。
       最悪の場合 C-d によって bash プロセスが落ちる可能性もあるかもしれない。
       (未だ落ちた事はないが)。
     3 C-d を処理する為に SIGUSR1 を使用している。
       その為 SIGUSR1 を別の目的で使用する事は出来ない。
 
   * 文字コードについて
 
     現在は基本的に UTF-8 を想定している。
     それ以外の環境のためには少なくとも以下の修正が必要になる。
 
     - ble.sh 自体を iconv で変換する事。或いは日本語を完全に排除する事。
 
       現在のところは日本語はコメント中にしか含まれていないはずである。
       コメントさえ削除すれば何処でも動くようになっていると良い。
 
     - 使いたい文字コード → unicode のデコーダを自分でかく事:
       これは "function ble-decode-byte+文字コード" を実装すれば良い。
 
     - Unicode → 文字のコードが正しく動作する様にする事:
       これは .ble-text.c2s (ble-core.sh) の辺りを直せばよい。
       "ble-text-c2b+文字コード"
       "ble-text-b2c+文字コード"
       も実装する必要がある。
 
     - ble/encoding:$bleopt_input_encoding/generate-binder
 
       現在 "C-@", "ESC" 及び "ESC *" を bind する為に、
       その符号化形式の非正規な符号に変換している。
       この変換はシェル関数 ble/encoding:$bleopt_input_encoding/generate-binder
       において文字符号化方式毎に (UTF-8 前提の設定を上書きする形で) 定義する。
 
       また bind を記録したキャッシュは $bleopt_input_encoding 毎に保持するが、
       このキャッシュの更新は bind.sh のタイムスタンプしか見ていない (ble-decode/bind 内)。
       新しい符号化方式を定義する時には、タイムスタンプを参照するファイル
       (ble/encoding:$bleopt_input_encoding/generate-binder を定義するファイル) を決める必要がある。
 
 
     他の文字コードは未だ一回も実装していないので上記以外にも必要な作業が出て来る可能性がある。
 
     + 2015-11-30 Note: ble-decode.sh (generate-source-to-unbind-default)
 
       文字コード実装時に問題があるかも。
 
       現在、bind -sp が出力する中途半端なバイトを解釈する為に、LANG=C で awk を起動している。
       UTF-8 の場合には複数バイト文字を構成するバイトは ASCII 文字と被らないので問題ないが、
       Shift_JIS 等の場合には ASCII 文字、特に \ や " を含む可能性がある。
       この場合には LANG=C にしていると問題が生じる。
       というか、bind -sp の出力する中途半端な文字と、複数バイト文字の一部を本質的に区別する方法はない様に思われる。
 
       ただし、救いは、もし ble.sh を plain な bash の上で起動するとすれば
       日本語で bind -sp に登録がなされていることはないだろうということである。
       つまり、ユーザが手で (或いは .inputrc に) bind '"日本語":"にほんご"' などとしない限りは問題は生じない。
 
   * bash-4.0, 4.1 において特殊シェル変数 FUNCNAME をユーザが unset した上で、
     関数内から ble.sh を source すると ble の使う連想配列がローカルに定義され問題になる。
 
     - bash-4.0 以降では連想配列を用いるが bash-4.2 未満では、
       連想配列を明示的にグローバルに配置することができない。
 
     - FUNCNAME がユーザによって削除されていなければ、
       この変数を用いて関数内から source されたことを検知できるので、
       その時には配列実装に fallback する。
       FUNCNAME が削除されていると fallback に正しく切り替わらずに問題になる。
 
   * bash-4.3 では C-x は、次の文字が来るまでは受信できない。
     bash-4.0 - 4.4 の他の version では遅延はないのでこれは bash-4.3 特有の問題である。
 
   * 構文に従った着色の中には bash の不自然な振る舞いや、
     複雑な振る舞いのために正確さを諦めた物がある。
 
     - bash の最初の [@()] の構文解析とパス名展開時の解析の齟齬
 
       echo [@(echo|[...])]
 
       恐らく bash は最初の単語の切り出しで @() を一単位として読み取り、
       ["@(echo|[...])"] の様に読み取る。その上で、改めてパス名展開を適用するが、
       その時には ["@(echo|[.."]")]" の様に解釈する。
       つまり、初めの構文解析とパス名展開の適用の間に齟齬がある。
 
       ble.sh では構文解析に従った解析・着色をすることにしたので、
       実際のパス名展開の適用結果が着色と異なることがあることに注意する。
 
     - bash echo {@(,)}
 
       これについても上と同様のことが起こる。
       単語の切り出しは {"@(,)"} となり、構文エラーは発生しない。
       後のブレース展開では {"@(",")"} と解釈されて分割される。
       単語が分断されてしまうのでパス名展開は起こらない。
 
     - bash のブレース展開時の ${var:-...}{,} の解析とパラメータ展開時の解析の齟齬
 
       echo ${var:-{a,b}{a,b}
 
       恐らく bash は最初にブレース展開を試みる時に、
       ${} の中については {} の入れ子を数えてスキップする。
       従って、上のコマンドの時は ${} が終端しないのでブレース展開は試みられない。
       しかし、パラメータ展開が実施される時には {} の入れ子は考慮に入れられず、
       最初に現れた "}" で終端するので、${var:-"{a,b"}"{a,b}" という解釈になる。
 
       [予定]
       ble.sh ではどの様に着色するか微妙である。
       理想的には最終的な解釈の ${var:-"{a,b"}"{a,b}" に応じた着色にしたいが、
       後半の {a,b} の部分が {} の入れ子のアンバランスによって
       無効化されている事を検出するのは困難である。
       仕方がないので、ブレース展開の {} の入れ子の勘定はバグとして無視する事にする。
       つまり、echo ${var:-"{a,b"}{a,b} という解釈で着色する。
 
     - bash のチルダ展開の時の echo a[]b]=~ の解析と、パス名展開の時の解析
 
       チルダ展開の時には a["]b"]=~ とはならず a[]"b]="~ という解釈になるので、チルダ展開は起こらない。
       一方で、パス名展開のときには a["]b"]"=~" という解釈になり、'ab=~' などのファイル名に一致する。
       ble.sh ではパス名展開の規則の方を優先させる。
 
     - ble.sh では [[ @({a,b}) ]] のブレース展開が有効であるかの様に着色される。
 
       実際には、条件コマンドの中ではブレース展開は無効になる。
       これに正確に対応する為には "条件コマンドの中の extglob"
       に対応する文脈値を定義する必要があるが、煩雑になるので対応していない。
 
     - ble.sh では echo [{@(a|b),[abc]}] の内部の extglob や [...] が有効であるかの様に着色される。
 
       しかし、実際にはブレース展開を実行したとしても [] の内部なので、
       extglob や [...] は不活性化しているはずである。
       しかし、これも解析が無意味に複雑になるので対応はしない。
 
     - ble.sh では echo {~user,~user} の内部のチルダ展開に反応しない。
 
       bash ではブレース展開された後にチルダ展開が実行されるので有効。
 
     - ble.sh はブレース展開が含まれる変数代入形式単語でも、
       ブレース展開より前のチルダ展開は有効である。
 
       bash では変数代入形式の単語の右辺でチルダ展開が起こる。
       しかし、ブレース展開が含まれている場合には例外としてチルダ展開が起こらない様だ。
 
       $ a=~:{a,b}:~:echo      → ブレース展開は起こらず、チルダ展開は起こる。
       $ echo a=~:{a,b}:~:echo → ブレース展開が起こり、チルダ展開は起こらない
                                  ble.sh では一つ目のチルダ展開の解析時点では、
                                  次にブレース展開が来ることを知らないので、
                                  一つ目の ~ はチルダ展開として着色する。
 
       規則がよく分からないが、取り敢えず ble.sh ではブレース展開が現れたら、
       それ以降はチルダ展開が無効になるようにしている。
       具体的には _ble_syntax_bash_command_IsAssign[ctx] の設定されている文脈は、
       ブレース展開が現れたときに、変数代入形式前の文脈値に戻すようにしている。
 
     - echo [a[!b
 
       echo [! の組み合わせは履歴展開にはならない。
       echo [a[!b] の場合にも履歴展開にはならない。
       しかし、echo [!a[!b の場合には履歴展開になる。
       違いは bracket expressions が閉じているか閉じていないかである。
       然し、それを判定する為には先読みをして単語の最後まで見ないといけない。
       それは実装上困難なのでこれは諦める。
 
       (bash の parser がここでどう動作しているのかは不思議ではある。
       例えば echo [a[!echo""] は無効で [a[!echo"" は有効である。)
 
     - echo $((echo)>/dev/null)
       よく考えたらこの有名なパターンに対応するのを忘れていた。
 
     - echo $(case A in A) echo B;; esac)
       実はこのパターン。Bash-4.0 以降では大丈夫だが、
       Bash-3.2 以降では構文エラーになる。ble.sh は bash-4.0 以降の振る舞いしかしない。
 
     - ${#var[...]修飾}
       この形式は Bash 的には構文エラーになるが、[...] の中身を相当先読みしないと
       修飾があるかないかを見る事ができないので諦めている。
 
     - set +H; echo ${!!修飾}
       これは Bash では構文エラーだが何故かが分からない。
 
     - {$v,$w}xxx これは $vxxx $wxxx に展開される。
       つまり、v と xxx がくっついて新しい変数名になる。
       これは分かりにくい動作だが、これを逆に使う人もあるのかもしれない。
       実の所、ブレース展開も文法レベルで実施されるべきなのかもしれない。
 
     - $((a[\10])) $((a["10"])) ${v:a[\10]} (bash <= 4.3)
 
       Bash では最初の解析で a[\10] の部分が抜き出されて、その後で a[\10] が処理
       される。最初の解析では [] の入れ子は考慮されない。一方で \10 が有効かどう
       かを判定する為には [] の入れ子を追跡する必要がある (bash-4.3 以下では \10
       は [] の外では使えないが中では使える)。ble.sh の実装ではこの場合には []
       の入れ子は追跡しないことにする。つまり、bash-4.3 以下では $((a[\10])) が
       許される筈なのにエラー着色になる。
 
       Bash-4.4 以上では上記の文脈では [] の内外で振る舞いが一貫しているので実際
       上の問題は出ない。他にも ((expr)) や ${v:expr} でも同様の入れ子追跡の処理
       の問題があるが、これらの場合には [] 内部と外部の振る舞いは一貫しているの
       で実際上の問題にはならない。
 
     - ${v:a["10"]} に関しても上と同様の問題がある。これは bash-5.1 以下で問題になる。
 
   * 2019-02-04 プログラム補完関数の中で標準入力は使えない。
     どうしてもユーザからの入力を得たい場合には、
     現在の補完が自動補完でない事を確認してから /dev/tty から直接取る事。
 
 bash 実装上で注意するべき事
 
   * 3.0以上 [Note: これは regcomp の問題かもしれない]:
     正規表現 '.^' や $'\n^' は文字列の先頭ではなく行頭に一致する。
 
     その他の場合 (.*^ など) にはちゃんと文字列の先頭にしか一致しない様だ。
 
     Ref. #D1869
 
   * bash-5.2 以上の patsub_replacement に注意する。
 
     任意の文字列に置換する場合は & が勝手に解釈されない様に "${var/x/"$s"}" の
     様に quote すると良い。但し、bash-4.2 では "${var/x/"$s"}" の " は literal
     に解釈されてしまう事に注意する。一番安全なのは一旦変数に代入するという事。
 
   * 変数の代入は基本的に quote は必要ないが、
 
     1 チルダで始まる時はチルダ展開を防ぐ為に quote が必要。
       (変数展開の中にあるチルダは quote しなくても大丈夫)
 
     2 配列要素を空文字列で連結するときは quote が必要。
       つまり、IFS= eval 'declare var=${arr[*]}' とすると空白区切りになる。
       IFS= eval 'declare var="${arr[*]}"' とする必要がある。
       また IFS が中身のある場合には問題は起こらない。
 
       - bash-4.3 以降では IFS= eval 'var=${arr[*]}' なら OK
 
     関係あるか分からないが
     http://lists.gnu.org/archive/html/bug-bash/2017-04/msg00001.html
     において以下のような例が紹介されている。これは bash-4.5 で修正されるらしい。
 
     | bash-4.2$ unset IFS; set ' '; a=$*; printf '<%s>' "$a"
     | < >
     | bash-4.3$ unset IFS; set ' '; a=$*; printf '<%s>' "$a"
     | <>
 
   * コマンドをつなぐ && と || の優先順位は同じで左結合である
     但し、算術式や [[ ]] に登場する && と || はC言語と同じ優先順位である。
 
   * unset の引数は quote しないとパス名展開の対象である。
     特に配列要素を消す場合には [...] を quote する必要がある。
 
   * unset -v または unset -f と明示的に指定しないと、
     意図せず同名の関数または同名の変数を消去してしまう可能性がある。
     変数を消す場合でも unset -v と明示する必要がある (ref #D0893)。
 
   * コマンドの単語中のパラメータ展開は "" でクォートする必要がある
     (ref #D0943)
 
     特に値として以下の物が含まれている可能性がある時は絶対必要である。
     先ず始めに IFS に含まれる文字がある場合は意図しない単語分割を抑制する為に "" で囲む。
     次に、グロブの特殊文字 *?[ が含まれている場合にも注意する。
     shopt -s extglob の時には @( や !( の並びにも注意する必要がある。
     更に、'\' が含まれる場合もグロブ特殊文字のクォートに何故か影響を与える様なので注意する。
     これは例えば shopt -s failglob において、a='\'; echo $a'*' がエラーメッセージを出す事で分かる。
 
   [complete 仕様について]
 
   * compgen -f はクォート除去、チルダ展開を実行する
     理解できないのはクォート除去した後にチルダ展開をするという事。
     compgen -f "'~/'" としても '~' というディレクトリには決して一致しない。
     compgen -f "'\~/'" 等とクォートした上に backslash も指定しないと行けない。
     結局どういう規則なのか分からないので、寧ろ arr=('~/'*) 等の様にするべき。
 
     Note: ~ だとちゃんと現在のディレクトリ以下のファイルに一致するようだ?
     Note: compgen -W でも似たような quote 除去・ブレース展開などを行う様だが、
       それでも理解できる振る舞いになっている。
     Note: bash --norc で echo \~/ から補完を実際に実行してみると echo ~/... に書き換わってしまう。
       何処かで quote が消えてしまっている。これはバグと見做すべきであろう。
 
   * $ complete -F foo -C bar command と登録すると foo, bar の両方が foo bar の順に実行される。
     $ complete -C bar -F foo command と登録すると bar foo の順に実行される。
     しかし、complete -p とすると両者とも
     complete -C 'bar' -F foo
     と表示され登録順・実行順についての情報を取り出す事ができない。
 
     →今試すと必ず foo bar の順序でしか呼び出されない。compgen でも同様に見える。
 
   * $ complete -F hoge1 -F hoge2 command とすると、-F hoge2 だけ有効になる
     (complete -p による表示もそうだし、実際に実行されるのも hoge2 だけであった)。
     -F オプションは後からものによって上書きされるという事の様だ。
 
   * shopt -q は通常の出力はやめてもエラーメッセージは出す。
     つまり未実装のオプション (compat* や autocd) について
     shopt -q をするとエラーメッセージが出力されるので
     結局 &>/dev/null にリダイレクトしなければならない。
 
   * locale の環境変数 LC_*/LANG を設定する時は &>/dev/null する必要がある。
     ref #D1205 #D1341 #D1355
 
     元々入っていた値が不正な値である場合、
     元の値を復元した時にエラーメッセージが意図されず出力される。
 
     ローカル変数として設定する場合は、
     - 値の復元はどうやら関数の本体を完全に実行し終わった後に起こる様なので、
       関数の本体自体を &>/dev/null で囲んでも意味はない。
     - 関数の中で unset を行っても意味はない。
     - 関数の中でもとの値を設定しても意味はない。
       関数が抜ける時に改めて設定される様だ。
 
     IFS= LC_ALL=C read -t 0 &>/dev/null
     としても復元時のメッセージは何故か抑制できなかった。
 
     * #D1341 更に、bash-4.1 以下では LC_ALL= LC_COLLATE=C func 等の形式にしても
       効果が現れない。local LC_ALL= LC_COLLATE=C としないと効かない様である。
 
       外部コマンドを呼び出す時には問題は起こらない。関数経由でも大丈夫。
       逆に外部コマンドの時には "LC_ALL=C awk" の形式にする必要がある。
       もしくは "local -x LC_ALL= LC_COLLATE=C" とする。
 
       ng$ aaa() { echo ${#1}; }; LC_CTYPE=C aaa あいうえお
       ok$ echo あいうえお | LC_CTYPE=C awk '{print length($0)}'
       ok$ echo あいうえお | LC_CTYPE=C ble/bin/awk '{print length($0)}'
 
     * 2021-01-15 aaa() { local LC_ALL= LC_CTYPE=C; ... ; } 2>/dev/null の形式でも
       駄目だという事が判明した。ちゃんとする為には関数内で unlocal までする必要がある?
 
   * Bash 正規表現はシステムの <regex.h> を使用するので環境依存である。
 
     Linux においては bash 正規表現の POSIX 文字クラス ([[:alpha:]] など) は
     ロケールによって何にでも一致するので信用できない。
     例えば GNU/Linux (Fedora 25) では ja_JP.UTF-8 で [[:alpha:]] は漢字・仮名にも一致する。
 
   * bind 関数の中で set +o emacs などをして編集モードを無効にすると、
 
     編集関数の実行自体が中断されるようである。
     具体的には set +o emacs を含む行だけ実行されて、次の行以降は実行されない。
     set +o emacs が eval に含まれる場合は eval が終わると共に中断される。
     また関数内に set +o emacs がある場合は、その関数は最後まで実行されるようだ。
 
     従って set +o emacs が実行されたことを検知して適切な後処理を実行するのは難しい。
     更にその後で set -o emacs に戻ってくると変な状態になる。
     bind -p ではちゃんと hook された状態になっているが、
     実際に操作してみると keymap はリセットされているように見受けられる。
     この辺りはもう少し詳しく調べてみないと具体的に何が起こっているかはわからない。
 
     例: 以下の3行のコマンドを実行しようとすると途中で中断され元の状態には戻らなくなる。
 
     $ set +o emacs
     > echo hello
     > set -o emacs
 
     直接 readline で実行している場合にはこの問題は起こらない。
 
   * ble.sh では変数の -i は積極的には使用しないことにした ref #D0894
 
     関数引数に使用する場合は、そもそも -i の機能を使う機会の方が少ないので
     全ての関数の引数に適用するのは非効率であり、一部の関数の引数にだけ適用するのは
     関数の仕様として分かりにくくバグの元である。そもそも算術式展開が必要化どうかは
     呼び出し元が知っていることのはずなので呼び出し元で算術式展開をするべきである。
 
     関数内で使用する場合についても明示的に算術式展開を実行すれば良い。
 
   * bind 関数中の set +v は揮発性 ref #D0930 (Bash 3.0--5.0)
 
     bind 関数中で set +v 等としてもその状態は
     次の bind 関数の呼び出しの際には元に戻ってしまう。
     この振る舞いは試した全ての bash version で共通だった。
 
 bashbug: 実装上で注意するべき事・バグ
 
   * bash-5.0 -- 4.4 (ref #D1334)
     trap handler が実行中に return を無引数で呼び出すと、
     無条件に trap handler 起動直前の $? が関数の終了ステータスになる。
     POSIX に要求されていると書かれているが解釈に難がある。
     特に trap handler を抜ける時の戻り値だけに影響を与えるのが自然に思われる。
 
   * bash-5.0 -- 3.0 (全 version) バグ (ref #D0943)
 
     $ shopt -s failglob
     $ a='\'; echo $a'*'
 
     これで failglob になる。\* に一致するファイルは存在しませんのエラーメッセージ。
     ファイルとして '*', '\*', '\a', 'a' 等があっても決して一致しない。
     これを防ぐ為には、パラメータ展開は必ず "" でクォートする様にすれば良い。
 
   * bash-5.0 -- 3.0 (全 version) バグ
 
     history -p をコマンド実行中に呼び出すと呼び出す度に履歴項目が減る。
     これは例えば f1() { history | tail -1; history -p '!!'; history | tail; } として、
     f1 を実行すると分かる。f1;f1;f1 等とすると一回で3件消える。
     更に bash-3.0 では bind -x の関数の中であっても history -p を呼び出す度に履歴項目が減る。
 
   * bash-4.4 -- 4.3 バグ
 
     \C-@ 関係に bind -x すると正しく動かない
     bash-4.4 での動作については未だ確認していない。
     → bash-4.4 でもやはり動かない。
 
     これは修正した http://lists.gnu.org/archive/html/bug-bash/2018-03/msg00165.html
 
   * bash-4.4 -- 3.2, etc
 
     rex="^([^\$]|\\'[^\\']*\\')+\$" && [[ 'i$' =~ $rex ]] && echo hello
     が一致する。\' の解釈が謎である。単に ' とすれば問題ない。
 
     rex=$'^([^$]|\\\'.\\\')+$' でも一致する。
     rex=$'^([^$]|\\\')+$' だと一致しない。
     \' は何らかのアンカーとして解釈されるという事だろうか。
     或いは単純に無視されているのか。
 
   * bash-4.2
 
     declare -g -r var とした時に、
     グローバル変数が定義されていなければローカルに新しく変数を作る様だ。
     bash-4.3 で直っている。
 
   * bash-4.2 以下
     bash-4.2 ～ bash-3.0
 
     \C-x 単体に bind -x して C-x に続けて何か打つと segfault する。
     $ bind -x '"\C-x":echo' → 続けて C-x a 等と入力
 
   * bash-4.1 以下: LC_CTYPE=C eval 'echo ${#var}' としても
     ${#var} が元のロケールで計算される。"変数代入 コマンド"
     の形式だとロケールの初期化が間に合わないのだろうか。
 
   * bash-4.0 segfault
 
     以下で segfault を起こすことが分かった。bash-4.1 以降では直っている。
 
     bash-4.0 -c 'function f1 { COMPREPLY=(alpha); }; compgen -F f1 2>/dev/null'
 
     但し、ble.sh の使用中に実際に compgen -F を通して segfault になることはなかった。
     もしかすると何らかの条件が整うと segfault するかもしれないので、
     念のためここに記録に残しておく。
 
   * bash-3.2 以下ではプロセス置換に含まれるブレース展開は
     プロセス置換ごと複製してしまう。
     例えば echo <(echo {1..3}) は、
     echo <(echo 1 2 3) ではなくて、
     echo <(echo 1) <(echo 2) <(echo 3) に展開されてしまう。
 
   * bash-3.2 以下では declare a としただけで空の値で初期化される。
     unset 状態になるという事はないので注意を要する。
 
   * bash-3.2, bash-3.1 では source にプロセス置換を渡しても読み取ってくれない。
     つまり source <( ... ) としても何も起こらない。
     代わりに eval -- "$( ... )" すると良い。
 
   * bash-3.2 -- 3.1
 
     ref #D0857
     10 以上のファイルディスクリプタで使用されている物に対して
     リダイレクションで新しい出力先を設定しようとしても失敗する。
     これは fd>&- として一旦閉じてからリダイレクションすれば良い。
 
     bash-3.1 では一度開いた fd を改めて開き直したり、
     或いは閉じたりすることができない。
     exec 34>/dev/null とすると、exec 34>&- としても閉じれないし、
     exec 34>a.txt としても /dev/null に繋がったままになってしまう。
 
   * bash-3.1 では declare -f funcname の funcname に + 等の文字を含める事ができない。
     一応 declare -F 等とすれば名前は列挙される様ではある。
     bash-3.2 未満では declare -f ではなく type -t で関数かどうかの確認を行う。
 
   * bash-3.1 での bind -r について
     bind -sp とすると "\M-[C" 等と表示されるがそれに従って bind -r '\M-[C'
     としても削除する事は出来ない。代わりに bind -r '\e[C' とすれば削除できる。
 
     eval -- "$(bind -sp | awk '/M-\[/{sub(/:$/,"",$1);gsub(/\\M-/,"\\e");print "bind -r " $1}')"
 
   * msys1, msys2: var='^M' とすると CR が消えてなくなる。
     msys2 では var=$'\r' とすれば大丈夫。また変数に入っている物も大丈夫。
     例えば var=$_ble_term_CR はOKである。
     msys1 ではそれでも駄目。local var=$'\r' とすれば大丈夫。
     変数に入っている物でも local を付けないと消滅してしまう。
 
     Ref #D1270
 
   * msys1 では named pipe が未対応。従ってプロセス置換も使えない。
 
 bashbug 算術式周りのバグと注意点
 
   * bash-3.0 - 4.4.7 算術式:
 
     条件分岐で実行されない部分でも配列の添字は 0 以上でなければならない。
     例えば以下はエラーになる @ bash-3.0, 3.1, 3.2, 4.0, 4.2, 4.3
     ((a=-1,a>=0?b[a]:0))
 
     もっと調べてみると配列の添字に限らず分岐しない所で式が評価されている様だ:
 
     + 三項条件式で起こる。true/false branches のどちらでも起こる。&& や || では起こらない。
 
       $ echo 'x=a=1; ((a=0,0?x:0)); echo $a' | bash      1 (bash-3.0 - 4.3)
       $ echo 'x=a=1; ((a=0,1?0:x)); echo $a' | bash      1 (bash-3.0 - 4.3)
       $ echo 'x=a=1; ((a=0,0&&x)); echo $a' | bash       0 (bash-3.0 - 4.3)
       $ echo 'x=a=1; ((a=0,1||x)); echo $a' | bash       0 (bash-3.0 - 4.3)
 
       $ echo 'x=a=1; ((a=0,0?b[x]:0)); echo $a' | bash   1
       $ echo 'x=a=1; ((a=0,0&&b[x])); echo $a' | bash    0 (bash-3.0, 3.1, 4.2+ / bash-3.2, 4.0, 4.1 は別の bug で 1)
 
     + 括弧で囲めば何も起こらない様だ。
 
       $ echo 'x=a=1; ((a=0,0?(x):0)); echo $a' | bash    0 (bash-3.0 - 4.3)
       $ echo 'x=a=1; ((a=0,1?0:(x))); echo $a' | bash    0 (bash-3.0 - 4.3)
 
       $ echo 'x=a=1; ((a=0,0?(b[x]):0)); echo $a' | bash 0 (bash-3.0, 3.1, 4.2+ / bash-3.2, 4.0, 4.1 は別の bug で 1)
 
   * bash-4.2 算術式 seg fault
 
     https://lists.gnu.org/archive/html/bug-bash-gnu/2013-01/msg00036.html
     https://lists.gnu.org/archive/html/bug-bash-gnu/2013-01/msg00042.html
     https://lists.gnu.org/archive/html/bug-bash-gnu/2013-01/msg00043.html
 
     算術式の中で配列要素の参照に関係して特定の式構造になると segfault する。
     多分、配列要素の読み出しの次の token が整数または代入式の左辺だと落ちる。
     配列要素を参照したら一旦算術式を閉じるのが良い。
     $ ((a=b[0],c=0))
 
     以下でも segmentation fault が起こった。
     $ (((klen=node[nofs+k])<0||(kbeg=j-klen)>end0))
     $ (((a=node[1])<2||(b=3)))
     $ (((a=node[1])||(b=3)))
     $ (((a=node[1])<2||b)) # OK
     $ (((a=node[1])||b))   # OK
     $ (((node[1])||(b=3))) # OK
     やはり起こる条件が良く分からない。
     代入式の右辺に配列が来て、
     その後に代入式の左辺に token があると駄目なのか?
 
   * bash-4.1, 4.0, 3.2: 算術式分岐内配列参照
 
     bash-3.2.48 で以下の評価に失敗する。
     bash-3.1 以下は大丈夫。bash-4.2, bash-4.3 も大丈夫。bash-4.0 は駄目。
 
     dbg=()
     ((a=0,b=0,0&&(a=1,x=dbg[0],b=1))) # NG
     配列添字で値を参照 (代入はOK) すると、その部分以降が必ず実行される。
     複合代入であっても駄目である。
 
     bash-4.0 bash-4.1 でも以下の式で必ず _pos[1]++ が実行されていた。
     ((_eoc[2]&&(_pos[0]=0,_pos[1]++)))
 
 
     $ ((a=0,b=0,0&&(a=1,x=dbg[0],b=1))); echo $a $b               → 0 1
     $ expr="a=1,x=dbg[0],b=1"; ((a=0,b=0,0&&expr)); echo $a $b    → 0 1
     $ expr="a=1,x=dbg[0],b=1"; ((a=0,b=0,0&&(expr))); echo $a $b  → 0 1
 
     更に配列添字も必ず評価されてしまう。
     ((i>=0&&a[i])) は i が負であっても参照される。
     そして、((i>=0&&a[i--])) をすると更に副作用も起こる。
 
   * bash-4.1 以下 (bash-3.0 ～ bash-4.1)
 
     配列要素に対して修飾付きのパラメータ展開を実行すると、
     配列添字に指定した算術式が2回評価される。
     例えば "${arr[i++]#a}" を実行すると i が 2 増える。
 
   * bash-4.0 他 算術式を使って値を計算する時の注意
 
     算術式の中に初期化されていない変数…例えば ret 等がある場合、
     ret の中身に不正な数式的な物が入っていたりコマンド置換が入っていたりすると、
     文法エラーになったりこれが eval されてしまう。
     実際に 4.0 では 'あ' という文字列が入っているだけでエラーになる。
     (より上の version では識別子名と解釈されているからなのかエラーにはならない。
     しかし、今迄は毎回「あ」等という変数を探していたのだろう。
 
   * bash-3.1, 3.0
 
     ?: 演算子の中身は全てカッコで囲まないと構文エラーになる。例えば、
     $ bash-3.1 -c '((a?(b=123):c?(d=321):1))'
     bash-3.1: ((: a?(b=123):c?(d=321):1: syntax error in expression (error token is "?(d=321):1")
 
 bash 配列の宣言に関する注意点
 
   * arr=(1 2 3) func の形式で配列をシェル関数に渡そうとすると、
     export arr='(1 2 3)' で渡されてしまう。
 
   * 既に配列変数になっている物に対して
     export var=value や typeset -x var=value をしても、
     呼び出された別コマンドからは環境変数として見えない。
 
     $ a=(1 2 3)
     $ (export a=1; bash -c 'declare -p a')
     bash: 0 行: declare: a: 見つかりません
 
     新しい変数として導入すれば良い。
     例えば関数内で新しく local -x var=value とするか、
     var=value command の形式で呼び出すようにすれば良い。
 
     $ (a=1 bash -c 'declare -p a')
     declare -x a="1"
 
 その他のバグ
 
   * BUG gawk-4.0.2 正規表現 [][:space:]] や [^][:space:]] に対して警告メッセー
     ジを出力する。実際には正しく解釈して正しく動作する様である。また、他の gawk
     version では問題はない。
 
     これは scan チェックに含める事にする。
 
 bash_features
 
   * time -- について。
     bash-5.1 以降で time -- command が可能。
     bash-4.2 以降で time -p -- command が可能。
     (bash-4.1 以前では time には -- を指定できない)
 
   * bash-5.0 以降: EPOCHREALTIME, EPOCHSECONDS
     ref #D0925
 
   * Bash-5.0 では POSIX に倣ってパラメータ展開結果に \ が含まれる場合に
     グロブパターンと見做す様に変更されたが、
     これにより問題が起こり POSIX が記述に誤りがあることを認めて修正した。
     結局 Bash-5.1 で 4.4 と同じ動作に戻すつもりらしい。
     https://lists.gnu.org/archive/html/bug-bash/2020-03/msg00051.html
 
   * ${param@a} (attributes) 及び他の transformation は bash-4.4 より
 
   * read -t timeout
 
     * -t オプションの対応は 2.04 である。
     * TMOUT 変数の対応は 2.05b-alpha1 以降である。
     * 小数を指定できる様になったのは 4.0-alpha 以降である。
     * `-t 0' で次の文字を読み取り可能かどうかチェックできるのは 4.0 以降である。
     * 4.3 以下では timeout した時に読み取った入力は失われてしまう。
       4.4 以降では timeout するまでに読み取った内容が指定した変数に格納される。
 
   * グローバル変数に対する属性指定 declare -g は bash-4.2 から
 
     更に bash-4.3 には declare -gA を二度行うとクラッシュするバグがあったらしい。
     現在の最新版ではそのような振る舞いは見られない?
 
     2021-02-10 #D1470 どうも bash-4.2 の declare -g にはバグがある。declare -gA
     とすると属性は global まで適用されるが、代入された値は関数を抜けると共に消
     滅する。2021-05-20 追記。declare -gA a=() とすると関数を抜けると共に値が消
     滅するが、declare -gA a; a=() とすると特に問題は生じない。
 
   * 連想配列 declare -A は bash-4.0 から
 
   * BASHPID 何と Bash 4.0 以降の機能らしい ref #D1200
 
     ------------------------------------------------------------------------------
     This document details the changes between this version, bash-4.0-alpha,
     and the previous version, bash-3.2-release.
 
     c.  There is a new variable, $BASHPID, which always returns the process id of
         the current shell.
     ------------------------------------------------------------------------------
 
     と思ったら既にソースコードの一部にも Bash 4.0 以降であるとの注記があった。
 
   * command |& command は Bash 4.0 以降なので使えない。
 
   * printf -v var %s value
 
     bash-3.1 以降で使える。
     bash-4.1 以降で var として配列要素 (arr[123] 等) を指定できる。
 
   * printf %(...)T は bash-4.2 以降から。但し、bash-4.2 では -1 を明示的に指定
     しないと現在時刻になってくれずに 0 になってしまう。bash-4.3 以降では省略し
     た場合は現在時刻になる。
 
   * ${!arr[@]} は bash-3.0 より
 
 bash_tips
 
   * swap の仕方
     local a=$b b=$a
     local や declare などは必要である。
 
   * [[ ]] の中で =~ で設定された BASH_REMATCH は直後の式で参照できる。
     つまり [[ $text =~ $rex && $BASH_REMATCH == ... ]] の様にできる。
 
     bash-3.0 から bash-4.4 までで以下のコマンドで確かめた。
 
     [[ "" =~ ^ ]]; [[ $BASH_REMATCH ]]; [[ a =~ a && $BASH_REMATCH ]]
 
   * 構文関係でマニュアルに載っていないものが色々ある。
 
     * }, fi, done, esac の直後に }, fi, done, esac, do, else, elif, then が来る場合はセミコロンは省略できる。
 
     * for ((expr1; expr2; expr3)) [ ; ] { list; } は比較的有名だが、
       for name [in name]; { list; }
       select name [in name]; { list; } も使える様だ。
 
     * select name [ [ in word ... ] ; ] do ...; done
       ※in word ... がない場合、do の前のセミコロンは省略可能である。
 
   * "$(case *) ;; esac)" に対応する可能性があるかと思ったが動きはない
     ref http://lists.gnu.org/archive/html/bug-bash/2017-11/msg00002.html, #D0928
 
   * function @() { ...; } は成功するが実際には関数は作られない
     ref http://lists.gnu.org/archive/html/bug-bash/2017-03/msg00220.html, #D0927
 
   * declare -c var という隠し属性がある。Capitalize する。Bash 4.0+
     変数の値の各単語について適用するのではなく本当に最初の文字にしか適用されない。
     この中途半端な機能の為に恐らくマニュアルに載っていないのだろう。
 
     ソースコードを確認すると他にも declare -G var という謎機能が存在する。
     同じ文脈に局所変数があればそれに設定してそれ以外ならば大局変数に設定する。
     これは丁度他の言語のレキシカルスコープを真似た物という事だろうか。
 
   * nameref & extra expansion
     気付いたのだが declare -n ref='arr[...]' の ... に任意の式を記述できる。
     これによって新しい乱数変数も定義できるのでは。例えば。
 
     declare -n var='var_[var_=RANDOM*RANDOM,0]'
 
     但し、算術式なので整数以外は代入できない。
     更に、$() でプログラムを実行することすらできる。
     然し、任意の文字列という訳には行かないのが問題。
     $() はサブシェルで実行されるので副作用を残す事ができない。
 
   * let & brace expansion
     これは算術式のページに既に書いた。
 
   * rcfile を処理している間は
 
     * 関数内で FUNCNAME, BASH_SOURCE, BASH_LINENO を確認するとFUNCNAME
       の最後の要素は "source" であり、BASH_LINENO の最後の要素は 0 に
       なっている。BASH_SOURCE の最後の要素がファイル名である。
 
     * bash-4.4 以降では $- に s (標準入力から読み取り中) が含まれない
       事で確かめられる。bashrc を抜けてPROMPT_COMMAND を実行する時には
       s が含まれる様になる。bash-4.4 未満では s は決して含まれない事に
       注意する。
 
     まとめると以下の様な関数で rcfile 中で走っているかどうかを判定できるのではないか。
 
     function ble/util/is-running-in-rcfile {
       [[ $- == *i* && ( _ble_bash -lt 40400 || $- != *s* ) ]] || return 1
       local nstack=${#BASH_LINENO}
       [[ ${BASH_LINENO[nstack-1]} == 0 && ${FUNCNAME[nstack-1]} == source ]]
     }
 
 
 *******************************************************************************
     Memo
 -------------------------------------------------------------------------------
 
 2023-01-31
 
   * review: direnv [#M0023]
 
     direnv は .envrc を bash で評価して、環境変数の変更を調べて、それを各シェル
     の変数に反映させるらしい。これにより使うシェルに依存せず一つの .envrc で同
     時に対応できる。然し一方でこれが意味する所は、環境変数だけしか親シェルに反
     映させる事ができないのだろうという事。ローカルな関数やエイリアスは引き継が
     れない (或いはエイリアスであれば可能であろう)? また環境変数に制限する事によっ
     てディレクトリに入る前の環境変数のセットをそのまま保存する事によって
     push/pop を自前で実装しなくて済む様になっている。
 
     .envrc は direnv allow しないと有効にならない。このallow/unallowedの情報は
     どこに記録しているのだろうか。うーん。別の箇所にディレクトリを作成している
     様にも見える。うーん。
 
     https://github.com/bbugyi200/funky これは各ディレクトリの中にデータベースファ
     イルを作って local functions を保存する事によって動く。グローバルに使える関
     数も定義できる (が .bashrc で定義するのと比べて何が違うのか謎)。
 
     https://github.com/cxreg/smartcd これは機能的になかなか参考になる気がする。
     README の see also のまとめが参考になる。
     https://github.com/cxreg/smartcd#see-also
 
     https://github.com/Tarrasch/zsh-autoenv ... smartcd SEE ALSO による
     と、~/.autoenv_authorized に実行して良い env ファイルが記録されているそうだ。
 
     https://github.com/hyperupcall/autoenv ... これは bash にも対応している。記
     録ファイル ~/.autoenv_authorized は zsh-autoenv と同じ様である。
 
     https://github.com/jamesob/desk ... これも似たような事を実装しているが、恐
     らく予め設定した内容だけでなく現在のディレクトリやコマンド履歴などの動的な
     情報も「セッション」として記録している気がする。然しここまで来ると screen
     で良いのではないかという気がしてくる。
 
 2021-12-31
 
   * "function f {}" vs "f() {}" [#M0022]
 
     function f は元々は ksh functions で、POSIX functions f() とは局所変数の取
     り扱いが異なる。ksh では f() の形式の関数では局所変数を定義できない。ksh
     functions ではその関数で宣言したローカル変数またはグローバル変数しか見えな
     い。この背景から function f() という両方を組み合わせた形で書くと鬼の首を撮っ
     たかの様に指摘してくる人がいる (Greg Wooledge だったか)。
 
     f() の形式の場合には f の部分は alias 展開の対象である。例えば alias
     die=std::die 等として名前空間を import している時に、関数を上書きしたい時に
     それが alias されているという事を意識せずに直接 die() { ... } 等として上書
     きする事ができる。
 
     function ... の場合には、f() の形式では定義できない、特別な文字を含んだ関数
     も定義する事ができる。POSIXLY_CORRECT の時には結局どちらの形式を使ったとし
     ても、識別子以外の名前で関数を定義する事はできないのであるが。
 
     Bash 5.0 以前では function hello の直後にはサブシェル () を本体とした定義は
     置けない。文法的にはこれが当たり前の様な気もするが、Bash 5.1 以降では直後に
     サブシェルを置ける様である。例えば function f(echo) など。
 
 2021-05-16
 
   * Linux パッケージのチェック (by killermoehre) [#M0021]
     どの Linux にどのパッケージのどの version が入っているかを調べられるサイト
     https://pkgs.org/search/?q=groff
 
 2021-05-15
 
   * PKGBUILD の説明は此処にある [#M0020]
     https://wiki.archlinux.org/title/VCS_package_guidelines
     https://wiki.archlinux.jp/index.php/PKGBUILD
     https://wiki.archlinux.jp/index.php/%E3%83%91%E3%83%83%E3%82%B1%E3%83%BC%E3%82%B8%E3%81%AE%E4%BD%9C%E6%88%90#.E9.96.A2.E6.95.B0_pkgver.28.29
 
     PKGBUILD と一緒に.SRCINFO も更新すること。
     pkgrel は新しい pkgver に変わったら一緒に 1 に変更する。
 
 2021-05-03
 
   * awk の互換性に関する注意点 [#M0019]
 
     * 正規表現 {m,n} は gawk-4 以降でしか既定で使えない。gawk-3 も nawk も mawk
       も駄目。
 
       POSIXに反しているが過去の互換性の為という事らしく gawk-3 では
       POSIXLY_CORRECT またはオプション --posix または --re-interval を指定すれ
       ば利用できる様になるが、nawk/mawk はそういうオプションすらない。
 
     * 正規表現 A?A? は mawk では最初の A? しか一致しない。
 
       これは明らかにバグの気がするがどうなのだろうか。
 
     * 16進リテラル 0xHHHH は gawk でしか使えない。
 
 2021-05-01
 
   * ble.sh 初期化時の Bash 設定に対する対策 [#M0018]
 
     ble.sh が set -euxv -o posix や FUNCNEST=0 等特殊な状況で呼び出される事がある。
     この様な環境ではまともに動作する事ができないので設定を適切な順序で解除してい
     く必要がある。
 
     set -eu に関しては適切な記述方法を取れば回避する事ができるので後回しにする。
     set -xv に関しても標準エラー出力を適当な物に繋いで置けば回避できる。set -o
     posix が設定されていると関数を定義できない。その他の振る舞いにも注意が必要だ
     ろう。alias も何が定義されているか分からないので出来るだけ expand_aliases を
     off にする方向で考えたい。
 
     現在の実装では以下の順にチェック・対策を行っている。
 
     1 最初の引数解析 (POSIX shell 準拠): この部分は別のシェルで起動した場合などで
       も引数解析の結果などを表示する為に対策よりも前に処理する。alias で { や if
       が書き換えられている事によって失敗しても、シェルが全く操作できなくなるとい
       う事はないだろうし、ユーザー側の責任とする。
 
     2 Bash のバージョンチェック。これをしないとそもそも対策コード自体動くか怪しく
       なってくるので先にチェックする必要がある。これもシェルが全く操作できなくな
       るという事はないだろうという事で、ユーザー側の責任とする。
 
     3 expand_aliases
     4 FUNCNEST
     5 set +o posix
 
       この三つを設定すれば取り敢えず安全に関数を定義して実行できる。
 
     6 reset-builtins
 
       builtin が上書きされてしまうのを防ぐ為。
 
     7 adjust-options (set +euxv; shopt -u nocaseglob; shopt -u expand_aliases)
 
 2020-05-11
 
   * Bash の HISTTIMEFORMAT 振る舞いのまとめ [#M0017]
 
     ref #D1351
 
     * Bash は、HISTTIMEFORMAT の値に関係なく、コマンドの時刻を常に内部
       的に管理している (#0x10 の件を考えると文字列で記録している疑いが
       ある)。HISTTIMEFORMAT が設定されている時、history コマンドで出力
       されるコマンド履歴に時刻が出力される。
 
     * 変数 HISTTIMEFORMAT が存在する時 (空文字列や unset も含む)、Bash
       は履歴ファイルに #%s の形式で時刻を保存する。
 
     * 履歴ファイルからコマンドを読み取る時、直前に #%s があればそれを
       コマンドの時刻とする。それ以外の時はコマンドの時刻は bash の起動
       時刻とする。これは HISTTIMEFORMAT の状態に関係ない。
 
       履歴ファイルから読み取る時には単一行モードと複数行モードがある様
       だ。変数 HISTTIMEFORAMAT が存在 (空文字列や unset も含む) してか
       つファイルの先頭行が #%s の時に複数行モードになる。
 
       時刻行は "#数字" で始まっているかどうかで判定する。先頭または #
       と数字の間に余分な空白が含まれている場合は時刻行ではない。"#整数
       " の後に別の文字列があったとしてもそれは無視される。但し、"#0"
       で始まっている時だけは行全体を時刻と見做すようで、余分な文字列が
       あると history で出力する際にエラーになる。
 
     * history コマンドの出力は HISTTIMEFORMAT が非空文字列の時にタイム
       スタンプが出力される。
 
       HISTTIMEFORMAT が設定されていても空文字列の時には処理は行われな
       い。これは通常の見た目の振る舞いでは区別がつかない (処理していて
       も処理していなくても出力に違いは出ない) が、履歴ファイルに #0xxx
       の様な無効なタイムスタンプが含まれていた時の振る舞いで分かる。
 
     * shopt -s lithist は、for 等の文法的に複数行に跨るコマンドについ
       て、そのままの形でコマンド履歴に登録する。単にコマンドラインで複
       数行を入力して実行しても改行で分割してコマンド履歴に登録される。
 
       これはコマンドを実行した時に Bash プロセスの内部のコマンド履歴に
       登録する際に影響を与える物であって、履歴ファイルへの書出しや履歴
       ファイルからの読み出しには影響を与えない様である。
 
     現在の ble.sh サポートの制限について。
 
     * mlfix: bash-4.4 以降では複数行コマンドを history -r で読み出せるが、
       bash-4.3 以前では複数行コマンドは history -s で構築せざるを得ない。
       従って複数行コマンドに関しては正しくコマンド時刻を復元できない。
 
 2020-05-06
 
   * trap: DEBUG/RETURN trap のまとめ [#M0016]
 
     DEBUG trap は設置した関数内で有効。set -o functrace (set -T) が設
     置されている時または呼び出される関数に declare -tf を設定している
     時にのみ呼び出される関数に継承される。trap -p の出力は現在処理して
     いる関数毎に異なる (継承しない場合は DEBUG/RETURN trap に対しては
     何も出力されない)。
 
     DEBUG: bash-4.3 以下では設置した関数の呼び出し元には影響はないが、
     bash-4.4 以降では呼び出し元の DEBUG trap も上書きする。DEBUG trap
     を削除した場合には、呼び出し元には影響は与えない。DEBUG trap の中
     では DEBUG trap は発火しない。
 
     RETURN:
 
     * BASH_COMMAND には最後に関数内で実行したコマンドが入っている。
       return を使った場合にはそれが、関数の末端で終わった場合には最後
       のコマンドが入っている。
     * RETURN trap は関数内部で実行されるので、return を呼び出して終了
       ステータスを変更する事ができる。但し、条件をつけないと、RETURN
       trap の return に対して再び RETURN trap が発火して無限ループにな
       るので注意する。
     * RETURN trap の中では RETURN trap は発火しない。それ以外の trap
       では発火する。
 
     BASH_LINENO, BASH_SOURCE, FUNCNAME についてはまだ詳しく調べていない。
 
 2020-04-14
 
   * ${###} 等のパラメータ展開・変数展開について [#M0015]
 
     Bash のパラメータ展開 #D1330
 
     <param>
 
     - 位置パラメータ: 1 2 ...
     - 特殊パラメータ: * @ # ? - $ ! 0 _
     - 変数名: /_[[:alpha:]][[:alnum:]]*/ の形式
     - 配列名[添字]
       添字はシェル展開の対象で配列の時は算術式の対象
     - 配列名[@], 配列名[*]
 
     <modifier>
 
     - @A 変数の定義
     - @a 変数の属性
     - @Q @E @P 値を加工する
       これらの ops は展開の対象ではない。つまりvar=A として ${xxx@$var} とはできない。
     - #, ##, %, %%
     - /, //, /#, /% (クォートとの兼ね合い)
     - ^ ^^ , ,, ~ ~~
       Note: ~ については https://qiita.com/t_nakayama0714/items/80b4c94de43643f4be51 に書いてあった。
     - = + - ? := :+ :- :?
     - :offset, :offset:length
 
     * $<param>
       Note: 配列, 2桁以上の位置パラメータは使えない。
 
     * ${...} の例外規則
 
       * ${#<param>}
         ${#@}, ${#*}, ${#a[@]}, ${#a[*]} は要素の数。
         それ以外については文字の数。
 
       * ${!var@} ${!var*}
 
       * ${!arr[@]} ${!var[*]}
 
     * ${<param><modifier>}
     * ${!<param><modifier>}
 
       * ! で始まる物については ${<param>} を変数名とする。
 
         Note: <param> は !, $ 以外でなければならない様だ。
 
         $@ $* ${arr[@]} ${arr[*]} の時には "$*" などを変数名と見做す。
         つまり、普通に ${!arr[*]##} 等とすると要素が1個の時以外はエラーになる。
         (arr=(a b c); IFS=; abc=4321; echo "${!arr[*]##}") 等とすると動く。
         (arr=(a b c); IFS=; abc=4321; echo "${!arr[@]##}") は動かない。
 
     ★${!#} で最後の引数を取れる。${@:$#} でも行ける。
       但し、引数がない場合は $0 に展開される事に注意する。
 
 2020-04-07
 
   * bashrc に於ける history の操作について [#M0014]
     初回の history -nrs の実行時に "未初期化" であれば初期化を行う。
     "未初期化" の判定は履歴がその時に空であるかどうかによる。
 
     * "未初期化" の時に history -awcd を呼び出した時は何も実行しない。
     * "未初期化" の時に history -nrs を呼び出した時は、
       履歴ファイル (HISTFILE) を読み取って初期化した後に要求された操作を実行する。
       これは bash の動作とは異なる。bash は履歴ファイルを読まずに操作を実行する。
       その後で何らかの条件で履歴ファイルの読み取りを最初のプロンプト表示の前に行う。
     * history -p に関しては "未初期化" かどうかに関係なく、そのまま実行する。
 
     bashrc の中で history -r を実行すると履歴の倍加が発生する。
     但し、実行時だけで記録される履歴ファイルは倍加しない。
 
 2019-06-10
 
   * history -na の動作に就いて [#M0013]
 
     * どのコマンド以降を新しいものとして取り扱うのか。という事について。
       特に他の Bash が bash_history に書き込んだ新しいコマンドを読み取った時、
       次に自分が history -a する時にどの範囲のコマンドを追加するのだろうかという事など。
 
       まとめると Bash の動作は恐らく以下の様になっている。
       先ず Bash は2つの変数を使っている。ここでは read_index と write_index と呼ぶ事にする。
       read_index は history -n で HISTFILE から次に読み出すべきコマンドの行番号を保持する。
       write_index は history -a で次に HISTFILE に書き込むべき history 内のコマンドの番号を保持する。
       Bash の起動時には read_index も write_index も同じ値に初期化される。
       history -n を実行すると read_index は HISTFILE の行数に再設定される。
       write_index は読み取った行数だけ増加する。
       history -a を実行すると write_index は history の項目数に再設定される。
       read_index は書き込んだ行数だけ増加する。
 
       この動作に従うと history -n; history -a や
       history -a; history -n を実行すると問題が生じる事になる。
       書き込み済みのデータ・読み取り済みのデータが混ざった時に正しく範囲を表現できない。
       この事が理由で巷にある同期の設定では history -a; history -cr を実行しているのである。
 
     * HISTCONTROL=erasedups
       試してみたが erasedups が設定されていたとしても history -n で新しく読み取った
       コマンドと同じ名前のコマンドを削除するとかそういう事は別にしない様である。
 
 2019-02-13
 
   * keymap: 以下のキーについては既定では同じ動作になる様に設定する事にする [#M0012]
     ref #D0929, #D0752
 
     - DEL C-? / BS C-h
     - NUL C-@ C-SP
     - RET C-m
     - TAB C-i
     - C-_ C-DEL C-BS
 
 2019-01-01
 
   * vi: inclusive/exclusive motion の実装に関して [#M0011]
 
     exclusive な motion は exclusive-goto.impl を呼び出す。
     inclusive な motion は inclusive-goto.impl を呼び出す。
     何れの場合も範囲を修正の後に exclustive-range.impl に委譲する。
 
 2018-08-31
 
   * decode: 端末の送信するキーシーケンスについて [#M0010]
 
     * back (BackSpace)
       xterm は back に対して BS (C-h) を送る。
       C-back に対して DEL (C-?) を送る。
       一方で、mintty, RLogin では back に対して DEL (C-?) を送る。
       C-back に対して C-_ を送る。
 
     * modifyOtherKeys(2)
 
 2018-08-05
 
   * compgen に指定した単語のクォート除去に関して [#M0009]
 
     参考: #D0714
 
     生成するコマンドの種類と、バージョンによってクォート除去されたりされなかったりする。
     以下に、クォート除去されることを期待してクォートしても問題がないかをまとめる。
 
       compgen -A command   クォート不可
       compgen -A directory クォート不可 (Bash-4.3 以降でクォート除去されない※1)
       compgen -A file      クォート不可 (Bash-4.0, 4.1 でクォート除去されない※2)
       compgen -A function  クォート可
       compgen -A variable  クォート可
       compgen -A arrayvar  クォート可
 
     ※1 バグと思われる。ble をロードしていると何故かクォート除去されている。
       然し、--norc や ble ロードなしで実行するとクォート除去されない。
       クォート除去が実行されなくなってしまう条件が分からないのでこれは使わない。
 
     ※2 バグと思われる。
 
 2017-10-31
 
   * ble 関数の典型的な終了ステータスについて [#M0008]
 
     127 適切な widget が見つからなかった:
       (由来: Bash でコマンドが見つからなかった時の値)
 
     126 処理をキャンセルするとき:
 
       install-hook した trap に関して、blehook internal_NAME 経由で trap の発火
       をキャンセルする時に返す値。
 
       廃止: widget を呼び出すことができなかった (未使用)
 
     125 widget を呼び出したが適切な処理が見つからなかった:
 
       __defchar__ に登録した widget がこれを返したとき
       次のハンドラを用いる。具体的には __default__ の呼び出しを試みる。
 
     147 ユーザの入力を非同期に待つ為に一時停止した:
 
       ble/util/idle の処理に於いて条件待ち状態に入る時や、widget に於いてユーザ
       の入力を待つ為に、自発的に一時中断した時に返す値。
 
     148 ble/util/idle や isearch や complete に於いて、ユーザ入力を処理する為に
       一旦現在の処理を中断する時に返す値。vi-mode のオペレータが 148 を返したと
       き後処理を実行せずにそのまま抜ける (由来: 128+SIGTSTP)
 
     124 プログラム補完において補完の再実行を要求する
       (由来: これは Bash の仕様に倣った)
 
     27 widget の動作がユーザによってキャンセルされた (由来: ESC = 27)
 
     6 ble-update で更新の必要がなかった時に内部的に使用 (由来: ACK = 6)
 
     2 コマンドの使い方が異なる
 
     3 ble/util/bgproc は named pipes がシステムでサポートされていない時に 3 を返す。
 
 2017-10-18
 
   * ble-decode: widget に関して [#M0007]
 
     __defchar__ および __default__ に登録された widget が 125 を返した時、
     その入力に対する適切な処理が見つからなかったことを表します。
     この時、次のハンドラの探索が行われます。
     次のハンドラがない場合には対応するものが見つからなかったというエラーになります。
 
 2017-09-24
 
   * vi-mode 以下は現在のところ対応しない予定である [#M0006]
 
     * 2017-09-24 vi-mode: % で用いる matchpairs には現在対応しない
 
     * 2017-09-17 vi-mode (insert mode/newline):
       インデントを挿入するが何もしなかった時にそれを削除することには対応していない。
 
       これは実際の所、挿入モードにおける移動と抜ける時の処理において、
       細工を行えば対応できる。現在の挿入モードの操作の繰り返しの記録の仕組みも使えるが、
       もっと別の仕組みを用意しても良い気がする。
 
     * 2017-09-12 vi-mode: タブ文字上にカーソルがある時のカーソルの表示位置
 
       後、気付いたことはタブ文字に居る時のカーソル位置は、
       ノーマルモードにいるときはタブ文字の最後の位置である。
       要するに p で挿入される位置を示しているとも言える。
       でも全角文字の場合にはちゃんと全角文字の先頭にカーソルが来る。
       この動作は分かりにくいし更に言うと現状の ble.sh の描画コードでは対応していない。
       これには取り敢えず対応しないことにする。
 
     以下は積極的に対応する予定はない。
     将来的に対応する場合の注意点がある場合も含む。
 
     * 2017-10-11 M ( ) [[ ]] { } :s :tag
       これらのコマンドは "ジャンプ" なので、$flag なしで実際にジャンプに成功する場合には
       set-local-mark 96 をする必要がある。
 
     * done: 2017-10-09 取り敢えず今の所はスクロール (C-b C-d C-e C-u C-y など) には対応しない
       →これは #D0886 で対応した。
 
 2017-09-08
 
   * vi-mode: 以下のリンクで重要そうなコマンドの一覧が見られる [#M0005]
 
     http://qiita.com/sfuta/items/0de4ead865c15e9e9b68 ?
     http://qiita.com/sfuta/items/2d646396a6117c8e53e5 g? z?
     http://qiita.com/sfuta/items/fd78f3ece8861f8142ee C-w? [? ]?
     http://vim-jp.org/vimdoc-ja/vimindex.html
     http://vim-jp.org/vimdoc-en/vimindex.html
 
 2015-11-28
 
   * デモ画像の作り方 [#M0004]
 
     * ble-0.2 のデモ画像はキャプチャソフトを使った (ref #D0926)
 
       - Cygwin の mintty を用いた。
         画面の幅は56列にし文字の大きさは14程度が良い。
       - キャプチャソフトには LICEcap というソフトウェアを使った。
       - キー入力を表示するソフトには KeyCastOW を改造した物を用いた
         https://github.com/akinomyoga/KeyCastOW
 
       ble-0.1 の時に行った基本的な操作に加えて、
       ble をダウンロード・展開して試してみるところも含めた。
 
     * ble-0.1 のデモ画像は ttyrec & seq2gif を用いて作成した
 
       準備
       $ # PS1=$'[\e[4;38;5;202mfoo@bar\e[m \\j \\W]\\$ '
       $ TTYREC=1
       $ ttyrec demo.tty
 
       echo hello, world
       printf hello
       [[ a == b ]]
       echo "hello $(echo bash $(echo world))"
       C-r for
       echo 'select, copy and paste' コピーする
       echo insert mode -> overwrite mode
       ls
       echo complete ble-TABdTAB histexpand !#:2
       echo "$HIST[TAB]"
 
       $ seq2gif -f 0 -b 15 -h 14 --render-interval=10 -p rosa --play-speed=1.5 < demo.tty > demo2.gif
 
       gif のフォーマット的には 0.01s よりも小さな遅延は設定できない。
       また、現実のブラウザでは 0.02s (50fps) よりも小さな遅延にすると強制的に 0.10 になってしまう。
       更に、Safari や Internet Explorer では 0.06 (16.67fps) よりも小さな遅延は 0.10 になってしまう。
       更に、Windows に附属している viewer では 0.10 よりも小さな遅延は全部 0.10 になってしまう。
 
       [[Frame Delay Times for Animated GIFs by humpy77 on DeviantArt>http://humpy77.deviantart.com/journal/Frame-Delay-Times-for-Animated-GIFs-214150546]]
       [[How to match animation rate of gif files accross browsers (Fenrir Developer's Blog)>http://blog.fenrir-inc.com/us/2012/02/theyre-different-how-to-match-the-animation-rate-of-gif-files-accross-browsers.html]]
       [[Nullsleep | Jeremiah Johnson - Animated GIF Minimum Frame Delay Browser Compatibility Study>http://nullsleep.tumblr.com/post/16524517190/animated-gif-minimum-frame-delay-browser]]
 
 
 2015-08-14
 
   * [memo] builtin check [#M0003]
 
     eval "grc --color --exclude=./test '\b(builtin[[:space:]]+)?$command\b' | grep -Ev '\bbuiltin[[:space:]]+$command\b'"
 
   * [memo] leak variables check [#M0002]
 
     ble/debug/leakvar#list を実行する。
 
     ble/debug/leakvar#reset var
     ...
     ble/debug/leakvar#check var tag1
     ...
     ble/debug/leakvar#check var tag2
 
   * [memo] 解析(ble-syntax/parse)の際の原則 [#M0001]
 
     データ配列とは _ble_syntax_stat, _ble_syntax_nest, _ble_syntax_tree を指すとする。
     或る点 p1 から或る点 p2 に解析を進める場合を考える。
 
     1 この時データ配列に対する変更は p1-p2 (exclusive) の間にだけ行われる。
       これは解析状態の復元と再開が適切に動作する為に必要である。
 
     2 解析の過程でデータ配列に格納されている情報は使用しない。
       これは解析状態の一致チェックの為に必要である。
       データ配列の内容に依存して動作が代わる場合、
       解析状態が一致しても解析結果が異なってしまう可能性があり、不整合を生む。
 
       但し、_ble_syntax_nest については専用の関数を通して 0-p2 の任意の場所を参照しうる。
       これ(専用の関数を通して得られる情報)については
       解析状態の一致チェックの対象に含まれているからである。
       (_ble_syntax_nest の任意の情報を参照して良いという意味ではない。)
 
     tree-append および nest-pop に対する制限
 
       tree-append は _ble_syntax_tree[i-1] に格納を行う。
       従って上記の条件1から p1<=i-1 つまり p1+1 <= i である必要がある。
       これは少なくとも 1 文字 i を進めてからでないと tree-append を呼び出せないという事である。
       nest-pop も内部的にそのまま tree-append を呼び出しているので同じ制限がある。
 
 
 *******************************************************************************
     bug-bash, third-party bugs & reviews
 -------------------------------------------------------------------------------
 
 2023-02-20
 
   * review: completion 自動生成
 
     argument-parser と一緒に completion を自動生成する試みがある。
 
     - spf13/cobra や rsteube/carapace 等の仕組み。
 
     - https://github.com/adoyle-h/bash-completor
 
     - ble.sh でも最初期に getopts interface を実装して、これだけで引数パーサー
       と同時にそれと consistent なコマンド依存単語着色を実装しようと試みた。結
       局、これは argument parsing 速度が遅いという事で放棄されて
       archive/getopt1.sh に眠っているが、直接実行するのではなくて、事前に関数を
       生成して置くという方式にすればそれは気にしなくても良いのかもしれない (但
       しその分だけ footprint が大きくなる)。実のところ ble-face だとか ble-bind
       の様に初期化時に大量に呼び出される物でなければ、別に其処まで速度を気にす
       る必要はない気もする。
 
     - 最近もシェルで getopts と同時にヘルプ等も自動的に生成しようという試みがあ
       る。これである。
 
       https://github.com/ko1nksm/getoptions
 
     - 他にも類似の物が定期的に github 上に現れる気がするが忘れた。
 
     ble.sh 的には以下の物を同時に全てしてくれるととても良い。
 
     - 引数解析器
     - 引数補完候補生成
     - 単語着色
     - 引数指定方法のエラーの検知、診断情報の取得、修正候補の生成
 
     一般的な枠組みとしては更に以下の様な物もあると便利なのだろう
 
     - ヘルプ自動生成
     - 引数に関する単体テストの自動生成 (特殊ファイル名、巨大数、etc.) →でも正
       しく動作しているかどうかの判定は別で書かなければならないのでは?
 
 
 2023-02-14
 
   * bug-bash: bash-5.2 で -u extquote しても ${var//[$'\n']} が改行を削除する。
 
 2023-02-06
 
   * bug-bash: 実は colored-stats は本来 LS_COLORS を反映するらしい。然し、
     readline 初期化前に設定されている必要がある。colored-stats も bind 等ではな
     くて inputrc 経由で有効にしなければならない様だ。
 
 2023-01-31
 
   * review: bash libraries
 
     https://blog.fascode.net/2022/05/05/fasbashlib/
     https://github.com/Hayao0819/FasBashLib ... これはライブラリ構成としてある
     べき形を一通り備えている様に思える。具体的な関数としてどれだけ非自明なもの
     が用意されているのかは余り確認していない。Common.sh を見ると悪しき set -Eeu
     -o pipefail を前提としている。GNU toolchain を要求している。fork を減らすな
     どの効率化については余り意識されていない気がする。結構 trivial なものまで関
     数として定義されている。うーん。ForEach だとか Array.Length だとか、既に
     bash に機能的に存在している物まで関数で wrap したり pipe 化したりと、syntax
     sugar 的な関数が多く、実践志向ではない。或いは minimalism 的潔さはない。ラ
     イブラリ構成としてメタ的な機能(naming convention 変換, etc)を揃えているので
     良さそうと思ったが、それも namespace の模倣のために整えられた枠組みの副産物
     と見るのが良い気がする。
 
     FasCode project の一部? で、これは何かと検索すると Alter Linux という日本産
     Linux distribution を有志で作っている集まりだろうか? Arch based. Issues を
     見ると日本語メインのコミュニティーで 373 stars. 他に Serene Linux というの
     も作っていて Ubuntu-based -> Fedora-based に変更したと書いている。作ってい
     るのは学生の集団らしい。
 
 2023-01-26
 
   * review: コマンド履歴データベースの設計
 
     fish はファイル名に一致する引数を覚えている。これにより autosuggestions で
     は、コマンドライン中のファイル名が現在していない時にはそのコマンドはスキッ
     プするという具合の振る舞いをする。
 
     https://github.com/ellie/atuin ... 暗号化・ホスト間共有・C-r拡張・各種統計
 
     https://github.com/jcsalterego/historian ... 単に .bash_history を検索するだけ
 
     https://github.com/ddworken/hishtory ... custom column として git_remote が
     紹介されている。git remote 単体が便利かどうかは分からない。sqlite3 だと
     column を dynamical に追加するのは難しそう。一方で git の commit id を一緒
     に記録するというのは一つの可能性である。
 
     https://github.com/larkery/zsh-histdb ... 実は同じ名前で zsh にもその様な
     plugin が存在している様である。中を除いてみたら実装はかなり近い形になってい
     る。履歴を表示するコマンドも用意しているが、余り細かい操作を実行できる訳で
     もない様だ。
 
 2022-06-26
 
   * またもや tempenv=... builtin eval ':;echo $tempenv' のバグに引っ掛かった。
     これはやはり直して貰いたい。
 
 2022-02-15
 
   * tmpenv builtin eval vs DEBUG trap
     Ref #D1772
 
     function print { echo "v=${v:-(not found)}"; }
     function trapdebug { echo "$FUNCNAME:1:v=($v)"; }
     builtin trap 'trapdebug' DEBUG
     v=xxxx eval print
     v=xxxx builtin eval print
 
     以上に於いて builtin eval print で実行される print に対する DEBUG trap の中
     から v=xxxx が見えない。eval print の時にはちゃんと見えているので意図的な振
     る舞いとも思われない。
 
 2022-01-23
 
   * wezterm, bash-preexec に対する patch を終結させる。
 
     * bash-preexec に API 安定化のお願いをする → これは PR を出したが返事がない。
       時々活動はあるみたいなので少しでも反応があった時に改めてお願いする事にする。
 
   * bash-preexec は既存の DEBUG trap を正しく実行できていない様に思われる
 
     $ trap 'echo XXX' DEBUG
     $ echo 1; echo 2; echo 3
     XXX
     1
     XXX
     2
     XXX
     3
     $ source bash-preexec.sh
     XXX
     XXX
     XXX
     $ echo 1; echo 2; echo 3
     XXX
     1
     2
     3
 
     これは意図的な物なのだろうか。。と思ったら以下に議論がある。
 
     https://github.com/rcaloras/bash-preexec/issues/52
     https://github.com/rcaloras/bash-preexec/pull/54
     https://github.com/rcaloras/bash-preexec/pull/109
 
     o ユーザーが trap DEBUG etc を実行しても破壊されない。
     o DEBUG trap の overhead がない。
     o 他の枠組みが DEBUG trap を設定・削除しても問題が起こらない。
 
 2021-12-11
 
   * bash-completion
 
     2022-02-02
 
     * [DraftPR で修正済み] _services が failglob で問題を起こしている。
 
       _comp_init_set_up_service_completions も駄目。うーん。failglob ではある
       がこれは自分が修正している途中の物ではない新しい物だろうか? →これは既に
       fix-failglob　の中に含まれていた。
 
     * [修正済み] rsync で *-from が云々という failglob が発生している
       →これは最新版では既に修正されている。
 
       結局ロードして欲しい bash-completion が全然ロードされない。何故 → 結局ロー
       カルの場所ではなくて其処で make install されている物が読み出されている様だ
       が、make install しても何故かずっと古いままという状態になっている様だった。
       autoreconf -i をし直して実行したらちゃんと新しい物に置き換えられた。make 自
       体がちゃんと動いていなかったという事になるのだろうか。何れにしてもこれでちゃ
       んと動く様になった。
 
     2022-01-23
 
     683 にも unresolved patch suggestion がある。
     https://github.com/scop/bash-completion/pull/687#discussion_r790203991 : IFS=$'\0' in mount
     https://github.com/scop/bash-completion/pull/687#discussion_r790203132 : mechanism of save/restore shopt
 
     2022-01-11
 
     * bash-completion: curl　の抽出オプションが極端に少ないのは何故か→これは
       curl --help は最低限のオプションしか表示しないから。そして --help all を
       呼び出せば全部表示される。確認すると --help all は指定されているが、quote
       されていない。
 
       類似の問題が過去にあったがその時に一緒に直されなかったのかと思ったが、こ
       れが正にその時の問題であって、test などが用意されていなかった為に未だマー
       ジされていないのだった。
 
       https://github.com/scop/bash-completion/pull/560
 
     2021-12-22
 
     * fixed: man の中で _expand を呼び出しているが意味ないのでは? info も同様。
 
     * man の _expand の直後にある eval は危ない気がする。
       →これは別項目で議論する。
 
       info にも同様の問題が存在する。
 
     * grc '&& [^[:space:]]+ \|\|'
       →何故 SC2015 で検出されないのだろうか? 変数代入の場合には許されるのだろうか。
 
     * command ls $... となっている部分が幾つかある。 -- を付加するべき。
       他にも色々とあるのではないかと思われる。
 
     2021-12-11
 
     * curl --http0, --http1, --proxy1 等存在しないオプションが生成されている
     * printf -v varname
     * test, [ の引数の文法に従った補完
 
 2021-12-08
 
   * space
 
     https://space.sh/
     https://github.com/space-sh/space (7k LoC)
     https://github.com/space-sh/space/blob/master/completion/init_autocompletion.sh
 
   * bashible というフレームワークでは関数名は ble_ で始まる様だ。
 
   * bash-dev: "help test" の -n の引数に STRING が二回登場している。
 
     →と思ったが、これは分かった。 [[ -n STRING ]] と [[ STRING ]] の二種類の指定の仕方を
     両方載せているというだけの話である。
 
 2021-09-22
 
   * bash-it で気になる事
 
     * bash-it disable alias を実行すると何も表示されず何も実行されない。
     * bash-it --help もしくは bash-it で色々表示されるが、明らかに表示されてい
       ないコマンドが存在している。
     * bash-it update に外部から登録できる機能?
     * bash-it に自動でインストールする機能もつける可能性について
 
   * bash-5.2
 
     $ i=0; b=$(< "file${a[i++]}"); echo "$i"
     1
 
     $ f=; b=$(< "${f:=file}"); echo "$f"
     file
 
     $ i=0; b=$(< "file$((i=123))"); echo "$i"
     123
 
     $ RANDOM=0; echo "$RANDOM"
     20814
     $ RANDOM=0; b=$(< "$RANDOM"); echo "$RANDOM"
     24386
 
     うーん。これに関しては zsh も ksh も副作用を残す形に実装している様だ。つま
     り、$(< ...) は特別な構文として同じシェルで評価するものとしているという事。
 
 2021-09-07
 
   * segv: bash-dev -c "declare -A A; unset 'A[\${v[0]}]'"
 
 2021-09-01
 
   * review: bash-raytracer
     https://github.com/aneeshdurg/bash-raytracer
 
     固定小数点で実装している。Issue 1 で遅いから inline 化して微妙に改善したと
     いう話をしているが、その改善したコードは push されていない。
 
 2021-08-30
 
   * review: bash-timestamping-sqlite
     https://github.com/csdvrx/bash-timestamping-sqlite
 
     - typo: synthax -> syntax
 
     - 行末に改行が抜けている事を示すマーカーを表示している。然しこれは CPR を使っ
       ている気がする。実装を見ると __notbottom という関数で判定していてこの関数
       では CPR を使っている。
 
     何れにしてもこれは他の人が組み込んで使える様な plugin ではなくて、一つの完
     結した設定になっている。コードも綺麗ではない。現段階では単に個人用の設定に
     説明がついているものと見るべきの気がする。これに対して色々と他の人が使える
     様に改善の提案をするのは違う気がする。
 
 2021-08-19
 
   * st: st 2>&- で開始しようとすると何も表示されない。st 2>&- 0>&- で開始しよう
     とした場合にはちゃんと動く。これは以下の様に修正するべき。後で送る。
 
     $ NOBLE=1 ./st.master 0>&- 1>&- 2>&-
     $ ./st.master 0>&- 1>&- 2>&-
 
     | diff --git a/st.c b/st.c
     | index ebdf360..a9338e1 100644
     | --- a/st.c
     | +++ b/st.c
     | @@ -793,14 +793,15 @@ ttynew(const char *line, char *cmd, const char *out, char **args)
     |                 break;
     |         case 0:
     |                 close(iofd);
     | +               close(m);
     |                 setsid(); /* create a new process group */
     |                 dup2(s, 0);
     |                 dup2(s, 1);
     |                 dup2(s, 2);
     |                 if (ioctl(s, TIOCSCTTY, NULL) < 0)
     |                         die("ioctl TIOCSCTTY failed: %s\n", strerror(errno));
     | -               close(s);
     | -               close(m);
     | +               if (s > 2)
     | +                       close(s);
     |  #ifdef __OpenBSD__
     |                 if (pledge("stdio getpw proc exec", NULL) == -1)
     |                         die("pledge\n");
 
     メールを投稿してみたが全然以下のページに反映されない。
     ブロックされているのだろうか。或いは初回は手動承認が必要になるという事か。
     maintainer は数日に一回しか返信しない様なので取り敢えず一週間待ってみようと思う。
 
     https://lists.suckless.org/hackers/2108/index.html
 
 2021-07-20
 
   * bashbug: ${text//$'\n'+( )/$'\n'} が滅茶苦茶遅い
     https://www.reddit.com/r/bash/comments/m4ts7j/why_is_this_spacereplacing_parameter_expansion/
 
     この記事では bash はそういう用途に使う物ではないだの何だのと言って別の手法
     を使えと書いているが、明らかにこれは bash のバグである。修正するべきだし修
     正は難しくない筈である。後で観察する事にする。
 
 2021-06-09
 
   * complete: contra x screen-4.99 で auto-menu を有効にしていると、
 
     $ cd .mwg/src/ble.sh/wiki
     $ l backup/[TAB][C-u]
 
     とした以降にコマンド1文字目を入力した時点で glitch が生じる。
     contra がどういうデータを受信しているのか確認する必要がある。
 
     通常の screen では問題は生じない様だ。また contra の代わりに mintty を使っ
     ても問題は生じない。変な文字幅モードが関係している可能性もある。
 
 2021-05-30
 
   * https://github.com/dnmfarrell/jp
     https://www.reddit.com/r/bash/comments/nmzans/jp_a_real_json_processor_in_bash
 
     何か変な事をしている。プロセス置換で読みだした fd に対して読み書きを実行している。
     一体どういう事だろうか…。
 
     $ exec 3< <(:)
     $ echo hello >&3 # これはエラーになる
     $ echo hello >/dev/fd/3 # これは行ける
     $ read -u 3
     $ echo $REPLY # 読める
     $ yes | head -1000000 > /dev/fd/3 # これはやはりブロックする C-c で中止
     $ mapfile -t arr < /dev/fd/3
     $ echo ${#arr[@]} # 32768要素 ("y" + LF)x32768 = 64kB つまりパイプバッファのサイズ
 
 2021-05-27
 
   * declare -p -A として見たら contra の状態が壊れた。何だろうか。
 
 2021-05-23
 
   * bash: いつの間にかに日本語の文字幅の計算がおかしくなっている
 
     [現象]
 
     | ble/util/c2w 及び ble/util/c2w-edit の計算は正しい。新しい bash セッショ
     | ンを開始した時には何も問題は発生しない。つまり、reload を通して壊れるとい
     | う事だろうか。然しそうだとしても不思議な壊れ方である。
     |
     | 何かが変わってしまっているという事なのだろうと思うが新しい bash セッション
     | で発生しない様なので取り敢えずこれの解決は後回しにする事にする。
     |
     | うーん。textmap が可笑しくなっている気がする。
     |
     | と思ったら ble/util/s2c で日に対して 230 が返って来ている。何故だろうか。
     | 実装を確認すると単に printf %d "'日" を実行しているだけである。実際に
     | builtin printf の出力結果がおかしくなっている事を確認した。うーん。不思議
     | な事である。
 
     builtin printf %d "'あ" が正しい値を返さなくなっている。一文字目の文字コー
     ドを返している。実装を見ると mbtowc を呼び出している。失敗したら一文字目の
     コードを返す実装になっている。これにより ble/util/s2c が誤った文字コードを
     返し、そして文字幅計算が間違って textmap に間違いが入る。というのが表示が乱
     れる原因であった。
 
     [再現条件?]
 
     a 新しい bash で ble-reload をしても特に問題は発生しない。
 
     b 一度でも LANG を C 辺りに変更すると問題が発生する様になる可能性? 特に再現
       はしない。LANG を元に戻せば元通りになる。また、問題の発生しているセッショ
       ンで LANG=C して LANG=ja_JP.UTF-8 にして見ても問題は治らない。
 
     ? 或いは設定が異なるのか。bind -v の結果を比較しても shopt の結果
       を比較しても $SHELLOPTS:$BASHOPTS の結果を比較しても同じである。dotglob,
       nullglob の設定の違いはあったがこれを解除しても振る舞いは変わらなかった。
 
     ? 或いは LANG 辺りを unset した痕跡があるだろうか。コマンド履歴を探したが
       unset でも LC でも LANG でも怪しい物は見つからない。実際に unset するなど
       しても特に問題は発生しない。
 
     ? よく分からないので bash を見に行くと builtins/printf.def で mbtowc を呼び
       出して文字を一文字抽出している。この mbtowc の文字コードの設定ができなく
       なっているのが問題なのだろう。うーん。やはり setlocale の問題の気がする。
 
     ? うーん。不思議である ble-detach しても状況は変わらない。然し何故か
       readline の文字幅判定等はちゃんと正しく動作している様である。printf
       \u3042 等もちゃんと動いている。
 
     ? うーん。実際にこのセッションで実行したコマンドの一覧を作って観察して見た
       が特に問題がある様には思われない。特に locale を破壊する様な事が起こると
       は思えない。怪しい物に setsid があるがこれで全てのシェルが駄目になるとい
       う事があるのだろうか。うーん。特に問題は発生しない。
 
     もう全然分からないので exec bash してみる事にする→exec bash したら治った。
     結局どういう事だったのか分からず終いである。結局不明である。C標準ライブラリ
     か Linux のバグなのだろうか。
 
 2021-05-21
 
   * bash: fix a problem that "set -e; builtin eval false || true" exits the shell
     false || true # OK
     eval false || true # OK
     builtin false || true # OK
     builtine eval false || true # 駄目
 
 2021-05-08
 
   * bash: Cygwin でも mapfile/read で unbuffered read に変更できないだろうか。
 
 2021-05-06
 
   * bash: complete -p の -F はやはり quote するべきなのではないか。
     $var となっている場合、!! となっている場合、{1..10} となっている場合。
 
   * bug-bash localvar_inherit: dynamic variables の性質も継承されるのは意図的か。
     Ref #D1532
 
     例:
 
       shopt -s localvar_inherit
       local BASH_COMMAND='xxxx'
       local LINENO='xxxx'
       local RANDOM='xxxx'
 
     * PS1 を評価する為に BASH_COMMAND を一時的に別の物に置き換えたい。
       localvar_inherit を一時的に off にしたり或いは tempvar を通して
       BASH_COMMAND を変更する等すれば一応 BASH_COMMAND を置き換える事は可能だが
       非自明である。
 
     * localvar_inherit は local variable という形で初期化を行わなかった時の振る
       舞いを制御する物と思っていたが、実際には上記の様にした場合に影響が出てく
       る。つまり、localvar_inherit の下で上を実行すると set/get がコピーされた
       上で代入が行われる様で、動的変数としての性質が継承される。振る舞いが変わっ
       てしまって困る。特に代入した値が消滅してしまう。
 
     * また、マニュアルを見ても attr 及び value が継承されるとは書かれているが
       dynamic variable としての性質が継承されるとまでは書かれていない (?)。
 
       > info bash より (man bash は本質的に同じ)
       >
       >   localvar_inherit
       >
       >         If set, local variables inherit the value and attributes of a
       >         variable of the same name that exists at a previous scope before
       >         any new value is assigned.  The 'nameref' attribute is not
       >         inherited.
       >
       >   declare
       >
       >         The '-I' option causes local variables to inherit the attributes
       >         (except the 'nameref' attribute) and value of any existing variable
       >         with the same NAME at a surrounding scope.  If there is no existing
       >         variable, the local variable is initially unset.
       >
       > declare --help より
       >
       >   -I    if creating a local variable, inherit the attributes and value of a
       >         variable with the same name at a previous scope
 
     * 他の実装はどうだろうかと思って zsh で RANDOM, LINENO を試してみたが、
       RANDOM に関しては local にしても何も振る舞いの変化は見られず、LINENO に関
       してはそもそも代入不可能だった。そもそも zsh は local var; とすると前のス
       コープの値は保持される単に unset になる。
 
     * 実際にこの継承を行っているのは variables.c:2738 の以下の部分である
 
       variables.c L2738
       > if (localvar_inherit || (flags & MKLOC_INHERIT))
       >   {
       >     /* It doesn't make sense to inherit the nameref attribute */
       >     new_var->attributes = old_var->attributes & ~att_nameref;
       >     new_var->dynamic_value = old_var->dynamic_value;
       >     new_var->assign_func = old_var->assign_func;
       >   }
 
     2021-06-09 SECONDS も影響を受けるだろうか。
 
     より現実的な例として以下の様な場合を考える事ができる。
 
     evaluate_prompt() {
       local BASH_COMMAND=$(HISTTIMEFORMAT=x history 1 | sed '1s/^[[:space:]0-9]*x//')
       result=${PS1@P}
     }
 
     Note: 実は上記の BASH_COMMAND 抽出方法は正確ではない。複数コマンドがある場
     合、本来 BASH_COMMAND は一番最後のコマンドだけを含む。また、HISTCONTROL 等
     によって履歴にコマンドが登録されなかった場合にも結果がずれる事になる。例示
     するならば具体的に結果を無理に模倣しようとせずに、何か適当に内容を書く事に
     するのが良い気がする。例えば、
 
     evaluate_prompt() {
       local BASH_COMMAND='echo "Hello, world!"'
       result=${PS1@P}
     }
 
 2021-05-04
 
   * empty associative array subscripts: これは結局返事がないが ToDo リストに入っ
     ているのかもしれない。或いはそうでもないのかもしれない。何れにしても、今少
     しずつ associative array subscripts の取り扱いの変更が行われているので、そ
     れらが済んでから処理されるのではないか。
 
   * return without arguments in trap handlers. これは結局強い理由がないと変更さ
     れない雰囲気になっている。
 
 2020-12-19
 
   * bug-bash: jobs in trap handlers
 
     以下を実行して端末を resize すると (true) の偽ジョブ情報が出力される
 
       trap '(true); jobs' WINCH
 
     SIGWINCH に限らない。以下を実行して C-c を押しても同様の問題が発生する。
 
       trap '(true); jobs' INT
 
     実は直後の bind -x の中で jobs を実行しても同様。
     一度でもユーザーコマンドを実行すれば偽情報は消える。
 
       trap '(true)' INT
       bind -x '"\C-t": jobs'
 
     2022-07-11 以下でも同様の問題が発生した。これは PROMPT_COMMAND 実
     行中に発生する事である。
     https://github.com/petobens/trueline/pull/46#issuecomment-1179853850
 
 2020-04-25
 
   * starship コマンド実行時間の計測
     preexec と precmd を使っている?
     https://github.com/starship/starship/blob/master/src/init/starship.bash
 
     追記 2022-02-17 これは ble.sh でも類似の物を実装した。
 
   * pipexec という物があるそうだ。と思ったが調べたら C で書かれている。
     https://github.com/flonatel/pipexec
 
   * zsh のテーマである powerlevel10k は実は結構複雑な処理を実装している。
     ごちゃごちゃとした雑多の設定の寄せ集めではない。
     ble.sh 程ではないが単にプロンプトと呼べるレベルを超えている。
     * https://github.com/romkatv/powerlevel10k
     * https://github.com/Powerlevel9k/powerlevel9k
       p9k と initial commit が同じなので再実装というよりは fork の気がする。
 
   * https://github.com/aristocratos/bashtop
     これは最近現れた物で pure bash で色々な UI を実装している。
     オプション引数はなく設定は直接編集する様になっている。
     背景が明るい時の配色に対応していない。256色要求。
 
     * 実用性よりも見た目重視。これはツールの性格による。
       ble.sh 自体は他のプログラムを呼び出す為の物なので主張は控え目。
       然し、宣伝の為には見た目を派手にした物も必要なのかもしれない。
     * 何故か現れたばかりなのに 6.3k も集まっているし、
       一体何が起こるとこのように話題になるのだろうか。不思議である。
       HN にも reddit にも大して人気になった物は見られない。
       何処から広まってどう人気になったのか不明である。
     * freebsd, aur, debian, fedora/centos にまでパッケージが在る。
 
 
 @todo
 *******************************************************************************
     ToDo
 -------------------------------------------------------------------------------
 
 * bump 時にする事
   - version up in README
   - Copyright year
   - Acknowledgments
   - todo 項目の整理
   - leakvars
   - version up in GNUmakefile
   - note.txt に含まれるログの移動 -> done.txt
   - keymap の移動 (これは別 commit にする?)
   - make_command.sh の整理 (scan 分離, char_width 分離)
   - note.txt -> memo.txt
 
 2023-09-13
 
   * bash-5.2 "\e[\000"
     Ref #D2069
 
     * bash-5.2 で "\e[\000": "<C0><9B>[" という macro になっているのが気になる。
       本来此処には \000 は存在するべきではない。これは実際に内部的に \000 があ
       るのかそれとも出力する時の問題で \000 となっているのか。然し、これは既に
       bash-dev では修正されているし、またそれにもかかわらず bash-dev でも今回の
       問題が起こっているので、これは今回の問題には関係ない。
 
       これは以前にも気付いていた事の気がする。探してみたら 2021-11-05 に項目が
       あってしかも放置されている。何れにしても 5.3 では修正されている。実際の振
       る舞いに影響があるのかどうかは不明である。
 
       うーん。これは bash-5.2 のソースコードを使って何が起こっているか確認する
       べきなのかもしれない。或いは bisect を実行する。bind に使っているスクリプ
       トはどこかに出力する事ができる筈である。或いはキャッシュになっている →
       キャッシュにあった。確認すると builtin bind '"\e[":"\xC0\x9B["' で bind
       しているので実行するコマンド自体が壊れていたとかそういう事ではないはず。
 
     * どうやら単に以下を実行しただけで既に再現する。
 
       $ bash-5.2 --norc
       $ bind '"\e[":"abcd"'
       $ bind -s
 
       そして M-[ を押すと (多少の keymap delay の後に) abcd が入力される。つま
       り、実際に \e[\000 が束縛されているというよりは表示の際に変な表示になって
       しまっているという事の気がする。
 
       これが実際に何らかの問題を具体的に引き起こす事はあるだろうか。そもそも通
       常は \e[ は単独では bind しない。なので、例えば ble-detach の時に復元する
       対象にはなっていないと考えられる。
 
 2023-09-03
 
   * complete: copilot
     https://github.com/akinomyoga/ble.sh/issues/358
 
     * copilot completion bash
       https://aws.github.io/copilot-cli/ja/docs/commands/completion/これは公式
       の copilot for shell の様な気がする。一番初めにチェックするべきはこれの気
       がする。copilot バイナリは何処で手に入るのかと思ったが standalone binary
       がある。
       https://github.com/aws/copilot-cli/releases/latest/download/copilot-linux
 
     * これは GPT に質問をしてコマンドを生成させるという事をしている。
       https://github.com/tom-doerr/zsh_codex/tree/main
 
       現在の文脈情報について含めることができるのだろうか。例えば、現在のディレ
       クトリの内容は云々だとか、README の内容は云々だとか。README の内容を普通
       に書き込むとその中に書かれていることも直接 GPT に対する司令だと勘違いして
       しまう可能性もあるのではないか。具体的にどのようにしたら良いのかの例はあ
       るのだろうか。
 
     * github-copilot-cli (fish)
       https://zenn.dev/tunefs/articles/b284d532ed5460
       これは github-copilot-cli というのを呼び出しているみたいがだが、
       github-copilot-cli は入力中のプロンプトの編集を手伝ってくれるのではなくて、
       呼び出すと独自のインターフェイスに入ってコマンドを実行してくれるだけである。
       https://www.npmjs.com/package/@githubnext/github-copilot-cli
 
 2023-09-02
 
   * tmux の外側の端末が取得できていない
     https://github.com/akinomyoga/ble.sh/issues/359
 
     自分の手元でも問題は再現する。何処かの時点で tmux の振る舞いが変わったとい
     う事なのだろうか。padparadscha の tmux 2.9a ではちゃんと動いている。
     chatoyancy の tmux 3.3a では動いていない。これは tmux version の問題だろう
     か。調べると 3.1, 3.2 では動いている。3.3 の CHANGES を見ていたら
     passthrough sequence を既定で off にしたと書かれている。以下の commit
 
     https://github.com/tmux/tmux/commit/eabbc80b75ef8e02653c2728d7f646fc6a8f558f
 
     なので set -g allow-passthrough on にしてもらわないと外側の端末を検出する事
     ができないのである。とは言いつつもし DECSCUSR をちゃんと tmux が外側に伝播
     するのであれば問題は起きないはず。と思ったが、どうもDECSCUSR に関しては 3.1
     でもちゃんと動いていない気がする。微妙に外側にカーソル形状変更が伝わってい
     るが一旦ブロックになると元に戻らない。この振る舞いは遡っても変わらない (2.6
     20170830 まで試した)。screen の中では動いている。更に 3.3 になると次のコマ
     ンドラインに行ってもカーソル形状は復元されなくなっている。
 
 2023-08-17
 
   * ext: Android OS コンパイル環境での問題
     https://github.com/akinomyoga/ble.sh/issues/353
 
     Android OS をコンパイルする時に応答がなくなると言っている。これは Android
     OS のバグなのではないか。調べてみると Android OS をコンパイルするのには4コ
     ア使って数時間かかるとか言っている。仮想マシンの中で実行しようと思うとます
     ます時間がかかるのではないか。しかも 18.04 LTS とかいう古い Ubuntu の OS で
     やっている。
 
     応答がない。
 
 2023-07-31
 
   * bash <= 4.4 & contra & mercury で矢印キーが動かない
 
     bash-4.4 で矢印キーが動かなくなっている。bash-3.2..4.4 の全てで動かなくなっ
     ている。
 
     % contra では起こるが xterm では起こらない。mintty でも起こらない。contra
     % 特有の可能性もある。bash-5.0 以上では動いているので contra が悪いという事
     % ではない気がする。 ESC O A 等の形式でキーを送信する端末において発生してい
     % る。これは bind の問題の様な気がする。
     %
     % と思ったら再現しなくなった。どうも、一旦 mercury にログインした事のある
     % contra の仮想端末でなければ再現しないという事だろうか。再現しない時には
     % ESC [ A が送信されているが問題が再現する時は ESC O A が送信されている。うー
     % ん。ESC O をその場で処理するかどうかが関係している気がする。然し試してみ
     % たところ mercury にログインしても front1 にログインしても再現しない。再現
     % 条件が分からない。こうなると xterm や mintty で起こらなかったのも偶々の可
     % 能性がある。
     %
     % chat 経由で mercury に入っても再現しない。screen の中から mercury に入っ
     % ても再現しない。chat の中の screen の中の mercury でも再現しない。
 
     分かっている事: 端末が矢印キーに対して ESC O A を送信する状態になると
     bash-4.4 以下で問題が発生する。然し、どのようにしたら端末が ESC O A を送信
     する状態になるのかの再現方法は不明。
 
     2023-08-02 再現方法が分かった。screen に入った状態で接続が切れたりして抜け
     ると中途半端な状態になって ESC [ A の代わりに ESC O A が送信される状態にな
     る。更に、この状態では bash-5.0 以降であっても矢印キーの振る舞いが変である。
     複数行コマンドラインに於いて上下キーで行の間を移動したいが、ESC O A になっ
     ている時には履歴項目の間の移動になっている。何故この様な違いが出るのかはよ
     く分からない。kpup などに翻訳されているという事だろうか。また再現した時に
     keylog でどのような受信・翻訳になっているかを確認する事にする。
 
 2023-07-18
 
   * Grisha が bind -X の出力形式を修正している
     https://lists.gnu.org/archive/html/bug-bash/2023-07/msg00076.html
 
     現在の ble.sh は間違っている事を前提として問答無用で前後の "" を削除してい
     たはず。これの削除をなかった事にする。取り敢えず Grisha は "" で囲まない様
     に変更している気がする。なので、ble.sh はこのままで大丈夫の筈だが後で振る舞
     いをチェックする。
 
 2023-06-21
 
   * menu for history entries (requested by auwsom)
     https://github.com/akinomyoga/ble.sh/issues/258#issuecomment-1599945461
 
 2023-06-12
 
   * stty: bash-5.2 以上 exit 後の stty 状態を正しく復元する手法?
     #D2046
 
     呼び出し元の端末が ble.sh であれば呼び出し元で改めて stty を呼び出すから問
     題ないが、そうでなければ壊れた stty 状態のままになって問題になる。呼び出し
     元が ble.sh であっても、連続で複数の対話コマンドを実行した場合には後続の対
     話コマンドの動作に影響を与える。
 
     これは bash-5.2 以降で EXIT trap が終了直前ではなく exit を呼び出した
     context で呼び出されるようになったのが原因である。bash-5.2 でもちゃんと終了
     時に stty を正しく設定する方法を考える必要がある。
 
     a 単に stty を遅延して呼び出すようにするのだと race condition で stty が間
       に合わなかったり、逆に次のコマンドが stty を調整した後にそれを上書きして
       しまったりする事になる。
 
     b DEBUG trap でトップレベルまで抜けてから exit を実行する? 然し、依然として
       bind の中で exit が実行される事には他ならないので問題はそのままである。
 
       a 例えば #D2046 の a で考えた様に一旦キー入力を介する必要がある。例えば
         DSR を送信して返事が来たら終了するという手がある。DSR に対応しているか
         どうかについては端末自動判定の結果があるかどうかで判定する事ができる。
         応答がない場合の可能性も考えると何か一つキーが来たらその内容に関わらず
         終了する。但し、CSI を途中で切ってしまうと中途半端な内容が stdin に残っ
         て問題になるので byte または char ではなく key に対して hook をかける必
         要がある。
 
       b 或いは stdin を潰してしまえばその場で終了するのではないか? と思ったがそ
         の場合に正しく端末の状態が復元されるのかは非自明である。更に exit に指
         定した exit status を反映させる方法が存在しない。
 
 2023-05-19
 
   * osh のテスト上で bash が失敗している。何故だろう。
     http://travis-ci.oilshell.org/github-jobs/
     http://travis-ci.oilshell.org/github-jobs/4035/app-tests.wwz/_tmp/soil/logs/ble-test-bash.txt
 
     * 先ず mawk が正規表現を正しく処理できていない。然し手元の mawk では特に問
       題がある様には見えない。arch 等でも問題が見られた記憶はない。最新の mawk
       で試してみる価値はある。
 
       > mawk: line 37: regular expression compile failed (missing operand)
       > ^('[^']*'|\$'([^\\']|\\.)*'|\$?"([^\\"]|\\.)*"|\\.|[^[:space:]"'`;&|()])*
 
       確認してみたが少なくとも Fedora に載っている mawk は Debian の最新の mawk
       と同じである。という事は最新の mawk で問題があるという訳では無い様に思わ
       れる。では逆に古い mawk で問題があるという可能性?
 
       と思ったが mawk のページには最近幾つかの新しい version が公開されている。
       これらを試す価値はある。改めて最新の物を試してみたが問題は再現しない。
       2010 の物を試してみたが再現しない。念の為、最も古い物を試してみる。と思っ
       たら再現した。2008 の物である。これは mawk のバグだと思って良いだろう。
 
     もしかしたらテストの失敗もこの mawk によって引き起こされているのかもしれな
     い。mawk を上書きした状態でテストを実行したらどうなるかについて確認する。うー
     ん。実際にやってみるとテストに新しく2箇所失敗する。然しながら oilshell ci
     上で見られたエラーは確認されていない。これはまた別の古い awk 実装によって問
     題が発生している可能性があるだろうか。更に試してみるとこの2個のエラーは正規
     表現のエラーとは関係ない様だ。
 
 
     ? mawk の version check をする? テスト上で問題が発生しないのは 20090705 以
       降である。また初期化時の正規表現のエラーが発生しないのは 20090710 以降で
       ある。
 
       ところが mawk が現在のバージョン表記に切り替えたのは mawk 1.3.3 20090721
       以降の様である。それ以前は "mawk 1.3.3 Nov 1996" という文字列固定で表示さ
       れている。バージョン表記に関しては mawk 1.3.4 以降であるか、または mawk
       1.3.3 20?????? 的な形式をしていれば良いという事にする?
 
       然し、このチェックを行う為だけでも初期化コストがかかる。そもそもこの様な
       古い mawk を使っている場合というのは限られているのでそもそも判定しなくて
       も良いのではないか。
 
     todo: mawk のテストも test-bash に追加する事にする。
 
 2023-05-13
 
   * complete: sed コマンドの補完
     [1] https://github.com/akinomyoga/ble.sh/issues/326
 
     zsh は sed -r[TAB] に対してちゃんと short flags を提示するし、"sed
     -re[TAB]" に対して sed expression の説明を提示する。これらをbash-completion
     と協力して実装する事はできない物だろうか。と思っていたら [1] でも要求された。
 
 2023-04-13
 
   * bash は実は補完で pathname expansions の結果を候補として出す
     https://github.com/scop/bash-completion/issues/444
 
 2023-04-10
 
   * gnuplot 実装を真面目に考える?
 
   * complete: here documents の補完
 
     よく考えてみたらそんなに実装は簡単ではないかもしれない。素朴に考えると
     completion-context にて here documents の中にいる時には here documents 全体
     を補完対象としてい補完 source を生成すれば良い気がする。然しそれだと here
     documents 全体が補完の置換対象となって着色が巨大になって自然ではない。
 
     実はこれは長い文法的単語の中に含まれるファイル名などの補完の場合にも問題に
     なる。実際にどの位置から補完を開始するのかが動的に変化する場合についても考
     慮に入れるべきの気がする。そしてそれは source 毎に設定できる様にする?
 
     a 然しそうすると補完開始位置が混在する事になる。或いは表示している時の着色
       だけが問題という事であれば単に着色開始位置を各候補に記録させれば良いだけ
       の気もする。
 
     b 或いは source 毎に補完開始位置は固定にして異なる補完開始位置の source が
       ある場合には、より前の位置から補完を開始した物を削除する?
 
       これを実装する為には動的に COMP1 を変更する仕組みが必要になる気がする。果
       たして source の生成途中で COMP1 を変更しても問題が起こらない様になってい
       たのだったか。現在の実装だと source の呼び出しの時点で COMP1 が決定されて
       いると考えて良い。なので、source の中で未だ候補を生成していない限りは
       COMP1 は他に影響を与えていないので問題はないのではないかという気がする。
 
       一方で既に述べた様に異なる source が異なる COMP1 を設定した時にどうするの
       かという問題が生じる。
 
       a これだと source 毎に補完を生成してから merge するという操作が必要になっ
         てしまうのではないか。
 
         然しその方が却って良いのかもしれないとも思う。現在の実装だと毎回一々
         old_cand_count 等を記録したり部分的にfilter をかけたりと非自明な操作が
         入っているので。然し、この様にしたとしても内部的に入れ子で source を呼
         び出している実装の場合には結局毎回チェックは行う必要がある事に違いはな
         い
 
         集計を行うとしたら source に登録してもらう配列名 (cand_*) と、それらを
         集めた結果の配列名 (merge_cand_*) を変える必要が出てくる。既存の実装の
         全ての cand_* に対する参照を書き換えるのは大変なのではないか→取り敢え
         ず数えると 104 個ある。其処まで多くはない。或いは、変数名はこれまでの儘
         にしておいて、source を呼び出している関数で合成を行う?
 
         また COMP1 についても各 source に対して用意して最後に統一するという手が
         ある。
 
         うーん。調べた所、cand_* に作用する関数は色々ある。source の内部でも
         source の外側でも呼び出す可能性がある物を考えたらやはり変数名は変更せず
         に generate-with-filter の側で切り替えを行う方が良いだろうか?
 
         * 先ず使用実態を調査しなければならない。
 
       b 或いは、以前の source が生成した物よりも後に開始位置をずらしたい場合に
         は既に生成した補完候補は削除する事にして、また、一旦開始位置が後ろにず
         らされたら後続のの補完 source はそもそも呼び出さないという仕組みにする?
 
         x この方法だと補完候補生成が source の順番に依存する様になってしまう。
 
       c 或いは、各 source の先頭で現在のずらされた状況を調べてもしずらされてい
         たら補完候補を生成しない、もしくは補完候補を生成しないなどの対策を行う。
         然し、この実装はそれぞれの source で細かい事を考える必要があるので余り
         望ましくない。
 
 
     c 或いは completion-context の決定の時点でコマンド毎に補完の開始位置をカス
       タム計算できる様にする? しかしこの方法だと、最初に「単語全体の補完を試み
       てその後で部分単語について補完を試みる」という段階的な補完を実行すること
       ができない。
 
 2023-04-09
 
   * contrib: (source snake.sh) して C-c C-c で停止させようとすると read が壊れる
 
     read にて -u が変数名ではないというエラーメッセージが出て止まらくなる。
     と思ったら再現しなくなった。よく分からない。
 
 2023-04-02
 
   * set -o posix で起動すると keymap が見つからないというエラーが発生する
 
   * history (bash 3.0): 履歴が重複して記録される
 
     bash-3.1 以降では問題ない様だ。つまり bash-3.0 だけで起きている問題である。
     これの優先度は低い。或いはもしかすると既知の問題である可能性?
 
   * prompt: 右プロンプトの範囲に合わせて textarea の横幅を途中で切り替える?
     https://github.com/akinomyoga/ble.sh/discussions/310
 
     これはこれまでにも考えた事があるはずだと思ったが todo 項目が見つからない。
     もしかすると頭の中で思っていただけかもしれない。
 
     * scroll 機能との兼ね合い → rps1 も一緒に scroll する事にすれば良い。
 
       少し考えてみたがどうも scroll 機能と conflict する気がする。scroll する毎
       に各行の折返を実行し直すというのは well-defined なのか。というかそもそも
       他のアプリケーションでもその様な変な形の枠の中で scroll しながら枠に合わ
       せて折返を実行し直すという実装は見た事がない。
 
       或いは、scroll する場合にはそれに応じて rps も一緒に scroll するという可
       能性? その様にすれば変な事は気にしなくて良い。rps1 を途中で切断しなければ
       ならないかもしれないがそれに関しては clip すれば良い気がする。
 
       然し長いコマンドラインを実行した後に rps1 が表示されない状態で次のプロン
       プトに行くという事にならないか。或いは長いコマンドラインの時には全体を一
       旦出力して次に進むという事にすれば良いのだろうか。新しいコマンドラインに
       移動する直前であればターミナルを溢れてしまっても問題ない筈なので。下手に
       削られて記録が消えるよりはそちらの方が自然の気がする。
 
       と思ったがスクロール範囲はプロンプトの最終行から始まる。なので、右プロン
       プトもプロンプトの最終行以降に被っている部分だけスクロールする事になるの
       だろうか。何だか複雑である。然し、そもそも右プロンプトもプロンプトの高さ
       で範囲を制限していて非自明な事をしているのでその程度の事は寧ろ自然の気も
       する。
 
 2023-03-27
 
   * menu-complete: 長い候補を表示した後の再配置
     Ref #D2025
 
     これは WINCH 後の振る舞いにも関係している。WINCH があったら menu を閉じるか
     或いは再配置を行う必要がある。現在は開きっぱなしになっている気がする。或い
     は…何か変な状態になっている。info panel の高さはクリアされているけれども描
     画されていない状態? の気がする。
 
     本当は info に関係する winch の callback も欲しいという事。或いは panel
     height 決定で要求したのと異なる高さになった時に呼び出す hook? というか単に
     panel height change に対する hook で良い気がする。そして既にその仕組は
     onHeightChange で実装されている。現状では info#panel::onHeightChange は実装
     されていない。此処で info#panel::onHeightChange に際して現在の選択項目が範
     囲外になっていたら再描画を発生させる hook を登録できる様にする。現在表示し
     ている内容が menu なのかどうかの情報を何処に記録するのかはよく分からない。
 
     どうも winch を実行すると瞬間的に高さが縮む様である。その後で続きを処理しよ
     うとすると高さがまた元の高さに戻る。うーん。と思ったがそうでも無いような気
     がする。前回と同じ高さであっても onHeightChange が呼び出されている。何故だ
     ろうか。内容がクリアされてなくなってしまった場合にも呼び出されるという事と
     思って良いか。
 
     →うーん。どうやら潰れて見えなくなった時には onHeightChange は呼び出されな
     い様だ。その後で最初に有限の高さに戻った時に onHeightChange が呼び出される。
 
     然し height change を受け取ったとしてもその場で再描画する訳には行かない。既
     に描画の途中でその処理の途中に height change が起こっているかもしれないから
     である。
 
     a うーん。onHeightChange に於いて invalidate を設定する? でもこれだと現状で
       潰れた時に onHeightChange を呼び出していないので、潰れた事を検知できない。
 
     b もしくは info#panell::render に於いて高さを毎回チェックすれば良いのかもし
       れない。と思ったが、これも潰れた時に一度も呼び出されないので潰れてまた拡
       大した時に検知できないのではないか。
 
     取り敢えず menu-complete 中に長い行が選択されて info が縮まった後にもちゃん
     と onHeightChange は呼び出される様だ。但し、onHeightChange が呼び出された後
     に果たして render が呼び出されるのかは保証できない。上の枠組みで高さが変化
     したら render を改めて呼び出すという事を処理する様にしてしまうと今度は無限
     ループになるのではないかという懸念が生じる。
 
     現状の canvas panel の枠組みにおける問題点は以下の二つである。
 
     * onHeightChange が潰れた時に呼び出されない。潰れた時にも呼び出す様に変更し
       たいが、既存の onHeightChange の処理がどうなっているか気になる。
 
       更に潰れたという事が command-layout 等の都合で一時的に潰れる (後で全体を
       再描画する予定) という事なのか、それとも他の panel が大きくて潰れざるを得
       なかった (後で再描画はしない。より小さい領域に fit する様に処理する必要が
       ある可能性はある) という事なのかで振る舞いが違っても良い。
 
       一時的に潰れているだけなのであれば現状の様に onHeightChange は呼び出さず
       に別の種類の処理を呼び出すべきの気がする。
 
     * 一つの描画処理の中で既に描画し終わった panel の size change が発生した時
       に、その panel を改めて再描画する様に処理するか?
 
       然しそもそも描画処理の途中に高さが変わるという事があるのかというのは疑問
       である。調べてみるとどの panel も途中で reallocate-height.draw を呼び出し
       ている。そもそもこの段階で処理を再考するべきなのではないか?
 
       最初の処理の段階で希望の高さを提出しておいて reallocate-height を実行した
       後に各 panel の描画を開始する。各 panel は与えられた高さの中で表示する様
       にする。もし足りない場合には fallback するか collapse する (減る分には問
       題はない筈)。
 
     * invalidate は panel 側でも管理するべき? 但し、分からない。
 
 2023-03-09
 
   * sabbrev: suffix alias in Zsh (拡張子で実行形式を選択)
     コマンド名補間も一緒に対応する必要がある。
     つまり suffix alias がある時には対応する拡張子を持つファイルも候補に表示する。
 
   * complete: 末尾に不完全な \ がある候補の specialchars フィルタリング?
 
     最後に中途半端な \ がある時には実はフィルターする時にも \ で quote する必要
     性のある文字が続いている物だけにするべきなのではないか。と思ったが処理的に
     複雑になるのではないか? 取り敢えず末端に中途半端な \ があるかどうかは
     comps_flags に B が含まれているかどうかで分かる。
 
     その上でその事実を用いて生成するファイル名を制限するかどうかというのが問題。
     然しその制限を適用する事によって候補がなくなってしまっては変な気もする。
 
     a 全ての候補を生成してから、生成候補を制限しても候補が残るようであれば制限
       をかける事にしようと思ったがそうしたとしても異なる種類の候補が混ざってい
       る時に不用意にフィルタできない。例えば sabbrev 候補は絞り込みの為に cand
       には quote を処理した後の値を入れている。
 
     b と思ったが quote の必要のない候補ばかりの時には生成候補がなくなっても良い
       気がしてきた。
 
     そうは言っても問題になるのが bash-completion によって生成される候補を制限す
     るかしないかという事。実際に生成している側でないとその意図は分からない。
 
 2023-03-08
 
   * :name: に対して emoji 変換を実装する?
 
     https://www.webfx.com/tools/emoji-cheat-sheet/ に一覧がある。
     然し、emoji リストの難点は思い出すのが大変という事。リストを表示できたら良いのだが。
     例えば sabbrev -m 経由で挿入するというのが良いかもしれない。:: を使う。
 
   * [保留] canvas/panel: 一旦 scroll buffer に行ったものを元に戻す可能性? (motivated by mozirilla213)
 
     https://github.com/akinomyoga/ble.sh/discussions/288#discussioncomment-5226973
     > (And the completion words fill and cut the previous output when scrolling
     > up the terminal which I think is a known limitation which is fine,
 
     panel の set-height で行が消えてなくなる? うーん。然し報告者の使っているら
     しき konsole では特に内容が失われるということはない様である。ちゃんと
     scroll buffer に内容が残っている。
 
     恐らく scroll buffer に行って一旦画面から見えなくなるという事を言っているの
     だろう。或いは、一旦 scroll buffer に行った物を、menu が閉じた後にある程度
     回復するという事。端末によっては何かそういう様な拡張をしていた様な気がする
     のでそれを有効にする可能性はある。
 
 2023-03-02
 
   * menu-complete: C-TAB を連続で押すと仮挿入をそのままに新しい補完が始まる
 
     menu-complete の外側の keymap で menu-complete が設定されている時には単に
     menu_complete/forward にしたりなどした方が良いのではないか。
 
     と思ったが menu_complete に対して引数が指定されている時などにどのように対処
     するべきかわからない。例えば insert_all や insert_brances や context=* が指
     定されている場合には単に移動するのではなくて今の補完を明示的にキャンセルし
     て新しく補完し直すべきなのではないか。然し、単なる complete や
     menu-completion や menu-complete backward 等の時には改めて開始するのではな
     くて内部での補完候補の移動を行いたい気もする。
 
     然しチェックするにしても全ての文字をチェックしていると大変である。と思った
     が、UTF-8 decode や key decode 等の処理の重さなどを考えたら大した事ないとい
     えば大したことない。
 
   * menu-complete: suffix もメニュー選択時に表示する機能?
     https://github.com/akinomyoga/ble.sh/discussions/297#discussioncomment-5159146
 
     然しこれは最後の確定時にならないと計算されない。メニューを選択した時にそれ
     も計算する? 然しそうするとしてもrequote だとか前方の文字列の吸収だとかその
     他の処理についてはどうするのか。
 
     特に前方の文字列の吸収に関しては実際に実行してしまうと元々の内容が消滅して
     しまうので駄目である。或いは前方の文字列に一致する物がある場合には単に挿入
     部分の方を短くすれば良いのかもしれないが、それはそれで着色範囲が変になって
     しまって見にくい。更に前方に完全に一致する場合には挿入文字列の幅が 0 になっ
     てしまって見えなくなる。また確定した時に何処にカーソルが移動するのかという
     のも分かりにくい。
 
   * wiki: Design Widget の翻訳?
     https://github.com/akinomyoga/ble.sh/discussions/272#discussioncomment-5013253
     https://github.com/akinomyoga/ble.sh/discussions/294
     https://github.com/akinomyoga/ble.sh/discussions/301
 
     何やら色々変な事を試そうとしている人がいるみたいなので。
 
 2023-03-01
 
   * [保留] decode: M-S-o と M-O のどちらか一方に強制的に揃える?
 
     現状では二つの形式に同じ binding を与える様に設定しているがわざわざ両方設定
     するのは大変である。一方で、CapsLock 等を考慮に入れると両者は実は互換ではな
     い。更に端末によって CapsLock がある時の振る舞いや、S を付加している時に
     Shift 前の文字を底字にするのか Shift 後の文字を底字にするのか振る舞いが異な
     る。なので正確に判定するのは難しい。
 
   * [保留] ble/builtin/readonly などの上書きを function#push で行う?
 
     ユーザーが独自に定義していた時などにそれを保持する為。また、ユーザーコマン
     ドを実行した直後にユーザーが上書きしていたら改めて push を行う。その時には
     既に push chain の中に登録済みであればそれを削除する等の仕組みが欲しい気が
     する (opts 引数で指定)。
 
     これはわざわざ表示しなくて良い気がする。
 
 2023-02-27
 
   * [保留] complete: compopt -o filenames が指定された時に末尾の空白を除去する?
     bash の振る舞いを確認する。
 
 2023-02-20
 
   * autoenv 実装
 
     既存の物と同じ設定ファイルを使い回す事を検討するべきだろうか。zsh-autoenv
     は .autoenv.zsh を使っている。これに倣うのであれば .autoenv.blesh という物
     を用意するのが便利である。
 
     * authorized 的なファイルの形式はどうするか。何処に記録するか。sha256sum を
       呼び出せば良い。然し、sha256sum が存在しなかった時にどうするのかや、前に
       無かったのに新しくインストールされた場合にどうするのか等が非自明である。
       取り敢えず cksum は存在すると思っておくべき? あと、前にはあったけれどもな
       くなってしまったという場合にもどうするのか困る。うーん。ファイルには hash
       の形式も一緒に記録する事にするのが良い気がする。
 
     * bleopt push/pop の機能を実装するべき。bleopt --push ... 等とする? 或いは
       全ての設定を一斉に push するという手もあるだろうか。或いは、bleopt 自体に
       hook して .autoenv を実行中の変更を全て track する。これが楽の気がする。
 
     * function については ble/function#push/pop を使ってもらう。alias は ble.sh
       側で追跡する。adjust の中で定義して大丈夫なのか? 抜ける時には特に今まであっ
       たものを敢えて削除する事はしないので一応使える? 然し、以前の alias が退避
       されていた場合にそれが restore される時に上書きされて昔の物に戻ってしまう
       という事が起こるのでは。という事を考えると alias に関しては adjust を一旦
       restore しておく必要があるのではないか。他にも FUNCNAME 等が気になる。
 
 2023-02-12
 
   * syntax: 5.0 以降では関数名として function `xxx` 等も実は許されている。5.3
     以降では更に <(...) も関数名として使える。しかもこれらは `xxx`() や
     <(...)() の形式でも定義できる。
 
     現在の実装では関数名を function NAME まで一回の解析で進むようにしている。何
     故だったか。何か理由があった気がするが、この取扱になっている限りはちゃんと
     対応するのは難しい。過去の記録を調べる必要がある。
 
   * complete: shopt -s extglob failglob で @(aa)() { echo; } という関数を作成し
     て置くと screen -dr の補完の途中でエラーメッセージが表示される。何処から表
     示されているのだろうか? 関数名を拾って更にその上でそれをパス名展開に晒して
     いる箇所があるのだろうか? simple-word ではないので ble.sh の内部ではないの
     ではないか…という気がするが分からない。
 
 2023-02-06
 
   * auto-complete: cd 等簡単に成否が分かる物については判定して除外する可能性
 
     然し cd を上書きしている場合等にはやはり問題になる。またコマンド毎に対応す
     るのは大変なのでこれも progcomp, chroma の様に判定するシェル関数を用意する
     可能性。ただ、問題なのは、単純コマンドでない時にコマンドの位置などの判定を
     行う必要があるという事。そしてその為には構文解析を各項目に対して回す必要が
     ある。という事を考えると重くて現実的でない気がする。
 
 2023-02-03
 
   * contrib: ble-import で contrib/ は不要なのではないか?
 
 2023-01-26
 
   * histdb: history の中から情報を取り出してそれを使って何かする機能
 
     これができなければそもそも実装する意味がない。例えば auto-complete で単語を
     表示する等。
 
     * done: wiki: BLE_SESSION_ID, BLE_COMMAND_ID
 
     * 履歴を操作・編集(削除)する機能も欲しい。
 
       histdb [list]                 コマンド一覧
       histdb list-session [options] セッション一覧
       histdb delete [OPTIONS]       コマンド削除
       histdb -s [.|session]         セッション指定
       histdb -d [.|dir]             ディレクトリ指定
       histdb -t [.|dir]             ディレクトリ指定(サブディレクトリも含める)
       histdb -g glob                コマンドをパターンで絞り込み
       histdb -c command_id          コマンドIDによる指定
 
 2023-01-25
 
   * complete: 英単語の曖昧補間やスペルミスの検出など
 
     この場合には一意確定だとしても挿入はしない方が良い。コマンド引数
     (source:argument) についてその他の候補生成が全て生成に失敗した時にこれを実
     行するのが良い気がする。そしてその場合には勝手に挿入しない事を表す flag か
     何かを設定する事にすれば良い。
 
     英単語辞書は bash で処理すると遅いので awk か或いは外部コマンドを呼び出すべ
     き。或いはこれまでに実行したコマンドから拾ってくる? これまでに実行したコマ
     ンドに関しては変な切り取り方をしても仕方がないので、
 
     a 予めコマンド実行時の文法解析結果を元に単語を抽出してファイルに記録してお
       く。これは comps との一致対象。記録は state ディレクトリの中にファイルを
       作成すれば良い。~/.local/state/blesh/history.xword.txt 等。
 
     b 同様に単語がファイル名に一致する場合にはそのファイル名を記録する
       (history.filename)。現在ディレクトリとの組にして記録するとより良いかもし
       れない。これは compv に対して一致を試みる。
 
       x 現在ディレクトリとの組にするのだとしたら結局現在ディレクトリで普通にファ
         イル名補完をするので十分なのではないか。逆にディレクトリに関係なくファ
         イル名を記録するとしても何か用途はあるだろうか。結局単語補完と実質同じ
         なのではないか。
 
     c 更に、simple-word の時には展開結果を記録する (history.vword.txt)?
 
       x 展開結果が長大になる可能性がある。
 
     d 更に c をスペース等で分割して単語を記録する (history.eword.txt)?  然しこ
       れも変な物を記録しても仕方がないので bash special chars に関しては含めな
       い様にする。もしくはそれらも分割子として取り扱う。これも compv に対して一
       致を試みる (特にスペース等で分割した後の直近の文字列に対して判定する)。
 
     history に関しては ToDo 2021-05-17 に関連項目がある。
 
 2022-12-09
 
   * edit,complete: alias expansion で alias sudo='sudo ' 等による引数の展開に対応?
 
 2022-12-03
 
   * declare -f の出力は特殊関数名には使えないのではないか?
     https://lists.gnu.org/archive/html/bug-bash/2022-12/msg00010.html
     https://lists.gnu.org/archive/html/bug-bash/2022-12/msg00011.html
 
     取り敢えず、これは evaldef の時点で function を prefix すれば良い気がする。
     今後の Bash の振る舞いの変更で function が追加されるかもしれないので、その
     時にはそれを避ける様にする。
 
     更に変数代入の形の関数名は declare -f &>/dev/null でテストする事もできない。
 
   * colorglass: face から読み取る時に作用する色設定?
 
     現在は全ての出力に対して色を変更しているが、プロンプトのテーマを別に指定し
     ている場合などを考えると、プロンプトの色には作用して欲しくない気がする。一
     方で元々の colorglass のアイディアでは全ての色に対して作用する事を考えてい
     た。両方の種類のオプションを提供するという手が考えられる。例えば、現在のオ
     プションはそのままにして、colorglass_face_* という物も提供する。
 
     インターフェイスは別として実装は考える必要がある。
 
     a 現在は face は全くキャッシュしていないので、face 読み取り部分に filter を
       挟むとなると遅くなる。或いはキャッシュするか。キャッシュするとしても将来
       的に face 間に依存性を持たせる実装を考えると個別にキャッシュできない。
 
     b 或いは、別の colorglass domain の区分けとしてプロンプトを処理する時とそれ
       以外で分けるという事も考えられるだろうか。しかしそれだと vim-airline の設
       定は prompt に含まれるので既定の色を抑える等の調整ができなくなる。
 
 2022-09-15
 
   * vim terminal や neovim terminal における keymap-timeout に対応する設定は何
     か。調べてみると ttimeoutlen や timeoutlen という物がある様だが、これの設定
     を変更しても振る舞いに変化はない気がする。後でちゃんと調べる必要がある。
 
 2022-09-11
 
   * 何らかの拍子に P[0 q の様な謎の文字列がユーザーコマンドの実行後に出力される
     様になる。
 
     これは DECSCUSR に関係しているのは確かだと思われるが、どうやって起こるのか
     分からない。例えば _ble_term_Ss 関係の変数が変な値になっているのが原因かと
     も思われたが別にこれらの変数に問題はない。P[0 q の様な文字列が含まれている
     変数も存在しない様に見える。
 
     * bleopt term_cursor_external=1 を設定してみたらコマンドが始まる前にも変な
       メッセージが出力される様になった。つまりやはり cursor-state の管理の部分
       で起こっている問題なのだろうと思われる。
 
     * 新しい bash を開始すると別に問題は生じない。また、そもそも表示幅も狂って
       いる気がする、と思ったがこれは本来端末に文字列として表示されない物が表示
       されている事によって位置がずれているだけなので、元の問題を解決すればこれ
       も解決する筈。
 
     コードを確認してみたら分かった気がする。quote-passthrough によって付加され
     た P が表示されてしまっているのである。そして、端末の入れ子情報が壊れている。
     実際に問題が生じている端末で C-xC-v で端末情報を出力してみた所、どうやら
     screen が三重に入れ子になっていると勘違いしているようである。
 
     terminal: TERM=screen.xterm-256color wcwidth=14.0-emacs, screen:49900
     (83;49900;0), screen:49900 (83;49900;0), screen:49900 (83;49900;0),
     contra:0 (99;0)
 
     何故後になってこの様な変な状態になるのか分からないが、ble.sh を reload した
     らちゃんと端末の入れ子状態の情報も正しくなって問題も起こらなくなった。
 
 2022-08-31
 
   * complete: 'a b c' というファイルがある状態で 'b [TAB] すると変な事になる。
 
     →今試してみると再現しない。bash-completion をロードしていてもしていなくて
     も問題なく補完される。
 
   * complete: ~/b/c/スペースを含むファイル[TAB] としても requote されない。
 
   * complete: 変数名の曖昧補完が効かない。一旦候補を生成したら menu-filter によ
     る曖昧絞り込みはできている。
 
 2022-08-29
 
   * DEBUG trap についても関数呼び出しの階層を再現する?
 
     user-handler#{load,has} がそれぞれの文脈で "現在の文脈での handler" を取得
     しようとしているのか、或いは "何れかの文脈で handler があるか" を取得しよう
     としているかをちゃんと区別する必要がある (というか関数を二種類作るべき?)
 
     また "現在の文脈" を正しく取得できているかどうかについてもちゃんと確認する。
 
     install-hook については top-level での hook があるかどうかを確認したい。結
     局 trap - DEBUG されない限りは何処かの stackframe で定義されている DEBUG
     trap が top-level に適用されると考えると、何れかの階層の handler があればそ
     れで判定していると思って良い。但し、install-hook については、初期化時に
     user が builtin trap で既に設定しているかどうかを判定する為に用いていて使い
     方が特別である。何れにしても、何処かの階層で既に定義があればユーザーの設定
     した builtin trap は無視するというので良い。[ しかし実はそもそも DEBUG は
     install-hook 内に継承されないので extdebug/functrace が設定されていない限り
     判定できないしその様に条件で弾いている ]
 
 2022-07-10
 
   * syntax: posix syntax check in posix mode?
 
     対応が面倒そう。本当にエラーになる訳では無いので普通のエラー着色とは少し異
     なる着色にする?
 
   * complete: - で始まるファイル名には ./ をつける?
 
     * コマンドによっては + で始まるファイルについても ./ をつける必要がある事も
       ある。そもそも + で始まるファイル名は普通ではないという事を考えると、+ で
       始まるファイル名についても - で始まるファイル名と同様に一律で ./ をつける
       様にしてしまって良い気がする。
 
     * './' を前置するという事は遡って書き換えるという事を意味する。どの様に取り
       扱うべきか。
 
       a うーん。INSERT 時に suffix を付加するのと同じ要領で ./ を挿入するという
         事にする? ./ は shell special characters を含んでいないので quote の状
         態がどうであれ勝手に挿入してしまって良い。
 
       b オプション名及びファイル名の両方の候補がある場合に menu-complete で両方
         選択肢を表示したい時にどうするのか。という事を考えると CAND の時点で ./
         をつけてしまって独立な二つの候補にする必要がある。という事を考えると元
         より CAND の時点で ./ をつけるべきなのかもしれない。
 
         然しこれだと実は filter されてしまうのでは?
 
       c a と b の両方を行うのが良い気がする。曖昧補間 (部分一致) の場合には b
         の方法だと filter されてしまって出て来ないので、最終段階で ./ を挿入す
         る様にすれば良い。一方で、先頭一致の場合にはオプション名候補と区別する
         為に ./ は CAND の時点で付けておく事にする。
 
     * --prefix=filename の様に生成した場合には --prefix の前に ./ を付加してし
         まわない様に、ちゃんと prefix 部分を認識して戦闘の [-+] 判定を行うべき。
 
     ble.sh builtin filename generation で ./ を付けるのは良いとして、progcomp
     で生成された - で始まる単語で同名のファイルが存在する場合にどうするか?
     progcomp で生成された物でファイル名に一致する物があった時に、それがオプショ
     ンを意図した物なのか或いはファイル名を意図したものなのかを区別する手段はな
     い。
 
     a bash-completion の _filedir 等に介入して ./ を付加する? 一方で、これでは
       もっと細かい補間関数で個別に生成している物や、bash-completion ではない設
       定に関しては対応できない。
 
     b 或いは同名のファイルがある場合には問答無用で ./ を付加する事にする?
 
   * complete: 空白で終わる alias の対応?
 
     空白で終わる alias は次の単語の alias 展開も引き起こす。然し一方でコマンド
     さえ確定してしまえば後はそのコマンドの補完によって対応するべきという考え方
     もある。うーん。それでも alias を設定するのはユーザーであり、そのコマンド自
     身ではないと考えるのであれば、やはり ble.sh の側でその辺りを解決して補完を
     呼び出すべきではないだろうか。
 
 2022-07-06
 
   * complete: func() TAB 及び function func TAB で関数定義を挿入する。
 
     bash-completion では function func [TAB] でこれに対応しているので。現在は
     function aaa の時 aaa には単語を設置していないが必要があれば登録しても良い。
 
 2022-07-04
 
   * [保留] debug_xtrace を bash-4.0 以下でも対応する?
 
     debug_xtrace が bash-3.2 で動いていない。と思ったらそもそも BASH_XTRACEFD
     は bash-4.1 以降の機能だったのだ。bash-4.0 以下では 2 を redirect する事に
     よって実現する? と思ったが 2 は ble.sh が出力するのに使っている気がする。特
     に ble/util/buffer.flush で使っている。更に他にも様々なエラーメッセージが 2
     に出力されるのではないか。という事を考えると 2 を xtrace に使うのは余り良い
     ことではない様な気がする。取り敢えず保留という事にする。
 
   * ext: trueline と組み合わせた時に問題が起こるとのこと。
     https://github.com/lecramyajiv/Emptydeeds/commit/b57e8354cc350d71c655d93c32112427ec8addda#diff-0a1c1083789380c5f4b4aaebd19b6a4b2431ae808f8b456cf865825cfb93b9dfR2527
 
 2022-06-19
 
   * 履歴番号を検索やプロンプトで表示しているが、これは history の最初が 1 でな
     い時にはずれるのではないか。後で確認する必要がある気がする。
 
 2022-06-14
 
   * cygwin: bash --norc, source すると C-xC-v 等の keybinding が動かない
     bash_execute_unix_command のエラーが出る。
 
     これは元々存在している inputrc か何かが悪さをしている可能性? 然しそうだとし
     ても普通に attach したら問題は生じない。なのでやはり違うのだろうか。
 
   * eterm: Emacs に実装されている M-x term 若しくは M-x ansi-term
 
     端末実装が色々滅茶苦茶である。infocmp にて対応している事になっている機能で
     も振る舞いが変である。
 
     * 先ず、IL, DL は行の途中で実行するとおかしな事になる。IL はその位置に改行
       を挿入して行を2つに分ける機能を持っている。DL は一方で emacs 内部で C-k
       をするのと同じ機能である。即ちその位置以降の文字列を消去するか、行末にい
       る場合には次の行と結合する。これは一応行頭に移動すれば問題ない気がする。
 
     * RI に関しては端末の一番下にいる時に全体を scroll down し、端末の一番上に
       いる時には何も実行しない。
 
     未だちゃんと動かない。これは後でちゃんと調べる必要がある。
 
 2022-06-02
 
   * bash-4.4 crash (reported by notmike-5)
     https://github.com/akinomyoga/ble.sh/issues/195
 
     source した瞬間に crash するという事だろうか?
 
     一方で別の問題を発見した。bash-completion scp の補完で 4.4 がcrash する。こ
     れは ble.sh なしでも再現する。また、bash-5.0 以降では発生しない。
     bash-4.2..4.4 の全てで再現する。これは後で bash-completion の側で対処が必要。
 
 2022-05-12
 
   * isearch: 現在行と全く同じ内容の行には一致しないというオプション
 
 2022-04-13
 
   * bash が `vi-edit-and-execute-command' を追加している。
 
     これは自分が以下で報告した事が元になっているのだろう。
     https://lists.gnu.org/archive/html/help-bash/2022-02/msg00031.html
 
     d70b5339 で追加されている。つまり help-bash で発言した次の日には修正が入っ
     ていたのだった。
 
 2022-03-19
 
   * 編集文字列に含まれる制御文字の反転表示の可能性
 
     現在は見た目には区別がつかない。プロンプトシーケンス \w, \W, etc に含まれる
     制御文字については反転の toggle で対処している。
 
     一方で、現在の実装だと単純に編集文字列に含まれる制御文字の反転状態を変更す
     る事はできない。着色に関係なく制御文字の表現を決めている、つまり地の反転状
     態に関係ない escape sequence を決める必要があるが、地の反転状態が分からなけ
     れば制御文字が終わった位置で正しく反転状態を復元することができなくなる。
 
     これについてはまた今後必要性を感じた時に実装すれば良い気がする。
 
 2022-03-03
 
   * 起動時の fork について
 
     * ble/base/adjust-builtin-wrappers/.assign (2 fork) ... 此処で builtin,
       alias を保存する為に2回に分けて defs=$(...) を実行している。この時点では
       初期化が終わっていないので ble/util/assign は使えない。
 
       これはそもそも勝手に上書きした builtin や alias を保持する必要があるのか
       という事を考えるとスキップしても良い様な気がする。起動の高速化の為にこう
       いった物を省略するオプションを用意して良い様な気はする。
 
     * ble/util/msleep/.check-builtin-sleep ... これはロードに失敗した時の事を考
       えて subshell 内部で実行している。
 
       これも sleep の方法を予め引数等で指定する仕組みを用意しておけばスキップす
       る事は可能である。また builtin sleep に頼り切るのも問題の気がする。という
       か builtin sleep だと C-c が効かない等の問題がある。
 
       改めて plain Bash に builtin sleep を読み込んで動作を調べてみる。と思った
       が再現しない。というよりそもそも ble.sh をロードしていても bash-5.0 でし
       か再現しない。つまり bash-5.0 & ble.sh の時にだけ bultin sleep 3 で C-c
       に対して即座に実行が中止されない。ble-detach していてもこの問題は発生する。
       plain Bash で直接 enable -f /path/to/sleep sleep して sleep 3 に対して
       C-c した時にはちゃんとすぐに終了する。
 
     * ble/builtin/bind/read-user-settings/.reconstruct ... これは記録されている
       default bash の binding と、現在の binding を比較してユーザーが設定した
       keybinding を抽出する為に awk を呼び出している。
 
       これは既存の readline 設定を読み取らない事にすればスキップはできる。実際、
       ble.sh の読み込み時に --noinputrc を指定すればこれは実行されない。
 
     以上の物は何れもユーザーオプションで省略できる様な機能ではある。然し一方で
     ロードのボトルネックは実は fork ではない。少なくとも Linux では。但し、
     Cygwin では 50ms/fork かかるので 4 fork 省略できるだけで 200ms も時間を短縮
     できるので大きい。
 
 2022-02-20
 
   * より一般の補完 framework に向けたインターフェイスについて
     https://github.com/rsteube/carapace/issues/431
 
   * compopt 実装: 現在の実装では "name" や -DEI が与えられた場合には何もせずに
     戻る様になっているが、本来現在の設定を変更するべきなのではないか。また、丁
     度変更対象の補完が現在の補完と一致している時には現在の補完の振る舞いに影響
     を与えるべきなのではないか。これについては実際の Bash の振る舞いを確認する
     必要がある。
 
   * rsteube の記事
     https://dev.to/rsteube/a-pragmatic-approach-to-shell-completion-4gp0
 
     filtering を description に対しても適用するという事が書かれている。それは確
     かに便利そうである。現状の実装では対応が難しい様には思われるが。これは fzf
     の様に一旦絞り込み専用の入力欄に移動するなどの事がないと使いにくいだろう。
 
   * trap (lastarg): 一応 heredoc 等を使えば eval の中から複数行の lastarg を設
     定する事ができるのではないか。他に複数行で、eval されても余分な実行が起こら
     ない様な方法はあるだろうか。不完全な引用符の場合には結局エラーが出力されて
     しまう。
 
     Ref #D1853
 
   * [保留] exec: builtin sleep に対して C-c が効かない
 
     % 現在の実装だと bash-5.0 以下で C-c でループ中に走っている外部コマンドを止
     % めた時に応答がなくなってしまう。bash-5.1 以上では一旦実行が停止するものの
     % 一応応答はする。
 
     と思ったらこの問題は外部コマンドではなくて builtin sleep を呼び出している時
     特有の問題だった。trap INT を設定しているのは問題なのだろうか。
 
   * edit: 現在の TRAPDEBUG の枠組みを拡張して try/catch/finally を実装できるのでは
     Ref #D1783
 
     もしその枠組がちゃんとできるのであれば edit.sh から util.sh に移動する。
 
 2022-02-14
 
   * 全ての ble.sh session にコマンドを送る機能があれば screen に再 attach した
     時の再調整等に役立つのでは。
 
     _ble_term_TERM の最初期かもできるし、或いは DISPLAY 環境変数の再設定もでき
     る。チェックの頻度は history-share と同様で良い気がする。
 
   * ble/builtin/trap DEBUG は関数の入れ子や trace 属性などは考慮していない。こ
     の事によって問題が起こる可能性もある。
 
 2022-02-12
 
   * highlight: ls -l ~/.c{onfig,a/b}
     ブレース展開の中に / が含まれているとディレクトリパス着色が動かない。
 
     うーん。そもそも highlight の仕組み的に / が含まれているとどうしたら着色で
     きるか謎という可能性がある? と思ったが恐らくそういう事ではない。何れにして
     も全体を一番最初に一致した PATH に対する色で同じ色で着色する様になっている
     筈。但し、その着色を実行する上で / で分割してから各 segment に対して着色す
     る様になっている為に、brace 展開中に / があると / で分断されてしまって正し
     く着色できないという事になるのだろう。
 
     ちゃんと対応する為には、"ブレース展開に対して最初の要素で着色をする" のでは
     なくて、ちゃんと各要素に対して着色をするという方向に改める必要があるのかも
     しれない。然し、それは実際の所面倒だし、そこまでする必要があるのかというの
     も謎である。これは優先度は低いがもし実装できたら面白いだろうという事である。
 
 2022-02-08
 
   * [保留] compat: bind -x 実行後の再描画はプロンプト最後の行以降
     https://lists.gnu.org/archive/html/help-bash/2022-02/msg00023.html
     https://lists.gnu.org/archive/html/help-bash/2022-02/msg00031.html
 
     どうも bash で試して見た所 に於いてはプロンプトの一番最後の行以降だけが再描
     画の対象らしい。現在の ble.sh の実装だと全体を再描画している。これだと
     help-bash に投稿した様な hack が使えなくなる。
 
     a Bash と同様に途中から出力する様に調整すれば良い。と思ったが、よく考えたら
       現在の実装では prompt は一気に出力する事になっているので一番最後の行だけ
       出力するという話はない。
 
     b うーん。その場で clip すれば良いのかもしれない。然しそれは処理として重く
       なる。また、clip した場合には結局描画する時にはカーソルを相対移動させる事
       によってカーソルが本来の位置に戻ってしまう。つまり、hack は結局使えない。
 
     そもそも hack を使える様にするという発想がおかしいのだとも言える。特に件の
     hack に関しては ps1_final で代用できる。それ以外の目的で描画を乱すとしたら
     それはやはり対応外であるし、もしそういった描画に対する介入を想定しないので
     あれば、結局全体を描画するという現在の振る舞いで特に問題は生じない筈である。
 
 2022-02-05
 
   * syntax: a=(%{1..10}) の % を '\x' に書き換える時文法構造が破壊 (?)
 
     $ bash
     $ rep=(%{25,08,0A,2{0..2},24,2{6..9},3B,3C,3E,5C,5E,60,7C})
 
     として起動した直後に上記の文字列を貼り付けて、それから先頭の % を削除して
     '\x' と入力したら文法構造が壊れてしまった。然し二度と再現しない。問題は '\x
     迄入力した時点で発生していた。もしかすると ' か \ を入力した時点で既におか
     しくなっていたのかもしれない。
 
 2022-02-03
 
   * キャッシュの判定でファイルを使って判定しているが、よく考えたら現在ロードさ
     れているコードとファイルに含まれているコードが同じとは限らないのではないか。
     もし、現在のシェルの起動時刻よりも比較に使っているファイルのほうが新しい時
     は、ble.sh 自体を reload した方が良いのではないか。と思ったがそれによって失
     われる設定も考えられる。という事から勝手に reload する訳にも行かない。
 
     起動時刻(というよりble.shロード時刻)を示す一時ファイルを使うという手も考え
     られるが、それだと後になってロードした module の場合には不正確になる。と思っ
     たが、古いコードを使って更新を実行してしまうよりは、新しいコードなのに古い
     情報を更新せずに利用するという位の方が未だましである。
 
     実はロード時刻は $_ble_base_run/$$.load に既に存在しているのでそれを使えば
     良い。
 
     検索してみると結構影響のありそうな箇所は沢山ある。一方で具体的にどの様に直
     すのか。load time だけで判定すると毎回キャッシュを更新する事になってしまっ
     て意味がない。(キャッシュが最新でない) & (load time よりも前に元のファイル
     が更新されている) という条件で判定するのが良い気がする。
 
     * キャッシュが最新でないというのは必須の条件である。そうでなければそもそも
       更新を実行する意味がない。load time が元ファイルより最近の場合にも何も問
       題は生じないので今迄通りに何も気にせずに更新すれば良い。
 
     * 従って、特に判断が難しいのは (キャッシュ),(LoadTime) > (元ファイル) の場
       合である。更に元ファイルを source した時刻は実は元ファイルよりも後の可能
       性もある。その時にはメモリ上には最新版があるのでそれに従ってキャッシュを
       更新しても問題ない。
 
     * よく考えたらここで対策をしても問題は生じるのではないか。元々キャッシュファ
       イルが存在しなくて、メモリ上に古い version の関数があって、それに基づいて
       新しくキャッシュを作成した場合、古い version のキャッシュがずっと残ってし
       まう。
 
       うーん。load time で time stamp を書き換える様にすれば良いのだろうか。
 
 2022-01-23
 
   * "for ((i=0;i<10;i++)); do sleep 1; done" で C-c すると ble.sh 全体がその場で停止する
 
     これは外部コマンドを実行中にそのコマンドが SIGINT で終了した場合、trap INT
     に登録されたハンドラーを介さずに即座に実行全体が終了してしまうのが原因であ
     る。
 
     もしそれがトップレベルのコマンドであれば ERR を用いて捕まえる事はできる。但
     し、それが SIGINT によって引き起こされたものなのか、普通のエラーとして返さ
     れたのかを判定する方法はない。
 
     更に関数内で実行された場合には ERR でも INT でも捉えられない。RETURN を使っ
     ても捕まえられない。これを解決する方法はない気がする。
 
 2022-01-08
 
   * mandb: echo のオプションの抽出 (help echo) がおかしい at fc35 vm
     chatoyancy では問題は発生していない
 
 2021-12-22
 
   * ディレクトリ固有の local commands & aliases を可能にする?
 
     一方で、勝手に設定をロードする様にしてしまうと怪しいディレクトリに入っただ
     けでそれが有効になってしまうという事が発生する。なので、一旦は enable する
     操作を求めるべきだし、また内容が変更されたらその都度承認を求めるべきである
     (過去に承認したものは hash か或いは実体を記録しておいて再度尋ねはしない様に
     できる)。
 
     →direnv が丁度同じ事を目的としたプロジェクトの様である。
 
     2023-01-30 direnv が一体どういう事をしているのかについて調べる → #M0023 に
     纏める事にした。
 
 2021-12-20
 
   * git-prompt, git-status 等の機能の模倣?
 
 2021-12-18
 
   * contrib/git: dirty で rps1 が更新された瞬間にカーソル位置がずれた。これは後
     で調べる必要がある。
 
   * deprecated functions の枠組みを整える。
 
     散発的に deprecate して行くと毎回設定を変更しなければならず面倒なので、
     version を指定して特定の version 以降になった時に限り初回だけ警告を表示する
     様にするのが良い。
 
     ((_ble_version>=500)) && ..... と言った具合。
 
     ? reject: deprecation は version ではなくて独立な番号付を使う可能性?
 
       →omb において考えていたが、これは特定のバージョンを予め指定するよりは
       deprecation level の様な 1 個ずつ増える整数にするのが良い。というのも、そ
       もそもどの version で完全廃止するのかというのは廃止を決定した瞬間には分か
       らないという事。そして、実際に廃止する瞬間には基本的には全て一度に廃止す
       るのであって、機能によって廃止したり廃止しなかったりという事はない。なの
       で基本的には、新しく廃止をマークする時には次の deprecation level を指定し
       ておいて、deprecation level が上がる時に一斉に廃止するのが良いと思われる。
 
       一方で、もしかすると緊急で廃止したいという状況が現れるかもしれないので、
       deprecation level は基本的には 100 の倍数にして置いて、細かい廃止を実行し
       たい時に限って 1 ずつ上げる様にするというのも手である。と思ったがその様に
       考えると結局それは _ble_version と同じになるのではないかという気もする。
       但し、基本的に廃止等は master でしか起こらない気がするので patch level と
       deprecation level に関してはずれが生じるだろう。
 
       また minor version とは無関係に廃止するという事があるのかも分からない。と
       いう事を考えるとやはりその意味に於いても ble.sh に於いては deprecation
       level と version は一致させて良いのではないか。という気がしてきた。
 
   * complete: FIGNORE と -o filenames
 
     どうやら元の bash では -o filenames が指定された時にのみ FIGNORE が使われる
     様である。一方で、現在の ble.sh では FIGNORE が設定されている時には強制的に
     fignore が実行される様になっている気がする。と思ったらこれは shopt -s
     force_fignore の設定を参照しての事だった。よく分からないのは bash は
     force_fignore が設定されていても、-o filenames が指定されていなければ
     FIGNORE が有効にならない様だという事。
 
     * FIGNORE で全て候補が消えた場合には FIGNORE を無効化して全て採択するべきで
       は? と思ったが元の bash ではその様な取り扱いはしていない。
 
     * Note: bash FIGNORE は glob は解釈しない。bash FIGNORE はそれが実際には存
       在しないファイル名だったとしても、FIGNORE に一致すれば候補削除する。bash
       FIGNORE は候補が FIGNORE で全滅してもそのまま。bash FIGNORE は単一候補だっ
       た時にも FIGNORE を適用して候補を消す。
 
 2021-12-14
 
   * compat: RLogin で ble-detach した後に modifyOtherKeys の状態がおかしい。
     bash --norc してもおかしい。RLogin である事は検出できている。
 
   * compat: terminator で status_line で表示が崩れる
     →これは今確認した所再現しない。terminator ではなく terminology の可能性?
     或いは古い vte の問題だった可能性もあるかもしれない。
 
   * compat: mlterm 起動時に表示が乱れる with statusline
 
     →これは単純に初期の char_width_mode,char_width_version が一致していない事
     による問題だった。始めから east にしておけば乱れは生じないという事は確かめ
     た。然し、auto で幅を判定する迄の表示の乱れは一般の問題ではないだろうか。
 
     乱れを最小限にするには文字幅を大きめに取るという意味で east で始めるという
     手もあるかもしれないが、実際には west の端末の方が多いという事を考えると別
     の問題が出てくる可能性がある。また、CPR に応答しない端末の場合ずっと east
     という事になってしまって問題である。起動して暫くは east にしてそれから west
     になるという様な感じの物を auto で判定中の幅にするべきだろうか?
 
   * C-backspace の問題 (端末自動判定?)
     https://github.com/akinomyoga/ble.sh/issues/94
     https://github.com/akinomyoga/ble.sh/issues/104
     https://github.com/msys2/MSYS2-packages/pull/2490
     https://github.com/microsoft/terminal/issues/755
 
     以前に色々の端末の動作を調べたと思ったが記録が全く残っていない。辛うじて上
     記の MSYS2 にどのようなパターンがあったかが記されているが、それぞれどの端末
     がどう振る舞っていたかの情報はない。改めて調べる。→ wiki にまとめた。
 
     うーん。^? と ^H が異なる形に bind されているという事は。。。どうしようもな
     い。既定では両方とも backspace だと思って置くしかない。ユーザーが自分で設定
     をする時にちゃんと判定するのが良い。
 
     もしくは端末を自動的に判定して C-h, C-_, etc を C-BS に置き換える設定を行う
     という事も考えられる。
 
 2021-12-11
 
   * declare の引数チェックをもっと真面目に実装する。chroma のインターフェイス
     設計の足がかりにする。
 
     * wattr=- (未着色) の時にのみ着色しているが、実際には一つでも未着色があった
      らそれ以降の引数に対して与える影響を考慮に入れなければならない。但し、これ
      を実行すると毎回ファイル名着色が全て計算されるなどの様な形になりとても遅く
      なると思われるので、未だ実装しない。
 
       これは一般の問題なので別項目で議論するべき気がする。mandb_opts 等を用いて
       指定する可能性。
 
     * declare: -f, -F が含まれる場合には関数名として任意の名前を含む事ができる。
       というかオプション名も含む事ができる? (declare -F -f とした時の解釈はどちら
       になるのだろうか?)
 
     * 変数代入の形式をしていない引数に関しては中身によってOKかもしれないし駄目
       かもしれない。
 
   * refactor: highlight-variable というインターフェイスを作る。
 
     と、思ったが quote 等も考えるとそういった関数を提供する事に意味があるのか
     分からなくなってくる。先に quote 除去した時の対応関係について解決する枠組
     みが必要になるのではないかという気もする。
 
   * cmdspec: cd 関連の cmdinfo は core-cmdspec ではなくて contrib/cmdspec/* 辺
     りに移動する?
 
   * PROMPT_COMMAND / trap DEBUG で問題が起こる? (found by rashad-moves)
     https://github.com/rashad-moves/HomeConfigurationFiles/commit/efbac4153fd5021f1bc00d42c618fd9d6f4090b9
 
     2022-03-03 うーん。どうもこの問題は以下で報告されている物と同じの気がする。
     timer_show が含まれている。
     https://github.com/akinomyoga/ble.sh/issues/176
 
     実行時間の表示について Q&A にでも書いておくべきだろうか。
 
   * complete (source:rhs): 変数名依存の補完に対応しても良いのでは。
 
   * complete: ARGEX (eval 文脈) の補完
 
     現在は "variable:=, command:D, file" で生成しているが、本来は一番先頭の引数
     を元にして argument (including progcomp, etc.) を呼び出すべきなのではないか。
 
   * complete: [[ の中の文法も考慮した補完。これは [[ の中の文法にちゃんと対応し
     た後で考える事の気がする。
 
 2021-12-06
 
   * mandb: コマンドの名称を抽出して保持して置けば binary の呼び出し時に使える。
     dnf や apt 等に問い合わせても良いのかもしれない。或いは、含まれているパッケー
     ジを見るという手もある。
 
     然し各コマンドについて man 等を呼び出すのは高価である。
 
     rpm, dnf でファイルの所属する package と含まれるファイルを抽出するには。
     https://linux-audit.com/determine-file-and-related-package/
 
     $ dnf -C repoquery --installed -f /usr/bin/git-lfs --qf '%{summary}'
 
     等の様にすれば良い。
 
     * resolved: しかしこれを呼び出すと package 一覧のダウンロード等を実行し始め
       るので問題がある気がする。或いは、更新を無効化した状態で呼び出す事ができ
       るだろうか →どうやら dnf -C とオプションを指定する事で cache から情報を
       取得できる様だ。
 
     * background で生成するにしても時間がかかるので、複数の bash session で同時
       に更新が実行されない様に注意が必要である。*.part.$$ に書き込んで、その後
       でそれを mv するという形にすると良い。更に、他の session が既に生成を試み
       ている場合には、background 生成を止める事にする。
 
     うーん。以下の結果を加工すれば一挙に全てのコマンドについて情報を抜き出せるのでは。
        $ dnf -C repoquery --installed --whatprovides /usr/bin/\* --nvr
        $ LANG=C dnf -C provides -q /usr/bin/\*
 
     * man -f ...
 
       というか man -s 1:6:8 -f command... を呼び出せばよいらしい。
 
       * linux では man -s 1:6:8 -f command 等として結果を得られる。whatis -s
         1:6:8 command としても同じ出力結果である。というか whatis 自体が man に
         よって実装されている疑惑 (-s オプションなどがあるので)。
 
       * cygwin で実行したら駄目だった。whatis sed awk とした時と全く同じ出力結
         果になったので、whatis を使っているのだろう。
 
       * solaris では man -f sed は表示されるが、man -f sed awk や man -f sed -f
         awk 等の様にして複数の結果を取得しようとすると何も表示されなくなる。1行
         目は空行で、2行目に man ファイルの情報があって、3行目にようやく説明が表
         示される。
 
       * minix では man -f sed で whatis を間接的に呼び出そうとしている。そして
         whatis はデータベースがない等の文句を言って動かない。
 
       * freebsd でも whatis を呼び出している様だ。警告が出ているが、複数指定し
         たら複数の説明をちゃんと出力してくれる。, 区切りで一行に複数の名称を出
         す事もある。例えば man -f awk とすると "awk, nawk (1) - <説明>" という
         具合の行を出力する。
 
   * complete: 文字列引数の中にファイル名を含めたい事もあるのでは。つまり "add
     a.sh" の様な。特に complete -m '...' の編集で欲しくなる。
 
   * bash-completion: awk - で long option だけが生成される。調べてみると
     complete -F _longopt が割り当てられているコマンドについては全てこのパターン
     の様である。
 
   * bash-completion: 空文字列に対して最初からオプションも生成して欲しい。
     そうしないと絞り込みの際に都合が悪い。
 
     うーん。bash-completion や他の補完の事を考えると一文字目に - が入力された時
     点で候補を再生成するべきの気がする。或いは - から始まる候補も追加する? 追加
     する場合には以前にあった物と重複する候補を削除しなければならない事に注意する。
 
   * syntax: for $(echo hello) に対しては着色しない。もしくはエラーとする。
 
     これは heredoc 単語と同様の問題である。因みに heredoc の単語に $() を含めた
     場合には、終端位置判定が正しくできなくなっている。普通に入力すると終端位置
     を逃す。終端を書いてから heredoc の中身を編集すると位置を正しく特定できる。
 
 2021-11-23
 
   * kitty shell-integration (requested by kovidgoyal)
     https://github.com/akinomyoga/ble.sh/issues/110#issuecomment-976182311
     https://github.com/kovidgoyal/kitty/issues/3948
 
     | [Check default shell-integration]
     |
     | * ok: 前のコマンドの内容を less で見る: C-S-g
     |
     |   vim-airline を表示している時に問題が生じる。中途半端に切れたりする。
     |
     | * ok: プロンプト移動(scrollback): C-S-{z,x}
     |
     | * マウスによるプロンプト内の移動:
     |
     |   遅い、vi_nmap の中にいると変な事になる。うーん。これはまた後で確認する。
     |
     | * xterm-title で現在ディレクトリを表示する。
     |
     |   これは別に何か新しい機能という訳でもないだろう。敢えて ble.sh で対応する
     |   とするのであれば、bleopt prompt_xterm_title を用いるぐらいの事である。
     |
     | * これも特に変な事はない。但し、ble.sh 側でユーザーが何か設定している場合に
     |   は、kitty integration の設定は off にすれば良い。
     |
     | * ok: winch glitch の解決。これは綺麗に動いている。
     |
     | * Sophisticated completion for the kitty command in the shell. これは
     |   core-complete の領分であるが何か特別な事が起こるとも思われない。
     |
     | 結局 vim-airline を実行した事による問題点は C-S-g で閲覧する内容の切り取り
     | 以外では特に問題になっていない様に見える。以下の三点を報告する。
     |
     | x subshell の中でちゃんと動作していない。従って tmux の内部でも動作しない。
     |
     | x 複数行コマンド編集時に vi_nmap で位置がずれる。他の keymap では問題は生じ
     |   ない。
     |
     | x vim-airline を使っていると時々コマンド内容が切れる
 
     最初の項目については意図的なのだという返信が来た。だとしても tmux で空にな
     るというのは変である。後で patch を作っても良い。問題にしているのは
     invasive という事だったので SHLVL, SUBSHELL, $- 辺りを参照して本当に kitty
     の中にいる時にだけ有効にするというのが良いのかもしれない。(と思ったが、元々
     の kitty.bash でも kitty かどうかをチェックしているのではないか?)
 
     2つ目の項目に関しては仕方のない制限だという事。up/down を有効化する
     sequence について提案した所、patch が送られてきたら見るとの事。これは忙しい
     ので今は未だ。
 
     3つ目は調査中。
 
 2021-11-21
 
   * complete: インラインでヘルプ・次に期待する引数の種類を表示するという話
     https://www.reddit.com/r/bash/comments/qrm3s2/hints_for_argument_types_in_bash/
     https://github.com/fish-shell/fish-shell/issues/2201
 
   * やはりメモリを使うという事は明記するべきである。
 
     bash-3.2 16MB 19MB
     bash-4.3 26MB 31MB
     bash-5.1 33MB 40MB
 
 2021-11-05
 
   * vim の :term 内部で実行すると振る舞いが変だ
 
     * 先ず最初のロード時に行が一行ずれる。それ以降は発生しない。modifyOtherKeys
       もしくは文字幅判定の為に出力している何かが問題を起こしているのかもしれな
       い。
 
       →どうもこのずれは status_line に関係している様だ。
 
     * うーん vim :term の中だと NUL (C-@, C-SP) を入力することができない。C-wは
       vim の側での操作に使われている様だ。これらは ble.sh の外側でも同様である
       事から、ble.sh の問題ではない。寧ろ vim term の仕様と見るべきである。
 
   * bash-5.2 で builtin bind -Xs を観察するとところどころ \000 が余分に挿入され
     ている。これは何か。bash-5.1 では問題はない。
 
 2021-10-26
 
   * winch: Window サイズを変化した時に menu の座標計算がずれる
     (menu_style=dense)そもそも resize した時点で menu の再配置を実行しなければ
     ならない筈である。
 
     或いはサイズが変わった時には menu-complete はキャンセルするべきなのではない
     か? 特に大量の WINCH を送ってくる端末があって、大量のメニュー項目の後ろの方
     のページを表示しているとすると、ほぼフリーズした様な形になってしまう。
 
     或いは次に TAB を押して他の項目を移動しようとした時点で改めて配置計算を実行
     する? 例えば、WINCH を受け取った時点では info を単に非表示にしておいて、次
     にメニューに対して表示の変更等を行う必要が生じた時に改めて計算を実行する。
 
     2022-03-04 そもそも ble/edit/info 自体が WINCH の時に再計算するべきなのでは
     ないか。特に高さだけでなく幅についても考えて再計算しないと内容が乱れてしま
     う。
 
   * スタートしてから数秒間は user input detection for C-m を off にした方が良い
     のでは。スタートした直後にペーストを実行する事があるとは思われない…。
 
     と思ったが bash を含む大量のテキストを入力した場合にどうなるのかというのは
     疑問である。とは言いつつも、その場合には親シェルの側でちゃんと paste
     detection ができているべきではないかという気がする。
 
 2021-10-04
 
   * fzf を直接読み込んだ時に動かない問題について
     https://github.com/akinomyoga/ble.sh/issues/126
 
     ble-update を実行すると動く様になるが最初から source ble.sh すると動かない。
     ble-import contrib/fzf-key-bindings をすると動く様になる。
 
     というか改めて説明を読むが一体どういう操作をしようとして問題が生じているの
     か謎である。C-r, C-s をしようとした時に問題が生じているという事だろうか。現
     在の実装では補完については contrib/fzf を自動でロードする様にしている。
     widget に関しては contrib/fzf-key-bindings 経由で呼び出さなければ駄目である。
 
     うーん。自動的に検出して補正する様にしようと考えたがそんなに単純ではない様
     に見える。
 
     a 例えば bind する瞬間に fzf 関連であるかどうかを調べて fzf 関連であると分
       かった時点で fzf-key-bindings を呼び出すという方法。
 
       x ユーザーが実行したい binding が fzf-key-bindings と同じかどうか分からな
         い。ユーザーが自分で調整して binding のキーを変更しているかもしれない。
         この場合には勝手に fzf-key-bindings を読んでしまうとユーザーの予期しな
         い binding が定義される事になり問題である。
 
         一方で、諸々の関数は fzf/shell/key-bindings.bash に定義されているのだか
         ら、そこに含まれている関数を使おうとしている時点で其処にある binding が
         そのまま使われていると仮定して良いのではないか。もし、ユーザーが
         fzf/shell/key-bindings.bash を自分でコピー・編集して使っているのだとし
         たら、やはり contrib/fzf-key-bindings.bash についても同様に自分の設定に
         合わせて編集するべきなのではないか。
 
       o bind で -x に fzf 関連を指定した場合に関数の中身を差し替える等の事をし
         ようとしても、例えば inputrc キャッシュで初期化を誘導する等の事までは
         キャッシュできない気がする。
 
         →これに関しては fzf-key-bindings では関数の中身を差し替えるのではなく
         て、別名の関数を定義してそれに差し替える様にして、更にその別名の関数に
         ついての autoload を def.sh 辺りに記述する事にすれば良い。
 
         x この方法だと __fzf_cd__ や __fzf_history__ をユーザーが直接自分で
         bind した時に対策できない。
 
     b 或いは、bind -x を実行する時にコマンド名が __fzf_history__ または
       fzf-file-widget だった場合にこれらの関数を上書きするという手法。
 
       x この方法だと __fzf_cd__ の検出ができない。__fzf_cd__ は、
         fzf/shell/key-bindings.bash だとマクロ経由で呼び出される様になっている。
         つまり bind -x ではないという事。かと言って accept-line に作用して、コ
         マンド実行前にコマンド内容を調べて関数を上書きするというのも非現実的な
         気がする。
 
       うーん。やっぱり現状の様に設定するべきなのではないだろうか。
 
 2021-09-28
 
   * fast-syntax-highlighting
 
     https://www.reddit.com/r/zsh/comments/oyege0/is_completionaware_syntax_highlighting_possible/
     https://github.com/zdharma/fast-syntax-highlighting/tree/master/%E2%86%92chroma
     https://github.com/Valodim/zsh-capture-completion
 
     どうやら programmable highlighting に相当する機能は
     fast-syntax-highlighting で既に実装されていて "chroma" と呼ばれているらしい。
     然し実のところそれ程沢山の実装がある訳でもない。
 
     他に zsh-capture-completion というモジュールに含まれる関数で capture.zsh
     'command' を実行すると 'command[TAB]' とした時の補完結果を取得できるらしい。
     これは ble.sh の上で作成する事も可能である。補完機能のテストで使うのに便利
     な気がする。
 
     bash-completion のテストをコピーできたら良い気がする…。でも全て python で
     定義されているというのは難点である。うーん。結局、その場で補完を実行する機
     能を実装したとしても使う機会がないからテストされずに残って意味のない機能に
     なりそうな気がする。
 
   * https://www.reddit.com/r/commandline/comments/pv1fm8/what_are_the_main_advantages_of_the_various_shells/
 
     fish の便利な機能について紹介している。
 
     * M-{right,left} でディレクトリ移動。これについては異なる keybinding で提供しても良い気がする。
 
       iswitchb の如く C-x C-b 等で探索するのもありではないか?
       その際には menu の機能を有効活用できる気がする。
 
     * fish の Abbreviations の振る舞いが気になる。
       zsh の zsh-abbr も気になる。
 
     然し、実際に ble.sh をロードさせてテストするというのは有効の気がする。
 
   * menu: C-x C-d で今迄に訪れたディレクトリの一覧。
 
     iswitchb と同様に絞り込みをしたいが入力した文字列は何処に表示するのが良いのか。
     panel に表示するのが良いだろうか。或いは、そもそも表示しなくても良いのかもしれない。
     何れにせよ太字で表示されるのであるから。
 
     太字ではなくてより強調した形にしても良いのかもしれない。これは face 経由で
     設定できる様にするのが良い様な気がする。現在は太字固定になっているが。
 
   * menu: C-x C-j で job 制御用の TUI メニューを表示しても良いのかもしれないとも思う。
 
 2021-09-26
 
   * bash-5.2: array が sparse でない ./configure option が追加された。
 
     もしかすると sparse arrays に declare -gA を指定する必要があるかもしれない。
     sparse かつ ordered な配列については簡単な workaround は存在しない。唯、そ
     の様な配列を実際に使っているかは分からない。なければ気にしなくて良い。
 
 2021-09-22
 
   * edit: 複数行モードの時は prior/next でページ移動?
 
   * plug: git clone 用の判定:
 
     これは
 
     $ grep -q '^github\.com' ~/.ssh/known_hosts
     $ grep -qEi '[[:space:]]*HostName[[:space:]]+([^[:space:]]+[[:space:]]+)*github\.com' ~/.ssh/config
 
   * 実は local rex=... [[ a =~ $rex ]] は関数に纏めたら良いのでは。
 
     速度的にはどうだろうと思って比較してみると4倍位遅くなる。もしくは 0.014ms
     だけ遅くなる。70回の評価で1ms, 1400回の評価で20ms, 7000回の評価で100msの差
     が出る。
 
     $ ble-measure "local rex=':point=([^:]*):'; [[ alpha:beta:point=end:b = \$rex ]]"
          3.618 usec/eval
     $ function ble/regex#match { [[ $1 =~ $2 ]]; }
     $ ble-measure "ble/regex#match alpha:beta:point=end:b ':point=([^:]*):'"
         17.402 usec/eval
 
     うーん。一般的には気にする速度低下ではないが、構文解析などの中心部では控え
     た方が良いかもしれないというぐらいである。通常の場所ではどんどん使って問題
     ないのではないか。
 
     →検索してみたが実は意外とそんなに沢山あるという訳でもない様だ。少しずつ置
     き換えていけば数日で終わるぐらいの箇所しか無い。概算で140箇所程度である。然
     し、そもそも其処までして置き換える必要があるのかという疑問もある。現状で動
     いているのであればそれで良いのではないか。一応他のシェルに移植する時に一括
     で動作を変更するのが楽という可能性はなくはない。
 
     2021-12-11 ble/string#match という関数名で追加した。
 
 2021-09-20
 
   * sabbrev: accept-line の時にも展開する可能性について (requested by pl643)
     https://github.com/akinomyoga/ble.sh/discussions/138
 
     * zsh-abbr の振る舞いについても確認する。
 
     * 振る舞いについての考察
 
       a グローバルに全ての合致する単語を置換する。
 
         x 先ず、意図しない物まで展開されてしまう可能性がある。
 
         x 展開を意図する単語があったとしても、通常は magic-space によって既に展
           開されていると期待するべき。なのでわざわざグローバルな展開を試みるま
           でもない。
 
       b 或いはその場所にある単語だけを展開する magic-accept 的な物。
 
       元の要求が結局どのような物だったかは返事がないので不明だが、考えて見るに
       b の方が良い。
 
 2021-09-15
 
   * haiku: ble/builtin/bind/.reconstruct-user-settings の gawk が無限ループになっ
     ている? 或いは滅茶苦茶遅くなっている。gawk 4.2 である。bash-4.4.23 から呼び
     出している。変な事が起こる様な余地はない様な気がするが…或いは正規表現エン
     ジンなどが壊れているという事なのかもしれない。
 
   * solaris: ble-bind を bashrc 内部で呼び出した時点で未だ attach していないの
     に色々と info を表示してしまっている。
     $_ble_base_cache/decode.cmap.gdict.*.dump を削除した時に再現する。
 
   * grapheme: SpacingMark, Prepend の幅は一体どうなっているのだろうか [#T0008]
 
     現在の実装では幅を全く考慮に入れていないが、入れるべきの気がする。c2w で
     combining に対して 0 を返す様にしたら Extend や Prepend に対しても c2w で値
     を計算して加算する様にすれば良いだろうか。然し、絵文字の Emoji_Modifier な
     ど組み合わせた時と単体の時で幅の異なる物も存在する。
 
 2021-09-06
 
   * menu: メニューの詳細表示を toggle できる様にするべきではないか。
 
     表示するか表示しないか完全に固定するのは微妙な気がする。
 
     後、desc-raw しか実際には使わない様な気がする。二種類の表示方法を用意したと
     しても、そもそも説明を生成する側で二種類を分けて生成する訳にも行かないので、
     どちらかに統一するべきではないか。速度が気になるというのはあるが、もしテキ
     ストだと解釈するとしても、全角文字などが含まれる場合には結局位置計算は省略
     できない。逆に ascii 文字だけで構成されているのであれば esc を解釈するとし
     てもそんなに速度低下なく処理する事ができる。
 
     表示の toggle は各メニューが表示される度に行うか或いは一回変更したら暫くそ
     の設定を保持するか。ユーザーの指定した設定を既定値として各 menu が表示され
     る度に toggle を行うという事を考えたがそれは如何にも面倒である。それよりは
     toggle は永続的な変更を引き起こすとした方が分かりやすい様な気がする。その場
     合には、bleopt の設定を永続的に設定してしまっても良いのではないか。
 
     然し、それだと desc モードになっている時に align 等を設定した時にどの様に振
     る舞えば良いのか分からない。一つの手は一旦完全に toggle 状態を clear して、
     改めて既定の style として align を設定するというのが自然な気がする。
 
     * toggle するとしたらその表示切り替えのキーボード操作はどうするのか。C-m と
       思ったがそれだと確定と同じ。C-d だと削除みたいな感じがする。insert は確か
       に toggle だがやはり直感的ではない気がする。 ScrLk や CapsLock NumLock 等
       も同様である (というか OS 側のキーボードの状態が変わってしまったりして大
       変である)。
 
       後、実際に menu-complete に入らなくても切り替えられた方が良い様な気がする。
       その場合には他と被らない様な操作にする必要がある。他で使われていない
       single-key の操作はそうそう残っていない気がするし、残っているとしてもそれ
       をたかが menu toggle に割り当てるべきなのかという問題もある。或いは、2
       keys による操作としても良い様な気はしている。
 
       例えば C-x | 等。特に C-x は menu-complete やその他の complete に色々割り
       当てているから丁度良い気がする。
 
       - "C-x d" は emacs では dired,
       - "C-x ?" は emacs では keybinding 一覧,
       - "C-x h" は emacs では全選択に割り当てられている。
       - "C-x |" は emacs では割り当てがない。
       - "C-x C-h" は前の文を削除する。
       - "C-x C-t" は行の入れ替え。
 
       若干操作しにくい気がするが、うーん。一旦 menu-complete に入ってしまえば
       "|" で入力できるようにすれば良いと思ったが…普通に "|" を入力したいという
       時があるのでそれは駄目だ。やはり C-? の形の方が良い。
 
   * menu: preview 機能をつけても良い。preview に表示する中身は候補の種類に応じて色々。
 
     そもそも desc の内容自体その場に表示するのではなくて preview 的な小さな窓の中に
     選択した時にだけ表示するという形式でも良いのではないかという気がする。
 
 2021-09-02
 
   * 改めて確認した所また Windows Terminal で動かなくなっている
 
     調べると Cygwin 経由で接続した時だけの問題の様である。
     これは Cygwin の側の conpty の副作用という可能性もある。
     というか最新版の Cygwin で直っている可能性もある。
 
     ? wt を path に加えて実行もできるのにも関わらず構文着色で赤になっている。不思議だ。
       type wt とするとちゃんと成功する。
 
     ? Cygwin から起動した時とスタートメニューから起動した時で、Windows
       Terminal の中で Cygwin タブを開いた時のプロンプトに含まれるシー
       ケンスが異なっている気がする。と思ったが、これは Cygwin の
       screen の中から起動すると、Windows Terminal の中の Cygwin も
       screen の中にいると勘違いするからであろう。気にしなくて良い。
 
       取り敢えず環境変数が継承される事は確認したし、
       CYGWIN=disable_pcon を指定していても指定していなくても Windows
       Termianl - Cygwin では座標計算がずれるという事が確認できた。やは
       り pcon は関係ないのかもしれない。
 
   * 起動時間を計測しているようだ
 
     ble.sh でかなり時間がかかっている様だという事。
 
     * ble.sh は background 処理を行う。特に ble-attach の末尾で行っている気がす
       る。なので、ユーザーが何も入力しない限り background 処理を完全に終えるま
       で ble-attach から抜けないのではないか。逆に、ユーザーが何か入力している
       時にはより早く初期化できるのではないか。と思って試してみたがそうでもない。
       というか殆ど変化がない。どういう事だろうか。
 
       ユーザー入力の検出ができていない? 或いはそもそも background 処理は最初は
       行っていない? 後者の様な気もするが後で確認する必要がある。
 
       letsnote でも試してみたがやはりユーザー入力があっても殆ど変化はない。
       GNU/LInux でも Cygwin でも同様にユーザー入力があっても変化はない様だ。
 
       実装を確認してみると確かに ble-attach の末尾で .tail を呼び出してい
       て、.tail は idle.do を呼び出している。うーん。不思議だ。或いは .tail の
       前後だけに注目すればより短くなっているかもしれない。
 
     * MSYS2 環境では ble.sh のロード及び attach にはかなり時間がかかる様だ。と
       いうかこれは fork の回数に直結しているという気もする。MSYS2 で調べると
       spawn が 10/s だった。
 
       一方で Cygwin だと 23/s 程度である。実は Cygwin の方が軽量である。或いは
       最適化が施されていると見るべきか。或いは whitelite に入れていただろうか。
 
 2021-08-31
 
   * complete: -E (_EmptycmD_) に対応していない
 
     一方でこれは一体どの様に振る舞うものとして実装すれば良いのか分からない側面
     がある。文字列が本当に空の時にはこれを使って補間するので良い。
 
     * ; で区切って未だ何も入力していない状況の時にはどう振る舞うべきか。元の
       bash では本当に空文字列の時にだけ呼び出される様である。また -E の用途とし
       て空の時のコマンド候補を生成するという役割もあるかもしれないが、
 
       というか改めて考えると ; で区切って未だの時には -I が対応する補完になるの
       ではないか。という事を考えると -E はやはり完全に空の時に対応するのではな
       いだろうか。実際に試してみるのが良い気がする。
 
       complete -F _initial -I, complete -F _empty -E で試してみると ; の次で呼
       び出した補完の場合には _initial が呼び出される。完全に空の時には _empty
       が呼び出されていて一文字でも入力されていれば _initial が呼び出される。入
       力されているのが空文字列であっても同様である。
 
     実装するとしたらどの様に実装するべきだろうか。単に空の時には新しく -E で呼
     び出す仕組みを作れば良いのだろうか。
 
   * msys2 での ble-update で変な動きをした。。
 
 2021-08-30
 
   * complete: overridden builtin 及び他の framework
 
     | * https://github.com/csdvrx/bash-timestamping-sqlite
     |
     |   この実装では history コマンドを上書きしている様な気がする。然し同時に
     |   ble.sh との併用を推奨している。うーん。この時 ble.sh が history を上書きす
     |   る、もしくはble.sh の history がこの枠組に上書きされるという事があったら何
     |   が起こるのだろうか。何か悪い事が起きる気がする。
     |   ble/function#push とかを使って何とかすれば良いのだろうか。
     |   その場合にはこの interface を固定する必要がある。
     |
     |   と思って実際にコードを確認したが history を上書きしている訳でもない様だ。
 
     何れにしてもこれは注意点として README に記述しておくべきなのではないか。
 
   * complete: そもそも遡って書き換える補完候補と純粋な意味での補完候補は区別す
     るべきなのかもしれない。TAB 補完では後者に基づいて補完を実行するが、メニュー
     の表示には両方を表示するという手がある。その場合にはメニューの内部で
     section を分けると良いだろうか。ページング等をちゃんと考慮に入れる必要があ
     る。
 
 2021-08-29
 
   * bashrc に直接設定を書く方法についても説明する。
 
     但しこの場合には ble-reload をした時に設定が消えるという事に注意する。→うー
     ん。この様な面倒な事が起こるのであればやはり記述しないほうが良いのではない
     か。
 
     よく考えてみたら source ble.sh と ble-attach の間に書いた bind にも同様の問
     題があるのではないか? と思ったが、ble-attach よりも前に書いているのであれば
     ちゃんと readline の側にも反映されている筈で問題はない筈。
 
     ユーザーがコマンドラインから設定した設定は消えてなくなってしまうという事に
     注意する。これらを記録して後で拾える様にするという手もあるかもしれないとは
     思う。
 
 2021-08-26
 
   * CPU 100% in macOS (reported by killermoehre)
     https://github.com/akinomyoga/ble.sh/issues/131
 
     CPU 100% になっている時に同時に gawk が待機している様である。
     100% になっている時の gawk の引数について尋ねたら返答が来た。
 
     二つの bash について異なる gawk が呼び出されている。前者は
     ble/history:bash/resolve-multiline/.awk で、後者は
     ble/history:bash/load/.background-initialize である。両方とも
     history に関係している。
 
     Q というかどちらの bash が CPU 100% になっているのだろうか。或いは両方?
 
     Q bash が起動した時に暫く 100% になるのか起動した後もずっと 100% のままなの
       か。もし暫くしたら収まるのだとしたらどれぐらいの間 100% でいるのだろうか。
       これがそんなに長くなければ少なくとも見た目の動作に影響がない限りはそのま
       まにしておいても良い様な気がする。
 
     Q CPU 100% になっている間 bash は応答するだろうか。応答するとしたら
 
     Q いつでも現象は再現するだろうか。或いは確率的に発生するだろうか。
 
     ----
 
     取り敢えずやはり巨大な history が問題であるという事までは分かった。
     自分の手許の linux では同じぐらいの巨大な history を用意したとしても
     そんなに遅くはない。
 
     ? 一方で向こうの報告によると builtin history を実行しているプロセスが重いと
       いうことの様である。自分の手許で確認しようとしているがすぐに処理が終わっ
       てしまうので確認できない。
 
     * 終了時にもかなり待たされる。
 
       終了時の nawk が滅茶苦茶遅くなる。gawk だと遅くないとかあるのだろうか。と
       思って改めて観察してみると最初に bash が 100% になって、その次に nawk が
       100% になるという具合に処理が進行している。
 
       ble/builtin/history/.write で時間を消費している。
 
       A:1630043056.816931
       B:1630043056.936962 0.12s ... history/.get-min
       C:1630043056.942516 0.06s ... history/.get-max
       D:1630043079.487224 13s ... builtin history >> file
       E:1630043092.465937 13s ... nawk の処理
 
     Q hang と slow は区別しているのだろうか。自分的には hang というのは待っても
       絶対に終わらないという意味である。然し、向こうは有限時間で終わるという事
       を確認しているのにも関わらず hang と言っている可能性がある。よく分からな
       い。
 
 2021-08-23
 
   * bash-4.2 では [[ ${arr[*]} == *" 2 "* ]] (where arr=(1 2 '')) が駄目
 
     一応該当しそうな物を検索すると以下の様な物がある。
     何れも空白には関係なさそうなので問題は起こらなそうな気がする。
 
     $ grc '\[\[ \$\{.*\[[*@]\].*\} [!=]= .* \]\]'
     ./ble.pp:145:    { ((${#BASH_SOURCE[@]})) && [[ ${BASH_SOURCE[${#BASH_SOURCE[@]}-1]} == *bashrc ]]; } ||
     ./src/decode.sh:3632:    [[ ${keys[*]} != "$bind_keys" ]] &&
 
 2021-07-14
 
   * bash-it によるプロンプト設定が prompt attach で反映されない。
 
     PROMPT_COMMAND 経由で PS1 を設定していると反映されないのだろうかと思ったが
     そういう訳でもない様だ。
 
     powerline-multiline で発生するとの事だが再現しない。
     というか powerline-multiline で発生する固有の問題なのか、
     それとも他の theme でも動作するのかの情報についても書いていない。
 
 2021-07-13
 
   * auto-menu: 一旦 (no items) が表示されるとそれ以降 auto-menu が動作しない
 
     auto-menu が有効になっている時に一旦 (no items) が表示されるとそれがそのま
     まになって二度と auto-menu が起動しなくなる。
 
     またこの時に C-l で再描画すると info に何も表示されなくなる。実はこれは
     menu が表示されている時には常に再現する問題である。
 
 2021-06-21
 
   * auto-menu が有効になっている時に複数行編集で座標が変になる
 
     2021-07-13 今試しても問題は再現しない。
 
     2021-07-18 再現した。履歴に複数行の項目が含まれている時に、その履歴が呼び出
     されると問題が発生する。ble-bind ... と入力した時に発生した。というかこれは
     本当に auto-menu の問題なのかどうか分からない。取り敢えず、textmap を再確認
     する必要がある気がする。ずれの量的にも前回の textmap の時と似たような振る舞
     いの様に見える。
 
     2021-07-19 chatoyancy の上では再現しない? vaiio2016 の上でも再現しない。
 
 2021-06-18
 
   * grapheme: ble/canvas/trace の lc lg の grapheme cluster 対応について
     Ref #D1619
 
     基底文字だけを指定しても、最後の Extend を指定しても端末によって左の書記素
     クラスターが破壊される可能性がある。書記素クラスター全体で出力する必要があ
     る。lc lg の組ではなくて lcs lw lg の組で結果を返さなければならない。lc lg
     はデバグ用なので其処まで配慮する意義は薄い。
 
     そもそも lc lg の枠組みはそろそろ削除しても良いのではないかという気すらする。
 
   * grapheme: 私用文字で置き換える事により書記素クラスター単位での編集を可能にする可能性
     Ref #D1619
 
     現在の所その必要性は限りなく低いと考えられる。
 
   * grapheme: Unicode version 毎の振る舞いの違い?
     Ref #D1619
 
     emoji_version と同様に grapheme_cluster についても version 毎の違いを考えて
     も良いのかもしれない。
 
   * emoji: Emoji 対応状況自動判定
     Ref #D1619
 
     | これも自動検出の対象にしても良いのでは。という気がする。というかそうする
     | べきである。所で Zle は実は内部的にそういう事をしている可能性がある。
     |
     | と思ったが端末によって unqualified の取り扱いもばらばらだろうし ZWJ に対
     | 応しているのかどうかも不明だし、という事を考えていくと単に
     | legacy/extended を区別すれば良いという訳ではない。場合によっては ZWJ シー
     | ケンスに対応しているかどうかと言ったフラグまで管理しなければならないかも
     | しれない。とは言いつつ実際にそのように振る舞う端末が存在するのかどうかも
     | 不明である。なので、これは実際の端末の振る舞いを整理しながら考える必要が
     | ある。
     |
     | 端末ごとの絵文字の振る舞いについて調べる必要がある気がする。kitty/vte は
     | unqualified はテキスト表示で EPVS によって絵文字になる。RLogin は
     | unqualified は半角で表示される? 幅は VS で変化しないように見える。mintty
     | は試した限りでは Emoji に対応していない。既定で off になっているという事
     | だろうか。
     |
     | 以下の振る舞いも端末の対応状況に応じて実装する。
     |
     | * EPVS の時には emoji_width または 2 になる様にしている。然し、絵文字の表示
     |   ができない端末では 2 にせずに普通の文字として求めた方が良い可能性もある。
 
     * legacy vs extended
     * unqualified をどう取り扱うか。EPVS 及び TPVS がどう作用するか
     * ZWJ sequence に対応しているかどうか
 
     現実の端末に於いてそれぞれどう対応されているか、そして三つの対応状況の組み
     合わせはどうなっているかについても調べる必要がある。
 
   * test: ログを何処かに保存する機能? その場合には着色等は除外する
 
   * syntax_debug の時にコマンド実行すると実行位置が変だ
 
     うーん。info　を削除する時のシーケンスが間違っている? menu の表示時には何も
     問題がない。menu に関しては消去してから実行するからだろうか。或いは、変なタ
     イミングで info が更新されて info が表示されてはいけないタイミングで表示さ
     れているという事だろうか。
 
   * progcomp の出力に関する議論 (reported by oc1024)
     https://github.com/akinomyoga/ble.sh/issues/121
 
     うーん。どうするのが良いのか微妙。Bash と同じ様に動作するべきなのか、或いは
     出力を抑制するべきなのか。関連する議論が幾つかあった様な気がする。というか
     最近抑制する様に変更した様な気がするが何故再発しているのだろう。実際に確認
     してみた所、歴史的には常に出力を許している様にも見える。不思議だ。
 
     うーん。実は progcomp-helper-func ではなくて、compgen の時点で出力を抑制し
     ていたのだったろうか。
 
     * 98835b5 2021-05-17 これは _ble_util_fd_stderr 等に保存した fd を使う様に
       する変更。本質的には tty を使う様になっている。元から helper-func で tty
       にリダイレクトしていた。
 
     * 9d4ad56 2021-05-06 うーん。以前の報告が見つかった。よく見たらこれも
       oc1024 による報告である。この commit では stderr に関連する変更はない。
 
       https://github.com/akinomyoga/ble.sh/issues/97
 
       どうもこの時は個別にバグのある関数を置き換えたのだった。修正は 9d4ad56 で
       ある。stderr/stdout に対しては全く変更していないし細かい議論もしていない。
 
     * 4fc51ae 2021-03-10 fzf に対する対策。これについては明示的に tty にリダイ
       レクトしている。これより前は compgen 呼び出しの stderr への redirect の為
       に stderr は抑制されていた。
 
     * 68f8077a 2020-04-06 これは compgen 呼び出しに builtin を付加しただけ。
 
     * 1ca53868 2019-01-01 これは complete -p の解析に機能を追加した物。この時点
       で compgen の stderr は抑制している。
 
 2021-06-13
 
   * menu-complete: 末尾一致 (skip-completed-text) が考慮に入っていない
 
     これは最終的な挿入時に処理するべきか、或いはメニュー項目を一時挿入している
     時から処理するべきか。メニュー項目を一時挿入している時から処理しないと振る
     舞いとして不自然になる気がする。
 
   * 終了ステータスが 2 の時に前回のコマンドを再ロードするというのは面白い試みかもしれない
 
     最近人気らしい thefuck により修正後のコマンドが取得できればなお良い。
 
 2021-05-29
 
   * syntax: 単語が sabbrev に一致する場合には着色するのが親切だ
 
     これは sabbrev に対する仕様拡張を行ってからでも遅くないのではないか。
     ble/syntax/progcolor/word:default 辺りに修正を加えれば良い。
     本来は progcolor よりも上の枠組みで着色したい気もするが
     それだと layer を増やす必要がある。処理が重くなりそうである。
 
     check-sabbrev 的な感じで付加的な処理として実装できれば良い。
     そうすれば custom な着色関数からでも呼び出せる。
     と思ったがちゃんと忘れずに呼び出すのも面倒である。
     やはりもっと下の枠組みで提供するべきだろうか。
     例えば、最終的に着色を格納する部分に介入してしまうという手もある。
 
 2021-05-27
 
   * wiki の更新
     * done: \g{...} について記述する (2021-06-13)
     * wiki: ble-import の -f オプション
     * wiki: bleopt の wildcard, -r, -u
     * wiki: blehook の -a
     * 2021-06-12 wiki: bleopt -I
     * 2021-05-24 airline: 使い方を説明に書く
 
   * やはり source_if() { source "$@"; } 等とすると引数が一つしかない場合に、自
     分自身が引数であると誤認してロードがキャンセルされる。
 
     % これは実は簡単に判定できるのではないだろうか。つまり引数が唯一つでしかも
     % 自分自身を指している場合には関数内で無引数でsource されたのであると判定で
     % きる。と思ったが違う。これで見えているのは外側の関数の引数なのだから、必
     % ずしもそういう形になっている訳ではない。
 
 2021-05-23
 
   * menu-complete: SIGWINCH による info#panel::invalidate の際にメニュー項目の
     再配置を実行するべきである。
 
     * info 拡張: というか info の表示を担っている class を動的に変更するべきな
       のではないか。現在の実装だと内容を変更する時には必ず info の関数を即時で
       呼び出さなければならない仕組みになっている。然し、そうではなくて機に応じ
       て丸ごと制御を移すなどの事をした方が良いのではないか。然し、一方でどの内
       容が一番上に来るべきかなどの制御も必要になる。現在は default/non-default
       の二層構造になっているがそれをもっと動的に変化できる様に改良するという手
       も考えられる。
 
 2021-05-21
 
   * progcolor: 取り敢えず builtin から始めるのが良いのではないかという気がする。
 
     ble.sh の関数についても着色及び補完関数を定義して行きたい。
 
 2021-05-19
 
   * complete: [TAB] 補完の場合には、ユーザー入力があった時に即座にキャンセルす
     るのではなくて timeout があっても良いのかもしれない。
 
 2021-05-17
 
   * 此処で思ったのだが nawk は Unicode の対象を取り扱えるのだろうか。。。UTF-8
     ならば通常の制御文字はそのままなので問題は生じないのではないかという気もす
     るが。文字数を数えて何かする様な処理では何か変な事が起こるかもしれないが、
     そうでなければ大丈夫の気がする。
 
     問題が起こるかもしれないのは brace expansion の形式でファイル名一覧を挿入す
     る処理。これに関しては UTF-8 だと例えば平仮名の途中で分断されたりして変な事
     が起こる可能性がある。
 
   * global: /dev/null を $_ble_util_fd_null に置き換える?
 
     #D1552 で議論した。毎回 open するよりも dup した方が高速である。一方で
     _ble_util_fd_null が上書きされたりした時は /dev/null の方が頑健である。
 
   * syntax: redirection が正しく解析できていない気がする
     以下の手順で編集した時に着色が間違っている。
 
     $ exec {fd}>/dev/null
     $ exec {}>/dev/null
     $ exec {_ble_base_fd_null}>/dev/null
 
   * 色見本について探した
 
     多くのサイトは微妙である。そもそも sRGB とかの概念があるのかないのか不明で
     ある。単純に RGB #XXXXXX の値を線形で CMYK に変換していたりしてかなり怪しい。
     色用語の場所にも sRGB やガンマ補正などの単語は見られない。
 
     https://www.color-sample.com/popular/jiscolor/ja/
 
     このサイトはちゃんと sRGB/Adobe RGB 等について載っているので少なくともちゃ
     んとその辺りの事を認識した上で作られたサイトであろうと思われる。然し権利関
     係の記述もないし、連絡先もない。メールボタンがあると思って押したら単に "友
     達にこのサイトを紹介する" メールを送る為のボタンだった。© 2021
     Color-Sample.com. All Rights Reserved. という表記の右にあるアイコンがリン
     クになっていたので押して見たが、単純にトップに跳ぶだけだった。Twitter アカ
     ウントは https://twitter.com/color_sample で見に行ったら 2014 で更新が止まっ
     ている。著作権が 2021 になっているのは機械的に置き換えているだけという事だ
     ろうか。何だかよく分からない。というかよく見たらブラウザサポートというアイ
     コンも古いブラウザが並んでいたりして更新が止まっている事を示唆している。
 
     https://triple-underscore.github.io/css-color-ja.html#rgb-to-lab
 
     w3 の CSS の仕様の翻訳。ここにちゃんと色々の知識が書かれている。この文書は
     最初から最後まで読むべき。
 
     http://mezala.la.coocan.jp/pc/jiscolor/jiscolor.html
 
     このページは複数の情報源からの差異について見せているがそもそも CMYK, RGB の
     変換式として異なるサイトから二種類持ってきていて (どちらかが間違っているの
     に違いない) 更に、Wikipedia からの数値も比較していて、どれだけ見た目が変わっ
     てくるかを見せているが。色には絶対的な基準はないのだとか色々言って納得して
     いるが、これらは単に sRGB と RGB の解釈を間違えて変換しているから起こってい
     る間違いのような気がする。(とはいいつつ画面の輝度やその他の要因もあるだろう
     から一概には言えないのかもしれないが、少なくともどういう条件の元での変換を
     行っているのか明示した上で、その差異について議論していなければ情報としては
     使い物にならない)
 
     https://www.colordic.org/w
 
     このサイトは和色大辞典と言って 460 色掲載しているそうで一番大きい気がする。
     然し、その RGB 値が sRGB なのかどうかとかも分からない。Q&A には再利用・再頒
     布可能性などについては述べられていないし、各色の出典についても書かれていな
     い。このサイトの RGB 値が実際に sRGB なのか何なのか確認して、その上で他の色
     についても変換を確認するのが良い気がする。
 
 2021-05-15
 
   * AUR blesh-git のカスタム update について
     https://aur.archlinux.org/packages/blesh-git/
     https://aur.archlinux.org/cgit/aur.git/tree/blesh-update.sh?h=blesh-git
 
     * {PRE,POST}_VERSION を local で宣言する
       これはもう既に修正してもらった。
 
     * _package.sh の属性は 644
       これに関しては結局指摘する機会がなかったからそのままだが、まあ大して問題
       はないだろう。
 
   * syntax
 
     1>&$fd- は使えない
     1>&./- もエラーになる
 
     もっとちゃんと調べる必要がある。
 
 2021-05-09
 
   * Fedora の package にするには結構面倒な手続きが要りそうな感じである。
     https://blog.jwf.io/2017/11/first-rpm-package-fedora/
 
     何れにしても ble.sh は頻繁に変更が加わっているし未だ 0.* の version の段階
     なので未だ公式に提出はしない事にする。1.0 を出す時に一緒に提出を考えるのが
     良いだろうと思われる。
 
   * v1.0 を出す迄に何か目玉の機能を実装したい所であるが、実の所、他のシェルに全
     くない様な機能で便利そうな物は存在しない。
 
     * syntax-highlighting ... 文法もちゃんと追跡した物
 
     * error message ... これは他のシェルにはない機能である。fish にあったりする
       かもしれないが。
 
     * vim mode ... これは highlighting も含めてなかなか気に入っている。
 
     * complete
       * sabbrev ... 個人的にこれは結構便利だと考えている。
       * auto-complete ... これは別に他のシェルと比べて何か良い訳でもない。
       * auto-menu ... これはちょっと煩い。けれど他のシェルにもあるので。
 
     * bottom panel ... 一つは bottom panel かもしれないがそんなに便利なのかとい
       うと微妙な所である。tmux の方の設定で似たような物を表示できる筈だし特に便
       利でもない。見た目に派手なので最初は喜んで使う人がいるかもしれないという
       位。
 
     * enhanced history ... 相対パスでファイル名を参照しているのを記録したい。そ
       れを auto-complete の実装に役立てたい。
 
     * TUI configuration?
 
     逆に欠けている物。ex mode の :cmd が全然対応できていない。
 
 2021-05-06
 
   * progcomp: complete -C completer で改行のエスケープに対応していない
 
     man bash によると completer の出力した結果は行志向であるが \ によるエスケー
     プで改行を含める事ができるらしい。然し、\ が特別な意味を持つのだとすれば行
     末に \ を置きたい時にはどうすれば良いのか。行内全体に於いてエスケープが意味
     を持つのだろうか。よく分からない事が多い。実際に試してみないと分からない。
 
     或いは read line で読み込む事ができる形式だろうか。
 
     →実際に動作を確認したところ、エスケープの除去は行われず \ も含まて補完文字
     列とされる様だ。よく考えてみれば、実際に挿入した時に複数の単語として解釈さ
     れてしまっては困る訳だから、確かにこの動作でなければならない。
 
     ? 末尾に \\ があったらどうなるだろうか → \\ であってもその後の改行は候補の
       一部と見做される様だ。
 
     さて、具体的にどの様に実装するのが良いか…という事を考えようと思ったが難し
     い。先ず標準出力を勝手に自分で COMPREPLY に代入するのは違う様に思われる。と
     いうのも、呼び出し元の compgen で -S suffix 等の加工をしてもらわなければな
     らないからである。だとすると、最終的な compgen の出力結果を解釈する時に行末
     の '\' で行を繋げる様に処理しなければならないのだろうか。
 
     そもそも改行を含むファイル名があった時に compgen はどの様な出力をするのか。
     うーん。普通にエスケープせずに改行を出力した様な気がする→確認した。確かに
     そうなっている。なので '\' が行末にあるからと言って勝手に振る舞いを変更する
     のも憚られる。
 
     或いは compgen の全ての機能を自前で模倣するという手もなくはない。その場合には区切りは全て制御下にある。
 
   * progcomp: -F もしくは -C で生成した候補に対しても dir/ 等の suffix を付ける
     必要はあるのか。もし付けたければ completion 側で付けるべきなのではないかと
     いう気がする。
 
 2021-05-04
 
   * robustness: ble.sh では exit を上書きしているが set -o posix の時にはそれが
     無効になる。
 
   * util: builtins 復元、function#advice, etc. において functrace 属性は復元し
     なくて良いのだろうか。復元という事を考えるとやはり declare -pf を使う必要が
     あるのかもしれない。
 
     bash version, posix mode も含めてどういう方法があってそれぞれどの様に振る舞
     うのか調べる必要がある。
 
     取り敢えず問題が起こらない事を確かめた上で getdef 自体を更新するのが良いの
     ではないか
 
     →と思ったが実際は複雑である。getdef を使って関数を別名にコピーするのに使っ
     たりしているが、その時に先頭部分だけを置換している。しかし declare -ft の部
     分についても関数名を置換しなければならない。そういう事になるぐらいであれば、
     個別に declare -ft かどうかを判定して、改めて declare -ft で属性を付加し直
     す様にしないと行けない筈である。
 
 2021-05-03
 
   * rlfunc: fetch-history
     8f485ff8 - new readline "fetch-history" bindable command
   * rlfunc: C-x s, spell-correct-word
     6be3a741
   * rlvar: enable-active-region
     b1965836 new "enable-active-region" readline variable
   * rlbind: prior, next
     65822e50 - alias expansion fix in case statements
   * vi-undo
 
   * 5.2: LS_COLORS *.readline-colored-completion-prefix (bash e59452c7)
 
     rlvar colored-completion-prefix が on でかつ LS_COLORS の中に
     *.readline-colored-completion-prefix という項目がある時、共通一致部分の着色
     をそれに書き換える。
 
     実際に bash の振る舞いを調べてみようとしたがどうも有効にならない。調べてみ
     ると、_rl_color_ext_list が初期化されていない。これを初期化する為には何かす
     る必要があるのだろうか。_rl_parse_colors という関数で初期化しているようだが、
     この関数はどこから呼び出されているのだろうか。
 
     うーん。分かった。readline.c:1327 で呼び出している。これは初期化部分である。
     つまり、readline を初期化するよりも先に LS_COLORS を設定しておく必要がある。
     更に言うと、bind 'set ... on' も事前にやって置かないと駄目。というか
     colored-stats の時点で同じ問題があったのではないか?
 
     これは単純に _rl_color_ext_list が空だったらその場で _rl_parse_colors の呼
     び出しを試みるという事と、それから LS_COLORS の値が変更される時に
     _rl_color_ext_list をクリアする。と思ったが、これだと LS_COLORS が空の時に、
     毎回 _rl_parse_colors が試みられて非効率的である。
 
     * 後、_rl_colored_stats = 0 が _rl_parse_colors の中で設定されている。
 
 2021-04-30
 
   * ble-reload: blerc 外のユーザー設定の保持
 
     外部のツールが呼び出した blehook PREEXEC+=... 等は別枠で保存しておくべきで
     はないか。そうしないと ble-reload した時に設定が消えてなくなってしまう。或
     いは、blerc の中から呼び出したか外から呼び出したかで取り扱いを変える。blerc
     の中で呼び出した設定は消えてしまっても仕方がない。一方で、blerc の外側で実
     行した物については保持しておくのが自然なのではないか。
 
 2021-04-29
 
   * robustness: main/init: readonly POSIXLY_CORRECT されていたらどうするのか。
 
     少なくともどちらの側の設定であっても ble.sh 的には困る。
 
     然し、readonly まで気にし始めるとあらゆる変数名で問題が起こるので気にしても仕
     方がないのかも知れない。せめて全て大文字の変数だけが readonly になっていると
     いう事を要請するのが妥当だろうか。ローカル変数で大文字を使っているというと
     KEYS WIDGET ARG FLAG REG 辺りは危ないかもしれない。
 
     然し、ここまで行くと「ユーザーが自分で変な事をしたのだから責任は持てない」と
     いうレベルの事の様な気がする。
 
   * robustness: main/init: 最初の bash version 判定も alias 対策可能かもしれない?
     然し、return/exit が上書きされる場合等も考えると難しいかも知れない?
 
   * robustness: "builtin read -e" 対策?
 
     これは今迄考えて来なかったが関連する考察 #D1520 があったので記録として残し
     ておく。但し、纏めた物を眺めるに総じて困難である様に思われる。
 
     a set -o emacs / set -o vi の切り替えを利用して read が使える様にする。つま
       り、ble.sh は裏側の keymap に bind して、ユーザーコマンドを実行する時に反
       転させるという方法。この方法には問題が多い。
 
       x 全てのユーザー関数 (補完関数、プロンプト、trap、blehook 等) で keymap
         を反転する必要があるのではないか。
 
       x ユーザーが emacs/vi keymap を切り替える rl bindable function を実行する
         と結局 ble.sh の bind している keymap が表に出てきてその時点で制御不能
         になってしまう。勝手にそういった binding を削除するのも非現実的な気がす
         る。
 
       x bash の version によっては keymap を切り替えると bind -x が中断した様な
         気もする。
 
     b trap DEBUG 等を使って builtin read -e が呼び出されるのを検出して、ble.sh
       で wrap した処理を行ってからそのコマンドの実行をスキップする。この方法に
       も色々の問題がつきまとう。ちゃんと透過的に対応できるかというと困難の気が
       する。
 
       x DEBUG のコストがある。
 
       x ユーザの設定した DEBUG の管理が面倒。結局 trap DEBUG を透過的に利用でき
         る様にする枠組みは完成していない。(これはその枠組さえ完成すれば余り気に
         しなくても良いのかもしれない)
 
       x 本当に実行するコマンドを入れ替える事が可能なのだろうか。例えば builtin
         read -e の呼び出し元から見て、本当に関数実行が入れ替わった様に見えるの
         か。exit status はどうなるのか。これは実際に実験してみないと分からない。
 
       x DEBUG の BASH_COMMAND を用いて元のコマンドを本当に再現できるのか。例え
         ば $1 等が使われていた時にその内容を取得する事は可能なのか (BASH_ARGV
         を有効にしておかなければならないのか? ユーザーが設定を変更してしまった
         らどうなるのか)。また、引数の境界等もちゃんと BASH_COMMAND を見ただけで
         分かる様になっているのか。これも色々実験しないと分からない。
 
     c builtin read -e に入った後で ble.sh の widget が呼び出されたら良い様に
       状態を adjust して widget の振る舞いを変更できないだろうか。
 
       x C-c に明示的に対応して、C-c が呼び出された時には設定を restore して抜け
         る様にする。これは面倒なだけで処理としては十分可能である様な気がする。
         但し、外側に SIGINT を伝播する必要はあるのかもしれない。
 
     d ユーザーがコマンドを実行する度に realine 設定を完全 unbind して、終わったら
       再度 bind し直す。でも、これは文法エラー等によってコマンド実行が中断された
       時に、ble.sh session に復帰せずに通常の readline の状態に落ちてしまう。
 
 2021-04-06
 
   * logout も exit と同様に置き換えるべきなのではないか。
 
   * prompt を評価する時に $var が local 変数に被覆されている。
 
     然し $var だけならば良いが $() で呼び出された関数が更に内部で変数を使用して
     いる可能性等を考えると下手に変な調整はしない方が良いかもしれない。PS1 に直
     接 $var と記述するかしないかで $() の内部でも変数が見えるかどうかが切り替わ
     るというのは不自然すぎる。それならば ble.sh 自体が変数を定義するのでそれに
     よって被覆されてしまうと説明した方が自然である。
 
     グローバルでない変数を列挙する方法は存在するだろうか。
 
 2021-04-26
 
   * keymap/vi: vi における既定の keymap を imap ではなく nmap にするオプション
 
     現在の振る舞いではコマンド実行後に nmap であれば insert-mode に戻すという操
     作をしていた筈である。その箇所を書き換えて、オプションに応じて変更先のモー
     ドを切り替える様にすれば良い。それと ble-attach した時の最初の設定を行った
     直後に、自動的に nmap に移動する様にする処理を加えれば良い。
 
   * ble-bind: ble-bind -P で、他のオプションで指定したタイプの binding だけを出力する?
 
     % -T を指定すれば -T の設定を出力する。--cursor を指定すれば --cursor の設
     % 定を出力する。cmap 関連のオプションを指定すればそれに関連する設定を出力す
     % る。と思ったが、-T, --cursor, --csi, -k, etc. はそれぞれオプション引数を
     % 取るので、引数読み取りの段階で -P の後で振る舞いを変更する様にしなければ
     % ならない。これはコマンドライン引数の解釈として不自然である。
 
     別のオプションを使って dump する内容を選別するのが良い。例えば、
     --filter=timeout:cursor:csi:cmap:etc 等である。
 
   * decode: [refactor] _ble_decode_KEYMAP_kmap_@ ?
 
     いきなり KEYMAP ではなくてその前に何か挟みたい。例えば
     _ble_decode_kmap_KEYMAP_@ に変更する等。この場合には KEYMAP の名称として紛
     らわしい物が定義された時に問題になるのではないか。前の実装で KEYMAP の直後
     に固定の文字列を挿入していたのは、末尾から KEYMAP 以外の部分を一意に切り取
     る事ができる様にする為の設計だったのではないか。
 
     現在の実装は末尾からの一意性が保証される様になっている。_kmap_ が他で使われ
     ていない限りに於いて、ちゃんと一意になっている。然し、名前空間として変であ
     るというのも分かりにくい。なので、 _ble_decode_kmap_KEYMAP_xxxx_yyyy にして、
     xxxx には yyyy に絶対に現れない文字列を指定すれば良い。例えば data 等。
 
 2021-04-04
 
   * history auto-save
 
 2021-03-21
 
   * robustness: 様々な基本的な変数が readonly でグローバルに固定されていたらど
     うするのか。ロードした瞬間に様々な良くない事が起こる気がする。然し、それを
     言い出すと、bash-completion や他のフレームワークにも強い影響が出てくるので、
     ble.sh だけが対応しても仕方がないという考え方もできる。
 
 2021-03-07
 
   * edit: キーボードマクロで "M-d" が "M-d d" と記録されてしまっている
     vi でも emacs でも同様に記録されてしまう。
 
 2021-02-28
 
   * canvas/trace: wordwrap に対応する。つまり、単語の途中で改行しない様にする。
 
     これは今の所具体的な用途もないので取り敢えずこの儘にしておく。
 
   * canvas/trace: より詳しい justify の仕様について設定できる様にする。
 
     #D1494 の案では "SEP*WEIGHT FILL SEP" を単位として指定するという話だったが、
     これはやはり不自然な感じで分かりにくいのでもっと分かりやすい指定方法を考え
     るべき。
 
     例えば、最低幅1重み2 '%1.2S{FILL}' という具合にするなど。こうすると % を
     SEP に指定できないし } を FILL に指定できないが使う機会があるとも思えない
     ので気にしない。或いは '%{1.2SFILL}' とする? うーん余計に分かりづらい。或
     いは printf strftime を真似て '%1.2(FILL)S' という具合にする。
 
     空白は既定で '%1.0( ) ' に相当する。その他の文字は '%0.0()X' に相当する物
     とする。
 
     2021-03-08 というより、各 sep の性質として登録するよりも、\q{...}  を通して
     設定できた方が自然なのではないか。
 
     \q{hfill w=2 fill=...}... という具合に。その場合には \1\2 と同様に特別なシー
     ケンスで fill を表現する必要はある。OSC か其処らを使えば良い気がする。或い
     は ANSI seq に何かあった気がしないでもない。
 
 2021-02-27
 
   * /dev/tcp/... についても特別に着色を行いたい。
 
     例えば < /dev/tcp/.../.. において正しいパスであるのにも拘らず、存在しないファ
     イルとしてエラーが検出される。
 
 2021-02-24
 
   * canvas/trace: trace の g0 は後で合成するのではなくて \e[m の段階で設定する
     べきなのではないか。
 
     後、g0 という名前も余りよくない気がする。他の x0 y0 からの連想で初期の g の
     値という雰囲気が出てしまう。然し一方で sgr0 からの連想で背景色という雰囲気
     もある。実際に別の場所では sgr0 を指定する事によって背景色を設定できる様に
     なっている。
 
     名前はさておきどの様に振る舞うのが良いのか。例えば \e[39m で既定色に戻すと
     いう操作の場合は本当に端末既定色に戻すべきなのか、或いは g0 で指定した色に
     するべきなのかというのは微妙な所である。g0 で指定した色にするべきの気がする。
 
     一方で、下線などの属性に関しては g0 で指定したものから解除できる様にするの
     が自然な気もするし、或いは g0 で指定した物は常に設定されているのが自然の様
     な気もする。どちらが良いのかは分からない。やはり現状の実装で良い様な気もす
     る。
 
     うーん。単に設定のあるなしという捉え方ではなくて下線ありと下線なしという独
     立したスタイルがそれぞれあるのだと思えば、やはり g0 を毎回上書きするのでは
     なくて、\e[m 等に対応する操作の時にだけ g0 の値に設定するというのが正解の気
     がする。
 
 2021-02-23
 
   * util: カーソルが bottom-dock にいる時の vbell の座標計算
     Ref #D1495 ... 取り敢えずの対策
 
     現在の実装は vbell が sc..rc を自由に使える前提になっている。しかしカーソル
     が bottom-dock に停泊している時に vbell が来るとvbell によって floating
     panels の位置が分からなくなってしまい、表示がずれてしまう事になる。
 
     同じプロセス (親シェル) の中で vbell を処理している場合には、一旦 floating
     panel の位置に戻ってから sc..rc をしてそれから再び bottom-dock に戻るという
     手順を踏む事によって問題を回避できる。然し、サブシェルの中にいる場合には現
     在の最新の配置情報にアクセスできないのでこの方法は取れない。
 
     現在は取り敢えずカーソルが bottom-dock に停泊している事はないとの想定で
     sc..rc を実行しているが、例えば info_display=bottom にして vi_cmap を使って
     いる時などにこの前提が破れてしまう。
 
     [解決方法]
 
     ちゃんと実装する為には、親シェルで全ての描画を行う様にする必要がある。その
     時に問題になるのがどうやって visible-bell の消去のタイミングを親側で決める
     かという事。idle を使う方法は bash-4 以降でしか使えない。シグナルを使う方法
     には余り頼りたくないが、現実的にはそうするしかないのだろうか。bash-3 と
     bash-4 で実装を切り替えても良い。何れにしてもサブシェルと通信を行う枠組みを
     整える必要がある気がする。
 
 2021-02-22
 
   * cavnas: 描画の最中で status が高さを取得する時に textarea の内容を削り取る可能性がある
 
     現在の render 中に配置を決定する仕組みは問題があるので再考する必要がある。
 
   * cygwin: 下部での IL が動かない旨を報告する?
 
     後 DA2 応答をしてくれないか頼みたい。
 
     $ printf 'Line %s\n' {0..100}; /bin/sleep 1; printf '\e[L'; /bin/sleep 1
 
     最下部で DL を実行した時にも何か変な事が起こる。
 
     $ printf 'Line %s\n' {0..100}; /bin/sleep 1; printf '\e[M'; /bin/sleep 1
 
 2021-02-13
 
   * edit: C-x e に続いて e を連続して押した時にマクロ実行を繰り返す様にしたい
 
   * 実は bash の read -e は C-r でコマンド履歴を参照できる。ble.sh では read 専
     用の履歴を独立に管理しているが、コマンド履歴にもアクセスできる様にするべき
     なのでは。と思ったがやはり何だか微妙な気がする。
 
     read 専用の履歴を別に管理するというのもありなのではないかという気がする。
     その場合には保存場所は何処にするべきだろうか。
     ~/.local/share/blesh
     ~/.config/blesh
     ~/.cache/blesh
 
     https://github.com/fish-shell/fish-shell/issues/744
 
     fish は過去に config に置いていてユーザの文句によって local/share に移動し
     た様だ。然し、local/share はそれはそれで何だか変な気もする。
 
   * gnuplot など他のコマンドに対して ble.sh によって編集機能を提供する事は可能
     だろうか。少なくとも pty を自分で開いてその中で gnuplot を起動する必要があ
     る? 或いは、gnuplot のリンク先の readline library を勝手に書き換えて bash
     を起動させて、更にその中で ble.sh を使って readline 関数の振る舞いを模倣す
     る?
 
     rlwrap 等を使うという手もある? rlwrap のじっそうはやはり pty を開くという物
     のようである。rlfe という物もあるようである。
 
     どうも gnuplot の場合には普通に gnuplot & で起動しても操作できる様
     な気がする。ble.sh で _ble_syntax_lang=gnuplot として更に
     exec:gnuplot を提供したらそれだけで普通に動く様な気がする。
 
     - ble-edit/is-single-complete-line で syntax:bash を呼び出している
       のをsyntax:$_ble_syntax_lang として呼び出す様に変更する必要があ
       る。他にも accept-line が is-complete を呼び出している。
 
     * shell-expand 系統の widget は gnuplot モードでは無効にしたい。
     * command-help 系統の widget も gnuplot モードでは別の実装にする。
 
 2021-02-10
 
   * main: 関数内で引数なしで source すると関数の引数がそのまま source の中から
     見える。これらを区別する方法はあるだろうか。
 
     うーん。shopt -u extdebug であれば BASH_ARGC の数が二種類の source の仕方で
     異なるようである (但しその具体的な数は bash-5 から変わっている。更に入れ子
     source や関数呼び出しなどが絡んできた時にどうなるかは不明である)。然し、
     shopt -s extdebug の時には両者は同じになる。
 
 2021-02-06
 
   * tui: TreeView
 
     以下の様な物があるのを見つけた。
     https://gitlab.com/TheDalaiAlpaca/saturnon/-/blob/master/saturnon
 
     実際どんな物かは確かめていないが、TUI 要素としてファイルピッカーは定番である。
 
     その基礎として先ず TreeView を実装するというのは一つの方向性。TreeView は
     List の拡張として作成するのが自然であろう。List の各要素の高さを変えられる
     様にして、更に中にそれぞれリストを保持するようにしたものと解釈できる。問題
     になるのはリスト項目が増えてきた時に高さの累積計算が重くなるという事。シェ
     ルで実装すると成ると重み付きB木の様な複雑なデータ構造にもしにくい。或いは、
     本気で重み付きB木をBash上で実装するという方向性もあるのかもしれない。
 
     Midnight Commander と同等の機能を ble.sh の内部で実装するというのも
     demonstration として良いのではないかという気がする。
 
 2021-02-05
 
   * 他の bash プログラム
 
     * https://stackoverflow.com/q/41043916/4908404
       history 候補を自動的に表示する可能性について議論している
 
       上記 StackOverflow の質問で提案されている。Google Chrome の search bar の様に、
       幾つか文字を入力した時点でもう履歴から項目を拾って幾つか表示し始めるという可能性。
       これは fzf の領分である様な気もするが shell integration を考えるとなかなか非自明である。
 
       というか普通の検索でも複数の候補を表示した方が分かりやすいのではないかという気がする。
       例えば或る一定以上の時間が経ったら一致する候補を列挙するなど。
       更に待っていると曖昧一致も列挙してくれる、という具合にする。
 
       2021-02-09 hstr が同様の機能を提供している。hstr の動作も参考にした方が良いのではないか。
 
     * https://github.com/dylanaraps/shfm/blob/master/shfm (file manager in POSIX shell)
       これは dylanaraps の fff の再実装
 
     * これは README に乗せるバッジの話
       https://img.shields.io/github/downloads/akinomyoga/ble.sh/total
       ダウンロード数の画像を生成できる様だ
 
     * Incremental parsing:
 
       ble.sh で行っている構文解析は特殊な物であるが如何にも既存の例がありそうである。
 
       検索したら以下の様な物があった。
 
       [Tree-sitter｜Introduction](https://tree-sitter.github.io/tree-sitter/)
 
       参考にしている論文を見てみると state matching で skip と書いているので、
       やはり単に途中から始めるというだけでなく途中で解析を中断するという考えも
       ある。寧ろ、完全に一致していなくても局所的な一致であれば解析を跳ばすとい
       う事を実行していると思われ、より積極的な最適化である。
 
       恐らく先にこれを見つけていたら ble.sh の構文解析の実装ももっと複雑になっ
       て、更になかなか完成しない日々が続いたのではないかという気がする。何事に
       も一長一短があるのであって既存の研究だって参考にできる部分と捨て置いて良
       い部分がある筈だが調べてしまうと完全に対応したく成るのが問題である。なの
       で、取り敢えず持てる範囲の知識で何かやってみるというのは大切な事なのであ
       る。
 
       oil 等は沢山調べすぎて行き詰まっているのではないかという気もする。或いは
       逆に何だか Python -> C++ translator を開発するなど変な方向に走っていて、
       それで余計に時間を取られているのではないか等等。やはりメンテナンス等を考
       えると、Python は prototype として捨て置いて、C++ で完全に書き直した方が
       得策なのではないか。Python -> C++ をずっと使う事にしていると、少しの機能
       追加で毎回 translator にも大幅に手をいれなければならず、結局メンテナンス
       が困難になる。特に第三者がコードに手を入れるのが極度に難しい。この構造を
       保持したまま続けるには最初に完全なる translator を作って、その後は
       translator の改良を行わないという決断が必要である (状況に応じて最適な翻訳
       が異なりうる事まで考えていたら完成した translator があってもきりがない)。
 
 2021-02-05
 
   * evaluate-path-spec (by 3ximus)
 
     evaluate-path-spec の改良に挑戦してみるという事なので。先ずは説明が必要である。
 
     * notilde に関しては eval の側で処理するべきではないか
     * 後で全体 path 以外については single を加える様にお願いする
 
     2021-12-31 詳細は以下にある。
     https://github.com/akinomyoga/ble.sh/issues/82#issuecomment-773487368
 
     83.sh に実装を入れて試してみる事にする。
 
     と思ったが具体的にどの様に実装すれば良いのだろうか。先ず初めに短い物から長
     い物まで順番にパスを構築する。その後に一番長い物から順番に一致を試みる。一
     番長い物が一致すれば、後はその得られたパスを既存のパターンに当て嵌めれば良
     い。と思ったのだが、どうやって当て嵌めるのだろうか。
 
     * extglob まで絡んで来ると余計に分からなくなる。と思ったが extglob は
       simple-word の要件を外れるのでここでは考えなくて良い。
 
     うーん。glob を解釈して正規表現に変換すれば行けるかもしれない。或いは、
     ${path#$pattern} または ${path%$pattern} 等として削って行けば良いのでは? と
     思ったが、$pattern の場合には * も一致してしまうのではないか。。
 
 2021-02-03
 
   * edit: 例えばファイル一覧を表示する機能を付けても良いのではないだろうか。
 
 2021-02-01
 
   * complete: complete_timeout_compvar でタイムアウトした単語の glob 文字を quote しない?
     Ref #D1457
 
     現在はグロブ文字も quote して COMP_WORDS と COMP_LINE を構築している。例え
     ば **/*.txt に時間がかかった時に COMP_WORDS には "'**/*.txt'" という文字列
     が格納されるが、これは本来 "**'/'*'.txt'" であるべきなのではないかという事。
 
     * 一方で、補完関数の方が複雑な quote に対応しているかという問題もある。
 
     * また、ここで quote しないと結局補完関数の方でも時間がかかってしまうのでは
       ないかという恐れがある。
 
     という事など考えると、取り敢えずは完全に quote する実装にしておく。後で気が
     向いたらまた考える。
 
   * highlight: failglob の時の a/b*/c/d.txt の着色が最後のファイル名になっている。
     本来はどの時点で failglob になるか判定して着色するべきなのではないだろうか。
 
 2021-01-28
 
   * progcolor: ble/syntax/progcolor/eval-word を着色を跨いでキャッシュできないか
 
     特に展開結果を何処かに保存しておきたい。新しい配列を用意するか、或いは hash
     にして記録するか。
 
     a hash にして記録すると一度評価した単語を再評価する機会が失われる。ファイル
       が追加・削除された時に更新されなくなってしまう。
 
       やはり、単語単位でやはりキャッシュしたい。そうすると shift にも耐えうる仕
       組みにしたい、という事で新しい配列を用意するか、或いは既存の配列に格納す
       るという方法になる。
 
     b 新しい配列を追加する
 
       また shift 等の操作が増える。面倒である。
 
     c 既存の配列に要素を追加する
 
       既存の配列に格納する場合には任意の文字列を含める事ができないので、補助配
       列にデータを格納する事にしてその添字を既存の配列に入れるという手がある。
       特に単語に id を振っておけば今後の word に関するデータ拡張にも使う事がで
       きる。
 
     →これに関しては ble/syntax:bash/simple-word/eval の側でキャッシュする様に
     したので、今の所はここでは対応しなくて良い気がする。当初は simple-word/eval
     では非常に短期のキャッシュしかしない方向を考えていたが、ファイルシステムが
     そう頻繁に変わる訳でもないので、取り敢えずは行毎にキャッシュを保持する事に
     した。なので、simple-word/eval のキャッシュは単語よりも寿命が長いので単語毎
     のキャッシュは今の所は考えない事にする。
 
     * 但し、やはりファイルシステムの変化に追随したいという事であれば、適当にキャッ
       シュを更新する必要がある気がする。或いは、globpat を含む様な場合にのみキャッ
       シュを行うというのでも良い様な気がしている。
 
     * また、ここでの実装手法は例えばエラーメッセージの記録等の場合にも使えるの
       ではないだろうか。という気がする。
 
 2021-01-22
 
   * highlight: 引数が沢山あると cygwin で滅茶苦茶遅い
 
     これは様々な種類のパス名展開を試そうとするのが原因だろうか。
     command 名と同様にキャッシュする様にしても良いのではないだろうか。
     でも少しずつ微妙に異なる引数が沢山ある場合には結局遅い。
     それよりは着色自体の高速化について考えた方が良いのではないか。
 
     * chat でも遅くなるかどうかについて確認する。
       やはり微妙に遅い様な気がする。
 
     何が遅くなっている原因化について確認する必要がある。
     例えば fork している可能性はあるだろうか。
 
 2021-01-08
 
   * syntax: 算術式の quote が変である
 
     x echo $((a['$hello'])) の $hello は展開対象なのに着色されない。
       →然しこれは文法上の問題なので寧ろ着色しない方が自然である様に思われる。
       (これは eval の引数を着色するのかという問題にも通じる)
 
     x ((a["$index"])) がエラー着色になっている
       →どうもこれは bash-5.0 から振る舞いが変わったという事の様である。
 
     x bash-5.1 からは (()) でも ' は quote ではない。
 
     x 更に言うと a['...'] の ' は a が連想配列の時には必ずしもエラーではない。
       現在はエラー着色になっているがこれは修正するべきの気がする。
 
 2020-12-19
 
   * Note (#D1435): blehook WINCH を処理している最中に終了したユーザのジョブがあ
     るとその通知が画面に表示されない可能性がある。これは実際に起こりうるのかど
     うか確認していない。
 
 2020-12-14
 
   * progcomp: progcomp で生成された補完候補を現在 quote している。
 
     * 生成された候補が既に quote されている場合や展開を含む場合に、
       意図したのと異なる結果になってしまう問題がある。
     * 更に既に入力済みの部分に一致しなくなるので遡って書き換わる可能性もある。
     * 生成された候補が複数の単語に分かれる場合に、
       それが blesh の quote によって一つに結合されてしまう問題もある。
 
     理想的には生成された候補を改めて simple-word/eval して、
     その結果に基づいて単語を再度挿入し直すという事が考えられるが、
     x 全ての候補に対してこれを実行する事を考えると処理が重くなってしまう。
     x また、\**\* 等を展開すると *** になってしまうので
       その quote を復元する方法についてもちゃんと考えなければならない。
 
     或いは simple-word element を一つずつ抽出して処理すれば良いのかもしれない。
 
 2020-11-30
 
   * tui: face editor の TUI の様な物を作っても良いのかもしれない [#T0007]
     というより fish の Web interface の様な物を TUI で提供しても良いのでは。
 
     2021-04-25 @Alyetama から似たような提案を受けた。
     https://github.com/akinomyoga/ble.sh/issues/80#issuecomment-826194833これは
     初期設定 wizard の様な物を想定している様だが、TUI config ではもっと自由にい
     つでもどの設定でも選んで設定できるのでより自由度は高い。そう言った物でも良
     いかという事を一応確認はしてみる。
 
     作るとしたら先ずは Color Picker?
     その前に layout engine? 或いは画面の切り替え?
 
     Window system がどうのこうのという計画があったような。window system に関し
     ては内部バッファだとかスクロールだとか textarea だとか様々の物を内包する物
     であった筈で、此処で必要になる物は其処まで複雑な物ではない。でも一緒に実装
     してしまっても良い様な気もする。
 
     - Windows system に必要な物。control, window, layout-engine,
       background-buffer, redraw, resize, etc.
 
       既にある panel, textarea 等を拡張する感じに考えても良いのかもしれない。但
       し、これ以上の ble.sh の肥大化を避ける為に canvas ではなくて新しく
       lib/core-forms.sh 的な物を追加して其処で実装するのが良いのではないか。
       textarea に関しては、forms が或る程度形になってから対応するという形で良い
       気がする。
 
       control に属する変数の記録方法? これは textarea と同様にしたいが、
       textarea の方も forms に対応しようとすると調整が必要になると考えられるの
       で、最初は既存の枠組みに捕われずに実装するので良い気がする。
 
     - window: overlay を実現する方法として二つの可能性が考えられる。
 
       a redraw 関数の方で clip 等を処理する方法。
 
         これは各 control の実装が複雑になってしまう。というより任意の clip
         region の形状に対応しようとしたら非現実的な実装になってしまう。
 
       b もう一つは Window の側で buffer を内部に保持し、最終的な描画の際にそれ
         を適当に clip して出力する方法。
 
         これに関しては内部 buffer の表現方法に工夫が必要になる。
 
     取り敢えず何も考えず少し実装してみた。clip に関しては redraw の側で適当に処
     理する事にした。また、trace に於いても clip 機能を実装した (#D1493)
 
     invalidate 範囲を記録できる様にしたい。
 
     更に、要素のサイズが変更された時、移動した時には親の該当範囲も一緒に
     invalidate する必要がある。
 
 
     自身の内容が変化した時、自身に被っている別の要素も一緒に更新する必要が出て
     くる事に注意する。
 
     a 上に物が被っていない時には clip 領域を勝手に広げて描画しても良いのではな
       いか。描画範囲を広げても良いかどうかについては render.draw の呼び出し元か
       ら指定できる様にすると良いのかもしれない。
 
     c 或いは、そもそも被らない様にするか、被っている時には更新しない様にすると
       いう手もある。
 
     d 或いは、render.draw の呼び出し元で一旦シーケンスを取り出して、その上でそ
       れを再度 trace によって clip するという手もあるかもしれない。然し、これは
       描画内容が大量にある場合にとても遅いので実は避けたい。
 
 2020-11-20
 
   * bash: declare -c や ${var~} 等は 5.2 で削除するとしているが本当だろうか
 
 2020-11-13
 
   * complete: bash progcomp と ble.sh progcomp の競合問題
 
     現在は complete:* の方が builtin complete の設定よりも優先される様になって
     いる。これは ble.sh がロードされていない時はbash-completion を使い、ロード
     されている時は ble.sh 様に特化した補完設定を使うという状況を考えると自然で
     ある。
 
     然し一方でユーザーが自分の好きな設定を builtin complete で設定してもそれが
     反映されないという問題が生じる。やはり builtin complete の方を優先させるべ
     きだろうか。或いは、complete:cd は既定ではロードしない様にして、contrib か
     何かに入れてユーザにロードさせる様にするのが良いのではないかという気もする。
     然し、ユーザにロードさせるとしてもコマンドを一つ一つロードするのではなくて、
     まとめてロードするという状況も考えられる。その場合には、やはり builtin
     complete と complete:* の競合が起こってしまいどちらを優先させたら良いのか分
     からなくなる。
 
     或いは ble.sh に特化した設定も builtin complete 経由で呼び出す様にする?
     しかしそうすると ble.sh から ble-detach した時に動作しなくなってしまう。
 
     attach/detach の際に設定を保存・復元するという方向性も考えられる。
 
     complete を上書きして両方の設定を行える様にするという手もある。この場合には
     attach/detach する時に既に設定した内容を読み取る等の工夫が必要になる?
 
 2020-11-11
 
   * syntax: $HOME 等の変数展開があるパスに対して simple-word/eval が重い問題
 
     中でグローバル変数の復元等の複雑な処理をしている。一回呼び出すだけならば良い
     が $HOME/.mwg/src/ble.sh/archive/layers ... 等の様なパスの着色で各ディレクト
     リの階層で展開を試みている場合に、何度も呼び出す事になると遅さがかなり目立つ
     ようになる。
 
     単語着色では determine-separated-path -> locate-filename ->
     highlight-pathspec という具合に三段で処理していて各段で毎回 eval しているの
     で特に重い。これは処理を統合して高速化する余地もある。コードが汚くなるという
     問題はある。よく考えたら現在の実装では locate-filename は特に eval は実施し
     ていない。単に : で区切っているだけである。なので locate-filename に関しては
     気にしなくても良い。
 
     或いは複数のパスを一度に eval する機能があっても良いのかもしれない。その場合
     に結果をどの様に返すのかは難しい。複数単語に展開される事を考えて既に一つの
     eval の時点で ret が配列だからである。各パスの最初の単語だけを返す事にするか、
     或いは全ての単語を全部混ぜて一つの配列に返すか。一つの配列に格納する場合には
     各パスに対応する index の範囲を返す事ができるがインターフェイスとしては分か
     りにくい。
 
   * bashbug: builtin で while という名前の builtin を load すると他の builtin が
     使えなくなる。
 
     ? 使えなくなるのは、同じ dll の中の物のみなのか或いは全ての dll の loadable
       builtin が使えなくなるのか。
 
     ? while 以外にも問題を起こす名前は存在するか。
 
     ? 影響を受ける builtin はキーワードと一致する名前の物のみか或いは全てか。
 
 2020-11-07
 
   * complete: PATH=path1:path2:path3 の補完
 
     PATH=path1:path2:path3 の時に着色が最後の要素にしか適用されないし、また補完
     は全然働かない。全く動かないのならばまだしも中途半端に動くのは変なのでちゃん
     と対応したい。
 
     →着色に関しては #D1409 で議論する。
 
     complete に関しては元の bash ではちゃんと動いているので尚の事問題である。
 
   * highlight: 条件コマンドの中での着色が効かない。着色しても良いのではないだろうか。
     今まで実装していなかったのは正しい文法解析や入れ子などの処理が面倒だったから。
 
     今確認してみると 条件コマンドの中でも ( && || ) などは特別な意味を持つ様であ
     る。更に & や | を使うとエラーになる。<< 等のリダイレクトもエラーである。必
     ずしも空白で単語が区切られる訳ではない様なので、これに関しては文法解釈のレベ
     ルで修正が必要になる。
 
     今試すと ; も途中に現れると区切りとして取り扱われてエラーになる。
 
     * |&;<>() は特別に取り扱う必要があるという事。単体の < と > に関しても正し
       い演算子の文脈に現れれば大丈夫だが、二項演算子の現れない場所で使うと構文
       エラーになる。この様な構文エラーまでチェックする必要があるだろうか。或い
       は演算子の結合まではチェックしない事にするか。
 
     * 括弧の途中で ]] が現れた場合にもエラーになる。
 
 2020-11-06
 
   * complete/mandb: progcomp で生成したオプションに関してもできれば desc を表示する様にしたい。
     progcomp に候補を生成させてもしオプションが含まれていて、
     かつそれが mandb の中に含まれているという事が分かった時に desc-raw を表示する。
 
     * git 等の場合には man git で得られるオプションと
       サブコマンドで得られるオプションは異なるので注意する。
 
   * complete/mandb: bash の場合にはビルトインコマンドのオプションまで混ざって列
     挙されてしまって駄目。bash 固有のオプションについてまとめたファイルを用意し
     ておくべきである。
 
     bash builtins のオプションに関しては builtin ... --help を使用すれば取得でき
     る。これはこれでまた解析の為のコードを書かなければならないが、bash の
     builtin に限れば形式が定まっているので解析のコードを書くのは難しくはない。
 
   * complete/mandb: 何と man git は .PP ... .RE 4 ... .RS でオプションを説明している。
     この様に .TP を用いない様な場合にも対応するべきなのだろうか。
 
   * complete/mandb: 同じ意味を持つオプションについて。
     同じ意味を持つ複数のオプションを分ける時に、
     分けてから sort するのではなくて sort してから分けるべきではないか。
     同じ意味を持つオプションは連続されて表示されて欲しい。
 
 2020-09-07
 
   * complete: メニュー絞り込みが働いている状態で単一確定ができない場合がある
 
 2020-09-03
 
   * main: attach 戦略再考 [#T0004]
 
     attach の戦略に関する議論は以下にある。
       #D1382, #D1124, #D0940, #D0737
 
     | a 即attach。PS1 表示
     |   x PS1 が後で変更された時に問題。
     |   x 後の設定の出力が消滅する
     |
     | b 即attach。PS1表示はする。出力抑制はしない
     |   x PS1 が後で変更された時に問題。
     |   x 後の設定の出力と混ざる
     |
     | c 即attach。PS1表示はpromptまで遅延
     |   x keymap初期化に時間がかかる
     |
     | d 即attach。PS1表示する。出力は記録して後でdump
     |   x 後の設定が対話的なインターフェイスを起動した時に問題
     |   x 後の設定が /dev/tty に対して出力したら防げない
     |   x 後の設定が初期化進捗などを出力するとそれが実時間で反映されない
     |
     | e PROMPT_COMMAND。trap DEBUG/RETURN を用いて変更検知
     |   関連: #D1124, #D0737
     |   x DEBUG はコマンド直前の実行なので最終行での書き換えは防げない
     |   x RETURN は rcfile 末尾では発生しない
     |
     | f PROMPT_COMMAND の読み書きを hook する(非ネイティブな)手法はあるか?
     |   x ない
     |
     | g 他の hook/trap を用いて適切なタイミングを検出?
     |
     |   a EXIT はシェルが終了する時なので使えない
     |   b command_not_found も使えない
     |   c kill -USR2 $$ によるハンドラは?
     |     x 試すと rcfile 終了を待たずに次のコマンドですぐに実行される
     |     x kill ... & として別プロセスから投稿しても同様
     |   d bash (execute_prompt_command) を確認したが介入点は他になさそう
     |   e PS1 に kill 等を埋め込んで通知させる
     |     x これは PROMPT_COMMAND よりも信頼できない
     |
     | h PROMPT_COMMAND の中の最初のコマンドを DEBUG で検出?
 
     可能性があるとすれば h の手法である
 
     * trap DEBUG/RETURN の性質を熟知していないとユーザの設定した
       DEBUG/RETURN と干渉しない様にするのは難しいと考えられる。
       これは DEBUG/RETURN の枠組みを整えてからにする必要がある。
 
     rcfile で ble.sh をロードした時には rcfile を抜けた後の
     PROMPT_COMMAND 直前でアタッチを行う。
 
     * "PROMPT_COMMAND の最初のコマンド" は恐らく判定可能である。
 
       rcfile 及び最初の PROMPT_COMMAND 内にいる時は BASH_LINENO の最後の
       要素は0 になっている。rcfile 内にいる時は FUNCNAME の最後の要素は
       "source" になっている。更に bash-4.4 以降では rcfile から
       PROMPT_COMMAND に移る時に $- に s が追加される。
 
       PROMPT_COMMAND で何か実行するならば、最初のコマンドは必ず
       FUNCNAME[-1] != source になっている筈である。
 
     対話シェルで ble.sh をロードした時は "bashrc を抜けた直後" という戦
     略は使えないが、HISTCMD, ${_histcmd@P} を用いてユーザコマンドか
     PROMPT_COMMAND かの判定が可能である。
 
     * HISTCMD は ユーザコマンドを実行している時には $(history 1) の最初
       の要素に一致する。PROMPT_COMMAND を実行している時には常に 1 になる。
 
     * HISTCMD が unset されている場合には代わりに _histcmd='\!';
       "${_histcmd@P}" が使える (bash 4.4)。HISTCMD が unset されているか
       どうかは HISTCMD=A して値が変化するかどうかで判定できる。
 
 2020-08-27
 
   * 真面目に宣伝など考えるべきなのかもしれない。
 
 2020-08-03
 
   * README: bashrc 設定方法の更新
     関連: #D1382, #T0004
 
     最終的には bashrc の何処に ble.sh を記述しても動くようにしたい。取
     り敢えず、比較的信頼できる手法が確立するまでは README の load 方法
     はそのままにしておく。
 
   * macOS で遅いという話 (reported by tigger04)
     https://github.com/akinomyoga/ble.sh/issues/58
 
     チェック項目は…
 
     * complete -r の代わりに
       shopt -u progcomp を指定したら改善するか?
 
     問題になっている可能性がある処理は
     ble/complete/progcomp/.compgen の builtin compgen 経由で呼び出される。
     特にユーザの定義した関数・コマンドは以下の関数経由で呼び出される。
     - ble/complete/progcomp/.compgen-helper-func
     - ble/complete/progcomp/.compgen-helper-prog
 
     上記の関数に benchmark を設定して stackdump なり何なりを計測する?
 
     ble/function#advice \
       around ble/complete/progcomp/.compgen-helper-prog \
       ''
 
     * 対策としては auto_complete の時には progcomp を実行しない
       というオプションを追加するというのが一つの可能性。
       bleopt complete_auto_progcomp=1 という事にするのが良い。
 
       実現可能性について。
       現在の呼び出し文脈が auto_complete かどうかを判定する必要がある。
       確認してみると comp_type に auto を含めている様である。
       実際にそうなっているのか確認する。
 
     情報をメールで貰った。
     メールではどの期間だけ complete -r を除いていたか分からないとしているが。
 
     2020-08-05 05:12:50 IST
     2020-08-05 05:13:27 IST
     2020-08-05 08:43:54 IST
     2020-08-05 08:43:57 IST
     2020-08-05 11:02:53 IST
 
     まあ、どの期間だけ有効になっていたのかという情報は実はそんなに重要ではない。
 
     眺めていて気づいた事。
 
     最後にユーザが入力を行ってから auto-complete が起動するまでに一定の時間がかかっている。
     大体 200ms の様な気がするが、しかし時間帯によって変わっている気もする。
     TAB 補完の場合にはこの delay が存在していない (0.06s) 事を考えると、
     これは history 補完にかかる時間という事だろうか。
     history 補完を無効にしたらこの delay は少なくなると判断して良いだろうか。
 
     補完が走らずに入力できている部分は history に match している入力であろう。
 
     どうも後半で時間がかかっているのは history の様に思われる。
     TAB 補完の時には 150ms 程度の遅延だが自動補完の時には 600ms に増えている。
     然し、その後で 200ms 程度に減少したりもしている。
     うーん。或いは単語の展開に時間がかかっているのかもしれない。
 
     * reject: 取り敢えず history 展開について高速化できないか確認する。
 
       | search-history-heavy について改善できないか考える。
       |
       | a 特に bash-5.0 以降では history -d range を用いて削除した上で
       |   history -p を実行すれば高速に過去の履歴を読み出す事ができるのではないか。
       |   →と思ったがよく考えたらどの範囲を削除したら良いのか不明である。
       |
       |   !string で一致させてその後その候補が当て嵌まらないと分かったとする。
       |   この時その候補以降の履歴項目を全て削除してから再度 !string で
       |   一致させれば良い様に思うが、最初に一致した候補が何番目の履歴項目か
       |   という情報がないのでどの範囲を削除したら良いのかが分からない。
       |
       |   a 例えば二分法で探索する? と思ったがこれだと二分の一の確率で
       |     サブシェルを生成しなければならない。明らかに非効率的である。
       |     或いは履歴展開に履歴番号も一緒に展開させる方法があったろうか。
       |     ない気がする。
       |   b やはり履歴番号を抽出できないかと思ったが、その様な履歴展開はやはりない。
       |     !string で一致させて単語指示子で履歴番号に置換できれば良かったが
       |     その様な単語指示子は存在しない。
       |   c 或いは、番号を指定しなくても一致した項目以降を削除する方法があれば良い?
       |     然し、history -d の引数はやはり数値であって履歴展開ではない。
       |
       |   この方針は難しいのではないかと思われる。
       |
       | b 或いは、history | grep を用いて最後に一致した項目を取り出す事ができるのではないか。
       |   但し、grep の時の問題は行区切りをどうするのかという事。
       |
       |   grep -z を用いれば NUL 区切りで判定する事が可能。
       |   然し、これは GNU extension である。安易には使えない。
 
       →うーん。調べてみたがちゃんと history search を呼び出す時に
       stop_check を指定しているのでユーザの入力があった瞬間に復帰する筈である。
       つまりこれ自体に時間がかかっていたとしても動きが遅くなる事はない筈?
 
       そもそも complete -r で解決したという事を考えると明らかに history は関係ない。
 
       然し、実際に timing log を見るとユーザの入力が待機されている…という事はない様な気がする。
       やはり現在の情報では history からの自動補完が問題になっていると考える根拠がない。
       従って、(不自然な方法を取ってでも) history 展開の高速化方法について考えるのは不毛である。
 
     * 再び報告があった。コンピュータ自体の処理が重くなっている時に動かなくなるという事らしい。
       普通に bash を動かしている時には問題ないという事を考えるとファイルアクセスが怪しい。
       ファイルアクセスしている箇所は沢山ある。特に着色のためのパス名展開である。
 
 2020-06-04
 
   * 行数が極端に少ない時の動作 (横スクロール)
     bash-5.1 では横スクロールモードに移行するそうだ。
 
     そもそも現状で一行しか使える行がない時に何が起こるか。
     実際に試してみると (line 1) という表示だけになって
     更にその上に何か表示しようとするのでまともに表示できない。
     2行の場合にもまともに動かない。vi-mode の mode name で 1 行消費している為である。
     3行の場合にようやくまともに動く様になるが、それでも vbell が上に被ってしまう。
 
     横スクロールまで実装しないとしてもまともに動作する様にはしたい。
     そもそも (line N) という表示を省略する様にする?
     現状の実装ではプロンプトは必ず表示する様になっている。
     然し、プロンプトを表示するからこそ変な事になっているのである。
 
     a 行数が 1 になった時にはそもそもプロンプトを表示しない?
       然し、それだとプロンプトが何も表示されなくなってしまってそれはそれで変だ。
 
     b プロンプトは固定で残りの部分で文字列を編集する?
       これだとプロンプトが画面よりも長い時に何もできなくなる。
 
     c プロンプトも一緒に横スクロールする?
 
       | これに対応する為にはプロンプトの内部の各文字の配置を追跡する必要
       | が出てくる。
       |
       | Bash native でも \[...\] を使っている場合にどうやって数えるのだ
       | ろう? という疑問が残る。
       | →bash の動作を見たところ、prompt も一緒にスクロールする。しかし
       | prompt の途中位置でスクロールが止まる事はない。つまり、prompt は
       | 全体が表示されるか全く表示されないかのどちらかである。
       | →prompt 自体の長さが画面の横幅よりも大きい時には、常に横スクロー
       | ルした状態になってしまい、コマンドの1文字目は常に '<' に隠れて表
       | 示されない状態になる。また表示の乱れも発生する。
 
       Bash は横スクロールによってプロンプトが表示されるか、全く表示さ
       れないかのどちらかの状態になる。中途半端にプロンプトが表示されて
       いる状態はない。プロンプトの長さが画面の長さよりも大きい場合は対
       応しきれていない。
 
     * プロンプトが範囲内に収まらない場合には何が起こるのか?
       プロンプトの trace の時に高さを制限していただろうか。
       →駄目。制限はしていない。そもそも制限する事自体が自然な動作なのかも分からない。
       リサイズした時に上に流れた情報を参照したいという場合を考えれば、
       プロンプトは制限せずに上に流れてしまうという振る舞いが自然の気がする。
 
     現在のスクロールの実装はプロンプト行の次以降で実施する前提になっている。
     つまり画面の高さが1行しかない場合には色々弄らなければならない。
     プロンプトが複数行ある場合にはそれだけ多く画面の高さが必要になる。
 
     * プロンプトの出力は気にせずに実施する。画面がスクロールしても気にしない。
       →これを実行するとその他の panel の描画位置もずれてしまう事になる。
       他のpanelの内容を上書きしないように事前に空行を挿入しようにも、
       空行を挿入した時点で他の panel の内容が反対側の端から流れてしまう。
       という事を考えると、行数が厳しい時には他の panel は全て潰すのが現実的。
 
       潰す条件がプロンプトの高さが一行に収まりきらない場合、というのは
       プロンプトとして変な物を指定する場合を考えると制限が強い気もするが、
       その様な場合は余りないと考えればそれでも良い気もする。
 
       因みにプロンプトの高さが1行に収まらない状況としては、
       プロンプト自体に改行が含まれている場合以外にも、
       プロンプト内に長い文字列が含まれていて何度も折り返す場合を含む。
 
   * util: ble/dict#* を用意する可能性?
 
     設定ファイルの自動アップデートの実装に関連して
     ble/dict#* という物を作成しても良いのかもしれないとも思う。
     既に辞書的な構造は ble.sh の各所で個別に実装して使用している。
 
     辞書の bash-4.0 未満における最適の実装は何だろうか。
     任意の key を取り扱える様にする必要性を考えると、
     : 等を区切りにして scalar に key を格納する訳には行かない。
     そうすると配列に key を格納する必要が出てくる。
     配列が巨大になってくると重くなってくる。
 
     a 簡単な hash を作るという手もあるだろうか?
       例えば配列サイズが小さい時には最初のバイトだけを使って、
       要素が増えてきたら n 番目のバイトまで使って hash を生成する。
       と思ったがそれだと共通の接頭辞を持つ key が沢山ある時に hash が衝突する。
       例えば /home/murase/... という物が沢山ある場合。
 
     b 或いは全ての文字を用いて hash を計算する?
       という事にすると今度は長い文字列に対して各文字について文字コードを取得する手間がかかる。
       特に bash-4.0 未満では色々面倒な事をする。何れにしても ble/util/assign を使うので遅い。
       (実際にこれでキャッシュをしていないのは下手にキャッシュするよりも ble/util/assign
       を実行した方が高速であるという事からであろうという気がする。)
 
     c key の sorted list を管理する。
       文字列で辞書順でどちらが速いかについては [[ str < str ]] で判定できる。
       後はアクセスの度に二分探索を実施すれば良いのである。
       挿入には結構時間がかかりそうな気もするが、まあ、大丈夫。
       然し、よく考えたら bash-4.0 未満の配列はアクセスが線形時間だった気がする。
       という事を考えると二分探索よりも線形探索の方が実は良いのかもしれない。
 
     使用ケースによって色々なので汎用的な実装はやはり難しい気がする。
 
     * key が整数の場合には普通に配列を使えば良い。
 
     * key が有限の単語 (識別子) の集合であれば、
       local apple=1 banana=2 pineapple=3 orange=4 等の様にして、
       普通に arr[apple]=red 等とという風にすれば良い。
 
       或いは普通に変数に保存すれば良い。
       eval "arr_$key=red" という具合である。
       この場合大量の変数が散らかってしまうが、
       それが気にならなければ最良の気がする。
 
     * key に ":" が含まれない場合には
       keys にコロン区切りの key の集合を保存しておいて、
       head=${keys%%:$key:*} head=${head//[!:]} 等とすれば
       key が何番目の要素であるかというのを取得する事ができる。
 
     * key が文字である場合も同様にして
       head=${keys##"$key"*} 等としてから ${#head} で文字数を見れば
       それが何番目の要素であるかというのを判定する事ができる。
 
     * 辞書をメモ化に用いている場合には実は関数自体の計算時間が
       bash による辞書の模倣よりも速い可能性を考えるべき。
       例えば ble/util/s2c については ble/util/assign printf %d '$c の方が
       下手な辞書よりも高速なのである。
 
     * key の種類がそんなに沢山でない場合には、
       key を配列に格納して線形探索するというので良い。
       これが最も単純で自然な実装になる。
 
       key を sorted list に入れて二分探索するという可能性もあるが、
       Bash-4.0 未満の配列のランダムアクセスは線形なので、
       それよりは普通に線形探索で舐めた方が良い気がする (実測すると違うかもしれない)。
 
     結局使用ケースによって最適な実装方法が異なるという事から統合は難しい。
     ble.sh の内部で使わない以上は用意しても仕方がない様に思われる。
     そもそも ble/dict#... の形式による配列アクセスは文法的にそんなに綺麗でもない。
     等の事を色々考えると、ユーザの為に用意する程でもない。
 
 2020-05-20
 
   * 破壊的変更と後方互換性
 
     * done: keymap_vi_nmap_name は keymap_vi_mode_nmap_string 等に改名するかもしれない。
       或いはもっと別の名前? やはり keymap_vi_mode_normal で良いだろうか。
       改名するとしたら complete_stdin_frequency と同様に別名に書き換える様にする。
       実はオプションの改名について枠組みにしてしまっても良いのかもしれないという気がする。
 
     * 勝手に古い設定を書き換える機能を作っても良いかもしれない。
       毎回一行ずつ書き換えを実行するのではなくて、
       書き換えを実行する sed スクリプトを貯めておいて、一括で書き換えを実行する。
       cp a a.bk && sed "$script" a.bk > a 等の様に実行する。
 
       sed スクリプトは何処に貯めて於けば良いのだろうか。
       書き換え対象のファイル名と一対一に対応するファイル名にする必要がある。
 
       a 辞書にファイル名を記録するか或いは hash を用意するか。
         hash は計算に時間がかかるので辞書にファイル名を記録するのが良い気がする。
         然し、bash-4.0 未満ではどの様にするのが良いのか微妙である。
 
       b 或いは、別に辞書など作らなくても直接ファイルシステム上に書き出しても良い気がする。
         つまり、 "$file.sed" に書き出して置いて、それを適用して削除する。という具合にする。
         問題はファイル名が被らない様にするという事。乱数で決定する事にすると駄目。
         "$file.__BLE_REWRITE__.sed" 的なファイル名にするのが良いのではないか。
 
     * ble{-edit => }/prompt/{print,process-prompt-string,backslash} についても
       警告を表示する様にする仕組みが必要になる気がする。
 
 2020-05-16
 
   * TERM=alacritty で何か変な事が起きるらしい。
     https://github.com/rux616/init/commit/b03e7ef3dab5171d1f60aa61323ef823401217d5#diff-0af95dc8119f1c458b7a0fd76dfe8042R37-R39
 
     調べてみると alacritty:extra/alacritty.info が terminfo らしい。tic -x extra/alacritty.info で入れる。
     然し、何も問題は起きていない様に見える。256color もちゃんと動いている。ずっと使っていると発生する問題だろうか。
     これは時間があれば rux616 に何が起こるのか尋ねても良い。
     所で、いつの間にかに alacritty は jwilm/alacritty から alacritty/alacritty に移動したらしい。
 
     →cache/alacritty.term を確認した所 ich, ech, dch が空になっている。
     然し、ble.sh は ich, dch は使っていない。ech を使う場合でも、
     [[ $_ble_term_ech ]] の時にのみ有効になる様になっている。
 
     他に気付いたのは 8-15 の着色が 0-7 と同じになっているという事。
     然し実際に tput で tput setaf 15 とすると CSI 9 7 m になる。
     何かが間違っている。再度実行してみた所、問題なく初期化された。
     と思ったら alacritty.term と xterm-256color.term の内容が同一になった変だ。
 
     続けて何度試しても問題は発生しない。何が起こったかは謎である。
 
 2020-04-25
 
   * trap: DEBUG trap を用いて DEBUG trap を再現できるか? [#T0003]
     参考: #M0016
 
     つまり関数呼び出し毎に DEBUG trap が設定されるというのを実装する必要がある。
     ble.sh が使っていなければ特に問題は発生しないが、
     INT を受信した時に ble.sh が DEBUG trap を設置する事になっている。
     従って、実装できれば実装するのが良いという様に考える。
 
     要件は以下の通り
 
     * 何も DEBUG trap が設定されていない時には overhead 0 にする。
       つまり builtin trap で何も設定されていない状態にする。
       ユーザか ble.sh のどちらかが何か設定している時に有効にする。
 
       実のところ、ble.sh の使い方は一時的な物なのでユーザの trap と
       同レベルの取り扱いで良いという気がする。唯単に trap で列挙されない、
       ユーザの設定した trap も保持する、という事が異なるだけ。
 
     * 関数呼び出しでの継承・非継承を再現する。
       実はこれはそのまま bash の継承・非継承に従うだけで良い気がする。
 
     * 呼び出し元への影響についても再現する。
       これは新しく trap DEBUG が呼び出される時に、
       builtin trap DEBUG もやり直せば良い?
       と思ったがそもそもそんな事をする必要もない気がする。
       現在のフレームに既に何か設定してあるという事は
       呼び出し元ではそれが必ず有効という事だから。
 
       bash-4.3 以下では何れにしても呼び出し元に影響を与える事はできない。
       うーん。bash-4.3 以下では trap DEBUG で保存した trap handler を
       関数が抜ける時に削除する必要があるという気もする。
       これについては実装時に注意深く実装すれば良いだけ。
 
     * DEBUG trap の中で DEBUG trap は設定できるが発火しない。
       BASH_COMMAND は書き換わらない。
 
     実の所、DEBUG は C-c の時にしか設定していないので、
     取り敢えず気にしない事にする。
 
     先ず試験的な実装を作成して見るのが良い気がする。
 
   * trap: INT
     現在の実装ではユーザの設定した INT で握りつぶしても、
     ble.sh の設定したハンドラによって実行が中断される。
     ユーザが INT を設定している時には握りつぶさない様にするという手もある。
 
   * [保留] bash-4.4 trap 内無引数 return の修正
 
     ref #D1350
 
     bash-4.4 以降では trap 内の無引数 return は trap handler が開始する直前の $? を返す。
     強制的に trap handler の内部での直前の $? を返す様にする方法はあるだろうか。
 
     * return() { builtin return $?; } とする案
       x 本来の return を実行する方法がない。
         RETURN trap を使って return 関数呼び出し後に builtin return できないか?
         x RETURN trap は抑も終了しようとしている関数内の文脈で実行される。
         x RETURN trap 内部では RETURN は発火しない。
     * alias return で何とか無引数の場合を $? に置き換える事は可能か。
       x 引数がある場合とない場合の両方に alias で対応するのは難しそう。
 
 2020-04-19
 
   * history: 履歴の管理の枠組みで欲しい物
 
     1 実行したコマンドを追記で記録する仕組み (勝手に編集したりしない)
       他のシェルと同様に追加の情報も記録する?
 
       * 実行したディレクトリ。実行した時刻。$$.$LINENO
 
       * コマンドラインに含まれる有効なファイルパスの集合
 
         | fish はこの情報を用いて history autosuggestions の時に
         | コマンド履歴のフィルタリングを実行する様だ。
         | 然し疑問なのは echo > a.txt で a.txt など出力ファイルが元から存在していた時には、
         | 新しくファイルを作成したいという時にその履歴が候補に出てこない、
         | という事態になってしまうのではないかという事。
         |
         | その様に考えるとやはり実は個別のコマンド毎に判定した方が良いのではないか。
         | 例えば cd の場合には使い方が決まっているので、
         | 実際にそのコマンドラインを実行した時に成功するか失敗するかはすぐに判定できる。
 
         自動補完のフィルタリングに関しては完全な判定はできないので
         取り敢えず core でサポートしなくても良い。
 
       * zsh は実行にかかった時間も記録する様である。
 
         | 然し、これは微妙。何故ならば bash ではコマンドの実行開始前に履歴を追加するから。
         | 実行後に書き換える仕組みが必要になる。或いは開始の記録と終了の記録を別々にする?
         | そうすると複数のセッションで実行している時に互い違いになってしまう。
         | なので実行するコマンド毎に ID を設定する必要がある気がする。
         | と思ったが ID は $$.$LINENO 等で良い気がする?
         | x と思ったが同じ PID でシェルが起動する事もあるのでは?
         |   o と思ったが同じ PID で複数のコマンドを同時に走らせるという事はないので問題ない。
 
         開始と終了をそれぞれ記録する。$$.$LINNO でコマンド毎に ID を設定して対応を取る。
 
     2 記録されたコマンドとは別に bash の履歴で遡れるコマンドのリストを管理する仕組み。
       こちらは長いコマンドを自由に削除したりできる様にする。
       倍加したりすると嫌なので枠組み 1 で得た差分に基づいて更新する?
       差分を取る方法を気をつけないと結局倍加するので、
       ちゃんと同期して差分を取れる様な枠組みを整理する。
 
 2020-04-09
 
   * 別の bash の枠組みについて
     https://github.com/sio/bash-complete-partial-path
     https://github.com/mgalgs/fuzzy_bash_completion
     https://github.com/brujoand/sbp
 
 2020-04-02
 
   * test: テストフレームワークの追加機能
 
     * 単体テストの機能
       * テストを直接本体の関数の近くに書き込める様にする?
         これは mwg_pp.awk の枠組みを用いた対応が必要である。というか出力
         先が ble.osh と分かれている場合を考えると、#%$> の右辺に変数を指
         定するべき? と思ったが #%$> を含む行自体をマクロに入れれば良い。
 
     * テスト集合の管理
       * 集計・サブシェルで実行した結果も扱える様に。
       * テスト結果のキャッシュ
       * 並列テスト
       * 様々な bash の version の結果を集計
 
     * 他のフレームワークの機能を確認
       * bats
       * oil/test
       * shellspec
         kcov を用いて coverage が計測できる
         skip を設定できる。前回成功したものをスキップできる。
 
     * GitHub 用に Travis を設定する。
 
 2020-03-22
 
   * read -t や read line の戻り値が変だ
     →今試してみると別に変な事はない。-e が入っていても入っていなくても。
 
     一応 C-c で read -e を止めた時の終了ステータスは 130 の所が
     ble.sh の実装では単に 1 になっているという違いはある。
 
   * bash-3.0 が malloc array.c botched というエラーが出てクラッシュした。
     これは bash のバグである。そして古いバグなので治りそうにない。
     更に言うと再現性もあるのかどうか微妙である。
 
   * oilshell で色々説明を行った。
     それらの説明へのリンクを作成して後で纏めるのが良い気がする。
     これは後で実行する。
 
   * decode: 大量の貼り付けの高速化4 (report by dylankb)
 
     現状の ble.sh の枠組みの中では大幅に改善した。
     然し、やはり decode を自前でやっている。
     そもそも decode の結果を整数の列にする時点で遅い。
 
     bracketed paste だと分かった時点で、
     stdin から文字列として読み取って、
     文字列としてそのまま挿入する等の事が可能な筈なのではないか。
     そうすれば無駄な処理をする事なく即座にエディタを起動できる。
 
     現在の nonblocking-read の実装に
     bracketed paste を検出する機能をつけて
     bracketed paste の処理中にはそれを使って
     良い感じに実行すれば良いのだろうか。
 
 2020-03-11
 
   * __line_limit__ の実装の制限
 
     1 replace-limited を直接呼び出している箇所については確認したが、
       replace-limited が .replace-range を通して呼び出している時、
       外側で ind, mark を設定していると計算がずれて範囲外になる可能性がある。
       特に vi で .replace-range を多用しているが面倒なので細かくチェックしていない。
 
     2 容量超過でもコマンドラインが短縮されていない場合
       (これは isearch の途中などで起こりうる)
       複数のキーから為るキーシーケンスが間に入る __line_limit__
       によって無効化される。
 
       これの対処方法として mouse_move と同様に特別に
       __line_limit__ を keyseq に属さないキーとして取り扱う方法がある。
       然し、現在ではチェックが非効率になるので対応していない。
       或いは keyseq に属さない keycode の範囲を定義して、
       その範囲で判定できる様にするのが良い気がする。
       (その様なキーは実は沢山ある)
 
   * history: fish の autosuggestions はファイルが存在しない履歴項目はスキップする (suggested by cole-h)
     https://oilshell.zulipchat.com/#narrow/stream/121540-oil-discuss/topic/autosuggestions
 
     うーん。どうやら fish は履歴を保存する時にその時に使った有効なパスも一緒に記録する様だ。
     Bash はそれを記録しない。という事は ble.sh が代わりに記録する等の工夫をする必要がある。
     然し、ble.sh が代わりに記録するという事になると履歴の一貫性を保つ為に工夫が必要になる。
     或いは、ble.sh の履歴を本体として bash の history は全部それを元に再構築する?
     その様にするしかない気がする。
 
     或いは cmdinfo:color の実装が完全であれば、わざわざ履歴を見て
     ファイルパスかどうかを判定しなくても、それが有効な履歴かどうかを判定する事が
     可能になる。特に cd に関しては簡単に判定する事ができる筈である。
     という事を考えるとわざわざ実装する必要はないのかもしれないとも思う。
 
 2020-02-02
 
   * vi mode の時は read も vi mode になっているべきではないのか?
     と思ったが vi mode にはコマンド実行等の色々と
     危ない機能も沢山ついているので、寧ろ cmap を使うべきで、
     然し、cmap を使うのだとしたらそれは殆ど現状の read の様な物だ。
 
     これはその内に request があるかもしれない。その時に対応する。
 
     と思ったが既定の readline では vi-map が使える様になっている。
     コマンド実行等はどの keymap に定義されているだろうか。
     或いは accept-line や edit-and-execute-command の意味を差し替えられる様にするか。
     そちらの方が現実的である様な気がする。
 
 2020-01-26
 
   * progcolor: 非同期で実行できる様にする可能性?
     場合によっては重い計算が必要になるかもしれないし、
     実は非同期で実行しても良いのではないかという事。
 
   * progcolor: redirect の場合にも対応したい
     実は補完の時にも redirect をプログラム補完しても良いのでは。
     但し、補完と着色で違うのは補完は一つの単語について呼び出されるのに対して、
     着色は一度に複数の単語を着色する事があるという事。
     補完に関しては引数とリダイレクトを別々に処理すれば良いが、
     着色の場合には一度に処理できる様にしたい。
 
   * progcolor: here document にも対応したい。
     here document に対応するコマンドを抽出する事は可能か?
     →here document は開始部分に対する参照を確か持っていたのでできる筈。
 
     実際にユーザは何を提供すれば良いのか。
     ble/cmdinfo/color:XXX を呼び出す様にするのか。
     然し、それだとそのコマンドの引数が変更される度に、
     対応する heredoc を抽出する必要が出てくる。それは面倒だ。
     或いは、heredoc に変更があった時に着色するだけで良いのでは。
 
     というか heredoc は単語ではない。でも一つの nest ではある。
     うーん。然し wrange に登録しているかは謎。
     その辺りも整理しつつ実装すると良い。
 
   * progcolor: コマンド自身が書き換えられた時には
     全ての引数について再度着色の確認が必要になるのではないか。
 
 2020-01-23
 
   * 前々から発生していたが曖昧補完などを実行すると時々ごみが残る。
     これは何故だろうか。そもそもカーソルよりも右に何か文字列が入るはずがないのに?
 
     再現させようとしても再現できない。
     これは実際に起った時に再度確かめる必要があるのである。
 
 2020-01-21
 
   * lmorg/murex という新しいシェルの対話環境
 
     https://github.com/lmorg/murex
 
     このシェルは POSIX 互換でないので微妙。
     パス名展開をするのに面倒な指定をしなければならない。
     既存の様々なツールと相性が良いかというと微妙な気がする。
     しかし fish や PowerShell よりは unix shell よりである。
 
     一方で対話インターフェイスに関しては色々工夫している。
     入力していくと一行下に現在入力しているコマンドの説明が表示される。
     何も入力していない場合は git リポジトリの情報を表示している。
     (然し、なにか入力するとすぐに消えてしまうので何処まで使いやすいかは分からない)
     kill まで入力すると補完候補としてプロセス ID を表示してくれる。
     プロセス ID に対してコマンドラインを説明として表示している。
 
     * 所で ble.sh ではメニューの形式は事前にユーザの側で指定する事になっている。
       然し、これは微妙な気がしてきた。というのも説明文があるかどうかの情報は
       補完生成側が知っている事である。なので、補完候補生成器の側で、
       メニューの表示形式を上書きできる様にするべきなのではないかという気がする。
 
 2020-01-17
 
   * Minix で無限ループになっている?
 
     echo と入力しようとすると確率的に無限ループになる。
     (それでも可也高い確率で無限ループになる。)
     auto-complete を off にしても発生する。
     menu-filter を off にしても発生する。
     という事は着色か或いは。。
 
     調べてみると暴走しているプロセスは別の Bash だという事が分かった。
     恐らく子プロセスで暴走している。何が悪いのだろうか。履歴?
     →履歴はちゃんとロードできている。その後で暴走する。
     →再度確かめたらやはり子プロセスの暴走としか思えない。
       と思ったがよく見ると親プロセスの暴走だった。両方で起こる?
 
     2020-02-03 新しい ble.sh を実行しているが固まるという現象が再現しない。
     これは新しい ble.sh のお陰だろうか、それとも偶だろうか。
     →暫く使っていたが全く再現しないので以前の ble.sh の問題と思って良いだろう。
 
     と思っていたら実は裏でちゃんと無限ループになっていた。
     どうも ssh が予期せず切断すると無限ループになる?
 
     気になるのは暴走していたプロセスは stderr にリアルタイムで
     データを出力し続けていたという事。
 
     | -rw-r--r--  1 murase  users  14174140 Feb  3 21:58 5726.stderr
     | -rw-r--r--  1 murase  users  14324924 Feb  3 21:59 5726.stderr
     | -rw-r--r--  1 murase  users  14504088 Feb  3 22:01 5726.stderr
     |
     | 出力内容は以下の通り 0d 1b 5b 4b の 4B を繰り返し出力している。
     |   $ < $_ble_base_run/5726.stderr od -t x1
     |   0000000   0d  1b  5b  4b  0d  1b  5b  4b  0d  1b  5b  4b  0d  1b  5b  4b
     |   *
     |   67250220   0d  1b  5b  4b  0d  1b  5b  4b
     |   67250230
     |
     | 0d 1b 5b 4b とは何か? \r\e[K である。CR EL である。うーん。
     | ble.sh の該当しそうな部分を調べてみる。
     |
     | * canvas:344 (negative cup:el)
     |   ble/canvas/put-cup.draw 1 $((x0+1))
     |   ble/canvas/put.draw "$_ble_term_el"
     | * canvas:1928 (negative sgr0:cr:el)
     |   ble/canvas/panel#goto.draw "$index" "$x" "$y"
     |   ble/canvas/put.draw "$_ble_term_el"
     | * edit:1520 (negative sgr0:cr:el)
     |   ble/canvas/panel#goto.draw "$_ble_textarea_panel" "$fminx" $((fminy-new_scroll))
     |   ((new_scroll==0)) &&
     |     x=$fminx ble/textarea#render/.erase-forward-line.draw # ... を消す
     | * edit:1680 (negative sgr0:cr:el)
     |   ble/canvas/panel#goto.draw "$_ble_textarea_panel" $((cols+1)) "$y"
     |   ble/canvas/put.draw "$_ble_term_el"
     | * edit:1696 (negative sgr0:cr:el)
     |   ble/canvas/panel#goto.draw "$_ble_textarea_panel" "${pos[0]}" "${pos[1]}"
     |   ble/canvas/put.draw "$_ble_term_el"
     | * edit:3869 (negative cuf:sp:sp:el)
     |   ble/canvas/put-cuf.draw "$advance"
     |   ble/canvas/put.draw "  $_ble_term_cr$_ble_term_el"
     | * edit:7322 (negative cr:el:sgr)
     |   ble/canvas/put.draw "$_ble_term_cr$_ble_term_el${_ble_term_setaf[9]}"
     |
     | うーん。何れも関係なさそうな気がする。
     | もしかして _ble_term_el2 に CR EL が入っている?→確認したがそうでもない。
     | 上の中で一番怪しいのは panel#goto.draw だと思ったが、
     | sgr0 が消滅している理由が分からないし、
     | 一度 CR を出したら _ble_canvas_x=0 になるのだから、
     | 何度も CR を出力し続けるのは変だ。
 
     暴走した bash は何れも console ではなくて pty だった。
     接続が途中で落ちると無限ループになるのだろうか。
     hp2019 側及び vmminix 側で nc/sshd を kill -9 しても再現しない。
 
   * 英語圏のニュースサイトに投稿する可能性 (suggestion by dylankb)
     Hacker News を紹介されたがここが適切なんだろうか?
 
     reddit に投稿した話がある。
     https://rcmdnk.com/blog/2014/02/23/computer-bash-zsh/
 
     単にリンクを貼るというのでも良いけれども。
     やはり様々な機能を惜しげもなく紹介する
     長い記事を書くのが良い気がする。
 
     →返信で自分の作品を投稿する時のルールの頁があった。
       なるほど。やはりルールがあったのである。危ない所である。
       https://news.ycombinator.com/showhn.html
 
       これによると作品の紹介は一度きりしかできないとの事。
       > The community is comfortable with work that's at an early stage.
       と書かれているがまさかこれは初期の作品でなければならないという訳でもあるまい。
       > Blog posts, sign-up pages, and other reading material can't be tried out
       と書かれているが…。使い方の説明記事の様でも駄目なのだろうか。
       Blog posts でなければ良い? 或いは README を派手に改造してしまうという手もある。
 
     https://news.ycombinator.com/shownew
     ここを観察していると "Show HN: 作品名 ― 説明" という名前の物が多いが、
     実は "Show HN: 今〇〇なのを作っているんだけど" というタイトルの物の方が upvote が多い。
     "作品名 - 説明" だといかにも宣伝という感じで入る余地がない気がする。
     一方で "〇〇なんだけど" みたいに書くと "自分も何か貢献できるんではないか" と錯覚して人がたくさん来る。
     そういう仕組になっているんだろうという気がする。
 
     * reject: "Show HN: Bash Line Editor -- syntax highlighting, autosuggestions, etc. in Bash"
       これは普通。つまらない
 
     * "Show HN: I am developing a line editor in pure Bash script. I'd like to hear your comments!"
       これだと面白そうとは思ってくれるかもしれないけれど使ってくれる人は少なそう。
       後 explicit にコメントが欲しい! という事をタイトルに書いても良いのだろうか?
       眺めてみるとそういう投稿はない。やはり雰囲気が分からないのである。
 
     * reject: "Show HN: I made syntax highlighting, autosuggestions, etc. in Bash"
       これも普通。つまらない
 
     * "Show HN: "Bash Line Editor" with syntax highlighting, autosuggestions, ... written in pure Bash!"
       やはり宣伝っぽい。
 
     * "Show HN: Bash Line Editor -- syntax-highlighting, autosuggestions and vim emulation written in pure Bash"
       vim と書くと他のエディタを使っている人やシェルでは別に vim は使わないという人が敬遠してしまわないか?
       然し話題に乗るという事だけであればその辺りを無視して投稿しても良い気がする。
 
     * reject: "Show HN: I wrote a line editor (syntax highlighting, autosuggestions, vim amulation, etc.) in pure Bash script"
     * reject: "Show HN: I wrote a line editor in pure Bash script which provides syntax highlighting, autosuggestions, vim emulation, etc. to Bash"
     * reject: "Show HN: Bash Line Editor written in pure Bash script for syntax highlighting, autosuggestions, vim emulation..."
       長い
     * "Show HN: Bash Line Editor totally written in pure Bash script"
       案外これぐらいの方が気を引けるのかもしれないと思う。
     * "Show HN: Bash Line Editor -- a next-generation Bash configuration"
       或いはこんな感じに煽った感じのタイトルにしても良い。zplug の真似
       でも技術的に面白いのは pure Bash script であるという事。
 
       "with syntax highlighting, autosuggestions, vim emulation" 等は書かなくてよい。
       書かない方が煽りになるのである。本当か? と思ってみんなリンクを開く。
       そしてどんな機能があるのかとみんな確認する。
       少なくともこれだけの物があるのだからがっかりする事はないだろう。
 
       でも落ち着かなければならない。Bash configuration と書くと、
       従来の PS1 や aliases や functions を包含する物と考えられてしまう。
       その様に考えると、Bash plugin と書いた方が良いか?
       或いは、plugin manager として突貫で他の物を取り込める様にするか、
       或いは README に強調しておくことにするか。
 
       というか Bash configuration というのが良くない。違う。
       もっと土台になるものなのである。
       実のところ "a next-generation Bash Line Editor" なのだ。
       然し line editor という意味では全然 next-generation ではない。普通だ。
       つまり Bash の設定にしては next-generation なのであって、
       line editor として next-generation な訳ではない。
 
       a next-generation Bash interface/infrastructure/extension/framework
 
       Framework としての側面も強調してよいのかもしれない。
       (或いは真面目にライブラリとして独立させても良い。
       decode 部分に関しては大幅に手を入れる必要があるかもしれない?)
 
     * "Show HN: I wrote a featureful line editor in pure Bash scripts"
       みたいな単純な物の方が気を引けるのではないかという気がする。
 
     調べるとスタートアップという文字が頻りに見える。
     投稿してみた感想を観察してみるとやはり何かのお誘いがある様である。
     タイトルに文字数制限は在るのだろうか。
 
     何れにしても今は忙しいので沢山の要望などが来てしまっては困る。
     従って暫くはこのまま放置するというので良い気がする。
 
 2020-01-05
 
   * Homebrew の設定を作成する?
 
     先ず Linuxbrew (Homebrew for Linux) を ~/opt/linuxbrew に入れた。
     普通と違う場所に入れようとしたので色々問題が起こって時間を食ってしまった。
 
     * brew tap について調べてみる事にする。
 
       % brew tap akinomyoga/ble.sh を実行すると https でダウンロードしようとする。
       % brew tap akinomyoga/ble.sh git@github.com:akinomyoga/ble.sh.git とすれば良い様だ。
       % それから brew install を試そうとするがどうやっても動かない。
       % どれをやってもそんな formula は見つかりませんのエラーになってしまう。
       % もしくは tap を確認すらしない場合もある。不思議だ。
       % $ brew install akinomyoga/ble.sh
       % $ brew install akinomyogable.sh
       % $ brew install akinomyoga/homebrew-ble.sh
       % $ brew install homebrew-ble.sh
       % $ brew install brew-ble.sh
       %
       % $ brew tap
       % を実行してみると。自分が登録した物の他に homebrew/core がある。
       % homebrew/core は中に formula を沢山入れた repo の筈である。
       % もしやと思って調べてみる。
       %
       % https://qiita.com/wkentaro/items/d4981582e08b134f1e1d
 
       どうも user/name に対応して github.com:user/homebrew-name を作成して、
       その中に formula.rb を入れて置くという事になっている様だ。
       面倒なのでそれよりは直接 core に取り入れてもらった方が楽だ。
 
     * 自分で formula を作ってみるのを試す
 
       仕方がないので自分で formula を作ってみるのを試す事にした。
       $ brew create --set-name blesh
 
       全て自分で記入しなければならない様だ。適当に formula を作成してみる。
       sha256 は何の sha256 を記入すれば良いのか分からないのでコメントアウトする。
       結局分からないので以下を参考にして埋めてみる事にする。
       https://github.com/10sr/homebrew-pkg/blob/813de30c121e8dea970f11e7c1e63e57d3a6a0ed/Formula/ble-sh.rb_
       * ビルドは gawk に依存しているので gawk に依存させてみる。
       * gmake については調べてみた所 macOS ではデフォルトで GNU make だそうなので不要?
         然し、mac ではデフォルトで make が入っているのだろうか。
         或いは自分で追加で入れる必要があったりするのだろうか。よく分からない。
 
       と思ったが何処にも *.rb が作られていない。
       $ find ~/opt/linuxbrew/ | grep blesh
       で調べてみたら ~/opt/linuxbrew/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/blesh.rb
       に新しく blesh.rb が作成されていた。これを使う事にする。
       試しに $ brew install blesh としてみたら動き出した。
       gawk を入れるためにその依存関係まで全てダウンロードしてインストールしようとしている。
 
     ? brew では自分で何処かで入手した formula を使うにはどうすればよいのか?
 
     * homebrew-core に登録する為には test を用意しなければならないようだ。
 
 2019-12-31
 
   * progcolor: 引数の中の着色 (zsh -c '...' の ... の部分)。
 
     いつか実装しようと思っていたら fast-syntax-highlighting が既に実装している。
 
     | fast-syntax-highlighting
     | →引数の中も着色すると思ったら '$(...)' の中も着色を行っている。
     | 然し、zsh -c '...' に関してはちゃんと zsh や -c を認識して着色している様だ。
     | 調べてみると awk もちゃんと文法的なチェックを行っている。
     | (→ うーん gawk --source '...' で文法チェックをできる様だ。)
     | sed に関しては行っていない。何れにしてもコマンド毎の着色を実現している。
 
     * コマンド毎の着色設定を指定できる様にした #D1245
 
     | 次に例えば awk に対応する事を考える?
     | 或いはそれよりは sh もしくは bash に対応する方が楽?
     | 色々考えてみたがちゃんと対応するのは可也大変である。
     | 先ず単語が単純単語でない場合にどの様に実装するか。
     | 等、色々難しい。既にある文法構造を利用して何とかできる可能性はある。
     |
     | awk に対応するとしても awk の様々な実装によってオプションなど異なる。
     | このオプションが異なっていると異なった着色になって、
     | ユーザに混乱を齎す。従って対応するとしたら完全に対応している時にだけ有効にする。
     | 何れにしても面倒である。awk よりは先に bash で対応した方が懸命ではないか。
     | awk の対応に関しては自分の blerc の中だけに留めておく。
     | その自分の blerc の中での awk の着色の設定で必要になると
     | 思われる補助機能をble.sh の方で実装する。
 
     * awk の着色対応を通じて ble.sh 側で支援の必要な機能を実装する。
 
     * 単純単語に関して。評価値を求める方法。
       評価値の各文字が元の単純単語のどの位置に対応するか。
       或いはその逆? どちらの方が適切だろうか。
 
       例えば引用符等に関しては対応する文字はないのでそのままの色が良い。
       従って評価後の文字に対応する評価前の範囲を取得すると良い気がする。
       然し、逆に評価前の $a が評価後に沢山の文字列になる事もある。
       その場合には評価後の各文字の色を評価前に割り当てるのは難しい気がする。
 
     * 対応する物がない文字をそのままの (下の層の) 色にする事は可能だろうか。
       恐らく getg 等で取得しなければならない。面倒である。
       或いは ble/highlight/layer:syntax では少し違う様に処理していた気もする。
 
     * 複雑な単語に関しては文法構造を利用する事も考える。
 
     * 現在の layer:syntax の枠組みでは一旦着色情報を wattr に格納してから、
       それを word table に対して適用するという仕組みにしている。
       この様にする事に何の意味があったのだったか?
 
       直接 word table に適用した方が早いのではないか?
       →これは何度も単語着色を求め直すのを省略する為である。
       つまり、単語着色を決定する部分と実際に適用する部分を分けて、
       前者をできるだけ省略する様にしている。
 
       実際に適用する必要がある場合でも前回求めた値を
       そのまま使えば良い場合があるという事なのである。
 
   * fast-syntax-highlighting の機能を確認する
     https://github.com/zdharma/fast-syntax-highlighting
 
     * コマンド毎の着色。オプションや引数が正しいかのチェックも行う。
       これは丁度 ble.sh で将来的に対応したいと思っている機能である。
     * 括弧の対応に応じた着色
     * gawk --source による文法チェック?
 
   * theme: 流石に theme を作った方が良い気がしてきた。
     少なくとも枠組みだけでも作って置くと良い気がする。
     と思ったが実際に例がないと枠組みの良い設計も分からない。
     zsh-syntax-highlighting はどうしているのだろうか。
     zsh-syntax-highlighting theme で検索してみる。
 
     どうも zsh-syntax-highlighting は theme を提供していない様だ。
     https://highlightjs.org/static/demo/
     ここは dark/light の両方を提供している theme があって参考になる。
     但し、ファイル名着色に使う色は色々調整しなければならないが。。
 
     fish の theme はあるだろうかと思って探すと。
     https://github.com/oh-my-fish/oh-my-fish/blob/master/docs/Themes.md
     どうもシェル業界では theme というのはプロンプトの事を指す様で。
     然し、fish のブラウザ設定画面ではタブは colors となっている物の、
     色々な設定の部分には theme という文字も見える。
     何れにしても theme というのは紛らわしいかもしれない。
     注意書きを書いておく必要があるかもしれない。
 
   * tui: TUI 設定画面?
     fish はユーザフレンドリーを謳っている。
     ブラウザで設定できるなど (リモートの場合には使えない気がするが)。
     ble.sh ではブラウザでなくても TUI で設定画面を用意しても良いのかもしれない。
     マウスサポートまですればブラウザでなくてもOKなのである。
 
     →fish の web 設定画面を確認してみた。
       実は theme と prompt が選べるだけだった。
       他は関数・変数・履歴・束縛・略語展開の一覧が見えるだけで、
       何も設定することはできないのだった。
       但し履歴項目の削除はする事ができる。
       略語展開も実は編集することができた。
     →theme に関しては配色が選べるだけで、
       具体的にどの色がどの意味というのは余り考えられていない気がする。
       適当に順番に割り当てただけなのではなかろうか?
 
     その様に考えると履歴の着色でも良いのかもしれない等と。
 
   * complete: 重い補完関数に対する対策
 
     * 曖昧補完の為に何度も progcomp を呼び出していて非効率的
       →無駄があると思ったが実際にどういう補完を行っているか調べると
       様々な補完点を試しているのだった。うーん。
       自動補完の補完候補がすぐに見つかる場合にはそんなにたくさん呼び出されない。
       補完交互が見つからない時には自動補完によって何度も補完が実行されて遅くなる。
 
       もしかすると自動補完を off にしたいという人は時間のかかる
       補完関数を使っているという事なのかもしれない。
       よく考えたら peco の類を設定している場合大変に面倒な事になるのでは?
       自動補完が実行される度に選択メニューが表示されてしまう。
       そもそも補完に peco を設定している時点で変ではあるが。
 
       色々な補完点で試すとしても現在の単語を 0 文字または 1 文字しか
       入力していない場合には、同じ状態で呼び出す事もあるだろうという気がする。
       その場合の為に compgen の呼び出し結果をキャッシュする利点はあるだろうか。
       つまり、同じ補完状態で再度呼び出される事を見込めるかどうかが問題になる。
 
     * 或いは、処理を非同期で呼び出すというのが良いのかもしれない。
       その場合には計算結果を何処かファイルに書き出す様にしなければならない。
 
       非同期で呼び出すのは -CF が設定されているときだけで良い。
       と思ったが -F の中で環境を変更したいという場合にはどうするのだろう。
       非同期で呼び出すという事にすると環境に対する変更が適用されない。
       これは bleopt で変更できる様にしても良いのではないだろうか。
 
   * complete: menu-complete 中の通常文字挿入は
     絞り込みに戻すのが良いのではないか。
     というか普通にキャンセルして挿入すれば絞り込みになるのでは?
     と思ったが menu-complete 状態からは抜ける事になる。
 
     後、suffix を挿入せずに確定する方法がなくなる。
     これについては別の操作方法について考えると良さそう。
     例えばスペースを押すと suffix 挿入を抑制して確定する等。
 
     →やはりこれは分かりにくいのではないか。
       fish, zsh の動作を確認してみたが menu-complete 中に
       新しい文字を入力すると何れも現在の選択肢を確定させた後に
       続きの文字が入力される様になっている。
       これらのシェルと異なる振る舞いをするのは良くない。
 
       だとすると絞り込みをする為には明示的に
       絞り込みのモードに入るキーを設定するべきなのでは。
       例えば M-e 等?
 
       因みに emacs で試してみると M-e, M-a は end/beginning of
       sentence 的な動作をしている様に見える。
       なので上書きしてしまっても良い様な気がする。
       うーん。でも end of line の代わりに使っている人がいるだろうか?
 
       因みに現在の ble.sh では M-e は何にも紐付いていない。
       うーん。M-e を勝手に補完の絞り込みモードに割り当てる事にする。
       絞り込みモードにいる時にはカーソルの動く範囲と編集範囲を制限する。
       と思ったが vi の様な複雑なモードの場合にそれを実現することは可能か?
       移動だけならば __after_widget__ で範囲外に出た時に
       強制的に範囲内に移動させる事が可能であるが、編集まで入ると困難である。
       編集を禁止しなければならないがそれは難しい。
 
       だとすると新しいプロンプトで編集させるというのが現実的だろうか。
 
 2019-12-29
 
   * color: term_true_colors=auto
 
     自動判定は難しい。screen-4.99.0 が truecolor on/off
     のオプションを持っているので実際にユーザが有効にしているかどうかは
     TERM や DA2 を使っても分からない。結局試しに色を設定して、
     その色を読み出すという事をしなければ判定できないのだろうか。
     然し、これも端末によって問い合わせができたりできなかったり
     (セキュリティ上の都合から)無効になっていたりする気がする。
 
     以下の優先順位で試すというのが妥当な実装方法の気がする。
     然し 1 の判定を非同期に行わなければならないので面倒である。
 
     1. 色を設定して問い合わせる
 
       http://nanno.dip.jp/softlib/man/rlogin/ctrlcode.html
       https://qiita.com/kefir_/items/c2bd46728364bdc7470b
       OSC 10 ; ? ST で前景色RGB問い合わせ、
       OSC 11 ; ? ST で背景色RGB問い合わせの様である。
       応答は OSC 10 ; "rgb:rrrr/gggg/bbbb" ST の形式?
 
       よく考えたら現在の実装では ESC-[ (CSI) しか特別扱いしていない。
       これに対応する為には "ESC ]" (OSC) についても処理する必要がある。
       これは ble-decode-char/csi/consume の辺りを拡張する必要がある。
       特に BEL または ST (ESC \) で終端する様に処理を書く事に注意する。
 
     2. DA2 を元に判断する
       然し https://gist.github.com/XVilka/8346728 のページには
       各ターミナルの対応 version が書かれていないので使えない。
       自分で調べ上げるしかないのだろうか。
 
     3. TERM を元に判断する (*-24bit *-24bits *-truecolor)
     4. terminfo を元に判断する (setf24, setb24, tc, RGB)
 
 2019-10-21
 
   * ずっと起動していると段々と遅くなっていくのは何故か。
 
     Ubuntu bash-4.3 (song437) で動かしていて気づいた。
     bash として新しく起動すると速い。
     ble-update や ble-reload をしたり、
     ble-detach / ble-attach しても直らない。
 
     カーソル移動だけでも遅くなって行くので描画が関係しているとは思われない。
     また、reload しても直らないという事から考えられる事は何か。
     履歴がどんどん溜まって重くなるという事でもない様な気がする。
 
     或いは変数のアクセスが遅くなって行くという事なのだろうか。
     変数に代入するスクリプトを回してみたが特に遅いという事はない様だ。
     (それにそもそも使用している時間に比例して変数が増えていくという物でもない)
 
 2019-09-24
 
   * ble.sh で export PATH=aaa:bbb:ccc で最後の部分しか着色されない。
     それぞれ着色するべきなのではないか。
 
 2019-09-22
 
   * complete: = を含むファイル名を補完すると = 以前の部分が重複して挿入されてしまう。
 
     →今確かめてみると再現しない。\= としていても = としていても同じ。
 
     2019-12-31 ./configure の引数で --prefix= を補完している時に
     = が \= になったり --prefix= も丸ごと置換されたりなど変な動作をする。
     一方で、complete -r で progcomp を消してやると変な事は起こらない。
     これは要するに progcomp の仕様の微妙な違いに起因して変な事が起こっている。
 
 2019-07-16
 
   * complete: パス名展開で複数語に展開される場合の補完に関して
     現在の実装ではパス名展開が起こったとしても展開された最初のファイル名を使って補完を実行する。
     然し、実際には展開された各パス名について補完を実施しても良いのではないだろうか。うーん。
 
     更に failglob の場合には続きを入力したら一致したかもしれなくても常に展開に失敗してしまう。
     というか現状でそもそも failglob だった時にそれを検出しているのかどうかすら怪しい。
     確認する必要があるのである。
 
     既に COMPV には複数の値が入る仕組みになっていた。
     それならばと COMPV に入っている値の数だけ source を呼び出せば良いのかと考えたが、
     実際に試してみると全く同じ候補が何度も生成されるだけに終わってしまった。
     よく考えたら progcomp では独自に展開を行っていたのではあるまいか。
     調べてみたらやはりそうである…。これに対応するのは面倒である。
 
     或いは複数語に展開される場合には先ず始めにその内のどれか一つに絞らせるという可能性もある?
     然しそれはそれで不便な気もする。
 
 2019-07-09
 
   * history.mlfix: bash-3.0 で実現する方法?
     history -s が使えないので複数行の履歴を登録する事が不可能である。
 
 2019-07-02
 
   * menu: 複数選択を可能にしても良いのではないか
     C-@ で toggle をする等。抜ける時に全てを挿入する?
     然し使いみちがよく分からない。使いたくなったら追加するというので良い気がする。
 
 2019-06-18
 
   * history: interactive な history 編集に対応できたらする
     つまりメニューを表示して其処で選択したり削除したりする。
     検索などもできる様にする。遅延で着色をする。
 
     core-complete に実装されている既存のメニューの枠組みは、
     menu item を配列に格納する。従って容量を食う。
     更に重そうである。これは独自に新しく実装した方が良いだろうか。
 
 2019-05-27
 
   * 次に機能を追加するとしたらマウスなのだろうという気がする。
     fish は未だマウスに対応していない。
     zsh はそういう拡張があるらしいがちゃんと動くのかは知らない。
 
     zsh extension: https://unix.stackexchange.com/questions/444601/any-terminal-shell-with-mouse-support
     fish suggestion: https://github.com/fish-shell/fish-shell/issues/4918
     question: https://superuser.com/questions/322367/are-there-any-unix-shells-that-support-mouse-reporting
 
     マウス対応の問題点はマウスが有効になっていると、
     従来の端末に対するマウス操作(端末に表示されている内容のコピー・ペーストなど)が使えなくなる事である。
     端末に表示されている内容まで全て ble.sh の管理下であればそういう事もできたかもしれない。
 
     部分的なサポートとして何らかのモードに入っている時だけマウスを有効にするというのはあるかもしれない。
     例えば補完のメニューを出している間だけ、など。然し、それもなかなか分かりにくい気はする。
     或る特定の範囲だけでマウスを有効にするという制御機能があった様な気がする。
     それが使えればそれを使ってマウスを有効にするというのが可能になる気がする。
     何れにしてもこれは考察が必要になるのである。
 
     2019-07-22 どうも既存の端末では Shift を押しながら操作すると
     Mouse report ではなくてローカルでの端末上でのマウス操作になる、
     というのを採用している物が多い、という話を何処かで見かけた。
     何処で見掛けたかは忘れたし実際にそうなのかの確認はしていないが。
 
 2019-04-21
 
   * 実は背景色を判定する方法はなくはない様だ。
     https://qiita.com/kefir_/items/c2bd46728364bdc7470b
     しかしそうだからと言って暗い背景用に配色を調整する必要があるので、
     それを実行するまでは対応しても仕方がないかもしれない。
 
     % というか、調べていたら DECSCNM (SM/RM(?5)) が背景が暗いか明るいかの設定の様だ。
     % という事は DECRQM して DECRPM を受け取れば普通に背景が明るいか暗いか分かるのでは。
     % そして Poderosa や screen の側でもそれを設定すれば良かったのではないか…。
     % と思ったが xterm は明るいか暗いかが反転している。
     % つまり、DECSCNM は飽くまでその端末の既定の背景と比べて反転しているかどうかしか分からない。
     % 既定の背景色が明るいか暗いのかの情報は取る事ができない。
 
     一方で、背景色の問い合わせで返ってくる色が DECSCNM の影響を受けるのか
     は気にして置かなければならない。
 
 2019-03-23
 
   * menu: alias select='while myselect $# "$@"' 等として select を上書きできるのでは
 
     というか現在の ble.sh で select を実行すると悲惨な事になる気がする…。
     と思ったが select は別に readline は使っていない様子だ。
     元の bash でも全然行編集できない感じの入力になっている。
     なので現状で問題が発生しているという訳でもない。
 
     もし置き換える事ができるのであれば便利かもしれないという程度である。
 
   * menu: 今後の拡張性
 
     * 因みにフィルタリング機能は menu-filter を統合・整理する形で実装したい。
       フィルタリング文字列の入力に関しては isearch や iswitchb の様な、
       単に文字を入力するか BS で戻るかだけしかできない様なものでも良い事にする。
 
       フィルタリングに関してはフィルタリングを実行する関数と、
       フィルタリングを誘発する為の機能を分離して実装する事にする。
       既存の menu-filter の機能は自動的にフィルタリングを呼び出す。
       明示的なフィルタリングの場合には keymap にフィルタリングを紐付ける。
 
     * cdhist では更にリスト編集機能までついている。
       つまり項目を並び替えたり削除したりと言った事ができる。
 
       うーん。これをどの様に返すかは微妙かもしれないが、
       _ble_complete_menu_items にある物を呼び出し元で参照してもらうというので良い気がする。
       或いは callback でどの様に並び替えたかを返すという手もあるが分かりにくいだろうか。
       両方という事で良い気がする。使う側で便利そうな方を選んでもらう。
       どの様に並び替えたかの操作が欲しければ callback を使うし、
       最終的な結果だけ欲しければ _ble_complete_menu_items を参照してもらう事にする。
 
     * callback という事で思ったが、実は accept だとか cancel だとかも
       全て menu_class 経由で定義した方が良いのではないだろうか。
       一つずつ全て callback を変数に設定していくのは面倒である。
       更に、並び替えの callback だとかどんどん増やしていくと際限がない。
 
 2019-03-22
 
   * menu-filter の使い心地が微妙なのはもしかして
     menu-complete を実行中に絞り込みができないからなのではないか。
     現在は menu-complete を実行している途中に入力をするとその場で確定してしまう。
 
     では bash の振る舞いはどうなっているだろうか。
     確認してみた所、bash の menu-complete はもうその場所に挿入してしまう。
     そして文字を入力すれば続きに挿入される事になる。
 
     現在の ble.sh の振る舞いはどうだろうか。
     その場で入力すると addtail 等の処理をせずにいきなり続きから入力されてしまう。
     少なくとも addtail ぐらいはするべきなのではないか。
     また、絞り込みを実行しても良いのではないかという気もする。
     然し、それでも何か違う様な気がする。
 
     絞り込みの入力欄と現在選択されている内容というのは別に一致している必要はない。
 
 2019-03-19
 
   * complete: 実装されていない補完関連の rlvar は以下の通りである。
     実際に対応するかどうかも含めて考察する必要がある。
 
     - set completion-map-case off
     - set disable-completion off
     - set expand-tilde off
     - set horizontal-scroll-mode off
     - set page-completions on
     - set completion-display-width -1
     - set completion-prefix-display-length 0
     - set completion-query-items 100
 
     うーん。これらの設定は bash の既定値では余り便利ではなかったりする。
     ble.sh で折角実装してもユーザに使ってもらえないのでは仕方がない。
     それならば最初から ble.sh の bleopt として提供してしまった方が良いのでは。
     元々 bash を普通に使っていて設定している人の為に、
     bash の規定値と異なる値を敢えて選択している時に限り
     ble.sh でその効果を再現する様にすれば良い。
 
 2019-02-09
 
   * main: --attach=prompt の問題は何だったか
     ref #D0940
 
     何か問題があって現在はこれを使っていないが、それは何だったろうか。
     何処かに記録されていて良い筈なのに何処にも記述がない。
     対応した時の記録は #D0737 にある。
     動かしてみた所、ちゃんと動いている様に見える。
 
     →恐らく、先ず古い ble.sh の version では使えないという事。
       それから PROMPT_COMMAND を上書きすると使えなくなってしまうからという事。
       ユーザに PROMPT_COMMAND を設定しないように要求するのは面倒である。
 
 2018-09-21
 
   * [保留] 2018-09-15 complete: 文脈の変更範囲で end0 だけ負になるバグ (ref `#D0818`)
   * [保留] 2018-09-11 complete: 端末が操作を受け付けなくなるバグ (ref `#D0817`)
 
 2018-08-16
 
   * complete: オーバーレイによる実装?
 
     現在の実装では仮挿入しているが、
     これによって現在の入力内容でエラー着色するべき所が、
     補完が実行された後の着色になってしまっていて、
     補完前の現状でエラーなのかどうなのかが判別できなくなっている。
 
     やはり仮挿入ではなくて overlay で実装するべきなのではないか。
     しかし overlay の仕組みを実装するのは面倒である。
     どの様な仕様にするのが良いのかの吟味から実装まで。
     しかし、これについては後回しで良いだろう。
 
     以下に仮入力の4種類の方法について言及がある。
     https://mattn.kaoriya.net/software/vim/20170905113330.htm
 
     リンク先は消えている。web archive のリンクを追記 (2018-09-23)。
     https://web.archive.org/web/20110630165743/https://www.mozilla-japan.org/projects/intl/input-method-spec.html
 
     * 2018-09-23 自動補完時の着色について
       cmplstofB さんからも指摘があった。
       https://github.com/akinomyoga/ble.sh/issues/5
 
       自動補完の候補文字列は実際に挿入しているので構文着色に影響を与える。
       "現在の内容" で着色するべきなのではないか、ということ。
       そうしないと例えば今入力したコマンドが実際に存在するコマンドなのかどうかが分からない。
 
 2018-08-05
 
   * edit: set blink-matching-paren on に相当する機能
     対応するならカーソル移動ではなくて着色でやった方が良い。
 
     | 括弧の対応と region が両方走っていると分かりにくい。
     | 既に region には複数箇所を highlight する機能がある。
     | そういう意味で region を使うという手もある。
     | と思ったが、分かりにくい問題に関しては region の方を上に配置すれば良い。
     | 複数箇所を highlight する機能は実装を参考にするだけで良い。
     | 論理的には全く異なる (region は _ble_edit_mark を参照する) し、
     | それぞれ独立に on/off する事を考えれば別の highlighter にするべき。
 
     region の複数箇所着色の実装を参考にする可能性も考えつつ、
     region とは独立な highlighter にしたい。
     その時は region の一つ下の層に挿入したい。
 
     また対応する括弧はどの様に検出するのが良いだろうか。
     やはり文法構造を参照する実装にするしかない様に思われる。
     しかし、括弧の対応には色々ある。引用符の対応、
     括弧の対応、if then else などのキーワードの対応、
     ヒアドキュメントの始まりと終わりの対応である。
     それらは必ずしも記録されていないし、また、記録されているとしても
     様々な形式で記録されている。取り敢えず一番簡単な対応として
     nest に記録されている物を着色するというのが良さそうである。
 
     2023-03-26 https://github.com/akinomyoga/ble.sh/discussions/308
 
     対応する request が来た。うーん。もっと最近にも関連した考察をした気がするが、
     メモに記録があるかどうかは覚えていない。
 
 2018-07-29
 
   * complete: メモ
 
     - 生成候補のキャッシュを行うとすれば source 内で実装するべきである #D0705
 
 2018-07-19
 
   * ble-decode: 'set convert-meta on' 的な操作
 
     ref #D0699 (LANG=C bash で ble.sh をロードすると全く操作できない)
 
     ble.sh の内部環境では set convert-meta off にしているが
     (そうしてないと特殊文字の受信時に無限ループになる)、
     外部環境で set convert-meta on だった時に、
     それをエミュレートする様な動作を行っても良い。
 
     外部環境における set convert-meta の状態は
     変数 _ble_term_rl_convert_meta_external に記録してある。
 
   * 現在の `LC_CTYPE` で表現できない文字を入力した時の `self-insert` の振る舞い
 
     ref #D0699
 
     self-insert で入力するのは逆符号化したバイト列であるべきでは?
 
     というのも LC_CTYPE が正しくない場合でもファイルシステムのファイル名などは
     そのまま謎の文字列として取り扱われるからである。
     然し逆符号化したバイト列は文字列として正しくないかもしれない。
     逆符号化したバイト列を更に一バイトずつ現在の LC_CTYPE に変換すると意味がない。
 
     これは文字列を編集などしようとすると分からない事になりそうなので、
     取り敢えず現段階では \u???? を出力するという現状の振る舞いを維持する。
     後で落ち着いてから再考する事にする。
 
     以下の c2s 使用箇所は一貫している必要がある。
 
     ble/widget/self-insert 編集文字列の入力
     ble/widget/vi-command/search-char.impl/core 検索文字列の入力
     ble/widget/vi_xmap/visual-replace-char.hook 置換に使う文字の入力
     ble/lib/vim-surround.sh/get-char-from-key 囲み文字の入力 (あらゆる遅延入力)
 
 2018-02-21
 
   * vi-mode: nmap (, ), {, }
 
     カーソルを N 文元に戻す or 先に進める。N 段落元に戻す or 先に進める。
 
     これは operator:d,c で "- ではなく "1 に記録するという例外の対象であるので、
     対応したらその例外のリストに登録する必要がある。
 
     2020-08-27
     https://www.youtube.com/watch?v=hIJh-KlQ7io
     この動画で zsh/bash の vi mode に (){} がない事を嘆いている。
     然し、"文" をどの様に定義するのか。文法的なコマンドで定義するのか、
     或いは、元の vim と同様に . の位置で判断するのか。
     シェルの機能としては . の位置で判断するのは使いようがない。
     一方で、シェル文法の . で移動する様にすると
     vim に使い慣れた人に取っては混乱の元である。
 
 2018-02-12
 
   * [保留] vi-mode: operators 保留項目 [#tmp0002]
 
     * 領域折り畳み zf には対応しない。
 
     * gq の formatexpr, formatprg には未対応である。
 
 2018-02-11
 
   * [保留] keymap/emacs: 連続する delete-backward-char の場合 undo の記録をまとめる可能性?
 
     現状では一文字ずつ記録しているので一文字ずつ undo される。
     現在の振る舞いの方が良いのか emacs と同様にまとめた方が良いかは微妙な所である。
 
 2017-11-21
 
   * syntax: for^J で改行にエラーが設置されるが見えない [#T0005]
 
     改行のエラーは何らかの方法で見える様にするか、
     或いは、改行位置にエラーがある様な時は、
     その前の文字でエラーが発生する様にチェックを行うべき。
 
     Note: これは端末によっては表示されたりする。端末による。
     エラー着色はどの様に行われているのか。for の後には FARGX1 に入る。
 
     これは ble-syntax:bash/ctx-command/.check-delimiter-or-redirect の冒頭部分が怪しい。
     と思ったが FARGX1 に関してはチェックが入っていないのでやはり関係ないだろうか。
     うーん。調べるとやはり文法レベルでの着色になっている。
 
     2019-03-11
 
     | rps1 で表示している時に EL を空白で代替していると、
     | 改行の着色が空白に反映される。これでも良いような気がしてきた。
     | 然し、右側が全て着色されるというのもうるさい。
     | 最初の1文字だけ着色して SGR(0) するかと思ったが、
     | そうするとその次にある文字の着色も消えてしまう。
     |
     | それの対策のために _ble_textmap_ichg があるのでは。
     | と思ったが、実装を見てみると違っている様に見える。
     | _ble_textmap_ichg は着色の調整に使っている事は確かだが、
     | _ble_textmap_ichg に登録されている文字の着色を計算しているのであって、
     | _ble_textmap_ichg に登録されている文字の次の文字の着色は計算していない様に見える。
     | うーん。_ble_textmap_ichg は他の箇所では全く使っていない。
     |
     | そうだ。思い出した…。_ble_textmap_ichg に登録されている文字は、
     | 配置の場所によって中身が変わるので、shift が使えないという事だった。
     | 特に、中身が変化している場合には文字を取り出して変更を行うのだった。
     | では以前 ichg に登録されていて、現在位置では ichg に登録されていない文字はどうなるのか。
     | と思ったら既定の文字形は別の所で決定されている様だ。
     | ble/highlight/layer:plain/update/.getch である。
 
     a 右側の1文字だけ着色される様にする?
 
       x 問題点はコピーペーストした時に必ず余分な空白が入る事である。
         これは右側の全てを着色させる場合にも同様の問題が生じる。
 
         また、エラーが有る時にだけ (着色の必要がある時にだけ)
         右側に空白を入れるという方法もある。
         しかし、その為にはその位置にエラーが有るのかないのかを
         外部から取得しなければならない。
 
         ble/textmap#update は edit.sh だとかの仕組みに依存しない、
         独立した枠組みにしたいので余り変な機能は取り付けたくない。
 
       x また実装上の問題点として、rps1 が表示されている時に、
         _ble_term_ech を使わない場合、2文字目以降の空白文字を SGR(0)
         でクリアしなければならない事である。この場合、
         改行の次の文字の SGR を復元する為には…
 
         _ble_textmap_ichg に次の文字の番号も追加するか、
         或いは現在の改行文字の SGR 状態を復元する必要がある。
         しかし textmap の処理をしている間は、
         未だ着色が完了していないので SGR 状態を取得できない。
 
         或いは着色部分だけ textmap#update よりも前に持ってきても良いのだが、
         その様にしたとしても色情報を textmap#update に伝達する手法が必要である。
         例えば getg なる関数を textmap#update から呼び出してもらう事にするのか。
         或いは呼び出す関数名も外から指定できる様にするのか。
 
     b やはり改行の前の1文字を描画時に強制的に着色するという手もあるのではないか。
       と思ったが…エラー着色だけ特別扱いするというのも変な話である。
 
     c その様に考えると初めから改行にはエラー着色はしないというのが正しい気がする。
 
       改めて調べると ble/syntax:bash/ctx-command-compound-expect がエラーを設置している。
       うーん。for だけの問題では無い様である。他に select, case の時にも同様である。
 
       ('for'|'select'|'case')
         [[ ${text:i:1} == $'\n' ]] &&
           ((_ble_syntax_attr[i-1]=ATTR_ERR))
         case $word_expanded in
         ('for')    ((ctx=CTX_FARGX1)) ;;
         ('select') ((ctx=CTX_SARGX1)) ;;
         ('case')   ((ctx=CTX_CARGX1)) ;;
         esac
         processed=begin ;;
 
       実際に上記の様にして見たら見える様になった。
       しかし rps1 が有効になっている時はやはりうるさく感じられる。
       また端末に依っては rps1 が無効になっていても行全体が赤く着色される。
       そういう端末 (mintty など) どういう発想なのかはよく分からないが…。
 
       更に here documents も行末にエラーを設置する。
       これについても対策したいが、here documents に関しては、
       nest の終端がない事によるエラー着色である。
       これは nest の範囲を変更しないと着色を変更できない。
 
       何だか中途半端な実装の気がしてきたので取り敢えずこの変更はなかった事にする。
 
     d うーん。右側の内容の消去は実は改行文字を使って行うのではなくて、
       描画した後に消去するという方法にした方が良いのだろうか。
       しかし、その様にすると、今度は urange の中にある行末というのを列挙して、
       それから各行末について位置を計算して実行するという事をしなければならない。
       textmap さえあれば指定範囲内の行末は二分法によって特定する事が可能である。
       しかし面倒である事に変わりはない。もっとまともな方法はないのだろうか。
 
     結局実装の面倒さを考えなければ三種類の仕様が考えられる。
 
     a 右側に1文字赤く表示する
     b 行末まで赤く表示する
     c 行の最後の文字を赤くする
     d 表示されなくても気にしない
 
 2017-11-09
 
   * complete: 候補の優先順位? 例えば拡張子でフィルタすると絞りすぎることがある。
     拡張子の要件を満たすものを先に表示して、満たさないものを後に表示する。
     満たさないものに関してはサブ候補として、TAB による接頭辞挿入には寄与しない。
 
     2018-07-28 候補間の優先順位をつける可能性。
     weak な優先順位は、候補を表示する時の順序。
     strong な優先順位は、候補絞り込みの際に一番優先順位の高いものが一つしかない場合にはそれに確定する。
 
 2017-11-05
 
   * vi-mode
 
     :help 関連の気になること:
 
     - v_p v_P: Implementation details に書かれている処理の順序は実際は逆
     - exclusive-linewise: ここの inclusive/linewise になる条件の記述は曖昧だし全く合っていない
     - star: vim-jp の文書だと WORD と書いてあるが、振る舞いは word (しかも \<\> で囲まれる) に近い
 
     振る舞いで気になること
 
     - i<C-o><C-c> とすると普通のノーマルモードに移行したように見えるのに、
       モード表示は -- (挿入) -- のままである。これは何故だろう。
       ble.sh ではノーマルモードに完全に移行する。
 
     - qa<C-c>q とすると ^C が二重に記録される。これは何か?
       ble.sh では単に ^C は入力された通りに一個だけ記録する。
 
     - C-v <bracketed paste> では矩形挿入にするべきなのではないか。
       ble.sh では矩形挿入を行う。
 
 
 2017-11-03
 
   * vi-mode (registers): 各種特殊レジスタの対応
 
     http://vim-jp.org/vimdoc-ja/change.html#registers
 
     - done: "% は現在のファイル名を保持するが、これは $HISTFILE の内容を返す事にした。
 
     - done: ": は一番最後のコマンドラインの内容である。
     コマンドラインを入力し途中でキャンセルした場合などには記録されない。
     空のコマンドラインで確定した時にも記録されない。
     コマンドが入力された場合は、それが存在しないコマンドであっても記録される。
     コマンドが実行されている途中では未だ設定されていない。
     つまり、そのコマンドが実行された後で値が設定される。
 
     - ". は挿入モードで挿入された文字列を保持する。挿入モードから抜ける時に記録すればよいだろうか。
     と思ったが説明をよく読んでみるとそういう振る舞いという訳でもなさそうだ。
     よく分からないので実際に動かして試してみる必要がある。
 
     - "# は代替ファイル (副ファイル) の名前だそうだが何か良くわからない。
     C-^ の動作と関係しているそうだ。これは未だ実装しない。
 
     - "= これは複雑だ
     - "* "+ "~ これは GUI で選択した範囲を表すものだそうだ。
 
 2017-10-31
 
   * [保留] vi-mode (_ble_keymap_vi_REX_WORD): Unicode categories?
 
     Bash の正規表現 (<regex.h> ERE) で対応するのは難しい。
     また必ずしも Unicode (UTF-8) で実行されるとは限らない。
     現在は UTF-8 しか対応していないが枠組みとしては
     別の文字コードにも対応できる余地は残して置きたい。
 
 2017-10-12
 
   * vi-mode まだ対応していない・考えていないコマンドを列挙する
 
     意外とそんなに残っていないようなので。
 
     * nmap: C-^ '括弧 `括弧
       C-t C-] M Q ZZ ZQ do dp { }
       [{char} ]{char} z{char} C-w{char}
       g<C-a> g<C-g> g<C-h> g<C-]> g# g* g$ g&
       g` g' g+ g, g- g8 g; g< gD gH gN gP gQ gT gV
       g] ga gd gf gF gh gn gp gq gs gt gw gx g@
 
   * [保留] vi-mode: xmap <C-]>
 
     % <C-]> なる物は今見ても存在しない。vivis https://qiita.com/b4b4r07/items/8db0257d2e6f6b19ecb9
     % 辺りに在ったものかとも思ったが、ない。zsh-vimode-visual を見てもない。
     % vim で C-] としてもベルが鳴る。何かの間違いで C-[ を C-] と書いてしまっただけなのかもしれない。
     % と思って改めて vimindex を見ていたら実はあった。
 
     C-] で "選択した文字のタグ" へジャンプと書かれている。
     タグとは何だろうと思ったら http://vim-jp.org/vimdoc-ja/tagsrch.html に説明がある。
     ctags のタグと同じものと思って良さそうだ。因みに :help ... で表示されるのもタグの様だ。
     またノーマルモードの C-] はカーソル位置の単語を ":ta" で検索と書かれているが、
     実質 xmap の時と同じことのようだ。
 
     % これについてはシェルの操作としてどの様な意味を持たせるのかというのは微妙な所である。
     % 履歴項目のブックマーク的なものとして利用することはできるかもしれない。
     % しかし、既にコマンドラインに入力されている文字列を元にジャンプをするとなると矢張り微妙だ。
     % 唯一意味がありそうなのは、指定した単語がコマンドライン上で定義された
     % シェル関数だった時にそこにジャンプするという物だが…本当に需要があるのかは微妙である。
     % しかし、シェル関数の定義を確認したいのであれば寧ろ command-help を呼び出せば良い。
     % シェル関数を修正するという目的ならば使えるかもしれない。
     % 然し、必ずしもシェル関数をコマンドラインで定義したとは限らないし、
     % 該当するファイルがあったとしてもそれをコマンドラインで表示する訳にも行かない。
 
     既に入力した文字列に対応して適切な履歴項目またはコマンドライン中の文字があればそこにジャンプする。
     例えばシェル関数を定義した履歴項目に跳んだり、変数名から declare に移動するなど。
     そういう機能でまともそうなのが定義できればそれを実装する。
 
 2017-09-18
 
   * vi-mode: operator = [#tmp0001]
 
     :help = を見ると (設定 equalprog || 内部関数 C-indenting, lisp || 外部コマンド indent) が使われるそうだ。
     但し、indentexpr が非空白の時、indentexpr が使われる (参照: indent-expression)。
 
     インデントの規則について調べる。
     先ず初めに空行 (空白だけの行) を隔てて前の行に括弧がある場合には、
     それを考慮に入れて初めのインデントが決定される。
     空行を隔てて前の行がインデントされていればそれを継承する。
 
     結局空行を隔てた前の行のインデントまたは最後の括弧の位置を継承するということ?
 
     また括弧の種類は () しか見ていない {} や [] は見ていないようだ。
     デフォルトが lisp だからだと思われる。
     これは実のところシェルに適したインデントを実行するようにするべきなのだと思われる。
     しかしながらシェルのインデントはかなり面倒くさい。
     特に if, then, else, while, do, done 等については現在の解析では状態を記録していない。
 
     関連してコマンドが閉じていない時 RET を押すと改行挿入にするという物がある。
     この機能を実装する為にも現在の入れ子の状態を調べる仕組みが必要になる。
     RET で改行挿入にする機能のほうが幾らか単純なので、
     それを先に実装してからこれを実装する方が良い気がする。
 
   * vi-mode: 関連して [/ 等の実装についても調べたい。
 
     既に vim-surround.sh で類似の機能について実装したが、
     [/ についても個別に実装したい所である。
 
     他にテキストオブジェクトで [{ [} [( [) などと同等の機能も実装している。
 
     [# [' [( [* [/ [` [D [I [P [p [[ [] [c [d [f [i [m [s [z [{ [<mouse2>
     ]# ]' ]) ]* ]/ ]` ]D ]I ]P ]p ][ ]] ]c ]d ]f ]i ]m ]s ]z ]} ]<mouse2>
 
   * vim-surround: ds cs インデント
 
     surround.vim では改行が絡むとき = によるインデントを実行している。
     現在 vim-surround.sh ではインデントを実行していない。
 
     2017-10-09 追記
 
     yS ySS でもインデントは起こる様である。
     更に、xmap S でもインデントを行う (xmap gS はインデントは行わない)。
 
 2017-09-17
 
   * cmplstofB: ビジュアルモード・選択モード?
 
     関連 #D0672 選択モード対応
 
     * テキストオブジェクトで範囲を選択し、また範囲を拡大する。
 
       どうやらテキストオブジェクトの拡大では左右の両端からの拡大を試みるような気がする。
       決して右端からテキストオブジェクトを拡大するというわけではないようだ。
 
       というのも変なところから初めて (...) の中に右端を移動して、
       その上で ib としてもエラーになるからである。或いは短くなる。
       どうも ib の動作としては左端から外側の ( を見つけて、
       それに対応する ) を右端に直すようである。
 
       うーん。これはテキストオブジェクトによって動作が異なるのかもしれない。
       aw などは明らかに右に向かって拡大を行っている。
       因みに矩形選択かどうかは気にしないようだ。
       同じ動作をする。行の右端に行くと次に次の行に普通に移動する。
 
     2018-02-22 現状の xmap におけるテキストオブジェクトの状況について整理する。
     - ble/keymap:vi/text-object/word.impl に於いては既に xmap での振る舞いに対応している様子である。
     - ble/keymap:vi/text-object/quote.impl は明らかに対応していない→対応した #D0670
     - ble/keymap:vi/text-object/block.impl も対応していない
     - ble/keymap:vi/text-object/tag.impl も対応していない
     - ble/keymap:vi/text-object/sentence.impl も対応していない
     - ble/keymap:vi/text-object/paragraph.impl も対応していない
 
 2017-09-16
 
   * cmplstofB: vim-surround.sh: ds cs cS yS ySsd ySSd S gS 'C-s' 'C-g s' 'C-g S'
 
     現在のところ特に要望は出ていないが ds cs あたりは使いたくなるのではないかと思われる。
     → ds cs に関しては要望が出たので対応した。
     → cS yS ySs ySS vS vgS にも対応した。
 
     残っているのは imap <C-s> <C-g>s <C-g>S のみである。
 
 2017-09-15
 
   * cmplstofB: here string 候補について
 
     here string 候補にファイル名以外のものがあれば対応する。返信待ち → やはり候補は難しい。
 
     コマンド名に応じた補完関数の設定を可能にする?
     例えば python3 に対する here document の場合には、import を補完候補に出すなど。
 
     2018-10-02 C++ の場合にはこんな感じに clang を呼び出せば良い様だ。
     clang -cc1 -fsyntax-only -code-completion-at=test2.cpp:7:7 test2.cpp
     http://d.hatena.ne.jp/ohtorii/20110319/1300514225
 
     Here document で補完候補を出す為には、
     Here document の内容 (先頭から現在位置まで) が
     単純内容 (単純単語に近いがシェルの特殊文字を使える) でなければならない。
     その為の関数を追加する必要がある。simple-word の実装を真似れば良い。
 
 2017-08-19
 
   * [保留] cmap/default.sh: "CAN @ ?" 代替?
 
     "CAN @ ?" は "C-x C-x" と較べて曖昧ということで現在無効にしている。
     これの代替キーシーケンスを定義しても良いかもしれない。
     といいつつ現実の端末に存在するものを登録しなければ意味がない。
     (そういう意味では "CAN @ ?" もこれに対応する現代的な端末が実在するのか怪しいのであるが。)
 
     思うに s-x だとか H-x だとか A-x を送りたければ CSI 2 7 ; ... ; ... ~ を使えば良い。
     何故 Emacs が "CAN @ ?" に対応しているのかは謎である。
 
     →実はこれは isolated esc と同じ方法を用いて区別して受信可能かもしれない。
     しかし、何れにしても "CAN @ ?" に対応している端末は殆どないので、対応する理由がない。
     https://superuser.com/questions/407391/super-key-over-ssh によると Konsole がこの形式を使うそうだ。
 
 2017-03-04
 
   * syntax: bug ヒアドキュメントによる nparam の更新が追いついていない。
 
     これは何でかというと nparam の計算に stat 保存点を超えた過去の情報を用いているからである。
     部分更新をしている為に過去の情報が書き換わったとしても
     stat 保存点で解析状態が一致したと見なされてしまい、
     其処で解析が中断してしまうのがいけない。
 
     これを解決する為にはヒアドキュメントの word に相当する部分は
     一気に解析する様に修正しなければならない。
     結局 word 部分は最終的には独自の方法で読み取るのが良い様な気がする。
 
     或いは暫定的に範囲を指定して stat を消去する様な機能があったような…?
     →昔その様な処理の仕方をしていたような気がするが、いま確認してみるとない。
     恐らく何か問題が色々生じて結局その方法は使わないという事になった様な気がする。
     記憶が正しければそれは time ... や function func () だとか func () を解析する時の話だった。
     結局何れの場合でも一回の解析で行けるところまで解析するという事になった。
     ヒアドキュメントでもその様に実装するのが一貫している。
 
   * syntax: ヒアドキュメント 終端 word 着色
 
     todo: 取り敢えず RDRS 等と同様に完全に入れ子を追跡する様に実装する。
 
     $() ${} の入れ子も含めた実装が必要になる。
 
     実は、通常通りに解析してしまって、
     後の着色で一様な色に塗り潰してしまうという方策で良いのではないか。
     しかしそれだと tree-enumerate の際に $() の内部で着色が起こる気がする…。
     % 特に部分更新などをすると確実に内部での着色が発生するのでは…??
     % →部分更新の時は一番外側の単語についても着色が判定されるから特に
     % 部分更新仮想で内科に依る違いは発生しないと思われる。
 
     取り敢えずの実装として通常通りに解析する様に変更した。
     単に ble-syntax:bash/ctx-heredoc-word から
     ble-syntax:bash/ctx-redirect に処理を委譲するだけで良かった。
     ヒアドキュメント特有の処理は ble-syntax:bash/ctx-heredoc-word/check-word-end
     の方にしかなかったからである。
     また、同時に CTX_RDRI, CTX_RDRH の単語を上から塗りつぶす様にした。
     しかし、やはり予想通り $() の内部などの単語の着色は発生してしまっている。
 
 2017-03-02
 
   * syntax: パラメータ展開・算術式評価内部の quote 除去が為されない状況での _ble_syntax_attr
 
     以下の項目で対応しきれなかった (対応しないことにした) ものをここにまとめる。
     cf. #D0375 "2017-03-02 [2016-08-06] syntax: extquote と "${}" の入れ子に関して"
 
     > - $(()) の中の () のネストに関しては対応していない。
     >   つまり () が一つでも挟まれば quote 除去が有効であるかのように着色される。
     >   →これは対応した。
 
     - $((a['1+1'])) などの添字の quote 除去は有効であるが、現実装では quote の着色はしていない。
       つまり $(('1+1')) などと同様に quote 除去が為されない物として着色を行っている。
 
       これに対応する為には $(()) の中でも [] に対応するネストを判定する様にしなければならない。
       ※一方で [] の中では () に対応するネストの判定はしなくても良い。
 
     - $(("${hello}")) などの構造では CTX_QUOTE の中で自身が有効かどうかを判定して
       自身の着色を変更したりするのは面倒なので、普通に (有効であるかの様に) 着色している。
 
       算術式の場合には quote 除去されないと分かっている時点で文法エラーになるので
       1文字目をエラーの色にするというので良い気がする。
       パラメータ展開の内部の場合には quote 除去されないからと言ってエラーにはならない。
 
     - bash では "${var# ... }" の中の '' は quote 除去される一方で、
       "${var:- ... }" の中の '' は quote 除去されない。
       この実装では取り敢えず quote は除去されるという取り扱いである。
 
       これらについては包括的に振る舞いを調査する必要があるだろう。
       他にも様々な種類のパラメータ展開があるし、
       また将来的に各種類のパラメータ展開についての詳細な構文解析にも対応する可能性がある。
       (特に ${var//a/b} の quote (\?) の取り扱いがややこしいのでこれは視覚的に分かる様にしたほうが良い。)
 
     - 現状では $(("a")) はエラー着色になっているが実は文法的に有効である。
       同じクォートでも $(('a')) や $((\a)) は文法的に駄目。
 
     - Bash 5.1 以降では (('a')) がエラーになる様に文法が変わった。
 
 2016-07-15
 
   * isearch: 現在の履歴内の位置を % で表示しているが、
     これは検索の進捗状況の表示の方が分かりやすいのではないか。
 
   * complete: declare の引数を特別扱いしているがこれも compgen があればそれに従うべきでは。
     もしくは、何か特別な処理をするとしても compgen を介して特別な処理をするべきではないのか。
 
     現状の実装だと、declare などの変数を宣言する組み込みコマンドについて、
     ユーザが complete によって補完の制御を行う事ができない。
 
 2016-07-08
 
   * prompt: 最終行・先頭行に何か表示する機能があっても良い。
 
 2016-07-07
 
   * isearch: 正規表現検索?
 
     →取り敢えず vi-mode で実装した #D0513。incremental ではない。
 
     正規表現で incremental にすると一度通り越したものに一致する可能性があるので直観的でない。
     もし incremental にする需要がある場合には再度考える必要がある。
     因みに、emacs は (分かりにくい動作だが) 現在の位置から続きの検索をする。
 
   * edit: 置換モード (正規表現・固定文字列・globパターン)?
 
     その為には置換前・置換後を入力する欄を別に表示する必要がある。
     入力欄でも様々な binding が使えた方が嬉しい。
 
 2016-06-22
 
   * tui: prompt-toolkit という物がある様だ。ちょっと観察してみるのも良い。
 
     基本的には補完候補を勝手に出すという事と、
     表示の仕方が emacs auto-complete と同様に
     overlay によって実現されているという事。
 
     所で overlay で実現するためには複数行で編集を行っている時に、
     下の行にある内容を記憶しておく必要性が生じる。
     Emacs の場合には表示している内容を完全に内部に保持しているので問題にならなかった。
     (a) 現在の実装で実現するためには内容を完全に記憶するか、そうでなければ
     (b) 複数行で編集を行っている場合には枠の位置・大きさを変更する際に
     毎回下の方にある行を再描画するかといった事が必要になるだろう。
 
     Bash では 2 次元配列を実現するのは辛いので
     結局内容を完全に記憶するというのは余り嬉しくない事だろうか。
     と思ったが、表示領域の幅 (COLUMNS) さえ把握しているのであれば、
     実は 1 次元配列の上に terminal の内容を保持してしまっても問題ない気がする。
     というか枠の大きささえ決まっていれば普通に sub window の様な物も
     bash で実現する事ができる。今まで余り考えたくないとして避けていたことだが、
     この方法ならば楽である。
 
   * tui: GUI Window System を整える? Window を出したり消したりだとかそういう事。
 
 2016-04-05
 
   * tree-enumerate による skip の実装と解析一時中断の不整合に関して。
 
     ble-syntax.sh: ble-syntax/parse/shift.impl2 の問題点である。
 
     現状の方法では、解析一時中断を行った時に shift 対象の高速な列挙が出来なくなる。
     唯一の現実的な高速化手法は "直前非空白要素の位置" を管理するように変更する事である。
     これは解析自体の動作とは全く関係なく、_ble_syntax_tree/stat/nest の配列としてのデータ構造を拡張するという事である。
     解析自体の実装とは直交して実装する事が可能と思われるが、新規情報の管理コストが増えるという問題点が残る。
 
     →一方で tree-enumerate を使った場合には閉じている単語内部の shift を省略できるなどの利点がある。
       最終的にはこれらを組み合わせたような shift が必要になるだろうと考えられる。
       もう少し詳しく考察を行う必要性がある。
 
 2015-12-20
 
   * complete: 履歴を用いた候補生成? 特に単語について。
 
     2018-09-23 これは動的略語展開によって部分的には対応された。
     しかし処理の重さから一度に全ての候補は計算しないし、
     また文法的な単語ではなくて COMP_WORDBREAKS によって分割された単語である。
     これを本当に対応しようと思ったら background でプログラムを
     走らせるなどの事が必要になる気がする。
 
 2015-11-21
 
   * 公開までに追加であった方が良いかも知れない物
 
     + 拡張性の提供 (拡張の仕方の説明)
       + theme の枠組を整える事 (setting files の置き場?)
         ble-color-list
       + 文字コード拡張 (Unicode との mapping)
       + 端末制御コード拡張
         tput からもっと積極的に読み込むべきなのでは?
         cmap/default.sh に加えて cmap/tput.sh 的な物も?
         > minimal.sh, xterm.sh, rosaterm.sh の整理。
 
     + 簡単なキーボードハンドラのサンプル (テトリスとか? 或いは sentaku 再実装とか)
 
       サンプルとしては、端末の出力画面に現れる物よりは、
       画面を altscreen で完全に切り替える物の方が実装しやすいと思われる。
       それでいて、read -t 0 などを有効に使えるとなるとテトリスなどになるだろうか。
 
     + マウス対応
 
     + キーボード入力内容を全部 vbell で表示する方法?
 
 2015-11-06
 
   * まったく同じ nest 状態になると思われるのに解析中断が起こらない
 
     ☆これは表面上は何の問題も起きない。多少無駄な処理をするだけである。
       従ってそんなに対処に緊急を要しない。
 
       | function ble-syntax/parse/nest-equals {
       |   local parent_inest="$1"
       |   while :; do
       |     ((parent_inest<i1)) && return 0 # 変更していない範囲 または -1
     -->     ((parent_inest<i2)) && return 1 # 変更によって消えた範囲
       |
       | local _onest="${_tail_syntax_nest[parent_inest-i2]}"
       | local _nnest="${_ble_syntax_nest[parent_inest]}"
       | [[ $_onest != $_nnest ]] && return 1
     変更によって消えた領域を指している場合は、
     既に消えた領域のデータを捨てているので nest の判定を行う事ができない。
     そんな訳で解析中断はできないと判定されてしまうのである。
 
     ここで解析中断を出来るようにする為には消えた領域のデータも取って置いて、
     その上で全く同じ解析結果になったら解析中断を行う、という事になろう。
     以降の解析の動作に違いがなければ良いのだから
     過去の nest の状態だけが一致していれば解析中断には充分である。
     これは別項目として独立させて残す事にする。
 
     ※問題は解析領域拡大によって i1 が後退する事によって
       変化の無かった部分についても解析結果が消去されてしまう事にある。
 
 2015-08-20
 
   * エラー検出・表示の管理について
 
     現状
 
     現在エラーは様々な方法で使用者に対して提示している。
     解析の途中状態で既にエラーと分かる物については
     _ble_syntax_attr に ATTR_ERR を設定している。
     これは _ble_highlight_layer_syntax1_table を経由して表示の着色に反映される。
     もう一つのエラーの種類は入力したコマンドラインの末端で入れ子が閉じていない物である。
     これは一番最後の文字と対応する入れ子の開始点の色を変更する事によって提示する。
     この着色は解析点より前に対して行われるので部分更新の対象とする事は難しい。
     従って _ble_highlight_layer_syntax3_table を介して、毎回全消去・再計算を実行している。
 
     以下に改善したい箇所について列挙する。
 
     - この様に複数の方法を用いてエラーを提示しているのは少し醜い。
       もう少し統一した枠組を作っても良いのではないかという気がする。
 
     - ATTR_ERR を用いて設定したエラーは、
       後の処理で追加される単語毎の着色によって上書きされてしまう。
       つまり、折角エラー通知の為に着色を設定していても使用者に見えない事がある。
       別の場所にエラーを登録しても良いのではないかという気がする。
 
     - 各エラー項目に対して何が問題なのか・何のエラーなのかのメッセージを設定したい。
       これらのメッセージも枠組の中で管理して、カーソルの位置に応じて表示できる様にしたい。
 
     もう少し現状について調べて実装の方法について考える。
     先ずエラー情報を記録する為の配列の形式について。
     既存のエラー着色に使っている配列 _ble_highlight_layer_syntax3_table が気になる。
     これを拡張する形で実装する事はできないだろうか。。
     →この配列は部分更新できないような情報を保持するのに使っている。
       部分更新できない様な着色であっても今回の実装によって
       よりましな方法に変更できるのではないか、という気もするが、
       それは今回の実装が終わってから考えれば良い事である。
       (初めからその様な物にも対応できる様に今回の実装を設計するという事も出来るが
       複雑になるので、取り敢えずは何も考えずに実装する事を目指す。)
 
     つまり、_ble_highlight_layer_syntax3_table は non local な着色の為に使うとして残し、
     それとは別にエラーを管理する為の配列を作成する。
 
     部分更新の際の効率を考えると _ble_syntax_attr と同様に、
     編集文字列中の位置を配列のインデックスとする方法が良さそうに思われる。
     然し一方で、エラーの数はそんなに沢山になるとは考えがたい (sparse) なので、
     リストにして管理するという方針も考えられる。どちらの方が良いだろうか。
     リストにしている場合、"エラー設置点 エラー開始点 エラー終了点 メッセージ" というデータ形式になるだろうか。
     shift や解析中断後の再開に際してはエラー設置点を用いた filtering を行う。
     % このエラー情報の内容は解析の動作に全く影響を与えないし、
     % 解析が同じように進めば全く同じエラー情報を生成すると期待できるので、
     % 解析中断の判断基準に含める必要はないと考えられる。
     →本当だろうか。エラー開始点・終了点などの情報は解析状態が同じになっても異なる値になりうるのでは?
       特に、現在 _ble_highlight_layer_syntax3_table で管理している物はその最たる例である。
       ここで、エラー開始点・終了点が正しく設定される為には次の条件が必要である。
 
       エラー設置点を p1 とする。ble-syntax/parse の 1 step で i=i1 から
       i=i2 まで進む (但し i1 <= p1 < i2) 時、エラー開始点 p2, 終了点 p3 は、
       i1 <= p2 < p3 < i2 を満たす。
 
       この条件が揃っている時のみに現状の解析中断条件で部分更新安全である。
       因みに p2, p3 を設置点からの相対位置で記録しておけば shift の操作が必要なくなるのでその様にするべきである。
 
 2015-08-16
 
   * 入れ子構造を考慮に入れた効率的な単語着色
 
     現状: 新規生成単語及び消滅単語の範囲 (range1) に関して再度単語の着色を実行する。
 
     x 但し、着色は "消滅単語の存在していた範囲" 及び "新規生成単語登録位置の範囲"
       に登録されている単語及びその子孫だけになっている。
       本来は、range1 に被さっている全ての単語について処理を実行するべきである。
 
     - 考慮に入れるべき事として、将来的に解析を途中で停止した場合でもそれなりに動くような方法がよい。
       しかしながら未だ解析を終えていない部分については結局どうしようもないから、
       解析が完了している部分文字列について木構造を作成して処理する事になるだろう。
       結局、現在 shift を実行するのに用いているのと同じ事をする事になる。
       (そしてそれは tree-enumerate/.initialize で実装されているので余り気にする事はない。)
 
     方法
 
     a 一つの方法は tree-enumerate を使用して末端から順に単語の範囲をチェックしていく方法である。
       つまり、現状の shift の実装と同じになっている。
 
     b もう一つの方法は、先に単語の木構造の情報だけ構築してから、
       range1 に対応するノードを列挙して構築する方法である。
       木構造として親ノードの位置・子ノードの配列を保持していれば、
       指定した範囲に対応するノードの範囲を効率的に計算する事が出来る。
 
       ただし、木構造の情報の構築自体にどれだけのコストがかかるかについて考える必要がある。
       木構造は後ろから掘り出すようにして実行する為、
       更新範囲の beg から文字列の末端 iN 迄を完全に構築し直す必要がある。
       部分更新するというのが難しいと思われる。
 
       しかし、部分更新は全くできないのでは等と考えていたが、
       考えてみると意外と部分更新も出来るのではないかという気になってくる。
       更新範囲に含まれていないノードの内部構造に関しては実は更新の対象ではない。
       また、更新範囲より前にあるノードの内部構造についても同様である。
       但し、親ノードの位置は、更新範囲より前にあるノードであっても更新する必要がある。
 
     c 或いは、parse の過程でより分かり易い木構造データも同時に構築してしまうという手もある。
 
       x parse の内部状態を増やせば増やす程、解析中断が難しくなるが
         最終的に構造を再構築するのであれば結局中断してもしなくても同じかも知れない…?
         しかしながら木構造を考えずに parse した後、木構造に対する更新を行った方が処理量は少なくなるはずである。
         というのも木構造を考えながら parse する事にすると、
         更新の必要のない文法的処理も木構造の構築と同時に実行してしまうからである。
         それよりは、文法的処理で必要最低限の所を parse で処理して、
         木構造の構築について必要最低限の所を後の処理で実行する、という形の方が良さそうである。
 
       o ただ、parse の過程で木構造も一緒に構築するようにした方が、
         データ同士の依存関係が整理されて良いという側面もある。
         parse の後で木構造としてどの範囲を更新するべきかを決定するのは面倒でありバグを生む原因にも成る。
         →parse の後で処理をする際にも何らかの "原則" を決めてその下で実装するなどした方が良いと思う。
         (逆に言えば上手に原則を決める事さえ出来れば、parse で木構造を構築する事の利点はなくなる。)
 
 
     入れ子構造の実装後に改善できる箇所
     - tree-enumerate-in-range 及びその呼出元
       現在は愚直に範囲内に設置されている単語識別子を
 
 2015-08-15
 
   * syntax: `function ...' において関数名の部分に使用した履歴展開を解釈する?
     履歴展開だけを解釈する新しい文脈が必要になると思われる。
 
     然し乍ら、履歴展開の結果として複数の単語になる場合などを考えると、
     そもそも一つの単語として読み取って良いのかなど疑問点が残る。
 
     % 或いは、その場で履歴展開としての妥当性を検証して色をつけてしまうという手もある?
     % →これだと正しく解釈されない。例えば履歴展開には $ が含まれて良いが関数名には $ が含まれないので、
     %   先に関数名としての切り出しを実行すると $ の直前で不正に関数名が中断する事になる。
 
 2015-08-14
 
   * 高速化: ble-syntax/parse: より厳密な shift 範囲の特定・省略?
 
 2015-08-11
 
   * 今後必要になる大きな書換・再実装は2つある:
     1 コマンドライン着色の効率的方法の模索
     > 2 shift の高速化の為の _ble_syntax_word, etc. のデータ構造の変更
 
 2015-02-24
 
   * layer の仕組みに対する問題提起
 
     | 現在の実装では各レイヤーは下のレイヤーが提供した文字配列を弄る事によって動作している。
     | しかし、実の所受け継ぐのは文字配列ではなくて描画属性の配列の方が良いのではないだろうか。
     |
     | o 先ず第一に実装の簡便さがある。
     |
     | o 次に、更新範囲というのは複数のレイヤーで似たような箇所になりがちなのではないかと思う。
     |   属性の配列で渡して置いてから一番最後の所で更新範囲に対して切り貼りをして文字配列を構築した方が良いかも知れない。
     |
     | x ただ、文字配列にするという事の利点も存在する。
     |   region 等の様に大域的に色を一時的に変更する様な物の場合、
     |   文字配列として region の下層にあるレイヤーについて記録を行っておく事は有意である。
     |   選択が解除された時に再び構築し直すというのは時間が掛かる。
     |
     |   但し、その様な動作をする物は限られている様にも思われる。
     |   殆どの場合には纏まった箇所でコンパクトに更新が行われる。
     |
     | x 括弧の対応などの場合、まとめて描画属性から文字列を構築する場合に細かい最適化が出来ない。
     |
     |   複数のレイヤーの描画属性の配列からまとめて文字列を生成する場合、
     |   複数のレイヤーが報告した更新範囲を総合してその範囲で文字列を再生成する事になる。
     |   しかし、括弧の対応など、実際の変更が小規模に渡るにも拘わらず、
     |   離れた二点で実施される色付けの場合には、変更の実体に反して範囲が拡大する。
     |
     |   今迄の様に文字列を各層で構築する方式の場合には、
     |   更新を各層の関数の中で自由に行う事ができるので、
     |   自身の変更の update に関しては最適な方法で更新する事ができる。
     |
     |   とはいいつつも更に上のレイヤーに渡す更新範囲はやはり巨大な物になる為、
     |   上のレイヤーでの合成作業が大域に渡る事は考えておかなければならない。
     |   実のところ合成作業についてはちゃんと実装していない。
     |   region に関しては可能な限り最適な方法になる様に実装したが滅茶苦茶複雑になった。
     |   実際の実装では被覆によって隠される更新などについては考慮に入れなくても良いが、
     |   複雑になりそうだという事に代わりはない。
     |   結局、内部的に描画属性の配列を持って更新に望まなければならないという事態になりそうだ。
     |
     | 何れにしても現在の実装は、今後拡張していく上で非現実的な感じがする。
     | ベースを (下層の情報を含まない) 描画属性の配列を上流に渡す方法に変更した方が良いのではと思う。
     | region 等の実装の際には cache を行う様にする等の工夫をその上で実装する様にしてみたい。
     |
     | また、実装が複雑になるが仕様がない。
     | 取り敢えず現在の所まともに着色を行っている所が syntax だけなので、
     | これを ble-highlight-layer:syntax に対応する上で考えてみる。
     |
     | ble-highlight-layer:syntax の内部で三つの描画属性の配列を用意し、
     | これらの三つの描画属性の配列を総合する事で文字列を構築する様にしてみた。
     | 可もなく不可もない感じの実装である。
     | 少なくとも各層で文字列を構築する様な実装はしたくない。
     | これぐらいが丁度良い実装の複雑さである様に思う。
 
     将来的には描画属性の配列で対応できる様にする。
 
 2015-02-23
 
   * bleopt_suppress_bash_output 制限
 
     - SIGWINCH (ウィンドウサイズ変更) の時に bash の表示する物になってしまう
 
   * 描画ちらつき: DCH や ICH 等を用いた効率化?
 
 2015-02-18
 
   * エラーメッセージの設定を可能にする
 
 2015-02-16
 
   * syntax: ToDo
 
     - [[ 条件式の文法。より正確に。特に括弧の入れ子。
 
       →括弧の入れ子というのはどういう意味であったか?
       今試してみた所括弧の入れ子などは関係なく ]] が来れば条件コマンドは終了とみなされる様である。
       例えば $ [[ ( [[ == ]] ) ]] は構文エラーになる。初めの ]] で条件コマンドが終了と解釈される為である。
 
 2013-06-10
 
   * sword で quote を正しく処理する?
     これは少なくとも解析器が出来た後に考える。
 
 2013-06-01以前
 
   * ble-decode
     + [kbd] terminfo からの読み取り (entry 名は tmux が参考になる)
     * ble-bind: -s オプションで文字入力の羅列を指定できる様にする (2019-02-10 #D0915 で実装)
 
   * 説明書
     + 文字コード decoder の追加方法
     + keysequence を指定する文字列の文法 (2018-09-23 done)
     + スタイルを指定する文字列の文法 (2018-09-23 done)
 
     取り敢えず GitHub の Wiki 上に作る事にした。
 
 
 *******************************************************************************
     Done (実装ログ)
 -------------------------------------------------------------------------------
 
 2023-10-01
 
   * canvas: Unicode 15.1.0 対応 [#D2078]
 
     対応してみたのは良いが GraphemeCluster でテストが失敗する様になった。U+924
     がどうも GraphemeClusterBreak では通常文字という事になっているが、test では
     extend であるかの様な振る舞いを要求する様になっている。どういう事だろうか。
 
     先ず GraphemeBreakProperty.txt に関しては 15.0.0 と 15.1.0 で変化はない。一
     方で GraphemeBreakTest.txt に関しては大幅に追加されている。その中で U+924
     に関しては combining とされている。と思ったが違った。どうも間に挟まっている
     文字が何か新しい規則に組み込まれた様だ? 何やらおかしな property が割り当て
     られている気がする。
 
     Extend_ConjunctLinkingScripts_ConjunctLinker_ExtCccZwj
 
     うーん。UAX #29 の変化を調べてみると実は 15.1.0 で新しく色々と追加されてい
     るという事が分かった。これはまた対応に時間がかかりそうだ。
 
     * InCB=Linker 及び InCB=Extend の直前で切れてしまうのではないか疑惑
 
       現在の Unicode の定義だとInCB=Consonant | InCB=LinkerEx が離れるし、
       InCB=LinkerEx | InCB=LinkerEx も離れるのではないか?
 
       或いはちゃんと InCB=Linker や InCB=Extend は Extend でもあるのだろうか?
       generate-table.sh では検出できていないから InCB={Linker,Extend} は何の
       GraphemeClusterBreak も持っていないのではないかと疑われる。ZWJ も
       InCB=Extend に含まれていそうなのに検出できていないのは何故?
 
       →と思って改めて確かめて見た所、どうやらちゃんと検出して沢山エラーが発生
       していた。改めて確認する必要がある。重複は Extend と ZWJ のみで発生してい
       る。また、全ての InCB=Linker 及び InCB=Extend は同時に Extend または ZWJ
       でもあった。特に ZWJ は InCB=Extend であった。つまり、以下の様な三種類に
       分類する事ができる。
 
       - Extend (1) InCB=None
       - Extend (2) InCB=Extend
       - Extend (3) InCB=Linker
       - ZWJ        InCB=Extend
 
     * 結局 GraphemeCluster の中に Indic_Conjunct_Break も埋め込まれた形になって
       しまったので、IndicConjunctBreak のテーブルは最早不要の気がする。
 
       * 既に実装した分について IndicConjunctBreak を参照しない形に書き換える→
         書き換えた。簡単だった。
 
       * 本当に GraphemeClusterBreak だけで実装できるのか確認する。実際に実装し
         てみる。
 
       * 以下はもう使わなくなった IndicConjunctBreak を取得するコード。
 
         後で使いたくなった時の為に何処かに取っておいた方が良いだろうか。うーん。
         然し、これはほぼ GraphemeCluster/c2break と実装は同じなので敢えて分かり
         やすい所に取って置く必要もない。なので、ここに残しておくだけにする。
 
         | #%< canvas.IndicConjunctBreak.sh
         |
         | function ble/unicode/IndicConjunctBreak {
         |   local code=$1
         |   ret=${_ble_unicode_IndicConjunctBreak[code]}
         |   [[ $ret ]] && return 0
         |   ((ret>_ble_unicode_IndicConjunctBreak_MaxCode)) && { ret=0; return 0; }
         |
         |   local l=0 u=${#_ble_unicode_IndicConjunctBreak_ranges[@]} m
         |   while ((l+1<u)); do
         |     ((_ble_unicode_IndicConjunctBreak_ranges[m=(l+u)/2]<=code?(l=m):(u=m)))
         |   done
         |
         |   ret=${_ble_unicode_IndicConjunctBreak[_ble_unicode_IndicConjunctBreak_ranges[l]]:-0}
         |   _ble_unicode_IndicConjunctBreak[code]=$ret
         |   return 0
         | }
         |
         | ## @fn ble/unicode/IndicConjunctBreak/get-left str index [opts]
         | ##   @var[ret] InCB 参考特性の値を返します。
         | ##   他は ble/unicode/GraphemeClusterBreak/s2break-left と同じです。
         | function ble/unicode/IndicConjunctBreak/get-left {
         |   local s=$1 i=$2 opts=$3
         |   if [[ $opts != *:code:* ]]; then
         |     local code
         |     opts=$opts:code
         |   fi
         |   ble/unicode/GraphemeClusterBreak/s2break-left "$s" "$i" "$opts"; local ext=$?
         |   ble/unicode/IndicConjunctBreak "$code"
         |   return "$ext"
         | }
 
   * ext/fzf: $() は blink-matching-paren on の時 `` より遅い [#D2077]
     https://github.com/junegunn/fzf/commit/e0b29e437be458066fca4dab39b282dfc11466f6
 
     という謎情報があるが GitHub のエラーで現在ページが見えない。
 
     →これは単に fzf の実装が bind マクロを通じて実装されている為に、$() が実際
     にマクロで入力される文字列の中に含まれていると blink-matching-paren on の時
     に bash が sleep を挟んで一致する括弧の highlighting を実行するという話だっ
     た。
 
     そもそも ble.sh では blink-matching-paren に対応していないし、対応するとし
     ても delay は入れない様にするだろうし、またマクロを通じた実装もできるだけ避
     ける様にしたい (とは言いつつ bash-3.? with ble.sh で fzf key-bindings を使
     おうとすると結局マクロによって文字列を入力する様になる)。
 
   * canvas: ｼﾞｮﾝ 等の文字列の幅が端末と整合していない [#D2076]
 
     "ｼﾞｮﾝ" 文字幅が正しく計算されていない。emacs はちゃんと処理できている様だ。
     つまり、規則に従うと濁点は前の文字に吸収される事になっているが実際にはそう
     ではないという事。これは規則の穴として処理するべき事の気がする。
 
     →実際に ble/util/s2w で計測してみた所、幅3という事になっている。そもそも何
     故そのような事になっているのだろうか。処理を確認する。うーん。grapheme
     cluster として読み取っている。そしてその grapheme cluster の大きさを台字の
     大きさをそのまま返す様にしているのが問題の様である。
 
     ? そもそも他の端末では正しく実装できているのだろうか (もしくはどの様に実装
       しているのか)
 
       →うーん。他の端末ではちゃんと濁点も幅を持って描画されるし、論理的にも内
       部では半角の幅を持って計算されている様である。更に言うならば行末での振る
       舞いを見る限りは grapheme cluster としての認識もされていない。
 
       xterm, terminology, lxterminal で確認した。可能な限り Unicode に書かれて
       いる物をそのまま実装しようとしている kitty ですらも半角カナの濁点・半濁点
       に関しては GraphemeCluster の Extend ではなく独立した文字として行折返し等
       を処理している様だ。
 
     つまり、そもそも grapheme cluster として取り扱わない様に修正するべきである。
     念の為、濁点がどの様なカテゴリになっているのかについて確認する。
     ble/unicode/GraphemeCluster/c2break の出力を確認すると濁点は
     GraphemeClusterBreak Extend という事になっている。
 
     [修正方法]
 
     make/canvas.emoji.sh を確認してみると中で _ble_unicode_GraphemeClusterBreak
     に値を設定しているので、これに倣って値を上書きして良いのではないかという気
     がする。周辺の文字で Extend になっている文字の一覧を見ることができれば良い。
     元にしているデータベースの方を先ずは確認する
 
     * 元にしているデータの時点で Extend になっている。
 
     * 半角カナ周辺では濁点と半濁点だけが Extend になっている様に見える。
       FE20..FE2F に combining ligature というのがあるが、これは明示的に前の文字
       を修飾する物なので、半角カナの様な特別な取り扱いは不要である。
 
       →取り敢えず半角カナの濁点と半濁点だけを修正の対象とする事にする。
 
     * recjt: もう一つ気づいた事は、元の GraphemeClusterProperty.txt では一緒に
       GeneralCategory も表示していてカタカナの濁点・反濁点は Lm になっていて他
       の Extend と異なっている。或いは、GeneralCategory が L? の時には特別扱い
       して表を修正するという事も考えたがそれはやめておく事にする。
 
       x 勝手に GraphemeClusterBreak を変更すると他の用途で参照した時に変更され
         たデータベースを参照する事になって混乱の元である。
 
       x Extend / L? が全て同様の取り扱いで良いのか分からない → と思ったが
         "Extend # L" で検索してみると半角カナの濁点・反濁点しか存在しなかった。
         そういう意味で GeneralCategory と組み合わせて判定しても良いのかもしれな
         い、と思ったがそもそも処置が必要な文字が半角カナしか現状で存在しないの
         であれば、無闇に将来追加されるかもしれない他の Extend # L? にも影響が出
         る様な実装にするべきではない。
 
     * 因みに make/canvas.emoji.sh の中で多くの端末で例外的な振る舞いとなってい
       る 0x1F3F{B..F} の範囲の文字についても、この際、既定で修正を加える様にで
       きないだろうか。
 
     2023-10-01 手で弄る様にしたら Unicode の例から自動生成したテストが失敗する
     様になってしまった。将来的な事を考えると端末毎に修正した
     GraphemeClusterBreak を切り替えたりする事なども考えられるので、直接元の
     GraphemeClusterBreak を弄るのも避けるべきだろうか。代わりに
     _ble_unicode_GraphemeClusterBreak_custom という配列に修正した
     GraphemeClusterBreak を記録する事にした。
 
     x これにより多少 GraphemeClusterBreak を読み取る時間が伸びてしまうのではな
       いかと思うが、ASCII に関しては処理をスキップして効率化しているので余り気
       にしなくても良い気がする。
 
 2023-09-20
 
   * complete: auto_complete 内容を入力しきっても auto_complete mode の中にいる [#D2075]
 
     auto_complete 候補が全然ないのに何故か auto_complete mode に入っている気が
     する? 何故? と思って改めて調べてみたが特に enter が呼び出されている気配はな
     い。
 
     提示された文字列が全てユーザーによって入力された時に auto_complete mode
     から抜ける機能は実装されていないという事だろうか。うーん。然し、既に
     auto_complete mode に入った状態だったのだからそのままでも良い気がする。と
     思って実装を確認したら既に同じ状態になったら自動的に抜ける様に処理してい
     る気がする。と思ったら実装が変だ。修正する事にする。
 
     これは ble-0.3 にも影響するので独立した項目にしたほうが良い。
 
 2023-09-18
 
   * layer: pattern で指定する layer に対するリクエスト (requested by johnalotoski) [#D2074]
     https://github.com/akinomyoga/ble.sh/discussions/362
 
     問題は効率よく実装できるかという事。部分更新ができれば良いが簡単かどうか分
     からない。
 
     また、一個のパターンもしくは有限個のパターンしか登録できないのは困る。
 
     a 一つの layer で一つの pattern という事にして複数のlayer を登録する事を想
       定するとますます遅くなる様な気がするし、またパターンを増やす毎に layer 定
       義の clone をしなければならくなり、また記録対象に関しても prefix 等を使っ
       て load/store しなければならくなり効率が悪くなり、管理が面倒になる。
 
     b 一方で、一つの layer で複数の pattern に対応しようとすると実装が複雑にな
       る。結局合成の処理は実装しなければならないし、部分更新を考えるのだったら
       結局各 pattern について前回の一致を記録する必要がある。そうでなくても全部
       記録してそれから調べるという事になる気がする。
 
     またどうせ実装的には region の複数 region 対応と同じ様な実装になる様な気が
     するので実装を共有する事ができる様な気がする。multi-range 的な base layer
     として実装するのが良い気がする。だとすれば結局 store/load 的な事はしなけれ
     ばならないので a の方針でも良いのではないかという事になってくる。
 
     但し、実質的に a 的な実装になるとしても layer の配列に登録するのが面倒とい
     う事を考えると b 的な内部インターフェイスにするというのは可能性としてありで
     ある。その場合には複数 layer をまとめる機能として実装するのか sublayer 的な
     物として実装するのか区別するのが良い。
 
     * 入れ子の配色パターンを指定したり、一致の仕方によって色を切り替える事がで
       きるようにしたり、より高度な指定を考えることはできるだろうか。
 
       これを突き詰めていくと実質 parse に近い事ができてしまう様な気もするが、そ
       うなった場合既存の構文解析の実装とどちらの方が良いのかという事にならない
       か? と思ったが、さすがに既存の構文解析の方は無限の階層を作ることができる
       し (単なる正規表現ではできない) 効率に関しても single pass (既存) と
       multi pass (入れ子着色) なので既存の方法の方が速いだろう。
 
     取り敢えず region の実装をコピーして観察してみるのが良い気がする。と思った
     が、今回実装しようとしているのは部分更新も必要になってくるので単に region
     の実装を一般化するだけでは全然足りない。やはり一から実装し直した方が良いの
     ではないかという気もする。
 
     ? うーん。正規表現を採用している限りは部分更新は不可能なのではないか。例え
       ば a(.{9}x)? というパターンに対して、前回の文字列が a2a4a6a8a0z だったと
       すると (0-1 2-3 4-5 6-7 8-9) という一致になる。z を x に書き換えると
       dirty range は 10-11 だけであるが、最終的な一致は (0-11) にならなければな
       らない。つまり、dirty range が幾ら後ろの方にあったとして、既に確定してい
       る一致が幾つあったとしても、それらを上書きする形で新しい一致が現れる可能
       性を常に排除できない。
 
       正規表現の表現能力が高すぎるからだろうか。先ず、extglob の時にも同様の事
       が当てはまる。
 
       glob (extglob なし) の時にはどうだろうか。* の最長一致を考える事にすると
       やはり問題は起こる気がする。但し、複数のパターンを跨いで遡らなければなら
       ないという事はない。単一のパターンしか考えていないのであれば。然し、今後
       の拡張性などを考えると単一の単純 glob パターンだけで着色を行うというのは
       制限が大きすぎる。それにそんなに便利そうではない。
 
       glob の最小一致という事にしておけば一度確定した一致は内容が変わらない限り
       は安定である。これに関しては複数パターンを組み合わせたとしても論理的な問
       題は生じなさそうである。一方で、複数パターンを組み合わせた実装にする為に
       は「各位置についてそれぞれパターンを試して行く」か「全てのパターンについ
       て最近接で次に現れる位置を計算して一番近い物から順に適用していく」などの
       実装を行う必要が出てくる。前者は重すぎて駄目であり、後者は余りに複雑であ
       る。
 
       などの事を考えると、表現力においても実装の複雑さや効率においても、正規表
       現を使うのが妥当と思われる。部分更新を諦める必要はあるがその方がすっきり
       して良いのかもしれない。
 
       取り敢えず単一正規表現の場合について考えれば良い。毎回先頭から末尾まで正
       規表現で範囲を抽出する事にする。
 
     * done: 先ずは着色範囲を決定する必要がある。
 
       取り敢えず実装した。着色範囲を決定したら後は region を拡張する形で実装し、
       一般化も行った。と言っても region との違いは各 selection に色を割り当てら
       れるという事と、複数の selection が接している可能性があるという事。然し、
       それだけだと速度的に遅くなってしまうかもしれないので、範囲決定について複
       数 selection がある場合でもちゃんと各要素について検査する様にした。
 
       動いている気がする。region も新しい枠組みの方に乗り換える事にした。少し修
       正した。ちゃんと動いている気がする。
 
     * done: later:{pattern} として実装した。これを呼び出して使う様にすれば良い。
 
     * done: _ble_highlight_layer__list は _ble_highlight_layer_list に改名する。
 
     * done: 使い方を簡単に base.pattern.bash の中にも記述する。例を config の中
       に入れようかとも思ったが単純すぎるのでわざわざ登録する程でもないだろうか。
 
     * done: base.pattern.bash から pattern.bash に変える
 
       {pattern} という名前にしたがこれを継承して新しい layer を定義するという訳
       でもないから pattern にした方が良い? と思ったが、ユーザーからは見えないだ
       けで内部的にはこれから派生した layer を自動的に定義している。そういう意味
       で {pattern} という名前は OK。
 
       一方でファイル名が base.pattern.bash になっているが、これについては
       pattern.bash で良いのではないかという気がする。ユーザーが明示的に自分で派
       生する事は想定していないのだから。
 
     * done: うーん。zsh syntax highlighting の highlighter を見たら pattern が
       glob で regexp が正規表現を使った物である様だ。なので regexp に改名するべ
       きではないだろうか。一方で glob を用いた実装についても考える余地がある。
       但し、glob を用いた物は単に正規表現に変換して適用すれば良いだけの気がする
       が。
 
       https://github.com/zsh-users/zsh-syntax-highlighting/tree/master/highlighters
       https://github.com/zsh-users/zsh-syntax-highlighting/tree/master/docs/highlighters
 
       glob に関しては最長一致と最短一致の二種類が考えられる。色々考えると実装は
       似た様な物になるだろうし一緒に実装してしまった方が良い気がする。
 
       →結局 {pattern} で regexp/glob 全てに対応する事にした。
 
     * done: 現在の実装だと regex を追加した順序が保たれないのではないか→これは
       修正した。独立した配列に順番に記録する。
 
     * done: auto_complete で仮挿入されている物に対してまで着色パターンが適用さ
       れている。仮挿入部分に対しては一致するべきではないのではないか。仮挿入部
       分を削除した物に対して選択範囲の決定を行って、その後で sel の中身を修正す
       る事にする。
 
       と思ってその様に実装してみたら更新されない事がある。どうやら
       auto_complete で予想された内容と同じ内容しか入力していない場合には DMIN<0
       になるので処理がスキップされてしまう。処理は前回の text の内容と一致する
       時にのみスキップするべきなのである。その様に実装した。
 
       →前回の text を記録していて問題になる可能性はあるか? もしそれで問題にな
         るのであればその他のあらゆる情報の記録で問題が発生する可能性がある気が
         するので気にしない事にする。
 
     * done: やはり /initialize-vars と /declare は分離するべきでは?
       /initialize-vars で VARNAMES がクリアされてしまうのは都合が悪い。といって
       毎回全て構築するのも無駄な処理の気がする。
 
 2023-09-17
 
   * memo: テストに使用した bashrc を独立させる [#D2073]
 
     色々の試行錯誤が bashrc の中に溜まっていくが後で参照する為に、各議論項目に
     対応する bashrc を残したい。各番号に割当を行う事にする。
 
     また一つの番号で複数ファイル memo/ 以下にあるものについてはまとめたい。二つ
     だと微妙だが三つ以上は全部まとめる事にする。note.txt や done.txt の中に参照
     がある場合にはそれも更新する (といってもほんの少ししかなかった)。
 
   * global: make scan したら問題が沢山出ている [#D2072]
 
     久しぶりに実行したら問題が沢山あるので修正する。今まで test-*.sh を検査の対
     象にしていなかったのを含めたのが原因の一つである。ble/test に指定しているコ
     マンドの中では builtin の使用に対するチェックを省略する事にした。他に累積で
     様々の見落としができていたので修正した。
 
   * github: windows-latest で CI テストが失敗する問題 [#D2071]
     https://github.com/akinomyoga/ble.sh/pull/363 test
 
     symbolic link の振る舞いが変わってしまっている。手元の mingw を更新して振る
     舞いを確認してみることにする。msys2 で pacman で最新版に更新する。エラーは
     発生しない。という事は github のテスト環境だけで起こる問題なのだろうか。
 
     * それとは別に interactive session で ble check bash すると履歴展開の振る舞
       いで結果が異なる事に気付いた。これについても修正しなければならない。
       interactive session と外で history -p の振る舞いが違うのだろうか。
 
       $ export q=\' line='$'$q'\'$q'!!'$q'\'$q
       $ bash -Hc 'builtin history -s histentry; builtin history -p "$line"'
       $'\'!!'\'
       $ bash -c 'builtin history -s histentry; builtin history -p "$line"'
       $'\'histentry'\'
       $ (set -H; builtin history -s histentry; builtin history -p "$line")
       $'\'!!'\'
       $ (set +H; builtin history -s histentry; builtin history -p "$line")
       $'\'!!'\'
       $ builtin history -s histentry; builtin history -p "$line"
       $'\'!!'\'
       $ set +H; builtin history -s histentry; builtin history -p "$line"; set -H
       $'\'!!'\'
 
       よく分からないが -H のコマンド実行の時にだけ問題が生じる様だ。他の文脈で
       は -H をつけても外しても問題の振る舞いは見られない。
 
       更に別の version も調べてみたら振る舞いは色々の様だ。
 
       bash -c xxx  3.0 展開失敗; 3.1..dev 展開
       bash -Hc xxx 3.0 展開失敗; 3.1..4.0 展開, 4.1..None
       (xxx)        3.0 現在コマンドに展開; 3.1..4.0 展開; 4.1..None
       (set +H;xxx) 3.0 現在コマンドに展開; 3.1..4.0 展開; 4.1..None
 
       xxx = builtin history -s histentry; builtin history -p "$line"
 
       Note: bash -c '(xxx)' および bash -Hc '(xxx)' はそれぞれ () のない場合と
       振る舞いは同じだった。
 
       然し、この振る舞いは現在観測している振る舞いと一致していない? と思ったが、
       スクリプトとして実行する場合にはちゃんと動いているというという事はスクリ
       プトとして実行している時は bash -c と一緒の振る舞いということで、これは自
       然である。一方で、ble session で ble check した時に失敗するのは ble
       session の中では常に展開されずに !! のままだということで、これも
       consistent である。
 
       さて、この振る舞いの違いが何処から来るのかについて確認したい。単に
       interactive かどうかで判定するだけでは駄目である。 bash -Hc の時にも振る
       舞いが変化する。逆に set +H の時に振る舞いが変わるという訳でもない。シェ
       ルかサブシェルかでは切り替わらない様に見える。今の所分かっている条件は i
       も H もない場合にのみ 4.1..dev で展開が発生する。
 
     [原因]
 
     | GitHub の blesh-test repository (private) を使ってまたテストを実行する事
     | にした。どうもそもそも symbolic link 自体が作られていない気がする。find
     | で見る限りは ln で作ったファイルが全て通常のファイルになってしまっている。
     |
     | 調べてみたが msys2 や Git for Windows 辺りで最近 symbolic link 周りが変更
     | されたという話も見当たらない。
     |
     | a msys2 ではなくて Windows の ln ls readlink find 等のツールを拾ってしまっ
     |   ている? と思って type -p でパスを確認してみたがちゃんと msys のを呼び出
     |   している気がする。(そもそも windows のものを呼び出していたら、使い方が
     |   違うので、別のエラーメッセージが発生しそうなものである)
     |
     | b 一方で Git for Windows の release note を見ると winsymlinks に加えて
     |   sysfile または nativestrict を指定する必要がある様な感じに書かれている。
     |   然し、sysfile を追加しても振る舞いに変化はない。
     |   https://github.com/git-for-windows/build-extra/blob/main/ReleaseNotes.md
     |
     | c 或いは一旦システムを開始した後に個々のコマンドで振る舞いを変更したい場
     |   合は MSYSTEM という環境変数を使えという話が以下のリンクで言及されていた。
     |
     |   https://github.com/msys2/MSYS2-packages/issues/3941#issuecomment-1680093862
     |
     |   これは最近のコメント (2023-08-16) だが最近変更でもあったのだろうか。其
     |   処で MSYSTEM にも MSYS の値をコピーして試してみたが振る舞いに変化はない。
     |
     |   そもそもこの Issue の報告者は lnk を MSYS に指定している。
     |
     |   https://github.com/msys2/MSYS2-packages/issues/3941
     |
     |   これはどういう意味だろうか。試しに lnk を追加してみたがやはり振る舞いに
     |   変化はない。
     |
     | d また Git for Windows の release note に戻ると winsymilnks:nativestrict
     |   (NTFS junction を用いた物) についても言及されていたのでそれも試してみた
     |   がやはり振る舞いは変わらない。
     |
     | 突然動かなくなったがこれはどういう事だろうか。取り敢えず test3.sh の中に
     | は ble.sh の中で最近変更した物は含まれていない様に思われる。それに問題は
     | 明らかに windows において ln がリンクを作れていない事によっている。その他
     | の要素がこの振る舞いに影響しているとは思えない。念の為 windows-2019 で振
     | る舞いが変わるかどうか確認する。
     |
     | e もう一つの可能性は MSYS はコロン区切りの筈だけれど、実際には何故か : が
     |   入っていると winsymlinks はちゃんと動かない。そして、今までは MSYS が空
     |   だったので問題が起こっていなかったが、新しく disable_pcon が追加された
     |   事で正しく認識されなくなってしまった?
     |
     |   →実際に MSYS=winsymlinks を試してみたら動く様になった。謎である。lnk,
     |   sysfile, nativestrict 等と組み合わせて指定してもちゃんと動く。
     |   hello_world という存在しない設定を指定しても動く。何と
     |   winsymlinks:disable_pcon の順番でもちゃんと動く。これが意味する所は
     |   MSYS の winsymlinks が設定されているかどうかをチェックする部分のコード
     |   が間違っているのではないかという事。念の為 disable_pcon:winsymlinks を
     |   自分で代入した場合も試してみる。期待通り動かない。sysfile:winsymlinks
     |   の場合でも動かない。
     |
     |   本体のテストの方は ble/path#append ではなくて ble/path#prepend を使えば
     |   何とかなりそうだ。
     |
     |   一方で、手元の msys2 では disable_pcon を MSYS に設定していても別にテス
     |   トは失敗しない。中では disable_pcon:winsymlinks の様な形になっている筈
     |   である。
     |
     | 取り敢えず workaround は分かったが winsymlinks の指定位置で振る舞いが変化
     | するのは理解できない。この振る舞いを制御しているのは何処だろうか。どうも
     | Cygwin のソースの中自体に winsymlinks というのが隠れている?
     |
     | 実は CYGWIN 環境変数は : 区切りではなくて ' ' 区切りの可能性?
 
     環境変数 MSYS (そして upstream の CYGWIN) は実はコロン区切りではなくて空白
     区切りである。今までの GitHub workflow では MSYS が空だったので単に
     winsymlinks が追加される形になって問題は発生していなかった。所が、最近 MSYS
     として disable_pcon が既定で設定される様になった。ここで winsymlinks を追加
     する為に : を使用した為にちゃんと winsymlinks が認識されなくなったのが問題
     の原因であった。この為にそもそも全く symbolic links が作られなくなったのが
     テストが失敗する様になった原因であった。
 
 2023-09-14
 
   * bashbug: "convert-meta on" の時 job 関連の bash の警告が出る [#D2070]
     Ref #D2069
     Ref memo/D2070.bashrc
 
     bash: DEBUG warning: mark_dead_jobs_as_notified: ndead (0) != js.j_ndead (1)
 
     色々試してみたがどうも bash-bisect の中でビルドすると問題が発生しなくて、
     bash-dev の中でビルドすると問題が発生する。何が悪いのだろうか。と思ったが、
     そうではない。release ビルドにしているから問題が発生しないのである。という
     事はそもそもこの問題がどこで発生するようになったのかも定かではない。もしか
     すると bash-5.2 の時点でも問題として存在しているのかもしれない。
 
     そもそもこのエラーはどのタイミングで発生するのだろうか。問題発生のテストケー
     スを最小化する事は可能だろうか。
 
     うーん。convert-meta が関係しているというのも何だか不思議な事である。単に
     locale が間違っているという事で起きているのではない。locale が間違っていて
     も convert-meta が off であればこのエラーは生じない。convert-meta on で
     bind 関連の問題が生じている時に限ってこの警告が発生する。
 
     最小ケースを作るか或いは bash に直接修正を入れるかのどちらかという事になる。
     先ずエラーが検出されているのは mark_dead_jobs_as_notified (jobs.c:4858) で
     あり、変数の値の不一致である。しかしこの不一致がどの時点で発生したのかとい
     うのは明らかではない。更に、convert-meta の関連性は更に不明である。或いは
     convert-meta がうまく行かない時の無限ループに関係があるのだろうか。意図的に
     マクロの convert-meta を介した無限ループを作ってみたら readline: maximum
     macro execution nesting level exceeded というメッセージが表示される。うーん。
 
     ? マクロ無限ループのメッセージが出たらそれに対して vbell を出そうとしてそれ
       で job のエラーが表示されているという可能性はあるだろうか。受け取った CSI
       の数 (19) と比べてみようと思ったがそれよりは警告が出る回数 (14) は少ない
       様である。visible-bell を潰してもやはり問題は出る。なので visible-bell は
       関係ないだろう。
 
     ? 次に確認するべきことは果たしてどのタイミングでメッセージが表示されている
       のかという事。文字列の受信が始まってから問題が発生している様な気がする。
       ble-decode/.hook -> ble-decode/EPILOGUE -> ble-edit/bind/.tail ->
       ble/util/idle.do -> ble/complete/auto-complete.idle ->
       ble/complete/auto-complete.impl ->
       ble/complete/auto-complete/source:syntax ->
       ble/complete/candidates/generate ->
       ble/complete/candidates/generate-with-filter substr ->
       ble/complete/source:command -> ble/complete/source:command/gen ->
       ble/complete/source:command/gen.1 -> ble/util/conditional-sync
 
       うーん。どうやら ble/util/assign の中で conditional-sync を実行しようとす
       ると問題が生じる様子である。更に言うと locale は関係ない。
 
     取り敢えず最小再現は以下まで小さくなった。この設定で C-t を二回押すと問題が
     再現する。locale などは関係ない。
 
       source out/ble.sh --norc --attach=none
       builtin bind -x '"\C-t": v=${ sleep 0.1 & }'
 
     以下が最小再現コードである。ble.sh と関係なく再現する。ここから少しでも減ら
     そうとすると何か変な事が起こる。謎である。
 
       enable -f /home/murase/opt/bash/dev/lib/bash/sleep sleep
       function f1 {
         for a; do :; done
         builtin sleep 0.1
       }
       builtin bind -x '"\C-t": v=${ f1 a & }'
 
       job error caused by funsub + bind + loadable builtin
 
     これに関して言えば ble.sh の側でできる事はないし、そもそも bash-5.3 はリリー
     スされていないし、問題はデバグ中に発生しただけで実際の構成では発生しないの
     で気にしなくて良い。
 
   * decode: "convert-meta on" in bash >= 5.2 with broken locale (reported by 3ximus) [#D2069]
     https://github.com/akinomyoga/ble.sh/issues/361
     Ref memo/D2069.bashrc
 
     kalilinux で存在しない locale を使っていると left/right が使えない
 
     そもそもこれは kalilinux 特有の問題なのだろうか。或いは locale が壊れていた
     ら常に起こる問題なのだろうか。一つの可能性は locale が見つからない事によっ
     て bash readline の meta 云々の設定が変わってしまって、それが理由で矢印キー
     が認識されなくなっている可能性。
 
     自分の手元の Arch で問題を再現することができた。起こっている現象としては
     ESC (27) が全く受信できていないという事。ble/decode/.hook の呼び出しを直接
     観察しても受信されていない。
 
     * reject: 実行した初回の bind -spX の出力が違う C-? C-u C-w がちゃんと bind
       されていない。然しこれは関係があるのだろうか。
 
       --- debug.0.txt^I2023-09-14 06:09:29.718861055 +0900
       +++ debug.1.txt^I2023-09-14 06:08:15.982192253 +0900
       @@ -5,7 +5,7 @@
        # arrow-key-prefix (not bound)
        # backward-byte (not bound)
        # backward-char (not bound)
       -# backward-delete-char (not bound)
       +"\C-?": backward-delete-char
        # backward-kill-line (not bound)
        # backward-kill-word (not bound)
        # backward-word (not bound)
       @@ -112,7 +112,7 @@
        # undo (not bound)
        # universal-argument (not bound)
        # unix-filename-rubout (not bound)
       -# unix-line-discard (not bound)
       +"\C-u": unix-line-discard
        # unix-word-rubout (not bound)
        # upcase-word (not bound)
        # vi-append-eol (not bound)
       @@ -162,7 +162,7 @@
        # vi-subst (not bound)
        # vi-tilde-expand (not bound)
        # vi-undo (not bound)
       -# vi-unix-word-rubout (not bound)
       +"\C-w": vi-unix-word-rubout
        # vi-yank-arg (not bound)
        # vi-yank-pop (not bound)
        # vi-yank-to (not bound)
 
       うーん。正常に動いている場合でも最初はこの様な状態になっている様なのでこ
       れは関係ないという気がする。
 
     起動した後に LANG='en_CA.UTF-8' を設定しても特に問題は発生しない。やはり起
     動時の初回のプロンプトで問題が起こるという事なのだろうか。
 
 
     * 更に手元の chatoyancy でも単に以下の bashrc で起動するだけで再現する。
 
       LANG='en_XY.UTF-8'
       source out/ble.sh --norc
 
       更に bash-4.0..5.1 まで問題は発生しない。bash-5.2 で実行すると core dump
       する。システムの bash で発生する。bash-dev でも同じ問題が発生している (そ
       れに加えて job 関連の警告が locale によって出る)。
 
       問題発生ケースの最小化について。これは bind 関係の問題だから bind を何と
       か色々やる事で再現できないだろうか。しかし、一回コマンドを実行すると直る
       事などを考えると単純ではない様に思われる。何らかの発生条件があるというこ
       と。取り敢えず手動 attach した時にも再現するかどうかを確認する。
 
       →手動 attach でも再現する。prompt の中で実行するとちゃんと受信できないと
       かそういう事なのだろうか? と思ったがそれも変だ。一文字でも入力したら
       prompt attach であっても PROMPT_COMMAND の外側に出てちゃんと bind の中で
       処理をする様になるので。
 
       という事を考えると、一回コマンドを実行すると問題が発生しなくなるという所
       に重点を置いて調べるべきだろうか。
 
       * 取り敢えず空のコマンドを実行しても問題は継続する。
       * C-x C-v で表示を行っても問題は継続している。
       * execute-command 経由でコマンドを実行すると直るが、これは普通にコマンド
         として実行するのと同じ様なものであるので、新しいことがわかったとは言え
         ない。
 
         或いは具体的に bash の中で何が起こっているのか追跡するべきなのかも知れ
         ない。特に keymap 関連の処理で受信された 27 がどの様に消えてしまうのか
         を確認する。コマンドを実行すると直るという事はやはり keymap のデータ構
         造が壊れているとかそういう事なのだろうか。或いは、コマンド実行時に戻し
         きれていない何らかの設定が存在している?
 
       * external-command を実行した時にどうなるかも確認する → 実は
         external-command を実行した場合でも問題は再現しなくなる。
       * ble/term/{leave,enter} の実行だけでも問題はなくなる。
       * ble/term/rl-convert-meta/{leave,enter} で問題が解消する。
 
         然し何故問題が発生するのだろうか。_ble_term_rl_convert_meta_adjusted の
         値はちゃんと最初から 1 になっている。つまりどこかで adjust が実行された
         筈ということ。PROMPT_COMMAND の内部から attach した時は readline の設定
         が復元して戻ってしまうという事だろうか。
 
         実際に振る舞いを確認してみると初回だけ convert-meta on になっていた。
         bash-5.1 以下ではちゃんと off になっている。
 
         prompt attach でも直 attach でも問題は発生する。つまり、attach のタイミ
         ングで回避できる物ではない様に思われる。
 
       うーん。これを回避する為には最初のキーの受信の時点で convert-meta off を
       明示的に実行するべきだろうか。然しそうだとしても最初の最初のキーが 27 の
       時にそれが欠けてしまうという問題が残る。或いは attach した直後に
       convert-meta off を実行すれば問題はなくなるのだろうか? と思ったが実際に
       attach の時に ble/term/enter を実行している筈なのでちゃんと convert-meta
       off は実行されている筈である。
 
       _ble_term_rl_convert_meta_adjusted の初期値は? → OK。ちゃんと空である。
       つまり、1 が設定されていた時点で何処かでちゃんと convert-meta off が実行
       されていたという事。それにも関わらず convert-meta が何らかのタイミングで
       on になってしまう。
 
       ? 特に、手動 attach をした場合でも問題が再現するというのは変だ。更にわかっ
         た事は、ble-bind -f C-t ... を実行していると手動 attach では問題が発生
         しなくなるが、prompt attach では問題が継続するという事。ble-bind を実行
         しているかしていないかで変わるというのも不思議な挙動である。
 
       ? もうひとつ不思議なのは convert-meta 絡みなのに LANG=C の時には問題が生
         じていないという事。locale の初期化に失敗した時にだけ勝手に
         convert-meta on になるという事なのだろうか。
 
       readline 最初の locale の初期化の際にエラーが起こると convert-meta を設定
       するという動作になっているのだろうか。その時点で convert-meta を off に戻
       す必要があるが、readline が最初に受け取った byte というのが消滅するのであ
       ればそれをスクリプトの設定の側から検出する事ができない。最初に受け取った
       文字を見て勝手に 27 が前に存在していたという事を推測するのは堅牢でない。
       ユーザーが入力した文字を勘違いする可能性がある。
 
       a bash に対する修正要求をする? 或いは過去に convert-meta を設定したのであ
         れば後で bash が勝手に convert-meta を変更するのは変だという事にはなら
         ないか。例えば convert-meta の状態を内部的には auto on off の３つにして
         おいて、既定値は auto で、ユーザーから一回でも指定があったら on/off に
         して、locale 失敗時には auto の場合にのみ convert-meta を再設定する。
 
         或いは、auto on off は保持しておいて、内部的な既定値を locale 失敗時に
         設定する。auto の時には内部的な既定値を参照する。という具合の実装に
         bash が変更してくれれば問題は解決する。
 
       b 別の方法としては readline の locale の初期化を強制的に実行する方法を考
         える。その後であれば勝手に convert-meta が設定される事もないだろう。
 
         と思ったが本当だろうか。普通に開始したとしても壊れた locale を設定した
         直後は readline の振る舞いが変になるのではないか → 少なくともユーザー
         コマンドとして LANG=en_ZZ.utf8 などの値を設定しても特に振る舞いが壊れる
         という事もないようだ。
 
         a read -e xxx </dev/null 等として強制的に readline の locale の初期化を
           済ませられないかと思って試してみたが振る舞いに変化はなかった。と思っ
           たが、よく考えたら read -e は ble.sh が上書きして subshell の内部で自
           前の read loop で実行するので何れにしても readline は呼び出さない様に
           なっている
 
         b 今度は builtin read -e xxx </dev/null として見たがそれでも駄目。
 
         c builtin read -e xxx <<< yyy としてみても駄目。一応変数 xxx には期待し
           た文字列が格納されている。 -e を指定しても読み取り元が tty でなければ
           readline は初期化されないという事なのかもしれない。
 
         d 今度は builtin read -et 0.1 xxx としてみたらどうやら動く様になった。
           builtin read -et 0.000001 でもちゃんと動く。builtin read -et 0.000001
           </dev/tty でも動く。
 
           但し、ble-bind -f ... で何かを設定しないとちゃんとは動かない。
           ble-bind -f を指定する事によって何かが初期化されてそれとの順番との兼
           ね合いだろうか。うーん。builtin read -et 0.000001 よりも前に ble-bind
           -f を実行している必要がある。順番を逆にするとやはり問題が発生する。
           ble-bind の中の何らかの操作が関係しているのだろうと思って調べてみると、
           単に ble/decode/initialize だった。然し、ble/decode/initialize が
           bash の振る舞いに影響を与えるというのも不思議といえば不思議である。更
           に調べると _ble_decode_initialize_inputrc=none だと
           ble/decode/initialize を呼び出しても問題が継続する。diff にすると収ま
           る。ble/builtin/bind/read-user-settings を呼び出すと収まる。
           ble/builtin/bind/read-user-settings/.reconstruct を呼び出すと収まる。
           然し、ble/builtin/bind/read-user-settings/.collect を呼び出しても収ま
           らない。不思議だ。と思ったら、.reconstruct の中で呼び出している
           LC_ALL= LC_CTYPE=C ble/bin/awk なのかもしれない → これだった。単に
           LC_ALL= LC_CTYPE=C で何かのコマンドを呼び出せばよかった様だ。
 
         e 今度は builtin read -et 0 xxx とした場合には動かない
 
       うーん。遅延で手動で attach する場合には、最初から convert-meta on になっ
       ていて、自分で convert-meta off に設定してから ble-attach すれば問題は生
       じない。
 
       まとめると最初のプロンプトを表示した後に locale の初期化とそれに応じた
       convert-meta の設定が行われる様である(本当か?)。
 
       存在しない locale が設定されている時に何処かのタイミングで convert-meta
       on に設定されるのが問題である。
 
       ? convert-meta on が設定されている時に ESC (もしくは ESC [ の組み合わせ)
         が完全に消滅するのは何故なのか。
 
         | 別の形で受信される等の事も起こっていない。素直に考えると M-[ という組
         | み合わせの文字に変換されても良い気がするのに、それすらも受信されない。
         |
         | 実は bash-5.1 以下では M-[ という形で受信できている可能性もある? と思っ
         | て確かめてみたが bash-5.1 以下では最初から convert-meta off になって
         | いた。やはり convert-meta on の時には ESC [ が受信ができない状態になっ
         | ていると考えるべき。
         |
         | 取り敢えず bash のソースコードを調べてみると convert-meta on の時はど
         | うも M-[ を ESC [ に分解する機能なのではないかという気がする。だとす
         | ると、そもそも ble/decode/.hook で 27 を受信できないという問題は独立
         | の様な気がする。何故振る舞いが変わるのだろうか。そもそも本当に
         | convert-meta は bash の _rl_convert_meta_chars_to_ascii に対応してい
         | るのだろうか? → bind.c を確認してみる限りはちゃんと対応している筈。
         |
         | 参照している箇所を少しずつ潰して行った所
         | _rl_function_of_keyseq_internal での取り扱いが振る舞いに影響を与えて
         | いる様だ (然し blame で見る限りこの部分は 12 年間変更されていないので
         | 他の部分の変更が波及してここでの振る舞いに変化をもたらしていると考え
         | られる)。うーん。readline.c の中の convert_meta を参照している所
         | (_rl_dispatch_subseq) も同時に振る舞いに影響を与えている。どちらか一
         | 方だけ潰しても問題は発生しない。両方をコメントあうとした時に問題が生
         | じなくなる。
         |
         | →分かった気がする。ble.sh は isolated ESC を区別する為に ESC ... を
         | C0 9B ... に変換して受信している。この時 convert-meta on だと C0 が変
         | な風に分解されてしまう (というか無限ループになる?)。結果として何も受
         | 信できずに終わるということの気がする。
         |
         | つまり "ESC [" → "C0 9B [" → "ESC @ 9B [" → "C0 9B @ 9B [" → …
         | という具合に無限ループになって恐らく中断されて何も受信できないという
         | 事になっている。
 
         ble.sh は isolated ESC と区別する為に ESC [ を C0 9B [ に変換している。
         一方で C0 は convert-meta の時には ESC @ に分解される
         (_rl_dispatch_subseq)。ESC @ は isolated ESC と区別する為に C0 9B @ に
         変換される。というのを繰り返して先頭の文字に対して無限の展開が起こって
         しまう。恐らくこれが強制的に中断される結果として ESC [ が全く受信されな
         いのだろうと思われる。_rl_function_of_keyseq_internal の中でも同様にし
         て C0 が ESC @ に分解される事によって振る舞いが変になっている。
 
     取り敢えず半ば偶然ではあるが workaround が見つかったのでそれを実装する事に
     する。これは ble.pp の環境確認の段階で実行するのが良さそうである。
 
   * make uninstall を提供するべきではないか [#D2068]
 
     そしてそれはそんなに難しくないはず。インストール対象は全て変数に入っている。
     ただし、INSDIR, PREFIX 等の変数を指定した時には、インストール時と全く同じ設
     定を覚えておく必要がある。然し、変数に依存するとしても対応するのは自然の気
     がする。
 
   * prompt: prompt ruler の位置は elapsed marker よりも後であるべきでは (motivated by U-Labs) [#D2067]
     https://www.youtube.com/watch?v=OS3I1cCCw_Q
 
     * ok: というか printf EOF などに対する振る舞いもちゃんとしているのだろうか?
       → これは試してみた所ちゃんと処理されている。
 
     これは ble-edit/exec/.adjust-eol の中で 呼び出しているのが問題である。呼び
     出し箇所を変更することにした。 ble-edit/exec/.adjust-eol は一箇所でしか呼び
     出されていないのでその呼出元に移動すれば十分である。
 
 2023-08-26
 
   * menu: append-arg で対応する項目がない時 bell (motivated by bkerin) [#D2066]
     https://github.com/akinomyoga/ble.sh/issues/354
 
     2023-09-14 色々考えたがやはり bell を鳴らすのを既定の動作とする事にした。
 
 2023-08-17
 
   * Makefile: github/workflows の macos-latest で失敗する [#D2065]
 
     色々実験した結果、どうやら make-3.81 では以下の規則があった時に三つ目に合致
     するファイル名の時であっても、一つ目の規則を適用してしまう様である。3.82 で
     はちゃんと問題なく動作する。
 
     | $(OUTDIR)/doc/%: % | $(OUTDIR)/doc
     | 	$(CP) $< $@
     | $(OUTDIR)/doc/%: docs/% | $(OUTDIR)/doc
     | 	$(CP) $< $@
     | $(OUTDIR)/doc/contrib/%.md: contrib/%.md | $(OUTDIR)/doc/contrib
     | 	$(CP) $< $@
 
     よく見てみるとこの make-3.81 における問題は contrib.mk にも既に書かれていた。
     contrib.mk における回避方法は三番目の規則をより詳しくすると言う物だったが、
     実は一つ目の規則を消して代わりにファイルを一つずつ記述する方が現実的の気が
     する。その様に変更する事にする。
 
     x contrib.mk で定義されているマクロ名に綴り間違いがある。序でにこれも修正し
       ておく。
 
 2023-08-16
 
   * PKGBUILD: 色々とけちがついているので修正する (requested by willemw) [#D2064]
     https://aur.archlinux.org/packages/blesh-git#comment-929483
 
     * provides & conflicts を修正した
     * depends & makedepends の修正
     * /usr/share/licenses/blesh に配置するライセンス
 
   * external: bash-3.2 初期化で無限ループになる  [#D2063]
 
     bash --norc で開始した後に source out/ble.sh しても問題は発生しない。
 
     →これは単に ~/.bashrc の方のバグだった。ble/util/idle.push のサポートが無
     い時に ble-import -d 経由で無限ループが明示的にできていた。
 
 2023-08-15
 
   * 2023-07-24 mc-4.8.29 で動かなくなっている (reported by mooreye) [#D2062]
     https://github.com/akinomyoga/ble.sh/issues/62#issuecomment-1646969652
 
     以下の内容を受信している。以前は単一行を受信していたのに複数行に分かれたの
     が問題という事だろうか。
 
     | declare -- _ble_edit_str=" mc_print_command_buffer () { printf \"%s\\\\n\" \"\$READLINE_LINE\" >&13; }"
     | declare -- _ble_edit_str=" bind -x '\"\\e_\":\"mc_print_command_buffer\"'"
     | declare -- _ble_edit_str=" bind -x '\"\\e+\":\"echo \$BASH_VERSINFO:\$READLINE_POINT >&13\"'"
     | declare -- _ble_edit_str=" PROMPT_COMMAND=\${PROMPT_COMMAND:+\$PROMPT_COMMAND"
     | declare -- _ble_edit_str="}'pwd>&11;kill -STOP \$\$'"
     | declare -- _ble_edit_str="PS1='\\u@\\h:\\w\\\$ '"
 
     然し、遡ってみてもこの部分の変更が行われたのは 4.8.26 ととても古い。一方で
     4.8.28 では遅延なく mc が開始される事は確認した。何故だろう。と思ったが後で
     気づいたのだが mc 4.8.28 でも ble.sh は正しく起動していなかった。代わりに
     sh に fallback していたが遅延なく失敗していたという事の気がする (mc の側で
     待ち時間を変更したのかもしれないし或いは出力内容によっては ble.sh session
     がクラッシュしていた可能性もある?)。
 
     取り敢えず accept-line で LINENO の上限を上げてみるとちゃんと起動する様になっ
     た。mc の中で ble.sh も一応動作している様だ。然し色々と問題がある。
 
     x fixed: 現在は取り敢えず $_ble_edit_LINENO -le 5 で判定しているが本来はもっ
       とちゃんと判定するべき。例えば、_ble_edit_str に含まれている文字列も検査
       してユーザーコマンドを誤って実行しないように対策をしておく事にする。新し
       い関数に分離した方が良いかもしれない。
 
       →これは PROMPT_COMMAND=${PROMPT_COMMAND... という時にのみ特別扱いをする
       様に変更した。その他の場合には別に通常通りにコマンドを強制実行しても問題
       ない。
 
     x fixed: C-o が何かの拍子に効かなくなる。どうやら C-o をエスケープシーケン
       スで送信するモードに入ってその後で戻らなくなってしまう事があるようだ
       (xterm)。
 
       set -o emacs を実行してモードを変更すると問題が発生する。sleep 1 の実行中
       に C-o 等のキーを入力すると状態が元に戻る。
 
       →mc の内部では modifyOtherKeys の調整を強制的に無効にすることにした。然
       し、それでも set -o emacs にすると C-o に対して待ち時間が発生する様になる。
       これは単に M-+, M-_ に対する応答がないからだと思われる。これについては
       ble.sh の側で M-+ および M-_ に対して現在のモードに関係なく応答する様に調
       整すれば良い様な気もするが、其処までする程の事でもないし plain Bash でも
       同様の問題が発生するのだから取り敢えずは考えない事にする。
 
     x fixed: mc がプロンプトの抽出に失敗している気がする
 
       | →これは罫線描画の問題でもあった。mc が考える罫線の幅と端末の罫線の幅が
       | 一致していなかった為に描画が乱れていたのだった。実際には、 "-- 挿入 --"
       | という文字列がプロンプトとして取り扱われていたのだった。また、"-- 挿入
       | --" がプロンプト文字列という想定の元ではちゃんと C-o を押した時の振る舞
       | いも正しくなっていた。
       |
       | 問題は "-- 挿入 --" を表示したままで mc に本物の方をプロンプトとして認
       | 識させる事は可能なのかという事。現在のカーソル位置はちゃんと本物の方の
       | 行にあるのでカーソル位置を合わせても恐らくちゃんとは認識してくれない。
       |
       | mc がプロンプトを抽出する瞬間だけ "-- 挿入 --" を消すという事も考えたが、
       | そもそも mc はどの瞬間にプロンプトを抽出しているのだろうか。というか、
       | そもそもどの瞬間にコマンドが終了してプロンプトが表示されたと判定してい
       | るのだろうか。PROMPT_COMMAND の段階では未だ何も表示されていない筈。うー
       | ん。\e+ または \e_ に対して応答した時点での内容を見ているという事なのだ
       | ろうか。
       |
       | 実際に試してみると C-o C-o を連続して押すと M-_ M-+ SP C-h というキーが
       | 送信されてくる様だ。更に振る舞いを見ると C-o で mc に戻る時に M-_ M-+
       | が送信されて、次の C-o で端末画面に移動する時に SP C-h が送信される様で
       | ある。
       |
       | 然し C-o "sleep 1" LF "sleep 1" LF C-o として見たがその途中でプロンプト
       | を更新している筈なのに M-_ も M-+ も何も受信していない。という事を考え
       | ると実は純粋に最後の出力内容でプロンプトを決めているという事なのだろう
       | か。
       |
       | * mode-indicator がなくてもプロンプト抽出できない
       |
       |   mode-indicator を修正して MC_SID が設定されている時には何も表示されな
       |   い様にした。しかしそれでもちゃんと抽出できていない。C-o から実行した
       |   時にはちゃんとプロンプトを抽出できているが、mc から直接コマンドを実行
       |   した時にはプロンプトがそもそも表示されていないのである。これはどうい
       |   う事だろうか。
       |
       |   調べてみると一応は mc からコマンドを実行する時でも ble.sh の gexec を
       |   経由してコマンドが実行されている様である。一方で何故プロンプトが表示
       |   されないのか、というと…。
       |
       |   mc の内部からコマンドを実行した時にコマンドの終了をどう検出しているの
       |   だろうか。例えば、M-+ 等のキーを予め設定して置いてそれによる処理が呼
       |   び出されたらその時点でプロンプトを読み出すのだろうか。と思って確認し
       |   てみたが mc の内部から実行した時には無駄な入力は一切していない。とい
       |   う事を考えると、PROMPT_COMMAND から呼び出している pwd 及び kill -STOP
       |   が怪しい。うーん。普通の bash だと kill -STOP が処理されるのはプロン
       |   プトが表示されてからと言う事なのだろうか。
       |
       |   →取り敢えず kill -STOP はPROMPT_COMMAND から削除して自前で kill
       |   -STOP を呼び出す様に変更する事にする。一旦は動いた様に見えたが単純に
       |   コードが壊れて ble.sh が開始していなかっただけだった。終了しても良い
       |   のかもしれない。
       |
       |   kill -STOP の実行をプロンプト表示の直後にしてもやはり問題が生じる。
       |
       | * done: 初回の実行に関しては gexec/.end で kill -STOP を実行しても初回
       |   の PROMPT_COMMAND に対応する処理は実行できない気がするので、寧ろ
       |   PROMPT_COMMAND の中で変数を設定してそれを読み取って kill -STOP を
       |   ble/textarea#render の最後で実行する様にした。然し振る舞いは変わらな
       |   い。よく考えたら mc は直接コマンドを入力して PROMPT_COMMAND を修正す
       |   るのだから、gexec/.end は何れにしても呼び出されるのだった。余り意味が
       |   ないのだったが、元の動作を考えるとこちらの方がより近いのでよしという
       |   事にする。
       |
       | * done: pwd のタイミングも遅延してみる? pwd の方のタイミングも関係して
       |   いるのかもしれないと思って、pwd の方も描画の後に実行する事にしてみた
       |   が振る舞いに違いはない。と思ったら ble/util/buffer.flush を実行してい
       |   なかった。これを実行する様にしたらちゃんと画面にはプロンプトが表示さ
       |   れる様になったが、mc は依然として拾ってくれない。
       |
       | * プロンプトの後に改行が挿入されている問題: どうも表示したプロンプトの
       |   次に改行が入って、そこから文字列が入力される状態になってい
       |   る。_ble_util_buffer の中身を見ても変な改行は含まれていない。plain の
       |   bash での振る舞いを見ると mc 内部からコマンドを実行した時には余分な改
       |   行が出力されている。どうやら mc は STOP でシェルが停止した後に改行を
       |   挿入して、更にその後でシェルにプロンプトを描画させてそれを拾っている
       |   様な気がする。
       |
       |   然し STOP の直後にプロンプトを表示する様にしても画面に何も表示されな
       |   くなってしまう。pwd だけ先に実行して直後に出力して、その後に STOP を
       |   実行する様にしても改行が次に表示されてしまう。
       |
       |   plain bash で PROMPT_COMMAND='echo -n 1 >&2;pwd>&16;echo -n 2
       |   >&2;kill -STOP $$;echo -n 3 >&2' 等として見ると 2 だけがプロンプトと
       |   して中執されている。これが意味するところは、pwd を実行してから停止す
       |   る迄に出力された内容を mc はプロンプトだと考えているという事ではない
       |   だろうか。では、なぜ現在の実装でそれが正しく抽出できていないのだろう
       |   か。
       |
       |   | そもそも微妙なタイミングの違いで出力されるされないが変わっている気
       |   | がする。色々実験した結果、pwd よりも前に出力した結果は画面に現れる。
       |   | 然し、pwd よりも後に出力した結果は表示される事もあるしされない事も
       |   | ある。直後に単に echo -n "..." >&2 で出力すると表示される場合が多い
       |   | が、一行でも IFS= eval 'local text=${arr[*]}' 的な事を挟むとそれだ
       |   | けで表示されなくなってしまう。この事から、本来は mc の意図としては
       |   | pwd の結果を受信したら bash の出力は捨てるモードに移行するのではな
       |   | いかという事。
       |
       |   → pwd ... kill -STOP の間に出力された内容は基本的には失われる。タイ
       |   ミングの都合で pwd 直後だとすり抜ける事がある。
       |
       |   kill -STOP の後に出力した内容は期間を置いても基本的には失われる。mc
       |   がどうやって plain bash のプロンプトを抽出しているのかは謎である。或
       |   いは、pwd の内容が変化した時にだけ読み取っているという可能性?
       |
       | * もう mc の振る舞いが全く分からない。プロンプトの抽出を mc がどのよう
       |   に実行しているかを調べるべきなのかもしれない。
       |
       |   1 read_subshell_prompt という関数があったから其処で何を受信しているか
       |     を調べてみたらカーソル表示・非表示の出力を拾っていた。どうも一番最
       |     初に受信した socket のブロックをプロンプトと考えているという事?
       |
       |     →何故か分からないが、ble/util/buffer で何も出力する物がない時には
       |     カーソル表示・非表示のシーケンスも含めて何も表示しない様にしたら、
       |     mc の中からコマンドを実行した時のプロンプトに関してはちゃんと正しい
       |     配置になる様になった。
       |
       |     どうも改行が勝手に挿入されていたのは空の ble/util/buffer の出力を
       |     mc が受信した時に勝手に改行を追加していたからではないだろうか。
       |
       |   2 それでも正しいプロンプトを抽出できていないと思ったら、どうもまた別
       |     の制御シーケンスの集合をプロンプトと思って受信している様だ。そもそ
       |     もプロンプトに対応する文字列をどうやって判定しているのかが気になる。
       |     タイミングの問題だろうか。或いは、改行以降を抽出しているという事な
       |     のか。
       |
       |     ble/util/buffer の出力している内容と read_subshell_prompt で受信して
       |     いる内容が一致しないと思っていたらどうやら一番最初だけしか
       |     read_subshell_prompt は呼び出されていない様だ。
       |
       |     内部の動作を確認してみるとそもそもプロンプトの更新をしていない。何
       |     故だろうか。should_read_new_prompt が設定された状態で次の出力が来た
       |     ら読み取る仕組みになっている。should_read_new_prompt は設定されてい
       |     る。然し、設定されてから次の出力を受信する前に関数が終了している。
       |     次に関数が呼びされる時には関数の初めで
       |     should_read_new_subshell_prompt がクリアされるので結局新しいプロン
       |     プトに更新するという処理が行われる事はないのである。
       |
       |     →何だか分からないが応急処置で色々変な事をしていたのを削除したら動
       |     く様になった。但し、vi.sh の mode-indicator "-- 挿入 --" は表示しな
       |     い様にしないとちゃんと動かない。色々弄ったのは
       |     memo/D2062/delay-mc-STOP.patch に残して置く事にする。
 
       [まとめ]
 
       * 表示が崩れる原因の一つは罫線の文字幅が一致していない事。これは単に端末
         の問題なので xterm を使えば問題は発生しない。
 
       * プロンプトの抽出に失敗していたののもう一つの原因は、
         ble/util/buffer.flush において出力内容が空であってもカーソル表示・非表
         示の端末制御シーケンスを ble.sh が必ず出力していた事がある。(というか今
         まで全ての bind/.tail でこれを必ず出力していた事になる?) これは出力内容
         がある時にだけ付加する様に変更する異にした。
 
       * また vi における mode-indicator for vi_imap を勝手にプロンプトと勘違い
         するので、mc の中では vi_imap に対してだけは mode-indicator は表示しな
         い様に変更する異にした。
 
     x ok: C-o を押した直後のカーソルの位置がおかしい。これはプロンプト抽出失
       敗とも関係しているのかもしれない。
 
       →これは問題はプロンプト抽出が直ってからは発生していない。
 
     x fixed: と思ったが、何度か C-o を押して画面を行き来すると結局プロンプトが
       消えてまたカーソル位置もおかしくなる。
 
       これは plain Bash の中では発生していない。というか plain Bash の中だと何
       度か C-o を押すと plain Bash が表示したプロンプトに置き換わる (mc が代わ
       りに表示するのは SGR が削除されて黒いのでそれとは区別できる)。
 
       M-_ M-+ を受信しているだけなのでその時にプロンプトを表示しなければならな
       い。というか、そもそも ble.sh は再描画している筈なのに表示されないのは何
       故だろうか。
 
       振る舞いを見ると M-_ 及び M-+ が受信されるのは C-o で端末に戻った時ではな
       くて、mc に戻った時の様である。うーん。つまり、mc に戻る直前の状態を mc
       が覚えておいてそれが端末に戻った時に復元されるということ? そして少しでも
       遅延があると mc に出力を食われて何も表示されずに終わってしまう。
 
       取り敢えず M-_ M-+ で mc に何かを送信するよりも前に必ず render & flush を
       実行する様にしたら問題が発生しなくなった。M-_ の方は render & flush しな
       くても良いが、M-+ の方は必ず render & flush しなければならない。
 
     2023-08-16 mc の外でも "-- INSERT --" の表示が無くなっていると思ったら、mc
     の時にだけ 1 に設定される筈変数の初期値が 1 になっていた。修正する。
 
 2023-08-13
 
   * history: bash-5.3 history -anrw で何処にも書き込まない [#D2061]
     https://lists.gnu.org/archive/html/bug-bash/2023-07/msg00165.html
     https://lists.gnu.org/archive/html/bug-bash/2023-08/msg00007.html
 
     bash/ChangeLog
     |                     8/2
     |                     ---
     | [...]
     | doc/{bash.1,bashref.texi},lib/readline/doc/hsuser.texi
     |     - history: document that if filename is not supplied, and HISTFILE is
     |       unset or null, the [-anrw] options have no effect
 
     と思ったが元からそういう振る舞いになっていた。議論を参照してみるとどうやら
     これまでの bash では何も設定されていないと ~/.history というファイルを勝手
     に作って其処に書き込む様になっていた様だ。
 
     * reject: 今までの bash の振る舞いを再現する様に書き換えるという手もあるか
       もしれないが振る舞いとしてやはり不自然なので ble.sh では bash-5.3 以降と
       同様に何も書き込まない事にする。
 
     * reject: history -anrw で HISTFILE が空の時にはエラーも出力しない?  ble.sh
       では HISTFILE が設定されていなくて -anrw を呼び出した時にエラーメッセージ
       を出力する様になっているが、bash-5.3 では何も出力しない様である。これにつ
       いてはやはりエラーメッセージを出力する方が自然の気がするので取り敢えずは
       エラーメッセージは表示する事にする。ユーザーが何かエラーメッセージを出力
       しない前提の使い方をしているという報告があった時にまた考える事にする。
 
     * done: エラーメッセージが常に history -a になっている。-anrw に応じて適切
       なオプション名を表示するべきではないか → FUNCNAME[1] の最後の文字から抽
       出する様に修正した。
 
     * done: ble/builtin/history/.get-histfile: 制御パス的に必ず true になる場所
       で [[ $histfile ]] で終了ステータスを設定している → 単純に削除する事にし
       た。
 
 2023-08-11
 
   * complete: faces menu_filter_* を設定しようとすると見つからない (reported by anuramat) [#D2060]
     https://github.com/akinomyoga/ble.sh/issues/352
 
     これは complete がロードされてから設定しなければならない。と思ったが、他の
     complete の face はロードする前でもちゃんと動く様になっている。という事は
     menu_filter_* についてもメインのファイルに移動する事にした方が良い気がする。
 
     その他には ble.sh の外で defface しているのは vim-airline だけである。これ
     についてはちゃんと vim-airline が読み込まれてから設定を行う様に
     blerc.template に書かれているので大丈夫のはず。
 
 2023-07-27
 
   * auto-complete: overwrite mode の時に self-insert が後続の文字を消去しない [#D2059]
 
     insert mode で表示されている auto-complete と一致する入力を
     そのまま確定するのは変ではないか。入力した文字数文だけ元々あった物を削除す
     る必要がある。
 
     一方で auto-complete を確定する時に元々ある文字列を上書きするのかどうかとい
     うのは微妙な問題である。現在の実装では insert mode かどうかに関係なくそのま
     ま挿入している。これはこの様な振る舞いの方が自然である。
 
     auto-complete 確定時の振る舞いを考えるとやはり auto-complete mode の時には
     上書きしないで挿入する様にする方が自然だろうかと思ったが、改めて考えると普
     通に入力した時の結果が auto-complete が background で走っているかどうかで降
     るまいが変わるのは問題である。auto-complete の確定は比較的非自明な操作をし
     た時にのみ起こるという事を考えたら、ac も起こらずに入力した時と一貫している
     必要はないが、通常の文字挿入に関しては ac が起こらずに入力した時と一致して
     いる必要がある。なので、やはり overwrite mode の時には auto-complete は一旦
     元の keymap に戻って入力を処理する事にする。
 
 2023-07-26
 
   * make: work around ecryptfs (reported by juanejot) [#D2058]
     https://github.com/akinomyoga/ble.sh/issues/347
 
     cp -p をすると mtime の秒以下が切り捨てられてしまうのでいつまで経ってもコピー
     元よりもコピー先の方が新しいという事にならない。
 
     a 一つの方法は cp -p をやめて直接 cp を実行するという事。これによって
       timestamp が更新されるので、いつの時点のファイルが其処にあるのかというの
       が分かりにくくなる。一方で、ファイルに変更がないのにファイルが新しくなっ
       た事によってキャッシュの再生成が起こるのではないかというのが気になる。
 
       →古いバージョンに一旦戻して動作を確かめるという時には寧ろ更新したほうが
       良いのではないか? と思ったが古いバージョンに戻す時には何れにしても git で
       戻した時にタイムスタンプが最新版になるので気にしなくても良い気がする。
 
     b 或いは常に 1s だけ加算してコピーするという事。然し、1s 加算するというのを
       実装するのが POSIX の範囲内で行おうとすると結構面倒である。それにファイル
       を一つコピーするのに一々幾つもコマンドを起動したくない。
 
     c 或いは問題のある filesystem の上で実行している時に限りコマンドを切り替える。
 
       ファイルシステムの検出方法は信用できるものはない様だ。例えば df -T /dir
       で表示できるが -T は標準化されていない。Linux の stat だと stat -f -c
       '%T' /dir としたらファイルシステムの名前が表示される。しかし BSD stat に
       はそもそも filesystem についての情報を表示する機能がない。mount -l につい
       てもシステムによって存在するかわからないし存在したとしても形式が同じかも
       分からない。また mount point を指定する必要があるので最初に df などを使っ
       て mount point を抽出しておく必要がある。
 
       或いは bash が入っているのであれば実際に cp -p してみて振る舞いを調べると
       いうのも手かもしれない。
 
       更にもう一つの問題は問題のある filesystem の上でどの様にして更新を行うの
       かという事である。touch によって時刻をコピーしたらちゃんと秒以下も反映さ
       れるのだろうか。また、touch -r はどのシステムでもサポートしている物なのだ
       ろうか。→ touch -r は標準化されている様だ。然し、やはり touch でも秒以下
       の情報は消滅してしまう様である。という事を考えると最新の時刻に更新するし
       かない。
 
     何れにしても pp を噛ませるファイル生成に関しては生成時刻がファイル時刻になっ
     ていた。という事を考えるとただコピーを行うだけのファイルの場合にも、コピー
     時点での時刻になっていても問題ないのだろうという気がする。
 
 2023-07-24
 
   * complete: cobraV2 の対策が動いていない (reported by 3ximus) [#D2057]
     https://github.com/akinomyoga/ble.sh/issues/348
 
     添付された生成コードを観察してみると completions に生成された候補が入ってい
     る。一方で core-complete.sh の .cobraV2.patch は out に生成されたデータが入っ
     ているという前提になっていて、out を修正しているが completions は修正してい
     ない。
 
     何処かの時点でコード生成が変更されたという事だろうか。cobra の方の実装を確
     認する必要がある。調べてみると [1] で変更が加えられている。
     __XX_extract_activeHelp が定義されている時に振る舞いを変更する様にすれば良
     さそうだ。
 
     [1] https://github.com/spf13/cobra/pull/1482/files#diff-ccbad943e447c0dbcf310892446819dea78bd471093c627e4aeb211c6ebb1b63
 
     実際に bb というコマンドを持っていないので正確には動作確認できないが適当に
     bb の出力を真似て実行してみた所、問題が再現できるという事と、対策したコード
     で問題が再現しない事を確認した。
 
     | --- gh348.sh~^I2023-07-24 06:31:13.884693063 +0900
     | +++ gh348.sh^I2023-07-24 07:00:07.415045133 +0900
     | @@ -57,6 +57,11 @@
     |      fi
     |      __bb_debug "The completion directive is: ${directive}"
     |      __bb_debug "The completions are: ${out}"
     | +
     | +out='hello^I(fdsafdsafdsa)
     | +world^I(test test test)
     | +aaaaa^Ixxxxxxx
     | +fdsafdsa'
     |  }
     |
     |  __bb_process_completion_results() {
 
     ? 問題が発生するのは desc がついていない候補も一緒に生成された時だけだが、
       報告では desc がついていない候補は生成されていない様に見える。何故だろう
       か?
 
       例えば空の候補が生成されている可能性? → 取り敢えず末尾に空行が含まれてい
       る場合にも問題が再現するという事は確認した。
 
 2023-07-18
 
   * docs: styleguide の追加 (motivated by bkerin) [#D2056]
     https://github.com/akinomyoga/blesh-contrib/pull/12#issuecomment-1507719943
     https://github.com/akinomyoga/ble.sh/pull/317
 
   * mawk in Ubuntu 16.04 LTS (reported by dongxi8, Frezrik) [#D2055]
     https://github.com/akinomyoga/ble.sh/issues/335
 
     Ref. #D2037
 
     mawk の version が古い。そして Ubuntu 16.04 LTS はこの古い mawk を使ってい
     る様だ。mawk が失敗するとどうやら全く操作ができなくなる様だ。これは良くない。
 
     x reject: 後テストしていて気づいたが --clear-cache が効いていない。
 
       もしくはそのまま ble.sh が起動してしまう。例えば bash out/ble.sh
       --clear-cache とするとそのまま新しい interactive session が始まってしまう。
       何故? chatoyancy 上でやっても再現しない。と思ったが勘違いだった。
 
       それでも既に ble.sh がロードされているセッションで source out/ble.sh
       --clear-cache を実行した時に ble.sh をリロードするのかリロードせずに既に
       ロードされている ble.sh で指定されたコマンドを実行するのかは非自明 → こ
       れに関しては新しい物をリロードした上でコマンドを実行するという現在の振る
       舞いで良い気がする。
 
       ble.sh がロードされていない時にsource out/ble.sh --clear-cache をした時に
       勝手に attach してしまうのは変だろう、と思ったが実際にはそのような振る舞
       いはしていなかった。勘違いだった。
 
       結局何れも勘違いだった。
 
     2023-07-18 更にまた別の人からも報告があった。 Ubuntu 18.04 LTS も 1.3.3 を
     使っているらしい。仕方がないので対応する事にする。
 
     mawk がダメという事は何処かに記録していた気がするけれど何処かに行ってしまっ
     た。と思ったが、mawk-regex.sh (2023-05-19 12:09:13) というスクリプトファイ
     ルが残っていた。此処に#D2037 の時に実験したコードが残っている。
 
     * ところで ko1nksm さんに確認を取ってみても良いかもしれない。もしかしたら既
       に記事にしているかもしれない、と思って調べてみたが結局よく分からない。取
       り敢えず {m,n} については何かの記事に書いていた気がすると思って Qiita で
       検索したら以下のページが見つかった (Google で検索しても出なかった)。
 
       https://qiita.com/ko1nksm/items/17b8105f793953dc83c7
 
       更に Qiita で検索をしていたら以下のページも見つけた。このページには正規表
       現にまつわる互換性問題がまとめられている。然しここにも {m,n} は言及されて
       いるけれども、mawk の [:class:] に関しては言及されていない。
 
       https://qiita.com/ko1nksm/items/53abc144558b9bb5629f
 
 2023-07-03
 
   * contrib/fzf-git: fzf-git 更新 (motivated by arnoldmashava) [#D2054]
     https://github.com/akinomyoga/ble.sh/issues/338
 
     gh という関数が gh (GitHub CLI client) と衝突している。fzf-git の upstream
     を見に言ったらいつの間にかに _gh に関数名を変更している。これが意味するとこ
     ろは元よりユーザーから呼び出すことは想定していなかったという事だろうか。更
     に、gist から github の通常の repository に移行している様だった。移行先では
     もっと大幅な refactoring が加えられている。移行先を track する様に変更する
     事にした。
 
   * history: history -w で空ファイルが書き込まれないという報告 (requested by Jai-JAP) [#D2053]
     https://github.com/akinomyoga/ble.sh/discussions/339
 
     先ず既に history が initialized されている時にはちゃんと書き込まれる筈の気
     がする。確認してみると _ble_builtin_history_initialized は初期化フェーズで
     設定される訳ではなくて飽くまで ble/builtin/history の初回呼び出しの時に設定
     される様である。
 
     そもそも何故この様な設計にしていたかを遡る必要がある。初期化フェーズに履歴
     が倍加したりする問題を避ける為にこの様な設計になっていた筈。
 
     #D1314 でこの辺りの振る舞いを導入していた。やはり履歴倍加問題の回避の為にこ
     の様に振る舞っている。
 
     * reject: 一応報告されたのは明示的に history -c を実行した後の問題であるか
       ら、其処で _ble_builtin_history_initialized=1 を設定してしまえば問題ない
       気がする。
 
     x ok: option:c で単に initialized=1 を設定すれば良い気がする。と思ったが
       bashrc の内部で history -c を実行した分は無視されて結局後で読み込まれる事
       になるので、その分は加味しないと行けないのではないのか。
 
       と思ったが既にそういう実装になっていた。問題は、 option:c であっても初期
       化前はスキップする仕組みになっているという事。
 
     こうなってくるとやはり以前の決断の通りに bashrc の内部では history の様々の
     操作は完全に無視する事にするしかない。一方で bashrc の内部にいるという判定
     をもっと厳しくする事はできるのではないかという気がする。
 
     1 bashrc の中かどうかの判定を行うのだとしたら最初にキー入力を受け付けた以降
       は bashrc の中ではないと判断できるのではないか。
 
     2 ok: 最初に bashrc の外で history -c を実行したという事が分かった時点で、
       それ以降は履歴が空であっても通常通りに処理するべきなのではないか。と思っ
       たがそれは元からそういう振る舞いだった。
 
     3 或いは単に ble-decode/.hook の内部から呼び出されているという事だけ見れば
       良いのではないか? と思ったが実際のコマンド実行は ble-decode/.hook の後で
       呼び出される hook 変数だった。それよりは edit.sh の .head と .tail の間に
       いる事を判定すれば良い気がする。然し、そういう変数は敢えて設定していない。
       見るとすれば stdout.on/stdout.off の状態だろうか。と思ったがこちらも敢え
       て状態管理はしていない。
 
       a だとすると .head 及び .tail の側に明示的に状態を設定する変数を新しく設
         置する?
 
       或いは既にある枠組みで何とかならないだろうか。decode.sh 関連は
       _ble_decode_bind_hook の内部で実行されるコマンドをカバーできないので駄
       目。_ble_attached だと、bashrc の中で attach して未だ抜けていない状態の時
       に駄目。edit.sh のコマンド実行関連だと、コマンド実行の外で実行されるコマ
       ンド (trap や PROMPT_COMMAND や bind -x など) がやはり漏れてしまうので駄
       目である。
 
       それを言い出したら .head/.tail に関しても、その外側で処理が走る場合がある
       のではないかという気もするが、今のところはその様な事はない気がする。Bash
       側のコマンド実行も行わないので余分なコードは全く実行されない。然し、将来
       的に異なるコマンド実行の枠組みができた時に .head/.tail の外側で実行して振
       る舞いが変だったという事になるのも嫌なのでちゃんと設計しておきたい気がす
       る。
 
       そもそも今欲しいのは .head/.tail の中かどうかという事ではなくて bashrc の
       外にいるかという事を判定する方法である。なので、それ専用の関数を作ってそ
       の他の場所に対する変更は最小限に留めるべきである。なので、.head, .tail を
       わざわざ状態に記録しなくても最初の .head の呼び出しまたは
       ble-decode/.hook 受信の時に変数を設定してしまえば良いだけである。
 
       b 既に keylog があるのであればその初回実行時に値を記録すれば良いのでは。
         と思ったがこれはループの大分内側にある様だ。やはり最初の PROLOGUE 呼び
         出しの辺りで何か値を設定するべきなのだろうか。
 
         うーん。ble-decode/.hook 自体に何回呼び出されたかの回数として
         _ble_decode_hook_count を記録する事にした。こうなってはコスト的には余り
         変わらない。
 
     取り敢えず _ble_decode_hook_count を導入し、それを参照して bashrc 内部でな
     い事が保証できる場合には history の処理をちゃんと実行する様にした。
 
     或いは PROMPT_COMMAND でそれが実行される事もあるだろうか? 然し、その場合に
     は ble-attach を bashrc から実行してその中から PROMPT_COMMAND を呼び出す場
     合を考えるとやはり履歴が初期化されていることを保証できないので、やはり
     history -cw は初回の PROMPT_COMMAND では無視される事になる。なので初回の
     PROMPT_COMMAND は動作保証しないという事にする。
 
     2023-07-03 実際に試してみたら動かない。history -w を実行しても何も書き出し
     がされない。うーん。 .write の実装を見たらそもそも histapp が空の時には何も
     実行しない様になっていた。これが原因である。
 
 2023-06-29
 
   * edit (.newline): overwrite mode の表示は消すべき (requested by mozirilla213) [#D2052]
     https://github.com/akinomyoga/ble.sh/issues/337
 
     元々 overwrite のマーカーは実際に着色しているつもりでいた。これをカーソルだ
     と思っているのだとしたら確かに残るのは変だ。これは単に region 着色を解除す
     れば良いだけだろうか。と思ったが overwrite_mode はまた独立した layer だった。
     実装方法には二種類ある。
 
     a overwrite mode を解除してからコマンドを実行する
 
       overwrite mode は _ble_edit_overwrite_mode で管理されている。
 
     b もしくは _ble_edit_line_disabled と同様にして再描画の際に無効化するか。と
       思ったが、_ble_edit_line_disabled は C-c 等で灰色にする場合の物であって、
       最終描画に使う物ではない。しかも _ble_edit_line_disabled は各 layer を
       off にする機能ではなくて、disabled という layer を一番上に被せるという形
       で実装されていた。
 
 2023-06-26
 
   * syntax: $(()) の中で "" が含められないということ (reported by mozirilla213) [#D2051]
     https://github.com/akinomyoga/ble.sh/issues/336
 
     動作を確認してみたら 4.3 では駄目だったが 4.4 以降では動く様だ。(()) ではど
     のバージョンでも動く。
 
     更に別の問題についても気づいてしまった。$((\10)) はどのバージョンでも失敗す
     るが、ble.sh は常に許容している。一方で、((\10)) は 5.0 までは動いていた。
     5.1 から動かなくなっている。また色々調べるともっと複雑である。
 
     context        expr = \10    expr = "10"    ASSIGNED NTYPE
     ------------   ------------  -------------  --------------
     $((expr))      false         bash >= 4.4    expr-paren-ax
     $[expr]        false         bash >= 4.4    expr-paren-ax
     $((a[expr]))   bash < 4.4    true           expr-brack-ai
     $[a[expr]]     bash < 4.4    true           expr-brack-ai
 
     ((expr))       bash < 5.1    true           expr-paren
     ((a[expr]))    bash < 5.1    true           expr-brack
 
     a[expr]        bash < 4.4    true           expr-paren-ai
     b[a[expr]]     bash < 4.4    true           expr-brack-ai
     ${a[expr]}     bash < 4.4    true           expr-paren-ai
     ${a[b[expr]]}  bash < 4.4    true           expr-brack-ai
     printf -v a[x] bash < 4.4    true           expr-paren-ai
     printf -v a[b[ bash < 4.4    true           expr-brack-ai
 
     ${v:expr}      false         bash >= 5.2    expr-paren-br?
     "${v:expr}"    false         bash >= 5.2    expr-paren-br?
     ${v:a[expr]}   bash < 4.4    true           expr-brack-ai
     "${v:a[expr]}" bash < 4.4    true           expr-brack-ai
 
     a=([expr]=)    true          true           expr-paren-di
     a=([b[x]]=)    true          true           expr-brack-di
 
     ? $["10"] はどうなのか → 4.4 以降では動く。うーん。全体的に改めてどの様な
       文脈で quote が許されるのか確認する必要がある。
 
     * うーん。'NQ(' の導入は割と古くて #D0375 である。取り敢えず新しい文脈を導
       入してしまう事にする。取り敢えず実装した。思ったがちゃんと反映されていな
       い。
 
     x fixed: $((\10)) でエラー着色になっていない。と思ったら単に新しく用意した
       関数 ctx-expr/.check-plain-with-escape を呼び出していなかった。呼び出す様
       にしたら期待通りに動作する様になった。
 
     * single quote 等の振る舞いは大丈夫なのか? → 調べてみた所 \10 と全く同じ振
       る舞いである。
 
     x 気づいてしまったのだが算術式中の a[expr] は更にそれがどの文脈だったかによっ
       て振る舞いが変わる。
 
     x reject: うーん。面倒な事に気づいた。${} や (()) の中では現在は [] の入れ
       子は追跡していない。しかし実際には quote の取り扱いが変わるのでそこまでちゃ
       んと対応しようと思ったらちゃんと追跡する必要が出てくる。しかし、一方で
       ${} や (()) の中では [] の入れ子は ${} および (()) 全体の終了に対しては考
       慮されない。うーん。
 
       これはまた two-pass parsing の問題である。((...)) を抽出する時には [ を無
       視して、次の解析で [ の入れ子を処理している。これはどうしようもないので対
       応しない事にする。
 
       → ページ上部の構文解析を諦めたものに追加した。
 
     * うーん。振る舞いが複雑すぎるのでテストを用意するべきの気がする →
       memo/D2051.sh に作った。
 
     x fixed: Bash では `echo 10` はいつでも有効の様だ。これに対応できていない。
       →対応した。
 
   * util: ble/builtin/readonly が bash options で壊れる (reported by dongxi8) [#D2050]
     https://github.com/akinomyoga/ble.sh/issues/335#issuecomment-1598485650
 
     readonly builtin: readonly BASH_COMPLETION_COMPAT_DIR がエラーになる。これ
     は何故だろう。Ubuntu 16.04 LTS でも再現しない。
 
     nocasematch? → これは nocasematch だった。nocasematch に対して耐性のある書
     き方をするか、或いは ble/builtin/readonly を他の ble/builtin と同じ様に
     bash オプションの保存・復元を行うかする必要がある。というか、set -xv 等の事
     を考えるとやはり保存・復元は実行するべきだ。
 
     ble/builtin/readonly の最初と最後で呼び出す事にした。
 
     ? 既に adjust-bash-options されている状態で呼び出しても問題ないのか気になる
       が、既に様々の関数でその様にしている事を思うと問題はないはずである。特に
       これらの関数は外側の状態を (グローバル変数ではなく) ローカル変数に記録し
       てそれをまた復元するという形を取っている。なので問題ない筈。
 
     2023-08-17 まだ問題があるという。然し問題が起こる理由が分からない。
 
     古い ble.sh をロードしてから後で新しい ble.sh をロードしている可能性もある
     のではないか。取り敢えず nocasematch / nocaseglob が怪しくてそれを修正した
     ら手元では再現しなくなった。
 
     a その他の可能性は bash-4.3 では問題が依然として発生するという事→再現しな
       い。
 
     b 或いは、Ubuntu 16.04 LTS だと問題が発生するという可能性→これも再現しない。
 
     c oh-my-bash と組み合わせると問題が発生するという可能性? → 特に問題は発生
       していない。
 
 2023-06-12
 
   * complete: fzf-completion で生成された path が full path になる (reported by teutat3s) [#D2049]
     https://github.com/akinomyoga/ble.sh/issues/329
 
     これは fzf-completion が raw command line を利用して raw insert を意図した
     候補を生成するからそれに合わせて振る舞いを調整した事に関係している。然し、
     依然として一部の path 名に関しては bash は PREFIX を取り出して処理する様だ。
     例えば common prefix を取り出してその / 以前の部分を削除してしまえば良いの
     だろうか。或いは、COMPS について / 以前の部分を common prefix にしてしまえ
     ば良い気がする。
 
     →うーん。調べてみると既に compopt -o filenames が指定されている場合には
     progcomp 側で自動的に COMP_PREFIX を指定して補完が実行される事になっている。
     そして、fzf completion 側でも実際に compopt -o filenames を指定している様だ。
     然し、問題は COMP_PREFIX が COMPV を元にして構築されている為に正しく prefix
     除去が動いていないという事だった。ble/syntax-raw が指定されている場合には
     COMPS を元にして COMP_PREFIX を決定する様に変更する。
 
     x fixed: sabbrev 候補生成が通常候補生成よりも後になっているので、
       fzf-completion で何も入力がない状態から何か候補を選択したとしても、一意確
       定せずに sabbrev と fzf-completion で選択した候補の選択画面になってしまう。
       以前は sabbrev 候補をより前に生成していたので単純に既に生成された候補を全
       削除すれば良かったが、 #D2011 により候補の生成順序を変更した。
 
       sabbrev 生成も抑制する仕組みが必要になるのではないか。
 
       a -o bashdefault に代わる何か? → bashdefault は何も生成されなかった時に
         既定の補完を行うものなので関係ない。
 
       b compopt の拡張を行おうとしたら、どうやら既に ble/no-default というオプ
         ションが実装されている様だ。これは補完候補が生成されなかった時に
         fallback で既定の補完を実施しないという意味であるが、補完候補が生成され
         た場合の振る舞いにも拡張する事ができる。これを fzf-completion 側で呼び
         出させて、sabbrev 候補生成は ble/no-default が指定されなかった時に呼び
         出す様にすれば良い。
 
   * complete: support `bleopt complete_requote_threshold` (requested by rauldipeas) [#D2048]
     https://github.com/akinomyoga/ble.sh/issues/332
 
     本当に必要な機能なのか怪しいが面倒なので実装する事にする。
 
 2023-05-23
 
   * [棄却] builtin: logout コマンドは上書きしなくても大丈夫なのか [#D2047]
 
     % 試しに logout を実行してみたらログインシェルではないという具合いにエラーに
     % なって何も起こらなかった。bind -x の内部からだと logout は実行できない仕組
     % みになっているのかもしれない→と思ったが本当にログインシェルでないと logout
     % は実行できない様だ。つまり SHLVL==1 という事か?
 
     実際にログインシェルで実行してみた所ちゃんと終了する。ジョブが残っている場
     合にもちゃんと一旦停止はする様だ。
 
     a 現在の振る舞いのままで良いだろうか。unload がちゃんと実行されているのか確
       認する必要がある→ちゃんと unload は実行される様だ。
 
     b 単に ble/builtin/exit に置き換えれば良いのだろうか。或いは、ble-detach と
       同じ様に logout という状態を設定して、その上で処理が終わった段階で終了を
       行うか。
 
       → ble/builtin/exit に置き換えるとログインシェルかどうかのチェックもなく
       振る舞いが変わってしまう。特に問題がない限りは logout はそのままでも良い
       気がしてきた。
 
       特に exit に介入している理由の一つは nix 等の設定で EXIT trap の中で更に
       exit を呼び出している場合など変な事をしている場合に無限ループになったりな
       どの問題が起こらない様にするための物である。
 
     取り敢えず現状のままという事にする。
 
   * stty: exit 後の stty 状態が壊れている in bash-5.2+ [#D2046]
 
     | 何故か bash --norc, bash, exit とした後に端末状態が壊れる様になった。何時
     | から起こる様になったのかを先ずは調べる。ble-0.3 では問題は発生していない。
     | つまり、やはり ble.sh の側の何らかの設定が関係していると思われる。
     |
     | 調べてみると 5b351e89 (2022-08-24) から発生する様になっている。今までずっ
     | と気付かなかったのも不思議であるが、たまたま bash --norc から bash を起動
     | する事がなかっただけなのかもしれない。或いはまた別の設定経由で動かなくなっ
     | たという事だろうか。問題は何だろうか。例えば exit trap が起動していない可
     | 能性がある? だとすると bgproc が放置されている事の原因も分かる。
     |
     | 取り敢えず stty がちゃんと呼び出されているかだけ確認する。どうやら最近ま
     | で気付かなかった理由が分かった。bash-5.1 では問題が発生しない。bash-5.2
     | および dev で問題が発生している。違いは bash-5.1 の中では EXIT trap は全
     | ての関数が抜けた後に発生しているのに対して bash-5.2 の中では EXIT trap が
     | 即座に実行されている事の様である。
     |
     | * うーん。stty 実行時に stdout,stderr が redirect されているのが原因かと
     |   も思ったがそうでもない様だ。stty 実行時に全てを /dev/tty に繋ぎ直したと
     |   しても問題は解決しなかった。
     |
     |   元々 stdin が残っていたがこれだけでもちゃんと動く筈という事の気がする。
     |   5.1 で stdout/stderr を潰しても動くか試してみる。うーん。5.1 だと
     |   stdin/stdout/stderr の全てを潰しても問題は発生しない。つまり、stty がちゃ
     |   んと効いているかどうかというのは実は今見ている問題とは関係がないという
     |   事だろうか。
     |
     |   うーん。やはり readline の終了時に stty を何か元の状態に復元する段階で
     |   変な事になっている気がする。然しそうだとしても ble.sh による再調整が走っ
     |   ているという訳でもない気がする。
     |
     | そもそも ble-detach で抜けた時には問題は発生していないか→ble-detach で抜
     | けた時には特に問題は発生していない。ble-detach で抜けた時には echo はちゃ
     | んと入っている様だ。一方で改行も無駄に echo されている気がする。
 
     [まとめ] この問題は bash-5.2 以降で trap EXIT がその場で実行される様になっ
     た事で、trap EXIT が bind -x の内部で実行される様になり、内部で実行した
     stty 復元の効果が bind -x 終了時に元に戻されてしまう事によって起こる。bind
     -x の外で trap EXIT を実行する方法があれば良いが今の所はその様な方法は見つ
     かっていない。
 
     a 可能性として一旦 detach してから exit するという可能性? C-d で終了を試み
       る場合には一旦 detach (もしくは ble/term/stty/finalize だけ実行) してから
       終了するのは技術的には不可能ではない気がする。然し、exit を実行された場合
       にはその様に一旦 readline に制御を戻す余裕もない。
 
       exit を強制的にキャンセルして、exit を emulate して top-level に戻り、更
       に detach を行ってから自前で exit をするという事も技術的には可能だろうか。
       然し、exit の振る舞いを正確に再現するのは難しいのではないかという気がする。
       特に redirections 等の復元はどうするのかなど。
 
       % というか一旦 trap EXIT が発火した時点でキャンセルする方法はない気がする。
       % と思ったが現在の議論はユーザーは上書きされた exit か logout を用いて終
       % 了するという想定をしている。
 
     b 或いは subshell で遅延してから stty を実行するという手があるだろうか? 然
       し、それだと例えば呼び出し元の shell がやはり ble.sh だった時に、遅延され
       て stty が実行されて stty が予期しない状態になってしまう。readline の収量
       処理が終わった後にその subshell が終了するまでブロックする仕組みが必要に
       なるが、その様な方法はない気がする。
 
     c 或いは諦めて呼び出し元が ble.sh session でない場合には stty sane を実行す
       る様に指示するメッセージを出す? 然し、端末の top-level だと常に表示されて
       しまい一々報告が来る事になる気がする。
 
       tty の一番大元であるかどうかを判定する方法はあるか?
 
       a reject: SHLVL? と思ったがこれは tty とは関係なく入れ子のレベルをカウン
         トするので screen や tmux でもカウントされてしまう。やはり端末の
         top-level かどうかを判定する必要がある気がする。
 
       b reject: 現在の session leader かどうかを調べれば良いのだろうか。然し、
         現在のプロセスが session leader かどうかを判定する方法はあるのか。
         session id がそのまま process id であれば良い様だ。session id は procfs
         があれば /proc/$$/sessionid から読み取れる様だ。然し、これを調べてみる
         と screen では単に screen が起動した session の id が全ての buffer に継
         承されている様に見える。なので使い物にならない。
 
       c 或いは単に PPID の tty をチェックすれば良いのかもしれない。と思ったが
         pid から tty を抽出する方法がよく分からない。ps ができているのだから
         procfs でのやり方はある筈と思ったがよく分からない。単に /proc/$$/fd/0
         を読み取るしかないのだろうか。でもその為には readlink を呼び出す必要が
         ある。外部コマンドを呼び出す必要があるのであれば単に ps を呼び出すのが
         早い。
 
       或いは tty の大元であるという判定ができるのであれば、その上でもっと積極的
       な修正を試みる可能性もある?
 
       * reject: サブシェルから stty sane? もし親プロセスが ble.sh でないのであ
         れば問答無用でサブシェルから stty sane を実行してしまっても良い様な気も
         するが、親プロセスが即終了して更に更に親プロセスに制御を戻す場合に、そ
         の更なる親プロセスに stty sane が影響を与えないかどうかは非自明である。
         というかそもそも親プロセスだって raw モードで文字列を読み出したいと思っ
         ている可能性もある。という事を色々考えるとサブシェルから stty sane を呼
         び出すのはやはり問題がある。
 
     仕方がないので取り敢えずは c の方針で stty sane を実行する様にメッセージを
     出す事にした。結局現状では疑わしい状況の時にメッセージを出すだけであるが仕
     方がない。
 
 2023-05-21
 
   * syntax: bash-5.3 ${ list; } 対応 [#D2045]
 
     * ble/util/assign の置き換え
 
       * set -m 等をして独立した PGID が作られるかの確認。この振る舞いが
         util.bgproc からの要求になっている。
 
         echo "$(set -m; sleep 5 >/dev/null & pid=$!; ps -o pid,ppid,pgid "$$" "$pid")"
 
         これは作られないと分かっている。
 
         echo "${(set -m; sleep 5 >/dev/null & pid=$!; ps -o pid,ppid,pgid "$$" "$pid")}"
 
         これはちゃんと作られる。OK。因みに
 
         echo "$( (set -m; sleep 5 >/dev/null & pid=$!; ps -o pid,ppid,pgid "$$" "$pid") )"
 
         も作られる。なので元々其処まで気にしなくても良かったのかもしれない。
 
       取り敢えず ble/util/assing を ble/util/assing に置き換えてみたがこれで実
       行するとエラーが沢山発生する。これは既に報告されているエラーである。これ
       が修正されるのを待って改めて置き換えて動作確認を行う。
 
       取り敢えず Oguz の報告した以下の問題が解決されたようである。今のところは
       何の問題もなく動いている。取り敢えず push して良い気がする。
       https://lists.gnu.org/archive/html/bug-bash/2023-05/msg00045.html
 
     * syntax 対応
 
       * 振る舞いについて調べる
 
         説明に書かれているのには反して ${(echo);(echo)} も動くし ${(echo) } も
         動く。ちゃんと直感的な実装になっている。
 
         ${ { list; } } もちゃんと {} の入れ子を考慮した実装になっている。一方で
         これを ble.sh の側で対応しようとすると {} の入れ子を追跡していない。
 
       [実装]
 
       a 改行判定の時と同じ様に {} の数を数えて処理すれば良いかとも思ったが、そ
         うすると解析状態とは別の状態に依存する様になってしまうので駄目。
 
       b 或いは nest の中に {} のカウントを保存する?
 
       c もしくは解析状態に {} の入れ子を記録する。
 
       d 或いは {} の入れ子もちゃんと処理する様に変更する。
 
       現実的に d の方向で実装するしかない様な気がする。或いは
 
       e ${ ... } の内部の {} の時にのみ入れ子を数える。
 
       うーん。算術式ですら [] で nest を作成しているのだから {} で入れ子構造を
       作るのが妥当の気がする。
 
       何れにしても取り敢えずは実装を考える。
 
       うーん。やはり単純に数える方が実装が楽なのではないか。現在の実装だと for
       ... { ... } 等に於いて for と } を組みにしてちゃんと構文が閉じているかを
       判定している。ここで {} を入れ子にして解析する事にすると、for も一緒に入
       れ子解析を実装しなければならなくなる。然し、単純に数える実装にするとやは
       り状態をどのように記録するのかという問題が生じる。或いは、{} で nest 構造
       を作るにしても keyword の begin/end は今までと同じ様に取り扱う。それで良
       い気がする。
 
       最終的に d で実装したが実は簡単だった。
 
     2023-06-12 結局 ${( は対応しない事になったようなので削除する。もしかすると
     これは zsh の attributes との互換性を考えての可能性もある。
 
 2023-05-16
 
   * main: --inputrc=TYPE の設定を適用する前に read-inputrc を呼んでいる [#D2044]
 
     osh を実行していて気づいたが --inputrc=none が効いていない。一方で最近の
     issue のデバグで効果があった様に見えたのは謎である。
     https://github.com/akinomyoga/ble.sh/issues/322#issuecomment-1539265410
 
     取り敢えず修正は適用しておく事にする。
 
   * util: idle.do 無限ループ [#D2043]
     Ref #D1980 (2023-02-27)
 
     Ubuntu で idle.do が無限ループになっている。どうやらファイル待ち状態になっ
     ているが sleep を全くしていない様である。これは 559d64b8 の regression であ
     る。条件式が微妙に間違っている。
 
     また、これが最近 bash の処理量が多い理由なのではないかという気がする。約二ヶ
     月半の間、idle.do が無駄に無限ループしていたという事になる。
 
     * それとは別に何故ファイルが作られずに失敗しているのかという問題がある。うー
       ん。VM の中であることによって何らかの事故によって git がクラッシュしてい
       る等?
 
     * それから core-debug-def.sh が ble/debug/profiler/end を export しているが
       実際に定義されるのは ble/debug/profiler/stop である。修正した。
 
     2023-05-16 無限ループは直っていない。と思ったら物凄く簡単なミスをしていた。
     修正する。
 
 2023-05-14
 
   * progcomp: _parse_help 経由で生成された項目に uniq をかける? [#D2042]
 
     bash-completion が重複したオプション項目を出した時に ble.sh はそれにそのま
     ま記述を追加してメニューに表示するので同じ候補が二つ表示されてしまう。
 
     sed --e[TAB]
 
     うーん。既に uniq はかけられている。問題は bash-completion が --expression
     と --expression= を両方出すが、ble.sh が --expression を mandb によって補填
     して --expression= に変換する事である。そもそも bash-completion が両方出す
     のも変な事なので、どちらか一方を出力するので問題ない。
 
     オプション候補に対して説明を付加する時点で = を除いた状態で重複がないかチェッ
     クして、その上で出力する様に修正する事にした。
 
 2023-05-13
 
   * progcomp: _parse_help の代わりに新しい _comp_compgen_help に介入 [#D2041]
 
     新しい実装は _parse_help ではなく新しい関数名に対して advice を仕掛ける必要
     がある。
 
     うーん。
 
     x fixed: 今までの実装で _parse_help - に対しての介入がちゃんと動いているか
       怪しい。この実装だと本来 _parse_help が読み取る筈だった stdin を盗んでし
       まうのではないか。キャッシュが一旦出来上がればもう読み取らないので問題な
       い。
 
     * ok: 実装チェック。bash-completion 2.11 の iperf -[TAB] が _parse_help -
       を呼び出す。ちゃんと動いている。その他の場合についても
 
       $ awk -F "$_ble_term_FS" '{print $1}' "$subcache" >/dev/tty
       $ echo $(awk -F "$_ble_term_FS" '{print $1}' "$subcache") >/dev/tty
 
       でチェックする。sed -[TAB] は _longopt で smartctl -[TAB] は _parse_help
       "$1" のテストになる。bind -[TAB] は _parse_usage のテストになる。取り敢え
       ず何れも期待どおりに動いている。
 
       bash-completion 2.12 の方でもちゃんと動く事を確認した。
 
   * cmdspec: その他の builtin のオプションの対応 (motivated by EmilySeville7cfg) [#D2040]
     https://github.com/akinomyoga/ble.sh/issues/325#issuecomment-1545474274
 
     これらは bash builtin なので man で情報を正しく抽出できない。代わりに help
     builtin で取得する必要があるが、これは明示的に指定する必要がある。
 
     * reject: builtin コマンドに対する既定の cmdspec を定義する? 或いは type で
       builtin だったら fallback として builtin 用の cmdspec を既定で適用する可
       能性? と思ったが ble/cmdspec/opts は補完専用の枠組みという訳でもなく、必
       要もないのに type で builtin かどうかを確認するのを既定で行うのも憚られる。
       やはり、一つ一つ全部指定した方が良い様に思われる。
 
     * done: pushd, popd, dirs の -N/+N の実装
 
       pushd に関しては既に core-complete の中で cd と一緒に実装していた。それに
       追加する形で popd と dirs も実装する。
 
     * mandb-help=@-- が認識されていないのは何故か。どうも明示的に無視されている
       様である。同じ mandb-help=@ に指定していても -- だけは認識されていない。
 
       或いは実装上の都合で意図的に -- を除外しているのだったか? と思ったが思い
       当たる事はない。実際に動作を追っていくと mandb の段階では -- はちゃんと生
       成されている。何処かで消滅しているという事だろうか。
 
     取り敢えず対応した。
 
     x ok: pwd の man-disable-man が効いていない気がする。man pwd から拾ってきた
       オプションを表示している。と思ったが単にキャッシュが更新されていないだけ
       だった。
 
     x test の disable-double-hyphen が効いていない。と思ったら
       disable-double-hyphen は別の用途だった。新しく mandb-exclude という項目を
       作る事にした。
 
 2023-05-12
 
   * progcomp: cd の short flag 補完で文字そのものを候補として表示しているが分からにくい (requested by EmilySeville7cfg) [#D2039]
     https://github.com/akinomyoga/ble.sh/issues/325#issuecomment-1545474274
 
     cd の short option 実装で -xxx の中に含まれる short option を選べる様にしよ
     うとしている。この関係で表示される候補は -c ではなくて文字そのもの c である。
 
     * done: 表示文字列は -c の形にする。ここで実際に挿入される文字列はともかく
       として表示状は -c 等の様にする事はできるだろうか。或いは最初のオプション
       だけは - 付きで表示して、short flags の二つ目以降はその文字その物を補完す
       る様にするのが簡単で良いだろうか。しかしその文字だけを表示するのも何だか
       変な気がするし、絞り込みをする際にも何だか変な気がする。という事を考える
       とやはり表示状は常に - になる様にするのが良いだろうか。→取り敢えず表示さ
       れる文字列に関しては - をつける事にした。
 
     * done: 本来は desciption を help から拾って来たい。mandb を呼び出して一緒
       に表示する様にしたい。取り敢えず実装した。
 
       これは汎用性があるので関数に分離したい気がする。分離した。
 
     x reject: 一意確定を mandb を用いて行うと補完確定時に空白が挿入されない。
       word だとちゃんと挿入される。何故か。と思って改めて実行してみたらちゃんと
       動いている。何かの勘違いか。
 
     * fixed: -@ に対する説明を抽出できていない。
 
       これは実装を調べていたら _ble_complete_option_chars という変数でオプショ
       ンとして許される文字の集合が管理されていた。これに @ を追加すれば良い。
 
     * fixed: -P に対する説明が help 出力の関係ない部分を拾っている。それらしい
       物が複数見つかった時にどちらを優先させるのかについて決める必要がある。例
       えばより長く空白が間に入っていたものを優先させるなど。現在の実装だと引数
       らしい物がくっついていた場合にそれを優先する様になっているがそれは変だ。
 
       或いは空白が複数続いている物を優先させる等の処置が必要かもしれない。単一
       空白しか行内に含まれていない物については優先度を下げるなど。完全に排除し
       てしまうとそれはそれで説明抽出できない物が発生するかもしれない。
 
       優先順位を計算して記録する仕組みを作るのは大変だと思ったが改めて実装を確
       認したら既にそのような仕組みが実装されていた。但し、インデントベースで決
       定されている。つまり、インデントの深さが浅い物を優先させる様になっている。
       空白が一つも含まれていない行の場合には優先順位を 100 だけ下げるのような感
       じの処置を追加で実装すれば良い。
 
       実装した。動いている。
 
     x CAND を勝手に変更して実装しているが本当にそれで良いのか? CAND は
       menu-filter にも使われれているので実際に挿入する物と異なる物を設定すると
       メニュー項目が消滅する等して面倒な事になるのではないか。
 
       本来は固有の action を割り当てて表示の時に内容を書き換えるべきなのではな
       いか。
 
       改めて実装を見てみたら表示の時に prefix を設定できる。という事は - を追加
       するのも簡単である。新しい action mandb.flag を定義して実装した。動いてい
       る様に見える…が座標位置の計算がずれてしまう。
 
     2023-05-14 オプションの着色にも @ を含めるべきではないのか。これは
     ble/progcolor/word:default/.is-option で判定している。正規表現を確認すると
     alnum _ しかチェックしていない。
 
     x menu-filter による再描画で prefix が表示されず、更に座標位置がずれる。
 
       どうも menu-filter による再描画の際に prefix が正しく描画されていないのが
       原因の様である。menu-complete による選択時には問題はない。という事は再描
       画の際にやはり問題になっているという事。
 
       →うーん。分かった。一致着色部分を構築する時に local out= を実行してしまっ
       ている所為で prefix の中身が消えてしまっている。修正した。
 
       これは 0.3 では影響ないだろうか → うーん。0.3 でも影響がある。修正する必
       要がある。独立した commit にするべきの気がする。
 
   * mandb: Ubuntu で echo に対する解析結果でオプションと説明の単語がくっつく (reported by EmilySeville7cfg) [#D2038]
     https://github.com/akinomyoga/ble.sh/issues/325
 
     制御文字を全て削除する段階でくっついてしまう様だ。何故か環境によって TAB を
     使ってオプション名と説明の間を区切っていたりそうでなかったりする様だ。取り
     敢えず TAB は空白に変換する事にした。空白一つに変換すると距離が近すぎる事に
     よってオプション引数と間違われる。2つでもオプション引数と解釈する様なので 3
     つ以上である必要がある。きりの良い 4 空白に置換する事にする。
 
   * main: Ubuntu では nawk という名前で gawk が入っている [#D2037]
     https://github.com/akinomyoga/ble.sh/issues/322#issuecomment-1543766152
 
     こういうおかしな事をするから Ubuntu は駄目だ。他の os はそんな事はしていな
     い。取り敢えずバージョン文字列を nawk に対してはチェックする事にした。
 
     バージョン抽出する為に awk --version のような具合にしていたがこれだと mawk
     が動かない。-W version と --version の両方を試す事にした。また、nawk は単に
     nawk -W version とすると標準入力を読み取る状態になってしまって固まってしま
     うので </dev/null をリダイレクトする事にした。
 
     但し、これを修正しても echo の補完の問題 #D2038 は解消していない。echo の補
     完の問題に関しては独立にちゃんと修正する必要がある。独立な項目で修正する。
 
 2023-04-12
 
   * 2023-03-24 histdb: sqlite3 がクラッシュする? [#D2036]
 
     或いは timeout した物の情報が同期されていなかった可能性? timeout をより短く
     して再現するかどうか確認する必要がある。
 
     2023-04-12 これは頻繁に起こっている。と思って改めてコードを確認してみたが、
     どうもクラッシュしていても自動で停止していても #alive は false になるので、
     #alive でなかったからと言ってクラッシュしたという訳ではない。クラッシュした
     かどうかの判定をしたければまた別の関数を作るしかない。然し、わざわざ別の関
     数を作ってチェックする必要があるのかも分からない。然し、現在はテスト段階で
     もあるしやはり微妙な失敗でもちゃんと検索して表示する様にしたい。
 
 2023-04-09
 
   * chore: 古いテスト用のファイルや説明用のサンプルを保存する [#D2035]
 
     * gitignore を更新して表示から除外するものを増やした
     * e.sh は refact.sh に合流。
 
     未だ幾つか残っているが取り敢えずはそのままにする。
 
   * bgproc, conditional-sync: support opts "kill9-timeout=TIMEOUT" [#D2034]
 
     * fix(conditional-sync): pid が opts で指定されていない時に、グローバルの
       __ble_pid を変更してしまう問題の修正。色々書き換えている時に残ってしまっ
       た && を削除する。
 
     ? OK: kill -9 の 9 はシステムに依存しないと思って良いのか?  POSIX の kill
       によると SIGKILL は 9 であると定められている様だ。なので気にしなくて良い。
       https://pubs.opengroup.org/onlinepubs/9699919799/utilities/kill.html
 
     * bgproc: kill9-timeout で SIGKILL までの timeout を指定できる様にした。
 
   * 2023-04-05 bgproc: exec に関する説明を書く [#D2033]
     https://github.com/akinomyoga/ble.sh/discussions/309#discussioncomment-5527375
 
     またサブシェルに fd が継承されるという事についても述べる。
 
     →色々書き加えた。
 
   * 2023-04-05 README: Guix package のリンクが壊れている [#D2032]
 
 2023-04-08
 
   * util (conditoinal-sync): opts に指定した pid=PID/-PGID が動かない (contributed by bkerin) [#D2031]
     https://github.com/akinomyoga/ble.sh/discussions/309#discussioncomment-5556211
     https://github.com/akinomyoga/ble.sh/pull/313
 
     これは conditional-sync を弄って外部から pid を指定できる様にした時のバグ
     https://github.com/akinomyoga/ble.sh/commit/8d623c1927c2c4e381bd484bcc51def3213890f6
 
     先ず PGID を指定すると kill がシグナルと勘違いして動かない。次に timeout=0
     を一緒に指定すると既存の pid があっても kill を試行せずにそのまま終了してし
     まう。
 
     提案では負の時にだけそのまま終了する様になっていたが、負であっても pid が指
     定されていればちゃんと kill して終了する様にしたい。調整する。
 
     ----
 
     2023-04-09 GitHub CI で Windows が失敗している。手元の cygwin で試すと何故
     か sleep 10 を kill しても全く効果がない。然し、プロンプトを跨いで kill を
     実行するとちゃんとその場で動く。色々実験した結果 subshell を少なくとも一回
     以上立ち上げた後だと kill が効く様である。これは kill -- でも kill -9 でも
     同様である。
 
     $ tkill() { kill -9 "$p"; ((count++)); sleep 0.01; }
     $ sleep 10 & p=$!; count=0
     $ (true)    # <-- これがあるかないかで必要な kill 回数が変わる
     $ tkill; while kill -0 "$p"; do tkill; done; date +'%s.%N':$count
 
     然し、CI test に関しては単に delay を入れるだけで解決してしまった。然し、場
     合によってはやはり kill できないという状況になると行けないので念の為
     Windows では subshell を一つ作る事にする。