note.txt

# -*- coding:utf-8 -*-

拡張

  * プログラム補完に於いて、
    補完関数内で compopt -o filter_by_prefix を指定した場合、
    生成される候補を接頭辞が一致するものだけに絞り込む。

制限

  * 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 がくっついて新しい変数名になる。
      これは分かりにくい動作だが、これを逆に使う人もあるのかもしれない。
      実の所、ブレース展開も文法レベルで実施されるべきなのかもしれない。

  * 2019-02-04 プログラム補完関数の中で標準入力は使えない。
    どうしてもユーザからの入力を得たい場合には、
    現在の補完が自動補完でない事を確認してから /dev/tty から直接取る事。

bash 実装上で注意するべき事

  * 変数の代入は基本的に 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-4.0 -- 3.0

    $'' 内に \' を入れていると履歴展開が '' の中で起こる?
    例えば rex='a'$'\'\'''!a' とすると !a の部分が展開される。

  * 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 では a=(""); echo "a${a[*]}b" | cat -A とすると
    a^?b となって謎の文字が入る。echo "a""${a[*]}""b" 等とすれば大丈夫。

  * 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}')"

  * bash-3.1
    呼出先の関数で、呼出元で定義されているのと同名の配列を作っても、中が空になる。
    > $ function dbg/test2 { local -a hello=(1 2 3); echo "hello=(${hello[*]})";}
    > $ function dbg/test1 { local -a hello=(3 2 1); dbg/test2;}
    > $ dbg/test1
    > hello=()

    これは bash-3.1-patches/bash31-004 で修正されている様だ。

  * bash-3.1

    - ${#arr[n]} は文字数ではなくバイト数を返す様だ。

    - "${var//%d/123}" は動かない。"${var//'%d'/123}" 等とすればOK。

    - bash-3.0, bash-3.1: local GLOBIGNORE すると、
      関数を出てもパス名展開の時にその影響が残っている。
      (直接変数の中身を見ても何もない様に見えるが。)
      unset GLOBIGNORE などとすると直る。

  * bash-3.0

    - ${#param} は文字数ではなくバイト数を返す、という事になっているらしいが、
      実際に試してみると文字数になっている (bash-3.0.22)。
      何処かで patch が当たったのだろうか。まあいいか…。

      (※${param:ofs:len} は 3.0-beta1 以降であれば文字数でカウントされる)

    - declare -p A で改行を含む変数を出力すると改行が消える。
      例: 一見正しく出力されている様に錯覚するが "\ + 改行" は改行のエスケープではなく、
        長い文字列リテラルを二行に書く為の記法である。つまり、無視される。
      $ A=$'\n'; declare -p A
      | A="\
      | "

  * msys1, msys2: var='^M' とすると CR が消えてなくなる。
    msys2 では var=$'\r' とすれば大丈夫。また変数に入っている物も大丈夫。
    例えば var=$_ble_term_CR はOKである。
    msys1 ではそれでも駄目。local var=$'\r' とすれば大丈夫。
    変数に入っている物でも local を付けないと消滅してしまう。

  * 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 bash-4.0, 4.1 (local), bash-3.0 ～ 3.2 (declare)

    a[${#a[*}]=value もしくは ble/array#push a value するとき、
    その配列を事前に宣言したければ local -a a のように -a を指定する必要がある。

    [問題]

    bash-4.1 以下で関数内で local arr しただけで ${#arr[*]} が 1 になる。
    その後、要素 #1 を設定しても ${#arr[*]} は 1 のままである。
    これの所為で以下のコードが破綻する:
      arr[${#arr[*]}]=...
    常に要素 #1 にしか代入されない事になる。

    bash-3.2 以下では関数内に限らず declare arr しただけで ${#arr[*]} が 1 になる。
    但し、要素[1] に設定をすると ${#arr[*]} は 2 に増加する。
    従って余分な空要素があるものの ble/array#push は失敗しない。

    [解決]

    local -a arr とすれば問題は起きない。
    ※local arr=() としても問題は起きないがこの記述だと
      今度は bash-3.0 で文字列 '()' が代入されて問題である。

  * BUG bash-3.0: local a=(...) や declare a=(...) とすると、a="(...)" と同じ事になる。
    a=() の形式ならば問題ない。

  * BUG bash-3.0: 今まで local -a a=() の形式ならば問題ないと信じてきたが、どうやら
    local -a a=('1 2') が local -a a=(1 2) と同じ意味になってしまうようだ。
    a="123 345"; declare -a arr=("$a"); このようにしても駄目だ。
    a="123 345"; declare -a arr; arr=("$a"); こうする必要がある。

  * BUG bash-3.0: "${var[@]/xxx/yyy}" はスカラー変数に対して空の結果を生む。
    ${var[@]//xxx/yyy}, ${var[@]/%/yyy}, ${var[@]/#/yyy} についても同様である。

  * 配列要素を連結する時

    動く例:
      IFS= eval 'value=${arr[*]}'
      IFS= eval 'value="${arr[*]}"'
      IFS= eval 'local value="${arr[*]}"'

    動かない例 (間に空白が入ってしまう):
      IFS= eval 'local value=${arr[*]}'

  * BUG bash-4.0..4.4: ローカルで local -a x; local -A x とすると segfault する。
    ref http://lists.gnu.org/archive/html/bug-bash/2019-02/msg00047.html, #D0924

    f() { local -a a; local -A a; }; f # これで segfault する

    - 別のスコープで定義された配列を -A とした場合には起こらない。
    - 同じスコープの場合でも unset a してから local -A a すれば大丈夫。
    - グローバルでは起こらない。

  * BUG bash-3.0..3.2: ^? や ^A の値が declare -p で ^A^? や ^A^A に変換されてしまう。

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] 等) を指定できる。

  * ${!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
-------------------------------------------------------------------------------

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

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 widget を呼び出すことができなかった
      未使用

    125 widget を呼び出したが適切な処理が見つからなかった
      __defchar__ に登録した widget がこれを返したとき
      次のハンドラを用いる。具体的には __default__ の呼び出しを試みる。

    147 ble/util/idle の処理に於いて条件待ち状態に入る時や、
      widget に於いてユーザの入力を待つ為に、
      自発的に一時中断した時に返す値。

      ユーザの入力を非同期に待つ為に一時停止した
      vi-mode のオペレータが 148 を返したとき
      後処理を実行せずにそのまま抜ける (由来: 128+SIGTSTP)

    148 ble/util/idle や isearch や complete に於いて、
      ユーザ入力を処理する為に一旦現在の処理を中断する時に返す値。

    124 プログラム補完において補完の再実行を要求する
      (由来: これは Bash の仕様に倣った)

    27 widget の動作がユーザによってキャンセルされた (由来: ESC = 27))

    6 ble-update で更新の必要がなかった時に内部的に使用 (由来: ACK = 6)

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]

    set | sort | sed -e '/()[[:space:]]*$\|^_\{0,1\}\(BLE\|ble\)/d' -e '/^[[:alnum:]_]\{1,\}=/!d' > a.txt

  * [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
-------------------------------------------------------------------------------

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. これは結局強い理由がないと変更さ
    れない雰囲気になっている。


@todo
*******************************************************************************
    ToDo
-------------------------------------------------------------------------------

0.6 ErrorMsg
0.5 ControlPanel/TUI Framework
0.4 progcolor

2021-05-29

  * syntax: 単語が sabbrev に一致する場合には着色するのが親切だ

    これは sabbrev に対する仕様拡張を行ってからでも遅くないのではないか。
    ble/syntax/progcolor/word:default 辺りに修正を加えれば良い。
    本来は progcolor よりも上の枠組みで着色したい気もするが
    それだと layer を増やす必要がある。処理が重くなりそうである。

    check-sabbrev 的な感じで付加的な処理として実装できれば良い。
    そうすれば custom な着色関数からでも呼び出せる。
    と思ったがちゃんと忘れずに呼び出すのも面倒である。
    やはりもっと下の枠組みで提供するべきだろうか。
    例えば、最終的に着色を格納する部分に介入してしまうという手もある。

2021-05-27

  * wiki の更新
    * wiki: ble-import の -f オプション
    * wiki: bleopt の wildcard, -r, -u
    * wiki: blehook の -a

  * declare -p -A として見たら contra の状態が壊れた。何だろうか。

  * やはり source_if() { source "$@"; } 等とすると引数が一つしかない場合に、自
    分自身が引数であると誤認してロードがキャンセルされる。

    % これは実は簡単に判定できるのではないだろうか。つまり引数が唯一つでしかも
    % 自分自身を指している場合には関数内で無引数でsource されたのであると判定で
    % きる。と思ったが違う。これで見えているのは外側の関数の引数なのだから、必
    % ずしもそういう形になっている訳ではない。

2021-05-24

  * airline: 使い方を説明に書く

2021-05-23

  * menu-complete: SIGWINCH による info#panel::invalidate の際にメニュー項目の
    再配置を実行するべきである。

    * info 拡張: というか info の表示を担っている class を動的に変更するべきな
      のではないか。現在の実装だと内容を変更する時には必ず info の関数を即時で
      呼び出さなければならない仕組みになっている。然し、そうではなくて機に応じ
      て丸ごと制御を移すなどの事をした方が良いのではないか。然し、一方でどの内
      容が一番上に来るべきかなどの制御も必要になる。現在は default/non-default
      の二層構造になっているがそれをもっと動的に変化できる様に改良するという手
      も考えられる。

  * main: BASH_XTRACEFD による出力の抑制?

    | 更に set -x についてもまた駄目になっているかもしれない。→試してみた所
    | attach 部分で無駄なメッセージが沢山表示される様になっていたが実行自体には
    | 問題はない様である。然し、BASH_XTRACEFD を使った方が良いのではないか。こ
    | れについてはまた別の機会について考える事にする。

    現在の手法だと必要なエラーまで抑制してしまうし、標準エラー出力を抑制する為
    に結構無理な事をしている。BASH_XTRACEFD を使って実装した方が綺麗になるので
    はないか。然し、また色々と実装上の不都合が生じるかもしれないので取り敢えず
    後でゆっくり対処する事にする。

2021-05-21

  * progcolor: 取り敢えず builtin から始めるのが良いのではないかという気がする。

2021-05-19

  * sabbrev: 単語でなくても任意の文脈で発動する sabbrev が欲しい。\ 等で前置す
    れば特に問題ないのではないか? 然し、その為には全ての場合について一致するか
    どうか確認する必要がある。

  * 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

  * history: 履歴が余りに消滅するので ble.sh の側で独立した履歴の仕組みを作りたい

    然し何処に履歴ファイルを置くのかという問題がある。

    a 今日日、~/.ble_history 的なファイルを置くのは憚られる。

    b .cache には消えても良い物を置くべきだから置くなという話もあれば、

    c .config はユーザー設定に纏わる物で dotfiles に入れている人もいるから勝手
      に書き込まないで欲しいという話もある。

    d 結局、.local/share/blesh/xxxx に置く事になるのだろうか。まあ、
      .local/share/blesh/data 辺りに置いて置けば良いだろう。然しその為には更に
      新しいディレクトリを生成する必要がある。現在は _ble_base, cache, run の三
      種類のディレクトリがある。

    履歴はどの様に記録するのが良いか。日付は unix time で記録するのが人間に分か
    る様に記録するのか。カレントディレクトリも記録したいし、存在する相対パスも
    記録したい。所で存在する相対パスはどの様にして抽出するのが良いのだろうか。
    単語着色の時に検知した物を何処かに記録しておく必要がある。

  * 色見本について探した

    多くのサイトは微妙である。そもそも 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: C-x s spell-correct-word
  * rlvar: enable-active-region
  * rlbind: prior, next
  * vi-undo

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

  * magic-space で alias 展開する機能があっても良いのでは?

    というか magic-space で何を展開するかの集合を設定できる様にするべき?
    bleopt edit_magic_expand=sabbrev:history:alias という具合に。
    流石にコマンド置換等まで展開するのはやりすぎの様に思われる。

  * 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 という物もあるようである。

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 があってもきりがない)。

  * 絵文字シーケンスや grapheme cluster

    今まで対応は不可能と思って割り切って考えてきたが実は可能なのではないかという気がしてきた。
    ゼロ幅の文字が存在しても特に変な事は発生しない気がする。
    注意しなければならない事としては dirty 範囲を広げなければならないという事と、
    文字の途中で SGR 等を挿入したりする事はできないという事。

    一方で端末の側でもこれに対応している必要があるのでテストという観点からは微妙。
    contra は対応していないし screen も恐らく対応していない。tmux はどうなのだろうか。

    tmux はこれに対応しているターミナルがないから未だ対応しないという事を言っている。
    一番最近では 2020-05
    https://github.com/tmux/tmux/issues/1605

2021-02-05

  * evaluate-path-spec (by 3ximus)

    evaluate-path-spec の改良に挑戦してみるという事なので。先ずは説明が必要である。

    * notilde に関しては eval の側で処理するべきではないか
    * 後で全体 path 以外については single を加える様にお願いする

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 は展開対象なのに着色されない。
    x ((a["$index"])) がエラー着色になっている
    x bash-5.1 からは (()) でも ' は quote ではない。

    更に言うと a['...'] の ' は a が連想配列の時には必ずしもエラーではない。

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'

  * 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-09-01

  * trap: ble.sh で上書きする時に元々存在していた trap はどうなっていたか。
  * trap: ble.sh を unload する時に復元する仕組みがあっても良いのではないか。

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

  * starship コマンド実行時間の計測
    preexec と precmd を使っている?
    https://github.com/starship/starship/blob/master/src/init/starship.bash

    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 にまでパッケージが在る。

  * 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 に記録されている物を着色するというのが良さそうである。

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-03-14

  * emacs: C-w を続けて実行すると kill-ring に追記にするべき

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 (実装ログ)
-------------------------------------------------------------------------------

2021-07-13

  * 2021-06-28 main: set -Bk 等の場合に対しても対策する [#D1628]

    set -B に対してはブレース展開を使っているコードが影響を受ける。ブレース展開を使っているコードは以下で抽出する事ができる。

    $ grc '[^$]\{[^[:space:]]*,[^[:space:]]*\}' --exclude={wiki,memo,test,ext} --exclude={lib/test-\*.sh,make_command.sh}
    ./keymap/emacs.sh:21:  copy{,-forward,-backward}-{c,f,s,u}word
    ./keymap/emacs.sh:22:  copy-region{,-or}
    ./keymap/vi.sh:220:  delete-backward-{c,f,s,u}word
    ./keymap/vi.sh:221:  copy{,-forward,-backward}-{c,f,s,u}word
    ./keymap/vi.sh:222:  copy-region{,-or}
    ./keymap/vi.sh:2799:  local _ble_keymap_vi_single_command{,_overwrite}= # single-command-mode は持続させる。
    ./keymap/vi.sh:2813:  ble/util/unlocal _ble_keymap_vi_single_command{,_overwrite}
    ./lib/core-complete-def.sh:78:                  ble/complete/menu-style:{align,dense}{,-nowrap}/construct-page \
    ./lib/core-complete-def.sh:80:                  ble/complete/menu-style:desc{,-raw}/construct-page
    ./lib/vim-airline.sh:114:  for name in {a,b,c,x,y,z,error,term,warning}{,_normal,_insert,_replace,_visual,_commandline,_inactive}; do
    ./lib/vim-airline.sh:343:  for unit in _ble_lib_vim_airline_section_{a,c,z,b,y,x}; do
    ./src/benchmark.sh:231:  for n in {1,10,100,1000,10000}\*{1,2,5}; do
    ./src/decode.sh:3944:  'M&&E,A[i++]=_ble_decode_Erro|'{254,255}
    ./src/edit.sh:7793:                  ble-decode/keymap:vi_{i,n,o,x,s,c}map/define
    ./src/util.sh:2667:    builtin unset -f ble/function#advice/{before,after,around,original}:"$name" 2>/dev/null
    ./src/util.sh:4218:    ble/array#push dirs "$_ble_base"{,/contrib,/lib}
    $ grc '[^$]\{[0-9.]+\}' --exclude={wiki,memo,test,ext} --exclude={lib/test-\*.sh,make_command.sh}
    ./lib/init-bind.sh:153:  for i in {128..255} {0..127}; do
    ./src/decode.sh:3937:  'M&&E,A[i++]='{0..127}
    ./src/decode.sh:3938:  'C=C<<6|'{0..63}',--M==0&&(A[i++]=C)'
    ./src/decode.sh:3939:  'M&&E,C='{0..31}',M=1'
    ./src/decode.sh:3940:  'M&&E,C='{0..15}',M=2'
    ./src/decode.sh:3941:  'M&&E,C='{0..7}',M=3'
    ./src/decode.sh:3942:  'M&&E,C='{0..3}',M=4'
    ./src/decode.sh:3943:  'M&&E,C='{0..1}',M=5'
    ./src/decode.sh:3985:  for i in {0..255}; do

    それほど多い訳でもないが代替手段がある訳でもない様な物が多く含まれる。
    うーん。これも ble.sh の内部では解除するオプションとするべきの気がする。

    set -k に対しては bleopt a=b 等が影響を受ける。他にも影響を受ける物は多く存
    在するかもしれない。何れにしてもこのオプションは非現実的である様に思われる
    のでやはり ble.sh 内部では解除する事としたい。

  * kitty, fzf: modifyOtherKeys で問題が生じている (reported by Nudin) [#D1627]
    https://github.com/akinomyoga/ble.sh/issues/126

    うーん。fzf が modifyOtherKeys で動かなくなっている。
    というか補完全般で問題が生じるのだろうという気がする。

    x 何故か知らないがまた kitty で動かなくなっている。うーん試して見た所、いつ
      の間にかに \e[>4;0m ですら効かなくなっている様だ。\e[>4m としなければなら
      ない。もう面倒なので kitty の時だけ異なる sequence を出力する様に修正する。

      以前は確かに修正したと思ったのだが…。確認すると以下で動作する事を確認している。
      ということはまた kitty の振る舞いが変わったという事である。
      https://github.com/akinomyoga/ble.sh/issues/110#issuecomment-841839605

      取り敢えず修正した。動作確認した。OK と思う。

  * kitty: keypad enter が変なシーケンスで送られてくる (reported by Nudin) [#D1626]
    https://github.com/akinomyoga/ble.sh/issues/127

    取り敢えず以下に挙げられているキーの番号を kitty 専用に判定する事にした。
    https://sw.kovidgoyal.net/kitty/keyboard-protocol.html#functional-key-definitions

  * compat: terminal dnkl/foot は DA2 で 010801 などの文字列を返すようだ (reported by GorrillaRibs) [#D1625]
    https://github.com/akinomyoga/ble.sh/issues/128

    これが DA2 の判定で8進数と解釈されてしまって問題が発生している。
    escape sequence に含まれる数字は全て明示的に10進数で解釈するべきである。

    因みに dnkl/foot は DA3 で FOOT という文字列を返すそうだ。

    * dnkl/foot を認識する様にした。
    * CSI の解釈で 0 が前置されていても良い様に書き直した。
      一部の CSI については既に対策されていたが今回全てに対して処理する事にした。
    * DA2 の解析はまた別の箇所で行われていた。これも対処する事にした。
    * ble/canvas/trace の諸々の制御機能についても対策した。
    * SGR の解析部分 (ble/color/read-sgrspec) は既に対処済みだった

    https://github.com/akinomyoga/ble.sh/issues/128#issuecomment-878670622

    追加修正。10# で後ろに何も数字が続いていないと 5.1 ではエラーになる。
    これは修正した。多分大丈夫。

2021-07-12

  * emacs モードで vi-bword 使う (requested by SolarAquarion) [#D1624]
    https://github.com/akinomyoga/ble.sh/issues/125

    調べると vi-bword vi-Bword があって、内部的にはそれぞれ vword uword として
    いる。それなら edit.sh に既に定義されている vword, uword を代わりに呼び出し
    たら良いのではないか、と考えたが、vword は定義されていない。実装を具体的に
    観察すると単純に単語決定に使う文字集合を edit.sh に引き込めば良いという訳で
    もない。

    観察する限りでは別に emacs mode でこの vi-bword 等を呼び出しても特に問題は
    生じない様にも見える。念の為どの変数を参照していてどの変数が emacs mode で
    期待している値になっているのかについて確認する。

    単語単位の移動は ble/widget/vi-command/forward-word.impl 等で実行されている。
    特別な動作をするかどうかは渡された引数 flag で判定している。取り敢えず flag
    が空だと仮定するとそのまま ble/widget/vi-command/exclusive-goto.impl
    "$index" "$flag" "$reg" が呼び出される。そしてそのまま exclusive-range.impl
    に渡される。ble/keymap:vi/needs-eol-fix "$dst" && ((dst--)) が呼び出されて、
    移動して、 ble/keymap:vi/adjust-command-mode が呼び出さる。

    * 最初の flag に関しては ble/keymap:vi/get-arg 経由で _ble_keymap_vi_reg の
      値を読み取っている。これは get-arg を呼び出していれば clear されている筈。
      一方で、set -o emacs 等を実行した時にちゃんとクリアされるだろうか。少なく
      とも vi-command/accept-line の中では clear-arg が呼び出されている。

      vi_imap の中にいる時にちゃんと clear されているのかというのは気になる。一
      応 ble/widget/vi_nmap/.insert-mode を呼び出す時にはちゃんと
      ble/keymap:vi/clear-arg が事前に呼び出される様に書いてある様である (見落
      としはあるかもしれないが)。

      emacs-editing-mode 経由で切り替えた時にちゃんと arg が clear されるのかど
      うか。見た所は全く考慮に入れていない様に見える。

      a reject: keymap に attach する時に clear する? 然し emacs 側で始末するの
        も変である。本来独立に実装されているべきである。

      b という事を考えると detach 時に処理できる様にするべき? 然しその場合には
        新しく __detach__ という特別キーも定義する必要が出てくる。もし定義した
        とすると、それを処理するのは何処で行うべきだろうか。
        ble/decode/reset-default-keymap を弄れば良い様な気もするが、初回呼び出
        しの際には既定で 'emacs' が代入されている為、detach が無意味に呼び出さ
        れてしまう気がする。それは変だ。

        a 或いは初期値を emacs 以外 (例えば safe) などにするという手もあるだろ
          うか。

        b 或いは初期値は空でも良いのかもしれない。例え emacs であっても初期化な
          しに使える訳ではない筈だから、現状の実装で必ず初期化は実行されている
          と見做すべきである様に思われる。

        c 或いは safe を代入しておくのでも良いのかもしれない。然し確認してみた
          所、safe であっても初期化なしには使えない様である。なので結局
          _ble_decode_keymap の初期値は空文字列で良いのではないかという気がする。

      もっと全然別の方法で clear される事を保証する事はできないのか。

      c 例えば、emacs-editing-mode widget 自体に clear-arg を呼び出すコードを付
        加しておくなど。

      d それよりは change-editing-mode hook でも定義しておくのが良い様な気もす
        る。然し、それだと結局 __detach__ の劣化版にしかならないので、それぐら
        いならば b の __detach__ に対応するべきの気がする。

      今の所 b が最有力の対処方法である。

    ble/keymap:vi/needs-eol-fix については現在の keymap が vi[on]map でなければ
    false になるので記にしなくて良い。

    ble/keymap:vi/adjust-command-mode については

    * _ble_keymap_vi_search_activate が非空の時に何か処理している。

      これは様々の検索で使われている気がする。例えば単語検索等の一致で使われて
      いる? この状態で vi_imap に入ったりすると値が残る気がする。と思ったが別に
      値は代入されていなかった。改めてどの状況でクリアされるか確認する。

    * _ble_edit_mark_active == vi_search の時にも何か処理している。

      これはどうやら $_ble_keymap_vi_search_activate 経由で代入される様だ。

    * _ble_keymap_vi_search_matched が何か有限の整数値を持っている時にも処理がある。

      その他は特に何も無いように見える。これらの変数についてそれぞれどう設定さ
      れてどう clear されるのか確認する。

    うーん。上記に関しては .insert-mode の中で
    ble/keymap:vi/search/clear-matched を呼び出す事にした。また、emacs mode に
    対しては clear-arg の処理に際して同時に clear-matched も呼び出す事にした。

    [動作確認]

    o 取り敢えず __detach__ は実装して思い通りに動く事を確認した。

    o また vi-bword が動作する事も確認した。テストが面倒なのでこれ以上の細かい
      動作確認は省略する。

2021-07-08

  * nullglob が勝手に on になってしまう現象 (reported by Lun4m) [#D1623]
    https://github.com/akinomyoga/ble.sh/issues/123

    nullglob を保存復元している ble/complete/util/eval-pathname-expansion が怪
    しいと考えたが実際に動作を確認してみるとどうやらこの関数の外側で状態が書き
    換わっている様である。また、補完の最中に設定が書き換わる事に違いない。と思っ
    たが分かった…。148 で抜ける時に dtor を実行せずに eval-pathname-expansion
    を抜けていた。修正した。

2021-07-04

  * bash-completion (_find): error message (reported by oc1024) [#D1622]
    https://github.com/akinomyoga/ble.sh/issues/121
    https://github.com/scop/bash-completion/issues/509
    https://github.com/scop/bash-completion/commit/f1ddf810e4ee6693acb9fab1be1794586aa111a0

    これはどうしようもない。bash-completion が悪い。

  * ble-0.3: bashrc で bind '"\e[D": backward-char' を実行した時にエラーメッセージ [#D1621]
    https://github.com/akinomyoga/ble.sh/issues/122#issuecomment-872690396

2021-06-19

  * term: どうも GNOME terminal が terminal identification を変更した様だ [#D1620]

    65;600x;1 になっている。

    | 6cd4713c5 src/vteseq.cc (2018-03-27) int const version = (VTE_MAJOR_VERSION * 100 + VTE_MINOR_VERSION) * 100 + VTE_MICRO_VERSION;
    | 6cd4713c5 src/vteseq.cc (2018-03-27) reply(seq, VTE_REPLY_DECDA2R, {65, version, 1});
    |
    | fde88ef7f src/vteseq.cc (2018-03-27) if (version != NULL) {
    | fde88ef7f src/vteseq.cc (2018-03-27)         for (i = 0; version[i] != NULL; i++) {
    | fde88ef7f src/vteseq.cc (2018-03-27)                 ver = ver * 100;
    | fde88ef7f src/vteseq.cc (2018-03-27)                 ver += atol(version[i]);
    | fde88ef7f src/vteseq.cc (2018-03-27)         }
    | fde88ef7f src/vteseq.cc (2018-03-27)         g_strfreev(version);
    | fde88ef7f src/vteseq.cc (2018-03-27) }
    | fde88ef7f src/vteseq.cc (2018-03-27) g_snprintf(buf, sizeof (buf), _VTE_CAP_ESC "[>65;%ld;0c", ver);
    |
    | Behdad Esfahbod
    | 3b22bcc86 src/vteseq.c (2009-01-06) g_snprintf(buf, sizeof (buf), _VTE_CAP_ESC "[>1;%ld;0c", ver);
    |
    | f3d79059c src/vteseq.c (2006-02-10) version = g_strsplit(VERSION, ".", 0);
    | f3d79059c src/vteseq.c (2006-02-10) if (version != NULL) {
    | f3d79059c src/vteseq.c (2006-02-10)         for (i = 0; version[i] != NULL; i++) {
    | f3d79059c src/vteseq.c (2006-02-10)                 ver = ver * 100;
    | f3d79059c src/vteseq.c (2006-02-10)                 ver += atol(version[i]);
    | f3d79059c src/vteseq.c (2006-02-10)         }
    | f3d79059c src/vteseq.c (2006-02-10)         g_strfreev(version);
    | f3d79059c src/vteseq.c (2006-02-10) }
    | f3d79059c src/vteseq.c (2006-02-10)   ret = g_strdup_printf(_VTE_CAP_ESC "[>1;%ld;0c", ver);
    |
    | Nalin Dahyabhai
    | ddad9e00e src/vte.c (2003-06-27) ret = g_strdup_printf(_VTE_CAP_ESC "[>1;%ld;0c", ver);
    |
    | 3c6d81bf0 src/vte.c (2002-08-22) version = g_strsplit(VERSION, ".", 0);
    | 3c6d81bf0 src/vte.c (2002-08-22) if (version != NULL) {
    | 3c6d81bf0 src/vte.c (2002-08-22)         for (i = 0; version[i] != NULL; i++) {
    | 3c6d81bf0 src/vte.c (2002-08-22)                 ver = ver * 100;
    | 3c6d81bf0 src/vte.c (2002-08-22)                 ver += atol(version[i]);
    | 3c6d81bf0 src/vte.c (2002-08-22)         }
    | 3c6d81bf0 src/vte.c (2002-08-22)         g_strfreev(version);
    | 3c6d81bf0 src/vte.c (2002-08-22) }
    | 3c6d81bf0 src/vte.c (2002-08-22) ret = g_strdup_printf("1;%ld;0c", ver);
    |
    | commit 3c6d81bf06becda3f9ab005c7310b2343588115e
    | Author: Nalin Dahyabhai <nalin@src.gnome.org>
    | Date:   Thu Aug 22 23:27:31 2002 +0000
    |
    |     * src/vte.c: Implement send-primary/secondary-device-attributes.  Bind
    |             shift+insert to "paste PRIMARY".  Guard against NULL window/icon title
    |             when telling the child app what they are.

    この歴史を観察すると一番最初に vte に実装された時 2002-08 から 1;version;0 であったが、
    2018-03 に 65;version;0 に変更された様である。VERSION は何処で定義されているのだろうか。

    | 現在の version は meson.build の中に定義されている。
    |
    |   project(
    |     'vte',
    |     ['c', 'cpp'],
    |     version: '0.65.0',
    |
    | meson に移行したのは 7566ad673 (2019-04-14) である。この時は 0.57.0
    |
    |   7566ad673 (Christian Persch 2019-04-14 21:11:43 +0200  20)   version: '0.57.0',
    |
    | それより前は configure.ac に定義されていた様だ。
    |
    |   m4_define([version_major],0)
    |   m4_define([version_minor],57)
    |   m4_define([version_micro],0)
    |
    | fde88ef7f の時点での version は 0.53.0 の様だ
    |
    |   137e16630 configure.in (Behdad Esfahbod      2010-06-30 15:27:30 -0400   1) m4_define([version_major],0)
    |   6f330cc1a configure.ac (Christian Persch     2018-03-12 21:44:43 +0100   2) m4_define([version_minor],53)
    |   b4b2eb2ce configure.ac (Christian Persch     2018-03-05 21:58:12 +0100   3) m4_define([version_micro],0)

    従って 1;5300;0 から 65;5300;1 に移行したという事。

    * 他の端末についても確認してみると konsole は 0;115;0 に固定である。
      (src/Vt102Emulation.cpp Vt102Emulation::reportSecondaryAttributes)

2021-06-13

  * 2021-06-06 complete: auto-menu の振る舞いの調整 [#D1618]

    * ok: auto_menu に於いては empty_completion の抑制もするべき。というか一般
      に auto に対して抑制するべきの気がする。と思ったが、実際に実装を確認する
      と既にその様な実装になっていた。no-empty opts を指定していた。

    * reject: うーん。auto-menu を既定で on にする事も考えたがこれは流石にうる
      さい様な気がする。やはり好き嫌いが出るだろうから既定で on にするのは避け
      た方が良い様に思われる。然し、on にした時にはできるだけ自然な動作になる様
      に努めたい。

    * complete_limit_auto_menu?

      導入した。然し、complete_limit_auto_menu を導入すると複数の source から候
      補を生成した時に一部の source からの結果だけ抽出してしまう。その時点では
      それで良いかもしれないが menu-filter が走ると直ぐに候補の数が少なくなって
      候補がなくなってしまう。此処で改めて候補を生成したい所だが、

      a complete_limit に引っかかったら全体をキャンセルして中途半端な候補による
        menu は表示しない。

      b (no items) になったら改めて候補を再生成する。然し、これは何処に実装する
        べきだろうか。実装するとしたら menu-filter.idle の気がする。然し、その
        menu がどの様に start したかによって振る舞いを変えるべきではないか。例
        えばユーザーが明示的に source を指定して候補を生成した場合には勝手に再
        生成すると元々のユーザーの与えた絞り込みが消えてしまう。

        或いは候補の生成に要した設定を何処かに記録しておいて同じ設定で補完を開
        始するという事。入力内容が増えた事によって絞り込み候補が少なくなったり
        して曖昧補完に移行するなどの事が考えられる。

      同様に menu-filter.idle の開始点よりも前に移動した場合も候補を再生成する
      べきなのではないだろうか。

  * 2021-06-10 prompt: [最適化] 単純なプロンプト内容は ${PS1@P} で展開? [#D1617]

    プロンプトが単純な内容しか含んでいない時には ${PS@P} で計算を省略できるので
    はないか。つまり、\X で特別な物を含んでいない限りは bashに任せる事ができる。
    (一方で \w の追跡などについては個別に判定する必要がある気もする。)

    然しそんなに速度向上には寄与しないのではないかという気もする。結局 trace は
    しなければならないからである。

    取り敢えず PS1 が単純化どうかの判定をどうするか。\ の後に "安全" でない文字
    が続いている物は全て除外するのが良い様に思われる。"安全" な文字を列挙する。

    - 0-7aenrdtAT@DhHjlsuvV[]!$\
    - wW ... これらには add-hash を付加したい様に思われる。
    - # ... これは駄目。ble.sh 的には内部の bash の番号をちゃんと更新できていない。

    意外と簡単に実装できた。動いている。\# も大丈夫。\w の更新も大丈夫。

  * 2021-06-06 prompt: エラーはまとめて出力するべき? [#D1616]

    現在の実装だとエラーを直接その場に出力する仕組みになっている。然しそうでは
    なくて、例えば新しい行を表示する直前等にエラーメッセージを出力するべきの気
    がする。その場合にはプロンプトの類を一旦仕舞うなどの工夫が必要である。或い
    は、trace 等で計測して出力する事になる。trace で計測したとしても画面の範囲
    よりも大きい場合には表示しきれないという事等色々考えるとプロンプトの類を一
    旦仕舞うのが妥当な気がする。

    特にプロンプトに関連するエラーはプロンプトの表示直前にまとめて表示するのが
    良いのではないか。と思ったが、プロンプトの部分更新でもエラーは発生する。と
    いう事など考えていくと微妙。というかプロンプトの処理に関しては、
    visible-bell で良いのではないかという気がする。

    というかそもそもエラーメッセージを表示する意味はあるのだろうか。認識してい
    なかったら単純に \q{...} のまま出力すれば良いのではないか。うーん。取り敢え
    ずは \q{...} の形でそのまま出力すると共に、visible-bell でも表示する事にし
    た。

2021-06-12

  * benchmark: ble-measure が bash-4.4 未満で結果を返さなくなっている [#D1615]

    これは local TIMEFORMAT= を指定したのが原因だった。
    TIMEFORMAT が unset の時には既定の結果になるが、
    TIMEFORMAT が空文字列の場合には既定の結果にはならないのだった。
    この際なので TIMEFORMAT に単純な文字列を指定して計測する事にした。

    この問題は割合最近に埋め込んだ物の気がする。確かめてみる。bbc2a904
    src/benchmark.sh 2021-05-19 11:25:18 +0900 である。うーん。この commit は雑
    多の物をまとめた commit である。特に ble.pp のロード時間計測コードを
    TIMEFORMAT を使って見やすくした時にその序として benchmark.sh で TIMEFORMAT
    が書き換えられていた時の対策のコードをちゃんとテストせずに書き加えたのが原
    因であった。

  * 2021-05-15 util: ^A, ^? を含む排列に関連するテストが失敗している [#D1614]

    % ^A 及び ^? に対する declare -p 補正が動かなくなっている @ bash-3.2
    %
    % #D1522 に於いて bash-3.2 以下では配列表記で ^A が ^A^A^A^A になる事を発見
    % したと思ったが、何故か今手許で試してみると ^A^A にしかなっていなくて以前
    % のコードでも良かったという事になる。再現するための条件が何かあるのだろう
    % か。例えばスクリプト内部では declare -p の結果は ^A^A^A^A になるなど。
    %
    % うーん。ble/util/assign を介すと確かに ^A^A^A^A になるがそれは scalar も
    % array も同様になっている。然し、#D1522 で対処した問題は配列の時にのみ起こっ
    % ていた問題の筈なのでこれは関係ない。
    %
    % 関数内のみで起こる問題の可能性? と思ったがそれも変である。実際に ^A^A^A^A
    % にならず ^A^A になっているのは関数内で実行している時である。対話でも ^A^A
    % にしかならない。
    %
    % 元々は memo/D1522.large-array-passing.sh に於いて発生していた問題だった。
    % 今となっては writearray の実装を使う様に変更した為に再現していない。うー
    % ん。分からないので、取り敢えず改めて各 version での振る舞いを整理してそれ
    % で OK とする事にする。
    %
    % 以下が実際にスクリプトを書いて実行してみた結果。
    %
    % * bash-3.0, 3.2, 3.2
    %   declare -- s="x^A^Ay^A^?z"
    %   declare -a a='([0]="x^A^A^A^Ay" [1]="z^A^A^A^?w")'
    % * bash-4.0, 4.1, 4.2, 4.3
    %   declare -- s="x^A^Ay^A^?z"
    %   declare -a a='([0]="x^A^Ay" [1]="z^A^?w")'
    % * bash-4.4, 5.0, 5.1
    %   declare -- s="x^Ay^?z"
    %   declare -a a=([0]=$'x\001y' [1]=$'z\177w')
    % * bash-dev
    %   declare -- s=$'x\001y\177z'
    %   declare -a a=([0]=$'x\001y' [1]=$'z\177w')
    %
    % うーん。やっぱり二重にエスケープされている気がする。
    % 発生する条件があるのだろうか。
    %
    % a 関数の中で実行すると発生しなくなる? そういう訳でもない様だ。
    % b interactive session で実行すると発生しなくなる? →そうでもない
    % c ble.sh をろーどしていると発生しなくなる? →そうでもない
    % d サブシェルで実行すると発生しない? →そうでもない
    %
    % うーん。これは寧ろチェックコードの方の問題だろうか?
    %
    % a コピーに関しては問題ない
    % b 出力に関しては
    % c 比較対象の "正解" を生成する時に "正解" が化けている。
    %   あー。これだった。修正した。というか正解はハードコードする事にした。


    結局問題は arr=(...) の形式でテスト用の配列を用意した時点で ^A や ^? が
    ^A^A や ^A^? に化けてしまっていた事にあった。それなのに、配列の中には ^A や
    ^? が正しく格納されているという前提で declare -p arr の結果だけに着目してい
    たのが混乱の原因だった。

    * 何と $'\c?' は Bash-4.4 と 4.3 以下で振る舞いが違う様だ。最近書いた関連
      するコードを fixup した。

    * 他にも類似の問題が生じている。これもテストの問題なのだろうか。

      L1482 で発生している問題。うーん。これもやはりテストの側の問題だった。
      というかどうやったら正確にテストする事ができるのか?

      色々試したが何だか変だ。これは出力する時の問題ではなくて、変数に代入する
      時の問題だろうか。特に配列に代入する時に発生する問題?

      →うわー。やっぱりそうだった。という事は今 writearray でやっている処理は
      正しくない。writearray でやっている処理は arr=() で代入した事によって壊れ
      ている内容を正しい物に修正するという様な処理を行っている事になる。


      * done: writearray 修正 (^A^A^A^A 対策コード除去)
      * done: print-definitions 修正 (^A^A^A^A 対策コード除去)
      * done: print-definitions の出力で arr=() の形式を避ける。
        print-definitions はどの様に修正したら良いのか非自明である。というのも
        ^A 及び ^? を含む時にどの様な内容を出力しても arr=() の形式を使っている
        限りは正しい値を代入することができないからである。

      取り敢えずこれについては修正した。OK

  * 2021-05-15 test: BUG 失敗する様になっている [#D1613]

    * quote-command の test に失敗している @ bash-4.3 直した

    * ^A, ^? を含む排列に関連するテストが動かなくなっている → #D1614
    * ble-measure が bash-4.4 未満で結果を返さなくなっている → #D1615

      これらについては別項目で処理する事にする。

  * main: DEBUG version の bash で警告を表示する [#D1612]

    relstatus が alp*|bet*|dev*|rc*|releng*|maint* の時にはロード時に "遅い" と
    いう事を警告するべきではないか。同時に wiki か README にも注意書きを書く必
    要はあるだろうか。

  * complete: "complete -p" 解析の修正 + 細かい修正 [#D1611]

    complete に対する細かい修正が溜まっているのでいい加減に push する。

    * 一つは quote された progcomp　が正しく unquote されずに続く complete -p
      の関数名抽出に渡っている問題の修正。

    他は m scan に関連する軽微なミスである。

    * local "${_ble_complete_cand_varnames[@]}" の localvar_inherit に対する対
      策が間違っている問題。

    * 文字数を数えるのに ${#ret[0]} の形式を使ってしまっている問題 (bash-3.0
      bug)

  * util: bleopt の unknown option の表示が空になる [#D1610]

    bleopt で誤ったオプション名を指定した時のエラーメッセージでオプション名が空
    文字列になっている。

  * prompt: \g{...} [#D1609]

    将来的に Bash が \g に対応するとしても \g{...} の形になるとは限らないし、ま
    た、\g 単体であれば \g と \g{...} を区別する事によって処理を分ければ良い。
    偶々 \g の次に {...} を書きたいという事もそうあるまい。

  * reject: idle: 時々自動的に表示更新をかけるべきではないか [#D1608]

    裏で処理が走っている間に状態が変化してそれを表示に反映させたい時にはどうす
    るのか。現在の実装だとその様な仕組みにはなっていない筈。例えば
    textarea#invalidate を実行した時にその場で反映されるだろうか。

    処理が一巡したら、もしくはn巡したら更新するのも良い気がする。否、時間を決め
    て置いてある程度時間が経ったら更新するというのでも良い。しかしそれならば、
    普通の task として n 秒置きに更新をかけるというので良い気がする。その様にし
    ておけば idle の他の処理が終わった後でも更新を確認し続ける様になるし自然な
    実装であるように思われる。

    それとは別に idle 内部の動作によって表示を更新する必要があるのであれば、そ
    の動作を起こした側でその場で更新をかけるか或いは新しく task を投入するかす
    るべきなのである。

  * util (bleopt): 遅延定義された設定項目の check [#D1607]

    airline: ble-reload する時に状態が書き換わってしまっているのに bleopt
    vim_airline_theme=light の儘なので初期化が正しく為されない。うーん。既定値
    から再設定される筈なのだがそれも正しく処理されていない? と思ったがそれは
    ble.sh のロード時に処理される事なので遅延ロードされるモジュールの設定には当
    て嵌まらないという事。遅延ロードされる時にはその場で "設定" を再現する必要
    があるのではないか? 然し、そうすると関連する関数が既に定義済みでないと正し
    く動作しない事になる。或いは bleopt -I vim_airline_@ 的な関数を最後に呼び出
    して最初期化を強制するという可能性もある。

    現在遅延定義される設定項目は恐らく vim_airline 及び vim_surround に限られる。
    complete, syntax は ble.sh に設定項目を定義しているので問題にならない。

    * done: vim-airline で bleopt -I vim_airline_@ を実行する

    * done: 他にも影響のある場所がないか確認する。特に bleopt/check:
      を定義しているオプションで、ble.pp の "bleopt -I" よりも後に実行
      される可能性のある物が対象である。

      確認した所 core-syntax.sh で定義されている check:filename_ls_colors が怪
      しい。と思って実際に確認してみた所ちゃんと対策は為されていた。今回のこの
      対策を bleopt -I を使う物に置き換える事にする。

    * ok: update wiki と思ったが、元々 bleopt はそんなに詳しく説明していなかっ
      た。bleopt -u　も bleopt -r も wiki には説明が書かれていないので、bleopt
      -I について今すぐに追加しなければならないという事はない気がする。一方で、
      bleopt のもっと詳しい説明についてはいつか書かなければならない。

  * prompt-git: bash 3 では async にできない→修正した [#D1606]

  * history: cygwin に於いて arg_offset を処理していない気がするが大丈夫なのか [#D1605]

    ble/builtin/history/.load-recent-entries から append:count=$delta という形
    で呼び出されている。Cygwin の時でも同様である。count により追加分だけが
    background で dump される様子である。arg_offset が使えない時には arg_count
    をクリアする等の工夫もされていない。つまり、Cygwin 上では正しく動かないとい
    う事? これを実装した時にどう考えていたのか後でログを確認する必要がある気が
    する。或いはもしかして何か ToDo に項目が残っていたりするだろうか。

    * 現在の実装について記録を確認

      うーん。何か ToDo に残っていないか探してみたが cygwin/Cygwin　では引っかか
      らない。次に arg_offset を導入した時のログを確認してみる。

      a 1bfc8ebe 2019-07-09 16:42:26 +0900 が怪しい。うーん。当時の記録を確認して
        みたが offset 等の実装の詳細に関する議論は全く残っていない。これは
        history.sh を導入した時の議論であって、恐らくこの時に現在の実装の様に
        history コマンドの模倣も実装してその過程で offset を導入した。

      b と思ったが、その前の f204bc73 src/edit.sh 2019-06-27 20:38:34 +0900 の段
        階で既に arg_offset は導入されていた様である。一応 offset がどうのこうの
        という議論はあるみたいだが、これはまた別の機能の offset の話の様である。
        この時の実装の arg_offset に関係する議論ではない様に見える。更に明示的に
        arg_offset で検索をかけてみたが done.txt の中には何も残っていない様である。

      c 更にその前の commit に行ってみたらもう arg_offset は残っていない。履歴の
        読み取りも直接 mapfile を呼び出しているに留まっている。

      うーん。或いは cygwin　では offset は使わない様になっていたという可能性はあ
      るだろうか。何故 Cygwin の事を考えずに変更を行ったのかかなり理解に苦しむ。
      うーん。それとも += を使う事にしていた可能性? うーん。然し再度確認してみて
      もその様な雰囲気は見られない。

    或いは実はちゃんと実装されていて Cygwin の時には arg_offset があっても問題
    ない様になっている可能性? うーん。そんな風になっている雰囲気は見られないが。。
    取り敢えず、Cygwin でもちゃんと途中からの追記になる様に修正する必要はあるだ
    ろう。

    * history: mapfile -O offset で読み取り始めると既存の項目がクリアされない様
      だが良いのか? これは Cygwin での実装をどの様にするのかという事にも関連し
      ている。

      現在の実装を見ている感じだと offset は任意に指定できる訳ではなくて常に末
      尾を指定する様になっている気がする。もしそれが正しいのだとしたら既存の項
      目の truncate 等について悩む必要はないという事になる。

      * ok: 一方で、_ble_history_edit に関しては一番最後に要素が追加されている
        可能性があるという事を考えると、やはり truncate しておくべきの気がする。
        と思ったが、_ble_history_edit に関しては Cygwin では単に _ble_history
        からコピーしているだけなので気にしなくて良い。

      * done: 末尾以外の offset を指定できる機能は削除するべきだろうか

        別の問題として特に末尾以外の offset が指定された時に後ろに続いているデー
        タを削除するべきか或いは保持するべきかという事。やはり offset を指定し
        ている箇所がないか確認が必要な気がする。という訳で '\boffset=' で検索し
        てみると。

        > $ grc '\boffset=[^=]' --exclude=ext | grep -v 'local offset='
        > ./keymap/vi.sh:2973:  local ind=${1:-$_ble_edit_ind} offset=$2
        > ./lib/core-complete.sh:2221:  local word1 index=0 offset=0 sep=
        > ./lib/core-complete.sh:4411:##     offset=NUMBER
        > ./lib/test-edit.sh:11:  local _ble_edit_str=$1 index=$2 offset=$3
        > ./lib/test-edit.sh:16:  local _ble_edit_str=$1 index=$2 offset=$3
        > ./src/edit.sh:1880:  local index=${1:-$_ble_edit_ind} offset=${2:-0}
        > ./src/edit.sh:1914:  local index=${1:-$_ble_edit_ind} offset=${2:-0}
        > ./src/history.sh:283:  ##     offset=NUMBER
        > ./src/history.sh:301:    elif local rex=':offset=([0-9]+):'; [[ :$opts: =~ $rex ]]; then
        > ./src/util.sh:617:  # Note: Bash 4.3 以下では ${arr[@]:${2:-1}} が offset='${2'

        やはり誰も　offset は指定していない。この機能は削除する。

      結局 truncate はしなくて良いと判断する。何故なら offset が指定されるとし
      ても常に末尾に対する追加だからである。

    * 次の問題は Cygwin に於いてどの様に追記を実装するのかという事である。

      % += を使うと 3.0 で使えない。然し ble/array#push は遅そうである。うーん。
      % 複雑になるが opt_source と arg_offset に応じて分岐する事にする。という
      % 訳で offset==0 の時には今まで通りにして、それ以外で bash-3.1 以上の場合
      % は += に置き換える。bash-3.0 の場合には _ble_history[10000]='str' とい
      % う具合に直接 index を指定して出力する事にする。
      %
      % →結局 arr=() arr+=() は遅いという事が分かったので、arr[ind]=str 一本で
      % 実装する事にする。

      ? 然し改めて思ったのだが、そもそも array=() や array+=() は arra[]='...'
        よりも高速なのだろうか。実験してみる価値はある。

        $ for a in {0..3}; do history; done | sed 's/'\''//g;s/^[[:space:]]*[0-9]\{1,\}[[:space:]]*//' > h.txt
        $ < h.txt awk 'BEGIN{apos="'\''"}{print "_dbg_history[" NR - 1 "]=" apos $0 apos}' > a.txt
        $ < h.txt awk 'BEGIN{apos="'\''";print "_dbg_history+=(";}{print apos $0 apos}END{print ")";}' > b.txt
        $ time source a.txt
        0.222
        $ _dbg_history=(); time source b.txt
        0.211

        うーん。Cygwin で試してみた限りでは大して変わらない様に見える。若干
        arr+=() の方が速いぐらいである。でも bash-3.0 では試していない。Cygwin
        には bash 3.0..3.2 は入れていない。然し、一応 Linux で bash 3 でどちら
        かが致命的に遅かったりという事がないかを確認する事にする。

        $ bash -c 'TIMEFORMAT="%Rs"; time source a.txt'
        0.454s
        $ bash -c 'TIMEFORMAT="%Rs"; time source b.txt'
        0.483s
        $ bash-3.0 -c 'TIMEFORMAT="%Rs"; time source a.txt'
        0.886s
        $ bash-3.0 -c 'TIMEFORMAT="%Rs"; time source b.txt'
        b.txt: line 1: syntax error near unexpected token `newline'
        b.txt: line 1: `_dbg_history+=('
        0.002s
        [ble: exit 1]
        $ bash-3.1 -c 'TIMEFORMAT="%Rs"; time source a.txt'
        0.770s
        $ bash-3.1 -c 'TIMEFORMAT="%Rs"; time source b.txt'
        物凄く時間がかかるので中止した
        $ bash-3.2 -c 'TIMEFORMAT="%Rs"; time source a.txt'
        0.757s
        $ bash-3.2 -c 'TIMEFORMAT="%Rs"; time source b.txt'
        ^C
        [ble: exit 130]
        $ bash-4.0 -c 'TIMEFORMAT="%Rs"; time source a.txt'
        0.782s
        $ bash-4.0 -c 'TIMEFORMAT="%Rs"; time source b.txt'
        ^C
        [ble: exit 130]
        $ bash-4.2 -c 'TIMEFORMAT="%Rs"; time source a.txt'
        0.613s
        $ bash-4.2 -c 'TIMEFORMAT="%Rs"; time source b.txt'
        0.929s
        $ bash-4.4 -c 'TIMEFORMAT="%Rs"; time source a.txt'
        0.474s
        $ bash-4.4 -c 'TIMEFORMAT="%Rs"; time source b.txt'
        0.911s
        $ bash-5.0 -c 'TIMEFORMAT="%Rs"; time source a.txt'
        0.457s
        $ bash-5.0 -c 'TIMEFORMAT="%Rs"; time source b.txt'
        0.494s
        $ bash-dev -c 'TIMEFORMAT="%Rs"; time source a.txt'
        0.322s
        $ bash-dev -c 'TIMEFORMAT="%Rs"; time source b.txt'
        0.383s

        この結果を見ると arr+=() は古い bash では致命的に遅い。arr=() について
        も確認して置いた方が良いのではないか?

        $ < h.txt awk 'BEGIN{apos="'\''";print "_dbg_history=(";}{print apos $0 apos}END{print ")";}' > c.txt
        $ bash-dev -c 'TIMEFORMAT="%Rs"; time source c.txt'
        0.385s
        $ bash-4.4 -c 'TIMEFORMAT="%Rs"; time source c.txt'
        0.901s
        $ bash-4.2 -c 'TIMEFORMAT="%Rs"; time source c.txt'
        0.915s
        $ bash-4.1 -c 'TIMEFORMAT="%Rs"; time source c.txt'
        1.098s
        $ bash-4.0 -c 'TIMEFORMAT="%Rs"; time source c.txt'
        1.099s
        $ bash-3.2 -c 'TIMEFORMAT="%Rs"; time source c.txt'
        1.091s
        $ bash-3.1 -c 'TIMEFORMAT="%Rs"; time source c.txt'
        1.111s
        $ bash-3.0 -c 'TIMEFORMAT="%Rs"; time source c.txt'
        1.155s

        うーん。この結果を見る限りは arr=() に関しては問題は存在しなかった様で
        ある。但しそうだとしても、arr[]=() の方式の方が安定して高速な結果を出し
        ている。これは完全に arr[]='...' に切り替えた方が実装もすっきりするので
        はないか。

      * ok: 一応 #D0701 に議論がある様なので確認しておく。確認した。この時の記
        録を見る限りは "_ble_history[index]='...'" 的な方法については速度を計測
        していないのだという気がする。なので、この方法自体に何か問題があったと
        いう訳ではなく、当時は一顧だにしなかったという事なのだろう。

      arr[index]=str を使うように切り替えた。awk 内部での hindex の取り扱いも変
      更した。これに伴って nlfix の時の修正インデックスの解釈も変更。nlfix につ
      いてはちゃんと変更後も動いている事を確認した。

      x fixed: 後は Cygwin で問題なく動くかを確認する。と思ったら動かない。フリー
        ズしてしまう。何故だろう。

        * うーん。どうも動かない様に見えたのは _ble_history_edit の方をロードし
          ていなかったからの様だ。

        * C-r でフリーズするのも _ble_history_edit に有限の内容が含まれる様に変
          更したら直った。然し、だからと言ってそれだけでフリーズするというのも
          解せない。

          それだと履歴が全く無い時にはどうなるのだろうか。試してみたが特に問題
          は生じなかった。どうも履歴項目で引数が多い物があってそれで遅くなって
          しまっているという事の気がする。これはまた再現したら対処するという事
          で良い事にする。

    これで offset 問題は解決だろうか。trunate に関しては arg_offset が有限の時
    は常に末尾に対する追記という事にした。arg_offset=0 の時には配列をクリアする
    事にした。その上で offset については Cygwin　の場合には直接 arr[index]=str
    の形式で初期化する事にしたので問題ない。他の環境では mapfile -O を今まで通
    り使う。大丈夫な気がする。

  * 2021-05-04 折を見て simple-word/eval のデータ授受にも mapfile -d '' を使う [#D1604]
    Ref #D1522

    mapfile -d "" が buffered になったら
    ble/syntax:bash/simple-word/eval/.print-result (lib/core-syntax.sh) を修正する。

    2021-05-08 もう bash の側では修正されている。然し、Cygwin に対しても動作を
    変更できないかどうか尋ねてその上で改めて一緒に修正するのが良い気がする。

    2021-06-12 未だ Cygwin についても修正できないかの問い合わせはしていないが、
    代わりに history のロードの側でも mapfile -d "" を使う様に変更したので、こ
    の際一緒に変更を適用する事にする。先に修正のある simple-word/eval を差し置
    いて history の方で利用するのは変だし、だからと言って history の方に対する
    変更も pending にするのには変更が大きすぎる。

    * reject: read -t ... についても同様に bash-5.2 以降で実装を切り替えて良い気がする。

      2021-06-12 今改めて考えると read -t の何の振る舞いを切り替えるのか分から
      ない。今まで unbuffered になっていた事によって read -d "" を使いたくても
      使えなかったのを控えていた箇所はあっただろうか。後、read -t というのは
      timeout の指定の事だが、今回の buffered/unbuffered の変化が timeout の振
      る舞いにどう影響を与えるのかは不明である。"read -t" の "-t" は唯単に手の
      癖で入力した物の様な気がする。

      これに関しては取り敢えず棄却で良い気がする。

  * history: [最適化] 初期化に新しい mapfile -d '' を使えないか [#D1603]
    Ref #D0681

    これは ble/util/readarray -d '' で実装されている。と思ったが…そもそも
    builtin mapfile を直接使えば良いのではという疑惑もある。一応、他の version
    の bash でも使える様にしてあるという利点はあるが。

    | というよりそもそも現在の実装になっているのは mapfile -d '' が遅かったからと
    | いう解釈は正しいのだろうか。ログを調べてみる必要がある。うーん。適当に検索
    | してみたが難しい。git blame で観察してみると
    |
    | 1bfc8ebe src/history.sh に移動
    |
    |   現在の実装は 2019-07-09 に大きく書き換えられている。と思ったが…これは単
    |   にコードを移動しただけの話かもしれない→うーん。やはりそうだった。
    |
    | f204bc73 src/edit.sh: history -nr の対応
    |
    | 18fdaf2a Cygwin 対策
    |
    | c0c7f13e 2018-03-14 これ。この時点で mapfile & nlfix を実装している。まと
    |   まった議論があるのもこの時のログである。#D0681 である。

    うーん。当時のログを確認してみるとそもそも mapfile -d '' で NUL 区切りのデー
    タを読み込めるという事を認識していなかった様な節がある。今回改めて実験及び
    実装をして見る事にする。Bash version 毎の配列コピー時間についても確認する。

    - 取り敢えず実装した。ちゃんと読み込めている。やはり配列コピーよりも
      mapfile の方が高速の様である。

    * done: 後で printf '[[%s]]\n' "${_ble_history[@]}" > a.txt 等として出力し
      た結果を比較して正しいかどうかを検証する。

    * done: Cygwin に於ける動作も変更したので動作確認の必要がある。

      Cygwin では awk 側で unescape をする様にしたので nlfix は不要である。

      動作確認の結果 mapfile -d '' の為に書いたコードでやったのと同じミスを修正
      するのを忘れていた。それを修正したらちゃんと動く様になった。OK

  これを機に以前の mapfile の修正も適用してしまう事にする。

2021-06-11

  * 2021-05-16 edit: BUG とても長いプロンプトにした時に列計算が壊れている (reported by telometto) [#D1602]
    また右端から入力を始めた時の折返しが正しくできていない。

    2021-06-11 stackoverflow で報告されていた (by telometto)
    https://stackoverflow.com/questions/67917673/odd-long-space-in-bash-when-writing-commands

    | うーん。ble.sh のバグが stackoverflow で報告されている。これは自分でも気
    | づいていた筈の問題である。何故忘れていたのだろう。割合最近気づいた事だっ
    | た筈である。調べたら 2021-05-16 の項目を見つけたのでそれに移動する事にす
    | る。

    取り敢えず修正する。抑々 trace が怪しいという事なので計算結果について確認する。

    $ x=0 y=0; LINES=10 COLUMNS=10 ble/canvas/trace 'HelloWorld'; declare -p x y ret
    x=10 y=0
    $ x=0 y=0; LINES=10 COLUMNS=10 ble/canvas/trace 'HelloWorldH'; declare -p x y ret
    x=2 y=2

    物凄く意味不明な間違い方をしている。うーん。implicit-move が悪いという所ま
    で特定した。と思ったら分かった。折返しが発生すると分かった場合に x+=w を二
    重に実行している。2回目の x+=w を削除したら普通の振る舞いに戻った。調べてみ
    るとこれは 4fa139ad 2021-03-21 に複数行 "rps1" に対応した時に埋め込んだバグ
    であった。

2021-06-10

  * prompt: 最適化 git の現在の dirty 状態は background で取得できる様にしたい [#D1601]

    prompt-git.bash に実装したい。という事を考えると、
    prompt-git.bash は早晩に lib に移動するべきなのではないかという気がする。

    これはどの様に実装するか。先ず初めに background で git を起動する。timeout
    を指定して直ぐに制御が戻らなければ取り敢えず放置する事にする。その後で結果
    が分かったらそれを取り出す。既に git を起動していて未だ結果が分かっていない
    時には何もしない。最後に結果が分かってから X 秒経過する迄は以前の結果を参照
    する。ディレクトリを移動した場合には、起動中の git はキャンセルして新しいイ
    ンスタンスを起動する。と言った位。

    一から実装する事も可能だが既存の枠組みに沿った形で出来るだけ実装したい。git
    の結果待ちは idle プロセスとして実装する。うーん。history 初期化のコードを
    観察した。正にこれと同じことをしたいのである。

    うーん。ライブラリにしようと思ったが微妙…。実は ble/util/idle.push -F
    tmpfile を使うだけで行ける話ではないか。履歴の場合にはデータが大量だったの
    で各ステップを分割して少しずつ処理する必要があった。然し、今回の場合には
    git の実行を待つという操作が1回存在するだけである。

    実装した。動いている。と思ったが何だか遅い。うーん。ble/util/msleep 20 を入
    れるか入れないかで大分変化する。ble/util/msleep 20 なら1秒で50回捌ける様な
    気がするがそうでもないのだろうか。うーん。取り敢えず一定時間経過する迄は
    version が変化しても無視する事にする。

    - 改めて計測してみると vim-airline を有効にしている時ですら一秒間に20プロン
      プト表示する事ができている。そもそも一つのプロンプトを表示するのに 50ms
      しかかかっていない。なので其処に 20ms 追加するのは 1.5 倍の時間がかかる様
      になる事を意味していて体感としてとても遅くなるのだという事。

    - 取り敢えず前回の結果からそんなに時間が立っていない時、かつ、前回の要求か
      らプロンプト更新が10回以内の時には git の呼び出しは控える事にした。

    # 単純な PS1 の時だけの場合のプロンプトの計算速度はどの程度だろうか。試して
    # みた所、29,26回/秒 だった。平均で 36.4ms かかっている。14ms の短縮である。
    # 此処で　PS1 の処理をなくしたとしてもそんなには変わらないのだろうという気
    # がする。プロンプトの計算は実はそんなに重くないのだろうという事。

    - また Linux では可也高速に git diff --quiet の結果を得る事ができる様なので
      ble/util/msleep の時間も 5 まで減らした。これでも大きすぎるかもしれないが、
      まあ、頻繁に更新はしない事にしているし特に問題にはならないだろう。

  * [dissolved] 2021-05-28 prompt: 最下行で ble-reload すると statusline が重複してしまう [#D1600]

    ble-detach してその後に ble-attach した時には問題は発生しない。
    →これは確認した所再現しなくなっていた。恐らく #D1592 で解決した問題だろう。

  * [reject] 2021-05-24 prompt: プロンプトの変数展開の更新検出 [#D1599]

    プロンプト更新検出に於いてプロンプトに含まれて
    いる変数展開 $XXXX も自動検出する? 然しエスケープや $() 等も拘ってくると複
    雑である。適当な方法で解析できたりしないだろうか。というか、終端を処理する
    為に parse していた様な気もする。その辺りについてはまた後で確認する。

    $RANDOM や $EPOCHREALTIME 等については除外するべきである。これらの変数への
    nref の検出は困難である。という事を考えるとやはりユーザーに任せるという可能
    性も考えられるが。

    然し一方でプロンプトを計算した瞬間の値を参照したいという需要も考えられる。
    例えば $BASH_COMMAND, $LINENO 等がプロンプトに含まれていたとして、その内容
    が変わったからといってユーザーはプロンプトの表示を更新する事を想定はしてい
    ないのではないか。という事を考えるとやはりユーザーが明示的に要求しない限り
    はプロンプトに含まれている変数展開を改めて評価する必要はないのではないかと
    いう気がする。

  * [ok] 2021-05-24 prompt: 現在のモードの算出の共有化・最適化 [#D1598]

    ble/prompt/.get-keymap-for-current-mode やble/keymap:vi/script/get-mode に
    関しては一旦計算値を別の変数に格納してそれを参照して値を計算するべきの気が
    する。これは git 等の最適化と一緒に新しく枠組みを考える事にする。

    取り敢えず枠組みは整えた。そしてこれらの関数では関連する変数に対して
    add-hash を実行している。新しい unit にする程の物でもないだろう。一つにはこ
    れらの関数はそんなに思い関数でもないという事。そして幾つも何度も実行する様
    な物でもないのでキャッシュしても仕方がないのではないかという事。大抵の場合、
    依存関係を追跡するコストの方が大きそうである。なので add-hash をして、これ
    らを含むプロンプトを再更新させるぐらいで良いだろうと思われる。

  * auto-menu: ubuntu20 で auto-menu を有効にしても動いたり動かなかったりである [#D1597]

    auto-menu の起動条件 (直前の widget) に対する判定で失敗しているのだろうか。
    或いはもっと別の要因だろうか。うーん。或いは idle.sleep に失敗しているとい
    う可能性もあるのかもしれない。

    どうやら ble_util_idle_elapsed が常に 0 になってしまって時間が経過しない
    という事で無限ループになっている様子だ。調べると _ble_util_idle_sclock が
    0 の儘で全く動いていない。_ble_util_idle_sclock は ble/util/idle/.sleep
    によって増える手筈になっている。ble/util/idle/.sleep は .sleep-until-next
    から呼び出される事になっているが、この関数の振る舞いを見るとどうやら
    sleep_amount が微妙に負になっている。現在時刻と次のタスクをする時刻を比較
    しているが、次のタスクを実行する時刻が何故か現在時刻よりも前の時刻になっ
    てしまっている。

    現在時刻は ble/util/idle.clock で取得されていて内部的には ble/util/clock
    になっている。ble/util/clock は中で EPOCHREALTIME を参照している。一方で
    次の時刻 _idle_next_time は何処から来るのかというと task の SXXXX という
    エントリーから読み出される。この SXXXX というエントリーは
    ble/util/idle.sleep で設定されていて、その関数の中で ble/util/idle.clock
    が呼び出されている。整理すると

    1 最初に ble/util/idle.sleep が呼び出されてその時の時刻を元にして待ち時刻
      が設定される。何らかの処理がなされてその回のループが終了する。

    2 次のループに入る前に次の待ち時刻まで sleep する。しかし、この時迄に時刻
      が経過して次の待ち時刻を超えてしまうので、スリープ無しで次のループが始
      まる。

    3 再び auto-menu.idle が開始するが auto-menu.idle は合計 sleep 時間を使っ
      て経過時刻を確認する。然し、実際には sleep は行われていないので
      auto-menu.idle は時間が経過していないと勘違いして再び sleep を設定して
      抜ける。

    此処での問題は auto-menu.idle は絶対時刻による待ちを設定しているのにも関
    わらず、判定及び残り sleep 時間の算出に sclock つまり sleep 合計時間を使っ
    ている事である。どちらかに統一するべきである。裏で重い処理が走っていよう
    ともそれはユーザーには見えないのでできるだけ定刻通りに処理を開始するべき
    であると思うと、絶対時刻を使用する方に揃えるべきである。

2021-06-09

  * 2020-09-07 complete: メニュー絞り込みの着色が残ったままになってしまう事がある [#D1596]

    menu_filter が off にならない状況が分かった。auto-complete による単純挿入で
    継続した時、menu_filter が更新されない。更に別の機能によって menu が削除さ
    れてしまった時にも更新されない?

    | と思って実装を確認したがそうでもない様な気がする。実装を確認すると現在の
    | keymap が menu-complete でもない限りは menu-filter の処理を走らせている。
    | 領域抽出などに失敗した時にも単に menu を clear するだけでそれ以外の特別な
    | 解除処理は行っていない。だとすると、menu-filter の着色の側で処理を行って
    | いる?
    |
    | 然し ble/highlight/layer:menu_filter/update を見る限りは現在 menu が表示
    | されている場合にのみ着色を行う様になっている。うーん。或いは dirty range
    | がない限りはそもそも layer が呼び出されない可能性? と思ったがそれも変であ
    | る。何か文字列を入力してもやはり着色が残ってしまうという現象が見えていた
    | 筈である。

    - やはり振る舞いを見るとちゃんとキャンセルはされている様である。この時に
      layer が更新されないのが問題なのだと思われる。
    - 更に layer の実装の方も確認してみると、これもちゃんと動いている気がする。
      ちゃんと update-dirty-range が呼び出されている。此処で改めて表示が更新さ
      れるべきなのである。うーん。勝手に後で表示が変化しているという事なのか。

    - 或いは、上の layer が更新を無視してしまっているのか。layer の list を確認
      すると plain syntax menu_filter region overwrite_mode disabled になってい
      る。 overwrite_mode と disabled は不活性になっていて region は
      auto_complete によって設定されている。つまり region が変更を握りつぶして
      いるという事。再構築の部分を確認してみると、既存の内容は全て捨てて下層と
      現在の範囲着色で完全に再構築している。

      うーん。分かった。選択範囲の変更がない場合に、例え下層で何か変更があった
      としてもスキップしてしまう様になっている。

    ? ok: layer:menu_filter は layer:region を参考にして作られた同様の問題点は
      ないだろうか→確認したがその問題はなさそうである。PREV_BUFF を上書きして
      返す場合にはちゃんと PREV_UMIN<0 である事を確認している。layer:region が
      問題になったのは PREV_BUFF を上書きしているのにも拘らず、元の PREV_BUFF
      に起こった変更を拾わなかったのが原因である。

    ? ok: さて、今回の修正では選択範囲が存在する時に menu_filter 着色が残ってし
      まうという話だったが、実際のコマンド実行に於いても menu_filter の着色が残っ
      てしまう様な場合が存在する気がする。と思ったが、実際にコマンドを実行する
      段階まで行けば menu_filter の着色は解除されていた様な気もする。これは選択
      範囲と関係ない様な気がするが、何故問題がそのまま発声していたのであろうか。
      うーん。

      というか今回の場合も何故問題が生じていたのかよく分からない。というのも
      auto_complete による選択範囲は変わっている筈だからである。うーん。DMIN<0
      なのは良い。そして、select[*] と osel[*] が一致している時に限りスキップが
      起こっている筈なのである。それなのに、実際に発声している状況を見ると sel
      <- osel で変更が起こっている筈なのに着色がスキップされてしまっているとい
      う事。どういう事なのだろうか。

      →確認してみた所、何といきなり osel が変化している。うーん。DMIN に変更が
      あってそれでスキップされていたという事だろうか。うーん。分かったそういう
      訳ではない。

      何が起こっているかというと…

      (1) auto_complete で空白文字が入力されて、カーソル位置と region の開始点
        が一文字後ろにずれる。この時点で一旦描画が呼び出される。この時は未だ
        menu_filter.idle が走っていないので menu は表示した儘で menu_filter の
        着色も有効の儘である。そうすると e[cho ][予測内容] の前半の [] を
        menu_filter 着色にして、後半の [] を region 着色した状態になる。
      (2) その後で menu-filter.idle が走って menu を削除する。この時、内部的に
        はecho [予測内容] の様に書き換わるが選択範囲に変更がない為に、
        layer:region が下層の変更を拾わずにその儘になっていた

      という事。今まで時々見られた物もこれで説明が着くのではないか。取り敢えず

    [まとめ] layer:region が、選択範囲が存在して前回と変更がない時に、下層で変
    更があったとしてもそれを反映しない設計になっていたのが原因であった。

  * 2021-05-29 bleopt: wildcard を使った時に obsoleted な物も列挙されている [#D1595]
    複数単語に展開された時にはフィルタする様にしたら良い。

  * blehook: -a を指定しないと直接 hook を指定しても表示されない [#D1594]

    % blehook -a face_name による結果の表示も一緒に遅延されている気が
    % する。というかそもそも blehook に遅延機能があったのだろうか。。
    % そしてその理由は? うーん。見た感じは遅延機能等ない。と思ったが分
    % かった。blehook 自体が faces にアクセスしようとして、それで初期
    % 化が発生している。

  * color: initialize-faces の遅延に関する問題 (motivated by jmederosalvarado) [#D1593]
    https://github.com/akinomyoga/ble.sh/issues/96#issuecomment-813185300

    * vim-airline: theme を blerc で設定しても何故か暫くすると dark の配色が読み
      込まれている気がする。改めて設定し直すと問題は起こらない。theme を変えた瞬
      間の配色が何だか変になる。

      うーん。調べてみると initialize-faces が2回呼び出されている気がする。何故だ
      ろうか。ble/syntax/attr2g 経由である。うーん。分かった。core-syntax.sh が定
      義している関数で ble/syntax/attr2g の初期化を遅延しようとしている。然し、最
      初にプロンプトを表示した時点で既に initialize-faces が実行されるので、その
      後で ble/syntax/attr2g { initialie-faces && ble/syntax/attr2g "$@"; } 等と
      すると二重に初期化される様になるのである。eval-after-load 的な仕組みで登録
      する必要があるのではないか。

    * また、initialize-faces が実行されたら実行した hook はクリアする事にする。

    * この際なので GitHub #96 のコメントで指摘されている遅延についても対処する。

      沢山の setface 設定を仕込んでいると最初のキーストロークの反応が遅いという
      話。これに関しては initialize-faces を idle で実行すれば良い。

      idle の登録順序はどうなっているだろうか。ロードした直後の idle の順序を確
      認する。complet を絶対パスでロードするように変更して、また syntax より後
      にロードする様に変更した。変更後の様子は以下の通り。

      [0]="R\\ble/history:bash/resolve-multiline async"
      [1]="R\\ble/util/import '/home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh'"
      [2]="R\\ble/util/import '/home/murase/.mwg/src/ble.sh/out/lib/core-complete.sh'"
      [3]="R\\ble/util/import '/etc/profile.d/modules.sh'"
      [10000]="R\\ble/util/msleep/calibrate"
      [10001]="R\\ble/textarea#render-defer.idle")

      うーん。syntax よりは前に faces は initialize して良いのではないか。とい
      う事を考えると、実は一番最初に登録してしまっても問題ない。登録した。

  * vim-airline を blerc からロードする様にすると余分な行が表示される [#D1592]

    | 調べると \q{lib/vim-airline} の中で問題が発生している。更に調べると
    | ble/prompt/unit:_ble_lib_vim_airline_mode/update の中の
    | ble/history/get-entry により何かが出力されている。出力内容を調べるとエスケー
    | プシーケンスを出力している。エスケープシーケンスの出処を調べる。
    |
    | | ble-attach
    | |   ble/term/initialize
    | |     ble/term/test-DECSTBM
    | |       ESC7
    | |       ESC[1;2r
    | |       ESC[2;1H
    | |       ESC[1B
    | |       ESC[6n
    | |       ESC[;r
    | |       ESC8
    | |   ble/decode/attach
    | |     ESC[>c
    |
    | 上記の出力内容は単に buffer に残っていただけ。
    | これらは特に何も問題を起こさない。
    | 以下の内容が問題を起こしている。
    |
    | | ESC(BESC[m^MESC[2KESC[1M
    | | ESC(BESC[mESC[30C
    |
    | もっと分かり易く書くと以下の形になる。
    |
    |   SGR0 CR
    |   EL(2) DL(1) ... put-dl.draw
    |   LF SGR0 CUR(30)
    |
    | EL(2) DL(1) の組み合わせは put-dl.draw が使っている物である。put-dl.draw に
    | 仕掛けて FUNCNAME[@] を出力してみると以下の結果になった。
    |
    | | ble/canvas/put-dl.draw
    | | ble/canvas/panel#set-height.draw
    | | ble/canvas/panel/reallocate-height.draw
    | | ble/edit/info/.render-content
    | | ble/edit/info/show
    | | ble/edit/info/immediate-show
    | | ble-edit/history/history-message.hook
    | | blehook/invoke
    | | ble/history:bash/load
    | | ble/history:bash/initialize
    | | ble/history/initialize
    | | ble/history/get-entry
    | | ble/prompt/unit:_ble_lib_vim_airline_mode/update
    | | ble/prompt/unit#update
    | | ble/prompt/backslash:lib/vim-airline
    | | ble/prompt/backslash:q
    | | ble/function#try
    | | ble/prompt/.process-backslash
    | | ble/prompt/process-prompt-string
    | | ble/prompt/.instantiate
    | | ble/prompt/unit:{section}/update
    | | ble/prompt/unit:_ble_prompt_status/update
    | | ble/prompt/unit#update
    | | ble/prompt/update
    | | ble/textarea#render
    | | ble/textarea#redraw
    | | ble-attach
    | | ble/base/attach-from-PROMPT_COMMAND
    | | ble/function#lambda/0
    |
    | つまり、ble-attach から呼び出したプロンプト再描画の中で vim-airline が呼び
    | 出されて、その中での modified の判定の為に get-edited-entry が呼び出されて
    | いるという事。get-edited-entry は内部で ble/edit/info/immediate-show を呼び
    | 出して居て、結果として何らかの不都合が生じて計算がずれる。
    |
    | a reject: 一つの可能性として DRAW_BUFF に出した出力が中途半端になっている事
    |   によって問題が生じているのではないかと思ったが、DRAW_BUFF を覗いた感じだ
    |   と特に何も登録はされていない。なので出力のバッファリングが輻輳していると
    |   いう可能性は考えなくて良い。
    |
    | b reject: 或いは buffer に既に入っている内容が問題になっている? と思ったが
    |   そうでもない。その場で buffer.flush して、get-edited-entry の出力だけ潰し
    |   ても特に問題は生じない。
    |
    | c reject: 或いは端末に繋がっている時だけしか問題のある出力をしない可能性は
    |   あるだろうか。つまり e.log に出力された内容を今は観察しているが、実際には
    |   端末に繋がっている時に限りもっと色々な出力をしている。具体的には非端末の
    |   時にはble/history/initialize は info で何も表示しない可能性。一旦
    |   get-edited-entry の直後で sleep を入れて何か表示されるのか確認してみる事
    |   にする
    |
    |   →特に何も表示されない。恐らく端末に繋がっているかどうかの違いで振る舞い
    |   が変わるという訳ではないと思われる。
    |
    |   →実際に非端末の出力先として 2> >(cat) を使った場合にも問題が再現する。と
    |   いう訳なので観察している出力で確かに問題が発生しているのだという事。
    |
    | d reject: もう一つの可能性は後で遅延して履歴読み込みが完了した時に info を
    |   削除する時に問題が生じているという可能性。
    |
    |   →これは関係ない。実際に get-edited-entry の stderr を潰せば問題は生じな
    |   くなっているし、その imbalance が生じる事によって表示が偶々正しくなってい
    |   るという様には考えがたい。
    |
    | e reject: 或いは get-edited-entry を呼び出した直後に buffer に入っている内
    |   容が後になって問題を起こしている可能性? → 確認したが、get-edited-entry
    |   直後には buffer は何も入っていない。これは関係ない。
    |
    | f もう一つの可能性として全体更新が中途半端になっている事によって座標計算が
    |   ずれているのではないかという事。然し、問題が生じているのは ble-attach か
    |   ら直接 ble/textarea#redraw を呼び出した時であって、これは panel/render で
    |   はないので、textarea と info の描画は独立の筈である。
    |
    | となって来ると、info から呼び出した set-height の実装か、或いは位置計算に問
    | 題が生じているという事になる気がする。出力内容と _ble_canvas_x,y の状態につ
    | いて確認する必要がある。
    |
    | | _ble_lib_vim_airline_mode
    | | declare -- _ble_canvas_x="30"
    | | declare -- _ble_canvas_y="0"
    | | declare -- _ble_canvas_excursion=""
    | | ^[(B^[[m^M^[[2K^[[1M
    | | ^[(B^[[m^[[30Cdeclare -- _ble_canvas_x="30"
    | | declare -- _ble_canvas_y="0"
    | | declare -- _ble_canvas_excursion=""
    |
    | うーん。これを見る限りは canvas 的にはカーソル位置は動かしていないつもりな
    | のである。改めてこのシーケンスがどの様に生成されているか確認する。
    |
    | | _ble_lib_vim_airline_mode
    | | declare -- _ble_canvas_x="30"
    | | declare -- _ble_canvas_y="0"
    | | declare -- _ble_canvas_excursion=""
    | | declare -a _ble_canvas_panel_height=([0]="1" [1]="0" [2]="0")
    | | [delta=-1,opts=]
    | | ^[(B^[[m^M^[[2K^[[1M
    | | ^[(B^[[m^[[30C[delta=0,opts=]
    | | declare -- _ble_canvas_x="30"
    | | declare -- _ble_canvas_y="0"
    | | declare -- _ble_canvas_excursion=""
    | | declare -a _ble_canvas_panel_height=([0]="0" [1]="0" [2]="0")
    |
    | うーん。どうやら panel#0 の高さが潰れてしまっている様子。然し、高さが潰れて
    | しまっているからと言ってカーソルの位置が変わるのは変である。うーん。
    | set-height までは別に座標計算が変な事にはなっていない様だ。set-height を抜
    | けた後で座標位置を復元している箇所があって、其処で計算がずれているという事
    | の気がする。
    |
    | うーん。分かった。以下の様な状態になっている。x=0 y=0 content=$'\n' になっ
    | ている。content に改行が入っているのだから、本来は y=1 でなければならない筈
    | である。何故この様な内容が生成されるのか確認する必要がある。
    |
    | declare -a _ble_edit_info=([0]="0" [1]="0" [2]=$'\n')
    |
    | 更に調べると ble/edit/info/.construct-content text 'loading history...' の
    | 構築結果がその様になっている。
    |
    | % 更に辿ると ble/canvas/trace-text がまるで動かなくなっている。何故。。。
    | %
    | %   x=0 y=0; ble/canvas/trace-text 'ABC'; echo "($x,$y)[$ret]"
    | %
    | % とすると x=0 y=0 ret=$'\n\n' 二重改行になってしまっている。これは大事。
    | % いつからこの様な事態になっていたのだろう。今まで気づかなかったのも不思
    | % 議である。というより、殆どの機能で着色を使っているので trace-text は余
    | % り使われてこなかったのである。更に遡って調べてみると v0.3.0 の時点で既
    | % に trace-text は動作していなかった様だ。0.2 系列では
    | % ble-edit/info/.construct-text という関数で現在の実装とは全く異なる物凄
    | % く単純な実装だった。この時は勿論問題はなかった。
    | %
    | % まとめると ble/canvas/trace-text は可也昔から壊れていた。v0.3.0 の時点
    | % で駄目。一方で v0.2 の段階ではその前身である
    | % ble-edit/info/.construct-text だったが、これはとても単純な関数でまた問
    | % 題も存在しなかった…と思ったが微妙に関数の仕様を勘違いしていた。
    | % trace-text は領域の大きさを外部から与える必要があったのである。

    結局何が起こっていたのかというと、ble/edit/info/.construct-content に於いて、
    ble/edit/info/.initialize-size が lines=0 を返して、それに対して
    ble/canvas/trace-text が変な振る舞いをしていたという事。

    問題が3つある。

    x fixed: ble/canvas/trace-text は lines が限界に達しているのにも関わらず改
      行を末尾に付加してしまう。これは個別に対応した。

    x ok: 改行を付加したのにも関わらず y を増やしていない。これは trace-text を
      ほぼ再実装した結果発生しなくなった。何故元の実装でこれが発生していたのか
      は分からない。そもそも改行 \n ですら trace-text では ^J と表示される。

      →これは分かった。ble/canvas/trace-text/.put-nl-if-eol が put-simple の中
      と終了時の2回呼び出されている。cols=0 の時には一回実行したとしてもまだ行
      末にいると判定されるので二回実行されるのである。

    x fixed: ble/canvas/trace-text を初期化する前に、何故か
      ble/edit/info/.initialize-size が lines=0 を結果として与えている。

      中では ble/canvas/panel/layout/.get-available-height を呼び出している。

      % 中で戻り値を確認すると ret=9730ret という謎の値が生成されている。と思っ
      % たがこれは debug コードのミスだった。

      改めて調べるとこの時点で 0 が生成されている。

      declare -a mins=([0]="1" [1]="0" [2]="0" [3]="0")
      declare -a maxs=([0]="1" [1]="0" [2]="1" [3]="0")
      declare -a heights=([0]="0" [1]="0" [2]="0" [3]="0")
      declare -- index="2"
      declare -- ret="0"

      うーん。この時点で maxs に LINES が設定されて欲しいが 1 になってしまって
      いる。うーん。原因が分かった。プロンプトの処理を行っている最中は LINES
      COLUMNS を通して描画範囲の大きさを指定しているが、これだと本来のレイアウ
      ト処理に影響を与えてしまう。

      取り敢えずは ble/canvas/trace は引き続き LINES COLUMNS を参照する事にして
      おいて、その外側の instantiate 等については LINES/COLUMNS は別変数経由で
      指定する事にする。

      書き換えた。これで現在 LINES= 及び COLUMNS= を設定している箇所は全て
      ble/canvas/trace の呼び出しか、または ble/textmap#update の呼び出しに限ら
      れる事となった。

    x fixed: 何故 panel#0 の高さが潰れてしまうのか。本来は此処で高さを変更する
      必要はないのではないか。というより高さ 1 の儘であるべきなのではないのか。
      特に ble/prompt/update の段階では。

      これは LINES=1 を設定していた為に visible-bell 専用の行が引き算されて 0
      になってしまっているという事だろう。LINES=1 の時には visible-bell も表示
      しない様に修正する必要がある。もしくは visible-bell の表示方法を変更して、
      即座に行送りにする。と思ったが、visible-bell を表示した時点で現在の表示内
      容を保持する事ができないので、やはり LINES=1 の時には visible-bell は表示
      しない様に変更するのが適切だろう。

    * done: この問題とは独立に get-edited-entry に於いて最新の値を参照している
      時には履歴をロードせずに済ませる様に実装する様にした方が良い。実装した。
      取り敢えず vim-airline の modified はこれでもちゃんと動いている。

    * done: trace-text のテストを拡充

    x 2021-06-08 airline: ロード時に keymap_vi_mode_show=1 に再設定すると表示が
      ずれてモード行の位置にプロンプトの残像が残ってしまう

      →これは #D1592 を修正したら再現しなくなった。

    x 2021-06-08 airline: status 行を表示している時の空コマンド行による改行がス
      ムーズではない。

      →これも #D1592 の修正で再現しなくなった。LINES/COLUMNS によりレイアウト
      再構成が毎回走っていたという事なのだろうか。何れにしても空コマンド行によ
      る改行で status line を出した儘にしているかどうかだけ、実装について確認す
      るのが良い。

      →確認した。textarea (panel#0) の再描画しかしていないので statusline 等に
      ついてはその儘の筈。但しプロンプトの再計算が入るので結局再描画はされる様
      な気もしないでもない。うまく cache が働いていれば dirty にもならずに再描
      画もなくそのまま前の表示が使われるのではないかという気がする。

2021-06-07

  * prompt: [最適化] 依存関係追跡の整理・最適化 [#D1591]

    x .instantiate の section update で git 情報や現在の vim モードに依存してい
      るが、一方で自動的な依存解決による section update が git 情報や vim モー
      ドを初期化する前に呼び出されている。

    これに関しては本来は git の情報は ble/prompt#update _alpha '' prompt-data
    等として初期化する必要があるのではないかという気がする。というか
    ble/prompt#update を流用する必要があるのかは謎である。実はデータ専用の関数
    を用意しても良いのではないだろうか。そしてデータは好きな様に利用する。

    ? そもそも配列を共有している理由はあるのだろうか。。。

      version hashref hash に関しては依存関係の管理に関係している。
      これは一つ上の枠組みで管理される物なので切り離しても良いのではないか。
      一方で (instantiate 7つ組) 及び (tailor データ) はプロンプト情報固有の物である。

      但し、version 更新の条件として (instantiate 7つ組) または (tailor データ)
      による更新が実際にあったかどうかを使っている。然し、version は一般に外から
      その内容が変更されたかどうかを判定する為に用いているから、やはり version
      hashref hash の組で管理するべきである。

      取り敢えず veresion hashref hash の順序を変更する事にする。

    うーん。何だか分からなくなってきた。そもそも現在の構造に欠陥がある様な気が
    する。hash を見て更新する必要があるかどうかを観察する事になっているが、依存
    関係がある時には hash で参照している先を初めに更新しておかなければ反映され
    ない。なので、依存先を先に更新しようと考える訳だが更新に使用する引数が分か
    らないという問題が生じる。

    a 依存先の hashref を展開して長大な hash で更新確認をする案

      % これは version で参照しているから行けないのであって、依存先の hash 本体を
      % 依存元が取り込んでしまえば問題ないのでは? とも思われるがそれは変数の時だ
      % けである。history index や git の情報など何らかの処理によって確認を取って
      % 値を計算してから出ないと分からない物に関してはやはり変数で参照していても
      % 駄目である。

      依存の更新がグローバル変数の変化を通してのみ発生する場合にはこれで良いが、
      実際には git 等の様に現在の値をその都度更新する必要がある物もある。

      history index/count に関しても既存のコードを大きく変えたくないので、同様
      の仕組みを使って実装したいと考えている。と思ったが、history に関しては変
      数経由にした方が良い様な気もする。描画(カーソル移動も含めて)の回数と履歴
      移動の回数を数えたら断然描画の回数の方が多いだろうから。

    b そもそも各 unit に外から引数を与えられる様になっているのが変である。外か
      らプロンプト文字列を与えられなくてもそれ単体として更新をできる様にする。
      これはそんなに難しくない筈である。というより、今まで外から引数を指定でき
      る形で更新していた事自体が変なのである。

      この場合に真面目に考えなければならないのは特定の条件で on/off される様な
      プロンプトの存在である。うーん。特定の条件で表示非表示を切り替える様な物
      の場合には、消去のコードも自分で生成するか或いは消去は外に任せる事にして、
      自身は表示している時の状態を保持し続けるという事か。うーん。これについて
      は外からの支持で動作するというので良い気がする。つまり、今までの振る舞い
      で良い。特に rps1, xterm_title, etc. に関しては他から参照される事もないの
      で、外から呼び出された時にだけ更新すれば良い。更新する必要がないのに古い
      依存関係経由で呼び出されるという様な事はないので大丈夫。

      1 先ず更新は全て unit#update 経由で実行するという事。現在は class 等とし
        て {section}/update を定義しているがこれは廃止する。個別にちゃんと
        /update で実装するという事。unit#update には引数は渡さない

        prompt-expand-{gbox,bbox} は廃止する。必要ならば呼び出し元で抽出を行う。
        と思ったが、helper 関数として存在しても良いのではという気がしないでもな
        い。何れにしてもこれは後回し。先ずは大きな構造の方を整理する事にする。

    * done: ble/prompt/section#update 廃止

    * done: vim-airline-mode は unit として実装する。

    * done: ble/prompt/unit:UNIT/section::tailor 削除

      これは明らかに実装を複雑化させている。そして tailor だけを invalidate す
      るというのも元々は効率の為だったが、既に様々な無駄がある中で余り意味のあ
      る最適化である様にも思われない。従って tailor は削除する。

    * done: history index/count は変数にする

      取り敢えず _ble_history_INDEX 及び _ble_history_COUNT

      ? _ble_history_prefix が謎である。設定している箇所は見つかるが解除してい
        る所が見つからない。local で宣言している訳でもないし textarea vars に設
        定されている訳でもないから復元される事もない様な気がする。

        例えば vi.sh で _ble_history_prefix=_ble_keymap_vi_filter_ を設定してい
        る。これは ble/keymap:vi/async-commandline-mode から
        ble/textarea#save-state _ble_keymap_vi_cmap を呼び出した後に実行されて
        いる。と思ったらこれについては _ble_keymap_vi_cmap_history_prefix に手
        動で保管して、その後で手動で復元している。vi.sh の中にある物は全てこれ
        だった。

        ./src/edit.sh:7857:  _ble_history_prefix=_ble_edit_read_
        これに関しては subshell で実行しているので戻さなくて大丈夫。

        他に設定している箇所はない。

      他の ble/history/get-{count,index} に関しては明らかに history を
      initialize しなければならない所以外は現状のままで関数経由で取得する事にし
      た。直後に history を initialize する場合にはその場で
      ble/history/initialize を呼び出して直接 _ble_history_{COUNT,INDEX} を参照
      する様に書き換えた。

    x 2021-06-09 textmap が更新される前に表示しようとすると col がずれてしまう。
      これはその場で更新してしまっても問題ないのではないか。特に textmap の更新
      が必要になるという事は dirty という事なので。

      →うーん。此処で気づいてしまったが。textmap で使用する文字幅を決定する為
      には rps1 の幅が必要で、一方で rps1 の中に配置情報を表示しようとするとそ
      の前に textmap を計算しなければならない。取り敢えず rps1 の中に含まれる情
      報は 前回の rps1 の幅に基づく textmap の情報と解釈する事にする。

      後、もう一つの問題は ble/widget/.update-textmap の内部で呼び出している
      textmap が rps1 の幅を考慮できていないという事。
      ble/widget/.update-textmap の実装をちゃんと rps1 の幅を考慮に入れる物に書
      き換えて、更に backslash:position 等の中から ble/widget/.update-textmap
      を呼び出す様に修正した。

  * prompt: [最適化] 依存関係の追跡と部分更新の対応 [#D1590]

    ble/prompot/clear については各プロンプト毎に設定できる様にするべき。
    再描画部分についても dirty かどうかを保持して更新するかしないかを判定するべ
    きの気がする。

    各プロンプト毎に何に依存しているかのリストと依存している物に対する hash を
    自動で生成する様な仕組みが欲しい気がする。仕様としては各プロンプト内部で情
    報を参照した時に ble/prompt/add-dependency xxxx を呼び出す。プロンプトの実
    体化を司る側ではこれをリストにして管理する。hash を生成する時には、
    ble/prompt/data:xxxx/hash を通して関数を呼び出し hash+=:xxxx=$hash を実行す
    る。然しこれだと hash のインスタンス化自体に split, for, += が必要になって
    重そうである。それよりは、直接 eval できる形にした方が良いのかもしれない。

    % つまり
    %
    % _ble_prompt_version_ref+='$LINENO'
    % eval "_ble_prompt_version=$_ble_prompt_version_ref"
    %
    % という具合にする。invalidate する時には各変数について ((LINENO++)) する等し
    % て処理を行う。各プロンプト要素を個別に invalidate できる様に各プロンプト固
    % 有の変数も用意する。コマンド実行後には全て更新する様にしたいので共通の更新
    % 条件としてそれも含めて置くことにする。
    %
    % 実際には ble/prompt/add-dependency は重複して呼び出す可能性もあるので [[
    % :$version_ref: == *:'$LINENO':* ]] 等を用いて重複を排除する。

    vim-airline の様に複数のサブプロンプトを組み合わせる形の場合には、サブプロ
    ンプトの version_ref を集めて判断する必要がある気がする。然し、そうすると長
    大な version 文字列になってしまうがそれで良いのだろうか。或いは無条件にサブ
    プロンプトを巡回して、その後で全体更新が必要かどうかについて判断するという
    のでも良い。その場合にはサブプロンプトの version 番号だけを参照する事にすれ
    ば良い。プロンプトのリストに登録する順序に注意する必要がある。

    _psx_hashdef  ... eval をすれば _psx_hash を計算できるパラメータ展開のコロ
                      ン区切りのリスト。
    _psx_hash     ... _psx_hash を eval して得られた文字列。更新を要求する場合
                      (invalidate) にはこの変数を空にすれば良い。
    _psx_version  ... プロンプト描画内容が変更された時に増加する番号。
    _psx_gdirty   ... プロンプト描画内容が更新された時に 1 に設定。

    同様に共通 hash を保持する。これが変化した時は全てのプロンプトは強制的に更
    新する様に仕組まれる。つまり、全てのプロンプトはこの共通 "prompt" に依存性
    を持つとする。この共通 "prompt" には実体が存在しない。PROMPT_COMMAND 及び
    PRECMD はこの仮想プロンプトに対して更新する。

    _prompt_hashdef
    _prompt_hash
    _prompt_version

    for p in prompt-list; do
      local _hash=${p}_hash _hashdef=${p}_hashdef
      eval "local new_hash=${!_hashdef}"
      [[ ${!_hash} == "$new_hash" ]] && continue

      hashdef='$_prompt_version'

      update....

      内容に変更があった && ((${p}_version++))
      eval "$_hash=$hashdef $_hashdef=\$hashdef"
    done

    hashdef の定義は更新時に毎回行う。最初は依存対象として $_prompt_version か
    ら始める。

    function ble/prompt/reference-prompt { hashdef+=:\$${1}_version; }
    function ble/prompt/reference-variable { hashdef+=:\$$1; }

    ? 全てのプロンプトを巡回しているとすると使われていないのに更新される物が出
      てくるのではないか。そう思うと使う物から順番に要求して、深さ優先順序で更
      新していく様にするべきなのではないか。その為には依存先のプロンプトの一覧
      を個別に保持する必要がある様な気もする。

      hashdef=$_prompt_version:$ps1_version,$ps2_version,...:$var1:$var2:$var3

      の様な形にして : で区切った二番目の要素を , で split して其処から依存先を
      抽出する様にするというのはどうだろうか。

    ? 現在の履歴項目内部の位置など一部の物は事前に関数の実行等が必要になる気が
      する。その場合にはどの様に対応するのか。$(ble/history/get-index;echo
      $index) を埋め込むのは遅そうである。では評価の前に関数を実行するのかと問
      われるとそれもよく分からない。そもそも更新の必要性はプロンプト毎に固定と
      いう訳ではなくて、現在表示している内容に依存している。

      或いは現在の履歴項目内の位置を常に変数で参照できる様にするべきなのだろう
      か。というか何故その様になっていないのだったか。

      うーん。history コマンドの使用によって不意に履歴がロードされたり、或いは、
      初期化によって history がロードされたりという事を想定しての事の気がする。
      実の所、この手のチェックは prologue か何処かで行ってしまえば良いのだとい
      う気がする。

      うーん。というか現在の履歴項目の位置というのも、read 等によって別の履歴に
      切り替わっている時にそれを反映するべきかというのも議論の余地がある。うー
      ん。_ble_history_prefix を設定する時にその辺りの更新処理も実行する必要が
      ある気がする。

      後、共通の変数名をどうするのかというのも困る。_ble_history_ind 及び
      _ble_history_count は既にメインのコマンド履歴の為に使われてい
      る。_ble_history_count を例えば _ble_history_cnt に解明して、その上で新し
      く_ble_history_{count,index} を現在の index/count の変数とする事にすると、
      今度は cnt,ind との区別が分かりにくい。やはり名前空間を分けたい気がする。
      然し一方でコマンド履歴は特別なので _ble_history, _ble_history_edit に格納
      されているというのも妥当である様に思われる。

      - reject: _ble_hist_index, _ble_hist_count というのも変である。
      - reject: _ble_history_current_index, _ble_history_current_count
      - reject: _ble_history_cur_index, _ble_history_cur_count
      - reject: _ble_history_prefix_index, _ble_history_prefix_count
      - reject: _ble_history_i, _ble_history_c
      - reject: _ble_history_cindex, _ble_history_ccount (common)
      - reject: _ble_history_gindex, _ble_history_gcount (global)
      - reject: _ble_history_pindex, _ble_history_pcount (prefix)
      - reject: _ble_history__index, _ble_history__count
      - reject: _ble_history_Index, _ble_history_Count
      - _ble_history_lineno, _ble_history_lines
        これだと繋がりが分かりにくい。
      - BLE_HISTORY_INDEX, BLE_HISTORY_COUNT
        これは一つの手な気がするがこれをユーザーへの公開変数とする意義はあるのか。
        慎重になった方が良い気がする。
      - _ble_history_INDEX, _ble_history_COUNT
        後でまた仕様変更できるのだという事を考えるとこれぐらいで良いのかもしれない。

    ? 設定を新しく変更して別のプロンプトに依存する様になったらどうするのか。うー
      ん。そう考えるとプロンプト更新は順番に呼び出すというよりは、必要になった
      時に不定期に何度でも更新すれば良い気がする。循環参照にならない様に注意さ
      えしておけば特に問題はないだろうという気がする。

    [実装]

    * done: プロンプト周りの整理が必要になる

      先ず ble/prompt/update はプロンプト全般の情報更新に努め、PS1 の結果は呼び
      出し元で必要になった時に読み出す様に変更する。

      ble/prompt/update の結果の内 x y lc lg は後で使用されている。一方で、g 及
      び ret に関しては使われていない気がする。特に ret は直後に別の物で上書き
      されているので関係ない。

      * ok: 変数 g を削除しても問題ないだろうか。

        g に関しては本当の所はどうだろうか。昔の実装では、trace を実行する時に
        入力していた様な気もするが…うーん。やはり違うかもしれない。結局 trace
        は使っていないし専ら textmap, slice, etc. で使っているのみである。もし
        使う事があるとすれば、一番最初の文字の着色だけである。然し、着色に関し
        てはに layer に任されている。layer では最初の g を認識して着色を省略す
        る等の事はしていただろうか。と考えるとしていない気がする。そもそも
        prompt の終端で g を sgr0 以外にしておく必要も分からない。

        実際に出力する場所を確認してみると必ず textarea#slice-text-buffer を使
        用している。そしてこの関数では必ず端点の g を読み取ってそれに対して sgr
        を生成して付加している。なので、prompt 終端の g が表示に影響を与えると
        は考えにくい。それとも highlight/layer の実装で g の値を参照する可能性
        はあるだろうか。うーん。外の g がどういう値になっているかは定義されてい
        ない筈なので参照していない筈。

      * reject: PS0 の最後の g をコマンド列の既定着色として用いる可能性:

        と思ったが、ユーザーがコマンドに色をつけようとしてわざと g として変な値
        を残しておくという事も考えられるだろうか。まあ、それに関しては余り考え
        ない事にする。少なくとも現在の実装では考慮に入れていないし、考慮に入れ
        るとしても別項目で考察するべき内容である。

        それに既定着色を指定できる様にするとなると SGR を生成する段階で様々の修
        正が必要になってくる。変更として大きくなってしまうし有用性がよく分から
        ないのでこのままにする。そもそも色を設定したいのであれば、ble-face を用
        いて設定するべきであって、PS1 経由で着色をするというのは避けてもらうべ
        きである。

      lc lg の計算は現在 ble/textarea#update-text-buffer 内部で実行しているがこ
      れは別の関数にする方が自然なのではないか→別の関数にした。

      ble/prompt/.load は最早誰も使っていないので削除しても良いのでは→削除した。
      引数の詳しい説明については ble/prompt/.instantiate に移動した。

      これ以上の整理に関しては枠組みが完成してからにするべきという気がする。

    * 試験的に新しい枠組みを作成する

      プロンプトを指定する番号はどの様にしたら良いだろうか。というか番号で指定
      できる必要はあるだろうか。考えてみればどうせ色々の変数は指定した prefix
      の下で変数を複数作って管理するのだった。という事を考えると実は prefix で
      指定すれば良いだけなのではないだろうか。取り敢えず prefix で指定する様に
      する。

      一番最初は依存関係の解決等は考えずにただ単純に更新するだけの関数にしてみる。

      * done: control-string 系全てに _data を付加する

      * ok: dirty が個別に設定されていなくても全て再描画する必要が生じる場合も
        ある。というか新しいプロンプトを表示する時は常にそう。invalidate の際に
        全てに dirty を設定する必要がある?

        % 普通に hashref_base (_ble_prompt_version) を確認するだけだと、プロン
        % プトの再計算までは行われるが内容が以前と一致した場合に再描画迄は行か
        % ない可能性がある。今迄は内容を再計算した時には必ず dirty が代入されて
        % プロンプトまで再描画していたが、今回は内容を再計算して更に変化があっ
        % た時にだけ dirty が設定されているので、再描画が実施されるとは限らない。

        と思って確認したが ble/textarea#invalidate が呼び出された時には全体描画
        になって、その時には改めて全て描画される様である。dirty が参照されるの
        は一部だけ更新されている時だけである。なのでこれについては気にしなくて
        良い。

      考えるに dirty は参照される時には参照されるが、参照されない時には参照され
      ない。何れにしても全て再描画される場合には dirty は見ずに常に再描画する仕
      組みになっているので問題ない。

      * done: 変数を参照した時にそれを登録する為の関数を定義する。

        関数名は何が良いだろうか。

        - reject: ble/prompt/add-variable var
        - reject: ble/prompt/add-variable-reference var
        - reject: ble/prompt/add-varref var
        - reject: ble/prompt/reference-variable var
        - reject: ble/prompt/listen var
        - reject: ble/prompt/listen-variable var
        - reject: ble/prompt/hook-variable var
        - reject: ble/prompt/depend-on var
        - reject: ble/prompt/add-dependencies var...
        - reject: ble/prompt/cite-variable var
        - reject: ble/prompt/cite-var var
        - ble/prompt/ref var
        - ble/prompt/onchange var
        - ble/prompt/detect var
        - ble/prompt/cite var
        - ble/prompt/cite-vars var...
        - ble/prompt/reference var

        a 将来的に変数以外の物を参照する可能性があるかどうかという事で var を関
          数名に入れるかいれないかが決まる気がする。考えて見るに eval して fork
          を伴わない物と言えば変数展開以外には算術式展開しか考えられない。とい
          う事を考えるとやはり reference で良いのではないだろうか。

        b 或いは、"変数" である事を示唆する様な動詞が存在すればそれを使うのが良
          い。例えば reference と言えば変数である。

        c というか良く考えたら追加する式を直接指定すれば良いだけの話の気がして
          きた。つまり、

        - ble/prompt/reference '$var'
        - ble/prompt/hash '$var'
        - ble/prompt/add-hash '$var'
        - ble/prompt/add-hashref '$var'

        うーん。add-hash が一番無難な気がする。結局内部で何をするかがこの関数名
        だけで分かるので。もっと分かりやすくするならば、add-update-hash 等にな
        るだろうか。然し短いほうが良いので add-hash にする。

      * done: うーん。vim-airline で子プロンプトを参照する様にしたが、よく考え
        ると、チェックを行うのは子プロンプトを更新する前なので、子プロンプトの
        更新による変化を検出できない。子プロンプトの更新を実施してからチェック
        を行う必要がある。

        然しここで問題になるのは、子プロンプトに渡すオプションやプロンプト文字
        列は事前には分からないという事。子プロンプトが存在する場合には先に子プ
        ロンプトを更新してから更新判定を実行する必要がある。うーん。或いは。や
        はりプロンプト毎に更新を行う関数を事前に登録しておくべきなのだろうか。

        プロンプト section_a を更新する為の関数を登録することにした。

      * done: ble/prompt/clear は個別に invalidate または自動検出にする

        というか実は更新の必要すらないかもしれない。今となっては必ず全ての
        prompt について hashref のインスタンス化を試す様になっている。ここに ps
        も含めるべきなのではないか。

        と思ったが、現在の実装だと ble/textarea#redraw は何も変更がないと即座に
        抜けてしまう様になっている。少なくともプロンプトに関しては更新を行わな
        いと駄目なのではないか。

        * ble/prompt/clear の使用箇所を改めて確認する

          ./ext/.../fzf-marks.plugin.bash:317:    [[ $PWD != "$pwd" ]] && ble/prompt/clear
            これは \w または \W を参照している時に呼び出す事にする。
            他に埋め込まれている変数の場合の可能性もあるが気にしない。

          ./keymap/vi.sh:468:    ble/prompt/clear

            これは show-mode-in-prompt の時に呼び出す物。これは変数に変える事が
            できるのでは。

          ./src/edit.sh:169:      ble/prompt/clear

            bleopt_prompt_status_align の変更に伴って更新を行う。うーん。これに
            関しては実は prompt#update の hash に値を含めても意味がない。最終的
            に生成される esc が同じである以上は dirty と判定されないからである。
            特に left と right の切り替えに対してちゃんと処理できない。という事
            を考えると hash をクリアするしかない気がする。

            結局、ble/prompt#update の内部から ble/prompt:"$prefix"/tailor とい
            う関数を呼び出させてその中で加工処理を行う事にした。tailor だけの
            invalidate として、ble/prompt#clear _ble_prompt_status tail を呼び
            出させる事にした。

          ./src/edit.sh:1275:    ble/prompt/clear

            これは ble/prompt/notify-readline-mode-change である。更にこの関数
            の呼び出し元も調べる必要がある?

          ./src/edit.sh:7568:  ble/prompt/notify-readline-mode-change

            これは ble/widget/safe/__attach__ から

          ./keymap/vi.sh:7649:  ble/prompt/notify-readline-mode-change

            これは ble/widget/vi_imap/__attach__ から

          というか本当にちゃんと更新されるのだろうか。と思った
          が、./keymap/vi.sh:468: ble/prompt/clear は実の所
          ble/prompt/notify-readline-mode-change に変えるべきなのでは? と思った
          が、vi.sh:468 は show-mode-in-prompt だけでなくプロンプトの表示を切り
          替えるのに使う物の気がする。うーん。

      * done: ble/prompt/notify-readline-mode-change に関しては自然に変数経由で
        更新を検知できる様にする。関数自体を削除した。

    x fixed: 何か入力した場合に何も表示されなくなってしまっているこれは何だろう
      か。恐らくこれは単に更新した時に expand gbox,bbox が解釈されていないのが
      原因だろう。

      修正した。問題は発生しなくなった。

    x fixed: 2021-06-09 history: isearch 検索を中止した時に履歴の先頭に移動する
      様になってしまっている。検索を開始する前の初期化に関係するのだろうか。と
      思ったがそうでもない様だ。履歴がロードされた後でも同様に問題が再現する。

      これは最近発生する様になった問題である。明らかに prompt の改良に伴っ
      て_ble_history_INDEX の記録関係に失敗する様になっている。うーん。
      get-index ではちゃんと大きな値を取得する事ができている。逆に復元する時の
      様子を見てみると…。

      _ble_edit_isearch_arr=([0]="29801:-:0:0:" [1]="29769:-:22:23:f" [2]="29305:-:6:8:fd" [3]="29305:-:6:9:fds")
      step=([0]="29801"

      うーん。ちゃんと正しい値を読み出す事ができている気がする。という事は現在
      の履歴位置が間違っているという事になるのだろうか。うーん。何と、
      history/goto の直後に _ble_history_INDEX は空欄になってしまっている。どう
      いう事だろうか。

      これは分かった。ble/history/set-index の実装で存在しない変数 (削除した変
      数) を参照していた。修正した。

  * 2021-05-24 airline: 説明書を書く。theme の枠組みを整える [#D1589]
    https://github.com/akinomyoga/ble.sh/issues/114 (2)

    * done: themes の枠組みを整えたい気がする。現状だとユーザーがそれぞれ対応し
      なければならない。面倒である。うーん。取り敢えず contrib に適当に加えてみ
      るというのも良い気がする。

    * done: _modified には対応していない。

      履歴項目については現在の内容とずれている時に modified にできる。最新項目
      については何か文字列があれば modified にできる→これは対応した。

    * done: themes は自動的に変換する様にできたら良いが調べてみると面倒な気がする。

      自動変換は vim スクリプトを書いて行った。取り敢えず themes は現状で良い気
      がする。mode_map も抜き出そうと思ったが実は atomic.vim しか設定している物
      はなかった。

      contrib に一括で追加しようと思ったが止めて置く事にした。もっと普通のファ
      イルが増えてからにするのが良い気がする。或いは要求したら自動的に何処から
      かダウンロードするというのも手なのかもしれない。

    * reject: テーマ用の bleopt を用意する

      bleopt vim_airline_theme=xxxx

      を設定したら自動で ble-import contrib/airline/xxxx を読み込む様にしたい。
      或いはよく考えたら直接 ble-import contrib/airline/xxxx と書けば良いだけな
      のではないか。

    * 説明に関しては theme を用意してそれを見てもらえれば十分の気がする。但し、
      辞書に関しては theme は bash-4.1 以下でも動く様に gdict を使わなければな
      らずややこしい。

      何れにしても huresche に対する返答で説明するので、その内容を後で Wiki に
      転記すれば良い。

    * done: というか、考えてみたら ble-import する時に毎回 contrib まで指定する
      必要があるのは変な気がする。source path を指定したら其処から自由に source
      してもらうべきなのではないのか。

      ble-import vim-airline
      ble-import core-syntax
      ble-import keymap-vi
      ble-import prompt-git
      ble-import fzf-bingings
      ble-import fzf-completion
      ble-import airline/landscape

      別にこれで良い気がする。寧ろこちらの方が良い。

      local user=${XDG_DATA_HOME:-$HOME/.local/share/blesh}
      BLE_IMPORT_PATH=$user:$user/lib:$_ble_base:$_ble_base/contrib:$_ble_base/lib

    x emacs mode にいる時に vim-airline を呼び出すと真っ黒になって何も表示され
      ない。と思ったらこれは inactive face が使われていて、この inactive の設定
      が物凄く見にくいという事だった。微妙に色が見える。じれが dark.vim の設定
      という事なのでそのままにする事にする。

    x 2021-06-10 ble-import の search path として ~/.local/share/blesh を追加し
      たが、これだと異なる version の設定ファイルが混在する原因である。そうする
      と不整合を生んで変な事になる。特に keymap/vi や keymap/emacs は致命的な問
      題を引き起こし得る。という事を考えると、 ~/local/share/blesh は直接は追加
      せずに ~/.local/share/blesh/local 等から読み取る様にするべきである。

2021-06-05

  * locale によっては正規表現の [a-z] でも駄目 (reported by huresche) [#D1588]

    a 一つの方法は全ての文字を [abcdefghijjklmnopqrstuvwxyz] と言った具合にして
      並べるという事。これは冗長である。0-9 に関しては C 言語の要求で連続に並ん
      でいる事が保証されているので書き出す必要はない。

    b もう一つの方法は必要な箇所で LC_COLLATE=C を設定するという事。然し、必要
      になる箇所が多岐に渡る。

    c 或いは、もう ble.sh の処理を全て LC_COLLATE で囲んでしまうというのも手な
      のかもしれない。と思ったが、LC_COLLATE を解除する場所でエラーメッセージが
      出るのを抑制しなければならない。とは言え、それはそんなに難しくない。問題
      は何処で LC_COLLATE で囲めば良いのかという事。ユーザーコマンドを実行する
      前後で切り替えれば良いのだろうか。或いは、PROMPT_COMMAND や hook を呼び出
      す時にも配慮しなければならないのだろうか。

    * 取り敢えず必要な箇所がどれだけあるかについて確認する。

      $ grc -i 'a-fa-f|a-za-z' --exclude=ext

      で検索すると流石に沢山ある。さて、もし LC_COLLATE=C を設定するのあれば実
      は [:alpha:] や [:alnum:], [:xdigit:] も使えるのではないだろうか。

      然し、何れにしても全ての箇所について個別に対応するのは難しい気がする。

    * reject: 正規表現を使っている各箇所で LC_COLLATE=C を設定する方針

      少し変更してみたがどうにも限界がある様な気がする。この方針は諦める事にす
      る。修正は memo/D1588.stub-LC_COLLATE-1.patch に残す。

    * reject: bind/.{head,tail} 内部で LC_COLLATE を設定する方針

      locale の設定をする時にはユーザーのロケールが壊れている場合に備えて、
      stderr を抑制している。然し、無闇に全体を囲んでしまうとエラーメッセージが
      全て隠蔽されてしまう。局所的に stderr を抑える事はできないだろうか。試し
      に実験してみると以下の様にすれば問題ない様だ。bash-3.0..dev まで全て確認
      した。

      $ bash -c '
        { LC_COLLATE=alpha; } 2>/dev/null
        unlocal() { unset -v "$1"; }
        fun() { local LC_COLLATE=fsa 2>/dev/null; unlocal LC_COLLATE 2>/dev/null; }
        fun'

      この方針でも全てをカバーしきれる訳でもないので微妙である。

    うーん。LC_COLLATE=C にする事にするか。取り敢えず内部環境では LC_COLLATE=C
    を強制する事にする。LC_ALL の状態も調整する。

    * LC_ALL 待避の取り扱いについて

      と思ったが現在の実装では LC_ALL も含めて文字コードの振る舞いを決定してい
      る。待避した _ble_bash_LC_ALL を使って振る舞いを変更するべきだろうか。或
      いは、現在の LC_ALL を使って振る舞いを決定するべきだろうか。うーん。

      ここで問題になるのは、LC_ALL を空にしてしまうと LC_CTYPE 等他の設定に影響
      を及ぼすという事である。現在、local LC_ALL= LC_COLLATE=C という形で様々な
      箇所で待避を行っているが、これだって LC_CTYPE カテゴリの値に影響を与えて
      しまう。

      a LC_ALL= を設定すると共にその他のカテゴリについても全て LC_ALL を適用す
        る。例えば ble/util/locale/project 的な関数を用意して、LC_ALL に有限の
        値が設定されている時にはそれを各 LC_* 変数に適用する。然し毎回それを実
        行するのは遅くなる原因である。特に変数の数だけ locale の設定が行われる
        と考えるとこれは避けたい。

      b そもそも LC_ALL は ble.sh の内部では無視するという可能性。LC_ALL は何ら
        かのユーティリティーの振る舞いを強制する為に使う物であって、対話環境で
        の locale を無理矢理に変更する為に用いる物ではない。寧ろ、そういうのは
        LANG を通して変更するべきである。

      c LC_ALL が振る舞いに影響を与えたとしても関知しない。これは一つの手である。
        LC_ALL を設定している時点で変な振る舞いをしたとしても文句は言えないとい
        う立場。然し、そうだとしても例えば Bash は LC_ALL を変更したからと言っ
        て変数名の規則が変わる訳でもないし、一貫しない動作になるのは避けたい気
        がする。

      d 逆に LC_ALL の効果が ble.sh 内部で中途半端に消えたりしても文句は言えな
        いという立場。これは現在の振る舞いに近いと言える。

      f 或いは射影を adjust の段階で実行するというのも手である。うーん。その方
        が現実的な気がして来た。

        LC_COLLTE=C に固定してしまっても問題ないだろうか。ユーザーの側で何か気
        になる事が発生する可能性はあるだろうか。例えば [a-zA-Z] の振る舞いが
        ble.sh 内部 (PROMPT_COMMAND, etc.) で変化してしまうという影響が考えられ
        るが、問題になる事は少ない気がする。例えば fzf の振る舞いが変わってしま
        うという事も考えられるが、実のところ LC_COLLATE=C ではなくてそのロケー
        ルにおける collation を使う必要があるという状況が思い浮かばない。これに
        ついては、ロケールに従った振る舞いにしたければ実際に呼び出す側が fzf に
        LC_COLLATE を設定するなどしてもらうという形で良い様に考える。

      うーん。f の方針で行く事にする。待避するとしたらどの変数を待避する必要が
      あるだろうか。Bash は LANG, LC_ALL, LC_COLLATE, LC_MESSAGES, LC_NUMERIC,
      LC_TIME に対して変更を検知している。これらに対して全てチェックを行う必要
      があるだろうか。

      ? ok: ble/variable#copy-state 関数を使おうと思ったがこの関数は対象が配列
        や辞書である時に問題になる。要素 [0] が存在していないと配列・辞書全体を
        削除してしまう事になる。然し、だからと言って配列・辞書の状態も保存する
        となると大変である。

        どうも bash-4.4 以降であれば unset -v 'a[0]' という具合にすれば、配列変
        数であれば該当要素だけ削除して、通常変数であればその変数を丸ごと削除す
        るという動作にする事ができる様である。うーん。という事は、

        unset -v 'a[0]' || unset -v a とすれば良いのではないだろうか。

      ? reject: (余談) 実は配列かどうかの判定に unset -v 'a[巨大な数]' を使う事
        ができる可能性?  と思ったがそもそも変数すら存在していない時にも unset
        -v 'a[xxx]' は成功する様である。なので、変数が存在している事の確認と共
        に判定を実行する必要がある。然し、空配列に対して変数が存在しているかど
        うかをどうやって判定するのか。declare -p a として確認する必要があるので
        はないか。然し、宣言されているだけで unset な状態になっている場合もあっ
        て、その場合には declare -p a も成功してしまう。

        * declare -p a
        * ((${#a[@]})), [[ ${a[@]} ]] , [[ -v a[@] ]], etc.

        色々考えると余り有用ではない様に思われる。特に bash-4.0 以降では辞書と
        の区別もしなければならないので unset -v だけでは不十分である。

      取り敢えず新しい ble/variable#copy-state を使って実装した。

    既存の LC_ALL= LC_COLLATE=C に対する対策等はもう不要になった様な気もするが、
    ユーザー環境から呼び出される可能性もあるのではないかなど色々考えると、既存
    の対策に関しては今は残しておいて良いのではないかという気がする。

  * vte の paste で LF が CR に化けるという話 (reported by alborotogarcia) [#D1587]
    https://github.com/akinomyoga/ble.sh/issues/120

    最初の報告で自分の手許で試してみても再現しなかったが、端末について確認を取っ
    てみると vte であって、更に LF の代わりに CR が送信されて来ているという事が
    分かった。

    いざ修正しようと思ってコードを確認したら既に workaround は入っている様に見
    える。と思ったが、これはあれだ。連続する CR が入っていると変換しきれていな
    い。修正した。多少速度が下がったかも知れないが仕方がないだろう。

2021-05-30

  * util: stdin, stdout が継承されて新しい端末を開いても元端末に表示される [#D1586]

    これは問題だ。取り敢えず inherit は基本的に止める方が良いのだろうか。
    指定した fd が別の fd と一致しているかどうかを判定する方法は存在するだろうか。
    というか端末 tty の結果が変わったら継承しないという具合にするのが良い気がする。
    端末 tty を取得する方法はコマンド tty を実行するしかないのだろうか。

    というか別に現在の 0 が端末であれば普通に上書きすれば良い気がする。
    その様に修正した。

  * decode: Kitty の modifyOtherKeys でまた問題が生じている (reported by lyiriyah) [#D1585]
    https://github.com/akinomyoga/ble.sh/issues/118

    報告によるとコマンドを実行する前には ESC は ESC としての用を為さないという
    事の様である。そしてコマンドを実行すると動く様になるという事。

    手許で Kitty で試してみた所再現した。modifyOtherKeys を internal/external 0
    に設定すると問題は再現しない。internal 2 にすると再現する。internal 1 に設
    定すると問題が発生してしかもコマンドを実行しても直らない。

    どうも Kitty で 2 に設定すると一回は modifyOtherKeys が有効になるが、それ以
    降は modifyOtherKeys は無効化される? 或いは 2 に設定しようとしても何も起こ
    らないという事だろうか。うーん。2 に設定しようとしても何も起こらないという
    事の様である。然し、それならば不思議なのは ble.sh は 4;2 を設定する前に 4;1
    を送信する様にしているという事。それなのに 4;2 の効果がないというのは不思議
    な事である。実際に手許で試してみても 4;1 に設定して 4;2 に設定すると、4;1
    に設定したのと同じ状態になる。

    問題は二種類ある

    * Kitty で \e[>4;1m の時に送信されるキーシーケンスが ble.sh で認識されてい
      ない。実際に試してみると ESC を押した瞬間に何かしら送信はされている様であ
      る。

      これに関しては具体的に何が送信されているのかを確認する。

      keylog で調べてみると "ESC [ 2 7 u" を送信して来ている。decode.sh を確認
      したがちゃんと認識している。と思ったが isolated ESC ではなくて modifier
      ESC として認識されている気がしてきた。調べてみた所、以下の様な流れで処理
      される事になり、modifier ESC になってしまう。

      ble-decode-char
        ble-decode-char/.getent
          ble-decode-char/csi/consume
            ble-decode-char/csi/.decode
              csistat 設定
          csistat を ent にコピー
        ble-decode-char/csi/clear
        ble-decode-char/.send-modified-key "$ent" "$seq"
          此処で $1 == 27 の時に
          ble-decode-char/.process-modifier Meta を呼び出している。

      csi で受信した文字が 27 の場合には IsolatedESC として処理する事にした。特
      に CSI シーケンスの処理結果として得られた 27 が modifier ESC になる事はあ
      り得ない気がするので csi/.decode の戻り値に対して一括で処理する事にした。

    * Kitty で 2 に復帰した時に \e[>4;0m の状態になっている気がする。
      \e[>4;1m\e[>4;2m で 2 に設定している筈なのに不思議である。手許で自分で設
      定するとちゃんと 4;1 の状態になっている。

      次の問題はこれである…。実際に確かめてみると、そもそも有効化の 4;1; 4;2
      の所に入っていない様だ。確認してみると
      ble/term/modifyOtherKeys/.supported が false になっている。更に調べると
      _ble_term_TERM が vte になってしまっている。

      DA2R を見て判断する事にする。Kitty の DA2R は一体どういう形式なのだろう。
      調べると以下が該当するコードである。

        ./kitty/screen.c:1460: write_escape_code_to_child(self, CSI, ">1;"
        xstr(PRIMARY_VERSION) ";" xstr(SECONDARY_VERSION) "c"); // VT-220 +
        primary version + secondary version

      そしてこれらの値は setup.py に於いて

        constants = os.path.join('kitty', 'constants.py')
        version = tuple( map(int, re.search( r"^version: Version =
          Version\((\d+), (\d+), (\d+)\)", constants, re.MULTILINE ).group(1, 2, 3)
          ))
        cppflags.append('-DPRIMARY_VERSION={}'.format(version[0] + 4000))
        cppflags.append('-DSECONDARY_VERSION={}'.format(version[1]))

      という具合にして初期化されている。kitty/constants.py には以下の様な行がある。

        version: Version = Version(0, 19, 3)

      どうも Kitty の version は永年 0 の様だ? 取り敢えず適当に kitty 用の判定
      条件を追加する事にした。

2021-05-29

  * syntax: \? を着色したい [#D1584]

    色は magenta で良い。\q が現れる箇所はコマンド、"..." である。それぞれ規則
    は異なる。特に後者については規則が分かりにくいので色を付ける対象にしたい。

    $'...' も別枠で着色する様にしたい。これもちゃんと実装した。これで
    $'...' を書く時にどのようなシーケンスが有効でどの様なシーケンスが
    無効か分かる。所で bash version 依存性はどうなっているのか確認する
    必要がある。

  * complete: quote されているコマンド名に対しても補完関数を適切に探索 [#D1583]

    quote していると補完関数が認識されない。例えば git co とすると OK だが
    'git' co とすると反応しない。然し実の所、これは普通の bash でも同様である。
    普通の bash でも 'git' としている時には git の補完関数は呼び出されない。

    unquote した上で補完を探索するべきである気がする。但し、alias 展開などに関
    しては quote された物で実行するという事。comp_line, comp_words に入っている
    のは展開前の quote された物であるので余計な事は考えなくて良い。

  * [reject] complete: そもそも -F に指定する事のできる文字列には制限がある筈である [#D1582]

    これを満たさない場合には強制的に其処で終端させる等の対策が必要なのではない
    か。

    然し、;&| 等が含まれていた場合にどの様に取り扱うべきかは不明である。明らか
    に何かが間違っているけれども、だからと言ってその直前までを関数名と捉えるの
    にも無理がある様な気がする。然し、それ以外に解釈のしようがないとも言える。

    或いは途中に空白がある場合には ble.sh の拡張として関数に余分の引数を渡す事
    にする? 然し、これは最新の bash-5.1 では使えない事なので古い Bash だけで使
    える機能として提供しても仕方がない。結局これは失敗するべきなのではないか。
    そして失敗するのだとしたら現状の動作のままで良いという事の気がする。

  * complete: alias の展開結果で変数代入を除去するべきではないか [#D1581]

    というより実の所 simple-word でできるだけ解析していくべきの気がする。と思っ
    たが、 ; や変数代入があった時の振る舞い、文法エラーがある場合の振る舞いなど
    は用途によってまちまちなのでこんｋ内は core-complete.sh の側で実装する事に
    した。

    simple-word の終端しない版というのはあっただろうか。なかったが
    simple_rex_element をそのまま使えば良い。

    * __load_completion を呼び出すと -D に相当する処理が勝手に入ってしまう。
      complete が駄目な気がする。自前で補完定義を探してロードする関数を作ってみ
      たが、その後で気づいたのは __load_completion は別に見つからなかった時に勝
      手に既定の定義を使う訳ではないのだという事。

      以下の自前の定義は結局使われる事はないのだった。

      | _ble_complete_progcomp_bashcomp_initialized=
      | _ble_complete_progcomp_bashcomp_dirs=()
      | function ble/complete/progcomp/.bashcomp-initialize {
      |   if [[ ! $_ble_complete_progcomp_bashcomp_initialized ]]; then
      |     _ble_complete_progcomp_bashcomp_initialized=1
      |
      |     local user repo bin
      |     user=${XDG_DATA_HOME:-$HOME/.local/share}/bash-completion/completions
      |     [[ $BASH_COMPLETION_USER_DIR ]] && user=$BASH_COMPLETION_USER_DIR/completions
      |     ble/string#split repo : "${XDG_DATA_DIRS:-/usr/local/share:/usr/share}"
      |     bin=./completions
      |     [[ $BASH_SOURCE == */* ]] && user=${BASH_SOURCE%/*}/completions
      |
      |     local path
      |     for path in "$user" "${repo[@]}" "$bin"; do
      |       [[ -d $path ]] && ble/array#push _ble_complete_progcomp_bashcomp_dirs "$path"
      |     done
      |   fi
      | }
      | function ble/complete/progcomp/.load-bash-completion {
      |   local cmd=$1
      |   ble/is-function __load_completion || return 1
      |   ble/complete/progcomp/.bashcomp-initialize
      |
      |   local dir file
      |   for dir in "${dirs[@]}"; do
      |     for file in "$dir"/{"$cmd","$cmd.bash","_$cmd"}; do
      |       [[ -s $file ]] || continue
      |       source "$file"
      |       return 0
      |     done
      |   done
      |
      |   ((_ble_base>=40000)) || return 1
      |   ble/is-function _filedir_xspec &&
      |     [[ ${_xspecs[$cmd]+set} ]] &&
      |     complete -F _filedir_xspec "$cmd"
      | }

  * complete: "\a" 等のコマンド名の補完で問題が起こる (reported by huresche) [#D1579]
    https://github.com/akinomyoga/ble.sh/issues/116

    [原因]

    | bash_completion との関連でまた問題が起こっている。最新の bash_completion で
    | 再現する事ができた。
    |
    | 何れにしてもこれは bash とのインターフェイスの違いなので修正されるのは
    | ble.sh の方であろう。そして文面を読む限りは "minimal ''" という名前のコマン
    | ドを呼び出そうとしている?  これは parse の問題の様な気もするが…。取り敢え
    | ず何が起こっているのか調べる。

    結局これは ble.sh の側の問題であった。再現条件は bash-5.1 である。
    bash_completion では何故か空文字列に対するコマンドでも complete -F _minimal
    '' を登録する様で、しかも bash-5.1 から complete -p の出力の形式が変化した
    事によって ble.sh が -F の解析に失敗して問題が露呈したという事になる。

    | * "a" では発生しない。"\a" や "$$" では発生する。
    |
    | 取り敢えず再現しているので何が起こっているのか調べる事にする。
    |
    | % うーん。どうやら。simple word じゃない時にコマンド名を決定できず、結果と
    | % して空のコマンド名に対して補完が呼び出されているという形になる。うーん。
    | % この場合にはどうするのが良いだろうか。もう直接 simple-word でない内容を転
    | % 写する?  うーん。それも一つの手である。
    |
    | と思ったが、そうでもない様である。例えば "$$" というのは simple-word である。
    | 改めて何で空になるのか確認する必要がある。
    |
    | "\a" は展開されて \a になるがそれにより補完は最終的に失敗する様だ更に引き続
    | き \\ による補完が呼び出されてそれが evaluate されて \ になる等している。然
    | し、"$$ の場合には数字に展開されて、その後で曖昧補完の為に一文字目 "1" の数
    | 字を使って補完されるという事が起こっている。それでもエラーは発生している。
    |
    | 不思議なのは普通に 1 として入力しても問題が生じないという事。というか、やは
    | り COMP_WORDS が空になってしまっているのが問題なのだという気がする。
    |
    | ? そもそも最初のコマンド名でない場合でも、simple-word でない場合には補完は
    |   どうなっていただろうか。
    |
    | →少し分かった。generate-subwords が5回実行されていて '$$', '', '1', '1',
    | '' となっていて問題のエラーは空文字列で呼び出された時に発生している様である
    | という事。遡って見るとそもそも compgen-helper-func 自体もその様に呼び出され
    | ているという事が分かった。ble/complete/progcomp/.compgen もその様に呼び出さ
    | れている。
    |
    | ? うーん。不思議なのは "a" 等の普通の表記の時にはその様な事がないという事で
    |   ある。何故だろうか。調べてみると普通の場合でもちゃんと空文字列による補完
    |   が呼び出されている。そもそもこの空の状態での補完の要求が一体何故呼び出さ
    |   れているのかという疑問は残るが、現在発生しているエラーメッセージとは関係
    |   がないという事だろうか。
    |
    |   然し空の文字列になる場合を除外してみるとちゃんとエラーメッセージなく補完
    |   が実行される様である。
    |
    | ? ok: 何故空の文字列で補完 compgen が呼び出されているのだろうか。
    |
    |   これは曖昧補完で -I による補完を試みているからである。
    |
    | ? done: 何故普通のコマンド名の場合には空の文字列で補完が呼び出されても問題
    |   が発生していないのか。何故特定の文字列の時にのみエラーメッセージが発生す
    |   るのだろうか。
    |
    |   | うーん。不思議な事だ。どうも調べると compdef に変な文字列が入ってくる。つ
    |   | まり complete -p 自体が予期しない内容の文字列を出力しているという事だろう
    |   | か。
    |   |
    |   | うーん。どうやら空文字列で呼び出されるのは曖昧補完の為に -I でコマンド名
    |   | を保管しようという時の話であって。然し、何故か文字列の種類に応じて -I で
    |   | 呼び出されたり或いは直接コマンド名で呼び出されたりというのが変化している
    |   | という様子。もっとちゃんと書くと何故か文字列の種類によって initial が付け
    |   | られずに compgen が呼び出されるという事。
    |   |
    |   | やはり initial なしで呼び出されるというのは変だ。initial がないという事は
    |   | コマンド引数としての補完を要求している事に他ならない。然し、空文字列での
    |   | 補完なのにそれは起こり得ない筈である。呼び出し元を確認する必要がある。調
    |   | べてみると何故か "$$ の時には source:argument が生成されているのだという
    |   | 事が判明した。一体どういう事なのだろうか。source:command は一切生成されて
    |   | いない。うーん。syntax の context 生成が怪しいという事になるだろうか。
    |   |
    |   | 生成された source を確認してみると declare -a sources=([0]="argument 0")
    |   | が生成されている。うーん。つまり、core-syntax.sh に於いて単語内部の nest
    |   | した文脈からだと argument が生成されてしまうという事である。

    "..." の内部の nest した文脈ではそれがコマンド名か引数内部かに関係なく
    argument が生成されてしまうのが原因だった。

    確認してみると以下の関数で argument 決め打ちにしている。
    ble/syntax/completion-context/.check-prefix/ctx:quote/.check-container-word

    判定の為に nest に登録されている単語情報を確認しているが不思議である。 CMDX
    や ARGX になっている。CMDI や ARGI ではないのだろうか。特に nest が始まった
    のが単語の途中であっても CMDX や ARGX になっている。

    > function ble/syntax:bash/ctx-command/.check-word-begin {
    >   if ((wbegin<0)); then
    >     local octx
    >     ((octx=ctx,
    >       wtype=octx,
    >       ctx=_ble_syntax_bash_command_BeginCtx[ctx]))

    うーん。この部分を見ると wtype は単語が始まった瞬間の文脈を保存している。

    > function ble/syntax:bash/ctx-command/check-word-end {
    >   # 単語の中にいない時は抜ける
    >   ((wbegin<0)) && return 1
    >
    >   # 未だ続きがある場合は抜ける
    >   ble/syntax:bash/check-word-end/is-delimiter || return 1
    >
    >   local wbeg=$wbegin wlen=$((i-wbegin)) wend=$i
    >   local word=${text:wbegin:wlen}
    >   local wt=$wtype
    >
    >   [[ ${_ble_syntax_bash_command_EndWtype[wt]} ]] &&
    >     wtype=${_ble_syntax_bash_command_EndWtype[wt]}

    更に此処で _ble_syntax_bash_command_EndWtype を用いて最終的に記録する wtype
    に変換している。という事は実際の判定でも _ble_syntax_bash_command_EndWtype
    を参照するべきである。

    [修正]

    * done: compcmd が空文字列の時に bash は '' を出力する。つまり微妙に quote
      するという事。

      $ complete -o bashdefault "''"
      $ complete -o bashdefault ''
      $ complete -p

      試した見た限りでは空文字列の時にだけ '' と出力してそれ以外の場合には直接
      出力する様である。これについては一つ対策を入れる必要がある。これは他の問
      題を修正してから取り掛かる。

  * util (assign): Cygwin で assign 一時ファイルの衝突が発生している様だ [#D1578]

    assign 一時ファイルに BASHPID を付加する様にしたら特に問題は発生しない様子。
    なのでやはり assign 一時ファイルの衝突なのだろうと思われる。実際に保存され
    たファイル名を観察するとやはり衝突が起こっているかも知れない。

    特に頻繁に起こるのは background シェルと親シェルに於ける
    ble/function#getdef なのだろうという気がする。取り敢えず、ble/util/assign
    におけるファイル名の確保を関数に纏める事にする。

    呼び出し元を出力して調べてみた所、そもそもサブシェル内部から呼び出しが発生
    しているのは ble/bin/awk の初期化のみの様であった。ble/bin/awk を、
    ble/util/assign が設定されてから即座に初期化する様に修正してみた所、
    subshell 内部からの ble/util/assign は全く発生しなくなった。

    * 他に気になることとしてはファイルの中身が残ってしまっているという事。

      dec する場所で一緒に clear する事も考えてみたが、実際に実装を見てみると一
      時ファイルの中身を呼び出す前に dec している。読み出し中にエラーがあって中
      断した時の事を考えてだろうか。然し、実行が中断してしまう程のエラーが起こ
      る状況が分からない。set -ue は off にしているし failglob は起こりようがな
      い。なので、dec の位置を変更して dec と一緒にファイルのクリアも行う様にす
      るというのは一つの手である。

      特に大量のデータがある場合にはやはりファイルの中身をクリアするのが望まし
      い。これで多少パフォーマンスが落ちてしまうかもしれないが、問題になりそう
      なのは初期化ぐらいの物であって、初期化の場合には色々他にも bottleneck が
      あるだろうという事で余り気にしない事にする。いざ初期化時間を縮めようと思っ
      たらまた何か別の初期化を遅延させる事にするのが良い。何れにしてもプロファ
      イリングした上で決める事である。

      取り敢えず今の所はファイルの中身は消去する事にする。

    対策は取り敢えずそれでよしという事にする。

2021-05-28

  * ble-reload した時に alias が無効になってしまう [#D1577]

    何故だろうか。そもそもshopt -u する様な事はない…と思ったが、うーん。これは
    単純なミスである。

  * history: bash-3.0 で履歴の数が減少していく問題が再発している [#D1576]

    これは対策をした筈なのに何故だろうか。

    取り敢えず対策コードにちゃんと進入しているのかどうかだけでも確認する。

    再現条件が分かった。bashrc からロードしていると発生しないが、コマンドから
    source して attach すると発生する。bash-3.1 では再現しない。

    該当箇所で確認したがちゃんと復元できている様な気がする。history -p で検索し
    てみたらもう一箇所別の場所で呼び出している。其処の判定条件を確認すると
    bash-4.0 未満の場合には無条件でサブシェルで実行している様に見える。と思った
    がよく見たら _ble_bash となるべき所が _ble_base になってしまっている。

    然し、そもそもサブシェルの判定は ((BASH_SUBSHELL)) で判定できるのでこんなに
    複雑な式を用いる必要はない。

    * done: 算術式の中で誤って _ble_base を使ってしまうという事が余りに多いので
      これも make_command.sh に登録しておくのが良い気がする。登録した。

      $ grc '\(\(.*\b_ble_base\b.*\)\)'

      他には同じミスをしている箇所は存在しなかった様である。

  * main: set -u で壊れていないか久しぶりに確認する必要がある気がする [#D1575]

    試してみたら沢山のエラーが発生している。というか本来 set +u で待避している
    筈なのに何故こんなに沢山のエラーが発生しているのだろうか。不思議である。
    一通り attach する迄の部分を修正していったが実は必要なかった。

    何故 set +u できていなかったのかというとそもそも adjust-bash-options 自体の
    guard で未定義の変数を触っていた為に、adjust-bash-options が実行されていな
    かったのが原因だった。それを直したら普通に動く様になった。

  * main: expand_alias の設定を変えるのはやはり良くない [#D1574]

    現在 ble.sh の内部では完全に alias を無効化しているが、そうすると blerc の
    中で alias を使っている場合に対して影響が出るのではないかという気がする。そ
    の場合には関数を使う様に指示する事もできるが、やはり alias が使えないという
    のは特殊な気がする。

    特に何らかのフレームワークを介して意図的に alias を使って様々の事を実現して
    いるという場合も考えられる。そういう事を考えると alias を何もかも動かなくし
    てしまうのは違う様な気がする。

    うーん。expand_aliases が影響を与えるのは主に ble.sh のロード時であって、ロー
    ドが完了した暁には殆ど影響はない? 然し、実際には沢山の eval を使っていて
    eval は影響を受ける。特にキーワードや builtin に名前が一致する様な alias に
    関しては対策を行っている。その他に影響を与える様な変な alias を設定している
    人がいたとしたらそれはその人が悪いのであって、ble.sh の関知する所ではないの
    ではないか。という事を考えるとやはり alias は有効のまま処理するべきの様な気
    がする。

    一応 expand_aliases の adjust を導入した時の議論を確認して問題がないか考え
    る。該当する議論は #D1519 にある。関連する問題として #D1526 があった。改め
    てこれについて考え直すのが良い。

    * 少なくとも adjust builtins をした後には expand aliases は必要ないのではな
      いかという気がする。或いは、adjust builtins で待避する alias の数を増やす
      必要がある気もするが。

    これの修正は簡単だった。他に影響が現れるとも思いにくいが一応確認はしておく
    事にする。

    と思ったらやはり単純ではない様だ。どうやら alias の状態が bind -x を跨いで
    戻ってしまうのは shopt -u expand_aliases している時だけの問題ではなくて、
    shopt -s expand_aliases だった時にも同様の様である。なので、やはりユーザー
    の側でどういう状態になっていたのかという事を記録・復元する必要がある。

  * ble-sabbrev の初期化遅延で内容出力迄も遅延されている (bash-3.*) [#D1573]

    ble-sabbrev の初期化を遅延しているが、内容確認の為の ble-sabbrev ですら遅延
    されて、ロードした時になってから内容が出力される。この振る舞いは修正するべ
    きである。然し、これを検出する為には、ble-sabbrev の一時実装の側で引数を解
    析する必要がある。

2021-05-27

  * canvas: 変数リークしている (buff, trap, {x,y}{1,2}) [#D1572]

    buff, trap は直ぐに見つかったが x1,x2,y1,y2 は使っている所が多いと思われる
    ので探すのは面倒である。とは言え特にプロンプト関係が怪しいと思われる。

    結局 x1,x2,y1,y2 は trace 自体が駄目だった。justify の初期化位置よりも後で
    local x1 x2 y1 y2 が宣言されていたのだった。然し、この justify の初期化位置
    は此処でなければならなかったのか。そういう理由があった様な気もするがこれに
    ついてはテストで確認する必要がある様に感じている。contra によるテストを設定
    して確認する必要がある。contra でテストを実行してみた所、特に問題なくテスト
    が通った。なのでこの部分の順序変更については気にしなくて良いだろう。

  * 新しい ble-face, blehook, bleopt で問題が起こっている [#D1571]

    * fixed: blehook で新しい hook を作成できなくなっている。何故だろうか。これ
      は引数解析のバグである。

    * fixed: ble-face --hel でエラーにならずにコマンドを実行することができてい
      る。これは修正した。他にも '-' に対する処理を blehook, bleopt と共に修正
      した。

    * fixed: ble-face --color=xxxx のエラーメッセージ表示時にエラーが発生する。
      直した。blehook, bleopt についても --color=xxxx と指定した時のエラーメッ
      セージを改善した。

    * done: ble-face の使い方を wiki にまとめる
    * done: --help に color の説明を含める。

  * bash-3.0 の初期化時に bleopt が出力されてしまっている [#D1570]

    % bash-3.1 では特に問題は起こっていない。という事はまた何かの bash bug に嵌っ
    % ているのか或いは場合分けのコードで bash-3.0 専用の部分に問題があるのか。
    %
    % --norc で source すると問題は起こらない。後で source ~/.blerc すると再現
    % する。同じセッションで再度呼び出せば再度発生する。これも解析のバグである
    % 様な気がする。不思議な事に一回目と二回目で起こる bleopt の位置が異なる。
    % 或いは、起こる回数が変わっているという事か。
    %
    % どうやら bleopt a:=1 という形で呼び出すと read-arguments の結果が空になる
    % 様だ。調べるとスカラーに対して ${var[@]/%/=value} 等とすると失敗する様だ。

    これはまた bash-3.0 のバグである。うーん。調べた限りだと、
    ${scalar[@]/xxxx} の形式は全て空になる。

    $ grc '\$\{[a-zA-Z_0-9]+\[[*@]\]/'

    で検索してみるとそんなに沢山は存在しない。取り敢えず全て確認 or 対策をする
    必要がある。また、m scan に含めるべきである。

    * 確認した所、既存のコードは全て配列に対して異実行していたので問題ない
    * m scan にも含めた。

    x local i "${vars[@]}" に変更漏れがあった。これも後で修正する。

    * 後これは遡って適用するべき項目である。なので独立した項目にする事にする。

  * util: gdict 再考 [#D1569]

    gdict について質問された。説明しようとして思ったのだが、現在の gdict の実装
    は ble.sh の中で直接 global dictionary を作る時を想定していて、module の中
    から global dict を作る場合は想定していないのだった。bash-4.0 で関数内から
    source した時には問題が生じる事になる。

    gdict はもっと一般に使う事ができる様にしたい。つまり、必ずしも直接 source
    した所から使うのではなくて、一般のスクリプトから使える様にしたいのである。
    そう思うと gdict は bash-4.2 以上でのみ使う事にして、それとは別に ble.sh 内
    部から使う為の gdict を定義するべきなのではないか。

    うーん。でもグローバルに何かを定義するのは常にグローバルであるという想定は
    妥当な仮定だという気もする。という事を考えると gdict は現在の実装でも良い気
    がする…と考えたが、もしグローバルな文脈でちゃんと定義できるのであればわざ
    わざ gdict を使わなくても dict を使えば良いのだという事になる。

    * 此処で改めて gdict の存在意義について考えてみると、"関数内で source され
      た場合にもグローバルに辞書を宣言したい" という事にある。

      a 一つの方法は何処から source された時にも使える様に 4.2 以上でのみ本当の
        辞書にしてそれ以外では配列実装に切り替えるという方法。

      b 然し、何処かに辞書ごとの実装の種別を記録しておいて、その種類に応じて辞
        書実装を切り替えるというのも一つの手である。然し、そうすると複数の変数
        に記録する事になってしまうので何だか変な感じがする。

        現在の辞書の実装ではキーを x$key にしているので、他の要素は特殊用途の為
        に使う事ができる。つまり、要素 0 に種別を格納しておくという事も可能であ
        る気がする。然し、配列実装の側では要素 0 はちゃんと意味のある要素として
        使っているので其処を変えるのは変な気がする。

        或いは、毎回 is-array を呼び出すという手もあるのかもしれないと考えたが、
        問題の bash-4.0, 4.1 では is-array の判定に assign を使っているので、辞
        書のアクセスの度にファイルの読み書きが発生する事になって気分が悪い。

      c 或いは、bash-4.0, 4.1 の時にだけ実装種別の判定を行う様にすれば良いので
        ある。

        またこの方法の場合には宣言時に [[ $FUNCNAME ]] 等を確認して宣言を切り替
        える必要がある。

        % if [[ $FUNCNAME ]]; then declare -gA X;
        %
        % x もう一つこの方法の弱点。この方法では FUNCNAME が期待通りに動く事を想
        %   定している。然し、ユーザーが unset FUNCNAME をしてしまっていると
        %   FUNCNAME は常に存在しない事になってしまい、誤判定してしまう。実は
        %   FUNCNAME がちゃんと動作しているかどうか確認する為には一回関数を呼び出
        %   して要素数が変化するか見れば良い。
        %
        %   % 類似の変数として FUNCNAME, BASH_LINENO, BASH_SOURCE が存在する。で
        %   % は、これらの変数が全て使用不能になっていたらどうすれば良いのだろう
        %   % か。(改めて確認した所、BASH_LINENO 及び BASH_SOURCE は関数呼び出し
        %   % でなくても常に存在している様である。そして source の場合にも要素の
        %   % 数が変化する。という事を考えると関数内かどうかの判定には使えない気
        %   % がする)
        %
        %   b BASH_LINENO/BASH_SOURCE を使って判定する事は可能だろうか。実際に呼
        %     び出してみてどの様に動作するか確認する必要がある。うーん。両者とも
        %     ファイル名と行数しか表示しないので関数かどうかの判定には全く使えな
        %     い。
        %
        %   c その場合には、caller builtin を使う事ができるだろうか。と思ったがこ
        %     れも駄目の気がする。これは関数であるかどうかに拘らず実行することの
        %     できる関数なので、結局関数内にいるかどうかを判定するのには使えない。
        %
        %     caller の出力を確認すれば一応 "関数名" or "source" を確認する事がで
        %     きる。此処で、"source" 以外の関数名があった時には関数内にいるという
        %     事は確定する。逆に全て "source" だった時にはどうだろうか。取り敢え
        %     ず自分がトップレベルから source されている場合には caller 0 が失敗
        %     する。この場合には "関数内にはいない" という事が確定する。
        %
        %   d reject: 或いは実際にその context で変数を定義してみたら良いのではな
        %     いだろうか。と思ったが、それも駄目である。関数内でもし呼び出されて
        %     いるのだとしたら、結局その関数の文脈にローカル変数が作られるので、
        %     確認する立場からすれば何れにせよ変数が見える事になる。問題は現在の
        %     文脈 (外側の関数) を抜けた時に自分の手元で定義した変数がちゃんと残
        %     存するかどうかという事なのである。
        %
        %   e declare xxxx としてから local で変数が存在するかどうか確認したら分
        %     かるのではないか。
        %
        %   f よく考えたら local が成功するか失敗するかで確実に判定可能なのではな
        %     いか。これだ。これで判定する事ができる…。local が別の理由で失敗
        %     する可能性としてその変数名が特殊変数であったり読み取り専用だった
        %     り型が変換不能だったりという事が考えられるが、_ble_... に選んで置
        %     けば特に問題はない。
        %
        % [source スクリプト内で関数内にいるかどうかの判定方法]
        %
        % 先ず初めに FUNCNAME が特殊な意味を保持しているかどうかを確認する。これ
        % は実際に関数を呼び出してその中で FUNCNAME の要素数が増えているという事
        % を確認すれば良い。もし特殊な意味を保持している場合には、FUNCNAME が定義
        % されていれば関数内にいるし、或いは FUNCNAME が定義されていなければ関数
        % 内ではない。
        %
        % 次に caller の出力を確認する。caller 0 が失敗すれば即ちトップレベルから
        % 直接 source された事を意味しているので、確実に関数外に存在する。caller
        % 0,1,2 を失敗するまで逐次呼び出して行って、途中で source 以外の関数名に
        % 出会ったら関数内部にいる事が確定する。

        local _ble_local_test とでもしておけば関数内部にいるかどうかの判定は可
        能である。というか、現在 FUNCNAME を使って実行しているテストもこれに切
        り替えるべきなのではないか。

        bash-4.2 以上の場合、常に -gA を使う。
        bash-3.2 以下の場合、常に配列を使う。
        bash-4.0, 4.1 の場合は条件分岐する。

        if local _ble_local_test 2>/dev/null; then
          NAME=() NAME_keylist=
        else
          declare -A NAME; NAME=()
        fi

        その様に書き換えた。

      * done: 既存の連想配列に依拠しているコードも、実際に配列が連想配列かどう
        かで判定するべきの気がする。

        現在は _ble_bash_loaded_in_function で判定を行っている。というか面倒な
        ので一部の物に関しては完全に gdict を使った実装に切り替える事にした。3
        つ書き換える事になった。

        - _ble_decode_kbd__k2c
        - _ble_builtin_history_rskip_dict
        - _ble_builtin_trap_n2i

        _ble_bash_loaded_in_function を使っていても gdict による宣言を使ってい
        ない物に関してはそのままにする事にした。

        残っている物は以下の物である。うーんこれらも書き換えてしまうべきだろう
        か。そちらの方が正直な所メンテナンスしやすい。問題は書き換えでバグが入
        らないかという事と、速度的に遅くならないかという事である。特に、現在の
        主なターゲットは bash-4.4 以降であると考えると、古い実装に対して配慮し
        なくても良い様に思われる。

        - ./lib/core-complete.sh:6102:if ble/is-assoc _ble_complete_sabbrev; then
        - ./lib/core-syntax.sh:6290:if ble/is-assoc _ble_syntax_highlight_filetype; then
        - ./lib/core-syntax.sh:6403:if ble/is-assoc _ble_syntax_highlight_lscolors_ext; then

        取り敢えず使われている箇所で速度が気になるかどうかを確認する。結局全部
        新しい実装に置き換える事にした。bash-4.2 以上であれば単に関数呼び出しコ
        ストと、要素が実際に存在しているかどうかの判定コストが増えるだけである。
        結局 s2c のテーブル以外については全て完全に gdict を使う事にした。

      * done: sabbrev の書き換えの際に ble/gdict#keys を使った。
        実装する必要がある。実装した。

    * done: 現在の辞書の中身を表示する為の関数、key の列を取得する為の関数もあっ
      た方が良いのではないかという気がする。

      ble/gdict#keys については既に上で実装した。
      ble/gdict#print については既存の関数を使って実装する事にした。

    * 後、bash-4.0, 4.1 で既に連想配列として宣言されている場合にはそれを流用す
      るべきなのではないだろうか→その様に書き換えた。OK 簡単に確認も済ませた。

2021-05-25

  * util: 設定インターフェイスの細かい修正 [#D1568]
    * ble-face 導入
      * done: ble-color-setface の出力で ref: を認識する
      * done: ble-color-setface で @ の形式に対応する?
      * done: ble-face -r で元に戻せる様にしないと themes の切り替えに困る
      * done: ble-face -u で変更された face を表示する。
    * done: bleopt xxx@xxx=xxxx で一括設定ができる様にする
    * done: bleopt 既定値からずれている物だけ出力する機能
    * done: bleopt 既定値に戻す機能
    * done: blehook internal hook は既定では表示しない機能

2021-05-24

  * global: gA をその場で代入しなければ 4.2 でも大丈夫 [#D1567]

    共通なコードも多くあったので整理して纏める事にした。大分すっきりした。

2021-05-23

  * contrib/git-prompt.sh の変数達は localvar_inherit で駄目なのではないか [#D1566]
    というか他にも同様の変数宣言の仕方をしている箇所は色々ある気がする。
    →検索して修正した。

  * keymap/vi: vim モード表示に関して (reported by huresche) [#D1565]
    https://github.com/akinomyoga/ble.sh/issues/114

    また vim のモード表示に関連する提案・質問が来ている。何処かに纏めておくべき
    であろうと思われる。取り敢えず後で vim mode の wiki ページに少なくとも説明
    かまたは説明へのリンクを載せておく必要がある。

    * done: 取り敢えず keymap_vi_mode_name_xxxx を変更したら mode name の更新を
      予約する様にしなければならない。と思ったが何処で呼び出す様にしたら良いの
      だろうか。現在の実装を確認するとモード変更時に update-mode-name を呼び出
      している。そしてこの関数は即座に表示を行っている。然し、他の関数から mode
      name の設定を変更する場合には、その場で info を表示してしまうと変な事にな
      る。

      a info pane を表示していない時は内部的に変更するに留める? 内部的に入れ替
        えるだけという機能を info に実装する必要がある。また、これだと一連の設
        定を変更した時に各項目ごとに info を表示し直すという事になって効率が悪
        い。

      b やはり更新は遅延させるのが望ましい。然し、遅延させるとしてもどのタイミ
        ングで更新を行うのだろうか。やはり info reveal の瞬間に内容を更新するの
        が良いのではないかという気がする。

      新しく info_reveal hook を追加して b の方針で実装する事にした。

    * vim-airline の API を調べてそれをできるだけ再現するようにするという可能性
      も考えられる。但し、厳密に再現できる訳でもないと思われるが。vim-airline
      の README にはそんなに customization の情報は書かれていない。

      * 単に各フィールドの内容が指定できるというだけの事である。

      * それから、truncation は ble.sh では実装されれていない機能である。うーん。
        これの対応は面倒だ。現在の実装だと trace の中で各フィールドについて計測
        を行って、その上で出力を行っている。なので、truncation も原理的には実装
        可能であるが、(1) 各フィールドの優先順位はどうやって指定するのか (2)
        separator 毎の最大・最小幅をいよいよ実装する必要が出てくる (3) 自動改行
        を抑制する など色々修正が必要である。特にどういう仕様にするのかというの
        が一番面倒である。自然なインターフェイスで separator 毎の最大・最小幅を
        指定できる物だろうか。

      よし。vim-airline を真面目に実装する事にする。

      ? 各セクションが空の時にセクションを潰したい。然し、一方で各セクションの
        内容はプロンプトシーケンスとして実装したい。これの両立は可能だろうか。
        うーん。何だか難しそうな気がする。実際に実体化するまでは各セクションが
        潰れるかどうかは判断できない。という事は先に各セクションを実体化するし
        かない。

        * 二重に処理する事になるがそうすると端末固有の SGR を二重に処理する事に
          なるのでは。うーん。一旦 ANSI 形式で出力するオプションを実装する必要
          がある気がする。

      * done: auto-truncation の実装

      * done: gitstatus に関しては後で vim-airline を実際に入れて動作を確認する
        必要がある。どうも vim-airline は tpope/vim-fugitive を使っている様であ
        る。また、dirty 状態かどうかは出力されない様である。取り敢えずよしとす
        る事にする。

        と思ったが改めて確認したらちゃんと出力されていた。機能を追加した。

      * done: ble/color/g2sgr-ansi を実装する
      * done: trace ansi の実装

      x fixed: prompt_status_line の再描画の時に前回の内容がクリアされない (g=0
        の時)

        うーん。不思議なのは直接 printf するとちゃんとクリアされるのに、
        ble/util/buffer 経由で出力しようとするとクリアされないという事。何故だ
        ろう。内容が消滅している可能性? 或いは、DRAW_BUFF か何処かに出力内容が
        残っている可能性もあるのかもしれない。

        調べてみると ble/util/buffer の中に excursion しているコードが入ってい
        る。うーん。どういう事だろうか。誰が ble/util/buffer に内容を入れている
        のだろうか…。不思議である。と思ったら enter-command-layout で info や
        status を消していて、その為に excursion 状態になっているという事の様だ。

        うーん。そもそも WINCH が起こるとこれまでの panel height も全て消えてな
        くなる訳だから、panel height に対する差分修正では駄目の筈である。高さを
        全て確保し直さなければならない。という事を考えると… height を全て空に
        すれば良いのだろうか。或いは。

        | →これは結局様々な問題が複合した結果だった。高さの完全再配置が実装され
        | ていないのが主な問題。そして LINES COLUMNS が反映される迄にどうやら時間
        | がかかる様だというのがもう一つの問題。後者については仕方がないので待ち
        | 時間を入れる事にした。
        |
        | と思ったがこの後者の問題はウィンドウサイズを変更する時に contra がリア
        | ルタイムに大量の WINCH を発生させるのが原因の様である。bash trap はシグ
        | ナルの回数を覚えていないので単に一回だけ発生している様に見えただけだっ
        | た。contra の実装が悪いとも言えるが、然し滑らかにサイズ変更をする端末で
        | は普通に起こって良い事なのでこれに対する対策を入れるのは良い事である。

        問題は最後の WINCH を捕まえる事ができないという事である。trap handler
        を実行している間は実行がブロックされている。WINCH の処理の最後で再度
        LINES COLUMNS が変化していないか確認すれば良いのではないか。
        →その様に変更したら可也振る舞いが改善した。

      x fixed: SIGWINCH で乱れる問題。実は tput で端末の大きさを取得すれば良い
        のでは。というか (:) 等を実行しても checkwinsize で更新されるのではない
        か。と思ったが tput で取得しても LINES COLUMNS で取得してもずれがある様
        である。

      x fixed: prompt_status_line が WINCH で再描画されていない?
        none になっている時に塗りつぶしを省略しているのが原因である。
        huresche にも改めて指摘されたのだった。

      x fixed: menu-complete が動かなくなっている。trace に手を入れたのが原因だ
        ろうか。

        あー。多分、合成がうまく行かなくなっている。改めて実装を確認する。と思っ
        たら動く様になっている。これも WINCH をした後に生じる問題だろうか。うー
        ん。その様だ。WINCH によって何故動かなくなるのが…謎である。

        menu#render-item はちゃんと呼び出されている。ちゃんと出力も構築されてい
        る気がする。出力までもちゃんと行っている気がする。ああ。分かったかもし
        れない。これは info が invalidate された儘になっているという事なのだろ
        う。直した。

      * done: https://itchyny.hatenablog.com/entry/20130820/1376978742
        此処で紹介されている landscape という配色がなかなか良いのではないか。
        と思って確認してみたがコードはなかなか面倒な事をしている。
        後でどういう結果になるのか調べてみる事にする。

        設定を抜き出しては見たが実際にやってみると白背景だと微妙な感じだ。

      * done: theme の設計を考えると eval-after-load ができる様にするべきでは。
        うーん。現在の実装だと eval-after-load は def.sh に登録している。然し、
        そうではなくて ble-import の枠組みの側で提供するべきなのではないだろう
        か。

        これは大きな変更になりそうな気がするので後回しにする。
        →結局そんなに大きな変更ではなかった。簡単だった。

2021-05-22

  * main: set -e の時にロードできない [#D1564]

    またロードできなくなっている。これは本当は定期的にテストしなければならない
    事の気がする。

    * adjust-builtins で失敗している。alias 定義を読み取る時の alias ... と、
      alias を削除する時の unalias に於いて存在しない alias を取り扱おうとする
      と exit status が 1 になって駄目の様である。

    * prompt attach の際にも問題が生じていた。二箇所条件の書き方を変更した。

      * blehook でも失敗している。中に於ける if builtin eval ... ; then ... が
        駄目の様だ。試してみると

        false || true # OK
        eval false || true # OK
        builtine eval false || true # 駄目

        という具合の動作になっている。bash-4.4, dev で確認した。3.0, 3.2 でも同
        様の振る舞いである。これは後でバグ報告に持っていく事にする。

        問題の箇所は eval を使わない形式に書き換える事にした。

    これでまたロードできる様になった。本当は blehook, ble-bind その他のインター
    フェイスについても set -e に対する対策をするべきの気もするが取り敢えず何も
    設定しない限りに於いては動くので良しとする事にする。そもそも set -e で対話
    シェルを使おうとする事自体があり得ない想定なので余り深く考えなくて良い。

  * 2021-05-16 complete: tar xf groff-1.19.2.ta[TAB] でエラーが発生する [#D1563]

    と思ったらこれは bash-completion だった。また確認してみたところ、これは5週
    間前に既に修正されていた様だ。

2021-05-20

  * 2021-05-13 tmux-resurrect により vi_imap が empty になる問題 (reported by RakibFiha) [#D1562]
    https://github.com/akinomyoga/ble.sh/issues/109

    "ble.sh: The keymap 'vi_imap' is empty." というエラーメッセージが出るとの事
    だが他には何もメッセージは出ないのだろうか。試しに keymap.vi を空にしてロー
    ドしてみると…再現した。

    * bash ble.sh --clear-cache オプションを実装した方が良い。

    * ファイルが存在するかどうかのチェックをしている箇所は、全て有限の大きさを持っているかどうかを確認した方が良い。

    * 空の keymap になっていたらキャッシュ無しで初期化し直す機能を付けた方が良いかもしれない。

    うーん。何と再現しなくなってしまった様である。
    こうなるとコードを見て憶測で修正するしかなくなる。

    # {
    #   ble/decode/keymap#load isearch dump
    #   ble/decode/keymap#load nsearch dump
    #   ble/decode/keymap#load vi_imap dump
    #   ble/decode/keymap#load vi_nmap dump
    #   ble/decode/keymap#load vi_omap dump
    #   ble/decode/keymap#load vi_xmap dump
    #   ble/decode/keymap#load vi_cmap dump
    # } 3>| "$fname_keymap_cache"

    あー。もしかすると原因が分かったかもしれない。そもそも前に自分が問題を経験
    した時にもそうだったが、ble/decode/keymap#load を改名した事が原因なのであっ
    た。此処で、ble.sh が部分的に更新されていたりすると問題になるという事なのだ
    ろうという気がする。tmux-resurrect が一体何をしようとしているのかは結局謎な
    のであるが、うーん。

    そもそも報告者が最新の物でも再現するとかしないとか言っていた時に、毎回 make
    をしていたのかというのも疑問の一つである。と思ったが rebuilding と言ってい
    るので、其処の所はちゃんとやっているのだろうという気がする。

    a あー。もしかすると複数の異なる ble.sh を使っていて cache が混合していると
      いうのは十分考えられる可能性である。と思ったが本当にそれで問題が発生する
      だろうか。何れにしても呼び出す vi.sh は同じディレクトリにいる ble.sh から
      呼び出される筈で中途半端に更新されていない限りは不整合は起こらない筈なの
      である。

      或いは tmux-resurrect が下手に関数等を保存しているのだとすると変な事が起
      こっても仕方ない → 試しに関数を定義して保存・復元して見たが関数は消滅し
      ていた。つまり、そういう事は関係ない。

      或いは vi.sh の timestamp が偶然未来に設定されてしまったりする様な場合に
      も問題が起こったりするかもしれない。

      うーん。やはり timestamp が壊れない限りはこれによって変な事が起こったりす
      る可能性は低い気がする。

    b 後タイムスタンプが nfs などによってずれていたりするとそういう事があったり
      するかもしれない。timestamp が信用できない時にはどうしようもない。これは
      個々の使用者の側で注意して時刻を合わせてもらうしかない。

    * done: 失敗したとしても端末の状態が壊れない様にする。

    ? コードを見てみると初期化に失敗した時には完全に空 map になってロードされな
      いのではなくて safe keymap に fallback する筈なのだが何故そうなっていない
      のだろうか。

      これは再現できるので修正はそんなに難しいことはない筈。

    2021-05-20 もう返事もないし再現もできないし、向こうでも何だか解決した様な雰
    囲気を出しているので取り敢えず対症療法を push する事にする。

    * 他にも似たような現象が起こる可能性があるのでキャッシュファイルについて全
      て -s を用いてチェックする事にする。
    * この際なので _ble_base_cache 内の構造・ファイル名についても整理する事にし
      た。

  * syntax: ${a~} に対応していない [#D1561]

    何れ消えると思っていたがどうも未だ消える気配はない様だ。取り敢えず使える環
    境ではちゃんと着色した方が良い様に思われる。

    後気付いたのだが実は ${a^^} や ${a,,} も bash-4.0 から使えた様だ。tolower,
    toupper の実装に使えるのでは。と思って確認した所、既に 4.0 以上ではこれらを
    使う様になっていた。

    軽微な修正だがこれだけ放置していても仕方がないのでもう push する。

  * prompt: update "PS0" between multiple commands (motivated by tycho-kirchner) [#D1560]

    複数のコマンドが一度に実行される時に、それぞれのコマンドについて PS0 が呼び
    出される。然し其処から参照される $# の値が更新されない様だった。調べてみる
    と、PS0 の更新をチェックする時に、更新の必要があるかどうかの判定をする hash
    値が複数のコマンドの間で変化がない為に更新が省略されていたという事。
    →hash に $# ($_ble_edit_CMD) も含める様にして対処する事にする。

  * decode (ble-bind): ble-bind -m KEYMAP で全ての keymap が出力されている (fixup 750ca38) [#D1559]

    これは指定した keymap を表示する様にした方が良い。というか元々そのつもりだっ
    た筈で単に対応を忘れていたという事の気がする。

  * main: bash ble.sh --test の終了ステータス (fixup bbc2a90) [#D1558]

    subshell からのロードを検出する様にした変更に於いて終了ステータスが意図しな
    い物になっていた。これは return $? || exit $? に於いて二個目の exit が
    return の $? を拾う様になってしまった為。

    a 面倒なので、_ble_init_exit は削除しない様に変更して見た。

    b しかし別の修正方法として eval を使う物を思いついた。うーん。eval を使う事にする。

    棄却した a の修正は此処に供養する。
    | diff --git a/ble.pp b/ble.pp
    | index c9a11d8..d172c7d 100644
    | --- a/ble.pp
    | +++ b/ble.pp
    | @@ -1398,9 +1398,9 @@ function ble/base/initialize/.clean-up {
    |    # 一時グローバル変数消去
    |    builtin unset -v _ble_init_version
    |    builtin unset -v _ble_init_arg
    | -  builtin unset -v _ble_init_exit
    |    builtin unset -v _ble_init_command
    |    builtin unset -v _ble_init_attached
    | +  #builtin unset -v _ble_init_exit
    |
    |    # 状態復元
    |    if [[ $_ble_init_original_IFS_set ]]; then
    | @@ -1444,18 +1444,17 @@ ble-import -f lib/_package
    |  if [[ $_ble_init_command ]]; then
    |    ble/base/sub:"$_ble_init_command"; _ble_init_exit=$?
    |    [[ $_ble_init_attached ]] && ble-attach
    | -  ble/util/setexit "$_ble_init_exit"
    |  else
    |    ble/base/process-blesh-arguments "$@"
    | +  _ble_init_exit=$?
    |  fi
    |
    |  #%if measure_load_time
    |  ble/debug/measure-set-timeformat Total nofork; }
    |  _ble_init_exit=$?
    |  echo "ble.sh: $EPOCHREALTIME load end" >&2
    | -ble/util/setexit "$_ble_init_exit"
    |  #%end
    |
    |  ble/base/initialize/.clean-up 2>/dev/null # set -x 対策 #D0930
    | -{ return $? || exit $?; } 2>/dev/null # set -x 対策 #D0930
    | +{ return "$_ble_init_exit" || exit "$_ble_init_exit"; } 2>/dev/null # set -x 対策 #D0930
    |  ###############################################################################

  * global: v0.3-master へのパッチ適用の際に気付いた細かい修正 [#D1557]
    細かい修正が溜まって来たので此処で一つずつ修正を適用してしまう事にする

    * Makefile で run ではなくて tmp を作っていた。ディレクトリ名を変更した時
      に一緒に変更するのを忘れていた。
    * ble/function#suppress-stderr に不要なごみ引数 { を渡していた。
    * C-w M-w の振る舞いを変更したが、blerc に以前の設定に戻す設定例を入れた。

    * IFS の異なる環境に対する対策としてできるだけ _ble_term_IFS を local IFS
      にコピーする様に変更していたが、この際なので直接 $' \t\n' と記述してい
      る部分をできるだけ全て $_ble_term_IFS に置き換える事にした。
    * src/benchmark.sh は独立したファイルとしても使える様にしてきたつもりだっ
      たが、ble/util/print, ble/util/print-lines を使う様になっていたので、こ
      れらの関数が定義されていない時には定義する様に修正した

2021-05-19

  * README: 様々な機能へのリンクを貼った方が良いのではないかという事 [#D1556]

  * 現在の初期化だと ble.sh session で source --test 等すると [#D1555]

    変な事になるのではないか。これは取り敢えず独立した項目として取り扱う事にする。

  * main: subshell 内部で source/reload したら何が起こるのか [#D1554]

    source した場合には何も起こらない。うーん。これは単に attach 戦略が prompt
    だから attach する前に終了しているという事の気がする。

    reload については reload が実際に実行されて色々と _ble_base_run のデータが
    破棄される。この状態で ble-detach を実行すると制御できなくなる。tty 状態は
    別に問題はない様だ。

  * main: AUR blesh-git について [#D1553]

    * ok: requirements: ble-update の為に git, gawk があった方が良いのかもしれ
      ない? 然し、最終的に AUR helper を呼び出すのであれば余り関係ないのかもし
      れない。特に package としては fallback になる事は想定していないので。

    * ok: (("$helper_prog" != 0))
      https://aur.archlinux.org/cgit/aur.git/tree/blesh-update.sh?h=blesh-git#n29

      (()) の中の quote のルールは変更されている。然し何故か PKGBUILD はそのま
      ま何事もなく動作しているどういう事だろうか。shopt が調整されているのだろ
      うか。或いは bash の version が違うのだろうか。適当な PKGBUILD を作ってそ
      の辺りを出力させたらはっきりするのかもしれない。何れにしても将来的に変更
      されるかもしれないという事などを考えると修正した方が良い。

      と思ったが改めて試してみたが問題はない様だ。単に手許で試す時に
      (("$xxx"!=0)) が ((!=0)) に展開されてエラーになっていただけなのであった。
      bash-5.1 で振る舞いが変更されたのは '' による quote の方であった。

    * local variables
      local PRE_VERSION
      local POST_VERSION

      恐らく他の所で使うという訳ではないだろう。というか、この関数は PKGBUILD
      で使われるのではなくて ble.sh から呼び出しているのであるから他の場所から
      使っているという事はない気がする。

    * _package.sh は実の所 source するだけなので実行属性は必要ない。唯、source
      path を経由して source したい時には実行属性がついている必要があるのだった
      か? man bash を確認したがちゃんと実行可能である必要はないとの事が明記され
      ている。

      というか今知ったがカレントディレクトリよりも PATH の方が優先されるのだそ
      うだ。だとすると結構変な事が起こるの可能性もあったのでは。今試しに ~/bin
      に ble.sh を登録して、bash --norc から ble.sh ディレクトリの外で source
      ble.sh を実行したらちゃんとロードされた。うーん。

    * done: contributing に lib/_package.sh を追加する

    取り敢えず残っている物については簡単に纏めてこの項目はOKとする。

2021-05-17

  * util: inherit special file descriptors [#D1552]

    #D1549 で setsid をしたら /dev/tty が見つからなくなって動かなくなった。
    /dev/tty が壊れてしまうという事態に対応する為に最初に確保した
    _ble_edit_io_std{out,err} を他の場所でも積極的に使う様にするのはどうか。

    * 更に考えると毎回 bash を起動する度に新しく fd を確保するのは無駄である。
      なのであれば、export して共有してしまえば良いのではないかという気がする。

    * また、ふと思ったのだが毎回 /dev/null を開いているのはどうなのだろうか。
      dup の方が軽かったりしないのだろうか。然し、/dev/null を dup できるのかと
      いうのも疑問である。然し、fork した途端に使えなくなるというのも変なので
      /dev/null は dup しても大丈夫なのだという気がする。

        $ ble-measure 'echo hello >/dev/null'
        7.439 usec/eval: echo hello >/dev/null (x10000)
        $ exec {fd}>&14; echo $fd
        14
        $ ble-measure 'echo hello >&14'
        5.035 usec/eval: echo hello >&14 (x20000)
        $ ble-measure 'echo hello >&$_ble_base_fd_null'
        5.821 usec/eval: echo hello >&$_ble_base_fd_null (x20000)

      やはり dup の方が高速である。然し、そもそもの処理時間が短いので気にしても
      仕方がないレベルではある。Cygwin でも同様の結果になるだろうか。

        $ exec {fd}>/dev/null
        $ echo $fd
        16
        $ ble-measure 'echo hello >&16'
        24.920 usec/eval: echo hello >&16 (x5000)
        $ ble-measure 'echo hello >/dev/null'
        41.100 usec/eval: echo hello >/dev/null (x2000)
        $ ble-measure 'echo hello >&$_ble_base_fd_null'
        28.320 usec/eval: echo hello >&$_ble_base_fd_null (x5000)

    →Cygwin でも dup の方が高速である。変数に入れると少し遅くなる。然し本当に
    置き換えてしまっても問題が生じないのかというと分からない。例えば
    _ble_base_fd_null がユーザーによって削除または書き換えられてしまったら何が
    起こるだろうか。大量のエラーメッセージが出て色々と悲惨な事になる気がする。
    後、/dev/null への redirect は可也基本的な事なので、もし置き換えるのだとし
    たら何よりも先立って初期化したい気がする。実装を確認すると ble/fd は
    ble/array を使用している。

    * 取り敢えず fd#alloc のコードや stdin/stdout/stderr のコピーのコードを整理
      して、

      (1) stdin/stdout/stderr は常にコピーを保持する様に変更する。

      (2) bash-4.1 以上では {fd}> ... を使う様にしていたがこれだと
      10,11,12,... という番号を使ってしまい、間違って上書きした時に大変な事にな
      るかもしれないので、昔の様に 30,31,32,... を使う様に戻す。但し以前はなかっ
      た上書き確認を行う。此処で問題になるかもしれないのは、他のフレームワーク
      が上書き確認をせずに 30,31,32,... を使おうとした時の事であるが、それは仕
      方がない。比較として考えれば 10,11,12,... よりは安全として差し支えないだ
      ろう。

      (3) openat_base 等のオプションは ble.sh ロード時のオプションから指定でき
      る様にする。

    * done: wiki で openat_base の項目を編集する

  * macOS で groff のエラーが出る (reported by killermoehre) [#D1551]
    https://github.com/akinomyoga/ble.sh/issues/112

    groff -k というオプションが使えないという事。macOS の groff は v1.19 らしく
    これは 2004 の version である。実に17年前の groff である。このオプションは
    UTF-8 の man を処理する為に追加した物。実質的に preconv | groff と同じらし
    い。しかし、そもそも macOS には preconv がないそうだ。というか。そもそも
    groff 1.19 は Unicode に対応しているのだろうか。

    取り敢えず groff をインストールして確かめてみる。うーん。全然駄目。そもそも
    utf8 device が存在していない様である。何か別の物をインストールすれば良いと
    いう訳でもなさそう。device として ascii, latin1, cpxxxx しかない。ascii に
    するしかない。man は LANG=C で探す。

    然し英語の man を探したとしても本当に groff -man が使えるのかも怪しい。と思っ
    たが検索してみると一応 -man には対応している様な気がする。と思ったが -man
    ではなくて -m man としなければならない?
    https://www.unix.com/man-page/osx/5/groff_tmac/

    どうも試してみたら最新版でも -m man で動作している気がする。 -man と -m man
    は synonym という事だろうか。取り敢えず groff -T ascii -m man <<< X | uniq
    が動くかどうかを確認する。

    と思ったが返信がない。取り敢えずこれで良いのかどうか分からないが #D1550 と
    一緒に変更を加えてみる事にする。それでも治らなかったら使う事にする。何か変
    更し残している事はあるだろうか?

    2021-05-17 と思ったら返事が来た。どうも macOS の groff で -T utf8 も一応は
    使える様子である。うーん。という事は \[uXXXX] も取り扱えるのだろうか。

    * もし \[uXXXX] が取り扱えるのであれば適当に \[uXXXX] に全て置換してしまえ
      ば良い。。。と思ったがどうやってやるのか微妙である。awk で変換しようにも
      awk では文字コードを取り出せないので uXXXX の形式に変換するのにも苦労する。
      うーん。od を使って binary に変換してそれから nawk で色々処理して、それか
      らまた od で元に戻すという様な面倒な処理を実装しなければならない。

      % と思ったが binary に戻す方法は不明である。うーん。調べると bash の
      % printf \x??  経由で出力するという事になっている? awk の printf は NUL
      % が出力できないとしている。他の文字は大丈夫だろうか。というより何故 NUL
      % が出力できないのだろうか。

      awk の printf を使うとしたらテストが必要? と思ったが macOS で動けば良いの
      だから BSD awk で動けば十分である→今試した限りだと nawk, mawk, gawk で何
      れもちゃんとできる。NULもちゃんと出力できるのでOK。

    * もしそのまま通過してくれるのであれば特に気にする事はない。が恐らくそうい
      う事はないのだろうという気がする。

    * 或いは結局全然駄目の可能性もある。うーん。どうなんだろうか。

    返事があった。\[uXXXX] で行ける様である。取り敢えず .preconv を実装した。手
    許で試してみる限りは動いている気がする。まあ、実際に動かして変な事が起こっ
    たらその時にまた考え直せば良い。取り敢えず遠隔で実装できるのは此処までであ
    る。

  * complete: ssh -option の後の補完が固まる (reported by rlanore, riblo) [#D1550]
    https://github.com/akinomyoga/ble.sh/issues/98

    $ alias ssh='TERM=xterm ssh'

    で再現するとの情報を得た。他に man -w が現れたり消えたりするという情報も。
    つまり、一つの man -w が 100% になっているのではなくて man -w が繰り返しルー
    プで呼び出されている? また、cache dir に大量のファイルができているという話
    も。つまり、ble/util/assign で無限ループを起こしている可能性がある。

    $ complete -r
    $ source ~/.fzf.bash
    $ TERM=xterm ssh -w[TAB]

    TERM=xterm ssh -bash: 一致しません: /home/murase/.ssh/config.d/*

    ble/complete/source:argument/.generate-from-mandb を見ると alias で展開され
    る限りは無限ループする可能性のあるコードがある。但し、重複判定はしている筈
    なので alias が有限である限りは無限ループにはならない気がするが…。うーん。
    分からない。或いは alias 展開で空文字列になった時に問題が生じる可能性?

    OK! 再現できた!

    - 自分の手元で再現できなかったのはどうも何か別の設定が勝手に
      bash-completion を読み込んでしまうからだった様である。一体何の設定が勝手
      に読み取るのかは謎だが、complete -r を実行しても何故か設定が読み込まれて
      しまう。と思ったが… ble.sh が __load_completion が存在している時には勝手
      にそれを呼び出す様にしていたのだった。そういう設計も考え物といえば考えも
      のである。但し、これも unset -f __load_completion すれば解除する事ができ
      る筈なのである。

    * fixed: 分かった。 ble/complete/source:argument/.contains-literal-option が
      variable leak して ret を書き換えしてしまっている。直した。

    * done: 更に alias で TERM=... としていても対応できる様に読み飛ばし機能も追
      加した。

    x fixed: 然し ssh のオプションを抽出するのに失敗している。何故だろうか。改
      めて振る舞いについて調べる事にする。ble/util/assign を ble/assign と書い
      ていた。修正した。

    x fixed: 未だ駄目。と思ったら man を探索する部分で $command とするべき所が
      $man になっている。

    x fixed: それでも駄目。調べると ssh の man を gzcat する所まではできている。
      其処から関係のありそうな物を抽出する所で失敗している。うーん。man から
      mdoc に変化するという場合もある様だ。どちらでも良い様に色々書き換える。然
      し、それでも nroff の形式がよく分からないので行き当たりばったり的な実装に
      なってしまう。取り敢えず Dd, Nm, Xo-Xc に対応した。また後段で __ble_key__
      と __ble_desc__ が同じ行になってしまった場合でも動く様に修正した。

    x fixed: エラーが出る groff -[TAB] ... これは nawk に日本語のコメントを渡し
      たのが行けなかった。日本語のコメントは除去する様にした。

    x fixed: 空白が沢山表示される。連続する空白は1つに縮約する様にしたい。

2021-05-16

  * work around Kitty bugs (reported by NoahGorny) [#D1549]
    https://github.com/akinomyoga/ble.sh/issues/110

    | bash-it に追加する事について考えると言っているがどの様な形で追加するのだろ
    | うか。コードを直接追加するのだろうか。その場合には色々と微妙。
    |
    | * 先ず ble.sh の codebase は bash-it よりも巨大だ。どかんと入れる事が良い事
    |   なのか分からない。
    |
    | * ble.sh 自体巨大だし UX 自体を大きく書き換える。それ単体として Issue/PR が
    |   頻繁にある。もし単純にスクリプトを追加すると、bash-it に issue が沢山立つ
    |   事になる。それよりは ble.sh の側に Issue が来て欲しい。
    |
    |   * 実は結構好みが別れる様であるという事。autosuggestion を off にしたいと
    |     いう人もいたりするし、syntax-highlighting が遅いという人もいる (これは
    |     完全なる思い込みだと思うが…)。
    |
    |   * 独立した設定ファイルが存在するという事から、ユーザーにちゃんと説明する
    |     必要があるという事。
    |
    | * 自分勝手な事だけれども、bash-it の一部として普通になってしまうと star が
    |   こっちに来なくなる。bash-it の方がメインだと思われるのは嫌である。
    |
    | * bash-it 自体にパッケージマネージ機能などがあればそれを通してインストール
    |   して貰うのが良いという気がする。それがなくても単に git clone etc. を内部
    |   的にして貰うのが良いという気がする。
    |
    | * theme の充実を図りたい。これは渡りに船なのではないか。然し、bash-it にも
    |   theme があるのだという事。
    |
    | * gitstatus.plugin.bash を見ると別に他のプロジェクトをそのまま追加している
    |   という訳ではない様である。存在が確認できた時に追加の設定を行っている様に
    |   見える。

    何だかそういう雰囲気でもなくなったので気にしない事にする。

    未だ Kitty で変な状態になるそうである。例えば setsid 関係で何か変な事が起こっ
    ている可能性? と思ったがもしそうだとするともっと滅茶苦茶な事が起こる様なの
    でこれは多分関係ないのだと思う。

    ble-detach をした後でも問題が再現しているという事を述べている。うーん。試し
    てみたら分かった。これは modifyOtherKeys の解除ができていない。\e[>4;0m が
    効いていないという事なのだろうか。と思ったら、どうもそういう訳でもない。
    printf $'\e[>4;0m' を送ったらちゃんと動く様になる。

    改めて詳しく見てみると…どうも external の既定は 1 の様である。取り敢えず
    workaround を追加する。

2021-05-15

  * package: AUR package (suggested by huresche, help by oc1024) [#D1548]
    https://github.com/akinomyoga/ble.sh/issues/108
    Ref #M0020 PKGUBUILD の書き方

    AUR の PKGBUILD の提案を受けた。PKGBUILD の内容を確認してみる。

    | > arch=('x86_64')
    |
    | arch=('any')
    |
    | > makedepends=('git')
    |
    | makedepends=('git' 'gawk')
    |
    | > pkgver() {
    | >     cd "${srcdir}/${_pkgname}"
    | >     printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
    | > }
    |
    | >     install -Dm644 ./note.txt "${pkgdir}/usr/share/doc/${_pkgname}/note.txt"
    |
    | `note.txt` is just a private note but not a part of the documentation.

    というか既にパッケージにしている人がいる。
    https://aur.archlinux.org/packages/blesh/
    https://aur.archlinux.org/packages/blesh-git/

    PKGBUILD の説明は此処にある
    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

    * fixed: 自分で試しに install を実行してみた所 644 になっていない。うーん。
      644 もしくは 755 になる様に umask 022 とした。

    ble-update を実行すると何が起こるのだろうか。
    取り敢えず複数の方法を組み合わせて対応するのが良い。

    a /usr/* /opt/* etc であって、
      ファイルが存在するけれど書き込み権限がないという時には、
      sudo bash "$_ble_base/ble.sh" --update を実行する。
      sudo の存在チェックも一応する必要がある気がする。

      (a) repository の書き込み権限がない場合と、(b) install 先の書き込み権限が
      ない場合の二つがある。(c) それから repository が見つからなくて、install
      先の書き込み権限がない場合もある。(a) と (c) の場合には全体を sudo で実行
      し直せば良い。但し、(a) の場合には他のユーザーのディレクトリを sudo で更
      新してしまうと変な事になるのでユーザーのチェックは必要である。権限昇格し
      た後に [[ -O file ]] でチェックすれば良いのだろうか。取り敢えずその方針で
      行く。

      この為に ble.sh --update に対応する必要がある。

    そもそも勝手にアップデートして良いのだろうか。複数のユーザーが勝手にアップ
    デートしたらどうなるのだろうか。と思ったが sudo 権限を持っているユーザーが
    勝手に物を実行するのが悪い。sudo を使ってインストールするのだからそれなりに
    他の人に気を遣うべきである。

    b アップデート用のスクリプトを作って sticky bit を付けて無理やりアップデー
      トを実行するという手もある。これは他のユーザーが同時にアップデートしたり
      する危険性が高いし、管理者権限で現在の ble.sh の状態を管理する事が不可能
      になるので駄目。

    c package manager が存在したらそれを使うという手を安易に提案されたが、それ
      だと package manager を使わずにインストールされたのに勝手に package
      manager 経由で再インストールされてしまうという事になりかねない。まあ、
      /usr/share に入っている時点で何らかの package manager を経由しているとい
      う事は明らかなのだから、余り気にしなくて良いのかもしれない。

      と思ったが現在の所は AUR ぐらいしか存在しない。そして AUR ではどの様にアッ
      プデートしたら良いのかよく分からない。単に再インストールすれば良いのだろ
      うか。或いは一旦削除してそれから入れるのだろうか。

    d done: package maintainer の用意したファイルを source するという提案。これ
      も確かに一つの手である。例えば lib/init-package.sh を使う。

      * 名称について: もしくはlib/init-PACKAGE.bash 等の方が良いかもしれない。
        もしこれらのファイルが存在したらそれを source する事にする。PACKAGE と
        大文字にしていると PACKAGE の部分を package manager の名前に置き換える
        のだと勘違いする人がいるかもしれない。やはり此処は init-package.sh にす
        るべきだろうか。然しそうすると今度は他の普通のファイルとの見分けが付か
        ない。或いは単に lib/package.sh とするか。或いは、lib/_package.bash と
        いう形にするのが良いだろうか。

        うーん。lib/_package.bash もしくは lib/_package.sh という事にする。内部
        で、ble/package/update なる関数を定義してもらう事にする。

    * README にリンクを貼る。README が長くなるのも面倒だし、そもそも普段使って
      いる人はコマンドを見なくても分かる筈。という訳で取り敢えずはパッケージ名
      だけ分かる様にしておく。

      一つ一つのコマンドについては Wiki にページを作る事にすれば良いだろうか。
      然し、Wiki のページに跳ぶのも面倒である。それにリンクが沢山あるのも変な感
      じがする。或いは、リンクは Wiki のページだけに向かわせる事にする。パッケー
      ジ名は単なる文字列とする。それが良い気がする。

    2021-05-23 oc1024 に間違いを指摘された。修正する。

2021-05-11

  * bind: 無引数 ble-bind で現在の binding を表示。現在の binding の着色 [#D1547]

  * complete: ble-sabbrev の出力の着色 [#D1546]

  * edit: やはり \C-x\C-v で ble.sh の version を表示したい気がする [#D1545]

    ble.sh, version 0.4.0-devel3+c89aa23 (noarch)

    Issue template での要求項目も簡単になる。現状だとユーザーに長いコマンドを入
    力させている。

  * 2019-02-09 うーん。git や bash-it の様に ble.sh でも ble コマンドの様な物を提供するべき? [#D1544]
    cf #D1543

    % と思ったが既に何処かには ble という名前のコマンドが存在していて、
    % これらは Bluetooth のサービスの開始・終了などを実行するのに使われている様子である。
    % もしこれらが広範に用いられている物なのだとしたら使いにくい。
    %
    % また、ble の名前の由来である zle コマンドの事を考えると、
    % ble widget の様な使い方を想像してしまうのではないかとの問題もある。
    %
    % 混乱を防ぐためには ble ではなくて ble.sh または blesh の様な名前が良いだろう。
    % しかしそうすると現状の ble-import だとかの機能を呼び出すのに余り適していない気がする。
    % つまり、blesh import ... で ble-import が呼び出されるというのは分かりにくい。
    % 或いは現状の ble-import を blesh-import に改名するという手もあるかもしれないが、
    % そういう事を考え始めると全ての関数を ble から blesh に改名したくなる。
    % それは面倒だし、元の zle という名前から離れていくので余りやりたくない。
    %
    % 実のところ、現状のまま ble-* の方が自動的に補完が効くので嬉しい。
    %
    % bash.env は bash.env という名前のコマンドを提供する様である。
    % https://github.com/midwire/bash.env
    % そういう事であれば ble.sh でも ble.sh という名前の関数を提供すれば良い気がする。
    % しかし ble.sh が入力しやすいのかというと微妙ではある。
    %
    % bash-it の場合には bash-it-update だとか bash-it::update だとかだと
    % 格好が悪いので bash-it update という形の関数名になるというのは分かる。

    結局 ble という名前で定義する事にした。既に同名のコマンドが存在している場合
    には、引数を認識できない時に限り元のコマンドを呼び出す事にした。

  * main: BLE_ONLOAD [#D1543]
    https://github.com/akinomyoga/ble.sh/issues/107

    shournal という plugin の作者が PS0, PS1 を使ってコマンド開始・終了を検出し
    ようとしている。それはそれで良いのであるが、ble.sh は PREEXEC, POSTEXEC と
    いう物を用意している。考えてみれば他の枠組みで使ってもらう為には、ble.sh の
    ロードの順序に関係なく PREEXEC, POSTEXEC が存在すればそれに attach できる様
    に記述したい。

    % ble.sh がロードされた時に呼び出す配列も用意した方が良いのではないか。
    % ble.sh がロードされた段階では blehook コマンドは使えないし、blehook の内
    % 部形式を上書きしようにも _blehook_h_... だとか様々な配列があって直感的で
    % ない。ロードした時に関しては特別に BLE_ONLOAD 的な配列を用意しても良いの
    % ではないだろうか。

    という事を考えると ble.sh が後からロードされた時の為に

      BLE_ONLOAD

    という配列を用意して其処に初期化用のコードを登録させるというのが手である。

    然し、ble.sh をロードしているからと言って attach しているとは限らない。
    plugin が動作を切り替えるのに使える関数を用意するべきなのではないか。現在
    ble.sh がロードされていてかつ attach していて更にユーザーコマンドの実行中で
    ない時という判定をする必要があるのではないか。

    取り敢えず zle を真似て ble という関数で現在の状態を検出できる様にしようと
    したが…。ble.sh がロードされていない状況にも対応する為には結局変数に頼るべ
    きなのではないか。実のところ特に ${_ble_attached-} をチェックすれば良いので
    はないかという気がする。問題は _ble_attached は明らかに内部変数といった形に
    なっていて公開に躊躇するという事。

    a _ble_attached を BLE_ATTACHED に改名する?

      値を設定している箇所は ble.pp 内部の5箇所のみである。なのでこの部分の変更
      はそんなに大変ではない。然し参照している物の内には fzf-marks も含まれてい
      る。うーん。

    b _ble_attached と共に BLE_ATTACHED も使える様にする?

      変更している箇所が 5 箇所なので連動して変更するのは簡単である。

      また、bash-4.3 以降では nameref を使える。唯、nameref 属性を追加する為に
      は -g が必要である。と思ったが -g は 4.2 から使えるので問題はない。

      そうは言っても version 毎に連動して変更するコードを実行するしないというの
      を切り替えるのも面倒なので、やはり常に明示的に連動して変更する様に書く方
      が楽である。

    * done: BLE_ATTACHED を公開変数にする。

    * done: ble コマンドで現在内部にいるかどうかを判定できる様にする?
      [[ $_ble_attach && ! $_ble_edit_exec_inside_userspace ]]

      0neGal が ble という名前のコマンドを作っていた。勝手に他の人がコマンドを
      作成する前に ble コマンドを予約しておくのが良い気がする。然し、他のコマン
      ドと被った時の為に本当の関数名は別にしておく? だとすると何が良いだろうか。
      調べると blesh というのも既に Bluetooth Low Energy の CLI ツールとして存
      在はしている様である。然しだからと言って blectl だと更に Bluetooth Low
      Energy の制御に使うコマンドの様である。ble-cli だとか blecli も同様である。
      或いはユーザーから直接使って貰う可能性は考えずに ble/dispatch にするとい
      う考えもある。然し、ユーザーに使われる事を想定しないのであれば、抑々別名
      として退避する意味もよく分からない。

      名前に関しては 2019-02 に既に議論が存在している。ble.sh という名前の関数
      を定義するという手についても示唆されている。bash.env や bash-it はそのま
      まプロジェクト名がコマンド名になっている。然し、ble.sh は既に沢山の関数を
      ble... としているのでやはり ble が最適である様に思われる。

      うーん。やはり ble -> ble/dispatch という事にする。と思ったが面倒なのでも
      ういきなり ble を定義している。後で問題になった時に処理すれば良い。と思っ
      たがやはり ble/dispatch を定義した。

    * done: blehook ATTACH, DETACH 対応した。

  * PS0 の中での \# の展開結果が異なるという話 (reported by tycho-kirchner) [#D1542]
    https://github.com/akinomyoga/ble.sh/issues/107

    これはそもそも ble.sh ではコマンドの受付と実行を分離しているからである。こ
    の様に疎結合にしたのに逆にその場で実行する様に書き換えるのは設計として許容
    できない。それに実際にその様に実装しようとすると色々と複雑になってしまう。
    なので、現在の枠組みの範囲内でそれを再現する様に実装しなければならない。

    もう一つの問題は ble.sh では同時に複数のコマンドを実行する可能性があるとい
    う事。そして、PS0 は各コマンド実行の直前に実行する物であって、PS1 はプロン
    プト表示の前に実行する物であるという事。という事を考えると、

      [PS0]
      COMMAND1
      [PS0]
      COMMAND2
      [PS1]
      PROMPT

    という形になる可能性もあるのである。

    [修正]

    * fixed: うーん。時々 Cygwin でプロンプトが表示されてからコマンドが実行され
      たりする原因が分かった気がする。これは queue に何かあるのにも拘らず直ぐに
      ユーザー入力が来て、それによって再度プロンプトが表示されて、その上でコマ
      ンドを実行するから起こることである。

      今となっては複数行入力の検出や bracketed paste mode など色々とユーザーの
      誤貼り付けに対する対策が整ってきているので、この様な遅延の対策は不要であ
      る。という事を考えると、queue に何かある時にはコマンドを実行する様に変更
      するというので良い。


    * OK: ble-edit/exec:gexec/process は誰も使っていない気がする。これは削除で
      良いのではないか。と思ったら勘違いだった。ちゃんと呼び出されている。

    x fixed: 改行が含まれる空コマンドの時に ble.sh は実行している気がする。但し、
      履歴には登録していない。少なくとも CMD が一個増えてしまっている。何が起こっ
      ているのだろうか。

      →空かどうかのチェックで空白とタブしか判定していなかった。一方で history
      に登録されていなかったのはまた別のフィルタが働いていたという事だろう。

      ? 履歴展開の展開結果が空の時には何が起こるのだろうか。と思ったが有限の文
        字列から空の履歴展開になる事もない様な気がする。いや !:5 等としたら空に
        なるのだろう→と思ったら bad word specifier というエラーになる。やはり
        空に展開する事はないという事なのだろうか。

        普通に history -s '' としたら空の履歴を登録する事ができて、!履歴番号で
        空に展開させる事ができる。空に展開される時にはコマンド実行としては取り
        扱われないが、改行はカウントされる。但しカウントされる改行は展開後では
        なくて展開前の行数になっている様子である。

    x done: 改行が含まれるコマンドの時に LINENO を増加させる。

    * done: \# 及び LINENO の振る舞いについて調べる

      \# は LINENO ではなくて _ble_edit_CMD を使わなければならない。というか、
      LINENO 等の振る舞いに関しても bash の PS0, PS1 の振る舞いに従わなければな
      らないのだろうか。両者の振る舞いについて確認する事にする。

      うーん。どうやら LINENO の方がペアを特定するのには便利な気がするが何故
      CMD の方を使っているのだろうか。

      ? どの様な時に LINENO と CMD がずれるのだろうか。normal bash で確かめてみ
        ると、どうやら不完全なコマンドを入力して "> " (PS2) で続きを入力した時
        にずれる様である。

        他に LINENO はコマンドを実行せずに Enter を押した時にも増えるし、一まと
        まりのコマンドの中に改行が含まれている時にも改行の数だけ余分に増える。

        C-c でコマンドをキャンセルした時にも増える様である。これについては
        ble.sh で試したらちゃんとその様になっていたので気にしなくて良い。

      ? Bash で \# に対応する変数はないのか。もしあるのであれば同様の名前で提供
        するべきなのではないだろうか。

        何処で \# の処理がされているのかと思ったが parse.y:6162
        (decode_prompt_string) の中にあった。current_command_number という変数
        を参照している。そしてこれは eval.c の中で incr されている。そも他の箇
        所では全く使われていないので、これは別に Bash の内部の値を取り出そうな
        どとはしなくて良い。

    * fixed: \# の振る舞いを PS0 の評価後に変化する様に変える

      % 取り敢えず \# はコマンドを登録する時に番号を保存する様にする。もし保存
      % されていたら其処で振る舞いを書き換える事にする。

      _ble_edit_CMD の increment を内部に移動する事にする? この変数は \# を通し
      てしか定義されない物の様なので他の場所で影響が出てくる事はない様に思われ
      る。なので PS0 の直後で increment する様に変更してしまって問題ない気がす
      る。

    * Note: どうやら normal bash でも PS0,PS0,PS1 という感じの組み合わせになる
      事がある様である。C-v C-j として改行を挟んで独立したコマンドを複数入力し
      た場合になる。この時には LINENO は PS0 前に inc されて CMD は PS0 直後に
      inc されている様に見える。PS0 に関してはこの振る舞いに倣うのが適切だろう。

    元々の報告では PS0 と PS1 が必ず pair になる事を期待しているのだろうか。そ
    もそも PS0 はコマンド開始前に出力する物で、PS1 はプロンプト表示前に出力する
    物なので必ずしも組になっているとは限らない。

    組になっている事を期待するのであれば PREEXEC 及び POSTEXEC を利用するべきな
    のである。但し、shournal が単に計測対象開始として PS0 を使って、計測対象終
    了として PS1 を使っているというだけなのであれば、PS0 が重複していても特に問
    題は生じないのである。

    もし PREEXEC, POSTEXEC を使うというのであれば ble.sh が後からロードされた時
    にもちゃんと有効化される様に記述する必要がある。。

2021-05-10

  * syntax: PS0 から stderr に出力できないという報告を受けた (reported by tycho-kirchner) [#D1541]
    https://github.com/akinomyoga/ble.sh/issues/107

    一体何をしたいのか謎だがまあ元の bash で動く以上はその動作を利用する設定も
    あるだろう。元々その様に実装していたのは set -x の出力を防ぐ為だったが、よ
    く見たら PS0 の出力は restore-bash-options の前だったのでこの段階では 2 を
    端末に出力しても OK.

  * 2021-03-21 gitstatus.plugin.sh の alias builtin で builtin eval 他が破壊されている [#D1540]
    https://github.com/akinomyoga/ble.sh/issues/93
    https://github.com/romkatv/gitstatus/pull/235

    * 取り敢えず暫定的な対策として source ble.sh の時に unalias builtin 等を実
      行する事にした。

    * 他に source ble.sh した後に gitstatus.plugin.sh が実行されて、更にその後
      になって ble-attach した時の事も考える必要がある。

    gitstatus.plugin.sh の側で対策できないのか。
    34e21707

    https://github.com/romkatv/gitstatus/issues/154
    ここで本人が builtin を置き換えるのは良くない事だという事を述べている。

    > It's generally not a good idea to redefine builtins. If you also redefine
    > things like true, local, unset, etc., gitstatus won't work. Please don't
    > file a bug in this case but rather fix your config.

    eval ... pos parameters
    source ... pos parameters
    source ... function scope or not (declare var の振る舞い)
    unset ... previous-scope dynamic-unset or value-unset
    exec ... persistent redirections
      これは実際に問題になるという事を確認した。

    これは報告したらもっと別の方法で exec bash を検出する方法について議論が始まっ
    た。幾つか結構怪しい方法も含めて紹介した。その内の一つの方針で実装してテス
    トしてみるそうである。

    これも返信が来て色々議論して alias を全く使わない様に向こうが修正してくれた。
    しかも後で気づいたのだが gitstatus の作者はあの powerlevel10k の作者でもあっ
    た。powerlevel10k は ble.sh と同じく zsh ではあるがシェルで色々と複雑な処理
    をゼロから真面目に実装している奴である。

  * highlight: 1>&a.txt のファイル名着色 [#D1539]

    着色だけでなく補完にも一緒に対応する。

    x fixed: 実装してみたが動かない→2箇所 RDRD2 になっていた。CTX_RDRD2 に直す。

    x fixed: 3<&- や 3<&4- 等の redirection に対してエラー着色になっている。

    x fixed: 1>& 1 に対して補完が効かない→check-prefix に登録していなかった。

    x fixed: 1>& に対して補完が効かない。ファイル名だけが生成される。check-here
      でもしかすると別の ctx になっている?  →調べたらそもそも ARGX になってい
      て其処から RDRD2 等に変わっていないので ARGX だと思って補完が開始されてい
      るのが原因である。何が問題かというと、次の単語がない時に redirection で
      stat を設置していないのが行けない。然し、そもそも RDRD2 等は単語の種類で
      あって解析の状態ではないのではないか? と思ったが別にそういう訳でもないら
      しい。ちゃんと RDRD2 という ctx になって解析されている。

      ここで問題になるのは RDRD2X 的な文脈が存在しないという事にある気がする。

      a 或いは一文字も入力されていなくても勝手に RDRD2 を開始してしまうべきなの
        だろうか。と思ったが RDRF, etc は nest の中にいるという事を前提とした実
        装になっているので、そのまま ctx を設定する訳には行かない。然し、そうは
        言っても空の nest を生成する事もできない。

      b 或いは stat か何処かの配列に次に来るべき者についての情報を記録するとい
        う事にする? 他の所ではその様な事をしていないのに此処だけでその様に処理
        するのも変である。

      c というかそもそも check-prefix で ARGX の時に redirection を検出するべき
        なのではないだろうか。

      最終的に c が正しい実装である。そもそも check-here は fallback 的な位置づ
      けであり此処に来た時点で実は変な補完になってしまう事は運命づけられている。

    * 他に << 及び <<- の後の補完も定義されていなかったのを定義した。適当に
      EOF:END:HERE 等としたがもっと別の物を追加するべきかもしれないし、あるいは
      ユーザーが設定できる様にするべきかもしれない。

    * 全般に fd の補完もできる様にした。

  * MSYS2 patch .inputrc [#D1538]
    https://github.com/akinomyoga/ble.sh/issues/104
    https://sourceforge.net/p/msys2/mailman/msys2-users/thread/CAFLRLk-UX7S%3DTAerNix7HvxDAv4aY2FwZuFZz%3DU%2BTLBAWxCLEg%40mail.gmail.com/#msg37275646
    https://github.com/msys2/MSYS2-packages/pull/2490
    https://github.com/git-for-windows/build-extra/pull/341

    Ref #D1534

    特に問題の行は削除するべきであると考えているが返信は未だない。
    強い口調で書き過ぎたから無視されているのかも知れないし、
    単にこの mailing list には誰もいないという事なのかもしれない。
    archive を遡ってもこの mailing list は活発であるとは言い難い。

    GitHub にソースを見つけたので PR を出してみた。
    こちらも直ぐには返事が来ない。
    一応ちゃんと変更の要求は取り込まれた。

    https://github.com/msys2/MSYS2-packages/pull/2490

    然し本当に git bash の msys と msys2 は一緒なのだろうか…。MSYS2 をインストー
    ルして、それから Git Bash もインストールしてみる。Git Bash の方は個人のディ
    レクトリには .inputrc はなくて、/etc/inputrc が読み取られている様である (実
    際に /etc/inputrc を編集して影響を与えている事を確認した)。そして、実は
    /etc/inputrc の内容と MSYS2 の .inputrc の内容は異なるという事も確認できた。

    ? ok: MSYS2 の /etc/inputrc はどうなっているのだったか→MSYS2 では
      /etc/inputrc は存在していない。なので、今回の変更だけで大丈夫のはず。

    ? ok: Cygwin の方にも inputrc があるのではないか→調べたら
      /etc/skel/.inputrc があったが、これはちゃんと変な binding は削除されてい
      た。検索した感じだとそもそもこの壊れた binding は cygwin の inputrc から
      来ていた様な気がする (違ったかもしれないが面倒なのでもう確認しない) ので、
      Cygwin の側では誰かが何処かの時点で気づいて削除したという事だろうか。

    ? done: Git Bash の /etc/inputrc にも変更要求を出さなければならない

      https://github.com/git-for-windows/git-sdk-64/blob/main/etc/inputrc
      https://github.com/git-for-windows/git-sdk-64/blob/main/etc/skel/.inputrc
      https://github.com/git-for-windows/git-sdk-32/blob/main/etc/inputrc
      https://github.com/git-for-windows/git-sdk-32/blob/main/etc/skel/.inputrc

      以上にファイルを見つけたがどうも違う様な気がする。これらのリポジトリのコ
      ミットを見ると自動的にアップデートされている。なので、これは別の場所に
      upstream があるという事を示唆しているのではないか。然し検索してみても関連
      する物は見つからない。

      https://github.com/search?q=org%3Agit-for-windows+%22msys2+mailing+list%22&type=code

      /etc/skel/.inputrc は MSYS2 から継承されるのだと考えたとしても、では
      /etc/inputrc は何処から来ているのだろうか。謎である。うーん。もしかして
      msys1 が起源になっている? というか Git Bash の MSYS は MSYS2 ではなくて
      MSYS1 なのだろうか。MSYS の version は何処でチェックできるのだろうか。

      改めて色々読んでいると build-extra も言及されている。適当にディレクトリを
      覗いたら inputrc があった。どうも GitHub の検索はファイル名本体には全く一
      致しないようだ。

      https://github.com/git-for-windows/build-extra/blob/main/git-extra/inputrc

      https://github.com/git-for-windows/git/issues/62 では PR は OK と言ってい
      るが何処に出したら良いのかについては何も言及していない。msysgit という物
      も存在する様だ…そちらにも PR を出す必要があるだろうか、と思って確認した
      ら msysgit は Git for Windows の前身であり同じ人が管理していて既に
      archive されていた。

    ? ok: MSYS-1.0 にも出した方が良いだろうかと思って活動を確認したが Mailing
      list は 2013 から動いていないし、最新版も 1.0.12 の 2016 年なので、此処で
      修正しても仕方がないと判断する。そもそも、ble.sh の側でも対策を入れたので
      実質的に問題は発生しない筈。

2021-05-08

  * decode: 初期化時にエラー (reported by RakibFiha) [#D1537]
    https://github.com/akinomyoga/ble.sh/issues/106

    一番最近の commit を観察したが特に怪しい所はない様に思われる。

    キャッシュが壊れている可能性? 然し、キャッシュをクリアしてしまうと問題が再
    現しなくなる可能性があるので後回し。
    もし ble-update を実行する過程でキャッシュが壊れるのだとしたらどれかの
    version から最新版に更新した時に問題が再現するかもしれない。そう思って
    026432d 9125795 79d671d 0506df2 032f6b2 からのアップデートを試したが再現は
    しなかった。

    どの commit で問題が起こる様になったのだろうか。改めて怪しい変更がないか
    commit を眺めて見る。試しに bind '"hello":"world"' としたら再現した。改めて
    decode-char の呼び出し部分を確認する。もしかするとここを "${chars[*]}" にし
    ていたり変数に代入したりする過程でその様に加工してしまっているかもしれない。
    と思ったら、本当に "${chars[*]}" にしてしまっていた。一文字の修正である。

2021-05-07

  * bind: fix a problem that "bind '"seq":"key"'" causes a loop macro "bind -s key key" (reported by thanosz) [#D1536]
    https://github.com/akinomyoga/ble.sh/issues/105

    これはどうやら OpenSUSE の inputrc にある、テンキーの / のエスケープシーケ
    ンスを / に翻訳する keybinding の問題だった。ble.sh は左辺をキー列に翻訳し
    てから bind する。という事なので、

      "escape-sequence": "key"

    の様な binding が存在すると、key: "key" という形に翻訳されてしまう。そうす
    ると無限ループに変換されてしまうという事である。

    これの対策は単に左辺と右辺が一致している時に binding を無視するというだけで
    良いのだろうか。或いは、それだけでは駄目なケースが存在するだろうか。例えば、

      "escape-sequence-long": "escape-sequence-short"

    という形になっていたとすると、

      key: escape-sequence-short

    という形になってしまって結局無限ループになってしまうのではないだろうか。現
    在の実装について改めて確認する→やはり左辺が keys で右辺が chars になってい
    るので単純に keys と chars を比較するのでは駄目である。結局 chars を keys
    に翻訳してから比較する事にした。実装した。テストした。動いている。OK

2021-05-06

  * progcomp: aws_completer が呼び出されない (reported by Archehandoro) [#D1535]
    https://github.com/akinomyoga/ble.sh/issues/102

    これは原因は分かった。complete -p の出力結果が quote されているのに、ble.sh
    はそれを直接解釈しようとしているのが原因であった。"'aws_completer'" という
    名前のコマンドを実行しようとして失敗している。

    そもそもこれは complete -p の出力結果が quote されていたりされていなかった
    りするのが原因である。version 毎にどうなっているか確かめてみる事にする。

    * コマンド名: コマンド名に関しては現在に至るまで一切 quote されない。

    * -C の引数について: bash-3.2 までは裸で引数が出力されるだけであった。

    * -F の引数も一切 quote されない。と思ったら bash-5.1 以降で -F を設定する
      時にチェックが入る様になった。然し、それでもブレース展開や履歴展開、変数
      展開も含める事ができるのでそのまま eval する訳には行かない。

    * -WGXPS の引数: 常に quote される

    * 引数が出力される順番は固定の様である。問題の -F func -C callback cmd はこ
      の順序で必ず最後に出力される。と思ったが、bash-4.0 以降では -C c -F f cmd
      の順序に変更になった。

    まとめると、

    * bash-3.2まで: complete [OPTIONS] -F str -C str    cmd
    * bash-4.0以降: complete [OPTIONS] -C 'str' -F str  cmd
    * bash-5.1以降: complete [OPTIONS] -C 'str' -F func cmd
      5.1 で安全になったかと思いきや func に !${} を含められるので駄目。

    うーん。コマンド名に関しては末尾から削除すれば良い。quote をちゃんと辿って
    行けば -F が現れた時点でこれは確実に本物の -F である。更に -F の引数に関数
    名として不正な物を指定する理由もないので、-F の直後は一つの単語だけ読み取れ
    ば良い。すると残るのは (もしあれば) -C callback 名という事になる。

    どの様に実装するか。結局どの bash version であっても -F func が quote され
    ないので eval するのは危ない。そもそも callback を設定する時点でその補完が
    呼び出された時点で駄目な訳だけれども、取り敢えず滅茶苦茶な事が起こらない様
    にする為には真面目に parse するのが良い。

    a 後ろから parse するのは問題ないだろうか? ... これは危険である。例えば -F
      が見つかったとしてもこれが本当に -F なのかは分からない。偽物の -F で、実
      は其処よりも前にも quote されていない引数が潜んでいる可能性がある。

    うーん。手順としては先ず初めに末尾にコマンド名が一致していればそれを除去す
    る (一致していなかった場合はどうするのかは謎)。次に正規表現で読める所まで読
    んで、それを eval する? 読みきれなかった部分については変数に残して置く。読
    めた部分を解析する。途中で -F に行き当たったら残りの文字列を特定して、続き
    は真面目に parse する事によって結果を得る? というか残りについては " -C " が
    含まれているかいないかで取り扱いを変更すれば良い気がする。然し、何らかのオ
    プションが -F の後に続いているという事もあるかもしれない。

    取り敢えず実装した。動いている。もう一つの問題として aws の補完結果は末尾に
    空白を含めているのにも関わらず noquote 等の処置をしていないという事。うーん。
    これに関しては…。仕方がないので aws_completer 用の WA とする事にした。また、
    コマンド名なのに偶然でディレクトリ名に一致して suffix がついてしまう事につ
    いても workaround とした。但し、考えて見るに -F もしくは -C で生成した候補
    に対して suffix を付けるのも変な気がする。これについては改めて考えても良い
    のかもしれない。

  * MSYS2 で Backspace で行全体が削除されるという話 (reported by n1kk) [#D1534]
    https://github.com/akinomyoga/ble.sh/issues/104
    https://sourceforge.net/p/msys2/mailman/msys2-users/thread/CAFLRLk-UX7S%3DTAerNix7HvxDAv4aY2FwZuFZz%3DU%2BTLBAWxCLEg%40mail.gmail.com/#msg37275646

    取り敢えず MSYS2 の .inputrc が怪しいという事で msys2-users に報告した。そ
    れとは別に ble.sh の側でも対策する事は可能だろうか。

    a 例えば MSYS2 にいる時には .inputrc は読み取らない (--noinputrc) 様にする?
      然し .inputrc だけ読み取らない様にしても仕方がない。ユーザー設定も読み取
      らない様にしないと bind で自動的に読み込まれた設定を読み取ってしまう事に
      なる。

    b INPUTRC=/dev/null を設定してから bind で初期化する事により bashrc で設定
      されたユーザー設定だけを読み取るという手もある気がするが、これも source
      ble.sh よりも先に bind 関連の設定にユーザーが触れていると駄目である。

    c 上記の問題は inputrc にある他の設定も全て潰してしまうという事である。それ
      ならば、C-? に対応する設定だけ ble.sh default に強制的に設定する様にすれ
      ば良いのではないだろうか。

    取り敢えず c の方針で実装する事にした。この様にしたとしても C-x C-r で
    inputrc を再読込するとまた変な状態になってしまうが、これは仕方がない。

  * complete: bash-completion bug workarounds (reported by oc1024) [#D1533]
    https://github.com/akinomyoga/ble.sh/issues/97

    自分の手許でも色々エラーメッセージが出てうるさい。

    bash-completion で修正を掛けるのは面倒だし時間がかかりそう。更に、各種
    distribution に波及する迄に更に時間もかかりそうなので取り敢えず暫定的に、
    ble.sh の側で bash-completion の実装を上書きする事にしてしまう。

    * 2021-05-06 bash-completion
      https://github.com/akinomyoga/ble.sh/issues/97
      https://github.com/scop/bash-completion/pull/492
      Ref #D1533

      python のテストを自分で実装したりしなければならず面倒である。
      実装した。PR を update した。これは向こうの反応待ち状態である。

  * 2021-04-06 localvar_inherit で動かなくなっている  [#D1532]

    或いは元から動いた事はなかった可能性も?

    * localvar_inherit をしていると local -r a した変数に対して、
      内側の関数で同名の変数を定義できなくなってしまう。

    うーん。それでも未だ色々動かない。というか、バグというかちゃんと書
    かれていないコードを洗い出すのに使えるかもしれないとは思う。

    * どうやら localvar_inherit になっていると local BASH_COMMAND としても
      BASH_COMMAND の値が変化する性質は受け継がれてしまう様である。

      | RANDOM でも同様の現象が発生している。
      |
      | $ f1() { local RANDOM=hello; echo $RANDOM; RANDOM=world; echo $RANDOM; }
      | $ shopt -u localvar_inherit; f1
      | hello
      | world
      | $ shopt -s localvar_inherit; f1
      | 20034
      | 20034
      |
      | 何が起こっているのだろう。元の変数がそのまま見えているという事だろうか。
      | と思ったがそうでもない。unset RANDOM して見たが元の変数が消えるという事は
      | なかった。恐らく localvar_inherit の時には値が受け継がれるのではなくて、
      | setter/getter が引き継がれてしまっているのが原因なのだろうと思われる。
      |
      | bash を確認すると subst.c (expand_declaration_argument) では
      | localvar_inherit が設定されている時には declare は declare -I と同様の振
      | る舞いになる。 declare -I の説明を declare --help で確認すると値と属性を
      | 継承すると書かれている。
      |
      |   if creating a local variable, inherit the attributes and value of a
      |   variable with the same name at a previous scope
      |
      | と思ったが実装をよく見ても inheriting の値が一切使われていない気がする。
      | 不思議である。未実装なのだろうか。或いは何かを見落としている? どうもこの
      | 関数は arr=() の形式の引数を処理する時にだけ使われているという事だろうか。
      |
      | 実際に localvar_inherit の処理を具体的に処理しているのは variables.c の方
      | である様に思われる。特に以下の部分 (variables.c:2738) が setter/getter を
      | 継承するコードである。
      |
      |   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;
      |     }
      |
      | 明示的にコピーしているという事を考えるとこれを覆すのは難しいかも知れない。
      | 具体的に変な振る舞いをする例を作ってそれを呈示すれば何か考えて貰えるかも
      | しれない。getter/setter が関わっている関数は他にあるだろうか。
      |
      | INIT_DYNAMIC_VAR で検索するとそういった関数の一覧が得られる。
      |
      | - "SECONDS", (v ? value_cell (v) : (char *)NULL), get_seconds, assign_seconds
      | - "FUNCNAME", (char *)NULL, get_funcname, null_assign
      | - "BASH_ARGV0", (char *)NULL, get_bash_argv0, assign_bash_argv0
      | - "BASH_COMMAND", (char *)NULL, get_bash_command, (sh_var_assign_func_t *)NULL
      | - "BASH_SUBSHELL", (char *)NULL, get_subshell, assign_subshell
      | - "RANDOM", (char *)NULL, get_random, assign_random
      | - "SRANDOM", (char *)NULL, get_urandom, (sh_var_assign_func_t *)NULL
      | - "LINENO", (char *)NULL, get_lineno, assign_lineno
      | - "BASHPID", (char *)NULL, get_bashpid, null_assign
      | - "EPOCHSECONDS", (char *)NULL, get_epochseconds, null_assign
      | - "EPOCHREALTIME", (char *)NULL, get_epochrealtime, null_assign
      | - "HISTCMD", (char *)NULL, get_histcmd, (sh_var_assign_func_t *)NULL
      | - "COMP_WORDBREAKS", (char *)NULL, get_comp_wordbreaks, assign_comp_wordbreaks
      |
      | TERM の場合はどうなっているのだろうか。これは special_vars という事になっ
      | ていて、値が変更した時に特別の関数が呼び出される様になっている。他に
      | TERM* や LANG, LC_* 等様々な変数がこれに相当する。これらは local に関係なく
      | 常に値が変更したら何か処理する事になっているので今回の振る舞いには関係ない。
      |
      | やはり勝手に上書きするのが悪いという結論になりそうな変数しか存在しない。
      | 敢えて言うならば RANDOM か LINENO ばかりだろうか。LINENO の方も確認したが、
      | やはり LINENO に対する代入は無視されて現在の行数が常に表示される様になっ
      | ている。因みに LINENO=1234 eval 'echo $LINENO' に関しては
      | localvar_inherit を設定しても特に変わりなく同名の tempvar が作成される。

      bash のバグか或いは confusing behavior かどうかは別として、古い version
      に対しては取り敢えず修正しなければならないので、対策は行う事にする。時間
      があれば bash に報告・相談もする事にする。

    * もう一つの問題は local -a buff とした後に ble/array#push としていると、前
      の配列の内容が既にあった場合にそれの続きとして値を push してしまうという
      事。こう言った使い方をしている箇所はないと思っていたが、確かめてみると古
      いコードを中心にして沢山あった。と思ったがそんなには無かった。合計で4箇所
      だけだった。

    上記の事を直したら取り敢えず動いている様に見える。残りは具体的に問題が生じ
    てから対処する事にする。

  * 2021-04-28 keymap 初期化に失敗した時にそれを検出しているのにも拘らず操作不能になる [#D1531]

    $_ble_base_cache/keymap.emacs が空の時、The keymap 'emacs' is empty 等の様
    にメッセージが表示されて空かどうかのチェックが為されている筈なのに、その後
    に何も操作できなくなる。

    ble/decode/attach の中でチェックが起こっている気がするが、その場合には
    attach せずに終わって操作不能にはならない筈なので関係ないかもしれない。

    今試しに keymap.emacs を空にして bash --norc から ble.sh をロードしてみたが、
    stty の状態が変になる物の操作不能になる訳ではない。set -o vi でスタートさせ
    てset -o emacs で切り替えようとすると問題が再現する。つまり、detach して
    attach した時の問題である。

    調べてみるとどうもコマンドは実行されている様である。stdout.off の状態になっ
    ている事によって操作できなくなってしまっているという事の様である。そしてそ
    れは、ble/decode/attach の呼び出し元の .check-detach の更に呼び出し元におい
    て、bind/.tail 経由で改めて stdout.off が実行されているという事になる。これ
    を抑制する為に、.check-detach の中で rebind に失敗した時には改めて
    .check-detach を呼び出して抜ける処理を実行する事にした。

    →然しそれでもやはり stdout.off が呼び出されてしまう。と思ったが、どうも
    .check-detach の戻り値を使って実際に detach が起こったかどうかを伝達してい
    る様である。ちゃんと再帰的に呼び出した .check-detach の終了ステータスを外に
    伝播させる。これで問題なく抜ける様になった。

  * 2021-04-06 main (--rcfile): 通常ファイルしか許可していないが [#D1530]

    <() や /dev/null を食わせたい事もあるだろう。後、ファイルが見つからなかった
    時に結局 ~/.blerc を読み取ってしまうのは不便。ファイルが見つからなかった場
    合には何も読み込むべきではない。

    --norc オプションにも対応した。

  * syntax: eval() { echo yes; } が構文エラーになっている [#D1529]
    local, declare も同じ。

    これは意外と簡単だった。処理順序を変えるだけで良かった。builtin の処理と
    keyword の処理が結合しているから切り離すのに時間がかかるのではないかと思っ
    たが、実際には builtin の処理は独立にしても問題ない様な実装になっていた。

  * main: freeze-utility-path が一時実装を置き換えなくなっている [#D1528]

    ble/bin/sleep を初期化する前に sleep の機能についてテストしている気がする?
    と思ったが最初に ble/bin/sleep を絶対パスではなくて command sleep で定義し
    ているので問題は起こらないのだった。というより、最近 freeze-utility-path で
    既存の関数がある時には上書きをしない様に変更したが、これは駄目だ。元々上書
    きする様になっていたのはこの一時的な実装を置き換える為であったのである。

    然し、上書きする様に変更してしまうと freeze-utility が ble/bin/awk を上書きしてしまう。

    a そうすると一時的な実装とそうでない実装を区別できる様に、関数か変数をマー
      カーに使う?

    b 或いは初めからもう定義してしまって呼び出した時点でパスを決定する事にする。
      初期化の順序によっては fork コストがかかる可能性もあるが、
      それも少しだけなので余り気にしなくても良いかもしれない。

      問題は ble/util/assign がちゃんと動作する迄に時間がかかるという事だから、
      ble/util/assign が準備できたかどうかを変数に記録しておけば良いのでは。

    c 或いは ble/util/assign が準備できた時点で .freze-utility を改めて呼び出す
      事にする。直接呼び出しても良いし、それだと密結合になるというのであれば、
      hook か何かを準備しても良い。

    d 或いは今まで通り freeze-utility は上書きをしてしまう様にする。awk に関し
      ては上書きしない様にリストから削除しておくか (然し削除の為にまたコードを
      書かなければならない。初期化時点では ble/array#remove もない)、或いは
      ble/bin/awk.protected か何かの様にして上書きをしない様に関数を定義する。

    うーん。大きく変更するのも面倒なので ble/bin/awk.protected を定義するという
    方針にする。と思ったが関数が存在するかどうかのテストはやはり util.sh を待た
    なければならない。

    ? ok: alias が定義されている時に freeze-utility は正しく動作するだろうか?
      →これは大丈夫。type -P としているから。

2021-05-04

  * util: bleopt/check-all で obsolete な設定も読み取ろうとしてエラーになっている [#D1527]
    obsolete なオプションに対しては初期設定のチェックは行わなくて良い。

  * syntax: 着色決定時に expand_aliases 設定が退避されている (reported by 3ximus) [#D1526]
    https://github.com/akinomyoga/ble.sh/issues/103

    0860be0 に於いて内部では alias が展開されない様に shopt -u expand_aliases
    を設定していた。然し、よく考えてみたら構文着色等に於いて expand_aliases が
    有効かどうかによって処理を変えていた。つまり expand alias の処理の際にちゃ
    んと退避した設定を確認する必要がある。

    実際に修正しようとしたら話はそう単純ではない様である。そもそも自分で shopt
    -s/-u expand_aliases を変更しようとしても完全に無視されてしまう。次のユーザー
    状態になる頃には勝手に元の値に戻ってしまっている。何故? 例えば
    POSIXLY_CORRECT を手で弄っている所為だろうか。或いは expand_aliases の保存
    復元の呼び出しタイミングが混ざっているからだろうか。それとも bind -x の中で
    変更した expand_aliases の状態は抜けると消えてしまうという事なのだろうか。

    やはり自分では何も操作していないのに expand_aliases の設定が変わってしまっ
    ている。うーん。という事は…どうすれば良いのか?

    * 内部で shopt -u expand_aliases にしたいというのは…。毎回 bind head で設
      定し直すぐらいしかできない→ bind/.head で再設定する様にした。

    * ユーザーが設定した設定が保持されないという事に関しては。これは明示的に自
      分で保存復元する必要がある。特に restore する時には shopt -u
      expand_aliases も明示的に実行する。→これは bind/.head で設定する様にした
      ので、わざわざ自分で実行しなくても良い。

    * エイリアスを展開する時に一時的に shopt -s expand_aliases 状態を復元する。
      と思ったが、それでは駄目だった。様々な所で ble/util/type を呼び出していて、
      その結果が alias にならないとそもそも expand-alias 関数自体が呼び出されな
      い。修正するべきは expand-alias ではなくて ble/util/type の方である。こち
      らを修正したら動く様になった。

  * util: test-canvas.sh ext/contra 依存性の解消 [#D1525]

    test-canvas.sh がエラーを出す様になっている。試すとテストを取り入れた時から
    既にエラーになっている。どういう事だろうか。と思ったが、テスト自体が
    ext/contra もしくは contra を前提としていた為に起こっていたエラーだった。存
    在しない時には通る様に書いたつもりだったがそうなっていなかった。

  * awk で {m,n} は使えないという事 [#D1524]
    https://unix.stackexchange.com/questions/354553/awk-repetition-n-is-not-working
    Ref #D1522

    更に nawk, mawk では十六進表記 0xHHHH も使えない。規格的には optional に対
    応しても良いという事になっている様だ。

    更に mawk は match("AAA", /AA?A?/) としても2文字しか一致しない。/A(AA?)?/
    という具合にしなければならない。

    過去の互換性の為であると言っている割に POSIXLY_CORRECT=always を指定しても
    対応するという気配はない。

    →特にこれらに引っかかりそうな箇所は今の所は見つからなかった。然し、
    今後の為にちゃんと記録しておく必要がある→ #M0019 に残す事にした。

  * nawk の方が軽いので既定で nawk を使う様に変えてみる [#D1523]
    Ref #D1522

    gawk 特有の振る舞いに依存している部分を洗い出す為にもこの変更は有用だろう。

    x nawk を使う様にして試してみた所、初期化時に "function" というメッセージが
      沢山表示される → これは nawk とは関係なくて freeze-utility で追加したコー
      ドで既存の ble/bin/??? が定義されているかどうか確かめる type の出力を
      /dev/null に繋いでいなかったのが問題であった。

    x また、use-solaris-xpg4 が他から参照されている。mshex にも
      akinomyoga.dotfiles にも use-solaris-xpg4 はない気がする。何処由来だろう
      か? →これは単に ble.pp に古いコードが残っていただけだった。

    他にも様々な問題が発生した様に思われたが全て最近行われた別の変更によるバグ
    だった。一通り修正できたので改めてテストを行う。取り敢えず動いている様な気
    はする。

  * 2021-03-15 巨大なディレクトリで TAB 補完が遅い (2) (reported by timjrd) [#D1522]
    https://github.com/akinomyoga/ble.sh/pull/65#issuecomment-798551355
    Ref #D1512

    修正したと思ったが依然として時間がかかっている。

    (1) 調べてみると、どうもconditional-sync が終わった後の
      builtin eval -- "$def"
      を実行する時に時間がかかっているという事。

      これを高速化する方法はあるだろうか。というか assign-array では駄目なのだ
      ろうか。と思ったが、ファイル名に改行が含まれている可能性などを考えると駄
      目という事?

    後気付いたのだが、ファイル名に改行が含まれている場合には何が起こるのだろう
    か。source:file はファイル名のチェックをしない様に今回書き換えたが実はこれ
    によって改行が含まれているファイル名の断片も生成される様になってはいないか。
    然し、eval-pathname-expansion で変な分割のされ方をしない限りは問題は起こら
    ないはずである。また、eval を経由して親に結果を渡す事によって、改行を含むファ
    イル名でも対応できる様になっている。

    うーん。eval の中でも時間がかかっている様に思われたが、これも eval するため
    の文字列を構築するのに時間がかかっているという事なのだろう。

    $ files=(*)
    $ time eval ': "${files[@]@Q}"'
    280ms
    $ time eval ': "${files[@]}"'
    216ms
    $ time for a in "${files[@]}"; do break; done
    235ms
    $ time echo ${#files[@]}
    0ms

    これらの結果を見るに、インデックスでアクセスする様にするべきという事か。

    $ time data=("${files[@]}")
    300ms

    a ${files[@]:offset:length} を使って切り分ける?
      →これは遅い。

      $ time : "${files[@]:0:100}"
      72ms
      $ time : "${files[@]:0:1000}"
      77ms
      $ time : "${files[@]:0:10000}"
      89ms

      うーん。これ自体にも時間がかかっている。然し、1000 単位で分割しようとする
      と 200k の場合には全て処理するのに 20s かかる。10000 単位ならば 200k ファ
      イルに対して 2s 以下で処理できるが、元から 200ms かかっていたのが 2s に増
      えるのは微妙な気がする。等の事を考えると、これにかかる時間は仕方がないと
      諦めるべきか。

      →単に ${arr[@]:xx:yy} が遅いというだけの様だ。

    b 直接要素にアクセスする。

      以下の様に直接アクセスすれば、全体を一気に置換した時と比べて遜色のない速
      度が出る。約2倍程度の速度低下で済んでいる。

      $ time for ((i=0;i<200000;i++)); do v=${files[i]}; done
      500ms
      $ time for ((i=0;i<10000;i++)); do v=${files[i]}; done
      29ms


    ? 高速な配列の初期化と言えば history.sh である。結局どの様な方法を用いてい
      たのだったか。やはり eval だったような気もする。確認する。

      うーん cygwin かそうでないかで場合分けしている。Cygwin 以外では mapfile
      を使って読み出している。改行を含む要素に関しては後で補正処理を行うという
      方法を用いている。Cygwin に於いては source している。中では恐らく直接巨大
      な配列のリテラルを指定している。

    $ time x=$(declare -p files)
    72ms

    実は declare -p 自体はそんなに低速ではない。
    現在の実装では quote を ${file[x]@Q} を用いて処理しているが、
    declare -p を用いれば多少の改善はできるかもしれない。

    $ time eval "$(time ret=(*); time declare -p ret)"
    real    0m0.326s
    real    0m0.071s
    real    0m1.345s

    $ cd /path/to/big-directory
    $ time files=(*)
    $ time def=$(declare -p files)
    $ time def=ret=${def#*=}
    $ time eval "$ret"

    具体的に timjrd に計測してもらったがやはり eval "$def" で結構な時間がかかっ
    ている様子である。特に 33k の項目に対して 0.87s かかっている。手元では 200k
    項目に対して 0.40s かかっている。(線形時間を仮定すれば自分の手元では 33k に
    対しては 0.066 で処理できるので余り気にならなかったのだろう。)

    因みに手元では配列のコピーも 0.27s かかっている。これはそんなに長くはないが、
    向こうでは 0.6s ぐらいかかるのだという事を示唆している。つまり、配列コピー
    も気安く行う事はできないのである。

    手元でより高速な方法を模索してみる事にする。

    a eval "$def" の処理時間は 200k 項目に対して 0.40s である。展開と読み取りに
      は 0.67s かかっている。total では 1.07s である。

    b printf '%s\0' "${ret[@]}" で出力した結果を mapfile -d '' で読み取る方法を
      試してみた。結果、読み取りに 0.74s かかっている。実は eval による手法より
      も時間がかかっているという事になる。展開も含めた total の時間は 1.17s で
      ある。total で考えれば手法 a とそんなに変わらないが、中断できないという事
      が問題である。

      更に mapfile -d "" は 4.4 以降でしか使えないので、4.3 以下でも使える様な
      read -d '' による方法の速度を計測してみた所、75s かかった。

      | if ((_ble_bash>=40300)); then
      |   printf '%s\0' "${ret[@]}"
      | else
      | fi
      | if ((_ble_bash>=40400)); then
      |   time ble/util/assign-array0 ret 'ble/util/conditional-sync "$sync_command" "" "" "$sync_opts"' &>/dev/null; local ext=$?
      | else
      | fi 2>/dev/tty

    c source にしたら total 時間を減少させる事ができるだろうか。

    2021-05-01 時間が空いてしまったので改めて現状を整理する。問題は subshell で
    得たファイルリストをどうやって親シェルに伝達するのかという事。500k の文字列
    配列を現実的な時間内に親シェルに伝達し、更に中断も可能である必要がある。

    例を交えて説明するとしたい事は以下の事である。現状で、eval "$(< a.tmp)" が
    遅いというのが問題である。合計時間が長いというのは未だ良いのだが問題はユー
    ザーからの interrupt があった時に中断できないという事にある。

    (
      a=({000000..500000})
      declare -p a > a.tmp
    ) &
    wait $!
    eval "$(< a.tmp)"

    declare -p a の実行自体はそんなに時間はかからない。また mapfile も比較的高
    速である。問題は declare -p a だと eval (遅い) で読み出す必要があって、
    mapfile にする為には要素を printf で出力する必要があるという事。

    a printf '%s\0' / mapfile -d '' (2.5 + 1.6)

      そうだとしても printf '%s\0' で出力して mapfile -t -d '' で読み出すのが一
      番高速でかつ中断可能の気がする。と思って試してみた所、mapfile は -d '' を
      指定した瞬間に遅くなってしまった。どういう事だろうか。最新版 bash でも同
      様である。

    b echo / mapfile -t (3.2 + 0.1)

      この方法は高速であるが代わりに改行を含む様な要素について特別な対処が必要
      である。また時間のかかっている部分での中断も容易である。

      特別な対処を実装したら合計で 3.2+0.1 になった。それでも他の方法よりは高速
      である。これが現実的な解であるような気がする。合計の処理時間は2倍以上になっ
      てしまうが。

    c declare -p a | awk ???

      declare -p を awk で処理する事を考えたが awk には行に含まれる文字数の上限
      があるのではなかったか。本当にそれを正しく処理できるのだろうかという懸念
      は残る。もしそうだとしても物凄く長い行を処理しても処理能力の低下は起こら
      ないのだろうか→文字数の制限が厳しいのは sed 実装だった気がする。POSIX 的
      には awk も制限があったけれども実際の実装ではそんなに問題にならなかったの
      だという気がする。

      読み取りの速度を考えると mapfile-nfix で読み取れる形式に変換するのが良い。
      つまり、declare の parse を awk で行うという事である。declare の形式は
      version によって異なっていたりバグがあったりするが…。

    やはり速度という観点で一番良いのは declare -p a | awk して mapfile-nfix で
    読み取るという物の様に思われる。それとは別に何故 mapfile -d '' が遅いのかと
    いうのは気になる所ではある。

    ? 何故 mapfile -d '' は遅いのだろうか。

      | 確認してみると delim が \n 以外の場合には unbuffered read に切り替える様
      | になっている。何故だろうか。zgetline の実装を見ると delim を引数に受け取
      | る様になっている。更に、zgetline は zread もしくは zreadc を呼び出してい
      | る。最終的に buffered の場合には read(fileno, buf, bufsz) を呼び出して、
      | unbuffered の場合には read(fileno, buf, 1) を繰り返し読む様になっている。
      | 実装を読む限り \n かそうでないかで振る舞いを変更する理由もない様な気がす
      | る。不思議である。理由について尋ねても良いだろうか。
      |
      | Greg に最終的な目標は何なのか。不適切な事を Bash で実行しようとしているの
      | ではないか、という様に文句を言われるかもしれない。その時の為に説明を書く
      | のが良い気がする。
      |
      | get_file_list() {
      |   (files=(*); declare -p files > tmpfile) & bgpid=$!
      |   while :; do
      |     if has_background_completed "$bgpid"; then
      |       eval -- "$(< "$tmpfile")"
      |       return 0
      |     elif has_user_interrupted; then
      |       cancel_everything "$bgpid"
      |       return 1
      |     else
      |       my_sleep 0.1
      |     fi
      |   done
      | }
      |
      | $ a=({000000..500000})
      | $ printf '%s\n' "${a[@]}" > tmp
      | $ mapfile -t a < tmp
      |
      | $ printf '%s\0' "${a[@]}" > tmp
      | $ mapfile -d '' a < tmp
      |
      | builtins/mapfile.def L187..L194
      | > #ifndef __CYGWIN__
      | >   unbuffered_read = (lseek (fd, 0L, SEEK_CUR) < 0) && (errno == ESPIPE);
      | > #else
      | >   unbuffered_read = 1;
      | > #endif
      | >
      | >   if (delim != '\n')
      | >     unbuffered_read = 1;

      これは報告した。

    さて declare -p | awk を実装してみたが遅い。実装している内に気づいたが、awk
    では文字列の途中から一致させる事ができないので、一致範囲を毎回切り出す必要
    があって、これを巨大な文字列に適用すると大変な事になる。今迄の実装で
    declare -p | awk が使えていたのは正規表現で一気に全体を置換するという様な簡
    単な処理しかして来なかった為である。

    →これについては split(s, a, / /) で分割して各要素について処理する様にした
    ら改善した。

    然しそれでも unescape の処理によって格段に時間がかかっている事は確かである
    様な気がする。もっと手っ取り早く変換する事はできないだろうか。例えば "..."
    と $'...' の何れかしか使われないという仮定で単純化できないか等。しかし、例
    えば空白一文字取って見ても " " の内部と、要素と要素の間の " [...]=" を明確
    に区別できる様な正規表現はない様に思われる。或いは "..." 全体に一致する様な
    正規表現を書ければ、特定の文字列を []="..." の直後に挿入して、更にその後に
    その特定の文字列を使って分割する事が可能だろうか。然し、その為には & または
    \1 等による後方参照で元々の文字列を置換後に参照する必要がある。gawk の
    gensub を使えば可能かもしれないが、その儘の awk では難しいのではないだろう
    か→改めて確認した所、

    ? 今試している awk 実装では問題になっていないが、この様な巨大な処理をすると
      なると awk 実装によってはとても遅くなる可能性があるのではないだろうか。

      | →試してみたらそもそも動作していなかった。動かないと思ったらそもそも nawk
      | は {m,n} に対応していない?
      |
      | $ echo '000' | nawk '/[0-9]{3}/'
      | $ echo '000' | mawk '/[0-9]{3}/'
      | $ echo '000' | gawk '/[0-9]{3}/'
      | 000
      |
      | この様な事態になっている。これは大変な事である。つまり、ERE は使えると思っ
      | て書いていると痛い目を見るという事である。更に調べると gawk-3.0 でも
      | --posix または --re-interval オプションを指定する必要があった様だ。
      |
      | https://unix.stackexchange.com/questions/354553/awk-repetition-n-is-not-working
      |
      | gawk であれば --posix または POSIXLY_CORRECT=always を指定すれば良いそう
      | だが、どの道他の実装では使う事ができない。という事を考えると一概に使えな
      | いと思っておくべきである。
      |
      | * 更に 0xHHHH もエラーメッセージなく勝手に 0 と解釈されていた。
      |
      | * また printf("%s\0",line) は普通に \0 が null-terminated と見做されて 0
      |   は出力されない。これは gawk の振る舞いの方が特殊である様に思われる。
      |   printf("%s%c", line, 0) で出力する事にする。
      |
      | * mawk は /[0-9][0-9]?[0-9]?/ としても /[0-9][0-9]?/ になってしまう。

      色々互換性の問題を修正した。見た感じだと nawk も mawk も gawk よりは高速
      である。余り気にしなくても良さそうである。

    ? 更に変な内容がなければもっと高速化できるのではないだろうか。

      例えば全て []="..." の形式だったならば、最初に " []=" を全て他と当たらな
      い様な物 (例えば ^A) に変換して、その後で "" の中身の unescape 処理をして
      から分割すれば良いのではないか。unescape は \\ -> ^B, \" -> ", \$ -> $,
      \` -> `, ^B -> \ とすれば良い。

    取り敢えず新しく実装した ble/util/{read,write}array を使う様に変更してみた。

  * main: ble-reload するとプロンプトの計算の箇所で問題が生じる [#D1521]

    これは当初 nawk のテスト時に気がついた問題なので nawk に関連して生じている
    のかと考えたが、gawk で試しても同様の問題が生じた。

    遡って調べてみると実は 82c5ece で発生する様になった問題の様である。
    取り敢えず bleopt/check-all でエラーが発生しているのかもしれない。
    →これが原因だった。これは独立な問題として commit する事にする。

  * set -o posix の時、ユーザーが read -e を呼び出すと [#D1520]
    何にも動かなくなるのではないか。

    a 然し、read -e 自体が posix の範囲外なので仕方がないという見方もできる。

    b 或いは、set -o posix の時には set -o emacs / set -o vi の切り替えを利用して
      read が使える様に調整するという事も原理的には可能である。その場合には実際に
      bind する対象の keymap が反転するので大幅な改修が必要かもしれない。

      x 然し、vi mode 及び emacs mode に切り替える機能も存在した筈である。これを
        呼び出されると結局 ble.sh の管理下の keymap が前に出てきて問題になる。
        read の中から呼び出された事を検出してどうにかその場で取り繕う事は可能だろ
        うか。

    c 別の方法で read が呼び出される瞬間を検出できないだろうか。或いは read -e に
      よって最初に widget が呼び出された瞬間に POSIX を始めとする様々の設定を回復
      する? その場合には C-c で read をキャンセルした場合にまた元に戻す事を忘れて
      はならない。

    d ユーザーがコマンドを実行する度に realine 設定を完全 unbind して、終わったら
      再度 bind し直す。でも、これは文法エラー等によってコマンド実行が中断された
      時に、ble.sh session に復帰せずに通常の readline の状態に落ちてしまう。

    →どうやら set -o posix でも本来の意味を取り戻す builtin とそうでない
    builtin が存在する様で、read の場合には set -o poix であっても関数が定義さ
    れていればそちらが呼び出される様である。なので気にしなくて良い。本当に問題
    が起こるのは builtin read -e が実行された時になるが、これは元から動いていな
    かった。

    実の所、builtin read -e に対しても制御を全く失う様な事態にならない様にした
    いが、それはまた別に考えた方が良いのでは? と思ったが、此処での考察はその場
    合にも同様に適用できる→別項目に残す事にした。

2021-04-30

  * 2021-03-21 set -o posix してから source ble.sh すると失敗する [#D1519]

    先に source ble.sh してから set -o posix する分には即座に問題は起こらない。
    然し ble-attach に失敗するという可能性は存在する。うーん。
    関数を新しく定義するという事をしなければ特に問題は発生しない?

    POSIX モードに対する処理は関数の外で実行する事にした。同時に順序を変えて一
    番最初に POSIX モードを ble.sh 内部状態として調整する事にする。

    ? done: 実のところ、enter/leave でユーザーの設定した同名の alias/function
      を保存し、それからまた後で復元するという事も原理的には可能なのではないか

      …と思ったが、果たして其処までの事をする必要はあるだろうか。保存の為にま
      た色々コマンドを走らせなければならなくなるが重くはならないだろうか。と思っ
      たが、alias ... declare -pf ... を呼び出すだけなので実はそんなに処理とし
      て重い訳ではない。問題は alias や declare が勝手に置き換えられていた時に
      ちゃんと動作するのかという話である。

      結局実装する事にした。

    ? done: 現在二段階に分けて unset -f しているが POSIXLY_CORRECT しているのだ
      から、builtin も unset も本来の意味を取り戻している筈で、それならば一回の
      unset -f で十分なのではないか。

    x fixed: 現在 set -o posix, +o posix を使ってモードを切り替えているが、これ
      は setを上書きされていた場合に使えない。直接変数に代入するべきである。更
      に言うと、local ... も使えるとは限らない。local が上書きされているかもし
      れないから。という事を考えると、これも直接グローバル変数の値を変数代入で
      変更するべきである。

      →これは確認した所、元から殆どその様になっていた。新しく追加したコードだ
      けで set を使っていたので、これを全て POSIXLY_CORRECT=y 及び \builtin
      unset -v POSIXLY_CORRECT に書き換えた。また、unset は -o posix の時にだけ
      実行する様に変更した。-o posix の時には \builtin unset は本来の意味で解釈
      される事が保証されているからである。

      ? と思ったが、unset を使って解除する場合には見えている一番上の
        POSIXLY_CORRECT が解除されるだけで、更に呼び出し元のスコープで定義され
        ている POSIXLY_CORRECT が存在した場合には依然として set -o posix のまま
        になるのではないか。

        $ f1() { local POSIXLY_CORRECT=y; f2; echo f1:$SHELLOPTS; }
        $ f2() { local POSIXLY_CORRECT=y; f3; echo f2:$SHELLOPTS; }
        $ f3() { set +o posix; }
        $ f1
        $ f2

        試して見た所、unset POSIXLY_CORRECT だとやはり、更にその上の階層の状態
        が見える様になるだけである。そして、set +o posix も全く同じに作用すると
        いう事が分かった。

        但し考えて見るに ble.sh はトップレベルで動いていてその途中で
        POSIXLY_CORRECT を設定して動作するという事もないので、unset が途中の関
        数スコープの POSIXLY_CORRECT に当たるという事もない。従って、普通に
        unset -v POSIXLY_CORRECT を一回実行するだけで問題ない。

        何か問題が起こるとすれば、ble-attach もしくは source ble.sh を実行した
        時に複数の local POSIXLY_CORRECT=y の中で実行された時である。然し、この
        場合にはどうにも対策の仕様がない。unset -v を繰り返し呼び出す事によって
        POSIXLY_CORRECT を解除する事はできるが、然しこれを実行すると呼び出し元
        で実行した local POSIXLY_CORRECT の意図を壊してしまい呼び出し元で問題が
        生じる可能性がある。

        実はこの事まで考えると set +o posix や set -o posix で POSIX 状態を操作
        するのは不味いのではないかという気がする。呼び出し元で設定した
        POSIXLY_CORRECT の動作を破壊してしまう。

    x posix にしていても eval の中の alias 置換を防ぐ事はできないのでは。
      alias 展開をオプションで無効にする必要があるのではないか。
      そして alias は割とあらゆる箇所で影響が出る。
      これは大丈夫だろうと思っている if や [[ 等も対象である。

      | a builtin に関しては危ない所を全て \builtin 等に書き換えてしまえば問題ない。
      |
      |   grc '(^|[[:space:];|&('\''"])builtin\b' --exclude={wiki,ext,memo}
      |
      | b 或いは shopt expand_aliases を off にして処理を行う? うーん。ble.sh の内
      |   部では expand_aliases を off にするのが良い気がしてきた。
      |
      | c と思ったが ble.sh に影響を与える様な alias だけを off にすれば良いので
      |   あって全ての alias を off にする必要性もない。そして ble.sh に影響を与
      |   える様な物に関しては、ble.sh の処理中には unalias してしまっている筈な
      |   ので殆どの場合は大丈夫な筈なのである。
      |
      |   ユーザー実行環境で ble.sh 関数が呼び出されて、その ble.sh の中で eval
      |   をした時に alias 置換が発生するという状況は考えられるが、まあ、その様な
      |   場合にまで気を配る必要は今の所ないと考えている。
      |
      |   取り敢えず、adjust-builtin-wrappers が呼び出される所までは \builtin の
      |   様にして escape する必要がある。後、adjust-builtin-wrappers 自体の処理
      |   でも対策が必要になる。
      |
      |   * 特に、adjust-builtin-wrappers の中で eval を実行しているが、其処で
      |     alias 展開が起こると問題である。特に ble/util/assign によって実行され
      |     る eval が問題になるのではないか。
      |
      |   後、ble/util/assign の中でも

      結局 expand_aliases を off にする事にした。ble.sh を読み込んで
      expand_aliases を無効にする迄の部分を \builtin の様に quote すれば良い。
      一旦関数を定義してしまえば実行時に書き換わる事はないので、気にしなくて良
      い。気にするべきは eval で実行される文字列 (新しく解析される文字列) であ
      る。

    * resolved: 保存・復元の時に sed を使っているがこれを置き換えられないか。

      | これは ble.sh 読み込み時の最初の最初の部分なので sed が PATH に含まれてい
      | ない可能性も考える必要がある。sed の代わりに使える物はないだろうか。
      |
      | a 例えば extglob を有効にしてパラメータ展開で置換を実行するというのは一つ
      |   の手である。
      |
      |   この方法だと一回 type の出力を変数に格納する必要がある。従って、余分に
      |   $(subshell) を実行する事になってしまって非効率的である。と思ったが、パ
      |   イプにする事によっても subshell が 2 つ余分に生成されるのだから、$() に
      |   しても特に overhead にはならない気がする。
      |
      |   然し extglob を on/off するのはそれはそれでまた面倒である。
      |
      | b どうにかして sed の binary を見つけてそれを先に ble/bin/sed に登録して
      |   しまう? 然し、その為に色々の処理が必要で、その処理を不明な環境で安全に
      |   実行するのもまた面倒である。
      |
      | 後、最初の実行時には注意深い実装が必要かもしれないが、一旦初期化が終わっ
      | てしまえば、ble/bin/sed を使っても良いし、ble/util/assign も軽い実装を利
      | 用する事ができる。いっその事、初めから初期化前用の実装と、初期化後用の実
      | 装に分けても良い気がする。

      汚いが extglob で処理する事にした。

      実際に動かしてみると bash-3.0 で滅茶苦茶遅い。何故だろうか。bash-3.1 では
      特に問題は起きていない。調べてみた所、+([[:lower:]]) とすると遅い。
      +([a-z]) は遅くない。直接書く様に修正した。

    * 現在の待避コードの順序について考える。

      posix だとそもそも ble/* という関数自体定義する事ができない。一旦関数さえ
      定義できてしまえば関数呼び出し自体はできる。

      FUNCNEST の設定。関数定義はできるが関数呼び出しができないという状態だと駄
      目なので。

    * 一応各 builtin について動作確認をしておく。

      builtin, unset, eval はOK
      return, break, continue, local もOK

      % declare は駄目だった。というのも関数定義を抽出するのに使っているから。set
      % -o posix していても declare は回復できないのだという事。うーん。つまり
      % builtin か declare のどちらかは必ず先に unset しないと動かないという事。
      %
      % local の方を諦める事にした。local を上書きしてもローカルに変数が作られる
      % 事になる為、期待した効果を再現する事は不可能になる。なので敢えて上書きし
      % ようという人はいないだろう。declare だと機能を勘違いしている人が上書きし
      % ている可能性がある。また最初の local POSIXLY_CORRECT が効果を失うのも避け
      % たい。

      やはり他にも色々動かない物があるので local を諦めるだけでは済まない。やは
      り builtin の復元を諦める事にする。そもそも builtin を置き換えようとする
      事自体が異常である。何か一つ置き換えを禁止するのだとしたら builtin にする
      のが自然ではある。

      x fixed: : は保存できていない。もしかすると set -o posix の時には declare
        -pf で定義を出力できないという事? 確かめてみたが別にそういう事はない様
        である。という事は逆に定義する時に失敗しているという可能性?

    x fixed: ble-reload 後に ble-detach を実行すると以下のメッセージが出る。

      | bash: builtin: is: シェルのビルトイン関数ではありません
      | bash: enable: is: シェルのビルトイン関数ではありません
      | bash: enable: a: シェルのビルトイン関数ではありません
      | bash: enable: shell: シェルのビルトイン関数ではありません
      | bash: unalias: is: 見つかりません
      | bash: unalias: a: 見つかりません
      | bash: unalias: shell: 見つかりません
      | bash: unalias: builtin: 見つかりません
      | bash: return: is: 数字の引数が必要です

      これを見るに何らかのエラーメッセージがコマンドとして実行されている?

      然し、ble-reload の後に履歴が可笑しくなっているのも、ble-detach の後に変
      な状態になっているのも治っていない。これらはまた別の問題という事か。

      どうも _ble_bash が変な値になっていて、それによって別のコードが呼び出され
      ていたという事。そしてそのコードはちゃんとテストされていなかったので元々
      バグを持っていて、それが発現していたという事の様である。そもそもそのコー
      ドは set -o posix でも動く関数定義取得の為に declare -pf と type を切り替
      えて使っていた物だったが、そもそも関数名が通常の識別子である限りは
      declare -f を常に使っていれば特に問題はない。基本的には declare -f を使っ
      て、: だけは bash の version で切り替える事にした。

      以前使っていた declare -pf / type の切り替えによるコードは以下に残して置
      く。

      | if ((_ble_bash>=40300)); then
      |   builtin local defs
      |   ble/base/adjust-builtin-wrappers/.assign '
      |     \builtin declare -pf "${builtins1[@]}" :
      |     \builtin alias "${builtins1[@]}" "${keywords1[@]}" :'
      | else
      |   builtin local fname
      |   ble/base/adjust-builtin-wrappers/.assign '
      |     \builtin declare -pf "${builtins1[@]}"
      |     \builtin alias "${builtins1[@]}" "${keywords1[@]}" :'
      |   defs=$'\n'$defs
      |
      |   # Note: bash-3.0 だと何故か extglob +([]) の中で [:alnum:] や [:lower:]
      |   #   を使うと滅茶苦茶遅い。何れにしても locale 依存になるのは避けたいので、
      |   #   直接 a-z と書くのが良い。
      |   builtin local pattern=$'\n+([][{}:a-z]) is a function\n'
      |   if builtin shopt -q extglob; then
      |     defs=${defs//$pattern/$'\n'}
      |   else
      |     builtin shopt -s extglob
      |     defs=${defs//$pattern/$'\n'}
      |     builtin shopt -u extglob
      |   fi
      | fi

      さて、これで問題は "何故 _ble_bash が消えて無くなるのか" という事に集約さ
      れる。(履歴の振る舞いが変になるのも古い bash の history -s の振る舞いが変
      だという事と関係しているのだろう。また、C-d の反応が悪いのも関係している
      だろう。)

      実際に _ble_bash が空になっているという事が確認できた。

      そしてそれは何故かというと ble/base/unload-for-reload で _ble_bash を
      unset しているのが原因だった。つまり、unload-for-reload を呼び出す迄は
      _ble_bash 等の初期化は遅延した方が良いという事なのだろう。builtin に対す
      る対策は _ble_bash には頼らずに version 判定するべきなのである。→結局ど
      の bash version でも動作する様に常に type を使って関数定義を得る事にした。

    x fixed: ble-reload すると何故か履歴項目が最後の項目に対する追記の様になっ
      てしまっている。ble-reload ではなくて source ble.sh しても同様の問題が発
      生する。bash --rcfile out/ble.sh としても発生している事を考えると mshex
      等の他の設定との組み合わせで起こっている問題ではなくてそれ自体として発生
      している問題である。

      遡って見ると #D1519 の問題であるという事が判明した。これは #D1519 の下で
      議論するべきであろう。然し、そうだとしても何が原因になっているのかは謎で
      ある。構文着色も動いている様に見えて何だか不思議な動作をしている。原因を
      特定する為に幾つか振る舞いを変えて試してみる必要がある。

      * 保存していた builtins を復元しない様に変更したが特に変化はない。依然と
        して変な振る舞いを続けている。

      * adjust/restore-builtin-wrappers を使わない様にしても変な振る舞いを続け
        ている。

      うーん。コードを見ても怪しい所は見つからない。明らかに機能不全を起こして
      いる箇所があるのだから其処を手掛かりに原因を探る方が懸命である様に思われ
      る。

      ble-detach で発生するエラーについて調べようとしたが原因の設定では再現しな
      い様である。再現する為の条件があるという事か? 或いは ble-detach で発生す
      るエラーに関しては実は adjust/restore-builtin-wrappers が関係しているとい
      う事だろうか。

      これの原因は前の項目で判明した _ble_bash の消滅だという事が分かった。一緒
      に治った。

2021-04-28

  * blerc にユーザーが使いそうな ble-bind を載せても良いのではないか (motivated by Alyetama) [#D1518]

    ble-bind -f up 'history-search-backward immediate-accept'
    ble-bind -f down 'history-search-forward immediate-accept'

    やその他の Vim の説明に書いた ble-bind など。
    magic-space の効果をなくす為の ble-bind も。

  * nsearch の再設計について (motivated by Alyetama, rashil2000, carv-silva) [#D1517]
    https://github.com/akinomyoga/ble.sh/issues/101
    https://github.com/akinomyoga/ble.sh/issues/80

    一旦は bleopt オプションを追加すると書いたが、ここは widget の引数として
    opts を受け取る様にして、readline settings を読み取る時の振る舞いは適当に
    Bash に合わせる様にする方が良いのではないかという気がする。或いは、多少はユー
    ザーが期待する様な振る舞いに調整しても良い。

    * 実際に history 内部を移動するかどうか。現在の振る舞いは history の中から
      "load" するという振る舞いになっているが、本当は isearch と同様に history
      の内部を "移動" するという振る舞いの方が分かりやすい。

      action=load
      action=move

    * 空文字列の時に唯の行移動に fallback するかどうか。
    * 空文字列の時に前回と同じ文字列で検索するという手もある。

      empty=line-move
      empty=graphical-line-move
      empty=logical-line-move
      empty=history-move
      empty=previous-search

      空文字で検索する事はない様に変更する。

    * カーソル位置を何処に置くか。
      point=end
      point=begin
      point=preserve

    * nsearch status を表示するかどうか。
      hide-status
      % hide-status-on-empty

    * 下を押し続けた時にまた元の状態に戻る様にする。
      これはオプションにしなくて良い。

    C-x p 等の時には以下の設定で実行する。

      action=move:point=preserve:empty=line-move

    readline function 経由での呼び出しではできるだけ Bash の振る舞いを再現する?

      action=load:point=preserve:empty=line-move

      % うーん。実は Bash も空文字列の検索に対しては特別の挙動をしている様だ。
      % つまり、今まで議論で一貫性のある振る舞いについて考えていたが、これは既
      % に Bash が自然な形で破っているので Bash に従うべきなのである。

      →改めて Bash を試してみた所、やはり単純に行を移動しているだけではない様
      に見える。カーソルを行末に移動しているが、それによって次の検索内容が変化
      するという訳でもない。実際、ble.sh の実装に於いて、空文字列に対して単に行
      移動の widget に委譲してしまうと、次の up の呼び出しの時に新しくロードし
      た文字列全体に対して再度検索が走ってしまう。

    point=end をリクエストされたが正直これはデフォルトにしなくて良い。
    変更したければ自分で nsearch に point=end を指定して ble-bind して貰う。

    色々考えると実は hide-status-on-empty は実装しなくても良いのではないかとい
    う気がしてきた。理由付けとしては空文字列検索を行うオプションはそもそも存在
    しないから。というか、hide-status 自体表示する必要がないのかもしれないとも
    思った。然し、一応実装しても良い気がする。


    [疑問]

    * ok: isearch に対する疑問。現在履歴位置の古い内容に一致しないのか。

      % よく分からないのは現在履歴項目を遡った状態であった時に、現在の履歴の内容
      % に一致したらどうするのかということである。うーん。isearch はちゃんと遡っ
      % ている時にはその内容に一致している気がする。が、それは何でかというと他の
      % 場所に周遊している時にはその時の編集している内容は履歴に反映させている為
      % である。此処での疑問は、cyclic で検索している時に、現在の編集内容では消え
      % ているが、現在位置の履歴に残っている文字列に一致する場合に何が起こるのか
      % という事
      %
      % →うーん。試そうとしたが isearch で入力している内に最初の方に入力した文字
      %   に一致する項目にジャンプするので実の所、この様な状況が発生する事は滅多
      %   にない。
      %
      % しかし原理的には現在位置の古い内容に一致してしまう事がある気がする。これ
      % を回避するには検索を開始する前に現在の編集内容を履歴に反映させておくか、
      % 或いは、cyclic で検索するにしても現在位置には一致しないようにしておくか。
      % 現在の実装ではどちらかになっているのだろうか。
      %
      % コードを確認した所、気になる部分を見つけた。#D1025 で同様の問題があって部
      % 分的な修正が行われた様に見える。何れにしても基本的には isearch は非
      % cyclic な検索になっているので、そもそも巡回して現在の位置が検索対象になる
      % 事がないので気にしなくて良かった。

      →isearch は現在履歴位置については自分でテストして、それ以外については非
      cyclic な検索で次の項目から検索する様にしているので、現在履歴位置の古い内
      容に一致する事はない。

    [実装]

    * ok: 先ず初めに down を続けた後に元のコマンドライン文字列を回復する機能に
      ついて考える。

      ? そもそも既に history の途中に移動している状態で nsearch を始めた時はど
        うなるのか? →変な振る舞いになっている。#1 から更に down を押したら元に
        戻るべきなのに、改めて上方向に検索して #2 という状態になっている。更に
        付け加えるならば "echo" という文字列には一致しない。

      うーん。元のコマンドライン文字列に戻った時に、nsearch 状態が継続している
      とするか、或いは、nsearch 状態から抜けるか。again または input の時には、
      元のコマンドライン文字列に戻ってしまうのは変である。元のコマンドライン文
      字列に必ずしも一致するとは限らないので。(然し、逆に言えば元のコマンドライ
      ン文字列に一致する場合にはどの様に動作するのが自然だろうか?)

      | ? 現在のコマンド文字列から検索対象を拾った場合には、元の位置まで戻って来
      |   たら nsearch 状態を抜けるのは自然である。と思ったが、それはそれで変であ
      |   る。例えば C-x up で検索を初めて、その後は up/down で移動していた時に突
      |   如として nsearch から抜けてしまうと不便である。という事を考えると
      |   nsearch 状態から抜けるというのは変な話である。
      |
      |   そういう観点から考えると、やはり勝手に nsearch 状態から抜けるのではなく
      |   て、現在文字列に一致している状態にするのが自然である。一方で、stack の
      |   先頭に記録しているのは、現在の一致状態ではなくて、nsearch 開始前の状態
      |   である。
      |
      |   例えば、現在のコマンドラインから検索対象を拾った場合に
      |   は、_ble_edit_nsearch_stack に初めから余分に record を追加しておくのが
      |   良いのではないだろうか。つまり、検索開始時に最初に
      |   _ble_edit_nsearch_stack に検索開始前の状態を保存すると共に、カーソル位
      |   置を point=* で指定したのに対応する位置に初期化してしまう。
      |
      |   と思ったが空文字列で empty=previous-search によって検索開始した時には現
      |   在のコマンドラインに一致しているとは限らない。など考えると明示的に現在
      |   のコマンドラインに一致するかどうかはチェックするべきである。
      |
      | ? input/again の時に元のコマンドライン文字列に一致する場合にどの様に取り
      |   扱うか。これは action=load にしているか action=goto にしているかでも振
      |   る舞いを変えるべきかもしれない。
      |
      |   →input/again でなくても現在のコマンドラインに一致しない可能性があるの
      |   で、これは input/again かどうかの問題としてではなくて、検索が初期コマン
      |   ドライン文字列に一致するかどうかの問題として捕らえるべきである。


      検索開始時点で現在の状態は _ble_edit_nsearch_stack に記録しておく。次に現
      在の行に対して一致するかどうかをチェックして、一致していたらそれも記録に
      残す。そしてその次の一致を調べる。

      うーん。何だか分からなくなってきた。もし現在のコマンドラインだけに一致す
      る時に nsearch をそもそも開始するべきかどうか? という話にもなる。現在の実
      装を確認してみた所、一応 nsearch は開始する様だ。然し、highlight も何も起
      こらない。うーん。これは実は highlight しても良いのではないだろうかという
      気がする。

      じゃあ、input 等で指定された検索対象が現在の内容にも履歴にも見つからない
      場合にはどの様に振る舞うべきなのだろうか。この場合には、選択範囲も何もな
      い状態で nsearch に入るという事の気がする。

      振る舞いとしては (1) 何処にも一致しない場合には現在の内容から少しも動かな
      いが、それでも nsearch 状態には入る。(2) 現在位置に一致して他に一致しない
      場合は、現在位置に一致した状態で固定。 (3) 現在位置にも他の位置にも一致す
      る場合には、他の最初に見つかった位置に移動するが down 等で現在位置に戻っ
      てくる事ができる。(4) 現在位置に一致せず他の位置に一致する場合には、他の
      最初の位置に移動するが down 等で現在位置に戻ってくる事はできない。という
      ので良い気がする。

      この振る舞いにするのであれば別に難しい事はない気がする。単に最初に現在位
      置に一致するかどうかをテストして、一致していたら stack に記録して状態を書
      き換えれば良いのである。

      実装を確認した感じでは現在のコマンドラインの内容は検索で参照しないし、中
      で実際に呼び出している検索処理である isearch も履歴の内容しか参照していな
      い。つまり、現在のコマンドラインの内容に対する一致は呼び出し元でちゃんと
      処理するという前提になっている。という事を考えると、この実装でも現在の内
      容に対する一致は呼び出し元でチェックすれば良い。というより古い内容に一致
      しない様に現在位置の一致は自前でする必要がある。

    * ok: 実装を確認した所、既に opts は受け取る様になっていた。これに色々とオ
      プションを追加すれば良い。

    * done: 空文字列の振る舞いとして単に行移動するだけの実装だと再検索で問題が
      起こるという事が判明した。これの対処方法は二種類ある。

      a 一つは行移動した時に必ず行頭に移動するという事。但し、その場合には検索
        文字列は改行を含まない物として、行頭から抽出するという様に振る舞いを変
        えなければならない。

        問題が起こるのはカーソル位置から検索文字列を取り出す時だけである。でも
        一貫性を考えれば、別に常に先頭に移動するという実装で問題ない気がする。

      b もうひとつの方法はやはり hide-status-on-empty で対処するという事。或い
        は empty=hide-status で良いのかもしれない。

      取り敢えず二種類をオプションで指定できる様にした。

    * done: opts hide-status

    * resolved: 検索対象の文字列を行頭迄にして見たが、実際の検索にはコマンドラ
      インの一番最初からの一致しか考えていないので、自分自身に一致することがな
      い。これは何だか変な気がする。或いは、現在行だけ置換するという手も考えら
      れなくもないが、それはそれで機能として複雑すぎる気がする。やはり、検索対
      象はコマンドライン先頭から抽出する事にして、更に、空文字列 up down の移動
      後もコマンドライン先頭に移動するべきである。という事を考えると、line-move
      というのは変である。history-move しか nsearch とは相容れない気がする。

      →line-move は機能として削除する事にする。

    x fixed: 今気づいたのだが read -e が動かなくなっている。どうも 856cec2 がい
      けない気がする。と思って確認したが別に read -e が動かなくなる様な要因はな
      い気がする。或いはもっと最近の修正が原因だろうか。どうも調べてみた所、最
      新の ble-bind --cursor の commit によって動かなくなっている様である。何故
      だろうか。refactoring で変更漏れがあっただろうか。

      refactoring 関連を確認してみたがぱっと見た感じでは変更漏れはない気がする。
      だとすると何が変わったのだろうか。何処で失敗しているのか read の中に入っ
      て行くべきだろうか。

      →分かった。これは ble/decode/keymap/push が 1 を返す様になってしまってい
      たのが原因だった。push の一番最後の行に [[ $cursor ]] && do something を
      入れた所為で、カーソルが設定されていない keymap/push が失敗する様になって
      しまっていた。カーソルの設定に関係なく 0 を返す様に修正した。

    x fixed: C-x up/down で移動する内に履歴が書き換わっている気がする。これは
      goto と load が入り混じっているからの気がする。ちゃんとその辺りを修正して
      からテストするべきである。

    x 下方向に検索できない状態になっている。というか goto-match で常に backward
      になっているのは変である。

      そもそも検索開始位置は現在の履歴位置とするか或いは末端とするのかという問
      題がある→確認してみた所、一応検索開始位置は現在の履歴位置になっている様
      である。

      ? 検索方向を反転する時に古い履歴内容に一致してしまうのではないか。

        検索開始位置の履歴項目には含まれていた単語を、編集でそれを消した後に検
        索すると、最初の一致が当初の検索方向に離れた箇所で起こる。その時に検索
        方向を反転させようとすると、過去の履歴に一致してしまう可能性がある。

        この時にはどの様に対処すれば良いか。先ず、検索方向の反転は stack の内容
        が1個しか残っていない時に起こる筈である。この時には、検索再開位置は現在
        項目か或いは検索開始項目でより検索再開方向に進んだ物を採用する必要がある。

    * 既定の動作をどの様にするのが良いのかよく分からなくなってきた。そもそも何
      故 nsearch という表示を隠す必要があるのかという事。

      特にカーソル位置を末尾に移動するという設定と組み合わせると、連続して同じ
      コマンドを実行した時には "カーソル前の文字列を検索する" という動作は最初
      の一回だけであり、それ以降には最初の一回で使った検索文字列を繰り返し使う
      という動作になっている。つまり、連続で実行している時には通常と異なる状態
      になっているというのは明らかである。という事を考えるとその事が分かる様な
      表示が必要になる筈である。単に上下で履歴内部を移動するのとは訳が違うので
      ある。

      zsh の振る舞いを調べてみた所、別にカーソル位置を変な所に移動するという事
      はしていない。と思ったが、どうやら history-search-end というモジュールが
      あって、それに history-beginning-search-backward-end 等の様な、末尾にカー
      ソルを移動する様な同じ機能の物が存在する様である。
      https://unix.stackexchange.com/a/97844/121088

      取り敢えず C-x up 等によって使える物については自分の思う様に実装する事に
      する。先ず action=load ではなくて移動。nsearch status は表示する。point
      は現在位置。explicit に呼び出しているのだから空文字列でも普通に nsearch
      に入る。

      readline 経由で up に割り当てている時には。

      a やはり2回 RET して実行されるというのは、保持する。そうすると nsearch
        status も表示して置くのが良い。Bash の元々の動作と思うと action=load は
        保持した方が良い様な気もする。空文字列の時に空文字列で検索するか、とい
        うと微妙。うーん。空文字列の時は history-move が良い気がする。うーん。

      b 或いは bash と完全に同一の動作を目指すのであれば、
        action=load:hide-status:immediate-accept 等と指定すれば良い。が、それは
        それでユーザーが便利にならない。ble.sh の便利さを押し出していきたいので
        あればやはり便利な動作を既定の動作とするのが良い気がする

        hide-status:immediate-accept:action=load:empty=empty-search:point=end

    [Note]

    * 空文字列移動: 行指向の通常移動に fallback する選択肢を考えたが、コマンド
      ラインの途中に移動すると、カーソル前の文字列が非空になるので、続けて移動
      しようとすると予期しない nsearch が始まってしまう。代わりに常に行頭に移動
      して検索文字列を行頭から抽出する様にすると、今度は自分自身に一致しなくな
      るので動作として分かりにくい。

    * C-x up で始めた時は empty=previous-search で良い気がする。うーん。ユーザー
      に入力させた時には空文字列を指定したのに前の文字列で検索が始まったら変で
      ある。なので既定の動作を previous-search にするのは変である。然し、コマン
      ドラインから検索文字列を抽出した時にだけ empty=previous-search にするのも
      分かりにくい気がする。

    [修正]

    x fixed: 描画で一番最後の文字が欠けてしまう。何らかの座標計算が間違っている
      という事だろうか。

      どうも point=end を指定すると振る舞いがおかしくなる。然し、可笑しな事が起
      こる余地などない様な気がする。或いは、_ble_edit_ind の値を勝手に此処では
      変えてはいけないという事なのか、或いは、${#_ble_edit_str} の値がここでは
      大きな値になっているか。

      どうも get-selection によって発生している様な気もする。もしかして空の
      selection range を指定すると発生する現象なのだろうか。試してみると、空の
      range の数だけカーソル位置がずれるという事が分かった。

      分かった。buffer を構築する時に空 range があると "SGR${buff[@]::0}" になっ
      て、これが 0 要素に展開されれば良いが、SGR がある為に 1 要素に展開されて
      しまって、結果として buffer の要素数が増えてしまっているというのが原因で
      あった。そもそも空 range については要素の追加自体を実行しないという形で対
      処する事にした。

      それとは別に空文字列で検索している時には _ble_edit_mark_active を設定する
      必要もない。判定条件を見たら、_ble_edit_ind==end だった時の条件がそのまま
      になっていたのが悪かった。これも修正した。

    x fixed: 最新行が空文字列の時、最新行に空文字列検索で移動できない。これは
      isearch の実装の問題だろうか。或いは最新行が空文字列の時は移動しても登録
      されないという事なのか。或いは isearch の検索範囲の判定で有限文字列化空文
      字列かで振る舞いが変わるという事か。

      →分かった。最新行が空文字列の時に移動しても登録されない事態になっていた。
      dirty かどうかの判定で文字列比較を行って同じであれば処理をスキップしてい
      たが、そもそも登録されていない時にも "空文字列" になってしまうので、"空文
      字列" を登録しようとしても登録されずに終わってしまうというバグであった。
      これは修正した。

    * done: wiki: widget についての説明を書く。これは rasheil2000 への説明を調整して
      乗せれば良い→書いた。

    * done: wiki: Q&A から説明へのリンクを書く→書いた。

    * done: wiki/Q&A: リンクが間違っている物があった→修正した。

    * done: wiki: key bindings について RET, TAB, ESC 等についての説明をちゃん
      と書く。
      https://github.com/akinomyoga/ble.sh/issues/101#issuecomment-828340592

    * done: blerc に何か書いても良いのかもしれない? 或いは Alyetama の言う様に
      wizardを作って其処から設定を選択できる様にする。取り敢えず今は blerc には
      書かない事にする→やはり書いた。

2021-04-26

  * util: 既定の cursor-shape の時には DECSCUSR は出力しない (motivated by jmederosalvarado) [#D1516]
    https://github.com/akinomyoga/ble.sh/issues/95

    % cursor shape を変更しない場合には external/internal の切り替えでも
    % DECSCUSR は出力しない様にするオプション?
    →オプションではなく固定でその様な動作に変更した。

    そもそもその様な実装になっていると思っていたが…。恐らく一番最初の状態が
    unknown になっているのが原因? もし最初の状態が 0 になっていたとして emacs
    mode の場合にはそのまま DECSCUSR が全く呼び出されずに済んだ可能性はあったろ
    うか。

    →実際に試しに最初の状態を unknown から 0 に変更した所、ちゃんと最初のカー
    ソル状態が保持される様になった。

    ? no: 然し、コマンドを実行した後にカーソル形状を元に戻すという操作が強制で
      入っている可能性はあるだろうか?

      →確認してみたが、特に external/internal は意識していなくて、また外部コマ
      ンドがカーソル形状を変化させてしまうという可能性は考えていない。外部コマ
      ンドが停止する時にカーソル形状を戻しておくべきであるという前提に基づいて
      いるのであろう。

      取り敢えずその前提は仮定する事にする。

    条件判定を変更したが、実は初めから値を 0 に設定しておけば同じ動作になるので
    はないだろうか…。此処で実装するべきは空文字列だった時と 0 の区別ではないか。
    と思ったが、0 を意図してブロックとして指定するユーザーがいるかも怪しい。ブ
    ロックであれば 1 を指定すれば良いからである。

    諸々考えると単に初期値を unknown から 0 にすれば良いという気がする。

  * term/edit: keymap 毎のカーソル形状 (motivated by jmederosalvarado) [#D1515]
    https://github.com/akinomyoga/ble.sh/issues/95

    現在の実装では auto-complete, menu 等の mini mode 等でカーソル形状は変わら
    ないと仮定して、emacs, vi_?map の間の変更だけでカーソル形状の再設定を行って
    いる。然し、今後 mini mode におけるカーソル形状の変更も考えると、もっと統一
    的にカーソル形状を管理する必要がある気がする。

    例えば keymap 毎にカーソル形状を設定できる様にして、keymap の切替時に設定さ
    れたカーソル形状に変更する様にする。指定した keymap にカーソル形状が設定さ
    れていない場合は、keymap stack 内の前の keymap を参照する。

    * この時、既存のカーソル形状の設定はどうするのか。

      現在の vi におけるカーソル形状の設定: imap,nmap,omap,xmap,smap,cmap
      ... これらの設定に応じてカーソル形状を変化させる様になっている。然し、実
      際の実装ではこれらの map は参照せずに設定している気がする… と思ったが確
      認したらちゃんと keymap を参照してカーソルを切り替えていた。

      設定の方法は bleopt keymap_vi_?map_cursor を介して行っているが、もし
      keymap 毎にカーソル形状を管理する様にするという事だと、(1) 既存の設定は翻
      訳しなければならない (2) 新しい方法に移行する様に情報を提示する必要がある。

      或いは、bleopt keymap_KEYMAP_cursor を一般に使える様にするという手もある
      が、これはこれで bleopt 内に名称の構造を作成する事になるので避けたい。

    * emacs に対応する。

    ? ok: cursor-state を decode.sh から参照しても依存関係的に問題ない
      か。cursor-state は何処で実装されているか? → util.sh で定義され
      ている様なので大丈夫。

    [変更]

    * done: 設定の変数名を決める ... _ble_decode_KEYMAP_kmap_cursor

      取り敢えずは bleopt_keymap_KEYMAP_cursor を参照して実装する? と思ったが後
      の調整が色々面倒になりそうなので、もうこの時点で変数名も決めてしまう事に
      する。

      元々の keymap の設定は _ble_decode_KEYMAP_kmap_@ に保持している。同様に
      _ble_decode_KEYMAP_kmap_cursor を使おうと考えたが、これだと dump/save で
      記録されてしまうので微妙である。また、どういう設定コマンドで設定するべき
      かという問題もある。

      a ble-bind を使って設定を行う? と思っても直感的に変である。例えば
        ble-bind -m KEYMAP --cursor 5 とか設定する事になる。うーん。そんなに変
        ではないかもしれない?

        後、これの呼び出しも遅延する事にすれば実は dump で記録されてしまう問題
        も気にしなくて良い気がする。KEYMAP に紐付いているという事を考えても、直
        観的に特に問題はない様な気もしてきた。

        この場合には ble-bind -P で出力する時にカーソル設定も出力する様にする必
        要がある。

      a 新しくカーソル設定だけの為のコマンドを用意する? というのもユーザーが覚
        える事が増えるだけで余り良くない。

      c 或いはやはり bleopt keymap_cursor_KEYMAP という感じにして、多少構造化さ
        れた名前の bleopt に変更するに留めるか。

      今は取り敢えず a の方針で考える事にする。

    * done: ble-bind にオプションを追加する。
    * done: ble-bind に於ける遅延初期化について確認する。
    * done: refactor: ble-decode-key/dump 其他。

    * done: 実装する。keymap/push, pop の際に cursor shape を再設定すれば良い。

      % 遡ってもカーソル形状が指定されていない場合には何もしない? 今までに何も
      % 設定されていなければ何もしない。今までに何か特別な物が設定されていた場
      % 合には 0 または空の文字列で DECSCUSR を呼び出してカーソル形状の設定をク
      % リアする。これは実は cursor-shape の側で設定を行っている筈なので気にし
      % なくて良い。

      遡ってもカーソル形状が指定されていない場合はカーソル形状をクリアする。

    * done: keymap_vi_?map_cursor の設定を翻訳する。

      書き換えの指示を表示する事にした。然し、遅延ロードで設定が読み込まれる為
      に表示が乱れてしまう。これに対応する為にはメッセージを受け取った時に表示
      する様にしなければならない。どの様にするのが良いか。或いは invalidate す
      る? と思ったが座標計算のずれまでは解決しない。

    * reject: term_vi_?map についても keymap 側に設定を移行するべきなのではないか。

      然しこれに関しては大して系統的に管理しようとはしていないし、もし何かしよ
      うと思う場合でも __attach__ で実行すれば良いのではないか。ただ
      し、__attach__ はその keymap を push した時にしか実行されない。一方で、
      term は pop して表に出てきた時にも実行する必要があるという点が異なる。そ
      ういう意味で ble-bind --cursor と同様に取り扱っても良いのではないか。とい
      うより、ble-bind --cursor を止めてもっと汎用的な hook を用意する可能性?
      と思ったが、やはり cursor は cursor で管理するのが良い気がする。

      term_vi_?map についてはユーザが設定したい時に利用する物なので、現状の儘
      naive な実装をするままで良い。複雑な仕様にするとユーザーが混乱する。

    * done: vi における動作テストを行う。

    * done: wiki: ble-bind に追記
    * done: wiki: 既存の keymap_vi_?map_cursor を廃止。
    * done: update blerc

  * 2021-04-04 keymap/emacs: emacs mode でも cursor shape を設定できる様にする [#D1514]
    https://github.com/akinomyoga/ble.sh/issues/95

    % keymap/vi と同様に実装した。本来は auto-complete や menu 等の mini mode の
    % 中でカーソルの形が変化することも考慮に入れて、もっと統一的な枠組みでカーソ
    % ルの形状を管理するべきな気もするが、現在は external/internal 及び major
    % mode の切り替えのみでカーソル形状を変更する取り決めにして、直接カーソル形状
    % の設定を各 major mode の切り替えで記述している。
    %
    % 2021-04-26 設定を変更した時に直ぐに反映する様にするには? →取り敢えず
    % keymap/vi と同様にカーソルの形状はトップレベルで決まっていると考えて、基底
    % keymap　が emacs かどうかだけで変更を適用する様にした。然し、既に上の段落で
    % 記述した様に、mini mode 毎にカーソル形状を変更する為にはちゃんと構造化して
    % カーソルを変更する仕組みを整備しなければならない。
    %
    % * 今の暫定実装だと、emacs モード内で vi に移行している時に意図しない動作に
    %   なる。vi は毎回自分の状態に応じてカーソルを設定しようとするとので、emacs
    %   の中で vi に移行していたとしても関係なくカーソル形状を変更してくる。なの
    %   で、emacs 内の vi でも vi のカーソル形状の設定は有効であると考えるべきで
    %   ある。
    %
    %   暫定実装では基底が emacs かどうかで判定しているが、そうではなくて、keymap
    %   stack の内部でカーソルが設定されている一番上の keymap を使って判定するべ
    %   きなのではないだろうか。
    %
    %   これも keymap ベースの判定方法なので、やはり keymap を基準にした実装に切
    %   り替えるべきの気がしてきた。

    この変更は結局 #D1515 の実装に伴ってキャンセルした。一応変更は
    memo/D1503.stub.patch に残しておく。

2021-03-15

  * 2021-03-03 syntax: 実は "${v#...}" の中身も tilde 展開の対象の様である [#D1513]
    https://lists.gnu.org/archive/html/help-bash/2021-03/msg00003.html

    bash-1.14 から bash-dev まで一貫して再現する。
    bash -c 'v=/home/murase/test; echo "${v##~/}"'

    : の後は特に展開対象という訳ではない様だ。変数代入形式の単語でも特に展開は
    しない。つまり本当に先頭に ~ がある時にのみ展開が発生する。

    $ bash -c 'v=x:/home/murase/test; echo "${v##x:~/}"'
    $ bash -c 'v=a=/home/murase/test; echo "${v##a=~/}"'
    $ bash -c 'v=a=x:/home/murase/test; echo "${v##x:a=~/}"'

    序でに、この振る舞いについては実はマニュアルにちゃんと記載されている。

    > In each of the cases below, word is subject to tilde expansion,
    > parameter expansion, command substitution, and arithmetic
    > expansion.

    対象は ${v-w} ${v+w} ${v?w} ${v=w} ${v#w} ${v%w} である。他は関係ない。

    * 他に posix モードに於いては変数代入形式の単語についてチルダ展開は起こさな
      い→これの対策も実装した。OK

  * 巨大なディレクトリで TAB 補完が遅くなる (reported by timjrd) [#D1512]
    https://github.com/akinomyoga/ble.sh/pull/65#issuecomment-798551355

    再現する事ができたので対応する事にする。200k のファイルまたはディレクトリが
    存在する所で TAB を押して少ししてから別のユーザー入力を押した時に直ぐにキャ
    ンセルされない。時には数秒待たされる事もある。現在の実装では補完時に別のプ
    ロセスを使っているので展開自体に時間がかかっているとしてもすぐにキャンセル
    される筈?

    ? 然し、本当にユーザー入力に対して即座にキャンセルするという事にして良いの
      だろうか。ある程度の interval は置くべきなのではないだろうか。と思ったが、
      実際の所、現在の実装で既にユーザー入力がある時にはすぐにキャンセルする動
      作になっていて、単にキャンセルが成る迄に待たされてしまうという動作になっ
      ているという事を考えるとこれは気にしなくて良い。

      →元から即座にキャンセルになる。ただ現状の実装ではキャンセルに時間がかかっ
      ているだけ。

    どうも TAB 補完の時には conditional-sync による実行がされていないのではない
    かという気がする。取り敢えず何処で時間がかかっているかを確認する。

    →絞り込みをかけていった所、ble/complete/source:file に於いて、生成したファ
    イルの存在確認とディレクトリかどうかの確認に時間がかかっていた。

    ? 然しそもそもこの確認は必要なのだろうか。現在の実装では nullglob を設定す
      る様にしているので存在しないファイル名が生成される事はないのではないか。
      やはり確認してみると nullglob を設定しているので改めてファイルの存在確認
      を行う必要はない筈。-e または -h で確認を行っているがこれは全ての生成され
      たファイル名に対して真であると考えられる。従ってこの処理は不要である。

      →特にファイル名の生成の時にはチェックはしない様に変更する事にした。ディ
      レクトリの場合にも予めパターンに / を含めているので、ディレクトリ以外が混
      入するとも考えられない。従って、全て使う事にする。但し、末尾の / は除去す
      る。

    然し、これまでの処理ではファイルの存在確認を全てのファイルに対して再実行し
    ていた。つまり、-d -e -h を実行していた。stat を何度も繰り返す事になるし、
    そもそもループで 200k ものファイルを回していたという事になる。なのに、手元
    の計算機ではかなり短い時間で処理できていた。bash は意外と遅くないという事な
    のだろうか。何れにしても環境によってはこれらのファイルアクセスに時間がかか
    るというのは理解できる。

    実のところこれが本当に報告された問題に関係しているのかは分からないが、少な
    くとも性能の改善はあるだろう。他にも bottleneck があるかもしれないがこれで
    良い事にした。

  * 2021-03-07 bleopt 初期化時に最初から存在する設定をチェックする? [#D1511]

    というのも ble-update や version up に従って設定名が変わるかもしれないから。
    ただ、今までに設定を破壊的に変更した事はないので余り気にしなくても良いのか
    もしれない。

    % その場でチェックをする為にはチェック用の関数が bleopt/declare の時点で存在
    % している必要がある。check 関数が定義されている時にはそれが bleopt/declare
    % よりも前になる様に書き換えていく。
    %
    % x 以下の関数は定義時にちゃんと関数群が存在しているか確かめているが、その関
    %   数群は未だ定義されていなかったりする。これらの初期化順序についてちゃんと
    %     再考する必要があるのではないか。
    %
    %   - canvas: bleopt/check:char_width_mode
    %   - util: bleopt/check:input_encoding
    %
    % 或いは値の設定に関しては ble.sh の基本的な初期化が終わった後に一括してチェッ
    % クを行う様にする? そうすると既定値を何処かに記録しておく必要があるのでは
    % ないか。

    その場でチェックする様にすると dependency injection 的に用意される設定値の
    場合に (オプションを宣言した時点では設定値が登録されておらず、後で各設定値
    が補助関数の定義などを通して登録される場合) 問題が起こる。

    結局、様々のモジュールを読み込んだ後で最後に一括してユーザによって指定され
    た値のチェックを行う事にした。既存の設定に関してチェック用関数の順序を変更する必要はない。

2021-03-09

  * README: uninstall に .cache の事が書かれていない [#D1510]
    書いた。

  * README: 0.3 に関しては release note の側に書いておくべきなのでは [#D1509]
    記入した。0.1..0.3 の情報を書いた。各 Release ページに使い方を記入した。

  * COMPAT complete vs fzf: システムによってロードされた fzf で固まる [#D1508]

    これは . /etc/bashrc を読み込むと強制的に読み込まれている設定である。ユーザー
    が自分で入れた fzf に関しては contrib/fzf-completion を ble-import して貰う
    事によって問題が起こらない様にしているが、システムによってロードされる fzf
    に関しては内容を上書きする隙がない。仕方がないので、core-complete.sh で
    _fzf_* が呼び出された時に contrib/fzf-completion を自動的にロードする様にす
    る事にした。元より bash-completion を勝手に呼び出したりする様にしているので
    他の framework ありきのコードがあっても気にしない。

    これは正直 fzf が tty ではなくて stderr になにか出力しようとするのが行けな
    い。/dev/tty に出力する様にして欲しい物である。

    うーん。 fzf のページを見てもそれらしい物は存在しない。環境変数などで指定で
    きれば良いのだが。man fzf を見てもそれらしい物は存在しない。そういう機能を
    request して見ようと思ったが、考えてみれば自分で fzf を呼び出す時には
    2>/dev/tty をつければ良いだけなので新しい機能として実装する意味がない。ユー
    ザー経由で呼び出しているのであればユーザーにその様に指定する様にお願いする
    べきなのである。

    然し、ble.sh がやっているのは bash progcomp の模倣である。bash の方で問題が
    ないのであれば、ble.sh の方で問題が起こるのは余り良くない。うーん。fzf につ
    いて関数などで上書きして振る舞いを変える? うーん。それだと fzf-xxx の様な派
    生コマンドを使われた時に対処できない。結局 bash progcomp を真似て 2 は tty
    に繋いだ儘にしておくべきなのだろうか。うーん。

    というかそもそも fzf が tty に出力する様にしたとして auto-complete に際して
    期待通りに動くかどうかというのは非自明である。取り敢えず試してみる。
    →試してみた所期待通りに動作しない。やはり fzf の設定をそのまま使うのは駄目。

    ? うーん。実行しても結果が反映されない。COMPREPLY をちゃんと設定しているか?

    ? redraw-line が正しく呼び出されていない。

      % これは恐らく ESC [ が M-[ になって bind されているのが原因。CSI の構築に
      % 失敗した時に M-[ と解釈するべきか或いは ESC [ と解釈するべきかは微妙な所
      % である。然し、CSI を構築する ESC は isolated ESC ではなくて他の文字と一緒
      % に受信した ESC であるべきと考えれば、やはり M-[ と解釈するべきだろうか。
      % そうすると、CSI に失敗した時に 1 byte だけ切り取って ESC を key として生
      % 成しているのを修正するべきである。

      改めて確認した所、そもそも CSI 0 n は認識できないシーケンスとして捨てられ
      ているという事が判明した。

    ? その他の問題として fzf を実行している間は modifyOtherKeys の設定によって
      fzf の操作ができなくなっているという事がある。うーん。実際に端末に作用す
      るかどうか分からないのに補完関数を呼び出す度に端末の状態を変更するという
      のも変な感じがする。

    面倒なので fzf が補完関数の名前に入っている時に限り特別の動作をする様にする?
    取り敢えず、固まったりしない様に調整した。

    % x fixed: CSI 5 n が候補の文字列に結合してしまっている。これは何故だろうか。
    %   COMPREPLY にはちゃんとした候補が入っている…気がする。
    %
    %   →これは compgen の標準出力を読み取って候補としているのが原因。元の
    %   progcomp の -F の場合には標準出力はそのまま端末に繋がっている。それに倣う
    %   様に修正した。
    %
    % x fixed: 候補が生成されない…と思ったら実は CSI 5 n に対する返答 CSI 0 n に
    %   よってユーザー入力に依る中断が入って処理がキャンセルされている。fzf の時
    %   にはどうにかしてこれに対する対策を行う必要がある。
    %
    %   a CSI 0 n を受信しても処理を続行するというのは難しい。何故ならば受信した
    %     段階ではそれがユーザー入力なのか応答なのか判定する方法がないので。受信
    %     して読み取ってから違ったら書き戻すというのも処理としては汚い。
    %
    %   b それなら CSI 5 n がそもそも伝播しない様に抑える必要がある。うーん。幸い
    %     にして CSI 5 n は標準出力に、それ以外のメニューの描画は標準エラーに出力
    %     されている。従って、_fzf* に対しては標準出力を潰す様にするのが良い気が
    %     する。

    色々対策してみたが実はこれらの対策は contrib/fzf-completion.bash と本質的に
    同じであった。fzf-completion.bash を自動で load する方が良いのではないか。

    x fixed: progcomp で単一候補を生成したとしても progcomp 以外に sabbrev も表
      示されてしまって単一確定にならない。うーん。これは _fzf_* で成功して単一
      確定の場合には既に生成した候補は全て削除するという事にすれば良いのでは。
      →既存の候補は消去する様に実装した。

    x そもそも既に入力済みの内容を無視している。normal bash で試してみると、既
      に何か入力済みの物がある場合には fzf による completion は起動しない。空の
      文字列の時にだけ fzf による選択が開始される。

      →これは曖昧補完の為に空文字列で補完候補生成を要求するのが原因であった。
      曖昧補完の時にはそもそも fzf を呼び出さない様に修正した。

  * BUG progcomp: 現在 read に介入して中断する様にしているが [#D1507]

    現在の実装だと

    while read || [[ $REPLY ]]; do ... done

    の様になっていると、無限ループになってしまう。
    中断する時にも引数に指定した変数は全て空にしておく必要がある。

    というより、現在の read の実装は普通に呼び出した時であってもちゃんと変数を
    空にしてくれるのか?

    % そもそも元の read の振る舞いが良く分からない。read line とした時にもう読み
    % 取る内容がなかったとして line が空になるのかと思いきやそうでもない? と思っ
    % たがこれは勘違いだった。試す時に : | read ... とすると subshell の中で値を
    % 設定するので、外側の変数には影響が出なかっただけ。

    うーん。取り敢えず中断の時には内部で </dev/null を builtin read に食わせて
    処理する事にした。option -e が指定されていても /dev/null に繋がっている時に
    は特に readline も起動せずに期待通りに動作する筈。

  * [OK] edit: read -a ARRAY に対応していない? [#D1506]

    と思ったが実はちゃんと対応していた。抑 -a ARRAY は bash-4.0 の時点でちゃん
    と存在している。調べたら bash-2.0 で配列に対応した当初から存在している様で
    ある。

    対応していない様に見えたが実のところ read -e で読み取った結果を改めて
    builtin read で解釈されているので特別に実装しなくてもちゃんと振る舞いを再現
    できているのである。

  * wiki: bleopt openat_base [#D1505]

    現在は実は積極的には使われていないという事。
    また、既に重複して開かない様に対策が為されているという事。

    →どの時点で対策が導入されたか確認しようとしたら実は ble-0.1 の時からちゃん
    と或る程度の衝突回避はある様だった。問題が発生するのは ble.sh が fd を使い
    始めた後でユーザーがそれを上書きしてしまった場合である。この問題は今も依然
    としてある。従って、現在の文章はそのままにする。但し、Bash 4.0 以下でしか使
    われないという事は書いておいて良いだろう。

    wiki を編集した。

2021-03-07

  * progcomp: やはりファイルが大量にあるシステムで遅い (reported by timjrd) [#D1504]
    https://github.com/akinomyoga/ble.sh/pull/65#issuecomment-791932281

    試しに complete -r して見ると発生しなくなる。

    という事は bash_completion が悪さをしているのだろうか。

    * fzf completion も勝手にロードされている。fzf completion の実装が悪いのか
      と思って fzf の completion をロードしない様にしたがそれでも問題は発生する。

    * highlight_filenme= としても特に問題は改善しない。逆に
      complete_auto_complete= として highlight_filename=1 のままの場合には特に
      問題も生じない。着色もそんなに時間をかけずに実行できている。という事を考
      えるとやはり progcomp 特有の問題である様に思われる。

    * bash の progcomp の場合には特に問題は生じていない。という事は -F で呼び出
      した関数を強制的に中断する機能があるのか、或いは -F の関数の呼び出し自体
      にはそんなに処理時間がかかっていなくて後の処理で時間がかかっているという
      事なのか。何れにしても計測が必要になる。

    実際に処理をブロックしているのは以下の関数の呼び出しの様だ。

    $ _minimal 'echo' '' 'echo'

    然し普通に呼び出してもそんなに時間がかかる事はない。

    ----

    _minimal の呼び出しに時間計測をかける。結局 _filedir の中にあるループがいけ
    ないのだという事。うーん。ble.sh の中で実行すると 20 秒も待たされるが、bash
    progcomp から呼び出すと 1.2 秒で終了する。何故だろう。

    実際に候補を bash progcomp 内で生成しているのか確認してみるとちゃんと候補は
    生成されている。

    もしかして read で変な処理をしているのが行けないという事だろうか。でもそん
    なに重い処理はしていない。うーん。オプションの処理をしているが、bash
    progcomp の時にも現在 attach しているかどうかのチェックは行っている。そんな
    に差が開く物なのか。

    実際に unset -f と read() { ble/builtin/read "$@"; } で囲んでみたら 0.6s に
    縮まった。1/60 の時間になった。

    ----

    これに対する対策はどのようにするのが良いか。

    a progcomp で compgen する時だけは unset -f read する? と思ったが、この状態
      で read -e を内部で呼び出されるなどすると変な事になってしまう。

    b decode-detach/attach するのは処理量的に好ましくない気がする。特に
      auto-complete で何度も呼び出されるのに、実際に時間がかかるかどうか分から
      ない処理のために毎回 detach/attach するのは大変。

    c 或いは _filedir 等の各関数に対して .advice around で unset -f read を行う?

    d 或いは read の中に complete_polling_cycle を仕込む。うーん。これが一番
      smart な気がしてきた…。

  * canvas: Kitty が CSI ; r に対して何もしない (reported by timjrd) [#D1503]
    https://github.com/akinomyoga/ble.sh/pull/65#issuecomment-791932281

    抑 CSI ; r にしていたのは DECSLRM CSI ; s に合わせる為であり、DECSLRM を
    CSI ; s にしていたのは、SCOSC と区別する為に引数の数に基づく heuristics を
    用いている為である。CSI r 自体については SUNSCRL と conflict が存在している
    が、SUNSCRL を実装している端末は Solaris console ぐらいしかないだろう。なの
    で、CSI r をそのまま出力しても問題ないと判断する。

    然し、引数の省略をすると動作しないというのは Kitty のバグなのではないのか。
    まあ Kitty の全体的なデザイン等について知らないので、もしかすると Kitty は
    全体的にそういう感じなのかもしれない。何れにしても Kitty の端末エミュレーショ
    ンは元より滅茶苦茶なので気にしても仕方がない。

2021-03-03

  * 2021-02-28 canvas/trace: align=right,center に対応する [#D1502]

    高さについても同様に対応しても良いのかもしれないがそれは必要になってからで
    良い。

    rps1 の各行右揃えに対応しようと思ったが問題がある。範囲計算がちゃんとできな
    いという事。rps1 が横幅一杯に広がれる様にする為には trace の計測開始点は
    x=0 でなければならない。然しこれで measure-bbox すると範囲が x=0..COLUMNS
    になって横幅一杯になってしまう。一方で、rps1 を表示する時には実際に文字が出
    力される範囲を取得したい。これはどの様にするのが良いか。

    a 描画開始点を実際に文字が出力される範囲の bbox の左上になる様にする? 然し
      それは最後まで範囲計算をしないと求められない。一番最後に、出力シーケンス
      の先頭に移動シーケンスをつけ加えれば実装できるが実装が汚くなる。特に右寄
      せしていない場合でも同様の機能を提供する等の事を考えると変である。

      更に、bbox の左上の位置というのが分かりやすいのかも不明である。何故なら呼
      び出し元は配置の結果として何処が bbox の左上になるのかという事を知らない
      からである。これは、呼び出し元で bbox の中身の配置について全く関知せずに、
      一つの blackbox として取り扱うという場合にのみ妥当である様に思われる。

    b 或いは描画開始点を右上にするという手も考えられる。右寄せの場合にはその方
      が自然に思われる。

      b1 計測の時には取り敢えず x=0 にして計測を行って、その後でユーザーが指定
        した (x,y) を起点とした描画シーケンスを構築するのである。然し、その時に
        は左に向かうシーケンス等が何処で壁に当たって止まるのかという振る舞いが
        変わってしまう。

      b2 代わりに unbounded な空間で計測をしてから再配置をするという事を考える
        と、今度は折角計測した内容が実は一行の中に収まらなかったという様な自体
        が生じる可能性もある。然し、これに関しては現在の実装でも似たような物で
        ある。しかし、少なくとも一つのフィールドの幅が行内に収まっていればOK。
        一つ一つのフィールドについて絶対範囲ではなくて幅や高さで制限をかける事
        になるが、それはまた実装が無駄に複雑になってしまう。

    c 或いは measure-bbox で文字列の範囲とカーソル移動の範囲の二種類のどちらを
      計測するか指定する事ができるようにする?

      両方の情報が欲しい場合も考えられるので、x1 x2 y1 y2 に加えて、x1c x2c y1c
      y2c 等を用意する? 少なくともカーソル移動は文字列を包摂するべきである。変
      数が増えるのも面倒なので x1[1] x2[1] y1[1] y2[1] 等の様に配列にしてその第
      二要素以降に値を格納するという考え方もある。然し、これはインターフェイス
      として分かりにくい。

      measure-bbox の振る舞いを切り替えられる様にするというのはやはり問題がある
      気がする。何れにしても両方の情報が必要になるからである。justify で配置を
      する時に出力された文字列の範囲を元にして配置を行うと、端にぶつかった時に
      座標計算がずれてしまう可能性がある。一方で、right align の大きさを調べる
      為には right を表示する必要がある。

    d 行毎に ret x1 x2 y1 y2 x y を算出する。これらの変数を全て配列にする。各行
      の bbox の左上 (x1,y1) を ret の出力開始点とする? (x1,y1) への移動に関し
      ては自前で実行する。その他の align も全て自分で処理する。

      これは微妙。これならそもそも trace に実装する必要もない様な気がする。
      (一応 sc/rc で囲んでいる部分やシーケンスを跳ばすという処理が非自明だが)
      そもそも trace に渡す前に分割して指定していれば良かったのである。

    % 調べて見た所、実は現在の実装は既に文字を出力した範囲の bbox を使う様になっ
    % ていた。という事は…。現在の実装で既に right を指定した時の範囲も表示して
    % いる物の範囲になっているという事?
    % →勘違いだった。ループの最後で記録しているが、これは制御機能によって移動
    % した後でも通過する場所に書かれている。

    表示が乱れる場合の事を考えると right の時には一旦右端に移動してから其処から
    の相対移動で描画するのが良い気がする。これは right の時の特別な取り扱い。

    * 現在の範囲追跡のコードを整理するという可能性。現在は移動を伴わないエスケー
      プシーケンスであっても記録を行う様になっている。これは無駄な気がする。

      また、全てに対して一律に範囲追跡を行っているので、文字列出力のみに対して
      計算する等の事ができない。と思ったが、結局最終的に文字列範囲とカーソル移
      動範囲の両方の情報が必要になるのであれば、文字列出力範囲に関しては独立し
      たコードで実装を行う筈で、これは気にしなくて良い。

    opts measure-gbox として出力した文字列の範囲を計算する事にした。

    * justify の時に最後に jg[xy][12] から g[xy][12] に転写する

    * main-loop の下部の ((w>0)) の処理について

      * 何故折返し処理を此処でしているのだろうか? w として有限の幅を設定する制
        御機能は限られている。調べた所、print+ と単一文字の時の二通りしか無い。
        単一文字に関しては行に収まらない場合には事前に改行を実施している。行に
        ぎりぎり収まる時の振る舞いはどうなっているか。うーん。

      * gbox は此処で処理するべきの気がする。有限幅の文字列がある時には此処に来
        るのだから。というよりこの処理自体を関数にしても良いのではないかという
        気もする。

      * そもそも此処で行っている処理は put-ascii や put-atomic で行うべきなので
        はないだろうか。

      →全て各制御機能及び print の内部で measure-bbox, gbox の処理を行う様に変
      更した。

    取り敢えず rps1 の複数行も実装して動作確認した。OKだと思う。

2021-02-28

  * 2021-02-06 render-defer.idle の優先順位を下げたい [#D1501]

    現在の実装では ble/textarea#render-defer.idle が menu-filter, auto-menu,
    auto-complete よりも先に来ているが、これは後に来るべき。特に menu-filter よ
    りも先に来ないと絞り込み状態の着色がずっと残ってしまう。

    menu-filter を render-defer.idle よりも前に挿入するべきである。どの様にすれ
    ば良いか。

    a 特定の要素の前に挿入するという操作を実装しても良いと思ったが、その為だけ
      に関数を用意するのも変である。それよりはオプションで指定できる様にする方
      が実装としては自然である。その時に挿入点よりも後に詰まって存在している要
      素はシフトする。

    b 或いは初めから各 background の優先順位を指定して登録してしまうという手も
      ある。というよりその方が自然である。どうせ決め打ちになるのでその方が柔軟
      に対応できる。

      現在 background idle (10000+) に登録される処理は以下の通り
      - ble/util/msleep/calibrate
      - ble/textarea#render-defer.idle
      - ble/complete/menu-filter.idle
      - push-background ble/complete/auto-complete.idle
      - push-background ble/complete/auto-menu.idle

    うーん。単に menu-filter を 9999 に登録すれば良い? これが単純で分かりやすい
    対応であろう。

  * 2021-01-31 complete: change bleopt complete_limit default [#D1500]

    実は今回の subshell による実行でしなくても良くなったのではないか。と思った
    が、元の報告だと別にグロブパターンと関係なく遅いという話だった気がする。と、
    思ったが補完の話だったのでやはりグロブパターンというかファイル名補完に関係
    がある。

    うーん。やはり 500 というのは上限としては小さすぎる様な気がする。
    auto-complete の 200 というのも小さすぎる様な気がする。もっと増やしても良い
    のではないかという気がする。5000 vs 2000 ぐらい。というか tab 補完に対して
    制限する必要があるのだろうか。

    ? globpat を含んでいるかのどうかの判定は実は failglob を使った方が早いかも
      しれない。現在の正規表現に基づく実装と速度を比較する価値はあるかもしれな
      い。しかし、../../.. みたいなパスが含まれている可能性等も考えると下手な事
      はできない。

  * [自然解消?] 2021-02-01 complete: slow tab completion after globstar words (reported by 3ximus) [#D1499]
    https://github.com/akinomyoga/ble.sh/issues/82#issuecomment-770390986

    パス名展開を compvar 構築時に全ての単語に対して実行しているのが原因かと思っ
    て#D1457 で compvar 用の timeout を導入してみたがどうも関係なかった様だ。報
    告に依ると globstar の着色が終わった後でも遅いという話だ。これはこちらの手
    元では再現しないという事が分かった。恐らく cache が働いているのだろうと思う。

    2021-02-04 新しい commit で改善したそうであるが、それでもパターンがない時よ
    りも遅いそうである。

2021-02-27

  * canvas/panel: set-height で高さ拡張時にその時の sgr0 が bce で適用されてしまう [#D1498]

    < /dev/tcp/..../80 で赤色になっている時に実行すると赤い行ができてしまう。
    これは sgr0 をせずに set-height を実行する事によって発生している事態である。
    そもそも赤い状態をそのままにして放置している事自体が変なのかもしれないが、
    取り敢えず set-height をする前に sgr0 をする必要はある気がする。

    $_ble_term_sgr0 を出力する様にしてみた。

    しかし、どうも ble/canvas/goto.draw する時にまた $_ble_term_sgr0 を出力する
    様なので、重複してしまう。問題が発生するのは、ble/canvas/goto.draw の時に既
    に目的地にいる場合で、その時は既定では sgr0 の出力も省略されてしまう。
    goto.draw の opts=sgr0 は、例え移動が起こらなくても sgr0 の出力を行うという
    物であった。→方針を変更して goto.draw に sgr0 を指定して其処で強制的に
    sgr0 を出力するという事にした。

  * エラーメッセージ "bash: ((: '0': syntax error:" (reported by rux616) [#D1497]
    https://github.com/akinomyoga/ble.sh/issues/92

    [状況]

    bash: ((: '0': syntax error: operand expected (error token is "'0'")

    * 最近発生する様になったという事。

    * 一度発生し始めると色々なキーを入力する度にメッセージが出るという事。

    * RET TAB BS 及び function keys が全滅。0-9 や numpad key も駄目。
      何故か # や & 等の記号は OK

    これは decoder が関係している気がする→2021-02の変更点を探してみたが特に怪
    しい所はない。

    * 連想配列が配列に化けてしまって発生しているという可能性もある。
      然し、連想配列の添字に quote 付きの文字列を指定する事があるだろうか。
      そもそも連想配列の添字に指定した '' が除去の対象だったかどうか怪しい。
      →試してみた所、どうやら展開の対象の様である。

    最初は発生していなくて途中から発生する様になるというのも不思議な事である。

    再現できた。というか空の blerc でも再現できた。どうも set -o vi だと発生し
    なくて set -o emacs だと発生する様だ。

    bleopt default_keymap=vi でも起きなくなる。
    bleopt default_keymap=emacs; set -o vi だと起きる。
    bleopt default_keymap=safe でも起こらない。

    うーん。emacs.sh の問題かとも思ったが最近変更した内容に関係のありそうな箇所
    は存在しない。だとすると別の場所で発生した問題が emacs.sh の中でたまたま見
    える様になっただけと考えるのが自然だろうか。

    取り敢えずなにかエラーメッセージが出ているという事はその場所を特定するとい
    うのは簡単の筈である。

    | 取り敢えず PROLOGUE と EPILOGUE の間だという事は分かった。decode byte 関
    | 連ではない。home を押しても一組しかエラーメッセージが出てきていないという
    | 事と、keymap safe, vi では発生していないという事から考えるに。だとすると
    | 残っているのは widget 実行辺りなのだが、様々な widget で発生している事か
    | ら __before_widget__ が怪しい。
    |
    | →確かに __before_widget__ だった。特に ble-edit/undo/add の中でエラーが
    | 発生している。
    |
    | % 更に ble-edit/undo/.get-current-state の内部で実行が途絶えている。と思っ
    | % たがそうでもなかった。その次の行の辺りだった。
    | %
    | % _ble_edit_undo_index に整数が入っている筈なのに history という文字列が入っ
    | % ている。と思ったら勘違いだった。_ble_edit_sttr に history という文字列が
    | % 入っているだけだった。
    |
    | やはり .get-current-state だった。調べると _ble_edit_undo_index の中に
    | '0' という文字列が設定されている。これは何処から来るのか調べる必要がある。

    分かった。配列を保存・復元する時に quote-words 的な処理で囲んだ要素を eval
    で評価するべき所が単に split-words で評価していたのが原因。最初は
    quote-words 的な処理にに書き換えたのが原因かと思ったが、逆で eval していた
    所を split-words に書き換えてしまったのが原因だった。つまり、犯人は 5f9adfe
    だった。IFS の調整として分割を全て split-words に置き換えた時に余分に書き換
    えてしまったのが原因。

    修正した。

    * ok: 他に似たような書き換えミスがなかったかどうか確認してみたが大丈夫の様
      である。

    後で改めて見てみたら修正によって破壊している。最近どうも全然駄目だ。毎回修
    正する時に新しいミスを導入にしている。改めて修正した。

2021-02-24

  * Makefile: keymap/*.txt に対する規則を削除してはいけなかった (reported by nihilismus) [#D1496]
    https://github.com/akinomyoga/ble.sh/issues/91

    f25a6e8 が悪い。22日15時過ぎに push したと思うから大体1.5日の間壊れていた事
    になる。これは良くない。修正した。動作確認もする必要がある。

2021-02-23

  * util: vbell で座標計算がずれる [#D1495]

    [状況]

    | 座標計算がずれる様になっている。ble.sh のディレクトリで空コマンドラインで
    | TAB 補完を実行しようとすると、complete_limit に達すると同時に sabbrev 候補
    | の \ が一次挿入される。この時に座標が一つ左にずれる。
    |
    | 8856a04 では問題は起こっていない。3cadd54 では問題が発生している。37363be
    | でも発生している。3cadd54 は ecb8888 に対応する。
    | 取り敢えず問題の commit は 69228fa にあると分かった。
    |
    | * bleopt edit_vbell= にすると問題は発生しなくなる。
    | * visible-bell の先頭で return して実際の処理を行わない様にすると発生しなく
    |   なる。
    |
    | 問題の commit では vbell に対する修正も色々入っている。やはりこの辺りが怪し
    | い。
    |
    | これは sc/rc による問題だろうか。然し、_ble_term_sc= _ble_term_rc= としても
    | 問題は再現している。fork の直前で return 0 すれば問題は生じない。つまり
    | .show 自体の問題というよりは出力が混ざる事による問題の様な気がする。
    | 然し buffer.flush を fork 直前に挿入しても何も効果はない。
    |
    | うーん。タイミングが丁度悪いという事なのだろう。

    あー。分かった。save-position/restore-position しているが、この時に
    _ble_canvas_{x,y} を参照している。然し、これらの値は subshell の中では更新
    されない。これが理由で座標計算がずれてしまうのである。

    [解決法]

    どの様に対策すれば良か。何が問題かと言うと…bottom-dock に対応する為に
    SC/RC を使っていて、それが visible-bell の使っている SC/RC と衝突していると
    いう事。コマンドライン上に居る時には visible-bell の為に SC/RC しても良いが、
    bottom-dock にいる時には visible-bell が SC/RC すると本来のコマンドライン上
    の位置が失われてしまって問題になる。これを防ぐ為に visible-bell では一旦コ
    マンドライン上に復帰してから visible-bell を表示する事にしている。

    どの様に解決するべきか。

    a IPCか何かを使って vbell の状態変化を親シェルに伝達して描画は親シェルで行
      う様にする? 然しどの様に伝達するのが良いだろうか。

      - シグナルは bind -x の内部ではチェックされない (もしくは bash の内部的に
        はチェックされているのかもしれないが対応する trap handler の呼び出しが
        遅延される)。然し、或いはそれでも良いのかもしれない。例えば現在
        bash-3.0 における C-d の読み取りは外部プロセスに行わせていて、C-d を検
        出したらファイルに書き込んでシグナルを送信する仕組みになっている。

      - tty に文字を挿入する事ができれば decode の枠組みに自然にイベントを組み
        入れる事ができるが、実際の所 tty に文字を外部から挿入する事はできない。
        シグナルを

      - FIFO か何かを使って通信するというのはよくある方法だが、現在の実装では
        visible-bell を実行する度に新しくプロセスを立ち上げているので、pipe を
        沢山管理しなければならないので非効率的である。

      - ファイルを使って処理をするという手が考えられる。bash-3.0 C-d でやってい
        る様にファイルに書き込んでからシグナルで通知する。然し、複数のプロセス
        が走っている場合には出力が混ざりあった時に問題が発生する。mkdir 等を使っ
        て同期するという手も考えられなくはないが益々処理が重くなってしまう。

        プロセスごとにファイルを作って処理するという手も考えられる。そして、読
        み取り用のプロセスは一つに絞る事にする。というか実は親プロセスで読み取
        りを実行すれば良いだけの気もする。ファイル書き込み中の同期に関しては、
        現在既に visible-bell でやっている様に複数の状態通知様ファイルを作って
        ファイルが空かどうかで判定する様にすれば良い。

    b そもそも別のプロセスを作る必要があるだろうか。全て親シェルで実行すれば良
      いのではないだろうか。折に触れて状態をチェックしつつ sleep して時間が来た
      ら親シェルが書き換え・消去を行う。

      然し、この方法の問題点は Bash 3.0 である。read -t 0 がないので、ユーザー
      入力が来た事の判定ができない。ユーザー入力があると想定してすぐ抜ける様に
      していると、実際にユーザー入力がなかった時に bind -x による制御が戻ってこ
      ないので、次にユーザー入力があるまで vbell の処理をする事ができなくなって
      しまう。ユーザー入力がないと想定して処理を続けると、vbell が表示されてい
      る間ユーザー入力が処理できなくなって固まった様になってしまう。

      そうするとやはり別プロセスに任せてそれをシグナルで処理するという事になる
      のだろうか。実際の所、シグナルハンドラーの中での処理は色々と怪しい事が起
      こるのでやりたくない。

      複数のサブシェルとメッセージをやり取りする様な一般的な枠組みを整えるのも
      手なのかもしれないと思う。

    c 取り敢えず今まで通り sc..rc が自由に使える前提で処理する

      今まで問題が起こっていなかったのは SC したまま放置される様な状況がなかっ
      たからである。その為いつでも SC...RC を気兼ねなく用いる事ができて親シェル
      の _ble_canvas_{x,y} の状態に依存せずに実装する事ができていた。本当の所、
      タイミングが悪ければ SC...RC が overlap して描画が乱れる可能性は 0 ではな
      いが確率的にはとても小さい筈。というのもシーケンスの書き出しは buffer に
      貯めてできるだけ atomic に行っているので。

      実は現在の所は SC/RC によって bottom-dock を実現しているとは言え、カーソ
      ルを bottom-dock に放置する様な事はしていない。なので、visible-bell の書
      き換えを行う時には常に SC..RC は閉じていると想定して良いのではないか。

    取り敢えず現在は c の方針で回避する事にする。

  * tui: trace に align/justify 機能を実装する [#D1494]

    prompt_status_line に右寄せの内容と左寄せの内容を表示するという需要はある。
    原理的にはユーザーの側で自前で実装してもらう事は可能である。然し、文字幅を
    考慮に入れる等すると実は非自明である。

    * prompt_status_line の中で適当に文字列を分割・計測したりして処理する方法も
      考えたが非効率な気がするし、エスケープシーケンスの中に justify の文字が含
      まれていたり、或いは prompt 展開の結果として justify の文字が現れる場合な
      どにも対応したいと思うとより下流で処理するべきである。

    * また、prompt_rps1 に於いても現在の実装では描画内容全体を一塊として右寄せ
      しているが、各行について右寄せをする様にしたい。

    その様に考えると trace の中で一括して実装した方が理に適っている気がする。

    * justify のデザイン

      | justify 用の文字の幅を保持するかしないかという問題が存在する。空白で
      | justify する場合にはどんなに狭くても空白一個分は開けなければならない。そ
      | うでないと英単語が互いにくっついてしまう事になる。他の制御文字等でフィー
      | ルドを区切る場合にはどうするか。うーん。その場合でも空白一個分は開けて置
      | きたい気がするが、しかし一方で | 等の様な記号を含める場合にはフィールドセ
      | パレータの分の空白があると邪魔なのではないか。
      |
      | 後、間を埋める文字についても指定できて良いのではないかという気がする。つ
      | まり、...... で埋めたり ------ で埋めたりするという事。実際に Emacs は
      | ---- で余分な部分を埋めているし、TeX の目次の様に .... で埋める様な機能が
      | あっても良い様な気がする。
      |
      | 指定方法について考える事にする。例えば、図形文字を sep に指定した場合には
      | 少なくとも 1 文字は其処にあると想定する。間を埋める場合にはその図形文字を
      | 繰り返す。制御文字を sep に指定した場合には幅が狭い時には零幅になる事を許
      | 容する。sep として複数の文字を指定できる様にし、それぞれの sep に応じて振
      | る舞いを変える。
      |
      | この方法の問題点は本文の中に fill 文字と同じ文字がある時に困るという事。
      | そう考えると fill 文字はやはり外部から指定できる様にした方が良いのではな
      | いか。でもそうすると間隔毎に異なる fill を使う事ができない。必ずしも sep
      | と fill を同じにしなくても良い。各 sep 毎に fill を指定できる様にするとい
      | うのも手である。但し、その場合にどうやって引数を指定するのかは謎である。
      |
      | というか空白の時にだけ特別扱いすれば良いだけなのでは。空白で justify する
      | のは英文の場合である。似たような文脈で空白以外で justify するという状況は
      | 考えにくい。

      仕様: 連続する同じ SEP がある時、その数はその SEP によって挿入される間隔
      の weight を表す。同じ SEP が離れて複数ある場合は、その SEP の間の文字列
      をその SEP に対応する FILL と解釈する。例えば SEP SEP -- SEP の場合はこの
      SEP の間隔の weight は 2 で fill は "--" と考える。

      最小間隔は通常 0 であるが SEP が空白の時は特別で 1 である。これは通常の英
      文の様なものを想定した特別規則である。

    実装方法について考える。やはり put-atomic, put-ascii を修正する事になる。
    clip とは相容れない。clip も処理しようと思ったら先に配置を決めておいて、
    その後で再び trace に入れて clip を実行する等という具合にする必要がある。

    clip と同様に出力する文字だけちゃんと配置できれば問題ない。
    その上で気にする必要があるのは "現在の塊" の範囲と、
    span weight である。

    うーん。measure についても justify が設定されている場合には注意が必要である。
    これも clip と同様に最初の実行では justify 用に使用して、後の実行に於いて改
    めて計算し直すのが適切である用に思われる。

    はみ出そうになった場合はどうするべきか。これは confine 等の取り扱いにも依る
    のではないかという気がするが、それらの処理は put-atomic, put-ascii の外側で
    為されている気がするので後で個別に考えれば良い。

    うーん。put-atomic 等の中では実は何も気にしなくて良い気がする。

    * reject: というか sep が図形文字の場合には、最初の各セグメントの幅計測時に
      は取り敢えず sep の幅も考慮に入れても良いのではないだろうか。うーん。やは
      り考慮に入れない方が自然の気がする。

    * done: xI yI を記録する。変数名は jxI jyI 等の方が良いのかもしれない。
      →jx0, jy0 という名前にした。

    * resolved: 現在の実装だとはみ出る場合にどうすれば良いか想定していない。という
      よりはみ出る場合に対して対策する必要はあるのだろうか。そもそも最初の点と
      最後の点だけ記録して、measure-bbox の内容は反映しなくても良いのではないか。
      その方が柔軟に設定できる様な気がする。

      →各フィールドについて初期位置と最終位置だけを元にして配置を決定する様に
      変更する事にした。

      然し、これだと右端を超えて描画されてしまう可能性が排除できない。うーん。
      その場合には適切に shift か clip を行う必要がある気がする。やはり初期位置
      と最終位置ではなくて幾何的に位置を決定する必要があるだろうか。でも、x1:x2
      が初期位置・最終位置の範囲外にはみ出ているという事は元からフィールド間で
      overlap があるという事に他ならないのだから、overlap してしまう事自体は問
      題ないのではないか。

      範囲外に収まらない時にのみ位置を shift するという処置を導入する事にする。
      →その様に修正した。

    * resolved: xenl の問題について。

      一番右端に寄った時に改行してしまう様な端末の場合、下手に一番右まで fill
      してしまうと描画が壊れてしまう。一番最後に出力した文字が右端に接触してい
      る時に改行が起こると想定しても良いかもしれないが、もし描画の途中で複数回
      右端に接触するという様な事があった場合、やはり描画が崩れてしまう。

      xenl のある端末の場合には一番右端まで領域を使ったとしても問題がないのかと
      思いきや、実は相対移動で左に移動しようとした時に結局ずれが生じてしまう。
      基本的に relative で移動している時には右端は使えないと考えるべきなのであ
      る。

      [実装] 然し、status line ではやはり右端まで使いたい。やはり一番右端に接触
      するのは、それぞれの行に於いて唯一回最後だけという想定をして良いだろうか。
      うーん。一応一番最後の位置と x2 が一致しているか確かめて、もしそうであれ
      ば一番右端に一番最後に接触したと想定する事にする。

      →そうするとやはり結局 measure-bbox は有効にする必要がある。

    x ok: ble/canvas/trace/.process-overflow に関しては justify に対して
      opt_relative を入れる事にすれば問題ない筈だが…。うーん。

      これは微妙だ。xenl cap のない端末ではそもそも最後の文字を出力しない様にし
      なければならない。というかそういう観点で言ったら実は、現在の
      opt_nooverflow の実装は駄目なのでは…。xenl のない端末で改行が発生してし
      まう。でも、opt_relative の時には OK である。

      少し xenl の取り扱いについて調整した。

    x ok: 現在の実装では !xenl の時に ble/canvas/trace で無駄な改行が入ってしま
      うのではないか。少し確認が必要である。どの様に検証するか。うーん。

      と思ったが問題の計算をしている所では opt_clip || opt_relative を仮定して
      いたので、そもそも端に接触するという事はないと考えている。なので、勝手に
      新しく改行が挿入されてしまうという心配は要らないという話だった。一方で、
      新しく導入した justify が関係して来る時には何が起こるだろうか。うーん。す
      ぐに .NEL を実行していて、更に .NEL の中では x==cols かどうかについてチェッ
      クしている訳ではないので大丈夫の筈。というか、justify の時には最初に仮想
      的な領域に書き込んでいて、右端で改行してしまう事に関しては後の再配置の時
      に処理する事になっているので気にしなくて良い。そういう意味では、後の xenl
      の処理に関しても同様。

    * done: 他に改行が必要になりそうな箇所を一つずつ探していく事にする。

      * ble/canvas/trace/.put-ascii.draw は justify の時には途中で改行する可能
        性のある動作はしない様にしてある。大丈夫の筈。

      * その他の通常文字(全角)の挿入の場合も範囲に入る時のみに文字列を出力する
        様にしてあるので勝手に改行が発生する事はない筈。

      * done: VT, CR, IND, RI でどの様に処理するのが良いかは微妙。別の行に移っ
        たと見做すのか或いは、また同じ行に戻ってきたら align するのか。というか、
        行った先でまた出力など起こす事を考えると、うーん? でも CR 以外は列番号
        は保持される。という事を考えると水平配置は途切れないと考えるのが自然な
        のではないか。

        VT/IND/RI に関しては何も処置はしない事にする。

        CR に関しては微妙である…。新しいフィールドという事にするか? 然しそれだ
        と指定もしていない sep が有効になっている感じで変である。うーん。jx0 に
        戻るというのが自然な振る舞いの気がする。

      * ok: CUU,CUD,CUF,CUB に関しては相対移動なので同じフィールド内での移動と
        解釈する事にする。

      * ok: HPA,CUP,CHA 等に関しては列番号を直接操作するので水平位置が途切れる
        様な気がする。然し、だからと言って別の行に移る訳でもないし…。これで移
        動しても同じフィールドの中にいるという事にする。

      * done: SC/RC に関してはどの様に取り扱うのが良いか。SC/RC についても
        SC/RC の内部にいる間はsep・改行も含めて特別な処理はしない様にするのが良
        い気がする。

      * done: \1..\2 による保存・復元。これに関しては field を跨いで復元される
        と微妙な感じだが…。うーん。或いは \1..\2 の内部では field の処理は無効
        化する?  それが自然な気がする。これは後で実装する事にする。

    * done: 空白文字の sep については特別扱いする。前の要素に空白文字を含めてし
      まって良い→と思ったがそれだと行折返しが発生した時に行末に余分な単語が含
      まれてしまう。

      ここは単に右に一文字ずらす事で span を最低限保つという方式にした。

      然し、この時の問題点は、他の種類の sep と混合していた時に、必ずしも空白に
      対応する sep に確保した span が割り当てられるとは限らない事。うーん。各
      span に対して "最低限これだけの幅は確保する" という制御は必要になるだろう。
      最初の計測の時点でその情報を参照するのだから、その情報も sep の記録に一緒
      に記録することにするのが良い気がして来た→その様に書き換えた。

    * ok: opt_relative を imply する。opt_measure も imply する。これらは判定を
      flags を用いて行う様にしたい。

      →これらは適当に実装した。

      1 現在の実装では opts=relative -> R, opts=measure-bbox -> M, opts=justify
        -> J を割り当てた。
      2 更に、char flags だと算術式の中で使えないので、別に変数 opt_relative (R),
        opt_measure (M or J) を用意した。
      3 他に、xenl についても opt_relative の時には自動的に imply する様にした。

    * done: $trace_flags == *M* が設定されている時に、範囲を改めて計算する。
      →実装した。

      特に center align している時に範囲を正確に抽出できているか確認する。でき
      ている。OK

    * done: test: フィールドの x1:x2 が範囲外にはみ出る時に正しくシフトできてい
      るか。

      →うーん。右端に一文字余裕を残した実装になっている。これは意図的な物だっ
      たか。確認する。うーん。xlimit が 29 になっている

      % →と思ったらこれは意図的な物だった。範囲を右端にはみ出ているので xenl
      % のない環境では xlimit を一文字減少させている。

      しかしよく考えたら、シフトを実装した今この取り扱いは不要な気がする。つま
      り、xenl のある端末では別に一番右端まで行っても良い。シフトがあるので右端
      を超えてしまう事はない。一方で、xenl のない端末の場合には常に駄目。

    * ok: 行末で begin-line してその後に改行が入るとどうなるのか。
      即座に end-line して空で終われば良し。そうでなければ対策が必要。

      →うーん。その様な状況があるのだろうか。元々何故このような事を考えたのか
      思い出せない。要するに $'\nhello' 等の様になっている時にどうなるかという事?
      この時は空の文字列が作られて終わるだけの気がする気にしなくて良い。

      と思ったが、現在の実装だと空の行に対しても無駄に処理をしている。この辺り
      は最適化の余地がある。取り敢えず justify_fields と DRAW_BUFF の中身を確認
      して空ならそのまま戻る様にした。

    * done: clip している時にも対応する。これの対応はどの様にするべきか。

      a 内部で再帰的に trace を呼び出して二回処理を行う。この時 opts を構築する
        のが面倒そうである。

      b trace の中身の中心部分を別の関数に分けてそれを二回呼び出す様にする。

      思うに殆どの opts は一回描画内容を決定したら継承しなくて良い気がする。
      寧ろ clip 処理は clip だけに徹するべきの気がする。という観点から考えると、
      方針 a に従って後で clip 用に trace を一回実行するのが良い気がする。

    * reject: 改行をしても別のフィールドには移らないオプション? 同じフィールド内で改行
      を行う。その時には xI:y+1 に戻る。

      また、フィールド内での CR はそのフィールドの開始位置に戻るべきでは。と思っ
      たが元からそういう実装になっていた。

      うーん。そういう事をしたければ \r\v 等とすれば良いのではないか。実際それ
      で動く筈。

    x justify:confine が変な動きをしている。一方で justify:truncate は動いている。
      →これは confine の側のバグだった。修正した。

    * done: 空白の時は空白で fill する。

    [追加修正]

    x \r が含まれている時に振る舞いが変である。→これは \r でフィールドの先頭に
      移動した時に追跡座標 x を正しく設定していなかったのが原因だった。修正した。

    o \v の動作については確認した。恐らく大丈夫。IND/RI も試していない
      が大丈夫だろう。

  * 2021-02-06 tui: trace に clip 機能を実装する [#D1493]
    Ref #T0007

    Note: これは元々 tui 計画の一部として実装した物だったが prompt_status_line
    や prompt_rps1 の為の align 実装に使う為に、trace を大幅に拡張したいという
    事で、独立な commit として適用する事にした。

2021-02-22

  * prompt: status line が最初の起動時に表示されていない [#D1492]

    | 何故だろうか。。。うーん。プロンプトが初期化される前だから? でもプロンプト
    | が初期化されたら…うーん?
    |
    | screen の中だと遅れて statusline が表示されるが、contra の中にいると次に何
    | か新しく表示されるまで何も表示されない。そもそもこの違いは何処から来るのだ
    | ろうか。screen の場合には誰かが invalidate しないと再描画がなされない筈なの
    | である。
    |
    | * screen で何故再描画が実施されるのか。調べてみると何らかのデータを受信した
    |   折に screen の中での再描画が走っている。
    |
    |   DA2R を受信した時に再描画が走っているのだろうと思ったがそうでもない様だ。
    |   contra でも DA2R は受信している。また、DA2R を受信してから一拍置いてから
    |   再描画が走っている様に見える。
    |
    |   もう少し詳しく受信しているバイト列を確認する事にする。
    |
    |   % うーん。分かった気がする。screen が CPR に応答した時に char_width_mode
    |   % が変わって invalidate が起こっているのではないかという気がする。contra
    |   % については CPR に応答していないが為に char_width_mode による invalidate
    |   % が起こっていない、という事なのだろう。
    |   %
    |   % →と思ったがやはり CPR ではない様である。先ず contra は一切 CPR に返事を
    |   % しないのは予想通り。一方で、screen はそもそも char_width_mode についての
    |   % CPR 要求はしていない。何故なら char_width_mode に emacs を指定しているか
    |   % ら自動判定にはなっていないのである。代わりに DECSTBM の判定に使っている
    |   % CPR を受信している。然し、その受信した CPR を完全に無視する様に書き換えて
    |   % もやはり再描画は発生しているのである。
    |
    |   再描画が起こっている理由について調べる。$caret_state が変化している事によ
    |   る再描画の様子である。
    |
    |   ? yes: というより本当にこの dirty の判定の所まで到達しているのだろうか。
    |     もっと前の段階て撥ねられていないだろうか。と思ったが、大丈夫の様だ。こ
    |     の判定の部分までは到達している。
    |
    |   caret_state の値について出力して確認してみる。
    |
    |     contra 内部       screen 内部
    |     ----------------  ------------------
    |     old=0:0:0:::      old=0:0:0:::
    |     new=0:0:0:::      new=0:0:0:::
    |     dirty:2           dirty:2
    |     old=0:0:0:::      old=0:0:0:::
    |     new=0:0:0:::      new=0:0:0:::
    |     dirty:clean       dirty:clean
    |     old=0:0:0:::
    |     new=1:0:0:::
    |     dirty:3
    |     chars=(DA2R...)   chars=(DA2R CPR)
    |                       CPR ble/term/t
    |     old=1:0:0:::      old=0:0:0:::
    |     new=1:0:0:::      new=0:0:0:::
    |     dirty:clean       dirty:clean
    |     old=1:0:0:::      old=0:0:0:::
    |     new=1:0:0:::      new=1:0:0:::
    |     dirty:clean       dirty:3
    |
    |   起動の振る舞いを見ると contra の場合には、CPR DA2R の応答を貰うよりも前に
    |   再描画の機会がある様だ。うーん。
    |
    |   ? 不思議な事に keymap_vi_load の実行は比較的最初に済んでいるという事であ
    |     る。もう一つの不思議な事は contra の内部でも dirty:3 が発生しているのに
    |     も拘らず prompt update が実行されていないという点。prompt の update の
    |     条件についても確認するべき気がする。
    |
    |     どうやらプロンプトが更新されたりされなかったりするのは history を読み込
    |     んだり読み込まなかったりする事による物のようである。何故端末が異なると
    |     history の読み込みに影響が出るのかは謎である。しかも、確率的にではなく
    |     て確実にそれぞれの端末で異なる一貫した動作になっているのも不思議な事で
    |     ある。

    [状況]

    最初に描画する瞬間は未だ keymap も読み込んでいない状態なので keymap_vi_load
    を経由して設定される prompt_status_line も表示されない。その後で
    keymap_vi_load が実行され、更にその後で再描画がかかる。

    違いは再描画がかかるタイミングが contra の中と screen の中で何故か異なる事
    によって出てくる様に見える。

    * keymap_vi_load との前後関係は実は関係ない。再描画がかかるのは何れにしても
      既に prompt_status_line が初期化された後の話なので、もしプロンプトの更新
      がかかるのであればどちらの場合でもちゃんとステータスラインが表示される筈
      である。

    * 代わりにコマンド履歴の読み込みのタイミングとの前後関係が問題になっている。
      screen の中では DA2R, CPR を受信した後に再描画が起こるが、この段階でコマ
      ンド履歴が読み込み済み状態になっている。これにより再描画に際してプロンプ
      トの再計算が実施される。一方で contra の場合には DA2R を受信する前に再描
      画がかかって、この時には未だコマンド履歴が読み込まれていない。この為に、
      プロンプトの更新の必要がないと判定されてプロンプトの更新無しで再描画だけ
      が行われている。

    何れにしても設計としてはプロンプトの設定を変更したら ble/prompt/clear を実
    行するべきで、更に、ble/prompt/clear を実行する時には
    ble/textarea#invalidate も実行するべきという事。

  * global: IFS 対策 [#D1491]

    多くの関数は IFS が普通の値になっているという事を前提にして書かれている。
    ble.sh の中では一時的に IFS を設定して動作する様になっているが、
    ユーザーから使用された時に IFS に変な値が設定されている可能性は排除でいない。

    * 引数を $* で渡された時の対策は取り敢えず grc -F で ${* もしくは $* に一致させて確認した。
    * 配列に対する単語分割 =($...) に関してもチェックは行った。

    * 他に配列を結合する処理に関しても注意が必要になる可能性がある。
      つまり、aa="${arr[*]}" の形の処理である。

      grc '\$\{[[:alnum:]_]+\[\*\]' --exclude={test,ext,wiki}

      取り敢えずこれも大体対応した。

    * builtin read も IFS に依存して振る舞いが変わる。

    他にも IFS が影響を与える様な状況はあるだろうか。恐らく他にもあると思うが、
    すぐには思い浮かばないので取り敢えずこれぐらいで良いだろう。

  * global: 現在様々な関数が引数として text... を受け取っているが [#D1490]

    実の所複数の引数を受け取る事に意味は余りない。
    実際に複数の引数をこれらの関数に渡している箇所があるとは思えない。
    現在は毎回 IFS を設定してこれらの引数を結合する様にしているが、
    そもそもその様な処理すら必要ないのではないか。

    * done: (main) ble/util/put
    * done: (main) ble/util/print
    * done: (util) ble/string#escape-*
    * done: (util) ble/string#{toggle-case,toupper,tolower}
    * done: (util) ble/string#[lr]?trim
    * done: (util) ble/string#capitalize
    * done: (util) ble/util/buffer
    * done: (util) ble/string#split-lines
    * done: (util) ble/util/idle.push
    * done: (vi) ble/keymap:vi/string#encode-rot13
    * done: (complete) ble/complete/cand/yield
    * done: (canvas) ble/canvas/put.draw
    * done: (edit) ble-edit/hist_expanded.update
    * done: (edit) ble/widget/(in|ex)ternal-command
    * done: (edit) ble/widget/execute-command

  * global: ロード時にエラーが出る (reported by 0neGal) [#D1489]
    https://github.com/akinomyoga/ble.sh/issues/85

    bash: ((: 4 0: syntax error in expression (error token is "0")

    うーん。 "4 0" という文字列が何処から混入するのかという事。
    "4 0" という文字列があるという事は何処かにそういう変数が存在しているという事?
    と思って declare -p の結果を grep で検索して 4 0 の組み合わせを探そうとしたが見つからない。
    配列に、要素を跨ってその様な値が格納されているのかとも思ったが、そうでもない。

    だとするとグローバル変数ではなくて内部で一時的に生成された文字列に問題が起きているという事?

    ((${#aaa[*]})) となるべき所を ((${aaa[*]})) にしてしまっているというのが怪しい。
    と思ったが m scan で引っ掛からない。
    sub:scan/array-count-in-arithmetic-expression でちゃんとチェックしている。

    3588158 で発生している。前に動いていた時はいつの version かと思ったが、
    どうも 0.3.3 を動かしていた様なので実は 0.4 でも前からずっと問題があった可能性もある。

    うーん。エラーメッセージから察するに "4 0" が完全な算術式として評価されよう
    としているという事。これにより ((...)) の形のコマンドで発生しているとすると
    かなり発生箇所を制限する事ができる。

    | ./lib/core-complete.sh:2847:      ((${simple_ibrace%:*})) && comps_fixed=1
    | ./lib/core-complete.sh:3282:      if ((${simple_ibrace%:*})); then
    | ./lib/core-complete.sh:3293:      if ((${simple_ibrace%:*})); then
    |
    |   simple_ibrance に値を設定している箇所は限られている。そしてその何れの場所
    |   でも確実に 数字:数字 の形になっているので、変な事が起こる余地はない。
    |
    | ./src/canvas.sh:1725:    (($3)) && ((x=0,y++))
    |
    |   ble/textmap#hit/.getxy.cur の第三引数…ではなかった。ここでは textmap 配
    |   列に含まれる単語を分割している。もしかして IFS に変な値を設定されていると
    |   いう事? と思ったがその影響が残っているのだとしたらもっと色々な大変な事が
    |   起こってしまう筈。そして実際に IFS= にして起動してみたが特にエラーメッセー
    |   ジは出ていない。
    |
    |   もう一つここが違いそうな理由は、報告によると起動時のみに問題が起こるとい
    |   う事であった。然し、もしここが本当に問題になるのだとしたらそれ以降もずっ
    |   と危ない感じになる気がする。
    |
    |   何れにしてもこの部分はもっとまともな実装に置き換えて良い気がする。
    |
    | ./src/color.sh:955:    (($name)) && return 0
    |
    |   name=_ble_faces__$1 としているので此処からは '4 0' という値は出てこない。
    |
    | ./src/util.sh:3244:    (($2))
    |
    |   これは ble/util/test-rl-variable の第二引数である。使用箇所を確認したが第
    |   2引数はそもそも指定していないか指定していたとしても 1 か 0 である。なので、
    |   これも違うだろう。

    然し、変数に alpha='4 0' 等の値が入っていてそれを ((alpha)) 等として実行し
    た場合にも同じエラーメッセージが発生するので本当にこの部分で発生しているの
    かというのは分からない。一方で $(()) の中で実行した場合にはエラーメッセージ
    が異なる物になるので、やはり (()) の中で発生しているというのは確定して良い。

    もしかすると bashrc の内部で ble-attach すると問題が発生する可能性?

    できた。再現できた。IFS= を ble-attach の直前に記入すると問題が生じる。

    どうやらコメントに依ると unset IFS にしている様である。という事は…。ble.sh
    をロードした時に unset 状態の IFS を保存して復元する時に空文字列になってし
    まうのが問題の原因になっている。

    * done: IFS の unset 状態も復元する様にする。復元する様にした。

    更にその後で空文字列の IFS が問題を引き起こしている。掘り下げていくと
    textarea#redraw の中で問題が発生している。

    * done: 空の IFS でも単語分割ができる様に個々の関数を書き換える。

      * 結局 ble/textmap#getxy.cur の問題だった。先に上で修正したと思っていたが
        修正漏れがあった。これで動く様になった。

      * 他にも IFS=$' \t\n' でないと動かない様なコードはないだろうかと調べると
        ble/canvas/trace の sc/rc がそれだった。修正した。

      * 他にも ble/textmap#update の中でも単語分割を使っている様子だったが、こ
        れは関数の先頭で IFS を設定しているので問題にならない。
        ble/string#split-words で書き換えようと思ったが performance の問題だろ
        う。そのままにしておく事にした。

      * 他のファイルも探したら沢山あったのでこの際全て修正する事にした。他にも
        IFS の値で振る舞いが変化する物は沢山あるのでこれだけで local IFS=$'
        \t\n' しなくてよくなったりはしないが、念の為変な動作を起こさない様にし
        ておく。

    x fixed: 全部直した筈だと思ったが ble-bind がエラーを出力している。
      →"$*" の類も全て IFS を気にする必要がある。取り敢えず util.sh の関数については
      IFS の値に拘らず動作する様に修正した。

  * keymap/vi: vim mode strings の設定をもっと柔軟にできる様にする (motivated by 0neGal) [#D1488]
    https://github.com/akinomyoga/ble.sh/issues/85

    Note: 0neGuyDev は名前が 0neGal に変化した様だ。

    * done: wiki vim のページ hook の説明で := の : が余分。
    * done: wiki vim の設定のページで全ての項目に注意書きを書く。

    何れにしても Cygwin での IL/DL の問題 (#D1482) に取り敢えずの決着をつけてから。
    →IL/DL の問題を解決したが未だ status line の問題 (#D1487) は残っていた。
    その後 status line の問題も解決した。

    どうやら Vim では mode() を用いて現在のモードを表現する文字列を取得する事が
    できるらしい。然し、mode() だけでは表しきれない情報も存在する様である。取り
    敢えず似た関数を用意さえすれば既存の枠組みを使って mode を status ilne に表
    示する事ができるのではないか。

    | Mode                                                                                          | `mode()` |
    |:----------------------------------------------------------------------------------------------|:---------|
    | INSERT                                                                                        | i        |
    | REPLACE<br/>VREPLACE                                                                          | R        |
    | NORMAL<br/>(insert)<br/>(replace)<br/>(vreplace)                                              | n        |
    | VISUAL<br/>(insert) VISUAL<br/>(replace) VISUAL<br/>(vreplace) VISUAL                         | v        |
    | VISUAL LINE<br/>(insert) VISUAL LINE<br/>(replace) VISUAL LINE<br/>(vreplace) VISUAL LINE     | V        |
    | VISUAL BLOCK<br/>(insert) VISUAL BLOCK<br/>(replace) VISUAL BLOCK<br/>(vreplace) VISUAL BLOCK | ^V       |
    | SELECT<br/>(insert) SELECT<br/>(replace) SELECT<br/>(vreplace) SELECT                         | s        |
    | SELECT LINE<br/>(insert) SELECT LINE<br/>(replace) SELECT LINE<br/>(vreplace) SELECT LINE     | S        |
    | SELECT BLOCK<br/>(insert) SELECT BLOCK<br/>(replace) SELECT BLOCK<br/>(vreplace) SELECT BLOCK | ^S       |

    これらは基本的にはそのモードに入る為に使うコマンドが使われる。
    然し、normal の n や select の s は名前から来ている。

    これに倣えば。拡張するとしたら VREPLACE は gR になるだろうか。
    insert, replace, vreplace は それぞれ i^O R^O gR^O になる。
    でもどうせ組み合わせるのであれば、実の所 ^O は必要ないのではないか。

    つまり、/(i|R|gR)?(n|v|V|^V|s|S|^S)?/ - ε (4x8-1=32-1=31種) という事になる。

    うーん。サンプルを見ると Rv というのが存在しているが実際に試してみると R に
    なっている。何故だろうか。後、やはり gR というのは都合が悪い気がする。
    vreplace の文字はまた別に考えたい。小文字の r を考えたがどうやら既に PROMPT
    というのの為に使われている様だ。だとすると ^R という事になるだろうか。うー
    ん。取り敢えず ^R という事にする。そもそも制御文字を使うとうのが良い事なの
    か微妙だが。RSTUV で何れも近い値というのも比較的良い事の気がする。

    * テストに用いた vimrc を移動する。

  * edit: prompt_status_line の表示が崩れる [#D1487]

    | prompt_status_line を試しに組み合わせて見たら表示がおかしくなっている。うー
    | ん。status の報告する文字列の高さが間違っているのが原因かとも思ったがそうで
    | もない。常に高さ1を強制する様に書き換えてみたがそれでも同じ問題が発生してい
    | る為である。
    |
    | という事はスペースを確保する時のコードが間違っているという事だろうか。これ
    | は丁度 stub branch で議論している物と関係する。というより stub branch の方
    | で何か修正を入れた気がする。その修正を適用してからこの問題が未だ継続してい
    | るか調べてその上で対処するべきだろう。
    |
    | →どうやら問題は継続している様だ。何故だろうか。なぜか知らないが高さを確保
    | できていないのが原因である。

    [再現]

    prompt_status_line を表示してかつ keymap_vi_mode_show= を使って vim mode
    string を表示しない設定にすると、一番下の行でコマンド実行した後に status
    line が消去されずに複製されて残ってしまう。

    振る舞いを調べると高さの確保は一応している様子である。毎回 1->2 に増やして
    いる。コマンドを実行した直後には高さ 1 という事になっている為であろう。然し、
    問題点が幾つかある

    * コマンド実行中にはステータス行は消去する筈なのに消去されていない。うーん。
      実装によるとコマンドを実行する前に ble/prompt/status#collapse を呼び出す
      事になっている。そして其処では set-height を用いてステータス行を消去する
      事になっている。然し消去できていない。

      調べてみるとそもそも status#collapse が呼び出されていない?? いや、これは
      呼び出されている。という事は set-height の途中で消えているという事であり、
      それはつまり元から高さが 0 だったという事。高さが増える事なく status line
      が表示されていたという事である。

    うーん。何かと思ったら reallocate-height.draw が呼び出されていない。現在の
    実装では他のパネルの高さが不整合になっていない限り reallocate-height.draw
    は呼び出されないのである。うーん。取り敢えず status#panel::render の中で
    reallocate-height.draw を試みるべきだろうか。

    status#panel::render の中で現在の高さを確認して足りなければ再配置を要求する
    様に変更した。これで OK の筈。これによって textarea の方に皺寄せが行く可能
    性もあるが、取り敢えずはこれで良い事にする。また後で reallocate-height につ
    いては考え直すのが良い→別項目を立てた。

  * decode: rlfunc.txt ファイルを移動する [#D1486]

    * .srcoption の中身も更新した。
    * GNUmakefile も書き換えた。
    * decode.sh も書き換えた。
    * 他に make_command.sh と vi.sh の中で言及していたファイル名を書き換えた。
    * 序でに散らばっていたテスト用のファイルをリポジトリに追加しておく。

  * term: screen で attach した時に時々 _ble_term_* が壊れる現象 [#D1485]

    screen で attach すると何故か色々壊れる現象があったが、どうも contra からの
    DA2R がそのまま screen の内部の shell に伝播しているという事の気がする。
    DA2R を受信した時に最初に受信した時の値を保持する様にするべきではないか。
    もしくは一旦受信したら blehook で削除しておく。

2021-02-21

  * decode (rlfunc): vi-replace in imap, vi-editing-mode in nmap (reported by onelittlehope) [#D1484]

    それから vi-replace in imap 及び vi-editing-mode in nmap は未実装である。

    * vi-editin-mode in nmap: 先ずは vi-editing-mode を vi-command で使うと何が
      起こるのかについて確認する。→どうやら vi_nmap を抜けて imap に戻る様であ
      る。うーん。これは単に vi_nmap/insert-mode にすれば良い気がする。

    * vi-replace はどうやら replace-mode に入る為のコマンドの様だ。そしてこれは
      insert と同じで良いのではないか?? と思ったがうーん。vi-command では "R"
      に割り当てられている。つまり、文字幅に応じた replace-mode に入るべきであ
      る。

      | vi_imap でも同等の replace-mode に入るための widget を追加するべきだろう
      | か。と思って、vi_imap/normal-mode-without-insert-leave &
      | vi_nmap/replace-mode を組み合わせて新しい widget を作りかけていたら、どう
      | やら既に存在していた様だ。vi_imap/overwrite-mode である。というより、既定
      | の insert がこれになっていた。
      |
      | なので作りかけた以下の関数は廃止。
      |
      | function ble/widget/vi_imap/replace-mode {
      |   ble-edit/content/clear-arg
      |   _ble_edit_mark_active=
      |   _ble_edit_overwrite_mode=R
      |   _ble_keymap_vi_insert_overwrite=R
      |   ble/keymap:vi/update-mode-name
      | }

      所で、既存の vi_imap/overwrite-mode は ble-edit/content/clear-arg がない
      が良いのだろうか。と思ったが、よく考えたら vi_imap では引数を指定する方法
      が存在しない。という事を考えたら別になくても良いという事なのだろうか。ま
      あ、ble-edit/content/clear-arg して困る事はない。もしかすると誰かが
      vi_imap でも arg を設定できる様に binding を追加するかもしれない。

    結局二つとも既存の widget を辞書に登録するだけで済ませる事にした。

  * decode (rlfunc): 既存の束縛の読み取り時にエラー (reported by onelittlehope) [#D1483]
    https://github.com/akinomyoga/ble.sh/issues/89

    二種類の問題がある。

    * 一つは LC_CTYPE であろう。現在のエンコーディングに一致しないバイト列が文
      字列に含まれている場合、bash の正規表現は一致に失敗する。もしくは何か変な
      一致の仕方をする。

      $ alpha=$'"\x9B": self-insert'
      $ rex='^"[^"]*$'
      $ [[ $alpha =~ $rex ]]

      然し実際に試してみたがそんな事は起こっていない。susu-linux の regcmop は
      振る舞いが違うという事なのだろうか。これについては no closing ... という
      メッセージを出している部分をもう少し詳しく見る必要がある。

    * もう一つは vi_imap/vi_nmap で vi-replace/vi-editing-mode に対応していない
      という事。これは単に対応していないというだけの事なのでできるだけ対応する
      様にする。

      然し、以下は期待通りに動いている。

      rex='^"([^\"]|\\.)*$'
      [[ $'"\x9B": self-insert' =~ $rex ]]; echo $?

      できた。再現できた。

      bind '"\x9b1;2H": beginning-of-line'
      source ble.sh

      更に良くメッセージを見ると正規表現でテストを実行する前に既に文字列が削れ
      て '"' だけになっている。

      →これについては修正した。

    https://github.com/akinomyoga/ble.sh/issues/89#issuecomment-782824259
    追記: 簡単なミスをしていた。修正する。

    https://github.com/akinomyoga/ble.sh/issues/89#issuecomment-782827987
    追記: まだ駄目だった。何度でも同じミスをしている…。ちゃんと実際にテストしなければならない。

2021-02-20

  * term: Cygwin console で最終行で IL/DL すると画面消去されるバグ [#D1482]

    Solaris に加えて Cygwin console も何だか変な振る舞いをしている。
    どうも一番下の行で .insert-newline をすると画面の内容が全て消える。
    分かった。どうやら一番下の行で IL すると問答無用で画面クリアされる。
    これは明らかにバグである。Cygwin をアップデートしてみる事にする。

    →cygwin を update して見たが修正されていない。なので、結局 ble.sh の側で対
    策をしなければならない。この様な壊れた IL に対して対策を実行する事は可能な
    のだろうか。

    * 取り敢えず現在位置が分かっていれば対応は可能である様に思われる。一番下の行
      にいる時には IL の代わりに CSI 2K を実行すれば良い。それ以外の行にいる時に
      は特に問題は起こらない様だ。

      うーん。最下部にいるかどうかで振る舞いを変えるのは難しい気がする。取り敢
      えず複数行の IL, DL の時にはちゃんと計算ができていれば最下行になる事はな
      い。問題は単一行の IL 及び DL で以下に最下行での IL/DL を避けるかという事。

      最下行にいない時には以降の内容を下に一行ずらす役割がある。うーん。それよ
      り下に内容があると分かっている場合には IL/DL を実行し、それより下に内容が
      ないという場合には DL を実行するというのが可能な対策方法である。

      うーん。かなり面倒臭い。というより CYGWIN の側で修正してもらえばこの様な
      面倒な事はしなくても良い筈なのである。取り敢えずこの workaround の為に本
      体の描画アルゴリズムを変更する事はしない事にする。

      IL/DL の中だけで対策可能であればそれを実施する。そうでなければ何もしない。

      例えば IND CUU を実行して一番下の行にダミー行を挿入して、その上で DL/IL
      を実行してから、RI かスクロールを実行してまた元に戻すという実装は可能だろ
      うか。→ SD,SU を実行してみたが消えてしまった行は戻ってこない様である。RI
      も同様に一度消えた内容が戻って来る物ではない。うーん。現在最下行にいるか
      どうかを判定して動作を切り替えるしかないのか。

    | a 結局 DSR(6) で現在位置を問い合わせて一番下の行にいる時には CSI 2K で行
    |   消去する事にした。
    |
    | x これで以前よりも全画面消去が起こる場面は減ったが、それでもやはり全画面消
    |   去が依然として発生している。何故だろうか。IL/DL を実行している箇所は既に
    |   全て抑えてある。とすれば IL/DL とは別に未だ全画面消去を引き起こす物が存在
    |   しているという事。
    |
    |   問題が発生している場所での出力内容を確認すると
    |
    |   ^[(B^[[m^[[1B^M^[[2K^[[1M^[(B^[[m^[[1A^[[31C^[(B^[[m
    |
    |   printf '\e(B\e[m\e[1B\r\e[2K\e[1M\e(B\e[m\e[1A\e[31C\e(B\e[m'
    |
    |   うーん。全消去が起きそうな気配は何処にもない気がする。と思ったが、よく見
    |   たら DL(1) が含まれている。これは一体何処から現れたのだろう…。あー。分かっ
    |   た。。DSR(6) で問い合わせする前に flush しないと駄目だ。
    |
    |   そして各スタックにある DRAW_BUFF にアクセスして出力予定の内容を全て集めて
    |   flush しなければならない。然し、DRAW_BUFF の中には取り敢えず内容を構築し
    |   て保存する為の物だったり、後で再解釈する為の物だったりする可能性もあり、
    |   一律に出力して良い内容7日どうかも分からない。という事を考えると put-il,
    |   put-dl の中で現在位置を検出して出力するという対策は全然駄目である。
    |
    |   | if ((_ble_bash>=40000)) && [[ ( $OSTYPE == cygwin || $OSTYPE == msys ) && $TERM == xterm-256color ]]; then
    |   |   # Cygwin console (pcon) では最終行で IL/DL すると画面全体がクリアされる。
    |   |   function ble/canvas/.put-il.workaround {
    |   |     local count=$1
    |   |     ((count==1)) || return 1
    |   |
    |   |     # Cygwin console 以外なら対策不要
    |   |     [[ ! $_ble_term_DA2R ]] || return 1
    |   |
    |   |     # 現在のカーソル位置の取得
    |   |     local reply=
    |   |     printf '\e[6n' >/dev/tty
    |   |     IFS= read -r -d R -t 0.1 reply </dev/tty
    |   |     local rex='([0-9]*);([0-9]*)'
    |   |     [[ $reply =~ $rex ]] || return 1
    |   |     local l=$((10#${BASH_REMATCH[1]}))
    |   |     local c=$((10#${BASH_REMATCH[2]}))
    |   |
    |   |     ((l==LINES)) || return 1
    |   |
    |   |     DRAW_BUFF[${#DRAW_BUFF[*]}]=$_ble_term_el2
    |   |     return 0
    |   |   }
    |   |   function ble/canvas/put-il.draw {
    |   |     local value=${1-1}
    |   |     ((value>0)) || return 0
    |   |     ble/canvas/.put-il.workaround "$value" && return 0
    |   |     DRAW_BUFF[${#DRAW_BUFF[*]}]=${_ble_term_il//'%d'/$value}
    |   |     DRAW_BUFF[${#DRAW_BUFF[*]}]=$_ble_term_el2 # Note #D1214: 最終行対策 cygwin, linux
    |   |   }
    |   |   function ble/canvas/put-dl.draw {
    |   |     local value=${1-1}
    |   |     ((value>0)) || return 0
    |   |     ble/canvas/.put-il.workaround "$value" && return 0
    |   |     DRAW_BUFF[${#DRAW_BUFF[*]}]=$_ble_term_el2 # Note #D1214: 最終行対策 cygwin, linux
    |   |     DRAW_BUFF[${#DRAW_BUFF[*]}]=${_ble_term_dl//'%d'/$value}
    |   |   }
    |   | fi
    |
    | b 別の手段を考える。一番上の行を犠牲にする事になるが SU/SD を組み合わせる。
    |
    |   DRAW_BUFF[${#DRAW_BUFF[*]}]=$'\e[S\e[A\e[M\e[B\e[T'
    |
    |   うーん。一応動いている様な気がするが、この対策法の問題点は DA2 を返さない
    |   端末で SU/SD に対応してない物があると描画がずれてしまうという事である。
    |
    |   あとちらつきが激しく出ているという事。やはり対策を実施するのは最
    |   低限にしたい。
    |
    | c また別の手法。一番下の行は諦めて DL/IL をする前に必ず IND/CUU を実行して
    |   一番下の行は使わない様にするという作戦。これは実際に試してみた所レイアウ
    |   ト崩れるので使えない。

    改めてそれぞれの方法の問題点について整理する

    a DSR(6) で問い合わせて判定する方法。

      o この方法は出力をキャッシュしていなければ確実に最終行を判定できる。

      x 然し実際にはカーソル移動なども含めて出力内容を複雑にキャッシュしている
        ので、その場で現在位置を取得したとしても全く意味がない。キャッシュを
        flush するにしても、それぞれのキャッシュがその場で画面に出力する事を想
        定した物でない場合もあり困難。

    b SU/SD の組み合わせを用いる。

      x 一番上の行の内容が犠牲になる。
      x 画面がちらつく。

        o これについては panel 内部で動作している限りは panel の最終行にいる時
          にだけ対策をする。これでちらつきはある程度抑える事ができる。それでも、
          panel の最終行にいる時にはちらつきが出るが、そもそも本当に最終行にい
          る時のちらつきは抑える事ができないので、我慢する。

      x Cygwin console であると誤判定した時に、その端末が SD/SU に対応していな
        いと悲惨な事になる。

    c 一番下の行は常に空になる様にしておく。

      x 使える領域が一行減ってしまう。
      x 今までの座標計算が狂ってしまうので注意深く全体を書き直す必要がある。

    d panel で一番下の行にいると分かっている時は単に EL(2) で良い。

      panel で一番下の行にいるという事が分かっている場合には、IL を一番下の行
      で実行する代わりに単に端末の最上部で DL をすれば良いのではないだろうか。
      と思ったが全然違う結果になるので駄目だ。

      或いは panel で一番下の行にいるという事が分かっているのであれば何処か別
      の行で IL/DL すれば良いのではないか。と思ったが、それだと端末最終行にい
      なかった時にずれるべき内容がずれずに残るのではないか。と思ったが、そも
      そも panel 外の内容に関しては関知しなくて良い。

      整理すると panel で一番下の行にいる時、panel の最上部で IL/DL を実行す
      る。その上で panel の最下部で EL(2) を実行すれば良い。うーん。実は最下
      部で EL(2) を実行するだけで良い気がしてきた。

    結局 b に d を組み合わせて実装した。どうも既存の IL/DL は全て panel 管理下
    にある様だ。という事なので実は実質的に d だけでうまく行くという事。

    x fixed: と思ったがどうも SU/SD の対策がコマンドを実行する度に発動している
      様子だ。と思ったがこれは単純ミスだった。opts=$2 を忘れて opts を使ってい
      た。

    ? IND を \n にして見たが微妙かもしれない。端末によっては現在の x の位置をずらしてしまうから。
      然し、現在の設計では ind によって位置がずれてしまう事も想定しているのではなかったか。

      と思ったが IND に対応していない物も沢山ある様だ。なのでやはり \n に頼るべきなのだろう。

      IND を使っている箇所について改めて確認する必要がある。ちゃんと x=0 にしているか?

      →どうも _ble_term_ind の使用は canvas.sh の中で閉じている様子である。
      put-ind.draw も内部でしか使われていない。殆どの箇所で既に対策済みか或いは
      元から column 0 にいる状態で使っている。

      問題に成るのは ble/canvas/put-move-y.draw の内部での使用で、mc の中で動作
      している時には CUU の代わりに IND を使っている。put-move.draw が何処で使
      われているか確認すると相対移動・noscrc で使っている。_ble_term_{sc,rc} も
      使えないし、相対移動なので後で絶対位置を指定して補正というのも使えない。
      ここは IND/LF で col が移動しない状況で使われていると期待するしかない。

      →うーん。現在の init-term だと LF が優先されてしまう。IND に端末が対応し
        ている事を期待して $'\eD' を使った方が安全に思われる。

  * term: sum (Solaris console) IND/RI が使えない。他色々動いていない [#D1481]

    * RI が使えない時にどの様にすれば良いか。

      * 使っている箇所の一つは vbell である。

        例えば prompt の上の行に一行 IL するという方針だと…。vbell を表示する度
        にずれてしまう。今ここで欲しいのは "上に一行も余裕がない時限定で一行確保
        する" という機能である。

      * ble/canvas/put-ri.draw

        これは2箇所から使われている。両方とも
        ble/canvas/panel/ensure-tmargin.draw という関数の中から使われていて、この
        関数は vbell から使う為の物である。

      * ble/canvas/panel#clear-after.draw
        これは単に cuu に置き換えれば良い気がする→置き換えた。

      結局 vbell が問題になる。_ble_term_ri が空の時に別の手法で vbell を表示す
      る?

      a 例えば xterm_title を使って表示するか。

        元から設定されている値を保存・復元したりするのが面倒である。push/pop の
        エスケープシーケンスも存在するかもしれないが、それに対応しているかどう
        かの判定も面倒である。というより RI を対応していない端末が xterm title
        等に対応しているとは思えない。この手法は追求しても余り意味がない。

      b 或いは、一番下の行に表示するというのは可能だろうか。

        この方法を取る場合には現在の canvas の tmargin の取り扱いを工夫しなけれ
        ばならない。というか RI が使えない場合には canvas の tmargin も振る舞い
        が微妙な気がする。

      c もしくは _ble_term_ri を使わずに被っても良いので先頭行を使う。

        然し、やはり内容が上書きされてしまうというのは都合が悪い様に思われる。

      d もしくは毎回一番上に行を挿入する。

        この方法だと bell が表示される度に行がどんどん下の方に移動してしまって
        余り嬉しい事にはならない。一応 IND を使って下に行きすぎない様に調整する
        事はできる。top/bottom dock に分かれている場合には制御が面倒である。

        現在の ble/canvas/panel/ensure-tmargin.draw の実装について確認する。
        DECSTBM が存在する場合には、スクロール領域を設定して bottom dock を固定する。
        その上で RI を実行して canvas 原点の上に tmargin 行だけスペースを確保する。

        それ以外の場合には即座に RI で canvas 原点の上にスペースを確保する。
        bottom に関しては破壊されてしまうのは我慢して invalidate する。

        さて、RI が使えない場合にどの様に内容をシフトするのか。場合分けして考え
        る。DECSTBM が使える場合にはやはり bottom dock を固定して於いて、その上
        で、top_height+tmargin だけ IND を実行する。これで少なくとも top dock
        の下に tmargin だけのスペースができる。その後で IL を一番上で実行すれば
        良い。

      うーん。完全ではないが d の方針で何とか誤魔化す事にした。

    * done: modifyOtherkeys がそのまま出力される。

      これは linux や minix と同様に出力しない様に変更。

    * done: home csi 214 z / end csi 210 z

      これは contra の escseq.html にまとめてある物に一致する気がするので確認する。

    * done: OSC がそのまま出力されている

      面倒なので xterm_title の所で直接 term の判定を行って切り替える。
      OSC を無視できるかどうかを各 OS のコンソールで確認する。
      freebsd, linux, haiku ではちゃんと無視できている。
      minix 及び sun は失敗している。

    * prompt_eol_mark 関連のカーソル移動に使われているシーケンスにも問題のある
      物がある。_ble_term_sc, _ble_term_rc の既定値が \e[s, \e[u になっていたが、
      これらは寧ろ少数派なので \e7, \e8 に切り替える事にした。Solaris では
      terminfo に \e7, \e8 は載っていないが実際には使える。

      また _ble_term_xenl に関しても terminfo になかった事から既定で 1 になって
      いたが、Solaris では 0 にする必要がある。修正した。序でに xenl がない時に
      は 0 ではなくて空文字列にする事にする。

    x ok: RI がない時の vbell の振る舞いが駄目。再度実装を確認する。
      うーん。幾らか修正して、更に必要な時にだけ高さを確保する様に変更した。

      そもそも sun console は下から出ていくと上に戻るという変な振る舞いをするの
      でまともに対応するのが難しい。適当な所で良しとするのが良い。

    * done: delete キーで ^? (DEL) が送信される。これについては TERM=sun* の時
      に ^?  を delete に変換して対策する事にした。実は既に infocmp kdch1 が ^?
      の時にはこの対策が実施されていたが、sun* の terminfo に kdch1 が登録され
      ていなかったのが原因だった。

    x 文字 x が入力できない。emacs にするとちゃんと入力できる。.blerc を別名に
      すると入力できる。と思ったがこれは set -o vi が実行されなくなるからだった。
      更に時々 segfault もする。またランダムな文字列を実行しようともする。

      これは恐らく "x?" で bind が形成されてその後でそれが削除される事により、
      x 単体の入力に対して出鱈目な文字列が実行されているという事なのだろう。
      では誰が x に bind しているのだろうか。。不思議である。

      うーん。inputrc は存在していないし、bind は特に直接呼び出されてはいない様
      だし、という事を考えると ble.sh で呼び出している builtin bind が問題を起
      こしているという事なのだろうか。

      generate-source-to-unbind-default の出力を保存してそれを読ませてみたら
      問題が発生するという事が分かった。特に問題のある行もない…と思いきや、

      builtin bind -r 'x1c' (bash-4.1)

      という変な行が混入している。これは一体何処から出てきた物だろうか。普通に
      動いている環境で実行してみると

      builtin bind -r '\x1c' (bash-4.4)

      という結果になっている。つまり、これは bash-4.1 特有の処置ではなくて一般
      に行われている処置である。

      問題の箇所を確認してみると awk で sub(/.../, "\"\\x1c\"") としている。
      つまり Solaris awk はこの \\ を消してしまうという事。と思っていたら、
      既にその問題点についてコメントに書かれていた。'\'' に対しては対策されていたが、
      直接 \ が現れる場合については対策されていなかったのが原因。
      特に \x の組み合わせが x に変換されてしまうという問題の様である。
      \x についても対応すると共にコードの整理を行った。

  * complete/mabdb: man awk の内容を抽出しきれていない [#D1480]

    先ず .PD という行が挿入されている事が原因の様である。
    .PD という行は皆無視しても良い様な気がしたので無視する。
    更に、複数のオプションに対して一つの説明がなされている場合に対応した。

    キャッシュファイルは LANG 毎に別にするべき気がする。特に LC_MESSAGES に従って
    設定するべき。

  * edit: "echo " の状態で \C-x\C-v するとバージョン情報が灰色 [#D1479]

    これは外部コマンドを実行する時に sgr0 をちゃんとしていないのが原因。何処で
    sgr0 をすれば良いのかと悩んだが取り敢えず insert-newline は新しい行に行くと
    いう意味なのだから sgr0 するのが自然である。他に外部コマンドを実行する瞬間
    にも sgr0 を実行する。

  * bash-4.4 で emacs mode で C-x * が効かなくなっている [#D1478]

    vi から emacs モードに切り替えると emacs モードで C-x が効かない。
    keyseq-timeout が長い時には問題は起こらない。

    [状況]

    | これは keyseq-timeout が関係している様だ。更に、一度 emacs モードにしてしま
    | うと、vim モードに戻しても依然として効かない状態が続いている。
    |
    | keyseq-timeout を長く設定してみたところ問題は発生しなくなったので、これはつ
    | まり "C-x ?" の組み合わせで 登録してキーを読み取ろうとしている事自体に何ら
    | かの問題があるという事なのだろう。という気がする。
    |
    | 然し vi に戻しても問題が持続しているのは不思議な事である。詳しく調べてみる
    | と vi に戻すと C-x 一回の入力に付き C-x が2回入力されている様子である。不思
    | 議な事である。
    |
    | * 普通に emacs モードから始めた場合には問題は起こらない。
    | * 同じモードで detach/attach しても問題は起こらない。
    | * 一回のコマンドで ble/decode/detach; ble/detach/attach しても問題は起こらない。
    | * ble-detach して set -o して ble-attach すると再現する。
    |
    | % 問題の一部は分かった。unbind cache に於いて "C-x ?" の組み合わせについて
    | % emacs モードの時にしか unbind していない。然し、これはモードに拘らず
    | % unbind するべきではないのか。つまり、set -o でモードを切り替えた時には元々
    | % と異なる keymap になっている為に [[ -o emacs ]] で判定したのと異なる
    | % keymap に作用する可能性がある? と思ったがそれは変だ。[[ -o emacs ]] になっ
    | % ているのであれば実際にその keymap になっている筈だし、unbind する時には一
    | % 旦元の keymap にしてから戻す様にしていた筈である。実際に
    | % ble/decode/detach においてその様に処理している。
    |
    | * ble-bind -m emacs -P で確認した限りは特に違いは見られない。という事を考え
    |   るとやはり bind の側の問題であろう。何故違いが生じるのだろうか。
    |
    | 全く同じ binder を用いていても問題が生じる物なのだろうか。何より異なる
    | keymap に対して作用しているのに影響が出るのは何故だろうか。うーん。
    |
    | うーん。builtin bind の呼び出しを全て検査すれば大丈夫だろうか。
    | と思って builtin を置換する実験をして見たら滅茶苦茶になる。
    | 何かと思ったら eval を通して $* を参照する場合には、
    | 関数の中から実行すると $* が変わってしまって駄目という事。
    | なので、builtin を置き換えて bind の呼び出しを監視する作戦は使えない。
    |
    | 直接 bash のソースを弄ってデバグする? うーん。
    | そもそも一体どういう状態になっているのかというのが謎である。
    | vi の時には何故二回連続で C-x が受信される事態になっているのか。
    | 本当に C-x が二回連続で受信されているのだろうか。。
    | 或いは C-xC-x の entry が xmap にされていると
    | C-x に対しても勝手に C-x C-x のマッピングが呼びされてしまうという事なのか。
    | もしそうだとしたら再現は簡単で良い。

    というより version 毎にちゃんと動いているか確認する。

    bash-4.4 vi: 動いている
    bash-4.4 vi->emacs: 駄目(何も受信されない) #1
    bash-4.4 vi->emacs->vi: 駄目(C-x が二回受信される) #2
    bash-4.3: 全部OK
    bash-4.2 vi: 動いている
    bash-4.2 vi->emacs: 動いている
    bash-4.2 vi->emacs->vi: 駄目(何も受信されない) #3
    3.0..4.1 は 4.2 と同じ振る舞いである。

    取り敢えず 4.4 の振る舞いだけは修正したい。

    うーん。#2 については何が起こっているか分かった気がする。以下で再現できる。

      $ bash-4.4 --norc -o vi
      $ bind -x '"\C-x":echo X'
      $ bind -x '"\C-x\C-x":echo XX'
      $ bind -r '\C-x\C-x'
      kbd <C-x><500ms> → XX と表示される

    #1 についても何が起こっているか分かった気がする。

      $ bash-4.4 --norc
      $ bind -r '\C-x'
      $ bind -x '"\C-x\C-x":echo XX'
      $ bind 'set keyseq-timeout 1'

    この状態だと C-x を押して timeout すると何も起こらない。
    keyseq-timeout を短く設定してしまうのが問題という事。

    問題 #3 では何が起こっているのだろうか。何も受信できていないというのが気に
    なる。emacs に移動した時に既に \C-x\C-x の bind -x & bind -r は終わっている
    筈である。この時点で cmd_xmap は問題がない筈。

    #3 に関しては以下の様にして再現する事ができる。

    $ bind -x '"\C-x\C-x":echo XX'
    $ bind -r '\C-x\C-x'
    $ set -o vi
    $ bind -x '"\C-x":echo X'
    kbd <C-x>

    [対処]

    | 敢えて \C-x\C-x の場所に何か変な値を設置しておく?
    | というかこれは元々の \C-x を検出する時の問題に関係するのではないか。
    | 実は以下のようにおけば問題ないのでは。
    |
    |   bind -x '"\C-x\C-x":C-x 用の文字列'
    |   bind -r '\C-x\C-x'
    |   bind -x '"\C-x":C-x用の文字列'
    |
    | 少し実験してみる事にする。
    |
    | 取り敢えず問題の再現から。bash-4.2 で以下で落ちる事を確認した。
    | bash-4.1,4.0,3.2 でも同様に落ちる。bash-3.1,3.0 では変な文字列を実行しよう
    | として失敗する。以前の実験で 3.2 だけ無限ループになったのは偶々だったのでは
    | ないかと思われる。
    |
    |   bind -r '\C-x\C-b'
    |   bind -x '"\C-x":echo X'
    |   kbd <C-x><C-b>
    |
    | さて、これの WA として \C-x\C-x を一回 bind してから unbind すると
    | いうのは有効か確認する。うーん。
    |
    | o 一応この対策をして置けば何れの場合にも crash はしなくなる。
    |
    | o bash-4.4 の場合にはこれで完全にOK。- 但し、bash-3.0..4.2 の場合にはこれを
    |   実行すると shadow binding timeout が発生しなくなってしまうので、-o emacs
    |   の時にだけ実行する様にした方が良い。
    |
    | 0 bash-3.0..4.2 の場合には vi->emacs->vi とした時に C-x で何も受け取れなく
    |   成る問題 #3 は持続している。然しそれでも、従来行っていた "C-x ?" に全て
    |   bind する作戦と同等の振る舞いを一つの binding で実現できているので、これ
    |   だけでも新しい手法に移行する価値はある。
    |
    | vi の側でも bind -x & -r を実行すれば検出できる様にはなるが、C-x 単体での検
    | 出ができなくなってしまう。でもそれは emacs keymap を一度でも使うのであれば
    | 避けようがないので、受容するしかない。或いは、emacs でも vi の上で動作する
    | 様にすれば良いのかもしれないが…。
    |
    | 取り敢えずこれがどの bash version でも再現するのかを確かめる。Bash-4.0 以下
    | では C-x を押すと行が新しくロードされる。これが意味する所は、 bind -x によっ
    | て unix_execute_command は呼び出されているが、対応する文字列の探索に失敗し
    | ているという事の気がする。
    |
    | ? 或いは一度は却下した bind -s '"\C-x": "\xC0\x98"' を用いる方法について再
    |   検討しても良いのかもしれない。遅延が生じるという事が述べられているが、ど
    |   の bash の version で起こるのか等について記録が残っていない。
    |
    |   * 先ずは遅延を再現しなければならない。そしてどの様な状況で問題になるのか
    |     を確認しなければならない。
    |
    |     →うーん。bash-4.4 で bind 'set keyseq-timeout 500' にしたら再現できた。
    |     これは何故発生しているかと言うと C-x ? が (過去に) 存在していた時に
    |     '"\C-x":"\xC0\x98"' を実行する為には結局 timeout/mismatch が必要だから
    |     である。
    |
    |     然しこの遅延に関しては "C-x ?" 全バインドの手法を取ったとしても共通であ
    |     る。特に問題になるのは C-x C-x と連続で入力した時に、この C-x C-x の組
    |     で認識されれば即座に反映されないという事である。"C-x ?" なら即座に反映
    |     される。'"\C-x":"\xC0\x98"' だと
    |
    |       C-x C-x
    |       \xC0 \x98 C-x
    |
    |     の様な形になるので余った C-x が残ってしまう。
    |
    |   x 更に、bash-4.2 で '"\C-x":"\xC0\x98"' を適用してみたが、結局遅延が存在
    |     する事には変わりがない様で、意味がない。bash-4.3 以降は現在は問題なく動
    |     作するので、対策は bash-4.2 以下に対してになるが、bash-4.2 以下では
    |     keyseq-timeout を指定する事もできないのでこの遅延をどうにかする事はでき
    |     ない。
    |
    | ? というかこの単一 bind 手法だと結局 C-x C-x とした時に遅延が生じるのではな
    |   いだろうか→確かめた。実際にそうだった。やはり単一 bind は駄目である。
    |   bash-4.4 ならば keyseq-timeout を短くすれば未だ何とかなるが bash-4.2 以下
    |   では次の操作をしない限りは C-x C-x に対して結果を受信する事ができない。

    [対処法比較]

    単一C-x (C-xC-xを一旦設定)

      4.4 ... keyseq-timeout の分だけ遅延が生じる。keyseq-timeout を 0 にすれば
        問題ない。何故 timeout 遅延が生じるのかと言うと、元々 emacs keymap には
        C-x ? の組み合わせが登録されていて、それらが全て削除されていたとしても
        (或いは削除しきれていないのかもしれない)、確定状態にならないからなのだ
        と言う気がする。

        ※C-xC-xを一旦設定する措置をしないとコマンドが登録されていない旨のエラー
        が発生する。

      4.2 ... timeout がないので key 一個分だけ遅延してしまう。keyseq-timeout
        を 0 にする訳にも行かない。

        ※C-xC-xを一旦設定する措置をしないとそもそも、次の key が来ていざ確定し
        た時にクラッシュしたりランダムな文字列を実行したりして問題になる。

    全 "C-x ?" の束縛 (C-x は unbind しておく)

      4.4 ... keyseq-timeout により timeout が発生すると "C-x" 単一で確定が為さ
        れるが、その時に何も実行されない。keyseq-timeout を十分長くすれば気にな
        らなくなる…かもしれないが、それでも振る舞いとしては微妙。

        ※C-x にも bind する様にしておくと今度は C-x に対して C-xC-x に対応する
        コマンドが実行されてしまう。

      4.2 ... key 一個分の遅延はない。emacs では特に何も問題は発生しない。但し、
        一旦 emacs で "C-x ?" の組み合わせに対して全 bind を実行していると、vi
        の側で単一 C-x に対して bind しようとした時に支障が出る。

        これを防ぐ為には "C-x ?" の組み合わせについて直接 -x を設置するのではな
        くて、文字列マクロ経由で読み取る様にするべきではないか。という事。この
        時の問題は…。やはり \C-x が再び現れると key 遅延が発生する事。つまり、
        bind '"\C-x\C-x":"\xC0\x98\x18"' 等とすると、\x18 (\C-x) に対して再び
        key 一個分の遅延が発生する。なので、'"\C-x\C-x":"\xC0\x98\xC0\x98"' と
        する必要がある。

        * 一方で、"\xC0" や "\x98" に関しては複数バイトの束縛は行わないので、
          "\xC0" の timeout/key 遅延について問題が新しく発生する事はない筈。

    Bash 4.4 では単一 C-x を採用する。Bash 4.2 以下では今まで通り "C-x ?" を全
    束縛するが、vi に影響が出ない様にマクロ経由で束縛する事にする。

2021-02-18

  * syntax: !; 及び time; の後の文脈 [#D1477]

    !; 及び time; の後の文脈で } fi done esac を要求しているが実際は任意のコマ
    ンドの筈である。少なくともそうなっている様に見える。問題の部分では #D0592
    を参照しているが、これは大きな書き換えなので特にこの部分で何故この様にした
    のかは謎。コメントには明示的に CTX_CMDXE と書かれている。そんな事はない筈な
    のに不思議である。

    よく #D0592 を見てみたら "time ; echo" でエラーになると書かれている。
    うーん。bash の version かと思って試したらそうだった。bash 4.3 以前は
    "time ; echo" がエラーになるのであった。一方で 4.4 以降は OK

2021-02-15

  * 2017-10-01 syntax: case $x in (a b) : ;; esac のパターン "a b" はエラー [#D1476]
    これも #D1474 で対応した。此処に挙げられているテストケースは有用だった。

    どうやら一個の単語までしか駄目な様子?

    更に case aaa in ((aaa)) echo;; esac 等の様に () の入れ子もエラーになる。
    shopt -s/-u extglob に拘らずエラーになる。
    一方で extglob の @() に関しては中で () の入れ子が可能である。
    つまり、case の中の (...) と extglob @(...) の文脈は異なる。

    他にも違いはある。@(<>) は許されるが、in (<>) は許されない。
    @(&&) は許されるが in (&&) は許されない。
    in (a|a|a) は許されるが in (a||a) や in (||) は許されない。
    in (&), in (|), in (;), in (<), in (>) は何れも駄目。
    in (a&b), in (a;b), in (a<b), in (a>b) も何れも駄目。

    どうも全然違う文脈の様に思われてきた。

    現在の実装では ble-syntax:bash/ctx-case から CTX_PATN に突入している。
    (他に CTX_PATN に入っている箇所を探すと、
    関数の引数の括弧に何か変な物が入っている場合と、
    コマンドの途中で突然括弧が現れた場合である。
    これらはエラーに対する復帰としての CTX_PATN なのでそんなに気にしなくて良い)

    どうも振る舞いを観察すると ctx-conditions と ctx-globpat の中間のように思う。
    単語を設置しなければならないという観点で言うと ctx-conditions に近い。
    一方で対応している構文の集合という観点で言うと ctx-globpat が幾らか近いように思う。

    2017-11-27 追記
    どうやら () の中の単語ではチルダ展開も有効のようだ。以下で hello が出力される。
    case a=~ in (a=/home/murase) echo hello; esac # これは対応済み
    case a=/home/murase in (a=~) echo hello; esac

  * syntax: case x) とした時の ")" の着色が括弧でちゃんと囲んだ時と異なる [#D1475]
    これは #D1474 における再実装で一緒に修正した。

  * syntax: case a in @) で @() と入力すると fatal error [#D1474]

    case a in ) の状態でパターンに @() を入力しようとするとシフトエラーになる

    | もっと具体的に調べてみると case a in @) の状態で @ の直後に ( を挿入する
    | となる。シフトエラーになるという事は case a in @) と入力した時点で壊れて
    | いると考えられる。
    |
    | | 先に ) を入力した時
    | | $ case a in @)
    | | _ble_syntax_attr/tree/nest/stat?
    | | 18 a    000 'c' | stat=(CMDX w=- n=- t=-:-)
    | |  | a    001 'a' |
    | |  | a    002 's' |
    | |  | a    003 'e' + word=CMDI:0-4/(wattr=d)
    | | 39 a    004 ' '   stat=(CARGX1 w=- n=- t=$4:-)
    | | 40 a    005 'a' + word=ARGI:@3>5-6/(wattr=d) stat=(CARGX1 w=- n=- t=$4:-)
    | | 41 a    006 ' '   stat=(CARGX2 w=- n=- t=$6:-)
    | | 42 a    007 'i' | stat=(CARGX2 w=- n=- t=$6:-)
    | |  | a    008 'n' + word=CARGI2:@5>7-9/(wattr=d)
    | | 34*a    009 ' '   stat=(CASE w=- n=- t=$9:-)
    | | 30*a    010 '@' | nest=(CMDX w=- n=- t=$9:-) stat=(CASE w=- n=- t=$9:-)
    | | 30*a  s 011 ')' + word="none":@8>10-12 stat=(PATN w=- n=@10 t=-:$9)
    | |  |    s 012 ^@   stat=(CMDX w=- n=- t=$12:-)
    | |
    | | 先に @ を入力した時
    | | $ case a in @)
    | | _ble_syntax_attr/tree/nest/stat?
    | | 18 a    000 'c' | stat=(CMDX w=- n=- t=-:-)
    | |  | a    001 'a' |
    | |  | a    002 's' |
    | |  | a    003 'e' + word=CMDI:0-4/(wattr=d)
    | | 39 a    004 ' '   stat=(CARGX1 w=- n=- t=$4:-)
    | | 40 a    005 'a' + word=ARGI:@3>5-6/(wattr=d) stat=(CARGX1 w=- n=- t=$4:-)
    | | 41 a    006 ' '   stat=(CARGX2 w=- n=- t=$6:-)
    | | 42 a    007 'i' | stat=(CARGX2 w=- n=- t=$6:-)
    | |  | a    008 'n' + word=CARGI2:@5>7-9/(wattr=d)
    | | 34 a    009 ' '   stat=(CASE w=- n=- t=$9:-)
    | | 30*a    010 '@' | nest=(CMDX w=- n=- t=$9:-) stat=(CASE w=- n=- t=$9:-)
    | | 30*a    011 ')' + word="none":@8>10-12 stat=(PATN w=- n=@10 t=-:$9)
    | |  |    s 012 ^@   stat=(CMDX w=- n=- t=$12:-)
    |
    | これら二つを比較しても違いは 011 の位置の s という記号のみである。この s
    | というのが何であるかは覚えていないが、実のところこの二つの両方で問題が再
    | 現するので @ を先に入力するか ) を先に入力するかは問題には関係ない。
    |
    | @の代わりに X を挿入した場合にどうなるか調べる。X に引き続いて (
    | を挿入しても問題は発生しない。
    |
    | | $ case a in X)
    | | _ble_syntax_attr/tree/nest/stat?
    | | 18 a    000 'c' | stat=(CMDX w=- n=- t=-:-)
    | |  | a    001 'a' |
    | |  | a    002 's' |
    | |  | a    003 'e' + word=CMDI:0-4/(wattr=d)
    | | 39 a    004 ' '   stat=(CARGX1 w=- n=- t=$4:-)
    | | 40 a    005 'a' + word=ARGI:@3>5-6/(wattr=d) stat=(CARGX1 w=- n=- t=$4:-)
    | | 41 a    006 ' '   stat=(CARGX2 w=- n=- t=$6:-)
    | | 42 a    007 'i' | stat=(CARGX2 w=- n=- t=$6:-)
    | |  | a    008 'n' + word=CARGI2:@5>7-9/(wattr=d)
    | | 34 a    009 ' '   stat=(CASE w=- n=- t=$9:-)
    | | 30 a    010 'X' | nest=(CMDX w=- n=- t=$9:-) stat=(CASE w=- n=- t=$9:-)
    | | 30 a    011 ')' + word="none":@8>10-12 stat=(PATN w=- n=@10 t=-:$9)
    | |  |    s 012 ^@   stat=(CMDX w=- n=- t=$12:-)
    |
    | 然し木構造を調べても X の時と @ の時で全く同じ状態になっている。な
    | のにシフトでエラーが発生するというのは不思議である。
    | →改めて確認した所、一番最初に発生するエラーはシフトエラーではなかった。
    |
    | | ble/syntax/tree-enumerate/.initialize/FATAL2
    | |   @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:4 (ble/syntax/tree-enumerate)
    | |   @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:6 (ble/syntax/print-status/.dump-tree)
    | |   @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:8 (ble/syntax/print-status)
    | |   @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:74 (ble/highlight/layer:syntax/update)
    | |   @ /home/murase/.mwg/src/ble.sh/out/ble.sh:13 (ble/highlight/layer/update)
    | |   @ /home/murase/.mwg/src/ble.sh/out/ble.sh:10 (ble/textarea#update-text-buffer)
    | |   @ /home/murase/.mwg/src/ble.sh/out/ble.sh:76 (ble/textarea#render)
    | |   @ /home/murase/.mwg/src/ble.sh/out/ble.sh:3 (ble-edit/bind/.tail)
    | |   @ /home/murase/.mwg/src/ble.sh/out/ble.sh:18 (ble-decode/EPILOGUE)
    | |   @ /home/murase/.mwg/src/ble.sh/out/ble.sh:79 (ble-decode/.hook)
    |
    | print-status の段階でエラーが発生している。つまり、直前の状態が問
    | 題なのではなくて ( を入力した直後の状態が壊れているのである。
    |
    | | _ble_syntax_attr/tree/nest/stat?
    | | 18 a e  000 'c' | stat=(CMDX w=- n=- t=-:-)
    | |  | a e  001 'a' |
    | |  | a e  002 's' |
    | |  | a e  003 'e' + word=CMDI:0-4/(wattr=d)
    | | 39 a e  004 ' '   stat=(CARGX1 w=- n=- t=$4:-)
    | | 40 a e  005 'a' + word=ARGI:@3>5-6/(wattr=d) stat=(CARGX1 w=- n=- t=$4:-)
    | | 41 a e  006 ' '   stat=(CARGX2 w=- n=- t=$6:-)
    | | 42 a e  007 'i' | stat=(CARGX2 w=- n=- t=$6:-)
    | |  | a e  008 'n' + word=CARGI2:@5>7-9/(wattr=d)
    | | 34 a e  009 ' '   stat=(CASE w=- n=- t=$9:-)
    | | 31*a e  010 '@' | nest=(PATN w=- n='none':10- t=-:$9) stat=(CASE w=- n=- t=$9:-)
    | |  |*a e  011 '(' |
    | |  6*a es 012 ')' + word="none":10-13 stat=(PATN w=- n=@10 t=-:-)
    | |  |    s 013 ^@   stat=(PATN w=- n=@10 t=$13:$9)
    |
    | というか、")" が存在しなくても普通に @( と入力しただけでエラーになってい
    | る。a@( としている時には大丈夫である。これはつまり単語と nest が同じ場所
    | で始まる事によってエラーになっているという事だろうか。うーん。確かに a@(
    | とすると a の位置と @ の位置の両方に nest が設定されている。という事は、
    | @( を入力した時に同時に二箇所に nest を設定しようとして状態が破壊されてい
    | るのである。だとすると $( でも問題が発生する筈→発生した。" でも問題が発
    | 生した。うーん。根本的に nest を再考する必要があるのかもしれない。

    [状況]

    以下の何れでも問題が発生する。原因は同じ位置に2つの nest を設置しようとして
    いる事にある。

    - case a in @(
    - case a in $(
    - case a in "
    - case a in (x);;"

    nest の位置をずらそうとしても " の場合には一文字しか無いのでずらす事ができ
    ない。逆にパターンの側の nest の位置を一文字前にずらすという事も考えたが、
    必ずしもパターンの前が空白とは限らない。例えば ;; など。この場合には結局同
    じ位置に nest を設置するしかない。或いは ;; の位置に nest を設置してしまう
    という手もあるのかもしれないが、それは不自然だし色々とまた変な問題が発生し
    そうである。

    [修正]

    やはり解決策としては同じ位置に nest を設置できる様にするという事。然し、現
    状のコードで nest が同じ位置に設置されないという前提は何処で使っていただろ
    うか。場合によって単に対応するだけでは済まないかもしれない。

    或いはもう一つの方法として、そもそも case パターンを nest にする必要があっ
    たのかという事。この方法の方が確実に簡単に修正できる気がする。然し、nest に
    した理由は何だろうか。単に既存の CTX_PATN を使いたかったからというのであれ
    ば簡単である。

    コードを確認してみたがやはり nest を使わないとすると新しい文脈値が必要にな
    りそうである。更に、元から case pattern の中は単語が一個だけになる様に制限
    を加える予定だった。これに対応する為には結局新しい文脈値が必要だったのだ。
    case pattern の単語数も一緒に対応してしまうのが良いだろう。

    うーん。実はコマンド文脈で読み取った方が良い? とも思ったがそうでも
    ない気もする。例えば | の取り扱いが異なる。& や ; 等他の delim の
    場合にはエラーにする必要がある。|| は一まとまりではなく一文字ずつ取る。
    | の直後は再び単語を受け付けて OK。など。

    - done: ble/syntax:bash/ctx-command-case-pattern

    実装したが無限ループになってしまう。調べると parse の中で同じ位置に対してずっ
    と計算している。

    parse (i=19): ctx=78 ble/syntax:bash/ctx-command-case-pattern-expect

    $ case x in @() echo ;; esac

    問題は ;; の直前で起きている様だ。これは BASH_REMATCH が途中で書き換わって
    いたのが見落としだった。修正した。OK 動いている。

    ----------------------------------------------------------------------

    2021-02-19 assertion failure が出た。

    assertion failure: ((_ble_syntax_bash_command_isARGI[ctx]))
    invalid ctx=79 in words
      @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:15 (ble/syntax:bash/ctx-command)
      @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:86 (ble/syntax/parse)
      @ /home/murase/.mwg/src/ble.sh/out/ble.sh:7 (ble-edit/content/update-syntax)
      @ /home/murase/.mwg/src/ble.sh/out/ble.sh:75 (ble/textarea#render)
      @ /home/murase/.mwg/src/ble.sh/out/ble.sh:3 (ble/textarea#panel::render)
      @ /home/murase/.mwg/src/ble.sh/out/ble.sh:5 (ble/function#try)
      @ /home/murase/.mwg/src/ble.sh/out/ble.sh:8 (ble/canvas/panel/render)
      @ /home/murase/.mwg/src/ble.sh/out/ble.sh:3 (ble-edit/bind/.tail)
      @ /home/murase/.mwg/src/ble.sh/out/ble.sh:18 (ble-decode/EPILOGUE)

    [再現]

    | 以下のコマンドラインに於いて "'; の ; の前にカーソルを置いて、其処から BS
    | の autorepeat で削除を行うと確率的に上記のエラーが発生する。不思議なのは
    | ctx=79 は最近追加した CTX_CPATQ であり、これは case の時にしか発生しない筈
    | の物であるという事。現状では何処にも case はないので ctx が 79 になる事はな
    | い様に思われる。core-syntax.sh の中を再度確認してみたが混入する事はない気が
    | する。
    |
    | $ debug/builtin() { unset -f builtin; IFS=" " eval 'echo "[$*]"'; builtin "$@"; local _ext=$?; echo "[$* ($_ext)]";
    |   builtin() { debug/builtin "$@"; }; return "$_ext"; }
    |
    | $ d() { unset -f builtin; A=" " : ': "[$*]"'; : "$@"; : a=$?; : "[$* ($a)]"; }
    |
    | $ : helloworldhelloworld; A=" " :; : a=$?; : "[$* ($a)]"
    |
    | あー。成程。79 が現れたのは BS で消す途中に ;; が現れる為である。確率的に発
    | 生していたのは、丁度 ";;" の時に文法の再解析が起こるか起こらないかである。
    | 一つずつ BS を押していれば必ず発生する。
    |
    | $ :; :;: a=$?;:
    |
    | OK. 以下が最小再現コードである。以下の状態から間の空白を削除するとエラーになる。
    |
    | $ ; ;a=1
    |
    | というより変な事をしなくても普通に以下で問題が発生する。
    |
    | $ case x in a=1

    取り敢えず 79 が出るのは別にバグではないという事は確認できた。
    そして修正は簡単だった。これは fixup にする。

2021-02-10

  * ble/builtin/read: 空文字列の時 C-d でキャンセルしない [#D1473]

    使い心地が変だと思って plain Bash で試してみたら C-d でちゃんとキャンセルに
    なる。ble/builtin/read もこれと同様に振る舞うべきである。

    →これも実装した。これは簡単な修正。

  * ble/builtin/read: 全く描画されなくなっている [#D1472]

    これは ble/canvas/panel/render において描画するかどうかを各パネルの高さで決
    定しているが、textarea は textarea#render の中で高さを決定する事にしている。
    なので高さがいつまでも 0 の儘になってしまって結局全く描画されないという事態
    になっている。

    | 本来は描画を実行する前に高さを決定するべきなのである。然し、現在の実装では
    | 中身の計算が重いために必要になるまで計算しない事にしている。うーん。
    | getHeight を受け取った時点で中身の計算を終わらせるべきだろうか。然し、希望
    | の高さを伝えたからと言って必ずしもその高さが通るとも限らないし、結局結果に
    | よっては再計算する必要が出てくる可能性は変わらない。
    |
    | その様に考えると結局現在の様な実装でも変わらないのではないかという気はする。
    | 或いは 0 という高さは特別な高さという事にして中身がある場合には必ず有限の高
    | さを指定する事にする?
    |
    | 然し、0を特別扱いする事にすると一時的に高さを 0 にして再び後で高さが有限に
    | なる可能性がある時、そしてその高さが有限になる機会が render の中で得られる
    | 場合に困る。なので、0 であってもやはり render は呼び出すべきなのではないだ
    | ろうか。
    |
    | うーん。然しそうすると… textarea を隠したい時にも必ず textarea が表示され
    | てしまうという事になってしまう。或いは、textarea を隠したい時には
    | _ble_textarea_panel には -1 などの値を代入しておくというルールにする? とい
    | うよりそもそも表示・非表示という状態は height とは別に持っておくべきなので
    | ある。

    * 表示・非表示の状態は height とは別に持っておくべき。現在の実装では取り敢
      えず各実装に任せる事にする。

    * render では取り敢えず高さ 0 であっても全ての panel について
      $class#panel::render を呼び出す事にする。これは render の中でレイアウトを
      計算する時に高さを変更したくなるかもしれないからである。

    * reject: 将来的には textarea#render を textarea#layout と textarea#render
      に分ける事も考えるべきかもしれない。

    | 少し textarea#layout と textarea#render に分ける事も考えたが、これをして
    | も結局何も変わらない。というのも、textarea#layout で高さを計算する時に自
    | 身の高さを変更すると結局、他のパネルの高さも全て再計算になる。なので、再
    | 帰的な高さ変更の可能性は、高さ計算を textarea#layout に分離したとしても本
    | 質的には解決していない。何か利があるとすれば最後の描画処理が省略できるだ
    | けである。そして最後の描画処理は ble.sh ではそんなに重い処理ではないので
    | 意味がない。
    |
    | また、今まで問題が起こらなかった理由でもあるが textarea は高さを要求する
    | が、info は高さが足りなければ他から奪おうという事はしないので、高さの更新
    | が再帰的になる事はない。特に textarea よりも info の方が後に render を行
    | うという事もあるので特に問題になっていない。(実は今までは info が描画した
    | 内容を textarea が truncate するという事になっていたのではないかという気
    | がするので、現在の実装のほうがよりまともなのであろう)

    * 結局 height 更新の無限ループは可能性として排除できない。それは render の
      中で height 設定をしても、layout の中で height 設定をしても同じことである。
      最終的には誰かが皺寄せを食うという事にしておけば何れにしても問題にならな
      いし、そうでなければそもそも解が存在しない。現在の実装では info が皺寄せ
      を食う事になっている。

  * global: 今度はまた別の連想配列のエラーが出ている (reported by 0xC0ncord) [#D1471]
    https://github.com/akinomyoga/ble.sh/issues/86#issuecomment-776165286

    新しいシェルを開いてもエラーが出ていると書いているが本当だろうか?
    もしこれが同じシェルだとしたら ble-update で駄目な事になるというのは理解できる。
    取り敢えずその為の修正だけは入れる事にした。

  * global: 連想配列の中身が bash-4.2 関数内ble.shソースで消滅する (reported by 0xC0ncord) [#D1470]
    https://github.com/akinomyoga/ble.sh/issues/86

    4.2 で動かないという話。調べると問題の _ble_builtin_trap_n2i は連想配列であ
    る。という事は -g の指定が怪しい。実際に ble.sh を関数内で source したら再
    現できた。

    然し、手元で reduced case を作ってみると動いている様な気がする。WINCH に対
    するシグナル番号を取得する時に結果が空になってしまってい
    る。_ble_builtin_trap_n2i から引いている。然し、 _ble_builtin_trap_n2i の値
    を見るとちゃんと SIGWINCH に対して 28 が割り当てられている様に見える。と思っ
    てよく見てみたら、途中で _ble_builtin_trap_n2i の中身が空になっている。もし
    かして、bash-4.2 だと属性は global まで適用されるが、値が local になってし
    まっているという事か。

    実際に試してみると確かに中身が空になる。うーん。今までは -gA を 40200 以上
    という条件で使っていたが、これは 40300 以上という条件に引き上げるべきだろう。

    * 結局最小再現コードは以下の様になった

      $ bash-4.2 -c 'a(){ declare -gA d=([k]=v);};a;declare -p d'
      declare -A d='()'
      $ bash-4.3 -c 'a(){ declare -gA d=([k]=v);};a;declare -p d'
      declare -A d='([k]="v" )'

    * reject: 判定条件を変数に入れて再利用できるようにする? と思ったがどうせそ
      の次の判定で細かく場合分けするので全体の条件だけ変数に入れて再利用しても
      却って分かりにくいだけである。これは棄却。

    * reject: 連想配列の使い方に応じて declare -gA を使う bash version を切り替える?

      使い方によっては引き続き 40200 でも大丈夫かもしれない。つまり、ble.sh を
      source した段階では空の儘で、実際に使っていく中で中に値をキャッシュすると
      いう場合。或いは、単にキャッシュとして使うという場合にも問題は起こらない。
      然し、実際に関数の中で値が初期化されるかどうかは attach の仕方にも依存す
      る。更に、これは関数内で ble.sh を source するという特殊な場合に於いての
      み影響が出るので余り細かい最適化を考えても仕方がない。

    全て 40300 に書き換えた。まあ、これで何も起こらないだろう。

2021-02-09

  * 2021-02-01: spike branch で tab completion で crash する (reported by 3ximus) [#D1469]
    https://github.com/akinomyoga/ble.sh/issues/82#issuecomment-770390986

    Ref: これは #D1452 / #D1468 と同じ問題。詳細は #D1468 で議論。

    eval-pathname-expansion の中で死んでいるのだろうか。failglob などの判定に失
    敗している可能性もある。つまり、shopt -s failglob が設定されている時に、
    globpat が含まれているのに含まれていないと判定された時に、set -f 等の操作を
    行わずにパス名展開を直接実行して、それにより強制的に終了してしまっている可
    能性。

    →でも元々 failglob があっても大丈夫な様に eval を使って評価していた筈→本
      当だろうか。eval だけで failglob を回避する事ができていたのだろうか。
      syntax の方で .set-result という関数を用意したのは何か理由があったのでは
      ないか。と思ったが、.set-result は failglob を避ける為の物ではなくて展開
      結果を格納する為の物だった。

    →更に、現在の判定方法で globpat を見逃すとも考えづらい。

    実際に手元で failglob の設定下で補完を試みたが変な事は起こっていない。bash
    version の違いかもしれないとも思ったが別に 5.1 でも dev でも変な事はない。
    3.2 や 4.0 4.3 4.4 で試しても違いはない。

    →hangは観測できたという話をしたらどうやら正確にはcrash ではなくて hang し
    ていた様だ。そして振る舞いを見る限りに於いては自分の手元で観測した hang と
    全く同じである。

  * 2021-02-03 TAB completion に於いて conditional-sync で hang する [#D1468]
    Ref: #D1452 と #D1469 は実はこの問題と同一であった。

    chatoyancy で再現している。

    3ximus の報告した crash は観測されていないが代わりに linux 上で hang すると
    いう現象は起こっている。親 shell が固まっていて一方で子 shell はいつまで経っ
    ても終了しないという状態になる。これはどういう状態だろうか。子 shell に対し
    て kill を実行するとその時点で終了して親 shell も使える様になる。時々、再び
    子 shell を生成してそれが固まるという現象は発生している。subshell が発生し
    ている状態で固まっているという様子を見る限りは恐らく conditional-sync で変
    な問題が起こっているのだと思われるが分からない。

    * 親shellの CPU が微妙に動いている。
    * ユーザー入力しても何故か親シェルが中断しない

    改めて condtional sync の実装を確認してみると2回 fork している。1つの fork
    はジョブ管理によって変なメッセージが発生するのを避ける為。2つ目の fork が実
    際に & で bg job を起動する為の物。症状として見られていた hanging shell は
    実は worker ではなくて最初の subshell の様だ。更に詳しく調べてみるとどうや
    ら msleep の中で停止してしまっているようだ。つまりこれは Cygwin 上で発生し
    ていた #D1452 のフリーズと全く同じ問題である。

    Cygwin のテストケースと同じ物で再現できるだろうか。

    ( echo {1..1000} & builtin read -t 0.000100 v < /dev/udp/0.0.0.0/80 ) >/dev/null

    Linux では /dev/udp ではなくて fifo を使っている筈。

    OK 再現した。

    $ mkfifo a.pipe
    $ exec 9<>a.pipe
    $ test1() { (eval "echo {0..$count}" & builtin read -u 9 -t 0.001 v) >/dev/null; echo ok $((count++)); }
    $ bind -t '"\C-t":test1'

    これは結局 bash のバグなので別の場所で議論する事にした。

    workaround を考える。

    A 一つの方向は先ず変な事が起こる発生確率を下げるという事。
      然し、それでも read -t がブロックする可能性は 0 ではない。
      これは実の所 /dev/zero を使っていても同様の筈である。
      とにかく変な事が発生する確率は 0 ではないという事。

      変な事が起こる確率を下げる為に。もう一つの可能性は以下の様に、
      $() を使って fork して、その後で read timeout を
    一番外側で実行するという事。

        { pid=$({ echo OK >&3; sleep 10; } &>/dev/null & echo $!); } 3>&1

      疑問としは孫シェルを wait できるのかという事。→うーん。駄目だった。

        bash: wait: pid 9447 はこのシェルの子プロセスではありません

      wait できない。という事は終了ステータスを検知する方法がない。或いは
      ble/util/assign と同様に終了ステータスは自前のファイル経由で読み取るとい
      う手もあるのかもしれないが…。とにかく面倒になってしまうという事は避けら
      れない。

      そもそもこの方向で問題を軽減できるのかどうかも非自明である。

    B read timeout を使わない方法を模索するべきなのかもしれない。
      然し read timeout が使えないとなるとやはり方法は絞られてくる。
      一つの方法は普通にコマンドの sleep を呼び出すという事。

      然し、spawn のコストと、更に sleep の分解能が秒単位しか無いという可能性が
      ある。そう考えると read timeout はどのシステムでも使う事ができるかなり便
      利な機能だったのである。

    c というよりそもそも conditional-sync ではデフォルトでユーザの入力を待って
      いるのだから、read -t を sleep に使うのではなくて、直接ユーザー入力を検出
      するのに使えば良いのではないのか? と思ったが駄目だ。read -t 0 ならばユー
      ザー入力を読み取らずに検査する事ができるが、read -t 0.001 だとユーザー入
      力を消費してしまう。そうなると気軽に実行できない。或いは、ユーザー入力を
      読み取る事ができた暁にはその場で ble-decode-char するという手もある?

      うーん。然し、_ble_bind_hook の中で実行した bind/.tail の中で
      ble-decode-char するとすると、例えば其処でコマンド実行が _ble_bind_hook
      に大して設定された時に、それがその場で実行されない可能性がある。更に、設
      定した物が実行される前に消滅してしまう可能性すらある。ble-decode-char を
      その場で実行する方式にすると色々木にしなければならない事が多い。

    d conditional-sync に限っては ALRM を subshell から投げれば良いのでは。と思っ
      て試してみたが、何も設置していない状態で kill -ALRM $$ すると親シェルが終
      了してしまう。ALRM に何か無視する様に ble.sh でハンドラを設置しても良いが、
      それはそれでまた面倒事が増える。

    うーん。二つの方向性がある。全般に msleep の問題を解決するという事と
    conditional-sync の問題を解決するという事。今までの発生頻度から考えると
    conditional-sync の対策だけをしても当面は大丈夫な気もするが、何れは msleep
    の問題を完全解決したい。そうなった暁には conditional-sync の対策は不要にな
    るし、また conditional-sync の問題だけ解決するのは臭いものに蓋をしているだ
    けで本質的問題の解決にはなっていない。それよりは msleep 自体の問題を解決す
    る様に考えたいのである。

    仕方がないので cygwin と同じ手法で回避する事にした。

    2021-02-13 /dev/zero による workaround を追加したがよく考えたら /dev/zero
    が全ての環境にあるとは限らないし、ある環境でも read をブロックしてくれるか
    は微妙である。と思ったが /dev/zero で止まるかどうかは bash の側の実装の問題
    なので、もし /dev/zero が 0 を出力し続けるのであれば、ちゃんとブロックはす
    るだろうと思われる。

    /dev/zero が存在する環境について一度確認はしておきたい。Solaris, Minix に存
    在する。FreeBSD, Haiku にも存在した。当然 Cygwin と Linux にも存在する。
    MSYS2 でも OK だった。何れも read -t 0.2 < /dev/zero がちゃんと期待通りに動
    いた。という事を考えれば基本的に全ての環境で /dev/zero が使えると考えて良い
    のではないだろうか。

2021-02-04

  * global: read timeout は $?==142 とは限らない [#D1467]

    read timeout は本当に常に 142 なのか。と思ったが現在の用例では 142 は
    conditional-sync によって固定で返されているので気にしなくて良い。因みに
    bash のソースコードを確認する限りは 142 は hardcoded ではない。

    * edit (ble/builtin/read/.loop): うーん。予め 142 に対応する終了ステータス
      を調べておくか、或いは 128 以上を一括で timeout と解釈するか。マニュアル
      には "128 より大きな値になる" とだけ書かれている。マニュアルに従った判定
      にするのが良い気がする。

    * util (ble/util/msleep/.use-read-timeout): これは現在は使っていない。何れ
      にしても Cygwin/MSYS の時にだけチェックする様にすれば、これらのシステムで
      は 142 固定と期待されるので大丈夫。

  * util (bleopt): bleopt でパイプに繋いでいても _ble_term_sgr0 が出力されている場合がある [#D1466]
    追加で関連する関数に於いて --color オプションで着色を制御できるようにする。
    * "--color" options for bleopt, blehook, ble-color-setface

  * 2021-02-01 highlight: highlight_timeout_sync=0 にしても遅い (reported by 3ximus) [#D1465]
    https://github.com/akinomyoga/ble.sh/issues/82#issuecomment-770390986

    % OK. Sorry, I actually reproduce this level of delay at my side too, but I
    % haven't regarded it as *terrible*. That's probably because I know what
    % `ble.sh` is doing in the background. I felt that it's actually doing a good
    % job considering how strange things `ble.sh` is doing in the background.
    %
    % →と思ったが、bleopt highlight_timeout_sync=0 を実行していなかった。これを
    % 実行したら自分のところでは特に問題もなく動く様になった。当初は実装のバグか
    % とも思ったが、一部の host の上でだけ動作しないという事があるだろうか。
    %
    % Do you think it is related to `ffmpeg` running in the background? I see in
    % the `top` pane multiple instances of `ffmpeg` are running, but the load
    % average is smaller than 2, which means that those `ffmpeg` instances are
    % waiting for an interrupt in more than half of their running time. If those
    % `ffmpeg` are encoding some video clips, they may be waiting for disk I/O.
    %
    % →と思ったが disk I/O 待ちだと status D になる筈である。画面を見る限りはそ
    % うなっていない。更に -x11grab というオプションについて調べてみるとこれはス
    % クリーンキャプチャである。つまり、これらの ffmpeg は単にこの説明を作るため
    % に起動しているだけで、問題には関係してこない。

    何れにしてもこれは background highlighting におけるユーザー入力による中断速
    度に関係している。でもどの部分が悪さをしているのか分からない。

    1. 入力検出?
    2. 生存検出?
    3. 或いは kill & wait だろうか。

    どうも background highlighting のユーザー入力によるキャンセルの応答が遅い様
    である。自分の手元では残念ながら再現しない。取り敢えず勘で可能性のある時間
    のかかりそうな箇所に関連した時間計測を依頼したがぴんと来ない。多分、別の所
    に原因があるのではないか。

    2021-02-04 追加報告では遅い時もあるしそうでない時もあるそうだ。後、遅いとは
    言っている割にそれ程遅い訳でもない気がする。単に複数のパス名展開が試みられ
    るのでそれぞれについてタイムアウトが試みられて遅くなっているというだけなの
    ではないか。という訳で、取り敢えずの修正として一度 timeout を起こしたら後続
    の eval も即刻で timeout する様に修正した。

    それから conditional-sync をチェックする頻度も変更する事にする。取り敢えず
    これで改善するかどうか判断する事にする。

    | 後、timeout は total でカウントするべきなのかもしれない。或いは一つ
    | timeout したらそれ以降は timeout が必要になる物はもう処理しない様に変更す
    | る。

    2021-02-05 新しい報告で上記の cumulative timeout & shorter polling interval
    で改善するという事が確かめられた。問題は現在の cumulative timeout によって
    本来短時間で着色できる単語が着色されずに残ってしまう可能性について。

    然し、そもそも cumulative timeout で本当に改善しているのかというのは謎であ
    る。今 highlight_timeout_sync=0 にしている。とすると highlight_timeout_sync
    が効いていないか、或いは highlight_timeout_async の側での cumulative
    timeout が効いているか。highlight_timeout_async の側での timeout が効いてい
    るとすると何故なのか。ユーザー入力がある場合には何れにしても has-input の
    チェックによってキャンセルされるのではないか。うーん。手元で試してみたが余
    り違いが分からない。

    * done: syntax_eval_polling_interval について doc を記述する

  * 展開済みであっても展開される単語の数に比例して遅い (reported by 3ximus) [#D1464]
    https://github.com/akinomyoga/ble.sh/issues/82#issuecomment-772529714

    * 以前大量の入力を与えた時に遅いという事を解決した時に似たような事があった
      気がする。パス名展開がなかったとしても大量の単語を含む配列をコピーすると
      遅いという話。

      前に経験した時にはどの様な事が原因でどのように対策したのだったか。記録を
      漁ってみると #D1302 に関連しそうな内容が書かれている。

      > chars=("${...[@]}" "$@") が 13 秒もかかっている。何故?

      うーん。改めて試してみたがそんなに遅くない。関数経由で代入して改善したと
      いう事が書かれているが、実際に試してみても関数経由で代入すると却って遅く
      なる。またパス名展開の影響かとも思ったが set -f しても大して変化しない。
      結局再現はできない。

      再現ができないので現在発生している問題が具体的にどういう物なのか調べる事
      もできない。取り敢えずまた計測をお願いするしかないのだという気がする。予
      想では cache が巨大である為に起こっている事ではないか。

    * reject: そういう意味では既に議論した様に、単語ごとに展開済みの単純な情報
      を記録する事にして必要になった時は eval まで取りに行くのではなくて一部だ
      け記録する事にするという手もある。

      →今は其処までしなくても良いという気がする。

    取り敢えず simple-word/eval のキャッシュとして完全な情報を記録する物と、最
    初の単語だけ記録する物を用意して、highlighting の内部では主に最初の単語だけ
    を参照する様に変更した。

  * syntax: tilde で始まる単語の着色がされない? (reported by 3ximus) [#D1463]
    https://github.com/akinomyoga/ble.sh/issues/82#issuecomment-772529714

    と思ったがそうでもない。条件が不明

    % notilde 関連かと思ったが違った。どうも evaluate-path-spec が after-sep の時
    % に変な振る舞いをしている。spec の抽出に失敗している。
    %
    % $ ble/syntax:bash/simple-word/evaluate-path-spec '~/work/idt/**/*.sh' after-sep
    % $ declare -p spec path
    % declare -a spec=([0]="~/wo" [1]="~/work/id" [2]="~/work/idt/**/*." [3]="~/work/idt/**/*.sh")
    % declare -a path=([0]="/home/murase/wo" [1]="/home/murase/work/id" [2]="" [3]="/home/murase/work/idt/agh/src/addon/make_latex_embedfont_css.sh")
    %
    % と思ったら単に evaluate-path-spec の使い方を間違っていただけだった。
    % 正しく sep を指定したら evaluate-path-spec の結果は期待した物になった。

    改めて evaluate-path-spec の中で何が起こっているのか調べたら確かに失敗している。

    wtxt='~/**/*.sh' path_opts='stopcheck:timeout-highlight:cached:after-sep' ext='1'
    spec=('~/' '~/**/' '~/**/*.sh')
    path=('/home/murase/' '' '')

    どうも stopcheck の有無で結果が変わる様である。
    ble/syntax:bash/simple-word/eval '~/**/*.sh' stopcheck; ext=$?; ble/debug/print-variables ext ret

    問題を狭めて行った所、原因が分かった。これは単純なミスである。
    command="print-result $word" とするべき所を 'print-result $word' にしていた。修正した。

2021-02-03

  * edit: status line に対応しても良いのではないか [#D1462]

    →改めて確認してみた所、prompt_status_line という設定が既に存在していた。

    ? terminfo tsl/fsl に対応している TERMは存在するのか

      これは terminfo の tsl fsl を使って何かを表示する物だが、実のところ
      tsl/fsl に対応している TERM はなかなかない。少なくとも screen, xterm は違
      う。

      * tmux の term entry には tsl/fsl が存在しているが、シーケンスを見るとこ
        れは prompt_xterm_title と同じ OSC であって間違っている。terminfo の説
        明を読む限りに於いては、tsl/fsl は端末の特別な行で内部ではエスケープシー
        ケンスなども普通に使える物と見られる。という事を考えると、tmux の様に振
        る舞うのは間違っている気がする。

      * cygwin も tmux と同様である。但し、OSC 0 ; ではなくて OSC ; になってい
        る。0 は省略可能という事なのだろう。

      * kterm には \e[?E\e[?..T ... \e[?F という物が登録されている。
      * aixterm は \e[?..T ... \e[?F
      * aixterm は \e[?..T ... \e[?F

      うーん。何れにしても最近の端末エミュレータに存在する様な物ではない気がする
      ので、取り敢えず prompt_status_line は ble.sh の新しい機能の為に使う事にし
      てしまって良い。

    既存の tsl/fsl によるタイトルは別名の設定にする事にする。
    prompt_terminfo_status という名前にでもするか。terminfo だけでなく termcap
    にも存在するようだから、prompt_termcap_status の方が良いのかもしれない。或
    いは、prompt_term_status にするか。

    * status line の区別がやはり付きにくい。背景色を設定できる様にしても良いのではないだろうか。
      元々 trace にその様な機能があった様な気がする。改めて確認する。なかったので新しく実装した。

  * syntax: echo ${!_} と入力すると誤った代入ですというエラーメッセージが表示される [#D1461]
    そもそも "${!_}" を実行しようとするとエラーメッセージが出るが、
    これが着色等の際に発生するのは良くない。何処で発生しているのか確認する必要がある。

    これは新しく追加した ble/syntax:bash/simple-word/is-simple-noglob の中で起
    こしている展開に対して2>/dev/null を付加すれば良かった。未だ master に push していない
    修正なので commit を fixup しようかと思ったが、実装ログが面倒な事になるので、
    下手に fixup するのは止める事にする。

  * benchmark: EPOCHREALTIME は LC_NUMERIC 依存 (reported by 3ximus) [#D1460]

    報告の画像で出ているエラーが何だろうと思って ble-measure の実装を
    見たが変な事はない。と思ったが此処で気づいた。EPOCHREALTIME の小数
    点は locale 依存である。という訳で対策する事にした。

  * global: help の類の整理 [#D1459]
    * bleopt: --help に対応していない
    * blehook: --help が単純すぎる

  * canvas: status line を最終行に表示する可能性 (suggested by 0neGuyDev) [#D1458]
    https://github.com/akinomyoga/ble.sh/issues/85

    元々の提案は vim の mode 名という事だったが、vim の mode 名だけを最終行に表
    示するのか、或いは補完候補等の情報も全て最終行付近に表示するのかという可能
    性がある。Emacs 等を考えると補完候補も最終行に表示するのが自然な気がする。
    なので、実装としては info を丸ごと一番最後に表示する可能性について考えて良
    い気がする。

    最終行に表示する為に必要な事。

    a 一つの方法は \e7 \e8 で現在位置を記録するという事。これは visible-bell で
      既にやっている事。問題になるのは info の内容を構築する時に \e7 \e8 を使え
      ないという事。trace に明示的に禁止・代替するオプションを付ける必要がある
      かもしれない。

    b もう一つの方法は DSR(6)/CPR で問い合わせるという方法。実はこの方法は未だ
      ble.sh には積極的に取り入れた事はない。とはいいつつも歴史的な端末でも軒並
      みこれに対応しているので、全ての端末で使えると思って良い。問題になるのは
      応答に時間がかかるので頻繁に問い合わせる訳には行かないという事。どのタイ
      ミングで問い合わせるのが良いのか非自明であるという点。

    取り敢えず実装としては a の方針を試すのが自然な気がする。実は canvas の
    panel を調整するだけで、他の部分は触れずに実装できてしまうのではないだろう
    か。前にも似た様な事を考えた事があるような気がしないでもない。

    自身の高さ変更だけでなく他の panel の高さ変更の時にも注意が必要。
    特に高さを増やす時。

    * ok: bell を表示する為の行が canvas origin の一つ上に確保されている事に注
      意する。と思ったが、\e7\e8 で移動するのであれば実は余り関係ないという気が
      する。

    ? reject: 間に適当な高さの空 panel を設置すれば良いのではないか、と思ったが
      間の高さが不明なので関係ない。

    * vfill 以降の高さが 0 の時に変な事が起こらないか
      →これについてはちゃんと意識して実装する事にした。

    うーん。取り敢えず実装した。canvas.sh に対する修正だけで大体動いているが細
    かい所で変な事が起こっている。

    x fixed: C-l をしても画面の一番上に移動しなくなってしまう。何故だろうか。
      →これは clear-screen する時に下部に excursion している状態で行っていたので、
      その後 textarea を描画する時に _ble_term_rc で位置が復元されるのが原因だった。

    x 空コマンドを実行した時に info が押し出されて消える。実装を見ると
      ble/widget/.insert-newline の *:keep-info:* が該当する部分だがちゃんと動
      きそうな気がする。と思ったら canvas.sh の panel#increase-total-height が
      未実装だったのを思い出した。

      % と思ったがよく見たらちゃんと実装できている気がする。然し整理した。それで
      % も動かない。そもそも普通に C-q C-j で改行を入力した時も info が消えてしまっ
      % ている。うーん。increase-height に失敗している?

      やっぱり実装できていなかった。端末の高さが十分に高い時は、全体の高さは増
      えない。うーん。制御機能を工夫してこれを何とかする方法は実際に存在するの
      だろうか。勿論 CPR や他の機能を使えば可能なのだろうと思うが基本的な移動と
      IND RI の組み合わせでできない物だろうか。

      うーん。無理の気がする。CUU&CUD の累積でできるのではないかと考えたが、累
      積させる方法が存在しない。


      やはり DECSTBM 等に依存するしかないのだろうか。或いは CPR を利用する。も
      しくは、再描画する。再描画が現実的な気がする、と思ったがサイズが変化する
      可能性がある場合全般に問題が発生するので、やはり現実的ではないように思わ
      れる。うーん。CPR を毎回発行して現在位置を記録する様にした方が良いのだろ
      うか。

      a reject: CPR の可能性について→余り現実的でない気がする

        ble/term/enter の辺りで CPR を発行する様にする事を考えたが。或いは
        ble/textarea#invalidate を発行する度に実行した方が良いのではないか。うー
        ん。然し、描画しようとしている時に即座に返答が帰ってくる訳でもない。と
        いって CPR が帰って来るまでブロックするというのも変だし、続きを async
        に処理するとういのも変である。やはり CPR は飽くまで補助的に使うべきなの
        だという気がする。或いは、画面の大きさが変わる時に初めて CPR 要求を出す
        という考え方もある。然し、そうすると async に処理しなければならなくな
        る…或いはその場で入力を待っても良いのかもしれないが…やはり駄目。別の
        入力を先に受信したりすると変な事になる。

      b done: 再描画の可能性について→呼び出し元で再描画が必要化判定するのは困難なの
        で event を発火するなどして対処する。

        実の所、再描画の為の関数を用意する筈だったので丁度良いのではないか。うー
        ん。再描画というよりは invalidate して、後で再描画するという形にするの
        が良い。invalidate については…。全体を invalidate するというのも考えら
        れるが一部を invalidate するというのも考えられる。矩形で invalidate さ
        れた領域を記録できる様にするのが良い気がする。

        →invalidate を呼び出してそれからそれを記録して、更に次の render の時に
        改めて反映させるというコードを ble-edit/info について新しく書いた。
        ble/textarea に関しては既に実装した関数を適当に呼び出すだけで良いという
        事にする。

      c done: DECSTBM を使う可能性について。取り敢えず最近の端末はこれに対応している
        だろうと想像されるのでこれを使うというので良い気がする。ble.sh 起動時に
        DECSTBM に対応しているかどうかを検出する。

    * done: DECSTBM の判定コード
      取り敢えず判定コードを書いた。

      →と思ったら行が消滅してしまう。うーん。→ IND の代わりに CUD を使って
      DECSTBM をテストする事にした。動いている。OK

    x fixed: cursor-position (DECSTBM が使えない場合) が info の中になってしまっている
      _ble_canvas_panel_focus という変数を用意した。
      然し、それでも振る舞いが変である。

    x fixed: (DECSTBM が使えない場合) 一番最後の行での描画が重複している。

      DECSTBM の有無で振る舞いが逆になってしまっている。これは明らかに
      set-height の振る舞いに (少なくとも片方は) 間違いがあるという事。

      →これは単純にバグだった。

    x fixed: DECSTBM を使っている時に一番最後から二行目が使われない。

      DECSTBM を使わない場合にはちゃんと動いているのでここにも何が間違いがある。

    * util (visible-bell) との干渉について

      x fixed: 実は visible-bell の実装にバグがある。

        RI を使って現在編集のコマンドと被らない様にしているが、実は現在行と被らな
        い様にしているだけであって、実際には編集文字列の2行目以降にいる時には
        visible-bell が上書きしてしまう。

      x fixed: 先頭行の visible-bell で info が消滅する。

      * resolved: _ble_term_{sc,rc} ... util.sh で使っている箇所がある

      * ok: visible-bell の中の trace で sc rc を使えない様にするべきでは? と思っ
        たが、visible-bell は純粋な text という事になっているので今は関係ない。
        将来的には esc seq も指定できる様にする可能性もあるが今は考えない。

    * resolved: ble/canvas 内で他にも _ble_term_{sc,rc} を使っている箇所がある。
      これは曖昧文字幅の問い合わせに使っていた。

    * ok: _ble_term{sc,rc} は edit.sh でも使っている箇所がある。
      →adjust-eol で使っている。これは大丈夫の筈。

    * ok: ble/canvas/panel#report-cursor-position 等については影響がないか確認
      が必要。ble/canvas/panel#get-origin についても。

      get-origin に関しては core-complete.sh で menu の構築で使われている様だが、
      絶対位置として他の panel の座標系と混ぜて使っている訳ではないので問題ない。

      report-cursor-position に関してはパネルの局所座標を引数に指定しているので
      呼び出し元は気にしなくて良い。特に問題も無い様に思われる。

    * done: trace で SC/RC を emulate する (with opts=noscrc)

    * done: bleopt で制御できる様にする

    * blerc に bleopt info_display を追記する。

2021-02-01

  * complete: support "bleopt complete_timeout_compvar" (motivated by 3ximus) [#D1457]
    https://github.com/akinomyoga/ble.sh/issues/82#issuecomment-770390986

    これは progcomp の関数を呼び出す時にパス名展開を実行しているからである。
    一応、応答がなくなるという事はないが補完に不自然に時間がかかるのは避けたい。
    progcomp の為に展開する時は noglob で展開する事も考えたが、
    展開した文字列を quote しているので、noglob で呼び出すと例えば *.txt
    が '*.txt' 等になってしまって意図しない結果になってしまう。

    どの様にするのが良いのかは不明である。或いは timeout したら '*.txt' にして
    しまうというのでも良いのかもしれない。

    bleopt complete_timeout_progcomp_glob=200 等の設定にして、timeout したら
    noglob で呼び出すというので良い気がする。

    retry-noglob-on-timeout という opts を追加する事にする。

    新しい bleopt の変数名は何が良いだろうか。

      complete_timeout_progcomp_glob だと長い。
      それに似たような変数が沢山あって気になる。
      そもそも単に timeout としていると何の timeout か分からない。

      ちゃんとした名前にするなら glob_timeout が良いが長い。
      一単語でこれを表現できないか。fsys_timeout, path_timeout, ...
      やはり専用の単語は存在しない以上は一単語にするのは難しい。
      また、似たような設定をまとめるという立場からすると以下の様な
      変数名で良いのではないかという気もしないでもないが、微妙。

        glob_timeout_progcomp
        glob_timeout_sync_highilght
        glob_timeout_async_highilght
        glob_timeout_auto_complete

      やはり highlight_*, complete_* という名前にしたい。

        highlight_timeout_sync
        highlight_timeout_async
        complete_timeout_auto
        complete_timeout_compvar

    →これは実際に試してみたが改善していない。

  * setup を動詞の様に使っている箇所が多くて気になるので修正する [#D1456]

    set up に代わる動詞を探しても余り良いのが見つからない。文脈に応じて全く違う
    表現に改めた関数もある。set up だけの場合には関数名としてはくっつけて setup
    としても良い事にした。setup-xxx というのは気になるのでせめて set-up-xxx の
    様に変更した。

2021-01-30

  * edit: emoji の表を更新する (reported by endorfina) [#D1455]
    https://github.com/akinomyoga/ble.sh/issues/84

    更新しようと思ったが現在のコードを確認すると色々工夫して高速化している。
    少し面倒である。取り敢えずデータのダウンロードだけは行う事にする。

    https://unicode.org/Public/emoji/

    色々考えて現在のコードの構造に近い形で再実装した。実は以前の実装に
    はバグがあった。

    以前のテーブルは https://github.com/vim-jp/issues/issues/1086 から
    拾ってきた物だったが、これは 2017 年の物だったので報告のあった
    flamingo の絵文字 (2018) は含まれていなかったのだ。

  * syntax: 構文解析で無限ループになっている [#D1454]

    特定のコマンドの編集で固まってしまったので gdb でアタッチしてみたらstack が
    300 段ぐらいまで成長している。問題の起こるコマンドを探ってみると、[[ ]] が
    あるかどうかで振る舞いが変わる様だ。

    [再現]

    $ for f in *; do [[ ]]; done

    に於いて、* の直前に "out/" を挿入しようとすると無限ループになる。 [[ ]] で
    はない別のコマンドの時には発生しない。


    [原因]

    | 構文構造を確かめてみると確かに構造が破壊されている。正常な場合にはちゃんと
    | 単語の chain が繋がって木構造を形成している。しかし、問題が起こるコマンドの
    | 場合、[[ ]] の兄要素が記録されていない。唯、これだけで無限ループになるとい
    | うのも変である。無限ループになってしまう原因も探りたい気がする。
    |
    | 正常時
    |
    | | $ for f in *; do :; done
    | | _ble_syntax_attr/tree/nest/stat?
    | | 18*a    000 'f' | stat=(CMDX w=- n=- t=-:-)
    | |  |*a    001 'o' |
    | |  |*a    002 'r' + word=CMDI:0-3/(wattr=d)
    | | 16*a    003 ' '   stat=(FARGX1 w=- n=- t=$3:-)
    | |  7*a    004 'f' + word=ARGI:@2>4-5/(wattr=d) stat=(FARGX1 w=- n=- t=$3:-)
    | | 36*a    005 ' '   stat=(FARGX2 w=- n=- t=$5:-)
    | | 37*a    006 'i' | stat=(FARGX2 w=- n=- t=$5:-)
    | |  |*a    007 'n' + word=FARGI2:@4>6-8/(wattr=d)
    | | 58*a    008 ' '   stat=(FARGX3 w=- n=- t=$8:-)
    | | 31*aw   009 '*' + word=ARGI:@7>9-10/(wattr=m1:72057594037934596) stat=(FARGX3 w=- n=- t=$8:-)
    | | 12*a    010 ';'   stat=(FARGX3 w=- n=- t=$10:-)
    | | 68*a    011 ' '   stat=(CMDXD w=- n=- t=$10:-)
    | | 20*a    012 'd' | stat=(CMDXD w=- n=- t=$10:-)
    | |  |*a    013 'o' + word=CMDI:@9>12-14/(wattr=d)
    | | 17*a    014 ' '   stat=(CMDX1 w=- n=- t=$14:-)
    | |  2*aw   015 ':' + word=CMDI:@13>15-16/(wattr=72057594037930241) stat=(CMDX1 w=- n=- t=$14:-)
    | | 12*a    016 ';'   stat=(ARGX w=- n=- t=$16:-)
    | |  1*a    017 ' '   stat=(CMDX w=- n=- t=$16:-)
    | | 19*a    018 'd' | stat=(CMDX w=- n=- t=$16:-)
    | |  |*a    019 'o' |
    | |  |*a    020 'n' |
    | |  |*a    021 'e' + word=CMDI:@15>18-22/(wattr=d)
    | |  |    s 022 ^@   stat=(CMDXE w=- n=- t=$22:-)
    | | \_ 'for'
    | | \_ 'f'
    | | \_ 'in'
    | | \_ '*'
    | | \_ 'do'
    | | \_ ':'
    | | \_ 'done'
    |
    | 異常時
    |
    | | $ for f in *; do [[ ]]; done
    | | _ble_syntax_attr/tree/nest/stat?
    | | 18 a    000 'f' |  stat=(CMDX w=- n=- t=-:-)
    | |  | a    001 'o' |
    | |  | a    002 'r' +  word=CMDI:0-3/(wattr=d)
    | | 16 a    003 ' '    stat=(FARGX1 w=- n=- t=$3:-)
    | |  7 a    004 'f' +  word=ARGI:@2>4-5/(wattr=d) stat=(FARGX1 w=- n=- t=$3:-)
    | | 36 a    005 ' '    stat=(FARGX2 w=- n=- t=$5:-)
    | | 37 a    006 'i' |  stat=(FARGX2 w=- n=- t=$5:-)
    | |  | a    007 'n' +  word=FARGI2:@4>6-8/(wattr=d)
    | | 58 a    008 ' '    stat=(FARGX3 w=- n=- t=$8:-)
    | | 31 aw   009 '*' +  word=ARGI:@7>9-10/(wattr=m1:72057594037934596) stat=(FARGX3 w=- n=- t=$8:-)
    | | 12 a    010 ';'    stat=(FARGX3 w=- n=- t=$10:-)
    | | 68 a    011 ' '    stat=(CMDXD w=- n=- t=$10:-)
    | | 20 a    012 'd' |  stat=(CMDXD w=- n=- t=$10:-)
    | |  | a    013 'o' +  word=CMDI:@9>12-14/(wattr=d)
    | | 17 a    014 ' '    stat=(CMDX1 w=- n=- t=$14:-)
    | | 12 a    015 '[' || nest=(ARGX0 w=- n=- t=-:-) stat=(CMDX1 w=- n=- t=$14:-)
    | |  | a    016 '[' |+ word=CMDI:15-17/(wattr=d)
    | | 32 a    017 ' ' |  stat=(CONDX w=- n=@15 t=$17:-)
    | | 12 a    018 ']' || stat=(CONDX w=- n=@15 t=$17:-)
    | |  | a    019 ']' ++ word="none":15-20>@19 word=CONDI:@16>18-20/(wattr=d)
    | | 12 a    020 ';'    stat=(ARGX0 w=- n=- t=$20:-)
    | |  1 a    021 ' '    stat=(CMDX w=- n=- t=$20:-)
    | | 19 a    022 'd' |  stat=(CMDX w=- n=- t=$20:-)
    | |  | a    023 'o' |
    | |  | a    024 'n' |
    | |  | a    025 'e' +  word=CMDI:@19>22-26/(wattr=d)
    | |  |    s 026 ^@    stat=(CMDXE w=- n=- t=$26:-)
    | | \_ '[[ ]]'
    | | |   \_ '[['
    | | |   \_ ']]'
    | | \_ 'done'
    |
    | どうも auto-complete が有効になっていると発生する様だ。
    | 入力のタイミングにも依る。一旦構文解析が終了してから無限ループに入る。
    |
    | 無限ループに入る時の構造
    |
    | | $ for f in out/*; do [[ ]]; done
    | | _ble_syntax_attr/tree/nest/stat?
    | | 18 a    000 'f' |  stat=(CMDX w=- n=- t=-:-)
    | |  | a    001 'o' |
    | |  | a    002 'r' +  word=CMDI:0-3/(wattr=d)
    | | 16 a    003 ' '    stat=(FARGX1 w=- n=- t=$3:-)
    | | 26 a    004 'f' +  word=ARGI:@2>4-5/(wattr=d) stat=(FARGX1 w=- n=- t=$3:-)
    | | 36 a    005 ' '    stat=(FARGX2 w=- n=- t=$5:-)
    | | 37 a    006 'i' |  stat=(FARGX2 w=- n=- t=$5:-)
    | |  | a    007 'n' +  word=FARGI2:@4>6-8/(wattr=d)
    | | 58 a    008 ' '    stat=(FARGX3 w=- n=- t=$8:-)
    | | 59*a    009 'o'    stat=(FARGX3 w=- n=- t=$8:-)
    | |  |*a    010 'u'
    | |  |*a    011 't'
    | |  |*a    012 '/' |
    | | 31 a  s 013 '*' +  word=ARGI:@10>12-14 stat=(FARGI3 w=FARGX3:9- n=- t=-:$8)
    | | 12 a  s 014 ';'    stat=(FARGX3 w=- n=- t=$14:-)
    | | 68 a  s 015 ' '    stat=(CMDXD w=- n=- t=$14:-)
    | | 20 a  s 016 'd' |  stat=(CMDXD w=- n=- t=$14:-)
    | |  | a  s 017 'o' +  word=CMDI:@13>16-18/(wattr=d)
    | | 17 a  s 018 ' '    stat=(CMDX1 w=- n=- t=$18:-)
    | | 12 a  s 019 '[' || nest=(ARGX0 w=- n=- t=-:-) stat=(CMDX1 w=- n=- t=$18:-)
    | |  | a  s 020 '[' |+ word=CMDI:19-21/(wattr=d)
    | | 32 a  s 021 ' ' |  stat=(CONDX w=- n=@19 t=$21:-)
    | | 12 a  s 022 ']' || stat=(CONDX w=- n=@19 t=$21:-)
    | |  | a  s 023 ']' ++ word="none":19-24>@23 word=CONDI:@20>22-24/(wattr=d)
    | | 12 a  s 024 ';'    stat=(ARGX0 w=- n=- t=$24:-)
    | |  1 a  s 025 ' '    stat=(CMDX w=- n=- t=$24:-)
    | | 19 a  s 026 'd' |  stat=(CMDX w=- n=- t=$24:-)
    | |  | a  s 027 'o' |
    | |  | a  s 028 'n' |
    | |  | a  s 029 'e' +  word=CMDI:@23>26-30/(wattr=d)
    | |  |    s 030 ^@    stat=(CMDXE w=- n=- t=$30:-)
    | | \_ '[[ ]]'
    | | |   \_ '[['
    | | |   \_ ']]'
    | | \_ 'done'
    |
    | うーん。変だ。やはり構文解析で起こっている無限ループではない様だ。とすると
    | 何が別の箇所で無限ループになっている。特に auto-complete で起こっているとい
    | う事、応答もしなくなる (SIGINT にも反応しない) という事から、
    | eval-pathname-expansion が怪しいのではないか。
    |
    | やはり /dev/zero で問題が発生しているという事なのだろうか…と思ったが、
    | msleep を read -t を使わない手法に置き換えても同様に無限ループになる事から
    | read -t ... /dev/zero の問題ではない。(それに [[ ]] によって構文構造がおか
    | しくなっている時にのみ発生するという事だから、やはり構文構造に関係のある問
    | 題なのだろう)。
    |
    | * 一つ怪しい箇所は extract-command である。core-complete.sh 関連でコマンド
    |   ライン内部の文法構造に関連する所と言えばこれしかない気がする。→実際に確
    |   かめてみたが無限ループは extract-command とは関係ない所で起こっている様だ。
    |
    | * パス名展開の中で起こっているとも考えにくい。何故ならばファイルの少ない場
    |   所でも問題が発生しているから。それに関数呼び出しが何十段にもなる事から、
    |   関数呼び出し自体で問題が発生しているというのは明らかである。
    |
    | 呼び出されている関数名を調べる事ができれば簡単なのだが難しい。
    |
    | * そもそも本当に auto-complete.idle の中で発生しているのだろうか。と思って
    |   確かめたらどうやら違う様だ。だとすると、bgworker による textarea#render
    |   が怪しい?
    |
    |   調べてみたらそうだった。更に textarea#render の中で怪しい所に絞り込みをか
    |   ける。どうやら update-text-buffer の中で問題が発生している。update-syntax
    |   の問題ではないようだ。update-text-buffer の中では layer/update を呼び出し
    |   ているので、恐らく layer:syntax/update が変な事になっているのだろう。
    |
    |   やはり ble/highlight/layer:syntax/update-word-table の中で無限ループになっ
    |   ている様だ。
    |
    |   ble/syntax/tree-enumerate-in-range で無限に要素が列挙されているか、或いは
    |   ble/highlight/layer:syntax/word/.update-attributes/.proc の中で無限ループ
    |   になっているかである。後者だった。
    |
    |   ble/syntax:bash/extract-command-by-noderef が怪しい。実際に中を調べるとど
    |   うやら ble/syntax/tree#previous-sibling が無限に兄要素を生成している様だっ
    |   た。何故その様な事になるのか。
    |
    | OK. 原因が分かった。
    | 1. 木構造が壊れている
    | 2. 単語情報のシフトに失敗する
    | 3. 兄要素の位置がずれて何も単語が登録されていない位置を参照している
    | 4. 空の単語情報なので兄の相対位置が '' = 0 に評価されて自己参照している。
    | という具合にして空単語でループが出来上がっている。実際に問題が起こっている
    | 時の木構造を見るとその様になっている。

    まとめると二つの問題がある。

    * [[ ]] の解析で構文木の兄情報が欠けてしまっている。nest-push する時に何故
      か tprev が記録されていないのが原因であろう。

    * 木構造が壊れている時に ble/syntax:bash/extract-command-by-noderef の中で
      兄ノードを探索する時に、一旦、空の単語情報に行き当たると自己参照して無限
      に兄ノードを取得してしまうという問題がある。

    [修正]

    後者に関しては、単語がちゃんと登録されているかどうか確認する様に実装を変更
    した。構文木の欠陥があった場合にそれを出力する様にした。これで構文木が壊れ
    ていても無限ループにはならない。

    前者に関しては何処で問題が生じているか分かった気がする。word-cancel した時
    に tprev の情報を復元しきれていないという事。然し、不思議なのは word-cancel
    は単語が設置された後に呼び出されるのだから tprev は既にその新しい値になって
    いる筈だという事。なので、改めて tprev を計算する必要はない筈なのである。

    うーん。もしかして二回連続で word-pop が起こった為に情報が消滅しているとい
    う事だろうか…。つまり nest-pop も既に終わっている状態という可能性?

    →恐らく2回連続で word-pop をした時に、外側の word から順に pop しているの
    がいけないのではないか。内側の word から順に pop するべきという事の気がする。
    いや、それも変だ外側の word を pop する時に内側の単語も全部削除するべきなの
    ではないか。うーん…? 或いは単語を設置する直前の状態に復元するというのが正
    しい振る舞いだろうか。

    改めて振る舞いについて何が起こっているのか考える事にする。

    A B [ [ X Y ] ] という状態になっている。但し [...] が単語の範囲である。そも
    そもどう言った情報が記録されているかというと。

    * 外側の単語については、tchild=(Yの位置), tprev=(Bの位置) になっている。
    * 内側の単語については、tchild=- tprev=- になっている。
    * 二つの単語を設置し終わった時の解析状態は、tchild=(Yの位置) tprev=- である。
    * 一つ単語終端を削除した時の解析状態は tchild=(Yの位置) tprev=(Bの位置) であるべき。
    * 更にもう一つ単語終端を削除した時の解析状態は tchild=- tprev=- になる。
      → word-cancel を2回施した時はこの状態を復元しているという事。

    実際の振る舞いを見ると tprev が初めから空になっている。これは nest-push を
    実行した為の気がする。nest-pop もちゃんと実行しておくべきの気がする? うーん。
    確認してみると別に nest-push した事によって tprev になっている訳ではない気
    がする。どういう事だろうか。そもそも inest=-1 になっている。変だ。

    ※現在の解析状態は "もしここで単語を閉じたらその単語にどの様な tchild,
    tprev が割り当てられるか" を表している。つまり、現在の文脈における
    tchild/tprev ではなくて、一つ上に上がった時の tchild/tprev である事に注意す
    る。

    よく分からなくなった。取り敢えず現在の実装を理解することは諦めて、改めてど
    の様に実装するべきかについて考えてみることにする。word-cancel は二種類の考
    え方がある。それぞれについて適切な実装は何だろうか。

    a 閉じてしまった単語を閉じる前の状態にする。

      この場合には実は単純に word に格納されている tclen tplen をそれぞれ
      tchild tprev に変換すれば良い。

    b そもそも単語がそもそも始まるよりも前の状態に戻す。

      この場合には tchild は記録されている単語の tprev で、tprev については変化
      はない。という事を考えると…。実は現在の実装はこちらを狙った物であると考
      える事ができる。

      この場合には word-cancel は実は一回だけしか呼び出さなくて良い。そして、一
      番外側の単語を削除すると同時に中に設置されている単語も全て削除するべきで
      ある。中に設置されている単語を削除するにはどうすれば良いか。tchild を辿っ
      て削除していく必要がある。面倒な事である。というか、tprev に至る迄を全削
      除で良いのではないだろうか。

2021-01-28

  * syntax/simple-word/eval: キャッシュ機能を付ける [#D1453]

    特に一回の着色 (layer:syntax/update) の中では同じ評価は一回しかしない様に工
    夫したい。キャッシュは dict に保存したいが二種類の問題がある。

    1. eval の展開結果は配列なのでそれをどうにか再評価可能な形式に変換する必要
      がある。bash-4.4 以降であれば ${ret[@]@Q} を用いれば良い。古い bash では
      この形式に合わせて記録を行う。

    2. bash3 では dict がないので工夫が必要

    取り敢えずこれは必要である。

    | うーん。それどころか一つのキーストロークの中でずっとキャッシュしても良いの
    | ではないか。tail 辺りで clear すれば良い。と思ったが余り変な事をしても駄目
    | な気もする。これだと bind 以外の枠組みで syntax/simple-word/eval を呼び出し
    | た時にキャッシュが全くクリアされなくて問題に成るのではないか。
    |
    | 例えば ble/builtin/read を使った時にキャッシュクリアが全くされないという事
    | になってしまう。但し、現在は read に対しては構文着色も auto-complete も有効
    | にしていないが。うーん。或いは widget を呼び出すタイミングでキャッシュをク
    | リアするという手もあるかもしれない…が、やはり ble/textarea#render と同じタ
    | イミングでクリアするのが自然な気がする。うーん。
    |
    | ble/textarea#render の中で clear してしまう? と思ったが、それはそれでやはり
    | 問題になる。将来的に textarea ではない物に対するキーボード操作も考えたいと
    | いう事を思うと、textarea#render の中からキャッシュをクリアするというのはや
    | はり変だ。
    |
    | そもそも汎用性を考えるのだとしたら cache は opts に指定した時にだけ使うとい
    | うので良い気がする。キャッシュをクリアする関数も別に公開しておいて、cache
    | を使う場合には自分でキャッシュの管理をせよという事にすれば良いのである。


    * done: dict を整備する。
    * done: キャッシュする様にする
    * done: キャッシュクリア用の関数を公開する

  * 2021-01-26 util: Cygwin 上で ble/util/msleep がフリーズしてしまう [#D1452]

    | 何故だろうか。普通にユーザコマンドとして実行した場合には特に問題は発生して
    | いない。サブシェルで実行しても問題は発生していない。内部 stty でサブシェル
    | で実行すると問題が起こる?
    |
    | →どうも繰り返し実行すると発生する様である。
    |
    | 以下を実行するとかなりの確率で固まる。
    | ( echo {1..1000} & builtin read -t 0.000100 v < /dev/udp/0.0.0.0/80 ) >/dev/null

    以下によって通常の bash でも固まるという事が分かった。Cygwin 特有の振る舞い
    である。Linux 上で試した限りでは問題は起こらない。

    ( echo {0..1000} >/dev/null & builtin read -t 0.001 v < /dev/udp/127.0.0.1/80 )

    他の実装だと exec 9<(sleep) を起動して置くという物や、builtin sleep を使う
    という物がある。

    a builtin sleep

      builtin sleep はコンパイラが利用可能なときにしか使えないのでこれに依存し
      たくない。飽くまで exec 9<(sleep) を使って実装して可能であれば builtin
      sleep を使うという様にする形になる。

    b 現在の /dev/udp/0.0.0.0/80 を弄って解決できないか

      うーん。不思議だ。'echo {1..1000}' を a.sh に書き出して置いて以下の様にす
      ると再現しない。

      ( . a.sh >/dev/null & builtin read -t 0.001 v < /dev/udp/127.0.0.1/80 )

      関数を function a { echo {1..1000}; } として a>/dev/null とした場合は再現する。

      * builtin read は read に置き換えても発生する。
      * 0.0.0.0 を 0.0.0.1 にすると通信エラーになって別の意味で使えない。
      * 127.0.0.1/80 でも再現する。
      * >/dev/null を >a.txt にしても再現する。
      * read を試みる前に様々なリダイレクトをしてみても状況は変わらない。
      * {0..1000} の部分や 0.001 の部分を変えると発生確率が下がる。

      うーん。微妙。というか環境が Cygwin だけというのであれば、最初からバイナ
      リを用意しておくという手もある。

      うーん。やはり Cygwin ではもっと別の実装を考えた方が良いだろうか。

    c exec 9< <(sleep)

      改めて exec 9< <(sleep) を試してみた所、遅延は殆どない様なので、これを採
      用する事にする。

    思えば今までにも時々あった Cygwin で固まってしまう問題はこれが原因だったの
    かもしれない。直前に fork してから is-stdin-ready を確認する機会が余りなかっ
    たり、或いはその他の条件で発生しにくかったりして再現しにくかったという事の
    気がする。という事を考えるとやはり /dev/udp/0.0.0.0/80 は今後は使わない方が
    良い気がする。

    →c の方法を使う事にした。古いコミットを参考にしてコードを復元する。
    8bb54be acb7163 d14557c f53c26d

    また udp によるコードを使いたくなるかもしれないので、取り敢えず今の所は
    bleopt internal_msleep_socket というオプションで udp 方式に切り替えられる様
    にしてコードを残しておく事にする。

    ----------------------------------------

    procsubst による実装に切り替えてもやはり同様の問題が発生する様だ…。
    うーん。どうした物だろうか。というかこれは bug-bash に報告しても良いのではないか。
    然し、normal Bash で再現させようとしても再現しない。然し症状としては同じなので、
    Cygwin における read のタイムアウトに問題があるという事は確かなのだろう。

    うーん。やはり Cygwin 用に特別にコンパイル済み sleep builtin を提供する?

    今試したら fifo が Cygwin 上でも動く様になっている。最近動く様になったのだ
    ろうか。或いは cygwin バージョンの問題だろうか。うーん。取り敢えず試しに動
    かしてみて、それで失敗したら procsubst に切り替えるという作戦にする。

    →駄目。やはり同じ問題が発生する。FIFO でも駄目という事。
    read -t を使うのが本質的に駄目という事なのだろう。
    唯、確率は格段に小さくなっている。

    sleep 10 | { echo {1..1000} >/dev/null & read -t 0.001 v; echo end; }

    この様にしている時には特に問題も発生しない様だ。

    builtin read -t "$v" v < "$$.pipe"

    この実装にしても固まる時には固まる。

    % 何と、builtin sleep を使っても同様に固まるという事が判明した。
    % つまり、read -t の問題ではない。Cygwin 自体に問題があるという事?
    % スレッドが停止するともう二度と動かないという種類の何か…。
    % →と思ったら勘違いだった。builtin sleep を使っているつもりが、
    % 別の方式をつかっていたのだった。

    一応 /dev/zero は期待通りに動く。但し、CPU 100% になるという事には注意する。
    短時間の sleep であれば /dev/zero に頼っても良いかもしれない。と考えたが、
    短時間の sleep を繰り返し使う場合などを考えるとやはり cpu100% になるのは好
    ましくない気もする。

    /dev/ptmx を試してみた。これはちゃんとブロックするし、勝手に停止してしまう
    事もないが代わりの問題として bash が終了しなくなってしまうという物がある。
    然し、通常の bash で同様の事をしても特に問題は発生しない様だ。何故だろうか。
    というか exec 9<&- を実行しようとしただけで固まってしまう。これは問題である。

    ble/util/msleep/.use-read-timeout socket check
    ble/util/msleep/.use-read-timeout fifo.exec2 check ||
      ble/util/msleep/.use-read-timeout procsub
    ble/util/msleep/.use-read-timeout fifo.open1
    ble/util/msleep/.use-read-timeout zero.open1
    ble/util/msleep/.use-read-timeout zero.exec1

    --------------------------------------------------------------------------

    結局 loadable builtin を使う事にしようと思って実装したが…。loadable
    builtin のライセンスはどうなっているのだったか。普通に考えるとこれは GPLv2
    に感染する気がする。という事は loadable builtin のソースコードをつけて配布
    するのは難しいという事になる。うーん。loadable builtin ならば OK という訳
    は…ないだろう。GPLv2 的に。調べたら正にそういう項目について記述されていた。

    https://www.gnu.org/licenses/gpl-faq.ja.html#GPLAndPlugins

    従って loadable builtins を使う方針は採用できない。結局、他の手法について考
    える必要があるのである。或いは確率が小さければ cygwin でも read -t を使って
    大丈夫だろうか、と思ったが conditional-sync を使っている限り、従来よりも格
    段に問題が起こる確率が高い。やはり read -t は諦めるべきだろうか。

    或いは conditional-sync の時だけ別の方法を用いるという可能性もある…。が、
    別の方法に心当たりがある訳ではない。どうしようもない。バイナリを添付する訳
    にも行かない。

    --------------------------------------------------------------------------

    取り敢えず /dev/zero では未だ hang が起きた事はないので、これで様子見する事にする。

  * util,syntax,complete: 配列内容の記録時に @Q を使った print に切り替える [#D1451]
    大した高速化ではないと思うがコードの整理も兼ねて。

  * syntax: auto-complete 内部の pathname-expansion についても conditional-sync を使う (motivated by 3ximus) [#D1450]
    https://github.com/akinomyoga/ble.sh/issues/82 (for auto-complete)

    取り敢えず [[ :$comp_type: != *:sync:* ]] の時には stop_check で実行して、
    それ以外の場合には強制的に実行するという方針で行く。

    ble/complete/util/eval-pathname-expansion に関してはそんなに面倒そうではない。
    ble/complete/util/eval-pathname-expansion は常にグロブパターンを伴って呼び出されるので場合分けは必要ない。
    常に conditional-sync を使えば良いのではないかという気がする。
    うーん。 *:sync:* が含まれる時だけはそのまま展開を実行する。
    →eval-pathname-expansion については対応した。恐らくこれで良いだろう。

    次に complete の内部から沢山の simple-word/eval を利用している。
    これらについても一つずつ確認して行く必要がある。

    以下の四つの関数が core-syntax.sh における stop_check を指定して実行するべき関数である。
    実際に使われているのは前者2つだけの様である。

    - ble/syntax:bash/simple-word/eval
    - ble/syntax:bash/simple-word/evaluate-path-spec
    - ble/syntax:bash/simple-word/detect-separated-path
    - ble/syntax:bash/simple-word/locate-filename

    |   $ grc 'simple-word/(eval|locate|detect)' lib/core-complete.sh
    | f lib/core-complete.sh:1970:    ble/syntax:bash/simple-word/eval "$subword" "$eval_opts"
    | f lib/core-complete.sh:1980:      ble/syntax:bash/simple-word/eval "$subword" noglob
    |   lib/core-complete.sh:2006:  ble/syntax:bash/simple-word/eval "$ret"; local value1=$ret
    |   lib/core-complete.sh:2011:      ble/syntax:bash/simple-word/eval "$ret"
    |   lib/core-complete.sh:2072:    ble/syntax:bash/simple-word/eval "$ret"; word=$ret
    |   lib/core-complete.sh:2093:          ble/syntax:bash/simple-word/eval "$ret"; left=$ret
    |   lib/core-complete.sh:2806:      ble/syntax:bash/simple-word/eval "$word" &&
    |   lib/core-complete.sh:2861:    ble/syntax:bash/simple-word/eval "$ret*" && ((${#ret[*]})) &&
    |   lib/core-complete.sh:3048:  local ret; ble/syntax:bash/simple-word/eval "$pattern"
    |   lib/core-complete.sh:3050:    ble/syntax:bash/simple-word/eval "$pattern*"
    |   lib/core-complete.sh:3223:    elif ble/syntax:bash/simple-word/eval "$reconstructed"; then
    |   lib/core-complete.sh:3229:        ble/syntax:bash/simple-word/eval "${reconstructed::${simple_ibrace#*:}}"
    |   lib/core-complete.sh:3234:      # Note: failglob により simple-word/eval が失敗した時にここに来る。
    |   lib/core-complete.sh:3624:  ble/syntax:bash/simple-word/evaluate-path-spec "$word0"; spec0=("${spec[@]}") path0=("${path[@]}")
    |   lib/core-complete.sh:3625:  ble/syntax:bash/simple-word/evaluate-path-spec "$word1"; spec1=("${spec[@]}") path1=("${path[@]}")
    |   lib/core-complete.sh:3705:        if ble/syntax:bash/simple-word/eval "$common_reconstructed" &&
    |   lib/core-complete.sh:3731:             ble/syntax:bash/simple-word/eval "$notilde$ret" noglob &&
    |   lib/core-complete.sh:3733:             ble/syntax:bash/simple-word/eval "$notilde$common_reconstructed" noglob &&
    |   lib/core-complete.sh:3761:                 ble/syntax:bash/simple-word/eval "$ret" &&
    |   lib/core-complete.sh:4206:      ble/syntax:bash/simple-word/eval "$ret"
    |   lib/core-complete.sh:4706:        ble/syntax:bash/simple-word/eval "$ret"
    |   lib/core-complete.sh:4930:  ble/syntax:bash/simple-word/eval "$ret"
    |   lib/core-complete.sh:5573:      if ble/syntax:bash/simple-word/eval "$ret" && local compv_new=$ret; then
    |   lib/core-complete.sh:5968:      ble/syntax:bash/simple-word/eval "$ret" || continue

    - ble/complete/progcomp/.compvar-generate-subwords/impl2
      この関数は eval を呼び出している。複数の単語に展開される時にそれを全て取得している。

    - ble/complete/source:argument/.contains-literal-option
      この関数は noglob を指定して変換を試すべきの気がするのでその様に変更する。

    - ble/complete/progcomp/.compvar-quote-subword

    - ble/complete/source:argument
      failglob で展開に失敗した時に * を付加して再度挑戦するのに使っている。
    - ble/complete/source:glob
    - ble/complete/candidates/.pick-nearest-sources
    - ble/complete/candidates/determine-common-prefix
    - ble/complete/candidates/determine-common-prefix/.apply-partial-comps
      ここでは evaluate-path-spec を使っている。
    - ble/complete/insert-common

    以上は候補生成時に使われる関数群である。
    全てユーザー入力があったらキャンセルという形で良い気がする。
    元々 148 を返す仕様の関数になっているので 148 の伝播についても面倒な対応は不要。

    - ble/complete/menu-filter
      これは .filter-candidates の戻り値を返すのを忘れている気がする。
      →修正した。

    - ble/widget/auto_complete/self-insert
      これは微妙。どの様にすればよいだろうか。
      timeout はまあいらない気がする。
      ユーザー入力によって interrupt されたらそのまま false を返せば、
      auto_complete モードから抜けるという動作になる。これで良い。

    - ble/complete/source:sabbrev
      % 展開した結果が使用されていない。バグが有る気がする。
      % →と思ったが iniitialize の中で参照されていた。

    [修正]

    * done: 毎回 timeout 等を設定するのは大変なので関数を用意する。
    * done: simple-word/{eval,evaluate-path-spec} の呼び出しを置き換える。

    x timeout した時に 142 を返すのを 148 に置き換えているが、
      これだと auto-complete 内部で timeout した時に、
      後続の idle まで中断してしまうのではないだろうか。

      →これは idle.do の側で修正する事にした。そもそも IS_IDLE で条件を差し替
      える事ができるようにしているので、呼び出した task の終了ステータスを信用
      する訳には行かない筈なのだ。

      此処で気になるのは complete における 148 の意味が必ずしもユーザ入力ではな
      くて、auto-complete における timeout の場合もあるという事になってしまった
      事だが、これが重大な結果を生み出す様には思われないので、取り敢えずはこれ
      で良いとする。

  * highlight: グロブパターンが含まれるファイル名の着色が遅い (reported by 3ximus) [#D1449]
    https://github.com/akinomyoga/ble.sh/issues/82 (for highlighting)

    glob expansion を subshell で実行してユーザー入力があったら timeout させる
    方針について考察。timeout は必要だろうか。

    * 或いは、もういきなり中断しても良いかもしれない。着色は次の rendering の時
      に反映させれば良いという発想。然し、その場合には再 rendering を発生させる
      為にどうにかして部分 invalidate しなければならない。或いは再描画の条件に
      着色未完の状態を含めても良いのかもしれない。着色の更新に関しては
      ble/textarea#update-text-buffer を呼び出した時に実行される。実は dirty
      range の有無に関わらず毎回 layer/update は呼び出される様だ。考えてみれば
      region の着色等は dirty range に関係なく変化する可能性があるので、この振
      る舞いも妥当である。

      一般に単語着色に関してはユーザーの入力があったら中断してしまって良いので
      はないだろうか。background worker の方で処理する事にすれば良い (但し、
      bash3 だと判定できないので難しい。bash3 に関しては loadable builtin が使
      えれば自前でそれを使ってしまうという手もある)。

    * キャッシュする可能性。同じ単語が繰り返し使われている場合に処理を短縮する
      為。これは特殊な場合にしか効果が現れない。余り効果はないのではないかとい
      う気がする。

    * globpat が含まれる場合にだけ subshell 実行する?
      globpat があるかどうかに関しては正規表現で判定すれば良い。

      "**" が含まれる場合にだけ subshell 実行するという可能性も考えたが、"*" や
      "?" だけでも大量のファイル名に展開される可能性もあるので、"*" だけ特別扱
      いしても仕方がない。

    * reject: ファイル数が多いディレクトリだけで subshell 実行する?

      ディレクトリ移動はそんなに頻繁に行わない筈なのでファイル数をディレクトリ
      移動をする度に確認すれば良いのではないか。と思ったが引数に
      dir1/dir2/... と指定する事もできるのでファイル数が多いディレクトリに現在
      いるかどうかという情報は余り当てにならない。

      "/" が含まれるかどうかを事前に判定する可能性もあるが、変数展開の中に / が
      含まれる可能性もあるので、完全に判定するのは難しい。

    * そもそも単語が単純な場合には展開の操作すら必要ないのではないか。

      {} も quote も history expan も param も ~ もない場合。

    [実装]

    * done: 取り敢えずユーザーからの入力がある場合には着色を中断する。サブシェ
      ルの中で実行する。後で着色し直す可能性については取り敢えず考えない。

      取り敢えず実装してみたが、微妙。とにかく入力を続ければ応答が全くないとい
      う訳ではないが、常に位置文字分だけ遅延している。何故だろうか。一文字だけ
      次の文字が来ている場合に次の文字が来ているという事を検出できていないとい
      う事だろうか。うーん。ble/decode/has-input の問題であろう。

    * done: simple-word/eval-noglob を eval ... noglob に書き換える

    * done: 以下の関数の呼び出し元で適切に stop_check を設定する様にする?

      ble/syntax:bash/simple-word/detect-separated-path
      ble/syntax:bash/simple-word/evaluate-path-spec
      ble/syntax:bash/simple-word/locate-filename

      特に bash3 で stop_check を行うかどうか。bash3 で stop_check をしたとして
      も常に is-stdin-ready は false になるので、唯単に今まで通りにブロックされ
      るだけである。然し、そうであるならば最初から subshell を生成する必要もな
      い。やはり bash3 では stop_check を省略する様に工夫する必要があるのではな
      いか。と思ったが、それならば simple-word/eval の側で bash3 では
      stop_check しないという様にしても良い気がする。
      →その様にする事にした。

      結局上記の3関数では常に stop_check を指定して、
      bash3 についての特別な取り扱いは simple-word/eval の側で実装した。

    * done: 以下の関数について 148 を返した時の振る舞いを正しく実装する。

      148 を返した時に現在はエラー着色にしているが、
      そうではなくて着色せずに抜ける事にする。

      ble/syntax:bash/simple-word/evaluate-path-spec [done]
        ble/syntax/progcolor/word:default/.highlight-filename [done]
          ble/syntax/progcolor/word:default [ok]
      ble/syntax:bash/simple-word/locate-filename/.exists [done]
        ble/syntax:bash/simple-word/locate-filename [done]
          ble/syntax/progcolor/word:default [ok]
        ble/syntax:bash/simple-word/detect-separated-path [done]
          ble/syntax/progcolor/word:default/.detect-separated-path [done]
            ble/syntax/progcolor/word:default [ok]

      取り敢えず ble/syntax/progcolor/word:default まで行って抜ければ、
      単語情報として何か間違った物が登録される事はない。

    x ok: ble/decode/has-input で次の文字が来ている判定しているが、一文字分だけずれ
      がある様に見える。何が起こっているのか調べる必要がある。

      調べてみると既に次の文字は受信している様である。
      問題は未だ処理しきっていないのに描画が実施されているという事である。
      コールスタックを見るとちゃんと EPILOGUE から呼び出されている。
      つまり、ちゃんと文字を処理してからという事になっている筈である。

      と此処で理由が分かった。入力した文字を表示する為に配色を計算しているのだから、
      配色を計算している間は未だ文字が描画されないというのは道理である。
      やはり timeout を入れないと変である。

      conditional-sync に timeout 機能も付ける事にする。

    * done: 着色せずに抜けた場合にはその事を記録に残す (progcolor_dirty)。
      これは ble/syntax/progcolor/word:default に対して実行すれば良い。
      或いは idle に bgworker を登録するだけでも良い?
      と思ったが、それだと沢山の bgworker が生成されてしまう気がする。
      idle に bgworker を登録するとしても、
      未着色単語がある事の情報は何処かに記録する必要がある。

      実は未着色範囲を管理した方が自然な実装になる気もする。
      例えば _ble_syntax_word_async_u{min,max} 等の変数に記録する。
      bgworker ではこれを _ble_syntax_word_u{min,max} に反映させて
      その上で着色を実行する…と思ったが shift 等の取り扱いがどうなるのか分からない。
      _ble_syntax_word_u{min,max} の場合にはどの様にしていただろうか。
      というより、_ble_syntax_word_u{min,max} が設定されるのはどのタイミングだろうか。

      % うーん。ble/syntax/parse/touch-updated-word で変更している。そしてこれは
      % ble/syntax/parse の中で呼び出される物である。一方で、ble/syntax/parse は
      % ble-edit/content/update-syntax から単体で呼び出される事もある。という事を
      % 考えると、此処で設定された _ble_syntax_word_u{min,max} は処理される事なく
      % 次の ble/syntax/parse に伝播する可能性があるという事。その時に必要になる
      % と考えられる shift が実行されていない。
      %
      % _ble_syntax_attr_u{min,max} についても同様である。これらもちゃんと shift
      % する必要がある。
      %
      % →と思ったら、ble/syntax/parse/shift の中でちゃんと shift されていた。
      % _ble_syntax_word_ 及び _ble_syntax_attr_ が接頭辞になっていたのだった。


    * done: 着色せずに残っている部分を着色する bgworker を実装する。
      最後まで完了した時に progcolor_dirty を clear する。

    * done: highlight_timeout_background: bg で着色している時の timeout は長めに取る。

    x fixed: 実際に試してみると相変わらず止まってしまう。CPUがぶんぶん回っている。

      調べてみると eval が stop_check なしで呼び出されている。
      stackdump してみると以下の様な呼び出しになっている。
      どうやら simple-word/eval の呼び出し元のチェックに漏れがあった様だ。

      stackdump:
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:27 (ble/syntax:bash/simple-word/eval)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:17 (ble/syntax/progcolor/eval-word)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:5 (ble/syntax/progcolor/word:default/.is-option-context)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:26 (ble/syntax/progcolor/word:default/.impl)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:3 (ble/syntax/progcolor/word:default)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:7 (ble/syntax/progcolor/default)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:31 (ble/syntax/progcolor)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:8 (ble/highlight/layer:syntax/word/.update-attributes/.proc)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:12 (ble/syntax/tree-enumerate-in-range)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:2 (ble/highlight/layer:syntax/word/.update-attributes)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:4 (ble/highlight/layer:syntax/update-word-table)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:32 (ble/highlight/layer:syntax/update)
        @ /home/murase/.mwg/src/ble.sh/out/ble.sh:12 (ble/highlight/layer/update)
        @ /home/murase/.mwg/src/ble.sh/out/ble.sh:9 (ble/textarea#update-text-buffer)
        @ /home/murase/.mwg/src/ble.sh/out/ble.sh:75 (ble/textarea#render)
        @ /home/murase/.mwg/src/ble.sh/out/ble.sh:2 (ble-edit/bind/.tail)
        @ /home/murase/.mwg/src/ble.sh/out/ble.sh:17 (ble-decode/EPILOGUE)
        @ /home/murase/.mwg/src/ble.sh/out/ble.sh:78 (ble-decode/.hook)

      取り敢えずこれについては修正した。

    x ok: 次におかしいのは、既に着色済みの筈単語も改めて毎回着色されている様な気がするという事。

      と思ったらやはり気の所為だろうか。。。今度はちゃんと新しい単語に対しての
      み処理が行われている様な気がする。と思ったが、どうも word:default 自体は
      新しい単語に対してのみ呼び出されているが、simple-word/eval は何度も呼び
      出されているという事の様である。呼び出し履歴を探ると以下の様になっている。

        ble/syntax:bash/simple-word/eval
        ble/syntax/progcolor/eval-word
        ble/syntax/progcolor/word:default/.is-option-context
        ble/syntax/progcolor/word:default/.impl
        ble/syntax/progcolor/word:default
        ble/syntax/progcolor/default
        ble/syntax/progcolor
        ble/highlight/layer:syntax/word/.update-attributes/.proc
        ble/syntax/tree-enumerate-in-range
        ble/highlight/layer:syntax/word/.update-attributes
        ble/highlight/layer:syntax/update-word-table
        ble/highlight/layer:syntax/update
        ble/highlight/layer/update
        ble/textarea#update-text-buffer
        ble/textarea#render
        ble-edit/bind/.tail
        ble-decode/EPILOGUE
        ble-decode/.hook

      うーん。分かった。ble/syntax/progcolor/word:default/.is-option-context で
      全ての引数に対して評価を行っている。ble/syntax/progcolor/eval-word で一応
      キャッシュはしているが、これは一回の着色の内部でのキャッシュであって、着
      色を跨いだキャッシュは行っていない。これはまた別の箇所で対策するべきの気がする。

    x fixed: 展開が timeout した時にエラー着色になっている。
      timeout の時には d で削除する事にしてみたが、
      d ではなく 0 になってしまって黒で塗潰されている。

      どうやら #setattr は g を設定するのであって、
      wattr の指定を行える物ではない様だ。

    * reject: 実は pathname expansion に限らずユーザー入力がある時には単語着色
      は中断して良いのではないだろうか。

      うーん。これは様子見。早く着色が終わる物から順に着色して行かないと、一番
      遅い着色によって他の着色がブロックされてしまう。なので、軽い物は先に処理
      するべき。何段階にも分けるのは現実的でないので、現状は重い単語だけ処理を
      後回しにする事にする。

    x fixed: ble/util/assign の混線に関連して発生していた様々な問題

      x "bash: 予期しないトークン `(' 周辺に構文エラーがあります" というエラー
        メッセージが出る。何処かにバグが有るという事。background で実行している
        時に発生している気がする。先ずは再現性。

      x うーん。操作していると突然 hang して暫くして emacs が起動した

        何やら操作していたら "# reached line_limit_length=10000" に抵触して、そ
        の後に emacs が起動した。2500項目の要素を含んだ "ret=(......) fdsa1
        aaaa" と言った感じの内容が入力されている。これが意味する所は何
        か。_ble_edit_str に内容が展開されているのが原因と考えられるが何が起こっ
        ているのだろうか。

        a ble-decode-char に紛れ込むとは考えにくい。

        b terminal の echo back に引っかかっているとも考えにくい。そもそもその為
          にはそれ専用の escape sequence で囲まなければならないし、それを出力する
          ような事が起こるとも思えない。

        c _ble_edit_str を直接編集している箇所もないだろうし、

        d 一つの可能性は ble/util/assign の混線である。然し、そうだとしても
          ble/util/assign で挿入内容を決定する様な機会があるだろうか。

        TAB は入力していなかったと思う。従って補完が関係している可能性は取り敢
        えず除外する事にする。

        →あー。分かった。ble/util/assign の混線である。conditional-sync で
        timeout した時に動かしていたプロセスを kill するのを忘れていた為に、遅
        延して ble/util/assign の一時ファイルに様々な情報が書き込まれて変な事が
        起こっていたという事。一つ前の問題もこれに関連して発生していた現象であ
        ろうと推測される。取り敢えず再びいろいろ試して問題が再現しないか確認す
        る必要がある。

      x fixed: failglob が発生する様な状況で failglob にならなくなっている。何
        故だろうか。これは瞬間的に timeout になっている所為で、failglob で失敗
        するよりも先に timeout 142 を返して、その為に着色が無効化されているのが
        原因だった。

    * done: glob が有効な場合でも実は最初に noglob で展開を行って、其処に
      rex='[*?]|\[.*\]|[@+!]\(.*\)' が含まれている時に限り改めて
      subshell で実行するという形式にしても良いのではないだろうか。

      これに関してはわざわざ noglob で展開を行わなくても、
      変数代入を実行すれば良いのではないだろうか。
      builtin eval -- "tmp=$word"

    * done: bash3 では globstar を一時的に off にする事も考える。

      然し、そうするとユーザに対して嘘の情報を提供する事になる。本来は一致する
      筈なのに failglob して赤色に着色される等の可能性。そういう事を考えるとや
      はり時間がかかっても良いから着色するか、或いは着色自体を諦めるか。簡単な
      内容の場合には着色を諦めても良いのではという気がする。

      或いは、** が含まれる場合に限って着色を諦めるという手もある。即座に 142
      を出力する様にすれば良い。これで OK

    * done: 変数展開の中まで参照して noglob かどうかを判定する前に、
      先に extract-parameter-names & 変数内容の復元をするべき。

      再び eval の構造を大きく書き換えたが取り敢えずは動作している模様である。
      取り敢えず conditional-sync を経由した展開も動いている様子だ。OK

    x 別項目: 全く同じ内容で eval を連続して2回試すという事が頻繁に起こっている。
      これは何だろうか。やはり eval-word による呼び出しと、それから本当の着色用
      の呼び出しが混ざっているという事だろうか。これに関しては、eval の呼び出し
      をキャッシュする事で対応できる気がする。

      但し呼び出しをキャッシュすると言っても、bash3 でどの様に対処するべきかは
      微妙である。やはり汎用の hash 辞書のインターフェイスを準備するべきかもし
      れない。

      これは調べてみた所、ble/syntax:bash/simple-word/detect-separated-path と
      ble/syntax:bash/simple-word/evaluate-path-spec の二箇所で発生していれう事
      の様である。これは eval の内容をキャッシュする様にすれば解決する話である。
      独立項目で取り扱う事にする。

2021-01-25

  * edit: change default behavior of "C-w" and "M-w" to operate on backward words (reported by 3ximus) [#D1448]

    ? done: C-w の振る舞いを readline に合わせる?

      後、やはりここまで来ると普通の bash との振る舞いの違いが俄然気になってくる。
      やはり C-w は kill-uword ではなくて kill-backward-uword であるべきなのではないか。
      やはり既定で kill-backward-uword にする様に変更する。
      M-w による copy-backward-word についてはどうするか。
      どうも readline の copy-backward-word は widget copy-uword と同じ振る舞いの様である。
      しかし、M-w は元の readline では使われていないし、
      ble.sh の M-w でどの様に振る舞っても問題はない気がする。

    ? ok: C-w で kill-uword する現在の振る舞いに何か理由があっただろうか。
      何か理由があって敢えて現在の振る舞いにしている可能性もある。

      bbbd155f src/edit.sh (Koichi Murase     2019-03-22 07:28:24 +0900 6763)   ble-decode/keymap:safe/.bind 'C-w'       'kill-region-or kill-uword'
      1fc7cbaf ble-edit.sh (Koichi Murase 2017-12-04 20:48:17 +0900 6185)   ble-decode/keymap:safe/.bind 'C-w'       'kill-region-or uword'
      f18485f0 (Koichi Murase 2017-12-04 14:36:52 +0900 4442)   ble-bind -f 'C-w'       'kill-region-or uword'
      3aa7fa66 (Koichi Murase 2017-12-03 18:31:00 +0900 4461)   ble-bind -f 'C-w'      'kill-region-or uword'
      6ca737d2 (Koichi Murase 2015-02-28 12:48:55 +0900  54)   ble-bind -f 'C-w'      'kill-region-or uword'
      ^c68412b (Koichi Murase 2015-02-09 03:13:19 +0900 3381)   ble-bind -f 'C-w'      'kill-region-or uword'

      どうやら一番最初に commit した時から現在の振る舞いだった様だ。
      ここから分かる事は現在の振る舞いに根拠はないという事。
      実装初期に kill-backward-uword がなかったか不完全だった時からこうである可能性がある。
      なので、振る舞いを現時点で変更しても何の問題もない。

      copy-uword vs copy-backward-uword についても全く同じだった。
      最初から M-w は copy-uword になっていた。

    これは他の ble versions にも適用した方が良いと思われるので独立した commit にする事にした。

  * edit ({kill,copy}-region-or): fix unconditionally combined kills/copies (reported by 3ximus) [#D1447]
    https://github.com/akinomyoga/ble.sh/issues/83#issuecomment-766831785

    C-w で無限に文字列が追加されてしまうという事を指摘された。

    % 何故だろう。手許で確認した時には動いている様に見えたのに。と思ったが手許で
    % 試した時は C-k や C-u を使っていたために気づかなかったという事の気がする。
    % →と思ったら分かった。テストのために自分で ble-bind していたが、
    %   その時に kill-region-or を使っていなかった。

    kill-region-or または copy-region-or の中で
    ble/decode/widget/call を用いて widget を呼び出した時に
    LASTWIDGET が {kill,copy}-region-or に書き換わる為に、
    無条件に前回のコマンドが切り取りコマンドであったと判定されてしまうのが原因。
    取り敢えず修正した。ble/decode/widget/* の関数がまた増えてしまったが仕方がない。

  * mandb: man のオプションの情報が文字化けしている [#D1446]

    % キャッシュが全然使われていない。毎回再生成されている様に見える
    % と思ったが、これは単に core-complete.sh が更新されたから、
    % それに応じて更新されているというだけの事だった。

    データを再生成してもやはり同様に文字化けしてしまう。

    調べると nroff は UTF-8 には対応していない様だ。groff は groff -k にて
    UTF-8 に対応する様だ。更に -k に加えて -Tutf8 も必要だった。

    groff ではなくて nroff の時にはどうするのかという問題は残るが、まあ groff
    のないシステムでは UTF-8 の man は存在しないと思って良い気がする。なので取
    り敢えずは気にしない事にする。

  * 2020-11-02 complete: support complete_limit{,_auto} (contributed by timjrd) [#D1445]
    https://github.com/akinomyoga/ble.sh/issues/64
    https://github.com/akinomyoga/ble.sh/issues/65

    これは時間はかかったが無事に merge まで行った。

    * done: source:file において substr を実装する。
    * done: filter を自前で実行する場合には cand/yield 内部での filter は不要。
      これは flag_source_filter=1 を設定して実行する事にした。
    * done: timjrd を README/acknowledgement に追加する。
    * done: complete_limit_reached にリークが存在している。
      ちゃんと source:* や candidates/generate などのコメントに使う変数を記述して、
      それから auto-complete の中で candidates/generate を呼び出す前に local で宣言する。

  * main: nfs の上に _ble_base_run があると問題になるのでは [#D1444]
    取り敢えずローカルに runtime directory を作る時には $HOSTNAME も含める事にした。
    XDG_RUNTIME_DIR 及び /tmp を使う場合には host specific であると期待してその儘にする。

2021-01-22

  * edit: C-w で kill-ring への追加を実装するという事 (suggested by 3ximus) [#D1443]
    https://github.com/akinomyoga/ble.sh/issues/83#issuecomment-764893198

    これについては先ず初めに仕様を確定しなければならない。

    例えば前方を切り取るコマンドの場合には必ず左に挿入する事にする? と思ったが、
    そうすると C-k を連続で使用した時に、切り取られる行の順序が逆になってしまう。

    ? というよりどの様なコマンドが存在しているだろうか。

      | 調べると C-k, C-u, C-w, M-d, M-h で kill-... を実行している。
      |
      | widget 名で言うと
      | - kill-{forward,backward}-{?word,{graphical-,logical-,}line,text}
      |   これの対応は簡単。backward に削除する場合には prepend し、
      |   forward に削除する場合には append すれば良い。
      | - kill-{?word,{graphical-,logical-,}line}
      |   これは微妙。emacs でどの様に振る舞っているだろうかと考えたが、
      |   よく考えてみたらその様に振る舞う物は存在しない気がする。
      |
      |   emacs.rlfunc.txt で対応表を見てみたが、kill-line に対応する
      |   rlfunc kill-whole-line しか振る舞いを確認できる物が存在しない。そして、
      |   この rlfunc kill-whole-line は kill-line と違って、
      |   コマンドライン全体を切り取ってしまうのでやはり振る舞いとして異なる。
      |
      |   と思ったが、実際に readline で実行してみると kill-whole-line は
      |   前回の内容に append する様である。取り敢えず ble.sh でもその様に振る舞う事にする。
      |
      | - kill-region
      |   これは前回の内容は完全に忘れるという振る舞いで良い。
      |
      | - vi_imap/delete-backward-word
      |   これは実は kill-ring には何も影響を与えない様だ。取り敢えず無視する事にする。
      |   readline の vi mode の時には kill するが combine はしない様だ。

      →結論としては、kill-region,kill-region-or 以外の kill-* は全て対象という事。
      kill-backward-* に関しては prepend で、それ以外については append という事。

    ? ok: append/prepend をした時に元々あった内容を上書きするのか、
      新しく項目が追加されるのか。
      →試して見た所、上書きする様である。

    ? done: /.*-range の allow_empty という引数は必要なのだろうか。
      kill,copy,delete に関しては決して指定される事はない。
      replace に関しては大体指定されている。
      指定されていない物は意図的な物かどうか確認する必要がある。

      - ./keymap/vi.sh:3995:    ble/widget/.replace-range "$eol1" "$eol2" "$text"
      - ./keymap/vi.sh:4016:    ble/widget/.replace-range "$eol1" "$bol2" "$text"
        上記二つに関しては eol1<eol2 が保証されているのでどちらでも良い。
      - ./lib/core-complete.sh:5832:    ble/widget/.replace-range "$pos" "$comp_index" "$value"
      - ./lib/core-complete.sh:5865:      ble/widget/.replace-range "$pos" "$comp_index" "$value"
      - ./lib/core-complete.sh:5871:    ble/widget/.replace-range "$pos" "$comp_index" ''
        上記3つに関しても同様に pos<comp_index が保証されている。
      - ./lib/vim-surround.sh:509:  ble/widget/.replace-range "$beg" "$end" "$content"
        operator なので幅0になる事は余りない気がするが、例えば編集文字列が空の時?
        →うーん。その様な場合であっても cs 経由でしかこの operator は呼び出されないので、
        結局、delimiter を使って範囲を切り出そうとする段階で失敗してしまう。
        結局、この operator が空文字列に対して呼び出される事はない気がする。

        もし仮に呼び出される事があったとしても、allow_empty を指定する方が自然。

      replace-range については常に allow_empty という事にする。
      kill,copy,delete については常に not allow_empty という事にする。
      →書き換えた。

    ? done: copy でも同様に振る舞う必要があるだろうか。
      →実際に試してみた所、同様に振る舞う様である。。。

    動かしていて気づいたが、C-k で行末の改行を削除できていない…。
    これは別 commit での bugfix にする事にする。

  * edit: support "bleopt edit_line_type" (motivated by 3ximus) [#D1442]
    https://github.com/akinomyoga/ble.sh/issues/83

    手で一つ一つ logical-line を明示的に指定するよりは、
    一つのオプションで一括で切り替えられる様にした方が良い。
    更に、今まで既定で graphical line を使っていたのを、
    logical line を使う様に変更する事にする。

  * edit (sword): fix definition of sword (motivated by 3ximus) [#D1441]
    https://github.com/akinomyoga/ble.sh/issues/83#issuecomment-764893198

    この質問で具体的に各単語がどのような定義になっているのか説明しようとして
    コードを参照した時に気づいた。sed によって & が置換前の文字列に展開されて、
    変な事になっていたのが原因。

2021-01-17

  * LC_CTYPE の切り替えエラーが出る (reported by 3ximus) [#D1440]
    https://github.com/akinomyoga/ble.sh/issues/81

    実際に確かめてみたら確かにエラーメッセージが出る。
    過去に対策したつもりだったが対策の仕方が間違っていた。
    色々実験した所、結局余計に一つ関数呼び出しをしなければ駄目な様だ。
    自動で stderr を抑制するように書き換える汎関数を作って対応する事にした。

2021-01-01

  * decode (ble-decode-kbd): support various keyseq specifications [#D1439]
    https://github.com/urbainvaes/fzf-marks/pull/41
    https://github.com/urbainvaes/fzf-marks/pull/43

    上記で ble.sh 特有の binding を追加してもらったが、ble-bind がユーザーが自
    由に対応キーを指定できる様に公開されている変数 FZF_MARKS_JUMP の形式に合わ
    ない為に C-g 決め打ちになってしまっている。ble-bind でも bind と同様の形式
    で keyseq を指定できる様にしたい。

2020-12-25

  * edit: f1 で関数定義を表示する時に LESS=-r が効いていない [#D1438]
    これは bash のバグの様である。バグ報告は bug-report でする事にして、
    ここでは簡単に修正してしまう。

  * edit: 2020-12-09 READLINE_MARK, etc. の値が残ってしまっている [#D1437]

    これは ble/textarea#adjust-for-bash-bind によって設定されている値である。
    コマンドを実行する時に復元・保存する様にするのが良いのではないだろうか。

    * 何故か READLINE_LINE, READLINE_POINT が export されている。
      と思ったが、これは ble.sh を bind -x の内部で動かしているからであった。
      READLINE_LINE 及び READLINE_POINT が

    * 普通の bash で実行するとどうなるのかと思ったが、どうやら自分で設定した
      READLINE_LINE 及び READILNE_POINT があっても bind -x の実行と共に削除され
      てしまう様である。

    取り敢えず adjust/restore する様にした。コマンドの実行の間で値が保存される
    様にした。bind -x が実行されても値がクリアされる事はない。

2020-12-20

  * [解消] 2020-09-27 SIGWINCH で job メッセージが出る [#D1436]
    2020-12-20 これは #D1435 と同一の問題であろう。直ったと見て良い。

    SIGWINCH に対して次の様な job メッセージが表示される様になっている。
    [1] 終了 [[ -n $_dotfiles_blesh_manual_attach ]] | [[ -n $_dotfiles_blesh_manual_attach ]]
    これは .bashrc で設定されている関数の一部である。何故?

    調べてみるとそもそも関数ですらなくて、
    これは ble-attach を呼び出す条件の中に含まれているコマンドだと分かった。
    つまり SIGWINCH に際して ble-attach 関連の何かが呼び出されて、
    そして最後に呼び出された ble-attach の呼び出し時のコマンド文字列が何処かに保持されている?
    もしくは再び .bashrc が source されている可能性もあるがやはりそれは変だ。

    2020-10-10 今試してみると再現しない。


  * edit: WINCH 後に偽のジョブ情報が表示される (reported by 3ximus) [#D1435]
    https://github.com/akinomyoga/ble.sh/issues/78

    前回報告を受けていた謎のジョブ終了メッセージについて。
    これは端末のサイズを変えた直後に起こるという新情報を得た。
    3ximus/dotfiles の .bashrc を確認して再現を試みた所、
    git-prompt.sh, prompt_7.sh, ble.sh の組み合わせで再現できた。

    更に設定を最小化していく。どうやら fork があると
    jobs にメッセージが乗る様になってしまうらしい。

    これの回避方法としてどの様な方法があるか。

    a jobs で得た新しいイベントを除去する?
      然し、これの問題点は唯の fork と、
      本当にジョブとして起動したコマンドの区別が付かないという事。

      振る舞いの違いとしては trap handler の中で発生したfork に対応するジョブの
      情報は trap handler を抜けた時に消滅しているという事である。

      但し、バックグラウンドとして起動したコマンドのジョブ情報もtrap handler を
      抜けると消えてしまうのかもしれない。試せば分かるが面倒なので必要になった
      ら確認する事にする。

    b もう一つの方法はシグナルを処理している時は
      jobs の更新は行わないという物。これが妥当な気がする。

      ? この現象が起こるのは WINCH だけなのか、或いは別のシグナルでも発生するのか。
        →確認した所、INT でも同様にジョブ情報に fork が乗る様である。

        trap '(true); jobs' INT

      ? 現在シグナルの中にいるかどうかを判定する方法は存在するだろうか。
        或いは ble.sh の枠組みの中で trap-handler 経由で呼び出されたか
        どうかの情報を用いて判定する?

        trap-handler の中にいるかどうかの判定方法。一つは return を
        使って関数を抜けた時に、直前の exit status を返すか、
        或いは固定の exit status を返すかを見るという方法。
        よく考えたらこれは bash-4.4 以降でしか使えない。
        Bash はこの部分について振る舞いを変更したのだった。

    % 取り敢えず b の方向で実装する事にする。
    % ble.sh の中での jobs の仕様実態について確認する。
    %
    % どうやら指定した名称に対応する jobs が存在するかどうかの確認にも
    % jobs -- "$value" を使用している様である。これについては、偶々
    % value に一致する終了したジョブ名が存在すると jobs -- "$value" を実行する事によって
    % その情報がジョブ情報のリストから削除されてしまう。この問題を回避する為に
    % jobs -- "$value" を実行する為に ble/util/joblist.check を実行しているが、
    % trap handler の中で joblist.check をスキップしてしまうと、
    % そのジョブ情報が正しく拾われずに消滅してしまう可能性が残る。
    % trap handler の内部では jobs はサブシェルで実行するのが良い気がする。
    %
    % 1 done: 何れにしても最初に trap handler の中で実行しているかどうかを確認す
    %   る必要がある。特に ble.sh の実装が原因で発生する変なメッセージを防げれば
    %   良いので、trap/.handler の中でローカル変数を定義する事にする。
    %
    % 2 done: jobs を使っている箇所を確認する。
    %
    %   * util.sh は ble/util/joblist だけでしか jobs を呼び出していない。修正した。
    %   * core-syntax.sh も ble/syntax/highlight/cmdtype/.is-job-name だけで使っ
    %     ている。対策した。
    %   * edit.sh では ble/builtin/exit で終了する時にユーザに確認を求める所で実
    %     行しているが、exit する時には何れにしてもジョブ一覧を出力するので敢えて
    %     直接実行する。変なジョブ情報が出力される事になってしまうがこれは仕方が
    %     ない。
    %   * 他に ble/widget/command-help/.type で jobs -- "" を実行している。これに
    %     ついても修正を行った。
    %
    % 3 動作確認: さて、実際に修正して見た所直っていない。どうも trap を抜けた後
    %   も変なジョブ情報は残っている様である。ユーザのコマンドとして jobs を実行
    %   すれば変なジョブは消えてなくなっているが、bind -x の中から jobs を呼び出
    %   すと全て出力されてしまうという事だろうか。
    %
    %   サブシェルの中で jobs を実行する様にした結果か、余計に大量の偽ジョブが登
    %   録されてしまっている。
    %
    % 改めて bind -x を組み合わせた時の動作についても確認する→うーん。再現した…。
    % WINCH の直後の bind -x の中で jobs を実行すると偽情報が出る。
    % 別の bind -x を一回実行してから次の bind -x で jobs を実行しても再現する。
    % bind -x 以外の入力を行った後でも、bind -x の中で jobs を実行すると再現する。
    % 一回でもユーザコマンドを (空でも良いので) 実行すると、偽情報は出なくなる。
    %
    % こうなって来ると変なジョブ情報が消えるのを待つ作戦に頼るのは困難である。
    % 今までの変更は取り敢えずなかった事にする。

    うーん。trap/.handler の中で jobs を敢えて実行して結果が描画に回る前に
    偽情報をクリアしてしまう事にする。blehook WINCH を実行する前に joblist 更新をして、
    更に実行した直後にも joblist の更新を行う。二回目の joblist の更新では、
    一時的に現れてそれで直ぐに消滅したイベントはイベントとして登録しない事にした。

    これだと blehook WINCH を実行している最中に終了した本当のジョブ終了の情報が
    消滅すrことになるが、実際に blehook を実行している途中に jobs の状態変化を
    Bash が受信するのか不明だし、もしそうだとしても blehook WINCH の処理のよう
    なごく短時間でその様な事が起こる確率は低いと考えられる。なので、気にしない
    事にする。

    取り敢えず動いてはいる様子である。

2020-12-14

  * progcomp: : や = の quote の取り扱い (reported by 3ximus) [#D1434]
    https://github.com/akinomyoga/ble.sh/issues/77

    ? そもそも \=, \: の様にエスケープしていたのは何故だったか。

    ? bash-completion の提供した補完に対して \= や \: の様にエスケープを実施す
      る必要はあっただろうか。その辺りの実装はどの様になっていたのだったか。

    関連しそうな物を探す。ble-0.3 では = のエスケープはしていない。

    #D1133 でコマンド名に関しては =, : の quote はしない様にしている。
    #D1098 6c6bae56 で = や : のエスケープが導入されている。
    #D1094 では = や : による候補の分割を議論している。

    うーん。元々エスケープは #D1098 で導入された物の様だが深くは考察していない。
    改めてどの様に振る舞うのが自然か考察する必要がある。

    * そもそも ble.sh の補完は展開後の結果を生成して貰う前提になっている。
      一方で bash の補完は展開前の結果を生成する事を許容している。
      例えば abc$(echo hello) の様な文字列を補完で生成する事すら可能なのである。
      それどころか複数単語からなる展開結果にする事も可能の筈である。

    * それでは progcomp の結果はそのまま挿入する事にすれば良いのではないか
      とも思われるが此処で問題になるのは、ble.sh の側で適当に展開を実行してから
      COMP_LINE を構築して progcomp に渡しているという事である。

      これは途中に $var 等の単純な展開等が含まれている場合でも
      progcomp で補完を実行できる様にする為に必要。

      この時、progcomp が展開前の補完結果を生成した時に、
      それを如何に元のコマンドライン文字列に反映させるのかが問題になる。

    x [OK] 手許では再現していないが scp chat\:down[TAB] で chat\: が消滅してしまう?

      notepc の方は bash_completion が入っていないので今試せない。
      * chat は port を変えているので localhost: から試そうとしてもできない。
        localhost や chat を .ssh/config に登録してパスワード無しで補完できる様にしたが、
        補完候補は出してくれない様である。
      * hp2019 -> chat を試してみたが再現しない。local にも mkdir downloads したが再現しない。

      うーん。取り敢えずそもそも何故失敗するのか考える?
      plain bash で実行したところ failglob で失敗している。
      shopt -u failglob にしたら ble.sh の中でも補完が動く様になった。

      そして chat\: が消滅してしまう問題に関しては、
      plain bash でも再現する事ができた。
      これは bash-completion の問題である。

      特にローカルのカレントディレクトリに "host:..." というファイルが存在する時に、
      host\:... と入力している可能性があって、この時に host: の部分が消滅してしまう
      という問題が発生する。

      https://github.com/scop/bash-completion/issues で報告をしようかと考えたが、
      もしかすると最新版で直っている可能性もあるので、
      最新版の bash-completion を試してみても良い。

    うーん。progcomp による展開結果が空白などを含んでいる時にどのように振る舞うのか。
    plain bash はそのまま何も加工を行わずに展開してしまう。うーん。
    blesh ではどの様に取り扱うべきか。

    * できるだけ progcomp が提供した quote を保持する様にしたい。
      然し、これは現実的には難しいのではないか。

      a = 及び : についてだけ quote しているかそうでないか保持する? それ以外の
        文字については自分で quote し直す。

        その為には progcomp が生成した単語について = や : で分割を試して、その
        上でそれぞれ quote してから再結合する? これだといかにも処理量が大きい。
        非効率的である。

        これは処理方法として複雑でありユーザから見たら不自然で予測不能に見える
        かもしれない。処理の重さとしては次に述べる方法よりは現実的である。

      b 入力済みの部分に一致する部分を除去してそのまま挿入。

        ここで問題になっているのは既に入力済みの部分に対応する文字列を
        どの様に取り除くのかという事であった。二分法を用いる等して
        これについて既に入力済みの部分を除去する方法はないだろうか。

        どの様にしたら良いのかを調べる必要がある。二分探索で調べるという方法と、
        1 unit ずつ読み取って行くという方法の二種類を考える事ができる。

        * 二分探索で調べるというのは複雑な気がする。元の文字列について途中で切
          断して二分探索していくという手も考えられるが、変数名の途中など変な所
          で切断すると内容が空になるなどして意図しない結果になってしまう。

        * 取り敢えず 1 unit (simple word element) ずつ読み取って行って、切断す
          るという方法? 然し、'...' 等の様に一気に読み取る事ができるliteral 等
          になっているとすると、実装が複雑になる。面倒である。そもそも処理が複
          雑になる。面倒である。

      c 今まで通り基本的に progcomp が生成した物は展開毎と見做して quote を行う。
        = 及び : は基本的には quote を加えない。compopt -o filename で quote が
        明示的に指定された時にのみ =, : の quote を行う。

        これは progcomp が quote を自前で行って候補を生成した時に問題になる。つ
        まり quote が二重に為される事になり、意図しない結果になってしまう。然し、
        この問題は今までにも存在していた問題の筈である。取り敢えずの修正として
        は妥当である。

    取り敢えず今までも quote を勝手にする事による問題はあった。
    全てを一度に解決するのは難しいししなくても良い。
    此処は c の方針で修正する事にする。

2020-12-13

  * README: ((_ble_bash)) && ble-attach だと set -u の時駄目 [#D1433]
    ble.sh ロードに失敗した時や ble.sh を意図的に読み込まなかった時に
    _ble_bash が存在しないので内容をチェックする前にエラーになってしまう。

    [[ ${BLE_VERSION-} ]] && ble-attach にするべき。

2020-12-10

  * complete/mandb: FreeBSD 上で man 情報の抽出に失敗している [#D1432]

    | freebsd には roff, nroff, troff 等が存在していない。
    | それでも man が動作している事を考えると、
    | 何らかの方法で man pages を変換しているという事の筈。
    | それについて調べて対応する。

    対応した。FreeBSD では mandoc というコマンドを使って変換を行っている。
    nroff と同様に -man 等を指定する事ができる様だが、
    どうやら FreeBSD は -man ではなくて -mdoc を想定して man pages を書いている様だ。
    という訳なので -mdoc を前提として抽出をする様に書き換えた。

    ちゃんと nroff を使う版も動いている。OK

  * highlight: command \^J-a とした時に -a がオプションとして着色されない (reported by cmplstofB) [#D1431]
    https://github.com/akinomyoga/ble.sh/issues/76

    現在の着色では \-a や ''-a 等の様に quote がある場合には、
    意図的にオプションとしての着色を避けている。
    そういう意味に於いて \^J-a もやはりオプションの前に quote が
    ある物として取り扱ってオプションとしての着色が無効になっている。

    a 然し意味的に考えるとやはり \^J は単語の一部に含まれない様にするのが自然に
      も思われる。

      ? その様に構文解析を変更する事は恐らく簡単だろうが、単語の一部として解析
        しない部分文字列がコマンドラインに含まれる事による副作用などはあるだろ
        うか。思うにリダイレクションなども単語の一部として登録していないので、
        特にこの事で問題が発生する事はない気がする。

      また sabbrev の単語判定でもやはり語頭の \^J は含まれない様にしたい。

    語頭の \^J は skip する事にする。これはどの様に実装すれば良いか?
    ^J や空白を処理している箇所で一緒に処理すれば良いだろうか。

    取り敢えず構文解析は修正した。多分大丈夫。副作用が起こるかもしれないが、
    それは実際に何かが起こってから見るという事で良いだろう。
    うーん。問題が起こるとすれば二次的に起こる問題ではなくて、
    構文解析自体が変になる可能性が高い気がするが多分大丈夫。

  * color: italic が描画できていないという (by rlanore) [#D1430]
    https://github.com/akinomyoga/ble.sh/issues/73

    試してみると手許では動いている。対応していない端末で使おうとしているのではないか。
    この Issue には返信がないがもう一つの新しい Issue に対して Terminal 情報を載せている。
    Terminator 1.92 を使っている様である。

    Cygwin 付属の Terminator 0.98 は italic に対応していない。
    Cygwin 附属の GNOME terminal は対応している。
    vte のソースコードを見ると 2012 には italic 関連のコードが存在している様だ。
    2014 にまた別のフォント初期化コードが追加されている。然し一方で pango も呼び出している。
    これが実際に X11 環境で使われるのかどうかはよく分からない。

    →これは結局向こうの tmux の設定が問題であった。手許で試して見たところに依
    るとどうも tmux は default-terminal の値に応じて自身の振る舞いも変更する様
    である。これについて wiki の manual にも書いておく必要があるのではないか。
    →wiki に説明を追加した。

  * complete/mandb: ^H が大量に挿入される (reported by rlanore) [#D1429]
    https://github.com/akinomyoga/ble.sh/issues/75

    これは nroff で太字を表現するのに <CHAR>^H<CHAR> を出力する物がある為。
    なので、単に .\b を削除すれば良い。

    取り敢えず修正してみたが本当に動くか微妙。複数の OS で試す必要があるのではないか。
    freebsd で試して見たところ、troff がないので動いていない。
    これについては後で対応する事にする。

2020-12-09

  * complete: 補完候補が更新されない問題 (reported by 3ximus) [#D1428]
    https://github.com/akinomyoga/ble.sh/issues/74

    これは明らかに menu-filter で候補がなくなった時に、
    元の候補を全て表示する様に変更したのが原因である。
    やはり一致しなくなった時点で候補は表示しない様に変更する事にした。

    b 或いは別の変更方法として、候補再生成のフラグを設定して、
      この時にはメニューから候補を拾う事はしない様にする?

      x と思ったが、そうすると結局候補を全て表示する意味がない? 候補を表示する
        のはメニューから選択させる為であるが、メニューから候補を拾わない様にし
        た時点でそれが使えない?

        % x と思ったが連続 TAB や、明示的な menu-complete の bind の時には、候
        % 補の再生成をせずに menu に入る事が可能になる。

        でも連続 TAB の場合は最初の TAB の時点で候補再生成が起こるので、表示し
        ている候補が使われる事はない。明示的な menu-complete の bind についても
        既定では C-TAB 等余り使われなさそうな物になっているので設計に考慮に入れ
        なくて良い気がする。

      此処まで処理を複雑にしても余り有用ではなさそう。次の TAB で候補一覧はすぐ
      に消えてしまうので、絞り込み前の候補一覧を表示しても却って混乱を生むだけ
      である。この選択肢は却下である。

2020-12-08

  * util/term: lxterminal, gnome-terminal で vte の検出に失敗している [#D1427]
    これはソースコードを確認してみた所、xterm の version 抽出コードを追加した時
    に動かなくなった物の様に見える。修正した。