# -*- coding: utf-8; fill-column: 79 -*-

拡張

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

  * compopt -o ble/syntax-raw
  * compopt -o ble/no-mark-directories
  * compopt -o ble/prog-trim
  * compopt -o ble/no-default
  * HISTCONTROL=strip

制限

  * ble.sh を attach しているとき builtin read -e は動かない。
    代わりに ble.sh が定義したシェル関数 read (組み込みコマンドを上書き)
    を用いて read -e を呼び出す必要がある。

  * bash-3 C-d について

    今は何とか C-d を処理する事に成功しているが完全ではない。

    1 C-d を押した時に bash が出力するエラーメッセージを使って捕捉している。
      このエラーメッセージは言語や設定によって異なると思われる。
      現在は以下のメッセージを調べている。
      - 'Use "exit" to leave the shell.'
      - 'ログアウトする為には exit を入力して下さい'
      - 'シェルから脱出するには "exit" を使用してください。'
      自分の bash が異なるメッセージを出力する時は
      それを bleopt_ignoreeof_message に設定する。
    2 連続で沢山 C-d を押すと "^D" が echo されて表示が乱れるかもしれない。
      最悪の場合 C-d によって bash プロセスが落ちる可能性もあるかもしれない。
      (未だ落ちた事はないが)。
    3 C-d を処理する為に SIGUSR1 を使用している。
      その為 SIGUSR1 を別の目的で使用する事は出来ない。

  * 文字コードについて

    現在は基本的に UTF-8 を想定している。
    それ以外の環境のためには少なくとも以下の修正が必要になる。

    - ble.sh 自体を iconv で変換する事。或いは日本語を完全に排除する事。

      現在のところは日本語はコメント中にしか含まれていないはずである。
      コメントさえ削除すれば何処でも動くようになっていると良い。

    - 使いたい文字コード → unicode のデコーダを自分でかく事:
      これは "function ble-decode-byte+文字コード" を実装すれば良い。

    - Unicode → 文字のコードが正しく動作する様にする事:
      これは .ble-text.c2s (ble-core.sh) の辺りを直せばよい。
      "ble-text-c2b+文字コード"
      "ble-text-b2c+文字コード"
      も実装する必要がある。

    - ble/encoding:$bleopt_input_encoding/generate-binder

      現在 "C-@", "ESC" 及び "ESC *" を bind する為に、
      その符号化形式の非正規な符号に変換している。
      この変換はシェル関数 ble/encoding:$bleopt_input_encoding/generate-binder
      において文字符号化方式毎に (UTF-8 前提の設定を上書きする形で) 定義する。

      また bind を記録したキャッシュは $bleopt_input_encoding 毎に保持するが、
      このキャッシュの更新は bind.sh のタイムスタンプしか見ていない (ble-decode/bind 内)。
      新しい符号化方式を定義する時には、タイムスタンプを参照するファイル
      (ble/encoding:$bleopt_input_encoding/generate-binder を定義するファイル) を決める必要がある。


    他の文字コードは未だ一回も実装していないので上記以外にも必要な作業が出て来る可能性がある。

    + 2015-11-30 Note: ble-decode.sh (generate-source-to-unbind-default)

      文字コード実装時に問題があるかも。

      現在、bind -sp が出力する中途半端なバイトを解釈する為に、LANG=C で awk を起動している。
      UTF-8 の場合には複数バイト文字を構成するバイトは ASCII 文字と被らないので問題ないが、
      Shift_JIS 等の場合には ASCII 文字、特に \ や " を含む可能性がある。
      この場合には LANG=C にしていると問題が生じる。
      というか、bind -sp の出力する中途半端な文字と、複数バイト文字の一部を本質的に区別する方法はない様に思われる。

      ただし、救いは、もし ble.sh を plain な bash の上で起動するとすれば
      日本語で bind -sp に登録がなされていることはないだろうということである。
      つまり、ユーザが手で (或いは .inputrc に) bind '"日本語":"にほんご"' などとしない限りは問題は生じない。

  * bash-4.0, 4.1 において特殊シェル変数 FUNCNAME をユーザが unset した上で、
    関数内から ble.sh を source すると ble の使う連想配列がローカルに定義され問題になる。

    - bash-4.0 以降では連想配列を用いるが bash-4.2 未満では、
      連想配列を明示的にグローバルに配置することができない。

    - FUNCNAME がユーザによって削除されていなければ、
      この変数を用いて関数内から source されたことを検知できるので、
      その時には配列実装に fallback する。
      FUNCNAME が削除されていると fallback に正しく切り替わらずに問題になる。

  * bash-4.3 では C-x は、次の文字が来るまでは受信できない。
    bash-4.0 - 4.4 の他の version では遅延はないのでこれは bash-4.3 特有の問題である。

  * 構文に従った着色の中には bash の不自然な振る舞いや、
    複雑な振る舞いのために正確さを諦めた物がある。

    - bash の最初の [@()] の構文解析とパス名展開時の解析の齟齬

      echo [@(echo|[...])]

      恐らく bash は最初の単語の切り出しで @() を一単位として読み取り、
      ["@(echo|[...])"] の様に読み取る。その上で、改めてパス名展開を適用するが、
      その時には ["@(echo|[.."]")]" の様に解釈する。
      つまり、初めの構文解析とパス名展開の適用の間に齟齬がある。

      ble.sh では構文解析に従った解析・着色をすることにしたので、
      実際のパス名展開の適用結果が着色と異なることがあることに注意する。

    - bash echo {@(,)}

      これについても上と同様のことが起こる。
      単語の切り出しは {"@(,)"} となり、構文エラーは発生しない。
      後のブレース展開では {"@(",")"} と解釈されて分割される。
      単語が分断されてしまうのでパス名展開は起こらない。

    - bash のブレース展開時の ${var:-...}{,} の解析とパラメータ展開時の解析の齟齬

      echo ${var:-{a,b}{a,b}

      恐らく bash は最初にブレース展開を試みる時に、
      ${} の中については {} の入れ子を数えてスキップする。
      従って、上のコマンドの時は ${} が終端しないのでブレース展開は試みられない。
      しかし、パラメータ展開が実施される時には {} の入れ子は考慮に入れられず、
      最初に現れた "}" で終端するので、${var:-"{a,b"}"{a,b}" という解釈になる。

      [予定]
      ble.sh ではどの様に着色するか微妙である。
      理想的には最終的な解釈の ${var:-"{a,b"}"{a,b}" に応じた着色にしたいが、
      後半の {a,b} の部分が {} の入れ子のアンバランスによって
      無効化されている事を検出するのは困難である。
      仕方がないので、ブレース展開の {} の入れ子の勘定はバグとして無視する事にする。
      つまり、echo ${var:-"{a,b"}{a,b} という解釈で着色する。

    - bash のチルダ展開の時の echo a[]b]=~ の解析と、パス名展開の時の解析

      チルダ展開の時には a["]b"]=~ とはならず a[]"b]="~ という解釈になるので、チルダ展開は起こらない。
      一方で、パス名展開のときには a["]b"]"=~" という解釈になり、'ab=~' などのファイル名に一致する。
      ble.sh ではパス名展開の規則の方を優先させる。

    - ble.sh では [[ @({a,b}) ]] のブレース展開が有効であるかの様に着色される。

      実際には、条件コマンドの中ではブレース展開は無効になる。
      これに正確に対応する為には "条件コマンドの中の extglob"
      に対応する文脈値を定義する必要があるが、煩雑になるので対応していない。

    - ble.sh では echo [{@(a|b),[abc]}] の内部の extglob や [...] が有効であるかの様に着色される。

      しかし、実際にはブレース展開を実行したとしても [] の内部なので、
      extglob や [...] は不活性化しているはずである。
      しかし、これも解析が無意味に複雑になるので対応はしない。

    - ble.sh では echo {~user,~user} の内部のチルダ展開に反応しない。

      bash ではブレース展開された後にチルダ展開が実行されるので有効。

    - ble.sh はブレース展開が含まれる変数代入形式単語でも、
      ブレース展開より前のチルダ展開は有効である。

      bash では変数代入形式の単語の右辺でチルダ展開が起こる。
      しかし、ブレース展開が含まれている場合には例外としてチルダ展開が起こらない様だ。

      $ a=~:{a,b}:~:echo      → ブレース展開は起こらず、チルダ展開は起こる。
      $ echo a=~:{a,b}:~:echo → ブレース展開が起こり、チルダ展開は起こらない
                                 ble.sh では一つ目のチルダ展開の解析時点では、
                                 次にブレース展開が来ることを知らないので、
                                 一つ目の ~ はチルダ展開として着色する。

      規則がよく分からないが、取り敢えず ble.sh ではブレース展開が現れたら、
      それ以降はチルダ展開が無効になるようにしている。
      具体的には _ble_syntax_bash_command_IsAssign[ctx] の設定されている文脈は、
      ブレース展開が現れたときに、変数代入形式前の文脈値に戻すようにしている。

    - echo [a[!b

      echo [! の組み合わせは履歴展開にはならない。
      echo [a[!b] の場合にも履歴展開にはならない。
      しかし、echo [!a[!b の場合には履歴展開になる。
      違いは bracket expressions が閉じているか閉じていないかである。
      然し、それを判定する為には先読みをして単語の最後まで見ないといけない。
      それは実装上困難なのでこれは諦める。

      (bash の parser がここでどう動作しているのかは不思議ではある。
      例えば echo [a[!echo""] は無効で [a[!echo"" は有効である。)

    - echo $((echo)>/dev/null)
      よく考えたらこの有名なパターンに対応するのを忘れていた。

    - echo $(case A in A) echo B;; esac)
      実はこのパターン。Bash-4.0 以降では大丈夫だが、
      Bash-3.2 以降では構文エラーになる。ble.sh は bash-4.0 以降の振る舞いしかしない。

    - ${#var[...]修飾}
      この形式は Bash 的には構文エラーになるが、[...] の中身を相当先読みしないと
      修飾があるかないかを見る事ができないので諦めている。

    - set +H; echo ${!!修飾}
      これは Bash では構文エラーだが何故かが分からない。

    - {$v,$w}xxx これは $vxxx $wxxx に展開される。
      つまり、v と xxx がくっついて新しい変数名になる。
      これは分かりにくい動作だが、これを逆に使う人もあるのかもしれない。
      実の所、ブレース展開も文法レベルで実施されるべきなのかもしれない。

    - $((a[\10])) $((a["10"])) ${v:a[\10]} (bash <= 4.3)

      Bash では最初の解析で a[\10] の部分が抜き出されて、その後で a[\10] が処理
      される。最初の解析では [] の入れ子は考慮されない。一方で \10 が有効かどう
      かを判定する為には [] の入れ子を追跡する必要がある (bash-4.3 以下では \10
      は [] の外では使えないが中では使える)。ble.sh の実装ではこの場合には []
      の入れ子は追跡しないことにする。つまり、bash-4.3 以下では $((a[\10])) が
      許される筈なのにエラー着色になる。

      Bash-4.4 以上では上記の文脈では [] の内外で振る舞いが一貫しているので実際
      上の問題は出ない。他にも ((expr)) や ${v:expr} でも同様の入れ子追跡の処理
      の問題があるが、これらの場合には [] 内部と外部の振る舞いは一貫しているの
      で実際上の問題にはならない。

    - ${v:a["10"]} に関しても上と同様の問題がある。これは bash-5.1 以下で問題になる。

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

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

  * 3.0以上 [Note: これは regcomp の問題かもしれない]:
    正規表現 '.^' や $'\n^' は文字列の先頭ではなく行頭に一致する。

    その他の場合 (.*^ など) にはちゃんと文字列の先頭にしか一致しない様だ。

    Ref. #D1869

  * bash-5.2 以上の patsub_replacement に注意する。

    任意の文字列に置換する場合は & が勝手に解釈されない様に "${var/x/"$s"}" の
    様に quote すると良い。但し、bash-4.2 では "${var/x/"$s"}" の " は literal
    に解釈されてしまう事に注意する。一番安全なのは一旦変数に代入するという事。

  * 変数の代入は基本的に quote は必要ないが、

    1 チルダで始まる時はチルダ展開を防ぐ為に quote が必要。
      (変数展開の中にあるチルダは quote しなくても大丈夫)

    2 配列要素を空文字列で連結するときは quote が必要。
      つまり、IFS= eval 'declare var=${arr[*]}' とすると空白区切りになる。
      IFS= eval 'declare var="${arr[*]}"' とする必要がある。
      また IFS が中身のある場合には問題は起こらない。

      - bash-4.3 以降では IFS= eval 'var=${arr[*]}' なら OK

    関係あるか分からないが
    http://lists.gnu.org/archive/html/bug-bash/2017-04/msg00001.html
    において以下のような例が紹介されている。これは bash-4.5 で修正されるらしい。

    | bash-4.2$ unset IFS; set ' '; a=$*; printf '<%s>' "$a"
    | < >
    | bash-4.3$ unset IFS; set ' '; a=$*; printf '<%s>' "$a"
    | <>

  * コマンドをつなぐ && と || の優先順位は同じで左結合である
    但し、算術式や [[ ]] に登場する && と || はC言語と同じ優先順位である。

  * unset の引数は quote しないとパス名展開の対象である。
    特に配列要素を消す場合には [...] を quote する必要がある。

  * unset -v または unset -f と明示的に指定しないと、
    意図せず同名の関数または同名の変数を消去してしまう可能性がある。
    変数を消す場合でも unset -v と明示する必要がある (ref #D0893)。

  * コマンドの単語中のパラメータ展開は "" でクォートする必要がある
    (ref #D0943)

    特に値として以下の物が含まれている可能性がある時は絶対必要である。
    先ず始めに IFS に含まれる文字がある場合は意図しない単語分割を抑制する為に "" で囲む。
    次に、グロブの特殊文字 *?[ が含まれている場合にも注意する。
    shopt -s extglob の時には @( や !( の並びにも注意する必要がある。
    更に、'\' が含まれる場合もグロブ特殊文字のクォートに何故か影響を与える様なので注意する。
    これは例えば shopt -s failglob において、a='\'; echo $a'*' がエラーメッセージを出す事で分かる。

  [complete 仕様について]

  * compgen -f はクォート除去、チルダ展開を実行する
    理解できないのはクォート除去した後にチルダ展開をするという事。
    compgen -f "'~/'" としても '~' というディレクトリには決して一致しない。
    compgen -f "'\~/'" 等とクォートした上に backslash も指定しないと行けない。
    結局どういう規則なのか分からないので、寧ろ arr=('~/'*) 等の様にするべき。

    Note: ~ だとちゃんと現在のディレクトリ以下のファイルに一致するようだ?
    Note: compgen -W でも似たような quote 除去・ブレース展開などを行う様だが、
      それでも理解できる振る舞いになっている。
    Note: bash --norc で echo \~/ から補完を実際に実行してみると echo ~/... に書き換わってしまう。
      何処かで quote が消えてしまっている。これはバグと見做すべきであろう。

  * $ complete -F foo -C bar command と登録すると foo, bar の両方が foo bar の順に実行される。
    $ complete -C bar -F foo command と登録すると bar foo の順に実行される。
    しかし、complete -p とすると両者とも
    complete -C 'bar' -F foo
    と表示され登録順・実行順についての情報を取り出す事ができない。

    →今試すと必ず foo bar の順序でしか呼び出されない。compgen でも同様に見える。

  * $ complete -F hoge1 -F hoge2 command とすると、-F hoge2 だけ有効になる
    (complete -p による表示もそうだし、実際に実行されるのも hoge2 だけであった)。
    -F オプションは後からものによって上書きされるという事の様だ。

  * shopt -q は通常の出力はやめてもエラーメッセージは出す。
    つまり未実装のオプション (compat* や autocd) について
    shopt -q をするとエラーメッセージが出力されるので
    結局 &>/dev/null にリダイレクトしなければならない。

  * locale の環境変数 LC_*/LANG を設定する時は &>/dev/null する必要がある。
    ref #D1205 #D1341 #D1355

    元々入っていた値が不正な値である場合、
    元の値を復元した時にエラーメッセージが意図されず出力される。

    ローカル変数として設定する場合は、
    - 値の復元はどうやら関数の本体を完全に実行し終わった後に起こる様なので、
      関数の本体自体を &>/dev/null で囲んでも意味はない。
    - 関数の中で unset を行っても意味はない。
    - 関数の中でもとの値を設定しても意味はない。
      関数が抜ける時に改めて設定される様だ。

    IFS= LC_ALL=C read -t 0 &>/dev/null
    としても復元時のメッセージは何故か抑制できなかった。

    * #D1341 更に、bash-4.1 以下では LC_ALL= LC_COLLATE=C func 等の形式にしても
      効果が現れない。local LC_ALL= LC_COLLATE=C としないと効かない様である。

      外部コマンドを呼び出す時には問題は起こらない。関数経由でも大丈夫。
      逆に外部コマンドの時には "LC_ALL=C awk" の形式にする必要がある。
      もしくは "local -x LC_ALL= LC_COLLATE=C" とする。

      ng$ aaa() { echo ${#1}; }; LC_CTYPE=C aaa あいうえお
      ok$ echo あいうえお | LC_CTYPE=C awk '{print length($0)}'
      ok$ echo あいうえお | LC_CTYPE=C ble/bin/awk '{print length($0)}'

    * 2021-01-15 aaa() { local LC_ALL= LC_CTYPE=C; ... ; } 2>/dev/null の形式でも
      駄目だという事が判明した。ちゃんとする為には関数内で unlocal までする必要がある?

  * Bash 正規表現はシステムの <regex.h> を使用するので環境依存である。

    Linux においては bash 正規表現の POSIX 文字クラス ([[:alpha:]] など) は
    ロケールによって何にでも一致するので信用できない。
    例えば GNU/Linux (Fedora 25) では ja_JP.UTF-8 で [[:alpha:]] は漢字・仮名にも一致する。

  * bind 関数の中で set +o emacs などをして編集モードを無効にすると、

    編集関数の実行自体が中断されるようである。
    具体的には set +o emacs を含む行だけ実行されて、次の行以降は実行されない。
    set +o emacs が eval に含まれる場合は eval が終わると共に中断される。
    また関数内に set +o emacs がある場合は、その関数は最後まで実行されるようだ。

    従って set +o emacs が実行されたことを検知して適切な後処理を実行するのは難しい。
    更にその後で set -o emacs に戻ってくると変な状態になる。
    bind -p ではちゃんと hook された状態になっているが、
    実際に操作してみると keymap はリセットされているように見受けられる。
    この辺りはもう少し詳しく調べてみないと具体的に何が起こっているかはわからない。

    例: 以下の3行のコマンドを実行しようとすると途中で中断され元の状態には戻らなくなる。

    $ set +o emacs
    > echo hello
    > set -o emacs

    直接 readline で実行している場合にはこの問題は起こらない。

  * ble.sh では変数の -i は積極的には使用しないことにした ref #D0894

    関数引数に使用する場合は、そもそも -i の機能を使う機会の方が少ないので
    全ての関数の引数に適用するのは非効率であり、一部の関数の引数にだけ適用するのは
    関数の仕様として分かりにくくバグの元である。そもそも算術式展開が必要化どうかは
    呼び出し元が知っていることのはずなので呼び出し元で算術式展開をするべきである。

    関数内で使用する場合についても明示的に算術式展開を実行すれば良い。

  * bind 関数中の set +v は揮発性 ref #D0930 (Bash 3.0--5.0)

    bind 関数中で set +v 等としてもその状態は
    次の bind 関数の呼び出しの際には元に戻ってしまう。
    この振る舞いは試した全ての bash version で共通だった。

bashbug: 実装上で注意するべき事・バグ

  * bash-5.0 -- 4.4 (ref #D1334)
    trap handler が実行中に return を無引数で呼び出すと、
    無条件に trap handler 起動直前の $? が関数の終了ステータスになる。
    POSIX に要求されていると書かれているが解釈に難がある。
    特に trap handler を抜ける時の戻り値だけに影響を与えるのが自然に思われる。

  * bash-5.0 -- 3.0 (全 version) バグ (ref #D0943)

    $ shopt -s failglob
    $ a='\'; echo $a'*'

    これで failglob になる。\* に一致するファイルは存在しませんのエラーメッセージ。
    ファイルとして '*', '\*', '\a', 'a' 等があっても決して一致しない。
    これを防ぐ為には、パラメータ展開は必ず "" でクォートする様にすれば良い。

  * bash-5.0 -- 3.0 (全 version) バグ

    history -p をコマンド実行中に呼び出すと呼び出す度に履歴項目が減る。
    これは例えば f1() { history | tail -1; history -p '!!'; history | tail; } として、
    f1 を実行すると分かる。f1;f1;f1 等とすると一回で3件消える。
    更に bash-3.0 では bind -x の関数の中であっても history -p を呼び出す度に履歴項目が減る。

  * bash-4.4 -- 4.3 バグ

    \C-@ 関係に bind -x すると正しく動かない
    bash-4.4 での動作については未だ確認していない。
    → bash-4.4 でもやはり動かない。

    これは修正した http://lists.gnu.org/archive/html/bug-bash/2018-03/msg00165.html

  * bash-4.4 -- 3.2, etc

    rex="^([^\$]|\\'[^\\']*\\')+\$" && [[ 'i$' =~ $rex ]] && echo hello
    が一致する。\' の解釈が謎である。単に ' とすれば問題ない。

    rex=$'^([^$]|\\\'.\\\')+$' でも一致する。
    rex=$'^([^$]|\\\')+$' だと一致しない。
    \' は何らかのアンカーとして解釈されるという事だろうか。
    或いは単純に無視されているのか。

  * bash-4.2

    declare -g -r var とした時に、
    グローバル変数が定義されていなければローカルに新しく変数を作る様だ。
    bash-4.3 で直っている。

  * bash-4.2 以下
    bash-4.2 ～ bash-3.0

    \C-x 単体に bind -x して C-x に続けて何か打つと segfault する。
    $ bind -x '"\C-x":echo' → 続けて C-x a 等と入力

  * bash-4.1 以下: LC_CTYPE=C eval 'echo ${#var}' としても
    ${#var} が元のロケールで計算される。"変数代入 コマンド"
    の形式だとロケールの初期化が間に合わないのだろうか。

  * bash-4.0 segfault

    以下で segfault を起こすことが分かった。bash-4.1 以降では直っている。

    bash-4.0 -c 'function f1 { COMPREPLY=(alpha); }; compgen -F f1 2>/dev/null'

    但し、ble.sh の使用中に実際に compgen -F を通して segfault になることはなかった。
    もしかすると何らかの条件が整うと segfault するかもしれないので、
    念のためここに記録に残しておく。

  * bash-3.2 以下ではプロセス置換に含まれるブレース展開は
    プロセス置換ごと複製してしまう。
    例えば echo <(echo {1..3}) は、
    echo <(echo 1 2 3) ではなくて、
    echo <(echo 1) <(echo 2) <(echo 3) に展開されてしまう。

  * bash-3.2 以下では declare a としただけで空の値で初期化される。
    unset 状態になるという事はないので注意を要する。

  * bash-3.2, bash-3.1 では source にプロセス置換を渡しても読み取ってくれない。
    つまり source <( ... ) としても何も起こらない。
    代わりに eval -- "$( ... )" すると良い。

  * bash-3.2 -- 3.1

    ref #D0857
    10 以上のファイルディスクリプタで使用されている物に対して
    リダイレクションで新しい出力先を設定しようとしても失敗する。
    これは fd>&- として一旦閉じてからリダイレクションすれば良い。

    bash-3.1 では一度開いた fd を改めて開き直したり、
    或いは閉じたりすることができない。
    exec 34>/dev/null とすると、exec 34>&- としても閉じれないし、
    exec 34>a.txt としても /dev/null に繋がったままになってしまう。

  * bash-3.1 では declare -f funcname の funcname に + 等の文字を含める事ができない。
    一応 declare -F 等とすれば名前は列挙される様ではある。
    bash-3.2 未満では declare -f ではなく type -t で関数かどうかの確認を行う。

  * bash-3.1 での bind -r について
    bind -sp とすると "\M-[C" 等と表示されるがそれに従って bind -r '\M-[C'
    としても削除する事は出来ない。代わりに bind -r '\e[C' とすれば削除できる。

    eval -- "$(bind -sp | awk '/M-\[/{sub(/:$/,"",$1);gsub(/\\M-/,"\\e");print "bind -r " $1}')"

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

    Ref #D1270

  * msys1 では named pipe が未対応。従ってプロセス置換も使えない。

bashbug 算術式周りのバグと注意点

  * bash-3.0 - 4.4.7 算術式:

    条件分岐で実行されない部分でも配列の添字は 0 以上でなければならない。
    例えば以下はエラーになる @ bash-3.0, 3.1, 3.2, 4.0, 4.2, 4.3
    ((a=-1,a>=0?b[a]:0))

    もっと調べてみると配列の添字に限らず分岐しない所で式が評価されている様だ:

    + 三項条件式で起こる。true/false branches のどちらでも起こる。&& や || では起こらない。

      $ echo 'x=a=1; ((a=0,0?x:0)); echo $a' | bash      1 (bash-3.0 - 4.3)
      $ echo 'x=a=1; ((a=0,1?0:x)); echo $a' | bash      1 (bash-3.0 - 4.3)
      $ echo 'x=a=1; ((a=0,0&&x)); echo $a' | bash       0 (bash-3.0 - 4.3)
      $ echo 'x=a=1; ((a=0,1||x)); echo $a' | bash       0 (bash-3.0 - 4.3)

      $ echo 'x=a=1; ((a=0,0?b[x]:0)); echo $a' | bash   1
      $ echo 'x=a=1; ((a=0,0&&b[x])); echo $a' | bash    0 (bash-3.0, 3.1, 4.2+ / bash-3.2, 4.0, 4.1 は別の bug で 1)

    + 括弧で囲めば何も起こらない様だ。

      $ echo 'x=a=1; ((a=0,0?(x):0)); echo $a' | bash    0 (bash-3.0 - 4.3)
      $ echo 'x=a=1; ((a=0,1?0:(x))); echo $a' | bash    0 (bash-3.0 - 4.3)

      $ echo 'x=a=1; ((a=0,0?(b[x]):0)); echo $a' | bash 0 (bash-3.0, 3.1, 4.2+ / bash-3.2, 4.0, 4.1 は別の bug で 1)

  * bash-4.2 算術式 seg fault

    https://lists.gnu.org/archive/html/bug-bash-gnu/2013-01/msg00036.html
    https://lists.gnu.org/archive/html/bug-bash-gnu/2013-01/msg00042.html
    https://lists.gnu.org/archive/html/bug-bash-gnu/2013-01/msg00043.html

    算術式の中で配列要素の参照に関係して特定の式構造になると segfault する。
    多分、配列要素の読み出しの次の token が整数または代入式の左辺だと落ちる。
    配列要素を参照したら一旦算術式を閉じるのが良い。
    $ ((a=b[0],c=0))

    以下でも segmentation fault が起こった。
    $ (((klen=node[nofs+k])<0||(kbeg=j-klen)>end0))
    $ (((a=node[1])<2||(b=3)))
    $ (((a=node[1])||(b=3)))
    $ (((a=node[1])<2||b)) # OK
    $ (((a=node[1])||b))   # OK
    $ (((node[1])||(b=3))) # OK
    やはり起こる条件が良く分からない。
    代入式の右辺に配列が来て、
    その後に代入式の左辺に token があると駄目なのか?

  * bash-4.1, 4.0, 3.2: 算術式分岐内配列参照

    bash-3.2.48 で以下の評価に失敗する。
    bash-3.1 以下は大丈夫。bash-4.2, bash-4.3 も大丈夫。bash-4.0 は駄目。

    dbg=()
    ((a=0,b=0,0&&(a=1,x=dbg[0],b=1))) # NG
    配列添字で値を参照 (代入はOK) すると、その部分以降が必ず実行される。
    複合代入であっても駄目である。

    bash-4.0 bash-4.1 でも以下の式で必ず _pos[1]++ が実行されていた。
    ((_eoc[2]&&(_pos[0]=0,_pos[1]++)))


    $ ((a=0,b=0,0&&(a=1,x=dbg[0],b=1))); echo $a $b               → 0 1
    $ expr="a=1,x=dbg[0],b=1"; ((a=0,b=0,0&&expr)); echo $a $b    → 0 1
    $ expr="a=1,x=dbg[0],b=1"; ((a=0,b=0,0&&(expr))); echo $a $b  → 0 1

    更に配列添字も必ず評価されてしまう。
    ((i>=0&&a[i])) は i が負であっても参照される。
    そして、((i>=0&&a[i--])) をすると更に副作用も起こる。

  * bash-4.1 以下 (bash-3.0 ～ bash-4.1)

    配列要素に対して修飾付きのパラメータ展開を実行すると、
    配列添字に指定した算術式が2回評価される。
    例えば "${arr[i++]#a}" を実行すると i が 2 増える。

  * bash-4.0 他 算術式を使って値を計算する時の注意

    算術式の中に初期化されていない変数…例えば ret 等がある場合、
    ret の中身に不正な数式的な物が入っていたりコマンド置換が入っていたりすると、
    文法エラーになったりこれが eval されてしまう。
    実際に 4.0 では 'あ' という文字列が入っているだけでエラーになる。
    (より上の version では識別子名と解釈されているからなのかエラーにはならない。
    しかし、今迄は毎回「あ」等という変数を探していたのだろう。

  * bash-3.1, 3.0

    ?: 演算子の中身は全てカッコで囲まないと構文エラーになる。例えば、
    $ bash-3.1 -c '((a?(b=123):c?(d=321):1))'
    bash-3.1: ((: a?(b=123):c?(d=321):1: syntax error in expression (error token is "?(d=321):1")

bash 配列の宣言に関する注意点

  * arr=(1 2 3) func の形式で配列をシェル関数に渡そうとすると、
    export arr='(1 2 3)' で渡されてしまう。

  * 既に配列変数になっている物に対して
    export var=value や typeset -x var=value をしても、
    呼び出された別コマンドからは環境変数として見えない。

    $ a=(1 2 3)
    $ (export a=1; bash -c 'declare -p a')
    bash: 0 行: declare: a: 見つかりません

    新しい変数として導入すれば良い。
    例えば関数内で新しく local -x var=value とするか、
    var=value command の形式で呼び出すようにすれば良い。

    $ (a=1 bash -c 'declare -p a')
    declare -x a="1"

その他のバグ

  * BUG gawk-4.0.2 正規表現 [][:space:]] や [^][:space:]] に対して警告メッセー
    ジを出力する。実際には正しく解釈して正しく動作する様である。また、他の gawk
    version では問題はない。

    これは scan チェックに含める事にする。

bash_features

  * time -- について。
    bash-5.1 以降で time -- command が可能。
    bash-4.2 以降で time -p -- command が可能。
    (bash-4.1 以前では time には -- を指定できない)

  * bash-5.0 以降: EPOCHREALTIME, EPOCHSECONDS
    ref #D0925

  * Bash-5.0 では POSIX に倣ってパラメータ展開結果に \ が含まれる場合に
    グロブパターンと見做す様に変更されたが、
    これにより問題が起こり POSIX が記述に誤りがあることを認めて修正した。
    結局 Bash-5.1 で 4.4 と同じ動作に戻すつもりらしい。
    https://lists.gnu.org/archive/html/bug-bash/2020-03/msg00051.html

  * ${param@a} (attributes) 及び他の transformation は bash-4.4 より

  * read -t timeout

    * -t オプションの対応は 2.04 である。
    * TMOUT 変数の対応は 2.05b-alpha1 以降である。
    * 小数を指定できる様になったのは 4.0-alpha 以降である。
    * `-t 0' で次の文字を読み取り可能かどうかチェックできるのは 4.0 以降である。
    * 4.3 以下では timeout した時に読み取った入力は失われてしまう。
      4.4 以降では timeout するまでに読み取った内容が指定した変数に格納される。

  * グローバル変数に対する属性指定 declare -g は bash-4.2 から

    更に bash-4.3 には declare -gA を二度行うとクラッシュするバグがあったらしい。
    現在の最新版ではそのような振る舞いは見られない?

    2021-02-10 #D1470 どうも bash-4.2 の declare -g にはバグがある。declare -gA
    とすると属性は global まで適用されるが、代入された値は関数を抜けると共に消
    滅する。2021-05-20 追記。declare -gA a=() とすると関数を抜けると共に値が消
    滅するが、declare -gA a; a=() とすると特に問題は生じない。

  * 連想配列 declare -A は bash-4.0 から

  * BASHPID 何と Bash 4.0 以降の機能らしい ref #D1200

    ------------------------------------------------------------------------------
    This document details the changes between this version, bash-4.0-alpha,
    and the previous version, bash-3.2-release.

    c.  There is a new variable, $BASHPID, which always returns the process id of
        the current shell.
    ------------------------------------------------------------------------------

    と思ったら既にソースコードの一部にも Bash 4.0 以降であるとの注記があった。

  * command |& command は Bash 4.0 以降なので使えない。

  * printf -v var %s value

    bash-3.1 以降で使える。
    bash-4.1 以降で var として配列要素 (arr[123] 等) を指定できる。

  * printf %(...)T は bash-4.2 以降から。但し、bash-4.2 では -1 を明示的に指定
    しないと現在時刻になってくれずに 0 になってしまう。bash-4.3 以降では省略し
    た場合は現在時刻になる。

  * ${!arr[@]} は bash-3.0 より

bash_tips

  * swap の仕方
    local a=$b b=$a
    local や declare などは必要である。

  * [[ ]] の中で =~ で設定された BASH_REMATCH は直後の式で参照できる。
    つまり [[ $text =~ $rex && $BASH_REMATCH == ... ]] の様にできる。

    bash-3.0 から bash-4.4 までで以下のコマンドで確かめた。

    [[ "" =~ ^ ]]; [[ $BASH_REMATCH ]]; [[ a =~ a && $BASH_REMATCH ]]

  * 構文関係でマニュアルに載っていないものが色々ある。

    * }, fi, done, esac の直後に }, fi, done, esac, do, else, elif, then が来る場合はセミコロンは省略できる。

    * for ((expr1; expr2; expr3)) [ ; ] { list; } は比較的有名だが、
      for name [in name]; { list; }
      select name [in name]; { list; } も使える様だ。

    * select name [ [ in word ... ] ; ] do ...; done
      ※in word ... がない場合、do の前のセミコロンは省略可能である。

  * "$(case *) ;; esac)" に対応する可能性があるかと思ったが動きはない
    ref http://lists.gnu.org/archive/html/bug-bash/2017-11/msg00002.html, #D0928

  * function @() { ...; } は成功するが実際には関数は作られない
    ref http://lists.gnu.org/archive/html/bug-bash/2017-03/msg00220.html, #D0927

  * declare -c var という隠し属性がある。Capitalize する。Bash 4.0+
    変数の値の各単語について適用するのではなく本当に最初の文字にしか適用されない。
    この中途半端な機能の為に恐らくマニュアルに載っていないのだろう。

    ソースコードを確認すると他にも declare -G var という謎機能が存在する。
    同じ文脈に局所変数があればそれに設定してそれ以外ならば大局変数に設定する。
    これは丁度他の言語のレキシカルスコープを真似た物という事だろうか。

  * nameref & extra expansion
    気付いたのだが declare -n ref='arr[...]' の ... に任意の式を記述できる。
    これによって新しい乱数変数も定義できるのでは。例えば。

    declare -n var='var_[var_=RANDOM*RANDOM,0]'

    但し、算術式なので整数以外は代入できない。
    更に、$() でプログラムを実行することすらできる。
    然し、任意の文字列という訳には行かないのが問題。
    $() はサブシェルで実行されるので副作用を残す事ができない。

  * let & brace expansion
    これは算術式のページに既に書いた。

  * rcfile を処理している間は

    * 関数内で FUNCNAME, BASH_SOURCE, BASH_LINENO を確認するとFUNCNAME
      の最後の要素は "source" であり、BASH_LINENO の最後の要素は 0 に
      なっている。BASH_SOURCE の最後の要素がファイル名である。

    * bash-4.4 以降では $- に s (標準入力から読み取り中) が含まれない
      事で確かめられる。bashrc を抜けてPROMPT_COMMAND を実行する時には
      s が含まれる様になる。bash-4.4 未満では s は決して含まれない事に
      注意する。

    まとめると以下の様な関数で rcfile 中で走っているかどうかを判定できるのではないか。

    function ble/util/is-running-in-rcfile {
      [[ $- == *i* && ( _ble_bash -lt 40400 || $- != *s* ) ]] || return 1
      local nstack=${#BASH_LINENO}
      [[ ${BASH_LINENO[nstack-1]} == 0 && ${FUNCNAME[nstack-1]} == source ]]
    }


*******************************************************************************
    Memo
-------------------------------------------------------------------------------

2023-01-31

  * review: direnv [#M0023]

    direnv は .envrc を bash で評価して、環境変数の変更を調べて、それを各シェル
    の変数に反映させるらしい。これにより使うシェルに依存せず一つの .envrc で同
    時に対応できる。然し一方でこれが意味する所は、環境変数だけしか親シェルに反
    映させる事ができないのだろうという事。ローカルな関数やエイリアスは引き継が
    れない (或いはエイリアスであれば可能であろう)? また環境変数に制限する事によっ
    てディレクトリに入る前の環境変数のセットをそのまま保存する事によって
    push/pop を自前で実装しなくて済む様になっている。

    .envrc は direnv allow しないと有効にならない。このallow/unallowedの情報は
    どこに記録しているのだろうか。うーん。別の箇所にディレクトリを作成している
    様にも見える。うーん。

    https://github.com/bbugyi200/funky これは各ディレクトリの中にデータベースファ
    イルを作って local functions を保存する事によって動く。グローバルに使える関
    数も定義できる (が .bashrc で定義するのと比べて何が違うのか謎)。

    https://github.com/cxreg/smartcd これは機能的になかなか参考になる気がする。
    README の see also のまとめが参考になる。
    https://github.com/cxreg/smartcd#see-also

    https://github.com/Tarrasch/zsh-autoenv ... smartcd SEE ALSO による
    と、~/.autoenv_authorized に実行して良い env ファイルが記録されているそうだ。

    https://github.com/hyperupcall/autoenv ... これは bash にも対応している。記
    録ファイル ~/.autoenv_authorized は zsh-autoenv と同じ様である。

    https://github.com/jamesob/desk ... これも似たような事を実装しているが、恐
    らく予め設定した内容だけでなく現在のディレクトリやコマンド履歴などの動的な
    情報も「セッション」として記録している気がする。然しここまで来ると screen
    で良いのではないかという気がしてくる。

2021-12-31

  * "function f {}" vs "f() {}" [#M0022]

    function f は元々は ksh functions で、POSIX functions f() とは局所変数の取
    り扱いが異なる。ksh では f() の形式の関数では局所変数を定義できない。ksh
    functions ではその関数で宣言したローカル変数またはグローバル変数しか見えな
    い。この背景から function f() という両方を組み合わせた形で書くと鬼の首を撮っ
    たかの様に指摘してくる人がいる (Greg Wooledge だったか)。

    f() の形式の場合には f の部分は alias 展開の対象である。例えば alias
    die=std::die 等として名前空間を import している時に、関数を上書きしたい時に
    それが alias されているという事を意識せずに直接 die() { ... } 等として上書
    きする事ができる。

    function ... の場合には、f() の形式では定義できない、特別な文字を含んだ関数
    も定義する事ができる。POSIXLY_CORRECT の時には結局どちらの形式を使ったとし
    ても、識別子以外の名前で関数を定義する事はできないのであるが。

    Bash 5.0 以前では function hello の直後にはサブシェル () を本体とした定義は
    置けない。文法的にはこれが当たり前の様な気もするが、Bash 5.1 以降では直後に
    サブシェルを置ける様である。例えば function f(echo) など。

2021-05-16

  * Linux パッケージのチェック (by killermoehre) [#M0021]
    どの Linux にどのパッケージのどの version が入っているかを調べられるサイト
    https://pkgs.org/search/?q=groff

2021-05-15

  * PKGBUILD の説明は此処にある [#M0020]
    https://wiki.archlinux.org/title/VCS_package_guidelines
    https://wiki.archlinux.jp/index.php/PKGBUILD
    https://wiki.archlinux.jp/index.php/%E3%83%91%E3%83%83%E3%82%B1%E3%83%BC%E3%82%B8%E3%81%AE%E4%BD%9C%E6%88%90#.E9.96.A2.E6.95.B0_pkgver.28.29

    PKGBUILD と一緒に.SRCINFO も更新すること。

    $ makepkg --printsrcinfo > .SRCINFO

    pkgrel は新しい pkgver に変わったら一緒に 1 に変更する。

    blesh-git の最新の pkgver は以下の様にして取得する

    $ (cd ~/.mwg/src; source ble.sh/ext/aur.blesh-git/PKGBUILD; pkgver)

    PKGBUILD のチェックは以下で行う

    $ namcap PKGBUILD

2021-05-03

  * awk の互換性に関する注意点 [#M0019]

    * 正規表現 {m,n} は gawk-4 以降でしか既定で使えない。gawk-3 も nawk も mawk
      も駄目。

      POSIXに反しているが過去の互換性の為という事らしく gawk-3 では
      POSIXLY_CORRECT またはオプション --posix または --re-interval を指定すれ
      ば利用できる様になるが、nawk/mawk はそういうオプションすらない。

    * 正規表現 A?A? は mawk では最初の A? しか一致しない。

      これは明らかにバグの気がするがどうなのだろうか。

    * 16進リテラル 0xHHHH は gawk でしか使えない。

2021-05-01

  * ble.sh 初期化時の Bash 設定に対する対策 [#M0018]

    ble.sh が set -euxv -o posix や FUNCNEST=0 等特殊な状況で呼び出される事がある。
    この様な環境ではまともに動作する事ができないので設定を適切な順序で解除してい
    く必要がある。

    set -eu に関しては適切な記述方法を取れば回避する事ができるので後回しにする。
    set -xv に関しても標準エラー出力を適当な物に繋いで置けば回避できる。set -o
    posix が設定されていると関数を定義できない。その他の振る舞いにも注意が必要だ
    ろう。alias も何が定義されているか分からないので出来るだけ expand_aliases を
    off にする方向で考えたい。

    現在の実装では以下の順にチェック・対策を行っている。

    1 最初の引数解析 (POSIX shell 準拠): この部分は別のシェルで起動した場合などで
      も引数解析の結果などを表示する為に対策よりも前に処理する。alias で { や if
      が書き換えられている事によって失敗しても、シェルが全く操作できなくなるとい
      う事はないだろうし、ユーザー側の責任とする。

    2 Bash のバージョンチェック。これをしないとそもそも対策コード自体動くか怪しく
      なってくるので先にチェックする必要がある。これもシェルが全く操作できなくな
      るという事はないだろうという事で、ユーザー側の責任とする。

    3 expand_aliases
    4 FUNCNEST
    5 set +o posix

      この三つを設定すれば取り敢えず安全に関数を定義して実行できる。

    6 reset-builtins

      builtin が上書きされてしまうのを防ぐ為。

    7 adjust-options (set +euxv; shopt -u nocaseglob; shopt -u expand_aliases)

2020-05-11

  * Bash の HISTTIMEFORMAT 振る舞いのまとめ [#M0017]

    ref #D1351

    * Bash は、HISTTIMEFORMAT の値に関係なく、コマンドの時刻を常に内部
      的に管理している (#0x10 の件を考えると文字列で記録している疑いが
      ある)。HISTTIMEFORMAT が設定されている時、history コマンドで出力
      されるコマンド履歴に時刻が出力される。

    * 変数 HISTTIMEFORMAT が存在する時 (空文字列や unset も含む)、Bash
      は履歴ファイルに #%s の形式で時刻を保存する。

    * 履歴ファイルからコマンドを読み取る時、直前に #%s があればそれを
      コマンドの時刻とする。それ以外の時はコマンドの時刻は bash の起動
      時刻とする。これは HISTTIMEFORMAT の状態に関係ない。

      履歴ファイルから読み取る時には単一行モードと複数行モードがある様
      だ。変数 HISTTIMEFORAMAT が存在 (空文字列や unset も含む) してか
      つファイルの先頭行が #%s の時に複数行モードになる。

      時刻行は "#数字" で始まっているかどうかで判定する。先頭または #
      と数字の間に余分な空白が含まれている場合は時刻行ではない。"#整数
      " の後に別の文字列があったとしてもそれは無視される。但し、"#0"
      で始まっている時だけは行全体を時刻と見做すようで、余分な文字列が
      あると history で出力する際にエラーになる。

    * history コマンドの出力は HISTTIMEFORMAT が非空文字列の時にタイム
      スタンプが出力される。

      HISTTIMEFORMAT が設定されていても空文字列の時には処理は行われな
      い。これは通常の見た目の振る舞いでは区別がつかない (処理していて
      も処理していなくても出力に違いは出ない) が、履歴ファイルに #0xxx
      の様な無効なタイムスタンプが含まれていた時の振る舞いで分かる。

    * shopt -s lithist は、for 等の文法的に複数行に跨るコマンドについ
      て、そのままの形でコマンド履歴に登録する。単にコマンドラインで複
      数行を入力して実行しても改行で分割してコマンド履歴に登録される。

      これはコマンドを実行した時に Bash プロセスの内部のコマンド履歴に
      登録する際に影響を与える物であって、履歴ファイルへの書出しや履歴
      ファイルからの読み出しには影響を与えない様である。

    現在の ble.sh サポートの制限について。

    * mlfix: bash-4.4 以降では複数行コマンドを history -r で読み出せるが、
      bash-4.3 以前では複数行コマンドは history -s で構築せざるを得ない。
      従って複数行コマンドに関しては正しくコマンド時刻を復元できない。

2020-05-06

  * trap: DEBUG/RETURN trap のまとめ [#M0016]

    DEBUG trap は設置した関数内で有効。set -o functrace (set -T) が設
    置されている時または呼び出される関数に declare -tf を設定している
    時にのみ呼び出される関数に継承される。trap -p の出力は現在処理して
    いる関数毎に異なる (継承しない場合は DEBUG/RETURN trap に対しては
    何も出力されない)。

    DEBUG: bash-4.3 以下では設置した関数の呼び出し元には影響はないが、
    bash-4.4 以降では呼び出し元の DEBUG trap も上書きする。DEBUG trap
    を削除した場合には、呼び出し元には影響は与えない。DEBUG trap の中
    では DEBUG trap は発火しない。

    RETURN:

    * BASH_COMMAND には最後に関数内で実行したコマンドが入っている。
      return を使った場合にはそれが、関数の末端で終わった場合には最後
      のコマンドが入っている。
    * RETURN trap は関数内部で実行されるので、return を呼び出して終了
      ステータスを変更する事ができる。但し、条件をつけないと、RETURN
      trap の return に対して再び RETURN trap が発火して無限ループにな
      るので注意する。
    * RETURN trap の中では RETURN trap は発火しない。それ以外の trap
      では発火する。

    BASH_LINENO, BASH_SOURCE, FUNCNAME についてはまだ詳しく調べていない。

2020-04-14

  * ${###} 等のパラメータ展開・変数展開について [#M0015]

    Bash のパラメータ展開 #D1330

    <param>

    - 位置パラメータ: 1 2 ...
    - 特殊パラメータ: * @ # ? - $ ! 0 _
    - 変数名: /_[[:alpha:]][[:alnum:]]*/ の形式
    - 配列名[添字]
      添字はシェル展開の対象で配列の時は算術式の対象
    - 配列名[@], 配列名[*]

    <modifier>

    - @A 変数の定義
    - @a 変数の属性
    - @Q @E @P 値を加工する
      これらの ops は展開の対象ではない。つまりvar=A として ${xxx@$var} とはできない。
    - #, ##, %, %%
    - /, //, /#, /% (クォートとの兼ね合い)
    - ^ ^^ , ,, ~ ~~
      Note: ~ については https://qiita.com/t_nakayama0714/items/80b4c94de43643f4be51 に書いてあった。
    - = + - ? := :+ :- :?
    - :offset, :offset:length

    * $<param>
      Note: 配列, 2桁以上の位置パラメータは使えない。

    * ${...} の例外規則

      * ${#<param>}
        ${#@}, ${#*}, ${#a[@]}, ${#a[*]} は要素の数。
        それ以外については文字の数。

      * ${!var@} ${!var*}

      * ${!arr[@]} ${!var[*]}

    * ${<param><modifier>}
    * ${!<param><modifier>}

      * ! で始まる物については ${<param>} を変数名とする。

        Note: <param> は !, $ 以外でなければならない様だ。

        $@ $* ${arr[@]} ${arr[*]} の時には "$*" などを変数名と見做す。
        つまり、普通に ${!arr[*]##} 等とすると要素が1個の時以外はエラーになる。
        (arr=(a b c); IFS=; abc=4321; echo "${!arr[*]##}") 等とすると動く。
        (arr=(a b c); IFS=; abc=4321; echo "${!arr[@]##}") は動かない。

    ★${!#} で最後の引数を取れる。${@:$#} でも行ける。
      但し、引数がない場合は $0 に展開される事に注意する。

2020-04-07

  * bashrc に於ける history の操作について [#M0014]
    初回の history -nrs の実行時に "未初期化" であれば初期化を行う。
    "未初期化" の判定は履歴がその時に空であるかどうかによる。

    * "未初期化" の時に history -awcd を呼び出した時は何も実行しない。
    * "未初期化" の時に history -nrs を呼び出した時は、
      履歴ファイル (HISTFILE) を読み取って初期化した後に要求された操作を実行する。
      これは bash の動作とは異なる。bash は履歴ファイルを読まずに操作を実行する。
      その後で何らかの条件で履歴ファイルの読み取りを最初のプロンプト表示の前に行う。
    * history -p に関しては "未初期化" かどうかに関係なく、そのまま実行する。

    bashrc の中で history -r を実行すると履歴の倍加が発生する。
    但し、実行時だけで記録される履歴ファイルは倍加しない。

2019-06-10

  * history -na の動作に就いて [#M0013]

    * どのコマンド以降を新しいものとして取り扱うのか。という事について。
      特に他の Bash が bash_history に書き込んだ新しいコマンドを読み取った時、
      次に自分が history -a する時にどの範囲のコマンドを追加するのだろうかという事など。

      まとめると Bash の動作は恐らく以下の様になっている。
      先ず Bash は2つの変数を使っている。ここでは read_index と write_index と呼ぶ事にする。
      read_index は history -n で HISTFILE から次に読み出すべきコマンドの行番号を保持する。
      write_index は history -a で次に HISTFILE に書き込むべき history 内のコマンドの番号を保持する。
      Bash の起動時には read_index も write_index も同じ値に初期化される。
      history -n を実行すると read_index は HISTFILE の行数に再設定される。
      write_index は読み取った行数だけ増加する。
      history -a を実行すると write_index は history の項目数に再設定される。
      read_index は書き込んだ行数だけ増加する。

      この動作に従うと history -n; history -a や
      history -a; history -n を実行すると問題が生じる事になる。
      書き込み済みのデータ・読み取り済みのデータが混ざった時に正しく範囲を表現できない。
      この事が理由で巷にある同期の設定では history -a; history -cr を実行しているのである。

    * HISTCONTROL=erasedups
      試してみたが erasedups が設定されていたとしても history -n で新しく読み取った
      コマンドと同じ名前のコマンドを削除するとかそういう事は別にしない様である。

2019-02-13

  * keymap: 以下のキーについては既定では同じ動作になる様に設定する事にする [#M0012]
    ref #D0929, #D0752

    - DEL C-? / BS C-h
    - NUL C-@ C-SP
    - RET C-m
    - TAB C-i
    - C-_ C-DEL C-BS

2019-01-01

  * vi: inclusive/exclusive motion の実装に関して [#M0011]

    exclusive な motion は exclusive-goto.impl を呼び出す。
    inclusive な motion は inclusive-goto.impl を呼び出す。
    何れの場合も範囲を修正の後に exclustive-range.impl に委譲する。

2018-08-31

  * decode: 端末の送信するキーシーケンスについて [#M0010]

    * back (BackSpace)
      xterm は back に対して BS (C-h) を送る。
      C-back に対して DEL (C-?) を送る。
      一方で、mintty, RLogin では back に対して DEL (C-?) を送る。
      C-back に対して C-_ を送る。

    * modifyOtherKeys(2)

2018-08-05

  * compgen に指定した単語のクォート除去に関して [#M0009]

    参考: #D0714

    生成するコマンドの種類と、バージョンによってクォート除去されたりされなかったりする。
    以下に、クォート除去されることを期待してクォートしても問題がないかをまとめる。

      compgen -A command   クォート不可
      compgen -A directory クォート不可 (Bash-4.3 以降でクォート除去されない※1)
      compgen -A file      クォート不可 (Bash-4.0, 4.1 でクォート除去されない※2)
      compgen -A function  クォート可
      compgen -A variable  クォート可
      compgen -A arrayvar  クォート可

    ※1 バグと思われる。ble をロードしていると何故かクォート除去されている。
      然し、--norc や ble ロードなしで実行するとクォート除去されない。
      クォート除去が実行されなくなってしまう条件が分からないのでこれは使わない。

    ※2 バグと思われる。

2017-10-31

  * ble 関数の典型的な終了ステータスについて [#M0008]

    127 適切な widget が見つからなかった:
      (由来: Bash でコマンドが見つからなかった時の値)

    126 処理をキャンセルするとき:

      install-hook した trap に関して、blehook internal_NAME 経由で trap の発火
      をキャンセルする時に返す値。

      廃止: widget を呼び出すことができなかった (未使用)

    125 widget を呼び出したが適切な処理が見つからなかった:

      __defchar__ に登録した widget がこれを返したとき
      次のハンドラを用いる。具体的には __default__ の呼び出しを試みる。

    147 ユーザの入力を非同期に待つ為に一時停止した:

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

    148 ble/util/idle や isearch や complete に於いて、ユーザ入力を処理する為に
      一旦現在の処理を中断する時に返す値。vi-mode のオペレータが 148 を返したと
      き後処理を実行せずにそのまま抜ける (由来: 128+SIGTSTP)

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

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

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

    2 コマンドの使い方が異なる

    3 ble/util/bgproc は named pipes がシステムでサポートされていない時に 3 を返す。

2017-10-18

  * ble-decode: widget に関して [#M0007]

    __defchar__ および __default__ に登録された widget が 125 を返した時、
    その入力に対する適切な処理が見つからなかったことを表します。
    この時、次のハンドラの探索が行われます。
    次のハンドラがない場合には対応するものが見つからなかったというエラーになります。

2017-09-24

  * vi-mode 以下は現在のところ対応しない予定である [#M0006]

    * 2017-09-24 vi-mode: % で用いる matchpairs には現在対応しない

    * 2017-09-17 vi-mode (insert mode/newline):
      インデントを挿入するが何もしなかった時にそれを削除することには対応していない。

      これは実際の所、挿入モードにおける移動と抜ける時の処理において、
      細工を行えば対応できる。現在の挿入モードの操作の繰り返しの記録の仕組みも使えるが、
      もっと別の仕組みを用意しても良い気がする。

    * 2017-09-12 vi-mode: タブ文字上にカーソルがある時のカーソルの表示位置

      後、気付いたことはタブ文字に居る時のカーソル位置は、
      ノーマルモードにいるときはタブ文字の最後の位置である。
      要するに p で挿入される位置を示しているとも言える。
      でも全角文字の場合にはちゃんと全角文字の先頭にカーソルが来る。
      この動作は分かりにくいし更に言うと現状の ble.sh の描画コードでは対応していない。
      これには取り敢えず対応しないことにする。

    以下は積極的に対応する予定はない。
    将来的に対応する場合の注意点がある場合も含む。

    * 2017-10-11 M ( ) [[ ]] { } :s :tag
      これらのコマンドは "ジャンプ" なので、$flag なしで実際にジャンプに成功する場合には
      set-local-mark 96 をする必要がある。

    * done: 2017-10-09 取り敢えず今の所はスクロール (C-b C-d C-e C-u C-y など) には対応しない
      →これは #D0886 で対応した。

2017-09-08

  * vi-mode: 以下のリンクで重要そうなコマンドの一覧が見られる [#M0005]

    http://qiita.com/sfuta/items/0de4ead865c15e9e9b68 ?
    http://qiita.com/sfuta/items/2d646396a6117c8e53e5 g? z?
    http://qiita.com/sfuta/items/fd78f3ece8861f8142ee C-w? [? ]?
    http://vim-jp.org/vimdoc-ja/vimindex.html
    http://vim-jp.org/vimdoc-en/vimindex.html

2015-11-28

  * デモ画像の作り方 [#M0004]

    * ble-0.2 のデモ画像はキャプチャソフトを使った (ref #D0926)

      - Cygwin の mintty を用いた。
        画面の幅は56列にし文字の大きさは14程度が良い。
      - キャプチャソフトには LICEcap というソフトウェアを使った。
      - キー入力を表示するソフトには KeyCastOW を改造した物を用いた
        https://github.com/akinomyoga/KeyCastOW

      ble-0.1 の時に行った基本的な操作に加えて、
      ble をダウンロード・展開して試してみるところも含めた。

    * ble-0.1 のデモ画像は ttyrec & seq2gif を用いて作成した

      準備
      $ # PS1=$'[\e[4;38;5;202mfoo@bar\e[m \\j \\W]\\$ '
      $ TTYREC=1
      $ ttyrec demo.tty

      echo hello, world
      printf hello
      [[ a == b ]]
      echo "hello $(echo bash $(echo world))"
      C-r for
      echo 'select, copy and paste' コピーする
      echo insert mode -> overwrite mode
      ls
      echo complete ble-TABdTAB histexpand !#:2
      echo "$HIST[TAB]"

      $ seq2gif -f 0 -b 15 -h 14 --render-interval=10 -p rosa --play-speed=1.5 < demo.tty > demo2.gif

      gif のフォーマット的には 0.01s よりも小さな遅延は設定できない。
      また、現実のブラウザでは 0.02s (50fps) よりも小さな遅延にすると強制的に 0.10 になってしまう。
      更に、Safari や Internet Explorer では 0.06 (16.67fps) よりも小さな遅延は 0.10 になってしまう。
      更に、Windows に附属している viewer では 0.10 よりも小さな遅延は全部 0.10 になってしまう。

      [[Frame Delay Times for Animated GIFs by humpy77 on DeviantArt>http://humpy77.deviantart.com/journal/Frame-Delay-Times-for-Animated-GIFs-214150546]]
      [[How to match animation rate of gif files accross browsers (Fenrir Developer's Blog)>http://blog.fenrir-inc.com/us/2012/02/theyre-different-how-to-match-the-animation-rate-of-gif-files-accross-browsers.html]]
      [[Nullsleep | Jeremiah Johnson - Animated GIF Minimum Frame Delay Browser Compatibility Study>http://nullsleep.tumblr.com/post/16524517190/animated-gif-minimum-frame-delay-browser]]


2015-08-14

  * [memo] builtin check [#M0003]

    eval "grc --color --exclude=./test '\b(builtin[[:space:]]+)?$command\b' | grep -Ev '\bbuiltin[[:space:]]+$command\b'"

  * [memo] leak variables check [#M0002]

    ble/debug/leakvar#list を実行する。

    ble/debug/leakvar#reset var
    ...
    ble/debug/leakvar#check var tag1
    ...
    ble/debug/leakvar#check var tag2

  * [memo] 解析(ble-syntax/parse)の際の原則 [#M0001]

    データ配列とは _ble_syntax_stat, _ble_syntax_nest, _ble_syntax_tree を指すとする。
    或る点 p1 から或る点 p2 に解析を進める場合を考える。

    1 この時データ配列に対する変更は p1-p2 (exclusive) の間にだけ行われる。
      これは解析状態の復元と再開が適切に動作する為に必要である。

    2 解析の過程でデータ配列に格納されている情報は使用しない。
      これは解析状態の一致チェックの為に必要である。
      データ配列の内容に依存して動作が代わる場合、
      解析状態が一致しても解析結果が異なってしまう可能性があり、不整合を生む。

      但し、_ble_syntax_nest については専用の関数を通して 0-p2 の任意の場所を参照しうる。
      これ(専用の関数を通して得られる情報)については
      解析状態の一致チェックの対象に含まれているからである。
      (_ble_syntax_nest の任意の情報を参照して良いという意味ではない。)

    tree-append および nest-pop に対する制限

      tree-append は _ble_syntax_tree[i-1] に格納を行う。
      従って上記の条件1から p1<=i-1 つまり p1+1 <= i である必要がある。
      これは少なくとも 1 文字 i を進めてからでないと tree-append を呼び出せないという事である。
      nest-pop も内部的にそのまま tree-append を呼び出しているので同じ制限がある。


*******************************************************************************
    bug-bash, third-party bugs & reviews
-------------------------------------------------------------------------------

2024-04-22

  * 以下で内部エラーになる

    $ bash-2.05b -c 'f() { exit; }; a=1 eval "f | :"'
    $ bash-dev -c 'f() { exit; }; a=1 eval "f | :"'

    これは以前に発見している tempenv のエラーと同根だろう。builtin eval を使っ
    た時には発生しない。

2023-02-20

  * review: completion 自動生成

    argument-parser と一緒に completion を自動生成する試みがある。

    - spf13/cobra や rsteube/carapace 等の仕組み。

    - https://github.com/adoyle-h/bash-completor

    - ble.sh でも最初期に getopts interface を実装して、これだけで引数パーサー
      と同時にそれと consistent なコマンド依存単語着色を実装しようと試みた。結
      局、これは argument parsing 速度が遅いという事で放棄されて
      archive/getopt1.sh に眠っているが、直接実行するのではなくて、事前に関数を
      生成して置くという方式にすればそれは気にしなくても良いのかもしれない (但
      しその分だけ footprint が大きくなる)。実のところ ble-face だとか ble-bind
      の様に初期化時に大量に呼び出される物でなければ、別に其処まで速度を気にす
      る必要はない気もする。

    - 最近もシェルで getopts と同時にヘルプ等も自動的に生成しようという試みがあ
      る。これである。

      https://github.com/ko1nksm/getoptions

    - 他にも類似の物が定期的に github 上に現れる気がするが忘れた。

    ble.sh 的には以下の物を同時に全てしてくれるととても良い。

    - 引数解析器
    - 引数補完候補生成
    - 単語着色
    - 引数指定方法のエラーの検知、診断情報の取得、修正候補の生成

    一般的な枠組みとしては更に以下の様な物もあると便利なのだろう

    - ヘルプ自動生成
    - 引数に関する単体テストの自動生成 (特殊ファイル名、巨大数、etc.) →でも正
      しく動作しているかどうかの判定は別で書かなければならないのでは?


2023-02-14

  * bug-bash: bash-5.2 で -u extquote しても ${var//[$'\n']} が改行を削除する。

2023-02-06

  * bug-bash: 実は colored-stats は本来 LS_COLORS を反映するらしい。然し、
    readline 初期化前に設定されている必要がある。colored-stats も bind 等ではな
    くて inputrc 経由で有効にしなければならない様だ。

2023-01-31

  * review: bash libraries

    https://blog.fascode.net/2022/05/05/fasbashlib/
    https://github.com/Hayao0819/FasBashLib ... これはライブラリ構成としてある
    べき形を一通り備えている様に思える。具体的な関数としてどれだけ非自明なもの
    が用意されているのかは余り確認していない。Common.sh を見ると悪しき set -Eeu
    -o pipefail を前提としている。GNU toolchain を要求している。fork を減らすな
    どの効率化については余り意識されていない気がする。結構 trivial なものまで関
    数として定義されている。うーん。ForEach だとか Array.Length だとか、既に
    bash に機能的に存在している物まで関数で wrap したり pipe 化したりと、syntax
    sugar 的な関数が多く、実践志向ではない。或いは minimalism 的潔さはない。ラ
    イブラリ構成としてメタ的な機能(naming convention 変換, etc)を揃えているので
    良さそうと思ったが、それも namespace の模倣のために整えられた枠組みの副産物
    と見るのが良い気がする。

    FasCode project の一部? で、これは何かと検索すると Alter Linux という日本産
    Linux distribution を有志で作っている集まりだろうか? Arch based. Issues を
    見ると日本語メインのコミュニティーで 373 stars. 他に Serene Linux というの
    も作っていて Ubuntu-based -> Fedora-based に変更したと書いている。作ってい
    るのは学生の集団らしい。

2023-01-26

  * review: コマンド履歴データベースの設計

    fish はファイル名に一致する引数を覚えている。これにより autosuggestions で
    は、コマンドライン中のファイル名が現在していない時にはそのコマンドはスキッ
    プするという具合の振る舞いをする。

    https://github.com/ellie/atuin ... 暗号化・ホスト間共有・C-r拡張・各種統計

    https://github.com/jcsalterego/historian ... 単に .bash_history を検索するだけ

    https://github.com/ddworken/hishtory ... custom column として git_remote が
    紹介されている。git remote 単体が便利かどうかは分からない。sqlite3 だと
    column を dynamical に追加するのは難しそう。一方で git の commit id を一緒
    に記録するというのは一つの可能性である。

    https://github.com/larkery/zsh-histdb ... 実は同じ名前で zsh にもその様な
    plugin が存在している様である。中を除いてみたら実装はかなり近い形になってい
    る。履歴を表示するコマンドも用意しているが、余り細かい操作を実行できる訳で
    もない様だ。

2022-06-26

  * またもや tempenv=... builtin eval ':;echo $tempenv' のバグに引っ掛かった。
    これはやはり直して貰いたい。

2022-02-15

  * tmpenv builtin eval vs DEBUG trap
    Ref #D1772

    function print { echo "v=${v:-(not found)}"; }
    function trapdebug { echo "$FUNCNAME:1:v=($v)"; }
    builtin trap 'trapdebug' DEBUG
    v=xxxx eval print
    v=xxxx builtin eval print

    以上に於いて builtin eval print で実行される print に対する DEBUG trap の中
    から v=xxxx が見えない。eval print の時にはちゃんと見えているので意図的な振
    る舞いとも思われない。

2022-01-23

  * wezterm, bash-preexec に対する patch を終結させる。

    * bash-preexec に API 安定化のお願いをする → これは PR を出したが返事がない。
      時々活動はあるみたいなので少しでも反応があった時に改めてお願いする事にする。

  * bash-preexec は既存の DEBUG trap を正しく実行できていない様に思われる

    $ trap 'echo XXX' DEBUG
    $ echo 1; echo 2; echo 3
    XXX
    1
    XXX
    2
    XXX
    3
    $ source bash-preexec.sh
    XXX
    XXX
    XXX
    $ echo 1; echo 2; echo 3
    XXX
    1
    2
    3

    これは意図的な物なのだろうか。。と思ったら以下に議論がある。

    https://github.com/rcaloras/bash-preexec/issues/52
    https://github.com/rcaloras/bash-preexec/pull/54
    https://github.com/rcaloras/bash-preexec/pull/109

    o ユーザーが trap DEBUG etc を実行しても破壊されない。
    o DEBUG trap の overhead がない。
    o 他の枠組みが DEBUG trap を設定・削除しても問題が起こらない。

2021-12-11

  * bash-completion

    2022-02-02

    * [DraftPR で修正済み] _services が failglob で問題を起こしている。

      _comp_init_set_up_service_completions も駄目。うーん。failglob ではある
      がこれは自分が修正している途中の物ではない新しい物だろうか? →これは既に
      fix-failglob　の中に含まれていた。

    * [修正済み] rsync で *-from が云々という failglob が発生している
      →これは最新版では既に修正されている。

      結局ロードして欲しい bash-completion が全然ロードされない。何故 → 結局ロー
      カルの場所ではなくて其処で make install されている物が読み出されている様だ
      が、make install しても何故かずっと古いままという状態になっている様だった。
      autoreconf -i をし直して実行したらちゃんと新しい物に置き換えられた。make 自
      体がちゃんと動いていなかったという事になるのだろうか。何れにしてもこれでちゃ
      んと動く様になった。

    2022-01-23

    683 にも unresolved patch suggestion がある。
    https://github.com/scop/bash-completion/pull/687#discussion_r790203991 : IFS=$'\0' in mount
    https://github.com/scop/bash-completion/pull/687#discussion_r790203132 : mechanism of save/restore shopt

    2022-01-11

    * bash-completion: curl　の抽出オプションが極端に少ないのは何故か→これは
      curl --help は最低限のオプションしか表示しないから。そして --help all を
      呼び出せば全部表示される。確認すると --help all は指定されているが、quote
      されていない。

      類似の問題が過去にあったがその時に一緒に直されなかったのかと思ったが、こ
      れが正にその時の問題であって、test などが用意されていなかった為に未だマー
      ジされていないのだった。

      https://github.com/scop/bash-completion/pull/560

    2021-12-22

    * fixed: man の中で _expand を呼び出しているが意味ないのでは? info も同様。

    * man の _expand の直後にある eval は危ない気がする。
      →これは別項目で議論する。

      info にも同様の問題が存在する。

    * grc '&& [^[:space:]]+ \|\|'
      →何故 SC2015 で検出されないのだろうか? 変数代入の場合には許されるのだろうか。

    * command ls $... となっている部分が幾つかある。 -- を付加するべき。
      他にも色々とあるのではないかと思われる。

    2021-12-11

    * curl --http0, --http1, --proxy1 等存在しないオプションが生成されている
    * printf -v varname
    * test, [ の引数の文法に従った補完

2021-12-08

  * space

    https://space.sh/
    https://github.com/space-sh/space (7k LoC)
    https://github.com/space-sh/space/blob/master/completion/init_autocompletion.sh

  * bashible というフレームワークでは関数名は ble_ で始まる様だ。

  * bash-dev: "help test" の -n の引数に STRING が二回登場している。

    →と思ったが、これは分かった。 [[ -n STRING ]] と [[ STRING ]] の二種類の指定の仕方を
    両方載せているというだけの話である。

2021-09-22

  * bash-it で気になる事

    * bash-it disable alias を実行すると何も表示されず何も実行されない。
    * bash-it --help もしくは bash-it で色々表示されるが、明らかに表示されてい
      ないコマンドが存在している。
    * bash-it update に外部から登録できる機能?
    * bash-it に自動でインストールする機能もつける可能性について

  * bash-5.2

    $ i=0; b=$(< "file${a[i++]}"); echo "$i"
    1

    $ f=; b=$(< "${f:=file}"); echo "$f"
    file

    $ i=0; b=$(< "file$((i=123))"); echo "$i"
    123

    $ RANDOM=0; echo "$RANDOM"
    20814
    $ RANDOM=0; b=$(< "$RANDOM"); echo "$RANDOM"
    24386

    うーん。これに関しては zsh も ksh も副作用を残す形に実装している様だ。つま
    り、$(< ...) は特別な構文として同じシェルで評価するものとしているという事。

2021-09-07

  * segv: bash-dev -c "declare -A A; unset 'A[\${v[0]}]'"

2021-09-01

  * review: bash-raytracer
    https://github.com/aneeshdurg/bash-raytracer

    固定小数点で実装している。Issue 1 で遅いから inline 化して微妙に改善したと
    いう話をしているが、その改善したコードは push されていない。

2021-08-30

  * review: bash-timestamping-sqlite
    https://github.com/csdvrx/bash-timestamping-sqlite

    - typo: synthax -> syntax

    - 行末に改行が抜けている事を示すマーカーを表示している。然しこれは CPR を使っ
      ている気がする。実装を見ると __notbottom という関数で判定していてこの関数
      では CPR を使っている。

    何れにしてもこれは他の人が組み込んで使える様な plugin ではなくて、一つの完
    結した設定になっている。コードも綺麗ではない。現段階では単に個人用の設定に
    説明がついているものと見るべきの気がする。これに対して色々と他の人が使える
    様に改善の提案をするのは違う気がする。

2021-08-19

  * st: st 2>&- で開始しようとすると何も表示されない。st 2>&- 0>&- で開始しよう
    とした場合にはちゃんと動く。これは以下の様に修正するべき。後で送る。

    $ NOBLE=1 ./st.master 0>&- 1>&- 2>&-
    $ ./st.master 0>&- 1>&- 2>&-

    | diff --git a/st.c b/st.c
    | index ebdf360..a9338e1 100644
    | --- a/st.c
    | +++ b/st.c
    | @@ -793,14 +793,15 @@ ttynew(const char *line, char *cmd, const char *out, char **args)
    |                 break;
    |         case 0:
    |                 close(iofd);
    | +               close(m);
    |                 setsid(); /* create a new process group */
    |                 dup2(s, 0);
    |                 dup2(s, 1);
    |                 dup2(s, 2);
    |                 if (ioctl(s, TIOCSCTTY, NULL) < 0)
    |                         die("ioctl TIOCSCTTY failed: %s\n", strerror(errno));
    | -               close(s);
    | -               close(m);
    | +               if (s > 2)
    | +                       close(s);
    |  #ifdef __OpenBSD__
    |                 if (pledge("stdio getpw proc exec", NULL) == -1)
    |                         die("pledge\n");

    メールを投稿してみたが全然以下のページに反映されない。
    ブロックされているのだろうか。或いは初回は手動承認が必要になるという事か。
    maintainer は数日に一回しか返信しない様なので取り敢えず一週間待ってみようと思う。

    https://lists.suckless.org/hackers/2108/index.html

2021-07-20

  * bashbug: ${text//$'\n'+( )/$'\n'} が滅茶苦茶遅い
    https://www.reddit.com/r/bash/comments/m4ts7j/why_is_this_spacereplacing_parameter_expansion/

    この記事では bash はそういう用途に使う物ではないだの何だのと言って別の手法
    を使えと書いているが、明らかにこれは bash のバグである。修正するべきだし修
    正は難しくない筈である。後で観察する事にする。

2021-06-09

  * complete: contra x screen-4.99 で auto-menu を有効にしていると、

    $ cd .mwg/src/ble.sh/wiki
    $ l backup/[TAB][C-u]

    とした以降にコマンド1文字目を入力した時点で glitch が生じる。
    contra がどういうデータを受信しているのか確認する必要がある。

    通常の screen では問題は生じない様だ。また contra の代わりに mintty を使っ
    ても問題は生じない。変な文字幅モードが関係している可能性もある。

2021-05-30

  * https://github.com/dnmfarrell/jp
    https://www.reddit.com/r/bash/comments/nmzans/jp_a_real_json_processor_in_bash

    何か変な事をしている。プロセス置換で読みだした fd に対して読み書きを実行している。
    一体どういう事だろうか…。

    $ exec 3< <(:)
    $ echo hello >&3 # これはエラーになる
    $ echo hello >/dev/fd/3 # これは行ける
    $ read -u 3
    $ echo $REPLY # 読める
    $ yes | head -1000000 > /dev/fd/3 # これはやはりブロックする C-c で中止
    $ mapfile -t arr < /dev/fd/3
    $ echo ${#arr[@]} # 32768要素 ("y" + LF)x32768 = 64kB つまりパイプバッファのサイズ

2021-05-27

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

2021-05-23

  * bash: いつの間にかに日本語の文字幅の計算がおかしくなっている

    [現象]

    | ble/util/c2w 及び ble/util/c2w-edit の計算は正しい。新しい bash セッショ
    | ンを開始した時には何も問題は発生しない。つまり、reload を通して壊れるとい
    | う事だろうか。然しそうだとしても不思議な壊れ方である。
    |
    | 何かが変わってしまっているという事なのだろうと思うが新しい bash セッション
    | で発生しない様なので取り敢えずこれの解決は後回しにする事にする。
    |
    | うーん。textmap が可笑しくなっている気がする。
    |
    | と思ったら ble/util/s2c で日に対して 230 が返って来ている。何故だろうか。
    | 実装を確認すると単に printf %d "'日" を実行しているだけである。実際に
    | builtin printf の出力結果がおかしくなっている事を確認した。うーん。不思議
    | な事である。

    builtin printf %d "'あ" が正しい値を返さなくなっている。一文字目の文字コー
    ドを返している。実装を見ると mbtowc を呼び出している。失敗したら一文字目の
    コードを返す実装になっている。これにより ble/util/s2c が誤った文字コードを
    返し、そして文字幅計算が間違って textmap に間違いが入る。というのが表示が乱
    れる原因であった。

    [再現条件?]

    a 新しい bash で ble-reload をしても特に問題は発生しない。

    b 一度でも LANG を C 辺りに変更すると問題が発生する様になる可能性? 特に再現
      はしない。LANG を元に戻せば元通りになる。また、問題の発生しているセッショ
      ンで LANG=C して LANG=ja_JP.UTF-8 にして見ても問題は治らない。

    ? 或いは設定が異なるのか。bind -v の結果を比較しても shopt の結果
      を比較しても $SHELLOPTS:$BASHOPTS の結果を比較しても同じである。dotglob,
      nullglob の設定の違いはあったがこれを解除しても振る舞いは変わらなかった。

    ? 或いは LANG 辺りを unset した痕跡があるだろうか。コマンド履歴を探したが
      unset でも LC でも LANG でも怪しい物は見つからない。実際に unset するなど
      しても特に問題は発生しない。

    ? よく分からないので bash を見に行くと builtins/printf.def で mbtowc を呼び
      出して文字を一文字抽出している。この mbtowc の文字コードの設定ができなく
      なっているのが問題なのだろう。うーん。やはり setlocale の問題の気がする。

    ? うーん。不思議である ble-detach しても状況は変わらない。然し何故か
      readline の文字幅判定等はちゃんと正しく動作している様である。printf
      \u3042 等もちゃんと動いている。

    ? うーん。実際にこのセッションで実行したコマンドの一覧を作って観察して見た
      が特に問題がある様には思われない。特に locale を破壊する様な事が起こると
      は思えない。怪しい物に setsid があるがこれで全てのシェルが駄目になるとい
      う事があるのだろうか。うーん。特に問題は発生しない。

    もう全然分からないので exec bash してみる事にする→exec bash したら治った。
    結局どういう事だったのか分からず終いである。結局不明である。C標準ライブラリ
    か Linux のバグなのだろうか。

2021-05-21

  * bash: fix a problem that "set -e; builtin eval false || true" exits the shell
    false || true # OK
    eval false || true # OK
    builtin false || true # OK
    builtine eval false || true # 駄目

2021-05-08

  * bash: Cygwin でも mapfile/read で unbuffered read に変更できないだろうか。

2021-05-06

  * bash: complete -p の -F はやはり quote するべきなのではないか。
    $var となっている場合、!! となっている場合、{1..10} となっている場合。

  * bug-bash localvar_inherit: dynamic variables の性質も継承されるのは意図的か。
    Ref #D1532

    例:

      shopt -s localvar_inherit
      local BASH_COMMAND='xxxx'
      local LINENO='xxxx'
      local RANDOM='xxxx'

    * PS1 を評価する為に BASH_COMMAND を一時的に別の物に置き換えたい。
      localvar_inherit を一時的に off にしたり或いは tempvar を通して
      BASH_COMMAND を変更する等すれば一応 BASH_COMMAND を置き換える事は可能だが
      非自明である。

    * localvar_inherit は local variable という形で初期化を行わなかった時の振る
      舞いを制御する物と思っていたが、実際には上記の様にした場合に影響が出てく
      る。つまり、localvar_inherit の下で上を実行すると set/get がコピーされた
      上で代入が行われる様で、動的変数としての性質が継承される。振る舞いが変わっ
      てしまって困る。特に代入した値が消滅してしまう。

    * また、マニュアルを見ても attr 及び value が継承されるとは書かれているが
      dynamic variable としての性質が継承されるとまでは書かれていない (?)。

      > info bash より (man bash は本質的に同じ)
      >
      >   localvar_inherit
      >
      >         If set, local variables inherit the value and attributes of a
      >         variable of the same name that exists at a previous scope before
      >         any new value is assigned.  The 'nameref' attribute is not
      >         inherited.
      >
      >   declare
      >
      >         The '-I' option causes local variables to inherit the attributes
      >         (except the 'nameref' attribute) and value of any existing variable
      >         with the same NAME at a surrounding scope.  If there is no existing
      >         variable, the local variable is initially unset.
      >
      > declare --help より
      >
      >   -I    if creating a local variable, inherit the attributes and value of a
      >         variable with the same name at a previous scope

    * 他の実装はどうだろうかと思って zsh で RANDOM, LINENO を試してみたが、
      RANDOM に関しては local にしても何も振る舞いの変化は見られず、LINENO に関
      してはそもそも代入不可能だった。そもそも zsh は local var; とすると前のス
      コープの値は保持される単に unset になる。

    * 実際にこの継承を行っているのは variables.c:2738 の以下の部分である

      variables.c L2738
      > if (localvar_inherit || (flags & MKLOC_INHERIT))
      >   {
      >     /* It doesn't make sense to inherit the nameref attribute */
      >     new_var->attributes = old_var->attributes & ~att_nameref;
      >     new_var->dynamic_value = old_var->dynamic_value;
      >     new_var->assign_func = old_var->assign_func;
      >   }

    2021-06-09 SECONDS も影響を受けるだろうか。

    より現実的な例として以下の様な場合を考える事ができる。

    evaluate_prompt() {
      local BASH_COMMAND=$(HISTTIMEFORMAT=x history 1 | sed '1s/^[[:space:]0-9]*x//')
      result=${PS1@P}
    }

    Note: 実は上記の BASH_COMMAND 抽出方法は正確ではない。複数コマンドがある場
    合、本来 BASH_COMMAND は一番最後のコマンドだけを含む。また、HISTCONTROL 等
    によって履歴にコマンドが登録されなかった場合にも結果がずれる事になる。例示
    するならば具体的に結果を無理に模倣しようとせずに、何か適当に内容を書く事に
    するのが良い気がする。例えば、

    evaluate_prompt() {
      local BASH_COMMAND='echo "Hello, world!"'
      result=${PS1@P}
    }

2021-05-04

  * empty associative array subscripts: これは結局返事がないが ToDo リストに入っ
    ているのかもしれない。或いはそうでもないのかもしれない。何れにしても、今少
    しずつ associative array subscripts の取り扱いの変更が行われているので、そ
    れらが済んでから処理されるのではないか。

  * return without arguments in trap handlers. これは結局強い理由がないと変更さ
    れない雰囲気になっている。

2020-12-19

  * bug-bash: jobs in trap handlers

    以下を実行して端末を resize すると (true) の偽ジョブ情報が出力される

      trap '(true); jobs' WINCH

    SIGWINCH に限らない。以下を実行して C-c を押しても同様の問題が発生する。

      trap '(true); jobs' INT

    実は直後の bind -x の中で jobs を実行しても同様。
    一度でもユーザーコマンドを実行すれば偽情報は消える。

      trap '(true)' INT
      bind -x '"\C-t": jobs'

    2022-07-11 以下でも同様の問題が発生した。これは PROMPT_COMMAND 実
    行中に発生する事である。
    https://github.com/petobens/trueline/pull/46#issuecomment-1179853850

2020-04-25

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

    追記 2022-02-17 これは ble.sh でも類似の物を実装した。

  * pipexec という物があるそうだ。と思ったが調べたら C で書かれている。
    https://github.com/flonatel/pipexec

  * zsh のテーマである powerlevel10k は実は結構複雑な処理を実装している。
    ごちゃごちゃとした雑多の設定の寄せ集めではない。
    ble.sh 程ではないが単にプロンプトと呼べるレベルを超えている。
    * https://github.com/romkatv/powerlevel10k
    * https://github.com/Powerlevel9k/powerlevel9k
      p9k と initial commit が同じなので再実装というよりは fork の気がする。

  * https://github.com/aristocratos/bashtop
    これは最近現れた物で pure bash で色々な UI を実装している。
    オプション引数はなく設定は直接編集する様になっている。
    背景が明るい時の配色に対応していない。256色要求。

    * 実用性よりも見た目重視。これはツールの性格による。
      ble.sh 自体は他のプログラムを呼び出す為の物なので主張は控え目。
      然し、宣伝の為には見た目を派手にした物も必要なのかもしれない。
    * 何故か現れたばかりなのに 6.3k も集まっているし、
      一体何が起こるとこのように話題になるのだろうか。不思議である。
      HN にも reddit にも大して人気になった物は見られない。
      何処から広まってどう人気になったのか不明である。
    * freebsd, aur, debian, fedora/centos にまでパッケージが在る。


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

* bump 時にする事
  - version up in README
  - Copyright year
  - Acknowledgments
  - todo 項目の整理
  - leakvars
  - version up in GNUmakefile
  - note.txt に含まれるログの移動 -> done.txt
  - keymap の移動 (これは別 commit にする?)
  - make_command.sh の整理 (scan 分離, char_width 分離)
  - note.txt -> memo.txt

2025-07-02

  * [保留] 3.2: 複数行の履歴項目がある時に履歴初期化前に C-r で検索すると history の出力が dump される?
    Ref #D2365

    テストの途中で発生していたが再現できなくなったので取り敢えず保留にする。

  * bug: 複数行コマンドがあると初回プロンプトで履歴展開が起こらない X20250702

    コマンドを未だ実行していない状態で履歴展開を実行しようとしても何も発生しな
    い (5.3)。もしくは変な項目に展開される (3.2)。これは最新の bash でも発生し
    ている。

    うーん。これは 5.3 bug の気がする。4.0..5.2 ではちゃんと動いている。それと
    は別に 3.2 では別のコマンドがロードされてしまう問題が発生していた。うーん。
    改めて実行してみたら 3.2 でもちゃんと動いている。不思議だ。

    更に分かった事は、'!trap[SP]' は動かないが '!echo[SP]' は動くということ。更
    に履歴ファイルを別の物にすると動く様になる。不思議だ…。分かった。trap の直
    前のコマンドが複数行コマンドだと発生する。然し、bash 5.2 では発生しない。

    resolve-multiline を実行しないようにすると問題は発生しなくなる。つまり
    resolve-multiline の過程で何かが起こっている。

    うーん。再現しようとすると 4.0..5.3 で再現する様なコードはできるが、5.2 で
    は動いて 5.3 では動かないという構成は plain bash では難しい? stty が何か関
    係しているのだろうか。もしこれが 5.3 で導入されたバグではないのだとしたら直
    してもらうのは難しいのではないか?

    * workaround として何が考えられるか? stty でも実行すると問題が解決するのだ
      ろうか? それとも? そもそも何故コマンドを実行すると問題が発生しなくなる?

      試しに stty を実行してみたが特に効果は無いようだ。不思議だ。

    * 5.2 と 5.3 の両方で再現するコードにて、何故か history -r で読み取った時に
      最初の項目が空になってしまっている。これは何故?

2025-06-23

  * termux: export A=/[TAB] や echo /[TAB] の補完に於いて / 以下のファイルでは
    なくて、現在ディレクトリの下の */* を補完候補として生成している。これは他の
    環境では発生していない。

  * history: "history -a; history -n" in PROMPT_COMMAND causes a wrong record
    https://github.com/akinomyoga/ble.sh/issues/595#issuecomment-3002209639

    history -a; history -n が PROMPT_COMMAND に入っていると最初の読み取りの時に
    壊れた history entry ができあがる。これは回避する必要がある。

    ble.sh を使わずに bash で起動すると別に変な事は起こらない。各行一つずつ履歴
    項目になる。特に何かをした後にそれが崩れるとう訳でもない様だ。普通に
    builtin history -r としても特に問題は生じない。うーん? と思ったが、よく考え
    たら複数行コマンドを読み取る時には ble.sh も history -r は使っていないのだっ
    た。複数行コマンドだけは history -s を通じて読み取っていた筈である。という
    事を考えると、builtin history -r や bash の初期化では常に各行一項目として読
    み取ると考えて良い気がする。

    問題は resolve-multiline にある様な気がする。と思ったが history-multiline
    を呼び出さない様にしても問題は発生する。そもそも履歴が倍加しているという事
    に注意しなければならない。うーん。誰が履歴を倍加しているのか?
    history/initialize で最初に history が load された時点既に倍加している気が
    する。と思ったが ble/history:bash/initialize が何故か複数回呼び出されている。
    何故? もっと深い ble/history:bash/load でどうなっているか確認したが、これの
    最初の呼び出しの時点で倍加は起こっている。また、この load は idle から呼び
    出されていて、更に idle はキー入力に対して発生している。

    PROMPT_COMMAND で history -a; history -n が設定されている時、ble-attach の
    中で最初の履歴のロードが実施され、更に、その後で .bashrc が終わった後で次の
    履歴のロードが実施されている様な気がする。そして .bashrc が終わった後に
    bash がロードしている履歴は何故か行ごとに読み取られるのではなくて全部くっつ
    いた状態で読み取られてしまう。

    うーん。倍加する問題は実は知っていた問題の様な気がするが、履歴項目が全部くっ
    ついてしまう問題については知らなかった。先ず、履歴項目が全部くっついてしま
    う問題をどうにかできないだろうか。普通に eval "$PROMPT_COMMAND" を .bashrc
    の中で実行するだけだと純粋に倍加するだけで履歴項目がくっついてしまう問題は
    発生しない。

    とにかく .bashrc の最後では大丈夫で、最初の bind -x 呼び出しで履歴項目が壊
    れている。何故履歴が全部くっついてしまうのだろうか。

  * history_share=1 でも初回コマンド実行時に固まるらしい。
    https://github.com/akinomyoga/ble.sh/issues/595#issuecomment-3010266326

  * github: exit status 3 の謎
    https://github.com/akinomyoga/ble.sh/discussions/597#discussioncomment-13561325

    kitty で試すしかない

    * mingw (msys2) でシンボリックリンクを作成できないのでインストールできない。

    * msys1 において PATH の自動修正ができていない。

2025-06-16

  * complete: for a^J[TAB] の補完が効いていない気がする。"d" と入力すると "do "
    になってくれる。一方で "{" と入力しても認識していないようだ。

2025-06-04

  * bash-5.3: 再度チェック

    * read -E: 対応するべき。言語は bash という事にする?
    * source -p PATH: 普通に source する時は -- を指定するべき。もしくは . を使う。
    * bind -pP の後の引数は解釈しない
    * compopt -o fullquote

    * https://lists.gnu.org/archive/html/bug-bash/2025-06/msg00000.html
      これは M-{ の振る舞いに変更が必要になるのでは? と思ったがその後の変更でま
      た振る舞いが元に戻った?

2025-05-08

  * bind 経由で設定したコマンドは復元時の bind に追加するべきではないか? どうせ
    復元時の keybinding はセッションごとに記録している。

  * と思ったが… bind.save が空の session が存在している。これは何だろう? 複数
    あるので偶然という訳でもない気がする。何らかの拍子に空になるということ。実
    際に bind -p を実行してみると何も binding が存在しない状態になっている。

    恐らく ble-detach をすると操作できない状態になる気がする。

    * bind.save が空の場合にそれを検出して既定の binding に置き換える。

    例えば ble-update を実行した時に問題が発生する可能性? と思ったが chat 上で
    ble-update を実行することはないのでそれは変だ。ble-reload を実行したらなる
    という訳でもないだろう。

    うーん。空の bind.save を持つ bash プロセスを調べてみると 1月04日に開始して
    いるが、bind.save 自体は 5月13日になっている。つまり、ble-reload もしくは
    source .bashrc をした時に殻になったという事ではないかという気がする。

2025-05-03

  * complete: ble/cmdinfo/complete:cd はやはり消す? 或いは別の bind の仕方を考える。

    * 関数定義形式の問題点はスペースやシェルの特別文字が含まれるコマンドに対し
      て補完を定義できない事である。代わりに dict に登録する形式にするか、或い
      は、ble complete を使って定義する形式にする? ble complete はもし登録され
      ていればそれを使い、そうでなければ Bash complete に登録された補完設定を用
      いるようにする。

      と思ったがそれだとユーザーが complete を使って設定をしても、ble complete
      の設定がされている限りはそれが無視されるという事態は変わらない。これはま
      た独立な項目である。

    * ble/cmdinfo/complete:cmd が定義されているとユーザーが complete を通して設
      定した補完設定が反映されない。

      a 一つの方法は ble.sh native の補完設定も complete 経由で登録する様にする
        という事。

        x これの問題点は COMP_* 等の変数の構築など non-trivial な処理を無駄に実
          行する必要があるという事。

          o 然し、逆に、既存の他のコマンドの補完設定を呼び出したいという事になっ
            たら、それらの変数が存在している事は利点でもある。とは言え、ble.sh
            の側で「既存の他のコマンドの補完設定を呼び出すコマンド」を提供すれ
            ば良いだけの気もするので余り利点でもないような気がする。

      b 或いは、complete を ble.sh の関数で上書きしてしまうという方法。この方法
        ならユーザーが complete で新しく設定をした時に既存の ble complete の設
        定を削除すれば良い事になる。

      一方で、安易に上書きできる様にしていると ble complete の側で折角「より良
      い補完設定」を用意したとしてもそれが使われないという事態になってしまう可
      能性もある。その辺りの折り合いはどの様につければ良いだろうか。結局、ユー
      ザーが二者択一を迫られる事になる。ble complete を使うか、或いはそれを全て
      上書きして bash-completion の設定を使うか。カバーしている範囲を考えると
      bash-completion 一択である。そして、bash-completion に伍するレベルで様々
      のコマンドに対応するのは困難だし、更に external completion based on
      bash-completion が沢山あるという事を考えると bash-completion をロードしな
      いという事はありえない。となると、もし bash-completion で提供されている一
      部の補完設定をより良いもので上書きしたい、となった時には結局 ble complete
      が存在すれば Bash の complete の設定よりも優先するという事にしなければな
      らなくなるのではないか? 色々考えると最終的には bash-completion 自体に手を
      入れてそれを改善するという方向性になる気がする。

2025-04-10

  * complete: auto-complete を個別に off にする方法の記述
    https://github.com/akinomyoga/ble.sh/issues/572

    やはり set -x 等で出力する仕組みを作る

    * cobra に関しては問答無用でコマンドを conditional-sync 経由の呼び出しに置
      き換えても良いのではないか? と思ったがそんなに時間がかかると分かっていな
      い物にまでそのような処理をするのも憚られる。やはり問題のある補完をリスト
      にして適用する方が良いだろうか…

      kubectl はリストに追加しておく。

    * wiki: auto-complete で各補完を無効にする方法について。 _comp_load を先に
      使える様にするということを明記するべき。また古い bash-completion の為に
      _completion_loader だか __load_completion を使った方法についても記述する。

      或いはそれ専用の設定関数を用意すれば良い。と思ったが bash-completion の読
      み込みまでは制御できない気がする。また後で考える事にする。

2025-04-03

  * edit: zle の様々の関数
    https://github.com/atuinsh/atuin/pull/1469

    zle の次の様な widget は便利なのではないか。

    - infer-next-history
    - accept-and-infer-next-history
    - 加えて直前の同じ内容の履歴項目に移動する機能があっても良いのでは

    zle には他にも様々な便利そうな widget が実装されている。それらを実装するの
    も良いのではないか。

  * complete: auto-menu もしくは menu-filter で絞り込み表示がされていて、tab を
    押した時に共通部分がなくて何も起こらないとき、代わりに menu に入っても良い
    のではないか?

  * 以下の D22XX がそのままになっている

    ./src/edit.sh:6766:  # Note (#D22XX): In bash < 4.0, "_ble_builtin_trap_processing" may be set by

  * iTerm2-Color-Schemes, Gogh の更新も bump 時の todo に入れるべきか?

  * function ble/complete/source:argument の中の *f* をチェックしているのは実
    際にここに来ることはあるのだろうか。この部分は c1b053253 で追加された。一
    方で、最近 6a426954

  * d56c7d2f 関数にした方が良いのではないか?

2025-02-20

  * complete: _comp_load / __load_completion に hook する? (reported by quantumfrost)
    https://github.com/akinomyoga/ble.sh/issues/561

    github#561 では cykerway/complete_alias を使用した時に cobra based の補完が
    説明を挿入してそれがそのまま候補に表示されるという事が発生している。

    cykerway/complete_alias が内部的に _command_offset を呼んでいる。それによっ
    て ble.sh による advice を免れている。

    ? no: でも、本当は _comp_load で読み込んだら一旦 124 で戻して改めて補完を実
      行するのでは?

      と思ったが、よく考えてみれば _comp_load で見つかろうが、既にロード済みで
      complete -p から読み取った場合であろうが、現在のコマンドラインに対して補
      完をするのではなく特定の部分に対して補完を試みるのが本来の目的なのだから、
      124 で呼び出し元に返すという様な実装になっている筈がない。

    やはり _command_offset は内部的に自前で補完関数を呼び出していた筈。更に言う
    と、既に定義されているが未だ advice を適用していない補完設定に対して
    は、_comp_load に対して介入しても引っかからない。

    _comp_command_offset の実装を確認してみたがフラットに書かれている所為で介入
    する場所がない。この関数を分解するにしても結構微妙である。うーん。寧ろ
    _comp_command_offset の実装をまるっきり置き換えてしまうべきだろうか。そちら
    の方が実は良い?

2025-01-16

  * README: ble-attach は startup files の最後でなければならないという話。

2024-12-24

  * vscode における初期化問題
    https://github.com/akinomyoga/ble.sh/discussions/524

    [ble-attach の問題]

    ble-attach を呼び出すと venv が初期化されない。どうも変だと思ったら vscode
    は .bashrc を shellIntegration-bash.sh 云々から読み込まれている様だ。単に
    PS1 が反映されていないという事だった様である。これの対策についてはまた考え
    なければならないだろうか。或いは、ユーザーに ble-attach ではなくそのまま書
    く方式を試す様にお願いするか。wiki に記述しても良い。

    或いは、既に VS Code の何かの Extension に対する対策を含めているのだから、
    VS Code Python Extension に対する workaround も ble.sh の中に含めるべき? し
    かしそうするとしてもどの様に処理したら良いか分からない。

    a ble-attach を無効化するにしても、ble-attach をわざわざ記述した理由がある
      のかもしれない。

    b 或いは、ble-attach の時点で VSCODE_* の環境変数が存在して未処理の場合には
      それを ble.sh の側で自前で処理して、その後で ble-attach する? 然し、そう
      するにしても shellIntegration-bash.sh が変更されたらそれで動かなくなって
      しまう。upstream を追跡するのは大変だし、追跡したとしてもどの version の
      shellIntegration-bash.sh を使っているのかまで検出しなければならない。

    c 或いは、呼び出し元が shellIntegration-bash.sh だと分かった時点で、それを
      自前で呼び出してそれから ble-attach を実施する?

    [source .venv/bin/activate の問題]

    一方で、これは結局報告者の問題とは関係ない様だ。報告者のビデオによると
    source .venv/bin/activate が書き込まれてその後に C-c が送信されて、それから
    実行スべきコマンドが書き込まれて実行されている様だ。然し、source ... C-c は
    自分の環境では実行されている気配が全くない。そもそも .venv/bin/activate は
    全く読み込まれていない様に見える。

2024-12-23

  * vi_nmap: pu をした時のカーソル位置が vim と一致しない
    Ref #D2304

    vim では、例えば "insert" がクリップボードにある状態で @echo で p を押すと
    einser@tcho になる。其処で u を押して元に戻すと e@cho になりそうな物なのに
    @echo になる。ble.sh の実装では e@cho になる。

    そもそも何故 vim がこの様に振る舞うのか分からない。vim の動作を確認する限り
    は、undo を実行した時の変更範囲の先頭にカーソルを移動する様に見えるが、pu
    に限っては u によって消去された範囲の先頭ではなくて u を押した時のカーソル
    位置に戻っている。

2024-12-09

  * highlight: cd を bind -x 経由で実行するとコマンドキャッシュがクリアされないので
    ./docker.sh などの着色がエラー着色のまま or 存在しないのに存在するかのよう
    になってしまう。ディレクトリを記録して変更があればキャッシュをクリアするべき。

2024-12-06

  * edit: url-quote-magic (requested by Bluey26):
    https://github.com/akinomyoga/ble.sh/issues/533

    magic-space 等に追加の処理を自分で登録できる枠組みを作るのが良い気がする。
    そして、提案された機能は contrib　に実装例を追加するという形にする。

  * README: シェルで実装する理由、ble.sh の目的

    * Criticism にシェルで commandline editor を実装するべきではないという批判。
      これについても何回か何処かで返信した様な気がする。うーん。これは README
      の中で書くよりかは wiki の中に書くべきだろうか? うーん。

      恐らくこのあたりだろうか。これは結局 performance に関係しての言及であって、
      複雑なプログラムをシェルで書く事にういての議論ではない。

      https://github.com/akinomyoga/ble.sh/issues/214#issuecomment-1193390781

    * そもそも何故 ble.sh を現在の形に作ったのかという事を何処にも書いていない
      気がする。これは何処かに書いても良い気がする。その議論は以下に書かれてい
      る。

      https://github.com/akinomyoga/ble.sh/issues/422#issuecomment-1986840459

  * wiki: Questions-for-bug-reports.md は Reporting-Issue.md に統合する

2024-11-26

  * read PS1: read -e の内部で PROMPT_COMMAND によって PS1 が書き換わる
    https://github.com/akinomyoga/ble.sh/discussions/528#discussioncomment-11339978

  * menu-style: 複数行 description
    https://github.com/akinomyoga/ble.sh/discussions/532#discussioncomment-11372936

    これは preview pane 付きの menu-style と同時なのではないか。

  * nsearch: nop search が無限に stack する
    https://github.com/akinomyoga/ble.sh/issues/531#issuecomment-2499092693

    同じ位置のゼロ幅一致は連続で発生しない様にするべきである

  * contrib/fzf-menu: util-linux >= 2.39 を requirements に追加する
    https://github.com/akinomyoga/ble.sh/issues/530

  * wiki: bleopt line_limit_type=editor
    https://github.com/akinomyoga/ble.sh/issues/520#issuecomment-2423335161

    history_limit_length > line_limit_length

  * wiki: Unresolved Issues を拾ってまとめる

    既に閉じたものもそうだが、昔から開きっぱなしになっている issues の幾つかは
    もう閉じてしまっても良いと思われる物や、解決・再現の見込みのないものがある。
    これらは Unresolved-Issues に移動して閉じることにする。

    また、閉じた物でも Information Needed ラベルのついた物も同様に確認する。

  * wiki: ble/function#advice の説明を何処かに記述する。他の関数についても記述する
    ことにする。

    Functions.md という名前の wiki ページでも作成することにする。

    うーん。これはまた新しいファイルを作る事になる。stuck しているので取り敢え
    ず分割してこれは後で記述する事にする。

  * complete: contrib に completion-util.bash 等を導入してそれを使って progcomp
    設定の振る舞いを調整できる様にする。opts 経由でどのような調整を行うかを指定
    できる様にしたい。

    - timeout=MSEC
    - timeout-auto=MSEC
    - disable-auto
    - subshell
    - term-leave

    等、様々な調整を追加する。

    * また実装したら wiki/{Performance.md,Reporting-Issue.md} の auto-complete
      の項目でそれぞれ引用する。

  * wiki/Reporting-Issues: keylog の使い方について記述する。syntax_debug や、
    leakvar や、debug_xtrace など。

    物によっては CONTRIBUTING の方に記述するべきかもしれない。特に自分で何か実
    装しながらチェックするべきもの (make scan など)。print-variables 等もこれに
    該当するのでは。

  * wiki/Questions-for-bug-reports: Reporting Issues に統合する

  * wiki/Performance.md: より詳細な設定 with contrib

    * auto-complete: contrib: auto-complete/ TAB completion 用の timeout を設定
      する関数も用意して良いのでは。

    * profiler, is-stdin-ready, conditional-sync, assign 等の関数について説明を
      用意する。下の Functions.md の項目にも注意する。

    * completion setting に対して個別に set -x 及び profiling を有効にする機
      能があっても良いのではないかという気がする。コマンドの実行結果 (入力の
      COMP_* および出力の COMPREPLY, exit status, etc.) も記録して良いのでは。
      それをユーザーに提供してもらう。然し、これはまた一つの大きな課題になる。

      うーん。その様に考えると無限に記述することが増えるので適当な所で議論を切
      り分ける必要がある。

    * 指定した関数の時間を計測する関数? これは core-debug か
      contrib/debug-utils 的な場所に関数を定義してそれを読んでもらう事にする。

  * wiki: describe wiki page
    https://github.com/akinomyoga/ble.sh/issues/531

    empty=emulate-readline について記述する。

  * wiki: Functions.md: 自動生成・抽出

    本当はソースコードの記述を自動的に集める関数を作りたい気もするが、うーん。
    沢山ある関数を全て含めるのは現実的でないし、説明も日本語の物と英語の物があ
    る。現状では取り敢えず別々に記述することにして、必要があれば指定した関数に
    ついてだけ抽出する機能を実装する

    * reject: マニュアルに含める関数のコメントに含めるマークアップを定義する?
      @export-doc など? と思ったがその様にしたとしてもどういう順番でマニュアル
      に含めるのかという問題が生じる。そう思うと結局マニュアルの側でコメントを
      参照するのが現実的ではないか。

2024-10-19

  * [保留] complete: menu-complete の背景色

    Ref #D2291 fish には pager_background や pager_secondary_background がある。
    各項目の文字列の pager_background は必要ない気がするが、各項目の領域の背景
    色を指定できるようにしても良い気はする。

    ただし、pager_secondary_background (交互に背景色を変える) などによって項目
    の配置ごとに背景色が異なる様にすると実装上の問題が生じる。現在の実装では
    esc 生成と出力サイズの計測を行って、それを元にして配置を決定している。背景
    色を配置を決定した後に決める様にすると、esc を再生成しなければならないので
    無駄に処理を二回しなければならなくなる。其処までの需要があるとは思われない
    ので、fish の pager_secondary_background は対応しなくて良い気がする。

2024-09-25

  * complete: ble/complete/candidates/filter#test 候補毎の COMPV の評価方法
    Ref #D2288

    [背景]

    現在の実装では候補毎に絞り込みに使う COMPV の値が異なる可能性がある。(1) 例
    えば或る候補が simple-word/eval によって得られた COMPV (既定) に合致する候
    補名として生成された場合は、その候補は新しい COMPS から生成された COMPV を
    用いて絞り込むべきである。(2) 或いは、別の候補が COMPS に直接合致する物とし
    て生成された場合には絞り込みも COMPS を用いて実施するべきである。(3) 或いは
    更に別の候補が COMPS を別の方法で評価した結果として得られた my_compv を用い
    て生成された場合は、その絞り込みも新しい COMPS から同じ方法で得られた新しい
    my_compv を用いて実施されるべきである。この様な事はシェルとは別の言語が途中
    に含まれるコマンドラインで発生しうる。或いは、引用符の中の一部の単語に対し
    て補完を試みた場合 (例 "hello \"wor[TAB] ") 等も、通常の simple-word/eval
    とは異なる単語評価の方法を用いる必要がある。

    既に fzf による compopt -o ble/syntax-raw で生成された候補や、
    execute-named-command の入力プロンプトにおける COMPS による候補生成などにお
    いて、menu-filter のフィルタリングの仕方を調整するべきだが、現状ちゃんと実
    装されていない物がある。これらの特別な取り扱いが必要になるかどうかというの
    は、候補の生成者 (source) が関知している。従って、cand_pack の内部に "compv
    生成方法" に関する情報を埋め込むのが自然と思われる。

    [修正項目]

    * compv 生成方法 (word-eval) に対して番号 iWE を割り当てる。`0` は `COMPS`
      をそのまま使うものとし、`1` は `COMPS` から
      `ble/syntax:bash/simple-word/eval` を用いて `COMPV` に変換するものとする。
      `2` 以降は新しい word-eval の方法が現れる度に追加して管理することにする。

    * cand_pack の中に word-eval の種類を記録できる様にする。データ形式について
      はよく考える必要がある。

      _ble_complete_cand_varnames には新しい変数を追加する。これまで大文字を使っ
      て来たがグローバル読み取り専用変数と衝突したら嫌なのでそろそろ prefix つ
      きの小文字の変数に少しずつ移行したい。或いは以降のデータについては配列に
      して、無駄に変数を増やさなくて良い様にする。

      cand_pack の形式については ble/complete/cand/yield が定義していると思って
      良い。PREFIX_LEN の次に整数を追加すれば良い気がする。

    * comp_filter_pattern は配列に拡張し comp_filter_pattern[iWE] とする。

      ble/complete/candidates/filter#init filter_type COMPS [COMPV...] は
      filter_type を記録する。COMPS は comp_filter_type[1] 等に格納する。それを
      用いて作られたパターンを comp_filter_pattern[0] に格納して良い (或いは必
      要になった時に使い手の側で comp_filter_type[1] を使って
      comp_filter_pattern[0] を初期化して良い)。追加で COMPV... が指定されてい
      る時には、それらの文字列を使って生成したパターンを
      comp_filter_pattern[1]... に格納する。これは遅延しない。

      ble/complete/candidates/filter#test str [iWE] はテストを行う。iWE が省略
      された場合は 1 とみなす。comp_fitler_pattern[iWE] に対応するパターンが未
      だ初期化されていない場合には、記録していた COMPS を元にしてその場でパター
      ンを生成する。

    * menu-filter や ble/complete/menu-filter/.filter-candidates 等では
      ble/complete/candidates/filter#init や
      ble/complete/candidates/filter#test の呼び出しを適切に更新して、候補毎に
      正しい種類の word-eval を用いて候補をフィルタリングできる様にする。その他
      の ble/complete/candidates/filter#test 呼び出しについても一つ一つ確認を行
      う。

2024-09-22

  * complete: bash-completion のコマンド名生成も WSL2 PATH に対して調整が必要では

    Ref #D2280

    うーん。bash-completion が内部で compgen -c を呼び出している場合にはこれで
    は対応できていないがどうするのか? 或いは手動で bash-completion の関数を上書
    きする?

    調べてみると compgen -c を呼び出しているのは _comp_compgen_commands だけの
    気がする。後 completions/complete で compgen -A command が呼び出されている。
    なのでこれらの関数だけ上書きすれば良い?

  * segment ベースのプロンプトの為の枠組み?
    https://github.com/akinomyoga/ble.sh/discussions/503
    https://github.com/akinomyoga/ble.sh/discussions/282

    airline と同様に縮んで来た時に長さを調整する機能? airline ではどの様に実行
    していたか確認する。基本的にはそれと同様に実行すれば良い。但し、その為には
    単純に自分の一つ左の要素を使って境界の文字を生成すれば良いという訳ではない。

    境界の種類についても幾つかから選択できる様にしたい。全体で一括で決めるので
    はなくて個別に選べる様にする?

    segment 毎に関数を定義できる様にする。ユーザーが定義できる様にする。と思っ
    たが、単に配列に prompt sequence を記述する様にすれば良いのではないか。境界
    についてもそれを指定する専用の prompt sequence を定義して、その中で変数に値
    を指定するなどすれば良いのではないか。

    sbp や liquidprompt や powerline などの構造を参考にする。それらの既存の
    segments を最小限の変更で再利用できる様にする?

2024-09-13

  * https://github.com/akinomyoga/ble.sh/discussions/500
    bashrc で多重にロードしている時に警告を出すべきでは。

    警告を出すにしてもどの様にして検出すれば良いのか。例えば BASH_SOURCE を見て
    .bashrc からどの様に呼び出されているかを記録する (source ble.sh を実行して
    いる行数も特定しておく)。その呼出パターンが複数種類ある場合に警告を発する?

    x 然し、例えばループの中で重複して呼び出している場合等には呼び出しパターン
      は同じになるのでこの方法だと検出できない。

    x また状況に応じて異なる経路で source ble.sh を実行するような設定になってい
      る場合には、改めてユーザーが source ~/.bashrc 等をした場合に、初回と異な
      る呼び出しのされ方をして、それに対して警告を発してしまう事になる。

    例えば ble.sh が source されてから PROMPT_COMMAND が実行される迄に次の
    source ble.sh が実行されたら警告を発する様にする? コマンドの実行回数・行番
    号については初期化時には小さな数になっている筈である。その情報も用いて最初
    のプロンプトよりも前に ble.sh が複数回呼び出されているという事は検出可能で
    ある。

2024-09-02

  * contra に ?5h のバグがあるかも。ちょっとした拍子に反転が戻っておかしな事に
    なる? 或いは screen の方かもしれない。と思ったがそもそも screen の中では反
    転できないという事が分かった。これは関係ない。

2024-08-25

  * [保留] build 時に network がないと怒られるという話 (reported by pallaswept)
    https://github.com/akinomyoga/ble.sh/issues/488

    それで commit hash が決定できないという話。何故?

    もしかすると shallow clone だと駄目ということ?

2024-08-23

  * menu-complete: ページ構築途中で中断すると現在位置がクリアされる

    最近の ble/util/is-stdin-ready の変更で動かなくなったのかと思ったが前から動
    かなかった様だ。と思ったが動作確認をミスしたかもしれない。また後でどの時点
    で発生する様になったのかを確認する。何故?

    ble/widget/menu/forward-line は ble/complete/menu#select を呼び出して、これ
    は ble/complete/menu/show を呼び出して、更に ble/complete/menu#construct が
    呼び出されている。そして、この関数は最初に menu_items や現在位置等の情報を
    設定している…あたかも新しい menu を開始する時の様に。必要なのは新しいメニュー
    を開始する時の処理と、別のページの内容を構築する処理を分離する事なのではな
    いか。

2024-08-21

  * [保留] decode: function name slash workaround 後にキーボード入力ができない (reported by teutat3s)
    https://github.com/akinomyoga/ble.sh/issues/484

  * histdb: 様々の種類の履歴についても個別に記録するべき? 全てコマンド履歴とし
    て記録していると異なる場所で異なる物を提案する様になって余り好ましくない。

  * history: 様々の種類の履歴についてもファイルに記録する。単純なファイル形式で
    良い。というか、実は通常のコマンド履歴についても bash によって一々消去され
    る .bash_history ではなくて、それとは別の場所に記録しても良いのではないか?

    それが histdb であるという考え方もあるかもしれないが、histdb は sqlite3 を
    要求している。もっと簡単で追加の依存性を要求しない物もあるべきである。

2024-06-05

  * 何処かの時点で ret -> REPLY に書き換えたい [#T0009]
    Ref #D2300

    既存ユーザーの設定で使われている場合にはどうするか。declare -n ret=REPLY を
    設定しようと思っていたが、local ret とした時点でそれが上書きされてしまうか
    ら駄目の気がする。逆に declare -n REPLY=ret としていたらどうなるか。これは
    逆にble.sh の内部で local REPLY=xxx とした時点で駄目になってしまう気がする?
    と思ったがその場合は REPLY は通常変数として問題ない気がする。

    自動で変換する時に気にするべきは ret=$? の様な別の用途で使っている物を除外
    する事。また、REPLY が使われている箇所があったらそれが batting しない様にす
    るという事。これについては全く使っていなければ問題ない気がする。

  * debug: debug_profiler_opts=flame

    flame graph にも対応する? 然し flame graph はインターフェイスが難しい気がす
    る。取り敢えず少なくとも等価な統計は出す事にする。percentage, 呼び出し回数,
    etc 等について統計を取る。

    既存のデータの読み取りにも対応する。

2024-04-17

  * highlight sabbrev

    inline sabbrev / line sabbrev 等は後回しで良い。

2024-03-19

  * isearch してから up をした時に選択解除してから上に行くという振る舞いに変わっ
    ている。これも何だか不自然な気がする。元々 set-mark でなかったのであれば up
    で普通に前の項目に移動するべきである。

    そもそも shift selection の時に up をした時に上の項目に移動せずに選択解除す
    る振る舞いになっていて、これは変である。

2024-02-22

  * histdb: calendar で実行時間等についても calendar を作れる様にしたい。現在は
    単に count しているだけ。

  * histdb: calendar やその他のコマンドについても -x 等でコマンドをフィルタでき
    る様にする。フィルタ演算子については atuin で使っている物を参考にする。

  * histdb: zsh-histdb の様に diff driver や merge strategy を提供する? 然し
    merge の瞬間には完全 lock が必要になるのではないか?

  * histdb: default palette を bleopt で指定できる様にする

2024-02-21

  * face 継承。これは設定を整理する上で役立つ。

    実装するべきでは。どうせキャッシュしているので速度には影響はない筈。一方で、
    face の値を変更する時に、影響がある face 全てのキャッシュをクリアするべきで
    は? と思ったがよく考えたら g -> sgr はキャッシュしているが、face -> g はキャッ
    シュしていない。ここでの疑問は合成を実装したとしてその算術式による合成がど
    の程度大変かという事。因みに現時点で再帰的な参照に関しては実装している。
    ref:... である。それとは独立にした方が良い気がする。

    うーん。

    * base=face にする。

    ? 循環参照の検出は行う? 或いは local をして無効化すれば良い? と思ったが算術
      式のレベルでは local を定義する事はできない。或いは複雑なことをすれば算術
      式でも index をずらしたりして回避できるかもしれないが其処までする事かは分
      からない。

      循環参照の検出は動的に行うのではなくて設定時に判定すれば良い。

    * 複数の base に対応するか?

      原理的には対応可能である。先ず base が一つの場合には b1,g,merge とすれば
      良い。base が二つの場合には b1,b2,g,merg,merge とすれば良い? と思ったが
      stack 指向ではないのでこの考え方は変だ。associatvity が成立するのだとした
      ら、g=xxx,b=b2,merge,b=b1,merge,...,ret とすれば良い。associativity は何
      処から出てくるか? (1) xor (revert) については自明 (2) 上書き型についても
      自明。その他の種類はない気がするので気にしなくて良い。

    * 基本的に合成というと足し算である。でも引き算的な物もないと困るのではない
      か? 分からないが取り敢えずは気にしない事にする。

  * bug-bash: bash-3.1..dev exec fd1<&"$var"- で $var の fd が存在しない時のエ
    ラーメッセージが fd1 が存在しない、という物になっている。

2024-02-14

  * complete: / の入った関数名で曖昧補完できていない?

  * selection: dispatch を実行した後に選択範囲を抜けているかどうか確かめる様に
    したが、2キー以上の組み合わせで何かする場合には結局現在の selection では駄
    目なのでは。

    もっとちゃんと対応しようと思ったら次の widget が呼び出された後に何か処理を
    入れる必要がある。然し、それでも arg などの widget の場合にはやはり駄目であ
    る。やはり設計を元に戻した方が良い様な気がしてきた。但し、@marked を経由し
    ない場合には clear-arg または get-arg 辺りで自動で clear する様にするのが良
    い様な気がする。

  * histdb: cpu は 100 倍したい。現在の実装だと微妙。これは何処かの段階で
    version up すれば良い。セッションを一旦すべて閉じてから処理する。

  * progcomp: fullquote を既定で指定して +o fullquote で解除できる様にする?

    その場合には複雑な bash の振る舞いを調べて模倣する必要があるが其処までする
    意味があるかは分からない。

2024-02-08

  * history: command history 以外についても永続的な履歴が欲しい気がする。state
    に沢山放り込めば良い。history.vi_filter, etc. これらはテキストファイルで良
    い。

2024-02-05

  * M-q による buffer stack

    CUA における C-s (保存) はコマンドラインではどの様な機能に対応するだろうか
    という事を考えて、或いはブックマーク的な使い方ができたら良いのかもしれない
    と思った。

    そう思うと zsh にあるらしきコマンドスタック (M-q) という物が気になる。少し
    考えると、順番に取り出すしかないというのは不便そうだし、中身を確認する方法
    もよく分からないし、本当に便利なのか分からないと思っていたが、C-o (開く) で
    例えばメニューを開いて選択することができるのだとすれば、それは便利である。

    そう思って検索してみると以下の記事がある。そもそもコマンドスタックという名
    前ではなくて buffer stack という名前の様だ。それで、自分の思っていたのと似
    たような不便さを感じている様である。但し、一つ前のコマンドを表示するという
    所に留まっていて、メニューを表示するとかそういう所までは考えていない様だ。

    https://kei-q.hatenadiary.org/entry/20110308/1299594629

    一応 M-q は fill-paragraph と conflict するがそもそもコマンドラインで fill
    paragraph を使う機会は存在しないだろう。

    * reject: zsh には POSTDISPLAY という物がある様だ。

      これは ble.sh における info に似たような物だろうか。と思って調べてみたが
      単に zsh-autosuggestions 用に用意された、suggestion を表示する為の物の様
      である。しかも編集文字列の末端にしか表示する事ができない。という事は
      zsh-autosuggestions はコマンドの途中では動かないという事か?
      zsh-autosuggestions を入れていないので分からない。fish については試してみ
      た所、やはりカーソルが末端にある時にしか autosuggestions は働かないみたい
      だ。というか、そもそも履歴からの補完にしか対応してない (恐らくカスタマイ
      ズはできるのだろうが)。

      更に調べると POSTDISPLAY を使おうとするプラグインが複数あるとおかしな事に
      なるという報告ばかり見つかる。まあ、それはそうだろう。

      後気になるのは、zle のページによると zle が呼び出される度に POSTDISPLAY
      はクリアされるという事。つまり、buffer stack の表示はその時にしか為されな
      いのでは? でも他にも設定を真似ている人が Qiita にいる様だから、ちゃんと持
      続的に表示される様にできるのだろう。

      何れにしても便利そうな機能ではない。

    ? 履歴項目の編集中に M-q を実行した場合には何が起こるのか。履歴位置が最初に
      戻るのか、それとも現在の位置にいるままで push が起こるのか → どうも現在
      位置にいるままで push が起こっている。何だか変な感じがする。

    ? 現在の内容を破棄して pop するにはどうしたら良いのか? →

      * M-g (get-line) らしい。

      zsh のマニュアルを見ると他にも沢山 buffer stack 関係の widget が存在して
      いる。

      * M-a (accept-and-hold) はpush&実行

      * C-o (accept-line-and-down-history) は次の履歴項目を buffer stack に読み
        込むと書いてあるがこれは bash の C-o と等価? 少なくとも動かした限りは別
        に push している訳ではなく top level に読み込んでいるだけの気がする。

        accept-and-infer-next-history はより面白い機能の気がする。履歴から完全
        に一致する項目を検索して次のコマンドを推測する機能? 但し、既定で
        binding を持たないので ble.sh に実装するかどうかは微妙。或いは、C-o の
        オプションとして実装するべきかもしれない。

      * push-input は push-line (M-q) の multiline 版の様だが ble.sh 的には行毎
        に確定はしないのでどっちも同じである。

      * run-help (M-h), which-command (M-?) は ble.sh では f1 に相当する。然も、
        buffer stack とは言っているがこれはそのままコマンドを実行してまた戻って
        きた時に元のコマンドをロードするというだけの話なので、余り buffer stack
        特有の使い方という訳でもない。

        一方で ble.sh 的には M-? 的な binding が存在しても良いかもしれないとは
        思う。但し、M-? は既に readline 由来の complete show_menu なので別の
        binding を探さなければならない。或いは M-f1?

  * keymap: 他のエディターモード

    ? 対応する keybinding が分からない物が沢山ある。それらについては emacs
      binding と同じキーで良いのだろうか? 或いは、

    * nano bindings: nano はもっと普通の keybinding によるエディターかと思って
      いたがそうではないみたいだ。確認してみると色々と独創的な操作体系になって
      いる。nano は名前から想像するに余り keybinding はないのではないか。と思っ
      たが syntax highlighting にも対応しているし、微妙なのでは?

    * notepad bindings: もしくは vs もしくは vscode もしくは Windows 系統の
      keybindings。現実的にはこれが便利の気がする。

      C-x C-v C-c, C-a, C-z C-y, C-f, 等様々である。新しい機能として置換(C-h)や
      ブックマーク(C-s)に対応したいという感じも出てくる。

    * これらの binding をどの様に選択するべきか? set -o vi 的なオプションはない
      ので bleopt で指定して貰う事になる。default_keymap

2024-02-01

  * bash_profile

    以下の謎のメッセージが頻繁に表示される。

    [1]   終了                  . "$HOME/.cargo/env"

    declare で関数などを表示してもこれを引き起こす様な物があるようには思われな
    い。trap や keybinding に含まれているかもしれないとも思ったがそれも declare
    の出力の中に含まれる筈である。或いは、/etc/profile.d の中で設定されている何
    かかもしれないと思ったが /etc/profile.d の中を見ても関係ありそうな物は存在
    しない。そもそも bg で source する事に何の意味があるのか。

    と思ったら .bash_profile に記述が追加されていた。然し、それでもこれが bg
    jobs として表示される理由が分からない。うーん。これは background job じゃな
    くて、foreground dead job で、ble.sh の実行環境的に残ってしまっているのが見
    えているという事か。然し、そうだとすると今度は何故 .bash_profile が同じシェ
    ルの中で読み込まれているのかという話になる。よく分からないので
    .bash_profile で記録する事にする。

    % 頻繁に表示されると思ったがもう表示されない。或いは或る瞬間に何かが起こっ
    % て全ての screen window の中でこれが開始されて、でもその後でそれぞれの
    % screen window に初めて触った時に少しずつ表示されたという事なのかもしれな
    % い。

    →2024-02-07 やはり発生した。また、screen の各 window の中でそれぞれ同時に
    発生したというのも再現している。また、emacs 等を開いていた window では何も
    発生していない。また debug.bash_profile.txt には何も記録されていない。

    a SHLVL>=2 で出力する様にしたが SHLVL 1 つまり、現在のシェルの中で実行され
      ているという可能性もある。どうも bind の中だと foreground job であっても
      jobs に現れる様だから。と思ったが本当だろうか? jobs になる為には少なくと
      も subshell にはならなければならない筈で、親シェルでは起こらない筈である。
      と思ったが subshell でも SHLVL は増加する様だ。

      また、よく考えたら screen の中のシェルは既に SHLVL 2 以上なので SHLVL 1
      以下のプロセスが入ってくるとは考えにくい。

    b 或いは .bash_profile ではなくて .profile にも似たようなコードがある? と思っ
      て見てみたらそうだった。勝手に .profile が作成されている。.profile にも同
      様にログを出力する様にした。

    c 実は他のセッションで生成されたメッセージが screen 内部の各端末に書き込ま
      れている? でもそういう訳では無い。ble.sh がプロンプトを更新する時のチェッ
      クで発生しているので。或いは、screen が何か作用している? と思ったが、これ
      も同じ理由で違うと思われる。

    * 然し、何故一度に同時に全ての端末で bg が発生したのかは謎である。或いは
      broadcast 機能を使って bash_profile が開始されたとかそういう事なのだろうか。

    うーん。調べてみたが別に message.post に何か変な物があるという訳でもない。

    2024-02-13 問題が再び発生したが何も bash_profile は通過していない気がする。

    ? 或いは winsz 関係かもしれない。attach した時のジョブが残留していて window
      size の変更があった時に何らかの拍子にそれが思い出されている? と思ったが、
      それでも変は変だ。それだと job entry を session の開始時からずっと専有し
      ていたという事になるが、jobs の時に [1] として表示されるので他のプロセス
      が [1] に来ないという事になってしまう。然し実際には emacs は [1] の上で動
      いている。

      もっと全然別の所で . "$HOME"/.cargo/env を呼び出している物があるのだろう
      か?

    2024-02-16 未だ現れると思ったら .bashrc の最後にテストの為に追加されている
    事に気づいた。呼び出されているのは bash_profile ではなくて .bashrc だったと
    いう事では?

    2024-02-17 再び発生した。然し該当するプロセスはやはり見つからない。そもそも
    本当に bashrc から呼び出されている物なのか? 其処から特定しなければならない
    気がする。コマンドに引数を与えて識別できないか試す事にする。

    確かに bashrc で発生している様だ。然し、発生した段階では bashrc を通過して
    いない様だ。またシェルの開始時刻によって出力したログの形式が異なる (bashrc
    で出力する際の形式を変えたのに伴い)。なのでもっと前 (恐らく bash の開始時)
    に通過した時の job がずっと残っていて最終的に出力されているという事だろうか。
    然し、そうだとすると jobs の count がずっと 1 でなければならない筈の気がし
    て、然しそうはなっていないので不思議だ。また一つのシェルセッションで同じジョ
    ブ番号 [1] で何度も起こる。もし、最初にできたジョブエントリーがずっと残って
    いるのだとすると何度も同じジョブが終了するのは変だ。また、自分で background
    コマンドを実行するとちゃんと [1] に割り当てられるので [1] がずっと埋まって
    いるという事もない。

    つまり、実際に [1] に新しいジョブが割り当てられて何かが終了しているがそのジョ
    ブの名前が attach 前に実行した最後のコマンドになってしまっている、という事?

    2024-02-24 関連するか分からないが関数内で ^C を受け取って INT/DEBUG が発生
    すると BASH_COMMAND の中身が常に . "$HOME"/.cargo/env になってしまって、ジョ
    ブ名も全てこれで固定されてしまう。bash-5.1 以降で発生する。

    x 何か分かった気がする。sleep 1 & を実行すると . "$HOME"/.cargo/env という
      コマンド名に置き換わっている。と思ったが再現しない。と思ったら次の項目で
      述べている関数内で ^C を実行した後に起こる現象の一つだった。

    x BASH_COMMAND の中身が常に . "$HOME"/.cargo/env になってしまう。

      あと top-level での BASH_COMMAND の内容が更新されていない? C-c すると常に
      BASH_COMMAND に . "$HOME"/.cargo/env という文字列が入っている。然し、条件
      がある様にも思う。関数の中で呼び出している限りは大丈夫? うーん。自分で
      declare -p BASH_COMMAND 等を実行する限りは BASH_COMMAND の中身は常に
      . "$HOME"/.cargo/env になっている。

      普通に新しい session を始めると問題はない様だ。然し、関数内で ^C が起こる
      と BASH_COMMAND が常に同じ値になってしまう。bash-5.0 以下では発生しない。
      bash-5.1 以上で発生する。bash-dev でも発生する。

      $ bash-5.2
      $ func() { for ((i=0;i<100000000;i++)); do :; done; }
      $ func
      ^C^C
      [SIGINT] main:1 (func)
      [SIGINT] global: ((i<100000000))
      [ble: SIGINT (130)]
      [ble: elapsed 1.084s, CPU 99.9% (self)usr1.077/sys7ms] func
      $ declare -p BASH_COMMAND
      declare -- BASH_COMMAND=". \"\$HOME/.cargo/env\" \"(bashrc) \$BASHPID\""

      一旦 ble-detach して ble-attach したら直るかと思ったら直らない。うーん。
      だとすると、再現コードはそんなに難しくないかもしれない? と思ったが適当に
      打ち込むだけでは再現できない様だ。

      うーんこれはまた独立な問題の気がする。cargo/env のメッセージが出るセッショ
      ンで sleep 1 & を実行してもちゃんと sleep 1 が表示されるので、
      BASH_COMMAND は少なくとも壊れてはいない。分かる事は bash は何処かに
      .bashrc の最後のコマンドを覚えていて、それが何かの拍子に表に出てくる事が
      あるという事。

    * TODO: bug-bash で報告する? 最小再現コードを作成しなければならないが面倒そ
      うだ。

    2024-02-25 取り敢えず普通に .bashrc を実行した時に末尾にあるコマンドを拾っ
    ているだけの様な気がするので、以下のテスト用のコードは .bashrc から削除する
    事にする。

    if ((BASH_VERSINFO[0]>=4)); then
      printf '%079d\n' 0
      printf '[%(%F %T %Z)T] %s\n' -1 "PID=$$ BASHPID=$BASHPID SHLVL=$SHLVL"
      declare -p FUNCNAME BASH_LINENO BASH_SOURCE
    fi >> ~/debug.bashrc.txt 2>&1

2024-01-06

  * complete: blesh completion source のAPI整理および定義方法の docs
    https://github.com/akinomyoga/ble.sh/issues/157#issuecomment-1867622494

    そもそも API 自体も再考する可能性がある。既に yield などは使っているプロジェ
    クトやユーザーが幾つかある様な気もする (rsteube/carapace など) が、それに関
    しては個別に GitHub 上で探索して報告する事にする。それと同時に後方互換性は
    できるだけ保つ。

2024-01-05

  * mc 的な TUI を自前で実装しても良いのではないか? どうも mc を使っている人は
    結構いるようである。更に、dylanaraps/fff 等の機能も参考にしても良いのかもし
    れない。と思ったが、fff はデモを見る限りは大した機能はないのではないのかと
    いう気がする。ranger/ranger も参考になるかもしれない。何れにしても自分的に
    は余り使わない気がする。

    報告があったので ranger を使ってみた。インターフェイス的には単純明快。ファ
    イルの中身をプレビューする事ができる。nnn というファイルマネージャも存在す
    る様だ。

2023-12-10

  * main: ble-update, ble-reload, bleopt, ble-sabbrev, ble-palette の adjust-bash-options

    もしくは全部 ble 経由で呼び出してもらうことにして ble の側で待避を行えば良
    いのかもしれない。

    ble-reload に関しては内部で source するのだとしたら無理やり状態を復元保存し
    ようとするのは問題がある気がする。特に ble-reload で adjust した後の状態を
    グローバル変数に記録してしまうのではないか。そう思うと ble-reload は待避の
    対象ではない気がする。そういう場合もあるという事を考えると ble で一括で待避
    するというのも実は柔軟性に書けるという事になるのかもしれない。

2023-10-04

  * {,dir/}*.* が failglob エラー着色になる。本来は *.* に対して一致が試みられ
    て failglob にはならない筈。どうも / で先に split するので /}*/* というパター
    ンに対して一致が試みられている気がする。本来は先に {} について処理するべき。

2023-09-13

  * bash-5.2 "\e[\000"
    Ref #D2069

    * bash-5.2 で "\e[\000": "<C0><9B>[" という macro になっているのが気になる。
      本来此処には \000 は存在するべきではない。これは実際に内部的に \000 があ
      るのかそれとも出力する時の問題で \000 となっているのか。然し、これは既に
      bash-dev では修正されているし、またそれにもかかわらず bash-dev でも今回の
      問題が起こっているので、これは今回の問題には関係ない。

      これは以前にも気付いていた事の気がする。探してみたら 2021-11-05 に項目が
      あってしかも放置されている。何れにしても 5.3 では修正されている。実際の振
      る舞いに影響があるのかどうかは不明である。

      うーん。これは bash-5.2 のソースコードを使って何が起こっているか確認する
      べきなのかもしれない。或いは bisect を実行する。bind に使っているスクリプ
      トはどこかに出力する事ができる筈である。或いはキャッシュになっている →
      キャッシュにあった。確認すると builtin bind '"\e[":"\xC0\x9B["' で bind
      しているので実行するコマンド自体が壊れていたとかそういう事ではないはず。

    * どうやら単に以下を実行しただけで既に再現する。

      $ bash-5.2 --norc
      $ bind '"\e[":"abcd"'
      $ bind -s

      そして M-[ を押すと (多少の keymap delay の後に) abcd が入力される。つま
      り、実際に \e[\000 が束縛されているというよりは表示の際に変な表示になって
      しまっているという事の気がする。

      これが実際に何らかの問題を具体的に引き起こす事はあるだろうか。そもそも通
      常は \e[ は単独では bind しない。なので、例えば ble-detach の時に復元する
      対象にはなっていないと考えられる。

2023-09-03

  * complete: copilot
    https://github.com/akinomyoga/ble.sh/issues/358

    * reject: AWS Copilog CLI (copilot completion bash)
      https://aws.github.io/copilot-cli/ja/docs/commands/completion/ これは公式
      の copilot for shell の様な気がする。一番初めにチェックするべきはこれの気
      がする。copilot バイナリは何処で手に入るのかと思ったが standalone binary
      がある。
      https://github.com/aws/copilot-cli/releases/latest/download/copilot-linux

      →うーん。上記の例は単に copilot コマンドのコマンド引数を補完する為の補完
      設定だった。更に、試してみた所 github-copilot-cli と互換なサブコマンドは
      提供されていない。そもそも AWS Copilot CLI は AI とは何も関係ない、AWS の
      コンテナ等を管理する為のコマンド? の様だ。

      全く関係ない物だった。

    * これは GPT に質問をしてコマンドを生成させるという事をしている。
      https://github.com/tom-doerr/zsh_codex/tree/main

      現在の文脈情報について含めることができるのだろうか。例えば、現在のディレ
      クトリの内容は云々だとか、README の内容は云々だとか。README の内容を普通
      に書き込むとその中に書かれていることも直接 GPT に対する司令だと勘違いして
      しまう可能性もあるのではないか。具体的にどのようにしたら良いのかの例はあ
      るのだろうか。

    * GitHub Copilot CLI

      * github-copilot-cli (fish)
        https://zenn.dev/tunefs/articles/b284d532ed5460
        これは github-copilot-cli というのを呼び出しているみたいがだが、
        github-copilot-cli は入力中のプロンプトの編集を手伝ってくれるのではなくて、
        呼び出すと独自のインターフェイスに入ってコマンドを実行してくれるだけである。
        https://www.npmjs.com/package/@githubnext/github-copilot-cli

      * 取り敢えず以下の頁を参考にして登録してみる事にした。

        https://zenn.dev/k9i/articles/56920952ce9644

      waitlist で待たなければならない。

2023-08-17

  * ext: Android OS コンパイル環境での問題
    https://github.com/akinomyoga/ble.sh/issues/353

    Android OS をコンパイルする時に応答がなくなると言っている。これは Android
    OS のバグなのではないか。調べてみると Android OS をコンパイルするのには4コ
    ア使って数時間かかるとか言っている。仮想マシンの中で実行しようと思うとます
    ます時間がかかるのではないか。しかも 18.04 LTS とかいう古い Ubuntu の OS で
    やっている。

    応答がない。

2023-06-21

  * menu for history entries (requested by auwsom)
    https://github.com/akinomyoga/ble.sh/issues/258#issuecomment-1599945461

2023-05-19

  * osh のテスト上で bash が失敗している。何故だろう。
    http://travis-ci.oilshell.org/github-jobs/
    http://travis-ci.oilshell.org/github-jobs/4035/app-tests.wwz/_tmp/soil/logs/ble-test-bash.txt

    * 先ず mawk が正規表現を正しく処理できていない。然し手元の mawk では特に問
      題がある様には見えない。arch 等でも問題が見られた記憶はない。最新の mawk
      で試してみる価値はある。

      > mawk: line 37: regular expression compile failed (missing operand)
      > ^('[^']*'|\$'([^\\']|\\.)*'|\$?"([^\\"]|\\.)*"|\\.|[^[:space:]"'`;&|()])*

      確認してみたが少なくとも Fedora に載っている mawk は Debian の最新の mawk
      と同じである。という事は最新の mawk で問題があるという訳では無い様に思わ
      れる。では逆に古い mawk で問題があるという可能性?

      と思ったが mawk のページには最近幾つかの新しい version が公開されている。
      これらを試す価値はある。改めて最新の物を試してみたが問題は再現しない。
      2010 の物を試してみたが再現しない。念の為、最も古い物を試してみる。と思っ
      たら再現した。2008 の物である。これは mawk のバグだと思って良いだろう。

    もしかしたらテストの失敗もこの mawk によって引き起こされているのかもしれな
    い。mawk を上書きした状態でテストを実行したらどうなるかについて確認する。うー
    ん。実際にやってみるとテストに新しく2箇所失敗する。然しながら oilshell ci
    上で見られたエラーは確認されていない。これはまた別の古い awk 実装によって問
    題が発生している可能性があるだろうか。更に試してみるとこの2個のエラーは正規
    表現のエラーとは関係ない様だ。


    ? mawk の version check をする? テスト上で問題が発生しないのは 20090705 以
      降である。また初期化時の正規表現のエラーが発生しないのは 20090710 以降で
      ある。

      ところが mawk が現在のバージョン表記に切り替えたのは mawk 1.3.3 20090721
      以降の様である。それ以前は "mawk 1.3.3 Nov 1996" という文字列固定で表示さ
      れている。バージョン表記に関しては mawk 1.3.4 以降であるか、または mawk
      1.3.3 20?????? 的な形式をしていれば良いという事にする?

      然し、このチェックを行う為だけでも初期化コストがかかる。そもそもこの様な
      古い mawk を使っている場合というのは限られているのでそもそも判定しなくて
      も良いのではないか。

    todo: mawk のテストも test-bash に追加する事にする。

2023-05-13

  * complete: sed コマンドの補完
    [1] https://github.com/akinomyoga/ble.sh/issues/326

    zsh は sed -r[TAB] に対してちゃんと short flags を提示するし、"sed
    -re[TAB]" に対して sed expression の説明を提示する。これらをbash-completion
    と協力して実装する事はできない物だろうか。と思っていたら [1] でも要求された。

2023-04-13

  * bash は実は補完で pathname expansions の結果を候補として出す
    https://github.com/scop/bash-completion/issues/444

2023-04-10

  * gnuplot 実装を真面目に考える?

  * complete: here documents の補完

    よく考えてみたらそんなに実装は簡単ではないかもしれない。素朴に考えると
    completion-context にて here documents の中にいる時には here documents 全体
    を補完対象としてい補完 source を生成すれば良い気がする。然しそれだと here
    documents 全体が補完の置換対象となって着色が巨大になって自然ではない。

    実はこれは長い文法的単語の中に含まれるファイル名などの補完の場合にも問題に
    なる。実際にどの位置から補完を開始するのかが動的に変化する場合についても考
    慮に入れるべきの気がする。そしてそれは source 毎に設定できる様にする?

    a 然しそうすると補完開始位置が混在する事になる。或いは表示している時の着色
      だけが問題という事であれば単に着色開始位置を各候補に記録させれば良いだけ
      の気もする。

    b 或いは source 毎に補完開始位置は固定にして異なる補完開始位置の source が
      ある場合には、より前の位置から補完を開始した物を削除する?

      これを実装する為には動的に COMP1 を変更する仕組みが必要になる気がする。果
      たして source の生成途中で COMP1 を変更しても問題が起こらない様になってい
      たのだったか。現在の実装だと source の呼び出しの時点で COMP1 が決定されて
      いると考えて良い。なので、source の中で未だ候補を生成していない限りは
      COMP1 は他に影響を与えていないので問題はないのではないかという気がする。

      一方で既に述べた様に異なる source が異なる COMP1 を設定した時にどうするの
      かという問題が生じる。

      a これだと source 毎に補完を生成してから merge するという操作が必要になっ
        てしまうのではないか。

        然しその方が却って良いのかもしれないとも思う。現在の実装だと毎回一々
        old_cand_count 等を記録したり部分的にfilter をかけたりと非自明な操作が
        入っているので。然し、この様にしたとしても内部的に入れ子で source を呼
        び出している実装の場合には結局毎回チェックは行う必要がある事に違いはな
        い

        集計を行うとしたら source に登録してもらう配列名 (cand_*) と、それらを
        集めた結果の配列名 (merge_cand_*) を変える必要が出てくる。既存の実装の
        全ての cand_* に対する参照を書き換えるのは大変なのではないか→取り敢え
        ず数えると 104 個ある。其処まで多くはない。或いは、変数名はこれまでの儘
        にしておいて、source を呼び出している関数で合成を行う?

        また COMP1 についても各 source に対して用意して最後に統一するという手が
        ある。

        うーん。調べた所、cand_* に作用する関数は色々ある。source の内部でも
        source の外側でも呼び出す可能性がある物を考えたらやはり変数名は変更せず
        に generate-with-filter の側で切り替えを行う方が良いだろうか?

        * 先ず使用実態を調査しなければならない。

      b 或いは、以前の source が生成した物よりも後に開始位置をずらしたい場合に
        は既に生成した補完候補は削除する事にして、また、一旦開始位置が後ろにず
        らされたら後続のの補完 source はそもそも呼び出さないという仕組みにする?

        x この方法だと補完候補生成が source の順番に依存する様になってしまう。

      c 或いは、各 source の先頭で現在のずらされた状況を調べてもしずらされてい
        たら補完候補を生成しない、もしくは補完候補を生成しないなどの対策を行う。
        然し、この実装はそれぞれの source で細かい事を考える必要があるので余り
        望ましくない。


    c 或いは completion-context の決定の時点でコマンド毎に補完の開始位置をカス
      タム計算できる様にする? しかしこの方法だと、最初に「単語全体の補完を試み
      てその後で部分単語について補完を試みる」という段階的な補完を実行すること
      ができない。

2023-04-09

  * contrib: (source snake.sh) して C-c C-c で停止させようとすると read が壊れる

    read にて -u が変数名ではないというエラーメッセージが出て止まらくなる。
    と思ったら再現しなくなった。よく分からない。

2023-04-02

  * set -o posix で起動すると keymap が見つからないというエラーが発生する

  * history (bash 3.0): 履歴が重複して記録される

    bash-3.1 以降では問題ない様だ。つまり bash-3.0 だけで起きている問題である。
    これの優先度は低い。或いはもしかすると既知の問題である可能性?

  * prompt: 右プロンプトの範囲に合わせて textarea の横幅を途中で切り替える?
    https://github.com/akinomyoga/ble.sh/discussions/310

    これはこれまでにも考えた事があるはずだと思ったが todo 項目が見つからない。
    もしかすると頭の中で思っていただけかもしれない。

    * scroll 機能との兼ね合い → rps1 も一緒に scroll する事にすれば良い。

      少し考えてみたがどうも scroll 機能と conflict する気がする。scroll する毎
      に各行の折返を実行し直すというのは well-defined なのか。というかそもそも
      他のアプリケーションでもその様な変な形の枠の中で scroll しながら枠に合わ
      せて折返を実行し直すという実装は見た事がない。

      或いは、scroll する場合にはそれに応じて rps も一緒に scroll するという可
      能性? その様にすれば変な事は気にしなくて良い。rps1 を途中で切断しなければ
      ならないかもしれないがそれに関しては clip すれば良い気がする。

      然し長いコマンドラインを実行した後に rps1 が表示されない状態で次のプロン
      プトに行くという事にならないか。或いは長いコマンドラインの時には全体を一
      旦出力して次に進むという事にすれば良いのだろうか。新しいコマンドラインに
      移動する直前であればターミナルを溢れてしまっても問題ない筈なので。下手に
      削られて記録が消えるよりはそちらの方が自然の気がする。

      と思ったがスクロール範囲はプロンプトの最終行から始まる。なので、右プロン
      プトもプロンプトの最終行以降に被っている部分だけスクロールする事になるの
      だろうか。何だか複雑である。然し、そもそも右プロンプトもプロンプトの高さ
      で範囲を制限していて非自明な事をしているのでその程度の事は寧ろ自然の気も
      する。

2023-03-27

  * menu-complete: 長い候補を表示した後の再配置
    Ref #D2025

    これは WINCH 後の振る舞いにも関係している。WINCH があったら menu を閉じるか
    或いは再配置を行う必要がある。現在は開きっぱなしになっている気がする。或い
    は…何か変な状態になっている。info panel の高さはクリアされているけれども描
    画されていない状態? の気がする。

    本当は info に関係する winch の callback も欲しいという事。或いは panel
    height 決定で要求したのと異なる高さになった時に呼び出す hook? というか単に
    panel height change に対する hook で良い気がする。そして既にその仕組は
    onHeightChange で実装されている。現状では info#panel::onHeightChange は実装
    されていない。此処で info#panel::onHeightChange に際して現在の選択項目が範
    囲外になっていたら再描画を発生させる hook を登録できる様にする。現在表示し
    ている内容が menu なのかどうかの情報を何処に記録するのかはよく分からない。

    どうも winch を実行すると瞬間的に高さが縮む様である。その後で続きを処理しよ
    うとすると高さがまた元の高さに戻る。うーん。と思ったがそうでも無いような気
    がする。前回と同じ高さであっても onHeightChange が呼び出されている。何故だ
    ろうか。内容がクリアされてなくなってしまった場合にも呼び出されるという事と
    思って良いか。

    →うーん。どうやら潰れて見えなくなった時には onHeightChange は呼び出されな
    い様だ。その後で最初に有限の高さに戻った時に onHeightChange が呼び出される。

    然し height change を受け取ったとしてもその場で再描画する訳には行かない。既
    に描画の途中でその処理の途中に height change が起こっているかもしれないから
    である。

    a うーん。onHeightChange に於いて invalidate を設定する? でもこれだと現状で
      潰れた時に onHeightChange を呼び出していないので、潰れた事を検知できない。

    b もしくは info#panell::render に於いて高さを毎回チェックすれば良いのかもし
      れない。と思ったが、これも潰れた時に一度も呼び出されないので潰れてまた拡
      大した時に検知できないのではないか。

    取り敢えず menu-complete 中に長い行が選択されて info が縮まった後にもちゃん
    と onHeightChange は呼び出される様だ。但し、onHeightChange が呼び出された後
    に果たして render が呼び出されるのかは保証できない。上の枠組みで高さが変化
    したら render を改めて呼び出すという事を処理する様にしてしまうと今度は無限
    ループになるのではないかという懸念が生じる。

    現状の canvas panel の枠組みにおける問題点は以下の二つである。

    * onHeightChange が潰れた時に呼び出されない。潰れた時にも呼び出す様に変更し
      たいが、既存の onHeightChange の処理がどうなっているか気になる。

      更に潰れたという事が command-layout 等の都合で一時的に潰れる (後で全体を
      再描画する予定) という事なのか、それとも他の panel が大きくて潰れざるを得
      なかった (後で再描画はしない。より小さい領域に fit する様に処理する必要が
      ある可能性はある) という事なのかで振る舞いが違っても良い。

      一時的に潰れているだけなのであれば現状の様に onHeightChange は呼び出さず
      に別の種類の処理を呼び出すべきの気がする。

    * 一つの描画処理の中で既に描画し終わった panel の size change が発生した時
      に、その panel を改めて再描画する様に処理するか?

      然しそもそも描画処理の途中に高さが変わるという事があるのかというのは疑問
      である。調べてみるとどの panel も途中で reallocate-height.draw を呼び出し
      ている。そもそもこの段階で処理を再考するべきなのではないか?

      最初の処理の段階で希望の高さを提出しておいて reallocate-height を実行した
      後に各 panel の描画を開始する。各 panel は与えられた高さの中で表示する様
      にする。もし足りない場合には fallback するか collapse する (減る分には問
      題はない筈)。

    * invalidate は panel 側でも管理するべき? 但し、分からない。

2023-03-09

  * complete: 末尾に不完全な \ がある候補の specialchars フィルタリング?

    最後に中途半端な \ がある時には実はフィルターする時にも \ で quote する必要
    性のある文字が続いている物だけにするべきなのではないか。と思ったが処理的に
    複雑になるのではないか? 取り敢えず末端に中途半端な \ があるかどうかは
    comps_flags に B が含まれているかどうかで分かる。

    その上でその事実を用いて生成するファイル名を制限するかどうかというのが問題。
    然しその制限を適用する事によって候補がなくなってしまっては変な気もする。

    a 全ての候補を生成してから、生成候補を制限しても候補が残るようであれば制限
      をかける事にしようと思ったがそうしたとしても異なる種類の候補が混ざってい
      る時に不用意にフィルタできない。例えば sabbrev 候補は絞り込みの為に cand
      には quote を処理した後の値を入れている。

    b と思ったが quote の必要のない候補ばかりの時には生成候補がなくなっても良い
      気がしてきた。

    そうは言っても問題になるのが bash-completion によって生成される候補を制限す
    るかしないかという事。実際に生成している側でないとその意図は分からない。

2023-03-08

  * :name: に対して emoji 変換を実装する?

    https://www.webfx.com/tools/emoji-cheat-sheet/ に一覧がある。
    然し、emoji リストの難点は思い出すのが大変という事。リストを表示できたら良いのだが。
    例えば sabbrev -m 経由で挿入するというのが良いかもしれない。:: を使う。

  * [保留] canvas/panel: 一旦 scroll buffer に行ったものを元に戻す可能性? (motivated by mozirilla213)

    https://github.com/akinomyoga/ble.sh/discussions/288#discussioncomment-5226973
    > (And the completion words fill and cut the previous output when scrolling
    > up the terminal which I think is a known limitation which is fine,

    panel の set-height で行が消えてなくなる? うーん。然し報告者の使っているら
    しき konsole では特に内容が失われるということはない様である。ちゃんと
    scroll buffer に内容が残っている。

    恐らく scroll buffer に行って一旦画面から見えなくなるという事を言っているの
    だろう。或いは、一旦 scroll buffer に行った物を、menu が閉じた後にある程度
    回復するという事。端末によっては何かそういう様な拡張をしていた様な気がする
    のでそれを有効にする可能性はある。

2023-03-02

  * menu-complete: C-TAB を連続で押すと仮挿入をそのままに新しい補完が始まる

    menu-complete の外側の keymap で menu-complete が設定されている時には単に
    menu_complete/forward にしたりなどした方が良いのではないか。

    と思ったが menu_complete に対して引数が指定されている時などにどのように対処
    するべきかわからない。例えば insert_all や insert_brances や context=* が指
    定されている場合には単に移動するのではなくて今の補完を明示的にキャンセルし
    て新しく補完し直すべきなのではないか。然し、単なる complete や
    menu-completion や menu-complete backward 等の時には改めて開始するのではな
    くて内部での補完候補の移動を行いたい気もする。

    然しチェックするにしても全ての文字をチェックしていると大変である。と思った
    が、UTF-8 decode や key decode 等の処理の重さなどを考えたら大した事ないとい
    えば大したことない。

  * menu-complete: suffix もメニュー選択時に表示する機能?
    https://github.com/akinomyoga/ble.sh/discussions/297#discussioncomment-5159146

    然しこれは最後の確定時にならないと計算されない。メニューを選択した時にそれ
    も計算する? 然しそうするとしてもrequote だとか前方の文字列の吸収だとかその
    他の処理についてはどうするのか。

    特に前方の文字列の吸収に関しては実際に実行してしまうと元々の内容が消滅して
    しまうので駄目である。或いは前方の文字列に一致する物がある場合には単に挿入
    部分の方を短くすれば良いのかもしれないが、それはそれで着色範囲が変になって
    しまって見にくい。更に前方に完全に一致する場合には挿入文字列の幅が 0 になっ
    てしまって見えなくなる。また確定した時に何処にカーソルが移動するのかという
    のも分かりにくい。

  * wiki: Design Widget の翻訳?
    https://github.com/akinomyoga/ble.sh/discussions/272#discussioncomment-5013253
    https://github.com/akinomyoga/ble.sh/discussions/294
    https://github.com/akinomyoga/ble.sh/discussions/301

    何やら色々変な事を試そうとしている人がいるみたいなので。

2023-03-01

  * [保留] decode: M-S-o と M-O のどちらか一方に強制的に揃える?

    現状では二つの形式に同じ binding を与える様に設定しているがわざわざ両方設定
    するのは大変である。一方で、CapsLock 等を考慮に入れると両者は実は互換ではな
    い。更に端末によって CapsLock がある時の振る舞いや、S を付加している時に
    Shift 前の文字を底字にするのか Shift 後の文字を底字にするのか振る舞いが異な
    る。なので正確に判定するのは難しい。

  * [保留] ble/builtin/readonly などの上書きを function#push で行う?

    ユーザーが独自に定義していた時などにそれを保持する為。また、ユーザーコマン
    ドを実行した直後にユーザーが上書きしていたら改めて push を行う。その時には
    既に push chain の中に登録済みであればそれを削除する等の仕組みが欲しい気が
    する (opts 引数で指定)。

    これはわざわざ表示しなくて良い気がする。

2023-02-27

  * [保留] complete: compopt -o filenames が指定された時に末尾の空白を除去する?
    bash の振る舞いを確認する。

2023-02-20

  * autoenv 実装

    既存の物と同じ設定ファイルを使い回す事を検討するべきだろうか。zsh-autoenv
    は .autoenv.zsh を使っている。これに倣うのであれば .autoenv.blesh という物
    を用意するのが便利である。

    * authorized 的なファイルの形式はどうするか。何処に記録するか。sha256sum を
      呼び出せば良い。然し、sha256sum が存在しなかった時にどうするのかや、前に
      無かったのに新しくインストールされた場合にどうするのか等が非自明である。
      取り敢えず cksum は存在すると思っておくべき? あと、前にはあったけれどもな
      くなってしまったという場合にもどうするのか困る。うーん。ファイルには hash
      の形式も一緒に記録する事にするのが良い気がする。

    * bleopt push/pop の機能を実装するべき。bleopt --push ... 等とする? 或いは
      全ての設定を一斉に push するという手もあるだろうか。或いは、bleopt 自体に
      hook して .autoenv を実行中の変更を全て track する。これが楽の気がする。

    * function については ble/function#push/pop を使ってもらう。alias は ble.sh
      側で追跡する。adjust の中で定義して大丈夫なのか? 抜ける時には特に今まであっ
      たものを敢えて削除する事はしないので一応使える? 然し、以前の alias が退避
      されていた場合にそれが restore される時に上書きされて昔の物に戻ってしまう
      という事が起こるのでは。という事を考えると alias に関しては adjust を一旦
      restore しておく必要があるのではないか。他にも FUNCNAME 等が気になる。

2023-02-12

  * syntax: 5.0 以降では関数名として function `xxx` 等も実は許されている。5.3
    以降では更に <(...) も関数名として使える。しかもこれらは `xxx`() や
    <(...)() の形式でも定義できる。

    現在の実装では関数名を function NAME まで一回の解析で進むようにしている。何
    故だったか。何か理由があった気がするが、この取扱になっている限りはちゃんと
    対応するのは難しい。過去の記録を調べる必要がある。

  * complete: shopt -s extglob failglob で @(aa)() { echo; } という関数を作成し
    て置くと screen -dr の補完の途中でエラーメッセージが表示される。何処から表
    示されているのだろうか? 関数名を拾って更にその上でそれをパス名展開に晒して
    いる箇所があるのだろうか? simple-word ではないので ble.sh の内部ではないの
    ではないか…という気がするが分からない。

2023-02-06

  * auto-complete: cd 等簡単に成否が分かる物については判定して除外する可能性

    然し cd を上書きしている場合等にはやはり問題になる。またコマンド毎に対応す
    るのは大変なのでこれも progcomp, chroma の様に判定するシェル関数を用意する
    可能性。ただ、問題なのは、単純コマンドでない時にコマンドの位置などの判定を
    行う必要があるという事。そしてその為には構文解析を各項目に対して回す必要が
    ある。という事を考えると重くて現実的でない気がする。

2023-02-03

  * contrib: ble-import で contrib/ は不要なのではないか?

2023-01-26

  * histdb: history の中から情報を取り出してそれを使って何かする機能

    これができなければそもそも実装する意味がない。例えば auto-complete で単語を
    表示する等。

    * done: wiki: BLE_SESSION_ID, BLE_COMMAND_ID

    * 履歴を操作・編集(削除)する機能も欲しい。

      histdb [list]                 コマンド一覧
      histdb list-session [options] セッション一覧
      histdb delete [OPTIONS]       コマンド削除
      histdb -s [.|session]         セッション指定
      histdb -d [.|dir]             ディレクトリ指定
      histdb -t [.|dir]             ディレクトリ指定(サブディレクトリも含める)
      histdb -g glob                コマンドをパターンで絞り込み
      histdb -c command_id          コマンドIDによる指定

2023-01-25

  * complete: 英単語の曖昧補間やスペルミスの検出など

    この場合には一意確定だとしても挿入はしない方が良い。コマンド引数
    (source:argument) についてその他の候補生成が全て生成に失敗した時にこれを実
    行するのが良い気がする。そしてその場合には勝手に挿入しない事を表す flag か
    何かを設定する事にすれば良い。

    英単語辞書は bash で処理すると遅いので awk か或いは外部コマンドを呼び出すべ
    き。或いはこれまでに実行したコマンドから拾ってくる? これまでに実行したコマ
    ンドに関しては変な切り取り方をしても仕方がないので、

    a 予めコマンド実行時の文法解析結果を元に単語を抽出してファイルに記録してお
      く。これは comps との一致対象。記録は state ディレクトリの中にファイルを
      作成すれば良い。~/.local/state/blesh/history.xword.txt 等。

    b 同様に単語がファイル名に一致する場合にはそのファイル名を記録する
      (history.filename)。現在ディレクトリとの組にして記録するとより良いかもし
      れない。これは compv に対して一致を試みる。

      x 現在ディレクトリとの組にするのだとしたら結局現在ディレクトリで普通にファ
        イル名補完をするので十分なのではないか。逆にディレクトリに関係なくファ
        イル名を記録するとしても何か用途はあるだろうか。結局単語補完と実質同じ
        なのではないか。

    c 更に、simple-word の時には展開結果を記録する (history.vword.txt)?

      x 展開結果が長大になる可能性がある。

    d 更に c をスペース等で分割して単語を記録する (history.eword.txt)?  然しこ
      れも変な物を記録しても仕方がないので bash special chars に関しては含めな
      い様にする。もしくはそれらも分割子として取り扱う。これも compv に対して一
      致を試みる (特にスペース等で分割した後の直近の文字列に対して判定する)。

    history に関しては ToDo 2021-05-17 に関連項目がある。

2022-12-09

  * edit,complete: alias expansion で alias sudo='sudo ' 等による引数の展開に対応?

2022-12-03

  * declare -f の出力は特殊関数名には使えないのではないか?
    https://lists.gnu.org/archive/html/bug-bash/2022-12/msg00010.html
    https://lists.gnu.org/archive/html/bug-bash/2022-12/msg00011.html

    取り敢えず、これは evaldef の時点で function を prefix すれば良い気がする。
    今後の Bash の振る舞いの変更で function が追加されるかもしれないので、その
    時にはそれを避ける様にする。

    更に変数代入の形の関数名は declare -f &>/dev/null でテストする事もできない。

  * colorglass: face から読み取る時に作用する色設定?

    現在は全ての出力に対して色を変更しているが、プロンプトのテーマを別に指定し
    ている場合などを考えると、プロンプトの色には作用して欲しくない気がする。一
    方で元々の colorglass のアイディアでは全ての色に対して作用する事を考えてい
    た。両方の種類のオプションを提供するという手が考えられる。例えば、現在のオ
    プションはそのままにして、colorglass_face_* という物も提供する。

    インターフェイスは別として実装は考える必要がある。

    a 現在は face は全くキャッシュしていないので、face 読み取り部分に filter を
      挟むとなると遅くなる。或いはキャッシュするか。キャッシュするとしても将来
      的に face 間に依存性を持たせる実装を考えると個別にキャッシュできない。

    b 或いは、別の colorglass domain の区分けとしてプロンプトを処理する時とそれ
      以外で分けるという事も考えられるだろうか。しかしそれだと vim-airline の設
      定は prompt に含まれるので既定の色を抑える等の調整ができなくなる。

2022-09-15

  * vim terminal や neovim terminal における keymap-timeout に対応する設定は何
    か。調べてみると ttimeoutlen や timeoutlen という物がある様だが、これの設定
    を変更しても振る舞いに変化はない気がする。後でちゃんと調べる必要がある。

2022-09-11

  * 何らかの拍子に P[0 q の様な謎の文字列がユーザーコマンドの実行後に出力される
    様になる。

    これは DECSCUSR に関係しているのは確かだと思われるが、どうやって起こるのか
    分からない。例えば _ble_term_Ss 関係の変数が変な値になっているのが原因かと
    も思われたが別にこれらの変数に問題はない。P[0 q の様な文字列が含まれている
    変数も存在しない様に見える。

    * bleopt term_cursor_external=1 を設定してみたらコマンドが始まる前にも変な
      メッセージが出力される様になった。つまりやはり cursor-state の管理の部分
      で起こっている問題なのだろうと思われる。

    * 新しい bash を開始すると別に問題は生じない。また、そもそも表示幅も狂って
      いる気がする、と思ったがこれは本来端末に文字列として表示されない物が表示
      されている事によって位置がずれているだけなので、元の問題を解決すればこれ
      も解決する筈。

    コードを確認してみたら分かった気がする。quote-passthrough によって付加され
    た P が表示されてしまっているのである。そして、端末の入れ子情報が壊れている。
    実際に問題が生じている端末で C-xC-v で端末情報を出力してみた所、どうやら
    screen が三重に入れ子になっていると勘違いしているようである。

    terminal: TERM=screen.xterm-256color wcwidth=14.0-emacs, screen:49900
    (83;49900;0), screen:49900 (83;49900;0), screen:49900 (83;49900;0),
    contra:0 (99;0)

    何故後になってこの様な変な状態になるのか分からないが、ble.sh を reload した
    らちゃんと端末の入れ子状態の情報も正しくなって問題も起こらなくなった。

2022-08-31

  * complete: 'a b c' というファイルがある状態で 'b [TAB] すると変な事になる。

    →今試してみると再現しない。bash-completion をロードしていてもしていなくて
    も問題なく補完される。

  * complete: ~/b/c/スペースを含むファイル[TAB] としても requote されない。

  * complete: 変数名の曖昧補完が効かない。一旦候補を生成したら menu-filter によ
    る曖昧絞り込みはできている。

2022-08-29

  * DEBUG trap についても関数呼び出しの階層を再現する?

    user-handler#{load,has} がそれぞれの文脈で "現在の文脈での handler" を取得
    しようとしているのか、或いは "何れかの文脈で handler があるか" を取得しよう
    としているかをちゃんと区別する必要がある (というか関数を二種類作るべき?)

    また "現在の文脈" を正しく取得できているかどうかについてもちゃんと確認する。

    install-hook については top-level での hook があるかどうかを確認したい。結
    局 trap - DEBUG されない限りは何処かの stackframe で定義されている DEBUG
    trap が top-level に適用されると考えると、何れかの階層の handler があればそ
    れで判定していると思って良い。但し、install-hook については、初期化時に
    user が builtin trap で既に設定しているかどうかを判定する為に用いていて使い
    方が特別である。何れにしても、何処かの階層で既に定義があればユーザーの設定
    した builtin trap は無視するというので良い。[ しかし実はそもそも DEBUG は
    install-hook 内に継承されないので extdebug/functrace が設定されていない限り
    判定できないしその様に条件で弾いている ]

2022-07-10

  * syntax: posix syntax check in posix mode?

    対応が面倒そう。本当にエラーになる訳では無いので普通のエラー着色とは少し異
    なる着色にする?

  * complete: - で始まるファイル名には ./ をつける?

    * コマンドによっては + で始まるファイルについても ./ をつける必要がある事も
      ある。そもそも + で始まるファイル名は普通ではないという事を考えると、+ で
      始まるファイル名についても - で始まるファイル名と同様に一律で ./ をつける
      様にしてしまって良い気がする。

    * './' を前置するという事は遡って書き換えるという事を意味する。どの様に取り
      扱うべきか。

      a うーん。INSERT 時に suffix を付加するのと同じ要領で ./ を挿入するという
        事にする? ./ は shell special characters を含んでいないので quote の状
        態がどうであれ勝手に挿入してしまって良い。

      b オプション名及びファイル名の両方の候補がある場合に menu-complete で両方
        選択肢を表示したい時にどうするのか。という事を考えると CAND の時点で ./
        をつけてしまって独立な二つの候補にする必要がある。という事を考えると元
        より CAND の時点で ./ をつけるべきなのかもしれない。

        然しこれだと実は filter されてしまうのでは?

      c a と b の両方を行うのが良い気がする。曖昧補間 (部分一致) の場合には b
        の方法だと filter されてしまって出て来ないので、最終段階で ./ を挿入す
        る様にすれば良い。一方で、先頭一致の場合にはオプション名候補と区別する
        為に ./ は CAND の時点で付けておく事にする。

    * --prefix=filename の様に生成した場合には --prefix の前に ./ を付加してし
        まわない様に、ちゃんと prefix 部分を認識して戦闘の [-+] 判定を行うべき。

    ble.sh builtin filename generation で ./ を付けるのは良いとして、progcomp
    で生成された - で始まる単語で同名のファイルが存在する場合にどうするか?
    progcomp で生成された物でファイル名に一致する物があった時に、それがオプショ
    ンを意図した物なのか或いはファイル名を意図したものなのかを区別する手段はな
    い。

    a bash-completion の _filedir 等に介入して ./ を付加する? 一方で、これでは
      もっと細かい補間関数で個別に生成している物や、bash-completion ではない設
      定に関しては対応できない。

    b 或いは同名のファイルがある場合には問答無用で ./ を付加する事にする?

  * complete: 空白で終わる alias の対応?

    空白で終わる alias は次の単語の alias 展開も引き起こす。然し一方でコマンド
    さえ確定してしまえば後はそのコマンドの補完によって対応するべきという考え方
    もある。うーん。それでも alias を設定するのはユーザーであり、そのコマンド自
    身ではないと考えるのであれば、やはり ble.sh の側でその辺りを解決して補完を
    呼び出すべきではないだろうか。

2022-07-06

  * complete: func() TAB 及び function func TAB で関数定義を挿入する。

    bash-completion では function func [TAB] でこれに対応しているので。現在は
    function aaa の時 aaa には単語を設置していないが必要があれば登録しても良い。

2022-07-04

  * [保留] debug_xtrace を bash-4.0 以下でも対応する?

    debug_xtrace が bash-3.2 で動いていない。と思ったらそもそも BASH_XTRACEFD
    は bash-4.1 以降の機能だったのだ。bash-4.0 以下では 2 を redirect する事に
    よって実現する? と思ったが 2 は ble.sh が出力するのに使っている気がする。特
    に ble/util/buffer.flush で使っている。更に他にも様々なエラーメッセージが 2
    に出力されるのではないか。という事を考えると 2 を xtrace に使うのは余り良い
    ことではない様な気がする。取り敢えず保留という事にする。

  * ext: trueline と組み合わせた時に問題が起こるとのこと。
    https://github.com/lecramyajiv/Emptydeeds/commit/b57e8354cc350d71c655d93c32112427ec8addda#diff-0a1c1083789380c5f4b4aaebd19b6a4b2431ae808f8b456cf865825cfb93b9dfR2527

2022-06-19

  * 履歴番号を検索やプロンプトで表示しているが、これは history の最初が 1 でな
    い時にはずれるのではないか。後で確認する必要がある気がする。

2022-06-14

  * cygwin: bash --norc, source すると C-xC-v 等の keybinding が動かない
    bash_execute_unix_command のエラーが出る。

    これは元々存在している inputrc か何かが悪さをしている可能性? 然しそうだとし
    ても普通に attach したら問題は生じない。なのでやはり違うのだろうか。

2022-06-02

  * bash-4.4 crash (reported by notmike-5)
    https://github.com/akinomyoga/ble.sh/issues/195

    source した瞬間に crash するという事だろうか?

    一方で別の問題を発見した。bash-completion scp の補完で 4.4 がcrash する。こ
    れは ble.sh なしでも再現する。また、bash-5.0 以降では発生しない。
    bash-4.2..4.4 の全てで再現する。これは後で bash-completion の側で対処が必要。

2022-05-12

  * isearch: 現在行と全く同じ内容の行には一致しないというオプション

2022-03-19

  * 編集文字列に含まれる制御文字の反転表示の可能性

    現在は見た目には区別がつかない。プロンプトシーケンス \w, \W, etc に含まれる
    制御文字については反転の toggle で対処している。

    一方で、現在の実装だと単純に編集文字列に含まれる制御文字の反転状態を変更す
    る事はできない。着色に関係なく制御文字の表現を決めている、つまり地の反転状
    態に関係ない escape sequence を決める必要があるが、地の反転状態が分からなけ
    れば制御文字が終わった位置で正しく反転状態を復元することができなくなる。

    これについてはまた今後必要性を感じた時に実装すれば良い気がする。

2022-03-03

  * 起動時の fork について

    * ble/base/adjust-builtin-wrappers/.assign (2 fork) ... 此処で builtin,
      alias を保存する為に2回に分けて defs=$(...) を実行している。この時点では
      初期化が終わっていないので ble/util/assign は使えない。

      これはそもそも勝手に上書きした builtin や alias を保持する必要があるのか
      という事を考えるとスキップしても良い様な気がする。起動の高速化の為にこう
      いった物を省略するオプションを用意して良い様な気はする。

    * ble/util/msleep/.check-builtin-sleep ... これはロードに失敗した時の事を考
      えて subshell 内部で実行している。

      これも sleep の方法を予め引数等で指定する仕組みを用意しておけばスキップす
      る事は可能である。また builtin sleep に頼り切るのも問題の気がする。という
      か builtin sleep だと C-c が効かない等の問題がある。

      改めて plain Bash に builtin sleep を読み込んで動作を調べてみる。と思った
      が再現しない。というよりそもそも ble.sh をロードしていても bash-5.0 でし
      か再現しない。つまり bash-5.0 & ble.sh の時にだけ bultin sleep 3 で C-c
      に対して即座に実行が中止されない。ble-detach していてもこの問題は発生する。
      plain Bash で直接 enable -f /path/to/sleep sleep して sleep 3 に対して
      C-c した時にはちゃんとすぐに終了する。

    * ble/builtin/bind/read-user-settings/.reconstruct ... これは記録されている
      default bash の binding と、現在の binding を比較してユーザーが設定した
      keybinding を抽出する為に awk を呼び出している。

      これは既存の readline 設定を読み取らない事にすればスキップはできる。実際、
      ble.sh の読み込み時に --noinputrc を指定すればこれは実行されない。

    以上の物は何れもユーザーオプションで省略できる様な機能ではある。然し一方で
    ロードのボトルネックは実は fork ではない。少なくとも Linux では。但し、
    Cygwin では 50ms/fork かかるので 4 fork 省略できるだけで 200ms も時間を短縮
    できるので大きい。

2022-02-20

  * より一般の補完 framework に向けたインターフェイスについて
    https://github.com/rsteube/carapace/issues/431

  * compopt 実装: 現在の実装では "name" や -DEI が与えられた場合には何もせずに
    戻る様になっているが、本来現在の設定を変更するべきなのではないか。また、丁
    度変更対象の補完が現在の補完と一致している時には現在の補完の振る舞いに影響
    を与えるべきなのではないか。これについては実際の Bash の振る舞いを確認する
    必要がある。

  * rsteube の記事
    https://dev.to/rsteube/a-pragmatic-approach-to-shell-completion-4gp0

    filtering を description に対しても適用するという事が書かれている。それは確
    かに便利そうである。現状の実装では対応が難しい様には思われるが。これは fzf
    の様に一旦絞り込み専用の入力欄に移動するなどの事がないと使いにくいだろう。

  * trap (lastarg): 一応 heredoc 等を使えば eval の中から複数行の lastarg を設
    定する事ができるのではないか。他に複数行で、eval されても余分な実行が起こら
    ない様な方法はあるだろうか。不完全な引用符の場合には結局エラーが出力されて
    しまう。

    Ref #D1853

  * [保留] exec: builtin sleep に対して C-c が効かない

    % 現在の実装だと bash-5.0 以下で C-c でループ中に走っている外部コマンドを止
    % めた時に応答がなくなってしまう。bash-5.1 以上では一旦実行が停止するものの
    % 一応応答はする。

    と思ったらこの問題は外部コマンドではなくて builtin sleep を呼び出している時
    特有の問題だった。trap INT を設定しているのは問題なのだろうか。

  * edit: 現在の TRAPDEBUG の枠組みを拡張して try/catch/finally を実装できるのでは
    Ref #D1783

    もしその枠組がちゃんとできるのであれば edit.sh から util.sh に移動する。

2022-02-14

  * 全ての ble.sh session にコマンドを送る機能があれば screen に再 attach した
    時の再調整等に役立つのでは。

    _ble_term_TERM の最初期かもできるし、或いは DISPLAY 環境変数の再設定もでき
    る。チェックの頻度は history-share と同様で良い気がする。

  * ble/builtin/trap DEBUG は関数の入れ子や trace 属性などは考慮していない。こ
    の事によって問題が起こる可能性もある。

2022-02-12

  * highlight: ls -l ~/.c{onfig,a/b}
    ブレース展開の中に / が含まれているとディレクトリパス着色が動かない。

    うーん。そもそも highlight の仕組み的に / が含まれているとどうしたら着色で
    きるか謎という可能性がある? と思ったが恐らくそういう事ではない。何れにして
    も全体を一番最初に一致した PATH に対する色で同じ色で着色する様になっている
    筈。但し、その着色を実行する上で / で分割してから各 segment に対して着色す
    る様になっている為に、brace 展開中に / があると / で分断されてしまって正し
    く着色できないという事になるのだろう。

    ちゃんと対応する為には、"ブレース展開に対して最初の要素で着色をする" のでは
    なくて、ちゃんと各要素に対して着色をするという方向に改める必要があるのかも
    しれない。然し、それは実際の所面倒だし、そこまでする必要があるのかというの
    も謎である。これは優先度は低いがもし実装できたら面白いだろうという事である。

2022-02-08

  * [保留] compat: bind -x 実行後の再描画はプロンプト最後の行以降
    https://lists.gnu.org/archive/html/help-bash/2022-02/msg00023.html
    https://lists.gnu.org/archive/html/help-bash/2022-02/msg00031.html

    どうも bash で試して見た所 に於いてはプロンプトの一番最後の行以降だけが再描
    画の対象らしい。現在の ble.sh の実装だと全体を再描画している。これだと
    help-bash に投稿した様な hack が使えなくなる。

    a Bash と同様に途中から出力する様に調整すれば良い。と思ったが、よく考えたら
      現在の実装では prompt は一気に出力する事になっているので一番最後の行だけ
      出力するという話はない。

    b うーん。その場で clip すれば良いのかもしれない。然しそれは処理として重く
      なる。また、clip した場合には結局描画する時にはカーソルを相対移動させる事
      によってカーソルが本来の位置に戻ってしまう。つまり、hack は結局使えない。

    そもそも hack を使える様にするという発想がおかしいのだとも言える。特に件の
    hack に関しては ps1_final で代用できる。それ以外の目的で描画を乱すとしたら
    それはやはり対応外であるし、もしそういった描画に対する介入を想定しないので
    あれば、結局全体を描画するという現在の振る舞いで特に問題は生じない筈である。

2022-02-05

  * syntax: a=(%{1..10}) の % を '\x' に書き換える時文法構造が破壊 (?)

    $ bash
    $ rep=(%{25,08,0A,2{0..2},24,2{6..9},3B,3C,3E,5C,5E,60,7C})

    として起動した直後に上記の文字列を貼り付けて、それから先頭の % を削除して
    '\x' と入力したら文法構造が壊れてしまった。然し二度と再現しない。問題は '\x
    迄入力した時点で発生していた。もしかすると ' か \ を入力した時点で既におか
    しくなっていたのかもしれない。

2022-02-03

  * キャッシュの判定でファイルを使って判定しているが、よく考えたら現在ロードさ
    れているコードとファイルに含まれているコードが同じとは限らないのではないか。
    もし、現在のシェルの起動時刻よりも比較に使っているファイルのほうが新しい時
    は、ble.sh 自体を reload した方が良いのではないか。と思ったがそれによって失
    われる設定も考えられる。という事から勝手に reload する訳にも行かない。

    起動時刻(というよりble.shロード時刻)を示す一時ファイルを使うという手も考え
    られるが、それだと後になってロードした module の場合には不正確になる。と思っ
    たが、古いコードを使って更新を実行してしまうよりは、新しいコードなのに古い
    情報を更新せずに利用するという位の方が未だましである。

    実はロード時刻は $_ble_base_run/$$.load に既に存在しているのでそれを使えば
    良い。

    検索してみると結構影響のありそうな箇所は沢山ある。一方で具体的にどの様に直
    すのか。load time だけで判定すると毎回キャッシュを更新する事になってしまっ
    て意味がない。(キャッシュが最新でない) & (load time よりも前に元のファイル
    が更新されている) という条件で判定するのが良い気がする。

    * キャッシュが最新でないというのは必須の条件である。そうでなければそもそも
      更新を実行する意味がない。load time が元ファイルより最近の場合にも何も問
      題は生じないので今迄通りに何も気にせずに更新すれば良い。

    * 従って、特に判断が難しいのは (キャッシュ),(LoadTime) > (元ファイル) の場
      合である。更に元ファイルを source した時刻は実は元ファイルよりも後の可能
      性もある。その時にはメモリ上には最新版があるのでそれに従ってキャッシュを
      更新しても問題ない。

    * よく考えたらここで対策をしても問題は生じるのではないか。元々キャッシュファ
      イルが存在しなくて、メモリ上に古い version の関数があって、それに基づいて
      新しくキャッシュを作成した場合、古い version のキャッシュがずっと残ってし
      まう。

      うーん。load time で time stamp を書き換える様にすれば良いのだろうか。

2022-01-23

  * "for ((i=0;i<10;i++)); do sleep 1; done" で C-c すると ble.sh 全体がその場で停止する

    これは外部コマンドを実行中にそのコマンドが SIGINT で終了した場合、trap INT
    に登録されたハンドラーを介さずに即座に実行全体が終了してしまうのが原因であ
    る。

    もしそれがトップレベルのコマンドであれば ERR を用いて捕まえる事はできる。但
    し、それが SIGINT によって引き起こされたものなのか、普通のエラーとして返さ
    れたのかを判定する方法はない。

    更に関数内で実行された場合には ERR でも INT でも捉えられない。RETURN を使っ
    ても捕まえられない。これを解決する方法はない気がする。

2022-01-08

  * mandb: echo のオプションの抽出 (help echo) がおかしい at fc35 vm
    chatoyancy では問題は発生していない

2021-12-22

  * ディレクトリ固有の local commands & aliases を可能にする?

    一方で、勝手に設定をロードする様にしてしまうと怪しいディレクトリに入っただ
    けでそれが有効になってしまうという事が発生する。なので、一旦は enable する
    操作を求めるべきだし、また内容が変更されたらその都度承認を求めるべきである
    (過去に承認したものは hash か或いは実体を記録しておいて再度尋ねはしない様に
    できる)。

    →direnv が丁度同じ事を目的としたプロジェクトの様である。

    2023-01-30 direnv が一体どういう事をしているのかについて調べる → #M0023 に
    纏める事にした。

2021-12-20

  * git-prompt, git-status 等の機能の模倣?

2021-12-18

  * contrib/git: dirty で rps1 が更新された瞬間にカーソル位置がずれた。これは後
    で調べる必要がある。

  * deprecated functions の枠組みを整える。

    散発的に deprecate して行くと毎回設定を変更しなければならず面倒なので、
    version を指定して特定の version 以降になった時に限り初回だけ警告を表示する
    様にするのが良い。

    ((_ble_version>=500)) && ..... と言った具合。

    ? reject: deprecation は version ではなくて独立な番号付を使う可能性?

      →omb において考えていたが、これは特定のバージョンを予め指定するよりは
      deprecation level の様な 1 個ずつ増える整数にするのが良い。というのも、そ
      もそもどの version で完全廃止するのかというのは廃止を決定した瞬間には分か
      らないという事。そして、実際に廃止する瞬間には基本的には全て一度に廃止す
      るのであって、機能によって廃止したり廃止しなかったりという事はない。なの
      で基本的には、新しく廃止をマークする時には次の deprecation level を指定し
      ておいて、deprecation level が上がる時に一斉に廃止するのが良いと思われる。

      一方で、もしかすると緊急で廃止したいという状況が現れるかもしれないので、
      deprecation level は基本的には 100 の倍数にして置いて、細かい廃止を実行し
      たい時に限って 1 ずつ上げる様にするというのも手である。と思ったがその様に
      考えると結局それは _ble_version と同じになるのではないかという気もする。
      但し、基本的に廃止等は master でしか起こらない気がするので patch level と
      deprecation level に関してはずれが生じるだろう。

      また minor version とは無関係に廃止するという事があるのかも分からない。と
      いう事を考えるとやはりその意味に於いても ble.sh に於いては deprecation
      level と version は一致させて良いのではないか。という気がしてきた。

  * complete: FIGNORE と -o filenames

    どうやら元の bash では -o filenames が指定された時にのみ FIGNORE が使われる
    様である。一方で、現在の ble.sh では FIGNORE が設定されている時には強制的に
    fignore が実行される様になっている気がする。と思ったらこれは shopt -s
    force_fignore の設定を参照しての事だった。よく分からないのは bash は
    force_fignore が設定されていても、-o filenames が指定されていなければ
    FIGNORE が有効にならない様だという事。

    * FIGNORE で全て候補が消えた場合には FIGNORE を無効化して全て採択するべきで
      は? と思ったが元の bash ではその様な取り扱いはしていない。

    * Note: bash FIGNORE は glob は解釈しない。bash FIGNORE はそれが実際には存
      在しないファイル名だったとしても、FIGNORE に一致すれば候補削除する。bash
      FIGNORE は候補が FIGNORE で全滅してもそのまま。bash FIGNORE は単一候補だっ
      た時にも FIGNORE を適用して候補を消す。

2021-12-14

  * compat: RLogin で ble-detach した後に modifyOtherKeys の状態がおかしい。
    bash --norc してもおかしい。RLogin である事は検出できている。

  * compat: terminator で status_line で表示が崩れる
    →これは今確認した所再現しない。terminator ではなく terminology の可能性?
    或いは古い vte の問題だった可能性もあるかもしれない。

  * compat: mlterm 起動時に表示が乱れる with statusline

    →これは単純に初期の char_width_mode,char_width_version が一致していない事
    による問題だった。始めから east にしておけば乱れは生じないという事は確かめ
    た。然し、auto で幅を判定する迄の表示の乱れは一般の問題ではないだろうか。

    乱れを最小限にするには文字幅を大きめに取るという意味で east で始めるという
    手もあるかもしれないが、実際には west の端末の方が多いという事を考えると別
    の問題が出てくる可能性がある。また、CPR に応答しない端末の場合ずっと east
    という事になってしまって問題である。起動して暫くは east にしてそれから west
    になるという様な感じの物を auto で判定中の幅にするべきだろうか?

  * C-backspace の問題 (端末自動判定?)
    https://github.com/akinomyoga/ble.sh/issues/94
    https://github.com/akinomyoga/ble.sh/issues/104
    https://github.com/msys2/MSYS2-packages/pull/2490
    https://github.com/microsoft/terminal/issues/755

    以前に色々の端末の動作を調べたと思ったが記録が全く残っていない。辛うじて上
    記の MSYS2 にどのようなパターンがあったかが記されているが、それぞれどの端末
    がどう振る舞っていたかの情報はない。改めて調べる。→ wiki にまとめた。

    うーん。^? と ^H が異なる形に bind されているという事は。。。どうしようもな
    い。既定では両方とも backspace だと思って置くしかない。ユーザーが自分で設定
    をする時にちゃんと判定するのが良い。

    もしくは端末を自動的に判定して C-h, C-_, etc を C-BS に置き換える設定を行う
    という事も考えられる。

2021-12-11

  * declare の引数チェックをもっと真面目に実装する。chroma のインターフェイス
    設計の足がかりにする。

    * wattr=- (未着色) の時にのみ着色しているが、実際には一つでも未着色があった
     らそれ以降の引数に対して与える影響を考慮に入れなければならない。但し、これ
     を実行すると毎回ファイル名着色が全て計算されるなどの様な形になりとても遅く
     なると思われるので、未だ実装しない。

      これは一般の問題なので別項目で議論するべき気がする。mandb_opts 等を用いて
      指定する可能性。

    * declare: -f, -F が含まれる場合には関数名として任意の名前を含む事ができる。
      というかオプション名も含む事ができる? (declare -F -f とした時の解釈はどちら
      になるのだろうか?)

    * 変数代入の形式をしていない引数に関しては中身によってOKかもしれないし駄目
      かもしれない。

  * refactor: highlight-variable というインターフェイスを作る。

    と、思ったが quote 等も考えるとそういった関数を提供する事に意味があるのか
    分からなくなってくる。先に quote 除去した時の対応関係について解決する枠組
    みが必要になるのではないかという気もする。

  * cmdspec: cd 関連の cmdinfo は core-cmdspec ではなくて contrib/cmdspec/* 辺
    りに移動する?

  * PROMPT_COMMAND / trap DEBUG で問題が起こる? (found by rashad-moves)
    https://github.com/rashad-moves/HomeConfigurationFiles/commit/efbac4153fd5021f1bc00d42c618fd9d6f4090b9

    2022-03-03 うーん。どうもこの問題は以下で報告されている物と同じの気がする。
    timer_show が含まれている。
    https://github.com/akinomyoga/ble.sh/issues/176

    実行時間の表示について Q&A にでも書いておくべきだろうか。

  * complete (source:rhs): 変数名依存の補完に対応しても良いのでは。

  * complete: ARGEX (eval 文脈) の補完

    現在は "variable:=, command:D, file" で生成しているが、本来は一番先頭の引数
    を元にして argument (including progcomp, etc.) を呼び出すべきなのではないか。

  * complete: [[ の中の文法も考慮した補完。これは [[ の中の文法にちゃんと対応し
    た後で考える事の気がする。

2021-12-06

  * mandb: コマンドの名称を抽出して保持して置けば binary の呼び出し時に使える。
    dnf や apt 等に問い合わせても良いのかもしれない。或いは、含まれているパッケー
    ジを見るという手もある。

    然し各コマンドについて man 等を呼び出すのは高価である。

    rpm, dnf でファイルの所属する package と含まれるファイルを抽出するには。
    https://linux-audit.com/determine-file-and-related-package/

    $ dnf -C repoquery --installed -f /usr/bin/git-lfs --qf '%{summary}'

    等の様にすれば良い。

    * resolved: しかしこれを呼び出すと package 一覧のダウンロード等を実行し始め
      るので問題がある気がする。或いは、更新を無効化した状態で呼び出す事ができ
      るだろうか →どうやら dnf -C とオプションを指定する事で cache から情報を
      取得できる様だ。

    * background で生成するにしても時間がかかるので、複数の bash session で同時
      に更新が実行されない様に注意が必要である。*.part.$$ に書き込んで、その後
      でそれを mv するという形にすると良い。更に、他の session が既に生成を試み
      ている場合には、background 生成を止める事にする。

    うーん。以下の結果を加工すれば一挙に全てのコマンドについて情報を抜き出せるのでは。
       $ dnf -C repoquery --installed --whatprovides /usr/bin/\* --nvr
       $ LANG=C dnf -C provides -q /usr/bin/\*

    * man -f ...

      というか man -s 1:6:8 -f command... を呼び出せばよいらしい。

      * linux では man -s 1:6:8 -f command 等として結果を得られる。whatis -s
        1:6:8 command としても同じ出力結果である。というか whatis 自体が man に
        よって実装されている疑惑 (-s オプションなどがあるので)。

      * cygwin で実行したら駄目だった。whatis sed awk とした時と全く同じ出力結
        果になったので、whatis を使っているのだろう。

      * solaris では man -f sed は表示されるが、man -f sed awk や man -f sed -f
        awk 等の様にして複数の結果を取得しようとすると何も表示されなくなる。1行
        目は空行で、2行目に man ファイルの情報があって、3行目にようやく説明が表
        示される。

      * minix では man -f sed で whatis を間接的に呼び出そうとしている。そして
        whatis はデータベースがない等の文句を言って動かない。

      * freebsd でも whatis を呼び出している様だ。警告が出ているが、複数指定し
        たら複数の説明をちゃんと出力してくれる。, 区切りで一行に複数の名称を出
        す事もある。例えば man -f awk とすると "awk, nawk (1) - <説明>" という
        具合の行を出力する。

  * complete: 文字列引数の中にファイル名を含めたい事もあるのでは。つまり "add
    a.sh" の様な。特に complete -m '...' の編集で欲しくなる。

  * bash-completion: awk - で long option だけが生成される。調べてみると
    complete -F _longopt が割り当てられているコマンドについては全てこのパターン
    の様である。

  * bash-completion: 空文字列に対して最初からオプションも生成して欲しい。
    そうしないと絞り込みの際に都合が悪い。

    うーん。bash-completion や他の補完の事を考えると一文字目に - が入力された時
    点で候補を再生成するべきの気がする。或いは - から始まる候補も追加する? 追加
    する場合には以前にあった物と重複する候補を削除しなければならない事に注意する。

  * syntax: for $(echo hello) に対しては着色しない。もしくはエラーとする。

    これは heredoc 単語と同様の問題である。因みに heredoc の単語に $() を含めた
    場合には、終端位置判定が正しくできなくなっている。普通に入力すると終端位置
    を逃す。終端を書いてから heredoc の中身を編集すると位置を正しく特定できる。

2021-11-23

  * kitty shell-integration (requested by kovidgoyal)
    https://github.com/akinomyoga/ble.sh/issues/110#issuecomment-976182311
    https://github.com/kovidgoyal/kitty/issues/3948

    | [Check default shell-integration]
    |
    | * ok: 前のコマンドの内容を less で見る: C-S-g
    |
    |   vim-airline を表示している時に問題が生じる。中途半端に切れたりする。
    |
    | * ok: プロンプト移動(scrollback): C-S-{z,x}
    |
    | * マウスによるプロンプト内の移動:
    |
    |   遅い、vi_nmap の中にいると変な事になる。うーん。これはまた後で確認する。
    |
    | * xterm-title で現在ディレクトリを表示する。
    |
    |   これは別に何か新しい機能という訳でもないだろう。敢えて ble.sh で対応する
    |   とするのであれば、bleopt prompt_xterm_title を用いるぐらいの事である。
    |
    | * これも特に変な事はない。但し、ble.sh 側でユーザーが何か設定している場合に
    |   は、kitty integration の設定は off にすれば良い。
    |
    | * ok: winch glitch の解決。これは綺麗に動いている。
    |
    | * Sophisticated completion for the kitty command in the shell. これは
    |   core-complete の領分であるが何か特別な事が起こるとも思われない。
    |
    | 結局 vim-airline を実行した事による問題点は C-S-g で閲覧する内容の切り取り
    | 以外では特に問題になっていない様に見える。以下の三点を報告する。
    |
    | x subshell の中でちゃんと動作していない。従って tmux の内部でも動作しない。
    |
    | x 複数行コマンド編集時に vi_nmap で位置がずれる。他の keymap では問題は生じ
    |   ない。
    |
    | x vim-airline を使っていると時々コマンド内容が切れる

    最初の項目については意図的なのだという返信が来た。だとしても tmux で空にな
    るというのは変である。後で patch を作っても良い。問題にしているのは
    invasive という事だったので SHLVL, SUBSHELL, $- 辺りを参照して本当に kitty
    の中にいる時にだけ有効にするというのが良いのかもしれない。(と思ったが、元々
    の kitty.bash でも kitty かどうかをチェックしているのではないか?)

    2つ目の項目に関しては仕方のない制限だという事。up/down を有効化する
    sequence について提案した所、patch が送られてきたら見るとの事。これは忙しい
    ので今は未だ。

    3つ目は調査中。

2021-11-21

  * complete: インラインでヘルプ・次に期待する引数の種類を表示するという話
    https://www.reddit.com/r/bash/comments/qrm3s2/hints_for_argument_types_in_bash/
    https://github.com/fish-shell/fish-shell/issues/2201

  * やはりメモリを使うという事は明記するべきである。

    bash-3.2 16MB 19MB
    bash-4.3 26MB 31MB
    bash-5.1 33MB 40MB

2021-11-05

  * vim の :term 内部で実行すると振る舞いが変だ

    * 先ず最初のロード時に行が一行ずれる。それ以降は発生しない。modifyOtherKeys
      もしくは文字幅判定の為に出力している何かが問題を起こしているのかもしれな
      い。

      →どうもこのずれは status_line に関係している様だ。

    * うーん vim :term の中だと NUL (C-@, C-SP) を入力することができない。C-wは
      vim の側での操作に使われている様だ。これらは ble.sh の外側でも同様である
      事から、ble.sh の問題ではない。寧ろ vim term の仕様と見るべきである。

  * bash-5.2 で builtin bind -Xs を観察するとところどころ \000 が余分に挿入され
    ている。これは何か。bash-5.1 では問題はない。

2021-10-26

  * winch: Window サイズを変化した時に menu の座標計算がずれる
    (menu_style=dense)そもそも resize した時点で menu の再配置を実行しなければ
    ならない筈である。

    或いはサイズが変わった時には menu-complete はキャンセルするべきなのではない
    か? 特に大量の WINCH を送ってくる端末があって、大量のメニュー項目の後ろの方
    のページを表示しているとすると、ほぼフリーズした様な形になってしまう。

    或いは次に TAB を押して他の項目を移動しようとした時点で改めて配置計算を実行
    する? 例えば、WINCH を受け取った時点では info を単に非表示にしておいて、次
    にメニューに対して表示の変更等を行う必要が生じた時に改めて計算を実行する。

    2022-03-04 そもそも ble/edit/info 自体が WINCH の時に再計算するべきなのでは
    ないか。特に高さだけでなく幅についても考えて再計算しないと内容が乱れてしま
    う。

  * スタートしてから数秒間は user input detection for C-m を off にした方が良い
    のでは。スタートした直後にペーストを実行する事があるとは思われない…。

    と思ったが bash を含む大量のテキストを入力した場合にどうなるのかというのは
    疑問である。とは言いつつも、その場合には親シェルの側でちゃんと paste
    detection ができているべきではないかという気がする。

2021-10-04

  * fzf を直接読み込んだ時に動かない問題について
    https://github.com/akinomyoga/ble.sh/issues/126

    ble-update を実行すると動く様になるが最初から source ble.sh すると動かない。
    ble-import contrib/fzf-key-bindings をすると動く様になる。

    というか改めて説明を読むが一体どういう操作をしようとして問題が生じているの
    か謎である。C-r, C-s をしようとした時に問題が生じているという事だろうか。現
    在の実装では補完については contrib/fzf を自動でロードする様にしている。
    widget に関しては contrib/fzf-key-bindings 経由で呼び出さなければ駄目である。

    うーん。自動的に検出して補正する様にしようと考えたがそんなに単純ではない様
    に見える。

    a 例えば bind する瞬間に fzf 関連であるかどうかを調べて fzf 関連であると分
      かった時点で fzf-key-bindings を呼び出すという方法。

      x ユーザーが実行したい binding が fzf-key-bindings と同じかどうか分からな
        い。ユーザーが自分で調整して binding のキーを変更しているかもしれない。
        この場合には勝手に fzf-key-bindings を読んでしまうとユーザーの予期しな
        い binding が定義される事になり問題である。

        一方で、諸々の関数は fzf/shell/key-bindings.bash に定義されているのだか
        ら、そこに含まれている関数を使おうとしている時点で其処にある binding が
        そのまま使われていると仮定して良いのではないか。もし、ユーザーが
        fzf/shell/key-bindings.bash を自分でコピー・編集して使っているのだとし
        たら、やはり contrib/fzf-key-bindings.bash についても同様に自分の設定に
        合わせて編集するべきなのではないか。

      o bind で -x に fzf 関連を指定した場合に関数の中身を差し替える等の事をし
        ようとしても、例えば inputrc キャッシュで初期化を誘導する等の事までは
        キャッシュできない気がする。

        →これに関しては fzf-key-bindings では関数の中身を差し替えるのではなく
        て、別名の関数を定義してそれに差し替える様にして、更にその別名の関数に
        ついての autoload を def.sh 辺りに記述する事にすれば良い。

        x この方法だと __fzf_cd__ や __fzf_history__ をユーザーが直接自分で
        bind した時に対策できない。

    b 或いは、bind -x を実行する時にコマンド名が __fzf_history__ または
      fzf-file-widget だった場合にこれらの関数を上書きするという手法。

      x この方法だと __fzf_cd__ の検出ができない。__fzf_cd__ は、
        fzf/shell/key-bindings.bash だとマクロ経由で呼び出される様になっている。
        つまり bind -x ではないという事。かと言って accept-line に作用して、コ
        マンド実行前にコマンド内容を調べて関数を上書きするというのも非現実的な
        気がする。

      うーん。やっぱり現状の様に設定するべきなのではないだろうか。

2021-09-28

  * fast-syntax-highlighting

    https://www.reddit.com/r/zsh/comments/oyege0/is_completionaware_syntax_highlighting_possible/
    https://github.com/zdharma/fast-syntax-highlighting/tree/master/%E2%86%92chroma
    https://github.com/Valodim/zsh-capture-completion

    どうやら programmable highlighting に相当する機能は
    fast-syntax-highlighting で既に実装されていて "chroma" と呼ばれているらしい。
    然し実のところそれ程沢山の実装がある訳でもない。

    他に zsh-capture-completion というモジュールに含まれる関数で capture.zsh
    'command' を実行すると 'command[TAB]' とした時の補完結果を取得できるらしい。
    これは ble.sh の上で作成する事も可能である。補完機能のテストで使うのに便利
    な気がする。

    bash-completion のテストをコピーできたら良い気がする…。でも全て python で
    定義されているというのは難点である。うーん。結局、その場で補完を実行する機
    能を実装したとしても使う機会がないからテストされずに残って意味のない機能に
    なりそうな気がする。

  * https://www.reddit.com/r/commandline/comments/pv1fm8/what_are_the_main_advantages_of_the_various_shells/

    fish の便利な機能について紹介している。

    * M-{right,left} でディレクトリ移動。これについては異なる keybinding で提供しても良い気がする。

      iswitchb の如く C-x C-b 等で探索するのもありではないか?
      その際には menu の機能を有効活用できる気がする。

    * fish の Abbreviations の振る舞いが気になる。
      zsh の zsh-abbr も気になる。

    然し、実際に ble.sh をロードさせてテストするというのは有効の気がする。

  * menu: C-x C-d で今迄に訪れたディレクトリの一覧。

    iswitchb と同様に絞り込みをしたいが入力した文字列は何処に表示するのが良いのか。
    panel に表示するのが良いだろうか。或いは、そもそも表示しなくても良いのかもしれない。
    何れにせよ太字で表示されるのであるから。

    太字ではなくてより強調した形にしても良いのかもしれない。これは face 経由で
    設定できる様にするのが良い様な気がする。現在は太字固定になっているが。

  * menu: C-x C-j で job 制御用の TUI メニューを表示しても良いのかもしれないとも思う。

2021-09-26

  * bash-5.2: array が sparse でない ./configure option が追加された。

    もしかすると sparse arrays に declare -gA を指定する必要があるかもしれない。
    sparse かつ ordered な配列については簡単な workaround は存在しない。唯、そ
    の様な配列を実際に使っているかは分からない。なければ気にしなくて良い。

2021-09-22

  * edit: 複数行モードの時は prior/next でページ移動?

  * plug: git clone 用の判定:

    これは

    $ grep -q '^github\.com' ~/.ssh/known_hosts
    $ grep -qEi '[[:space:]]*HostName[[:space:]]+([^[:space:]]+[[:space:]]+)*github\.com' ~/.ssh/config

  * 実は local rex=... [[ a =~ $rex ]] は関数に纏めたら良いのでは。

    速度的にはどうだろうと思って比較してみると4倍位遅くなる。もしくは 0.014ms
    だけ遅くなる。70回の評価で1ms, 1400回の評価で20ms, 7000回の評価で100msの差
    が出る。

    $ ble-measure "local rex=':point=([^:]*):'; [[ alpha:beta:point=end:b = \$rex ]]"
         3.618 usec/eval
    $ function ble/regex#match { [[ $1 =~ $2 ]]; }
    $ ble-measure "ble/regex#match alpha:beta:point=end:b ':point=([^:]*):'"
        17.402 usec/eval

    うーん。一般的には気にする速度低下ではないが、構文解析などの中心部では控え
    た方が良いかもしれないというぐらいである。通常の場所ではどんどん使って問題
    ないのではないか。

    →検索してみたが実は意外とそんなに沢山あるという訳でもない様だ。少しずつ置
    き換えていけば数日で終わるぐらいの箇所しか無い。概算で140箇所程度である。然
    し、そもそも其処までして置き換える必要があるのかという疑問もある。現状で動
    いているのであればそれで良いのではないか。一応他のシェルに移植する時に一括
    で動作を変更するのが楽という可能性はなくはない。

    2021-12-11 ble/string#match という関数名で追加した。

2021-09-15

  * haiku: ble/builtin/bind/.reconstruct-user-settings の gawk が無限ループになっ
    ている? 或いは滅茶苦茶遅くなっている。gawk 4.2 である。bash-4.4.23 から呼び
    出している。変な事が起こる様な余地はない様な気がするが…或いは正規表現エン
    ジンなどが壊れているという事なのかもしれない。

  * solaris: ble-bind を bashrc 内部で呼び出した時点で未だ attach していないの
    に色々と info を表示してしまっている。
    $_ble_base_cache/decode.cmap.gdict.*.dump を削除した時に再現する。

  * grapheme: SpacingMark, Prepend の幅は一体どうなっているのだろうか [#T0008]

    現在の実装では幅を全く考慮に入れていないが、入れるべきの気がする。c2w で
    combining に対して 0 を返す様にしたら Extend や Prepend に対しても c2w で値
    を計算して加算する様にすれば良いだろうか。然し、絵文字の Emoji_Modifier な
    ど組み合わせた時と単体の時で幅の異なる物も存在する。

2021-09-06

  * menu: メニューの詳細表示を toggle できる様にするべきではないか。

    表示するか表示しないか完全に固定するのは微妙な気がする。

    後、desc-raw しか実際には使わない様な気がする。二種類の表示方法を用意したと
    しても、そもそも説明を生成する側で二種類を分けて生成する訳にも行かないので、
    どちらかに統一するべきではないか。速度が気になるというのはあるが、もしテキ
    ストだと解釈するとしても、全角文字などが含まれる場合には結局位置計算は省略
    できない。逆に ascii 文字だけで構成されているのであれば esc を解釈するとし
    てもそんなに速度低下なく処理する事ができる。

    表示の toggle は各メニューが表示される度に行うか或いは一回変更したら暫くそ
    の設定を保持するか。ユーザーの指定した設定を既定値として各 menu が表示され
    る度に toggle を行うという事を考えたがそれは如何にも面倒である。それよりは
    toggle は永続的な変更を引き起こすとした方が分かりやすい様な気がする。その場
    合には、bleopt の設定を永続的に設定してしまっても良いのではないか。

    然し、それだと desc モードになっている時に align 等を設定した時にどの様に振
    る舞えば良いのか分からない。一つの手は一旦完全に toggle 状態を clear して、
    改めて既定の style として align を設定するというのが自然な気がする。

    * toggle するとしたらその表示切り替えのキーボード操作はどうするのか。C-m と
      思ったがそれだと確定と同じ。C-d だと削除みたいな感じがする。insert は確か
      に toggle だがやはり直感的ではない気がする。 ScrLk や CapsLock NumLock 等
      も同様である (というか OS 側のキーボードの状態が変わってしまったりして大
      変である)。

      後、実際に menu-complete に入らなくても切り替えられた方が良い様な気がする。
      その場合には他と被らない様な操作にする必要がある。他で使われていない
      single-key の操作はそうそう残っていない気がするし、残っているとしてもそれ
      をたかが menu toggle に割り当てるべきなのかという問題もある。或いは、2
      keys による操作としても良い様な気はしている。

      例えば C-x | 等。特に C-x は menu-complete やその他の complete に色々割り
      当てているから丁度良い気がする。

      - "C-x d" は emacs では dired,
      - "C-x ?" は emacs では keybinding 一覧,
      - "C-x h" は emacs では全選択に割り当てられている。
      - "C-x |" は emacs では割り当てがない。
      - "C-x C-h" は前の文を削除する。
      - "C-x C-t" は行の入れ替え。

      若干操作しにくい気がするが、うーん。一旦 menu-complete に入ってしまえば
      "|" で入力できるようにすれば良いと思ったが…普通に "|" を入力したいという
      時があるのでそれは駄目だ。やはり C-? の形の方が良い。

  * menu: preview 機能をつけても良い。preview に表示する中身は候補の種類に応じて色々。

    そもそも desc の内容自体その場に表示するのではなくて preview 的な小さな窓の中に
    選択した時にだけ表示するという形式でも良いのではないかという気がする。

2021-09-02

  * 改めて確認した所また Windows Terminal で動かなくなっている

    調べると Cygwin 経由で接続した時だけの問題の様である。
    これは Cygwin の側の conpty の副作用という可能性もある。
    というか最新版の Cygwin で直っている可能性もある。

    ? wt を path に加えて実行もできるのにも関わらず構文着色で赤になっている。不思議だ。
      type wt とするとちゃんと成功する。

    ? Cygwin から起動した時とスタートメニューから起動した時で、Windows
      Terminal の中で Cygwin タブを開いた時のプロンプトに含まれるシー
      ケンスが異なっている気がする。と思ったが、これは Cygwin の
      screen の中から起動すると、Windows Terminal の中の Cygwin も
      screen の中にいると勘違いするからであろう。気にしなくて良い。

      取り敢えず環境変数が継承される事は確認したし、
      CYGWIN=disable_pcon を指定していても指定していなくても Windows
      Termianl - Cygwin では座標計算がずれるという事が確認できた。やは
      り pcon は関係ないのかもしれない。

  * 起動時間を計測しているようだ

    ble.sh でかなり時間がかかっている様だという事。

    * ble.sh は background 処理を行う。特に ble-attach の末尾で行っている気がす
      る。なので、ユーザーが何も入力しない限り background 処理を完全に終えるま
      で ble-attach から抜けないのではないか。逆に、ユーザーが何か入力している
      時にはより早く初期化できるのではないか。と思って試してみたがそうでもない。
      というか殆ど変化がない。どういう事だろうか。

      ユーザー入力の検出ができていない? 或いはそもそも background 処理は最初は
      行っていない? 後者の様な気もするが後で確認する必要がある。

      letsnote でも試してみたがやはりユーザー入力があっても殆ど変化はない。
      GNU/LInux でも Cygwin でも同様にユーザー入力があっても変化はない様だ。

      実装を確認してみると確かに ble-attach の末尾で .tail を呼び出してい
      て、.tail は idle.do を呼び出している。うーん。不思議だ。或いは .tail の
      前後だけに注目すればより短くなっているかもしれない。

    * MSYS2 環境では ble.sh のロード及び attach にはかなり時間がかかる様だ。と
      いうかこれは fork の回数に直結しているという気もする。MSYS2 で調べると
      spawn が 10/s だった。

      一方で Cygwin だと 23/s 程度である。実は Cygwin の方が軽量である。或いは
      最適化が施されていると見るべきか。或いは whitelite に入れていただろうか。

2021-08-31

  * msys2 での ble-update で変な動きをした。。

2021-08-30

  * complete: overridden builtin 及び他の framework

    | * https://github.com/csdvrx/bash-timestamping-sqlite
    |
    |   この実装では history コマンドを上書きしている様な気がする。然し同時に
    |   ble.sh との併用を推奨している。うーん。この時 ble.sh が history を上書きす
    |   る、もしくはble.sh の history がこの枠組に上書きされるという事があったら何
    |   が起こるのだろうか。何か悪い事が起きる気がする。
    |   ble/function#push とかを使って何とかすれば良いのだろうか。
    |   その場合にはこの interface を固定する必要がある。
    |
    |   と思って実際にコードを確認したが history を上書きしている訳でもない様だ。

    何れにしてもこれは注意点として README に記述しておくべきなのではないか。

  * complete: そもそも遡って書き換える補完候補と純粋な意味での補完候補は区別す
    るべきなのかもしれない。TAB 補完では後者に基づいて補完を実行するが、メニュー
    の表示には両方を表示するという手がある。その場合にはメニューの内部で
    section を分けると良いだろうか。ページング等をちゃんと考慮に入れる必要があ
    る。

2021-08-29

  * bashrc に直接設定を書く方法についても説明する。

    但しこの場合には ble-reload をした時に設定が消えるという事に注意する。→うー
    ん。この様な面倒な事が起こるのであればやはり記述しないほうが良いのではない
    か。

    よく考えてみたら source ble.sh と ble-attach の間に書いた bind にも同様の問
    題があるのではないか? と思ったが、ble-attach よりも前に書いているのであれば
    ちゃんと readline の側にも反映されている筈で問題はない筈。

    ユーザーがコマンドラインから設定した設定は消えてなくなってしまうという事に
    注意する。これらを記録して後で拾える様にするという手もあるかもしれないとは
    思う。

2021-08-26

  * CPU 100% in macOS (reported by killermoehre)
    https://github.com/akinomyoga/ble.sh/issues/131

    CPU 100% になっている時に同時に gawk が待機している様である。
    100% になっている時の gawk の引数について尋ねたら返答が来た。

    二つの bash について異なる gawk が呼び出されている。前者は
    ble/history:bash/resolve-multiline/.awk で、後者は
    ble/history:bash/load/.background-initialize である。両方とも
    history に関係している。

    Q というかどちらの bash が CPU 100% になっているのだろうか。或いは両方?

    Q bash が起動した時に暫く 100% になるのか起動した後もずっと 100% のままなの
      か。もし暫くしたら収まるのだとしたらどれぐらいの間 100% でいるのだろうか。
      これがそんなに長くなければ少なくとも見た目の動作に影響がない限りはそのま
      まにしておいても良い様な気がする。

    Q CPU 100% になっている間 bash は応答するだろうか。応答するとしたら

    Q いつでも現象は再現するだろうか。或いは確率的に発生するだろうか。

    ----

    取り敢えずやはり巨大な history が問題であるという事までは分かった。
    自分の手許の linux では同じぐらいの巨大な history を用意したとしても
    そんなに遅くはない。

    ? 一方で向こうの報告によると builtin history を実行しているプロセスが重いと
      いうことの様である。自分の手許で確認しようとしているがすぐに処理が終わっ
      てしまうので確認できない。

    * 終了時にもかなり待たされる。

      終了時の nawk が滅茶苦茶遅くなる。gawk だと遅くないとかあるのだろうか。と
      思って改めて観察してみると最初に bash が 100% になって、その次に nawk が
      100% になるという具合に処理が進行している。

      ble/builtin/history/.write で時間を消費している。

      A:1630043056.816931
      B:1630043056.936962 0.12s ... history/.get-min
      C:1630043056.942516 0.06s ... history/.get-max
      D:1630043079.487224 13s ... builtin history >> file
      E:1630043092.465937 13s ... nawk の処理

    Q hang と slow は区別しているのだろうか。自分的には hang というのは待っても
      絶対に終わらないという意味である。然し、向こうは有限時間で終わるという事
      を確認しているのにも関わらず hang と言っている可能性がある。よく分からな
      い。

2021-08-23

  * bash-4.2 では [[ ${arr[*]} == *" 2 "* ]] (where arr=(1 2 '')) が駄目

    一応該当しそうな物を検索すると以下の様な物がある。
    何れも空白には関係なさそうなので問題は起こらなそうな気がする。

    $ grc '\[\[ \$\{.*\[[*@]\].*\} [!=]= .* \]\]'
    ./ble.pp:145:    { ((${#BASH_SOURCE[@]})) && [[ ${BASH_SOURCE[${#BASH_SOURCE[@]}-1]} == *bashrc ]]; } ||
    ./src/decode.sh:3632:    [[ ${keys[*]} != "$bind_keys" ]] &&

2021-07-14

  * bash-it によるプロンプト設定が prompt attach で反映されない。

    PROMPT_COMMAND 経由で PS1 を設定していると反映されないのだろうかと思ったが
    そういう訳でもない様だ。

    powerline-multiline で発生するとの事だが再現しない。
    というか powerline-multiline で発生する固有の問題なのか、
    それとも他の theme でも動作するのかの情報についても書いていない。

2021-07-13

  * auto-menu: 一旦 (no items) が表示されるとそれ以降 auto-menu が動作しない

    auto-menu が有効になっている時に一旦 (no items) が表示されるとそれがそのま
    まになって二度と auto-menu が起動しなくなる。

    またこの時に C-l で再描画すると info に何も表示されなくなる。実はこれは
    menu が表示されている時には常に再現する問題である。

2021-06-21

  * auto-menu が有効になっている時に複数行編集で座標が変になる

    2021-07-13 今試しても問題は再現しない。

    2021-07-18 再現した。履歴に複数行の項目が含まれている時に、その履歴が呼び出
    されると問題が発生する。ble-bind ... と入力した時に発生した。というかこれは
    本当に auto-menu の問題なのかどうか分からない。取り敢えず、textmap を再確認
    する必要がある気がする。ずれの量的にも前回の textmap の時と似たような振る舞
    いの様に見える。

    2021-07-19 chatoyancy の上では再現しない? vaiio2016 の上でも再現しない。

2021-06-18

  * grapheme: ble/canvas/trace の lc lg の grapheme cluster 対応について
    Ref #D1619

    基底文字だけを指定しても、最後の Extend を指定しても端末によって左の書記素
    クラスターが破壊される可能性がある。書記素クラスター全体で出力する必要があ
    る。lc lg の組ではなくて lcs lw lg の組で結果を返さなければならない。lc lg
    はデバグ用なので其処まで配慮する意義は薄い。

    そもそも lc lg の枠組みはそろそろ削除しても良いのではないかという気すらする。

  * grapheme: 私用文字で置き換える事により書記素クラスター単位での編集を可能にする可能性
    Ref #D1619

    現在の所その必要性は限りなく低いと考えられる。

  * grapheme: Unicode version 毎の振る舞いの違い?
    Ref #D1619

    emoji_version と同様に grapheme_cluster についても version 毎の違いを考えて
    も良いのかもしれない。

  * emoji: Emoji 対応状況自動判定
    Ref #D1619

    | これも自動検出の対象にしても良いのでは。という気がする。というかそうする
    | べきである。所で Zle は実は内部的にそういう事をしている可能性がある。
    |
    | と思ったが端末によって unqualified の取り扱いもばらばらだろうし ZWJ に対
    | 応しているのかどうかも不明だし、という事を考えていくと単に
    | legacy/extended を区別すれば良いという訳ではない。場合によっては ZWJ シー
    | ケンスに対応しているかどうかと言ったフラグまで管理しなければならないかも
    | しれない。とは言いつつ実際にそのように振る舞う端末が存在するのかどうかも
    | 不明である。なので、これは実際の端末の振る舞いを整理しながら考える必要が
    | ある。
    |
    | 端末ごとの絵文字の振る舞いについて調べる必要がある気がする。kitty/vte は
    | unqualified はテキスト表示で EPVS によって絵文字になる。RLogin は
    | unqualified は半角で表示される? 幅は VS で変化しないように見える。mintty
    | は試した限りでは Emoji に対応していない。既定で off になっているという事
    | だろうか。
    |
    | 以下の振る舞いも端末の対応状況に応じて実装する。
    |
    | * EPVS の時には emoji_width または 2 になる様にしている。然し、絵文字の表示
    |   ができない端末では 2 にせずに普通の文字として求めた方が良い可能性もある。

    * legacy vs extended
    * unqualified をどう取り扱うか。EPVS 及び TPVS がどう作用するか
    * ZWJ sequence に対応しているかどうか

    現実の端末に於いてそれぞれどう対応されているか、そして三つの対応状況の組み
    合わせはどうなっているかについても調べる必要がある。

  * test: ログを何処かに保存する機能? その場合には着色等は除外する

  * syntax_debug の時にコマンド実行すると実行位置が変だ

    うーん。info　を削除する時のシーケンスが間違っている? menu の表示時には何も
    問題がない。menu に関しては消去してから実行するからだろうか。或いは、変なタ
    イミングで info が更新されて info が表示されてはいけないタイミングで表示さ
    れているという事だろうか。

  * progcomp の出力に関する議論 (reported by oc1024)
    https://github.com/akinomyoga/ble.sh/issues/121

    うーん。どうするのが良いのか微妙。Bash と同じ様に動作するべきなのか、或いは
    出力を抑制するべきなのか。関連する議論が幾つかあった様な気がする。というか
    最近抑制する様に変更した様な気がするが何故再発しているのだろう。実際に確認
    してみた所、歴史的には常に出力を許している様にも見える。不思議だ。

    うーん。実は progcomp-helper-func ではなくて、compgen の時点で出力を抑制し
    ていたのだったろうか。

    * 98835b5 2021-05-17 これは _ble_util_fd_stderr 等に保存した fd を使う様に
      する変更。本質的には tty を使う様になっている。元から helper-func で tty
      にリダイレクトしていた。

    * 9d4ad56 2021-05-06 うーん。以前の報告が見つかった。よく見たらこれも
      oc1024 による報告である。この commit では stderr に関連する変更はない。

      https://github.com/akinomyoga/ble.sh/issues/97

      どうもこの時は個別にバグのある関数を置き換えたのだった。修正は 9d4ad56 で
      ある。stderr/stdout に対しては全く変更していないし細かい議論もしていない。

    * 4fc51ae 2021-03-10 fzf に対する対策。これについては明示的に tty にリダイ
      レクトしている。これより前は compgen 呼び出しの stderr への redirect の為
      に stderr は抑制されていた。

    * 68f8077a 2020-04-06 これは compgen 呼び出しに builtin を付加しただけ。

    * 1ca53868 2019-01-01 これは complete -p の解析に機能を追加した物。この時点
      で compgen の stderr は抑制している。

2021-06-13

  * menu-complete: 末尾一致 (skip-completed-text) が考慮に入っていない

    これは最終的な挿入時に処理するべきか、或いはメニュー項目を一時挿入している
    時から処理するべきか。メニュー項目を一時挿入している時から処理しないと振る
    舞いとして不自然になる気がする。

  * 終了ステータスが 2 の時に前回のコマンドを再ロードするというのは面白い試みかもしれない

    最近人気らしい thefuck により修正後のコマンドが取得できればなお良い。

2021-05-29

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

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

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

2021-05-27

  * wiki の更新
    * done: \g{...} について記述する (2021-06-13)
    * wiki: ble-import の -f オプション
    * wiki: bleopt の wildcard, -r, -u
    * wiki: blehook の -a
    * 2021-06-12 wiki: bleopt -I
    * 2021-05-24 airline: 使い方を説明に書く

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

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

2021-05-23

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

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

2021-05-21

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

    ble.sh の関数についても着色及び補完関数を定義して行きたい。

2021-05-19

  * complete: [TAB] 補完の場合には、ユーザー入力があった時に即座にキャンセルす
    るのではなくて timeout があっても良いのかもしれない。

2021-05-17

  * 此処で思ったのだが nawk は Unicode の対象を取り扱えるのだろうか。。。UTF-8
    ならば通常の制御文字はそのままなので問題は生じないのではないかという気もす
    るが。文字数を数えて何かする様な処理では何か変な事が起こるかもしれないが、
    そうでなければ大丈夫の気がする。

    問題が起こるかもしれないのは brace expansion の形式でファイル名一覧を挿入す
    る処理。これに関しては UTF-8 だと例えば平仮名の途中で分断されたりして変な事
    が起こる可能性がある。

  * global: /dev/null を $_ble_util_fd_null に置き換える?

    #D1552 で議論した。毎回 open するよりも dup した方が高速である。一方で
    _ble_util_fd_null が上書きされたりした時は /dev/null の方が頑健である。

  * syntax: redirection が正しく解析できていない気がする
    以下の手順で編集した時に着色が間違っている。

    $ exec {fd}>/dev/null
    $ exec {}>/dev/null
    $ exec {_ble_base_fd_null}>/dev/null

  * 色見本について探した

    多くのサイトは微妙である。そもそも sRGB とかの概念があるのかないのか不明で
    ある。単純に RGB #XXXXXX の値を線形で CMYK に変換していたりしてかなり怪しい。
    色用語の場所にも sRGB やガンマ補正などの単語は見られない。

    https://www.color-sample.com/popular/jiscolor/ja/

    このサイトはちゃんと sRGB/Adobe RGB 等について載っているので少なくともちゃ
    んとその辺りの事を認識した上で作られたサイトであろうと思われる。然し権利関
    係の記述もないし、連絡先もない。メールボタンがあると思って押したら単に "友
    達にこのサイトを紹介する" メールを送る為のボタンだった。© 2021
    Color-Sample.com. All Rights Reserved. という表記の右にあるアイコンがリン
    クになっていたので押して見たが、単純にトップに跳ぶだけだった。Twitter アカ
    ウントは https://twitter.com/color_sample で見に行ったら 2014 で更新が止まっ
    ている。著作権が 2021 になっているのは機械的に置き換えているだけという事だ
    ろうか。何だかよく分からない。というかよく見たらブラウザサポートというアイ
    コンも古いブラウザが並んでいたりして更新が止まっている事を示唆している。

    https://triple-underscore.github.io/css-color-ja.html#rgb-to-lab

    w3 の CSS の仕様の翻訳。ここにちゃんと色々の知識が書かれている。この文書は
    最初から最後まで読むべき。

    http://mezala.la.coocan.jp/pc/jiscolor/jiscolor.html

    このページは複数の情報源からの差異について見せているがそもそも CMYK, RGB の
    変換式として異なるサイトから二種類持ってきていて (どちらかが間違っているの
    に違いない) 更に、Wikipedia からの数値も比較していて、どれだけ見た目が変わっ
    てくるかを見せているが。色には絶対的な基準はないのだとか色々言って納得して
    いるが、これらは単に sRGB と RGB の解釈を間違えて変換しているから起こってい
    る間違いのような気がする。(とはいいつつ画面の輝度やその他の要因もあるだろう
    から一概には言えないのかもしれないが、少なくともどういう条件の元での変換を
    行っているのか明示した上で、その差異について議論していなければ情報としては
    使い物にならない)

    https://www.colordic.org/w

    このサイトは和色大辞典と言って 460 色掲載しているそうで一番大きい気がする。
    然し、その RGB 値が sRGB なのかどうかとかも分からない。Q&A には再利用・再頒
    布可能性などについては述べられていないし、各色の出典についても書かれていな
    い。このサイトの RGB 値が実際に sRGB なのか何なのか確認して、その上で他の色
    についても変換を確認するのが良い気がする。

2021-05-15

  * AUR blesh-git のカスタム update について
    https://aur.archlinux.org/packages/blesh-git/
    https://aur.archlinux.org/cgit/aur.git/tree/blesh-update.sh?h=blesh-git

    * {PRE,POST}_VERSION を local で宣言する
      これはもう既に修正してもらった。

    * _package.sh の属性は 644
      これに関しては結局指摘する機会がなかったからそのままだが、まあ大して問題
      はないだろう。

  * syntax

    1>&$fd- は使えない
    1>&./- もエラーになる

    もっとちゃんと調べる必要がある。

2021-05-09

  * Fedora の package にするには結構面倒な手続きが要りそうな感じである。
    https://blog.jwf.io/2017/11/first-rpm-package-fedora/

    何れにしても ble.sh は頻繁に変更が加わっているし未だ 0.* の version の段階
    なので未だ公式に提出はしない事にする。1.0 を出す時に一緒に提出を考えるのが
    良いだろうと思われる。

  * v1.0 を出す迄に何か目玉の機能を実装したい所であるが、実の所、他のシェルに全
    くない様な機能で便利そうな物は存在しない。

    * syntax-highlighting ... 文法もちゃんと追跡した物

    * error message ... これは他のシェルにはない機能である。fish にあったりする
      かもしれないが。

    * vim mode ... これは highlighting も含めてなかなか気に入っている。

    * complete
      * sabbrev ... 個人的にこれは結構便利だと考えている。
      * auto-complete ... これは別に他のシェルと比べて何か良い訳でもない。
      * auto-menu ... これはちょっと煩い。けれど他のシェルにもあるので。

    * bottom panel ... 一つは bottom panel かもしれないがそんなに便利なのかとい
      うと微妙な所である。tmux の方の設定で似たような物を表示できる筈だし特に便
      利でもない。見た目に派手なので最初は喜んで使う人がいるかもしれないという
      位。

    * enhanced history ... 相対パスでファイル名を参照しているのを記録したい。そ
      れを auto-complete の実装に役立てたい。

    * TUI configuration?

    逆に欠けている物。ex mode の :cmd が全然対応できていない。

2021-05-06

  * progcomp: complete -C completer で改行のエスケープに対応していない

    man bash によると completer の出力した結果は行志向であるが \ によるエスケー
    プで改行を含める事ができるらしい。然し、\ が特別な意味を持つのだとすれば行
    末に \ を置きたい時にはどうすれば良いのか。行内全体に於いてエスケープが意味
    を持つのだろうか。よく分からない事が多い。実際に試してみないと分からない。

    或いは read line で読み込む事ができる形式だろうか。

    →実際に動作を確認したところ、エスケープの除去は行われず \ も含まて補完文字
    列とされる様だ。よく考えてみれば、実際に挿入した時に複数の単語として解釈さ
    れてしまっては困る訳だから、確かにこの動作でなければならない。

    ? 末尾に \\ があったらどうなるだろうか → \\ であってもその後の改行は候補の
      一部と見做される様だ。

    さて、具体的にどの様に実装するのが良いか…という事を考えようと思ったが難し
    い。先ず標準出力を勝手に自分で COMPREPLY に代入するのは違う様に思われる。と
    いうのも、呼び出し元の compgen で -S suffix 等の加工をしてもらわなければな
    らないからである。だとすると、最終的な compgen の出力結果を解釈する時に行末
    の '\' で行を繋げる様に処理しなければならないのだろうか。

    そもそも改行を含むファイル名があった時に compgen はどの様な出力をするのか。
    うーん。普通にエスケープせずに改行を出力した様な気がする→確認した。確かに
    そうなっている。なので '\' が行末にあるからと言って勝手に振る舞いを変更する
    のも憚られる。

    或いは compgen の全ての機能を自前で模倣するという手もなくはない。その場合には区切りは全て制御下にある。

  * progcomp: -F もしくは -C で生成した候補に対しても dir/ 等の suffix を付ける
    必要はあるのか。もし付けたければ completion 側で付けるべきなのではないかと
    いう気がする。

2021-05-04

  * robustness: ble.sh では exit を上書きしているが set -o posix の時にはそれが
    無効になる。

  * util: builtins 復元、function#advice, etc. において functrace 属性は復元し
    なくて良いのだろうか。復元という事を考えるとやはり declare -pf を使う必要が
    あるのかもしれない。

    bash version, posix mode も含めてどういう方法があってそれぞれどの様に振る舞
    うのか調べる必要がある。

    取り敢えず問題が起こらない事を確かめた上で getdef 自体を更新するのが良いの
    ではないか

    →と思ったが実際は複雑である。getdef を使って関数を別名にコピーするのに使っ
    たりしているが、その時に先頭部分だけを置換している。しかし declare -ft の部
    分についても関数名を置換しなければならない。そういう事になるぐらいであれば、
    個別に declare -ft かどうかを判定して、改めて declare -ft で属性を付加し直
    す様にしないと行けない筈である。

2021-05-03

  * rlfunc: fetch-history
    8f485ff8 - new readline "fetch-history" bindable command
  * rlfunc: C-x s, spell-correct-word
    6be3a741
  * rlvar: enable-active-region
    b1965836 new "enable-active-region" readline variable
  * rlbind: prior, next
    65822e50 - alias expansion fix in case statements
  * vi-undo

  * 5.2: LS_COLORS *.readline-colored-completion-prefix (bash e59452c7)

    rlvar colored-completion-prefix が on でかつ LS_COLORS の中に
    *.readline-colored-completion-prefix という項目がある時、共通一致部分の着色
    をそれに書き換える。

    実際に bash の振る舞いを調べてみようとしたがどうも有効にならない。調べてみ
    ると、_rl_color_ext_list が初期化されていない。これを初期化する為には何かす
    る必要があるのだろうか。_rl_parse_colors という関数で初期化しているようだが、
    この関数はどこから呼び出されているのだろうか。

    うーん。分かった。readline.c:1327 で呼び出している。これは初期化部分である。
    つまり、readline を初期化するよりも先に LS_COLORS を設定しておく必要がある。
    更に言うと、bind 'set ... on' も事前にやって置かないと駄目。というか
    colored-stats の時点で同じ問題があったのではないか?

    これは単純に _rl_color_ext_list が空だったらその場で _rl_parse_colors の呼
    び出しを試みるという事と、それから LS_COLORS の値が変更される時に
    _rl_color_ext_list をクリアする。と思ったが、これだと LS_COLORS が空の時に、
    毎回 _rl_parse_colors が試みられて非効率的である。

    * 後、_rl_colored_stats = 0 が _rl_parse_colors の中で設定されている。

2021-04-30

  * ble-reload: blerc 外のユーザー設定の保持

    外部のツールが呼び出した blehook PREEXEC+=... 等は別枠で保存しておくべきで
    はないか。そうしないと ble-reload した時に設定が消えてなくなってしまう。或
    いは、blerc の中から呼び出したか外から呼び出したかで取り扱いを変える。blerc
    の中で呼び出した設定は消えてしまっても仕方がない。一方で、blerc の外側で実
    行した物については保持しておくのが自然なのではないか。

2021-04-29

  * robustness: main/init: readonly POSIXLY_CORRECT されていたらどうするのか。

    少なくともどちらの側の設定であっても ble.sh 的には困る。

    然し、readonly まで気にし始めるとあらゆる変数名で問題が起こるので気にしても仕
    方がないのかも知れない。せめて全て大文字の変数だけが readonly になっていると
    いう事を要請するのが妥当だろうか。ローカル変数で大文字を使っているというと
    KEYS WIDGET ARG FLAG REG 辺りは危ないかもしれない。

    然し、ここまで行くと「ユーザーが自分で変な事をしたのだから責任は持てない」と
    いうレベルの事の様な気がする。

  * robustness: main/init: 最初の bash version 判定も alias 対策可能かもしれない?
    然し、return/exit が上書きされる場合等も考えると難しいかも知れない?

  * robustness: "builtin read -e" 対策?

    これは今迄考えて来なかったが関連する考察 #D1520 があったので記録として残し
    ておく。但し、纏めた物を眺めるに総じて困難である様に思われる。

    a set -o emacs / set -o vi の切り替えを利用して read が使える様にする。つま
      り、ble.sh は裏側の keymap に bind して、ユーザーコマンドを実行する時に反
      転させるという方法。この方法には問題が多い。

      x 全てのユーザー関数 (補完関数、プロンプト、trap、blehook 等) で keymap
        を反転する必要があるのではないか。

      x ユーザーが emacs/vi keymap を切り替える rl bindable function を実行する
        と結局 ble.sh の bind している keymap が表に出てきてその時点で制御不能
        になってしまう。勝手にそういった binding を削除するのも非現実的な気がす
        る。

      x bash の version によっては keymap を切り替えると bind -x が中断した様な
        気もする。

    b trap DEBUG 等を使って builtin read -e が呼び出されるのを検出して、ble.sh
      で wrap した処理を行ってからそのコマンドの実行をスキップする。この方法に
      も色々の問題がつきまとう。ちゃんと透過的に対応できるかというと困難の気が
      する。

      x DEBUG のコストがある。

      x ユーザの設定した DEBUG の管理が面倒。結局 trap DEBUG を透過的に利用でき
        る様にする枠組みは完成していない。(これはその枠組さえ完成すれば余り気に
        しなくても良いのかもしれない)

      x 本当に実行するコマンドを入れ替える事が可能なのだろうか。例えば builtin
        read -e の呼び出し元から見て、本当に関数実行が入れ替わった様に見えるの
        か。exit status はどうなるのか。これは実際に実験してみないと分からない。

      x DEBUG の BASH_COMMAND を用いて元のコマンドを本当に再現できるのか。例え
        ば $1 等が使われていた時にその内容を取得する事は可能なのか (BASH_ARGV
        を有効にしておかなければならないのか? ユーザーが設定を変更してしまった
        らどうなるのか)。また、引数の境界等もちゃんと BASH_COMMAND を見ただけで
        分かる様になっているのか。これも色々実験しないと分からない。

    c builtin read -e に入った後で ble.sh の widget が呼び出されたら良い様に
      状態を adjust して widget の振る舞いを変更できないだろうか。

      x C-c に明示的に対応して、C-c が呼び出された時には設定を restore して抜け
        る様にする。これは面倒なだけで処理としては十分可能である様な気がする。
        但し、外側に SIGINT を伝播する必要はあるのかもしれない。

    d ユーザーがコマンドを実行する度に realine 設定を完全 unbind して、終わったら
      再度 bind し直す。でも、これは文法エラー等によってコマンド実行が中断された
      時に、ble.sh session に復帰せずに通常の readline の状態に落ちてしまう。

2021-04-06

  * logout も exit と同様に置き換えるべきなのではないか。

  * prompt を評価する時に $var が local 変数に被覆されている。

    然し $var だけならば良いが $() で呼び出された関数が更に内部で変数を使用して
    いる可能性等を考えると下手に変な調整はしない方が良いかもしれない。PS1 に直
    接 $var と記述するかしないかで $() の内部でも変数が見えるかどうかが切り替わ
    るというのは不自然すぎる。それならば ble.sh 自体が変数を定義するのでそれに
    よって被覆されてしまうと説明した方が自然である。

    グローバルでない変数を列挙する方法は存在するだろうか。

2021-04-26

  * keymap/vi: vi における既定の keymap を imap ではなく nmap にするオプション

    現在の振る舞いではコマンド実行後に nmap であれば insert-mode に戻すという操
    作をしていた筈である。その箇所を書き換えて、オプションに応じて変更先のモー
    ドを切り替える様にすれば良い。それと ble-attach した時の最初の設定を行った
    直後に、自動的に nmap に移動する様にする処理を加えれば良い。

  * ble-bind: ble-bind -P で、他のオプションで指定したタイプの binding だけを出力する?

    % -T を指定すれば -T の設定を出力する。--cursor を指定すれば --cursor の設
    % 定を出力する。cmap 関連のオプションを指定すればそれに関連する設定を出力す
    % る。と思ったが、-T, --cursor, --csi, -k, etc. はそれぞれオプション引数を
    % 取るので、引数読み取りの段階で -P の後で振る舞いを変更する様にしなければ
    % ならない。これはコマンドライン引数の解釈として不自然である。

    別のオプションを使って dump する内容を選別するのが良い。例えば、
    --filter=timeout:cursor:csi:cmap:etc 等である。

  * decode: [refactor] _ble_decode_KEYMAP_kmap_@ ?

    いきなり KEYMAP ではなくてその前に何か挟みたい。例えば
    _ble_decode_kmap_KEYMAP_@ に変更する等。この場合には KEYMAP の名称として紛
    らわしい物が定義された時に問題になるのではないか。前の実装で KEYMAP の直後
    に固定の文字列を挿入していたのは、末尾から KEYMAP 以外の部分を一意に切り取
    る事ができる様にする為の設計だったのではないか。

    現在の実装は末尾からの一意性が保証される様になっている。_kmap_ が他で使われ
    ていない限りに於いて、ちゃんと一意になっている。然し、名前空間として変であ
    るというのも分かりにくい。なので、 _ble_decode_kmap_KEYMAP_xxxx_yyyy にして、
    xxxx には yyyy に絶対に現れない文字列を指定すれば良い。例えば data 等。

2021-04-04

  * history auto-save

2021-03-21

  * robustness: 様々な基本的な変数が readonly でグローバルに固定されていたらど
    うするのか。ロードした瞬間に様々な良くない事が起こる気がする。然し、それを
    言い出すと、bash-completion や他のフレームワークにも強い影響が出てくるので、
    ble.sh だけが対応しても仕方がないという考え方もできる。

2021-03-07

  * edit: キーボードマクロで "M-d" が "M-d d" と記録されてしまっている
    vi でも emacs でも同様に記録されてしまう。

2021-02-28

  * canvas/trace: wordwrap に対応する。つまり、単語の途中で改行しない様にする。

    これは今の所具体的な用途もないので取り敢えずこの儘にしておく。

  * canvas/trace: より詳しい justify の仕様について設定できる様にする。

    #D1494 の案では "SEP*WEIGHT FILL SEP" を単位として指定するという話だったが、
    これはやはり不自然な感じで分かりにくいのでもっと分かりやすい指定方法を考え
    るべき。

    例えば、最低幅1重み2 '%1.2S{FILL}' という具合にするなど。こうすると % を
    SEP に指定できないし } を FILL に指定できないが使う機会があるとも思えない
    ので気にしない。或いは '%{1.2SFILL}' とする? うーん余計に分かりづらい。或
    いは printf strftime を真似て '%1.2(FILL)S' という具合にする。

    空白は既定で '%1.0( ) ' に相当する。その他の文字は '%0.0()X' に相当する物
    とする。

    2021-03-08 というより、各 sep の性質として登録するよりも、\q{...}  を通して
    設定できた方が自然なのではないか。

    \q{hfill w=2 fill=...}... という具合に。その場合には \1\2 と同様に特別なシー
    ケンスで fill を表現する必要はある。OSC か其処らを使えば良い気がする。或い
    は ANSI seq に何かあった気がしないでもない。

2021-02-27

  * /dev/tcp/... についても特別に着色を行いたい。

    例えば < /dev/tcp/.../.. において正しいパスであるのにも拘らず、存在しないファ
    イルとしてエラーが検出される。

2021-02-24

  * canvas/trace: trace の g0 は後で合成するのではなくて \e[m の段階で設定する
    べきなのではないか。

    後、g0 という名前も余りよくない気がする。他の x0 y0 からの連想で初期の g の
    値という雰囲気が出てしまう。然し一方で sgr0 からの連想で背景色という雰囲気
    もある。実際に別の場所では sgr0 を指定する事によって背景色を設定できる様に
    なっている。

    名前はさておきどの様に振る舞うのが良いのか。例えば \e[39m で既定色に戻すと
    いう操作の場合は本当に端末既定色に戻すべきなのか、或いは g0 で指定した色に
    するべきなのかというのは微妙な所である。g0 で指定した色にするべきの気がする。

    一方で、下線などの属性に関しては g0 で指定したものから解除できる様にするの
    が自然な気もするし、或いは g0 で指定した物は常に設定されているのが自然の様
    な気もする。どちらが良いのかは分からない。やはり現状の実装で良い様な気もす
    る。

    うーん。単に設定のあるなしという捉え方ではなくて下線ありと下線なしという独
    立したスタイルがそれぞれあるのだと思えば、やはり g0 を毎回上書きするのでは
    なくて、\e[m 等に対応する操作の時にだけ g0 の値に設定するというのが正解の気
    がする。

2021-02-23

  * util: カーソルが bottom-dock にいる時の vbell の座標計算
    Ref #D1495 ... 取り敢えずの対策

    現在の実装は vbell が sc..rc を自由に使える前提になっている。しかしカーソル
    が bottom-dock に停泊している時に vbell が来るとvbell によって floating
    panels の位置が分からなくなってしまい、表示がずれてしまう事になる。

    同じプロセス (親シェル) の中で vbell を処理している場合には、一旦 floating
    panel の位置に戻ってから sc..rc をしてそれから再び bottom-dock に戻るという
    手順を踏む事によって問題を回避できる。然し、サブシェルの中にいる場合には現
    在の最新の配置情報にアクセスできないのでこの方法は取れない。

    現在は取り敢えずカーソルが bottom-dock に停泊している事はないとの想定で
    sc..rc を実行しているが、例えば info_display=bottom にして vi_cmap を使って
    いる時などにこの前提が破れてしまう。

    [解決方法]

    ちゃんと実装する為には、親シェルで全ての描画を行う様にする必要がある。その
    時に問題になるのがどうやって visible-bell の消去のタイミングを親側で決める
    かという事。idle を使う方法は bash-4 以降でしか使えない。シグナルを使う方法
    には余り頼りたくないが、現実的にはそうするしかないのだろうか。bash-3 と
    bash-4 で実装を切り替えても良い。何れにしてもサブシェルと通信を行う枠組みを
    整える必要がある気がする。

2021-02-22

  * cavnas: 描画の最中で status が高さを取得する時に textarea の内容を削り取る可能性がある

    現在の render 中に配置を決定する仕組みは問題があるので再考する必要がある。

  * cygwin: 下部での IL が動かない旨を報告する?

    後 DA2 応答をしてくれないか頼みたい。

    $ printf 'Line %s\n' {0..100}; /bin/sleep 1; printf '\e[L'; /bin/sleep 1

    最下部で DL を実行した時にも何か変な事が起こる。

    $ printf 'Line %s\n' {0..100}; /bin/sleep 1; printf '\e[M'; /bin/sleep 1

2021-02-13

  * edit: C-x e に続いて e を連続して押した時にマクロ実行を繰り返す様にしたい

  * 実は bash の read -e は C-r でコマンド履歴を参照できる。ble.sh では read 専
    用の履歴を独立に管理しているが、コマンド履歴にもアクセスできる様にするべき
    なのでは。と思ったがやはり何だか微妙な気がする。

    read 専用の履歴を別に管理するというのもありなのではないかという気がする。
    その場合には保存場所は何処にするべきだろうか。
    ~/.local/share/blesh
    ~/.config/blesh
    ~/.cache/blesh

    https://github.com/fish-shell/fish-shell/issues/744

    fish は過去に config に置いていてユーザの文句によって local/share に移動し
    た様だ。然し、local/share はそれはそれで何だか変な気もする。

  * gnuplot など他のコマンドに対して ble.sh によって編集機能を提供する事は可能
    だろうか。少なくとも pty を自分で開いてその中で gnuplot を起動する必要があ
    る? 或いは、gnuplot のリンク先の readline library を勝手に書き換えて bash
    を起動させて、更にその中で ble.sh を使って readline 関数の振る舞いを模倣す
    る?

    rlwrap 等を使うという手もある? rlwrap のじっそうはやはり pty を開くという物
    のようである。rlfe という物もあるようである。

    どうも gnuplot の場合には普通に gnuplot & で起動しても操作できる様
    な気がする。ble.sh で _ble_syntax_lang=gnuplot として更に
    exec:gnuplot を提供したらそれだけで普通に動く様な気がする。

    - ble-edit/is-single-complete-line で syntax:bash を呼び出している
      のをsyntax:$_ble_syntax_lang として呼び出す様に変更する必要があ
      る。他にも accept-line が is-complete を呼び出している。

    * shell-expand 系統の widget は gnuplot モードでは無効にしたい。
    * command-help 系統の widget も gnuplot モードでは別の実装にする。

2021-02-10

  * main: 関数内で引数なしで source すると関数の引数がそのまま source の中から
    見える。これらを区別する方法はあるだろうか。

    うーん。shopt -u extdebug であれば BASH_ARGC の数が二種類の source の仕方で
    異なるようである (但しその具体的な数は bash-5 から変わっている。更に入れ子
    source や関数呼び出しなどが絡んできた時にどうなるかは不明である)。然し、
    shopt -s extdebug の時には両者は同じになる。

2021-02-06

  * tui: TreeView

    以下の様な物があるのを見つけた。
    https://gitlab.com/TheDalaiAlpaca/saturnon/-/blob/master/saturnon

    実際どんな物かは確かめていないが、TUI 要素としてファイルピッカーは定番である。

    その基礎として先ず TreeView を実装するというのは一つの方向性。TreeView は
    List の拡張として作成するのが自然であろう。List の各要素の高さを変えられる
    様にして、更に中にそれぞれリストを保持するようにしたものと解釈できる。問題
    になるのはリスト項目が増えてきた時に高さの累積計算が重くなるという事。シェ
    ルで実装すると成ると重み付きB木の様な複雑なデータ構造にもしにくい。或いは、
    本気で重み付きB木をBash上で実装するという方向性もあるのかもしれない。

    Midnight Commander と同等の機能を ble.sh の内部で実装するというのも
    demonstration として良いのではないかという気がする。

2021-02-05

  * 他の bash プログラム

    * https://stackoverflow.com/q/41043916/4908404
      history 候補を自動的に表示する可能性について議論している

      上記 StackOverflow の質問で提案されている。Google Chrome の search bar の様に、
      幾つか文字を入力した時点でもう履歴から項目を拾って幾つか表示し始めるという可能性。
      これは fzf の領分である様な気もするが shell integration を考えるとなかなか非自明である。

      というか普通の検索でも複数の候補を表示した方が分かりやすいのではないかという気がする。
      例えば或る一定以上の時間が経ったら一致する候補を列挙するなど。
      更に待っていると曖昧一致も列挙してくれる、という具合にする。

      2021-02-09 hstr が同様の機能を提供している。hstr の動作も参考にした方が良いのではないか。

    * https://github.com/dylanaraps/shfm/blob/master/shfm (file manager in POSIX shell)
      これは dylanaraps の fff の再実装

    * これは README に乗せるバッジの話
      https://img.shields.io/github/downloads/akinomyoga/ble.sh/total
      ダウンロード数の画像を生成できる様だ

    * Incremental parsing:

      ble.sh で行っている構文解析は特殊な物であるが如何にも既存の例がありそうである。

      検索したら以下の様な物があった。

      [Tree-sitter｜Introduction](https://tree-sitter.github.io/tree-sitter/)

      参考にしている論文を見てみると state matching で skip と書いているので、
      やはり単に途中から始めるというだけでなく途中で解析を中断するという考えも
      ある。寧ろ、完全に一致していなくても局所的な一致であれば解析を跳ばすとい
      う事を実行していると思われ、より積極的な最適化である。

      恐らく先にこれを見つけていたら ble.sh の構文解析の実装ももっと複雑になっ
      て、更になかなか完成しない日々が続いたのではないかという気がする。何事に
      も一長一短があるのであって既存の研究だって参考にできる部分と捨て置いて良
      い部分がある筈だが調べてしまうと完全に対応したく成るのが問題である。なの
      で、取り敢えず持てる範囲の知識で何かやってみるというのは大切な事なのであ
      る。

      oil 等は沢山調べすぎて行き詰まっているのではないかという気もする。或いは
      逆に何だか Python -> C++ translator を開発するなど変な方向に走っていて、
      それで余計に時間を取られているのではないか等等。やはりメンテナンス等を考
      えると、Python は prototype として捨て置いて、C++ で完全に書き直した方が
      得策なのではないか。Python -> C++ をずっと使う事にしていると、少しの機能
      追加で毎回 translator にも大幅に手をいれなければならず、結局メンテナンス
      が困難になる。特に第三者がコードに手を入れるのが極度に難しい。この構造を
      保持したまま続けるには最初に完全なる translator を作って、その後は
      translator の改良を行わないという決断が必要である (状況に応じて最適な翻訳
      が異なりうる事まで考えていたら完成した translator があってもきりがない)。

2021-02-05

  * evaluate-path-spec (by 3ximus)

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

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

    2021-12-31 詳細は以下にある。
    https://github.com/akinomyoga/ble.sh/issues/82#issuecomment-773487368

    83.sh に実装を入れて試してみる事にする。

    と思ったが具体的にどの様に実装すれば良いのだろうか。先ず初めに短い物から長
    い物まで順番にパスを構築する。その後に一番長い物から順番に一致を試みる。一
    番長い物が一致すれば、後はその得られたパスを既存のパターンに当て嵌めれば良
    い。と思ったのだが、どうやって当て嵌めるのだろうか。

    * extglob まで絡んで来ると余計に分からなくなる。と思ったが extglob は
      simple-word の要件を外れるのでここでは考えなくて良い。

    うーん。glob を解釈して正規表現に変換すれば行けるかもしれない。或いは、
    ${path#$pattern} または ${path%$pattern} 等として削って行けば良いのでは? と
    思ったが、$pattern の場合には * も一致してしまうのではないか。。

2021-02-03

  * edit: 例えばファイル一覧を表示する機能を付けても良いのではないだろうか。

2021-02-01

  * complete: complete_timeout_compvar でタイムアウトした単語の glob 文字を quote しない?
    Ref #D1457

    現在はグロブ文字も quote して COMP_WORDS と COMP_LINE を構築している。例え
    ば **/*.txt に時間がかかった時に COMP_WORDS には "'**/*.txt'" という文字列
    が格納されるが、これは本来 "**'/'*'.txt'" であるべきなのではないかという事。

    * 一方で、補完関数の方が複雑な quote に対応しているかという問題もある。

    * また、ここで quote しないと結局補完関数の方でも時間がかかってしまうのでは
      ないかという恐れがある。

    という事など考えると、取り敢えずは完全に quote する実装にしておく。後で気が
    向いたらまた考える。

  * highlight: failglob の時の a/b*/c/d.txt の着色が最後のファイル名になっている。
    本来はどの時点で failglob になるか判定して着色するべきなのではないだろうか。

2021-01-28

  * progcolor: ble/syntax/progcolor/eval-word を着色を跨いでキャッシュできないか

    特に展開結果を何処かに保存しておきたい。新しい配列を用意するか、或いは hash
    にして記録するか。

    a hash にして記録すると一度評価した単語を再評価する機会が失われる。ファイル
      が追加・削除された時に更新されなくなってしまう。

      やはり、単語単位でやはりキャッシュしたい。そうすると shift にも耐えうる仕
      組みにしたい、という事で新しい配列を用意するか、或いは既存の配列に格納す
      るという方法になる。

    b 新しい配列を追加する

      また shift 等の操作が増える。面倒である。

    c 既存の配列に要素を追加する

      既存の配列に格納する場合には任意の文字列を含める事ができないので、補助配
      列にデータを格納する事にしてその添字を既存の配列に入れるという手がある。
      特に単語に id を振っておけば今後の word に関するデータ拡張にも使う事がで
      きる。

    →これに関しては ble/syntax:bash/simple-word/eval の側でキャッシュする様に
    したので、今の所はここでは対応しなくて良い気がする。当初は simple-word/eval
    では非常に短期のキャッシュしかしない方向を考えていたが、ファイルシステムが
    そう頻繁に変わる訳でもないので、取り敢えずは行毎にキャッシュを保持する事に
    した。なので、simple-word/eval のキャッシュは単語よりも寿命が長いので単語毎
    のキャッシュは今の所は考えない事にする。

    * 但し、やはりファイルシステムの変化に追随したいという事であれば、適当にキャッ
      シュを更新する必要がある気がする。或いは、globpat を含む様な場合にのみキャッ
      シュを行うというのでも良い様な気がしている。

    * また、ここでの実装手法は例えばエラーメッセージの記録等の場合にも使えるの
      ではないだろうか。という気がする。

2021-01-22

  * highlight: 引数が沢山あると cygwin で滅茶苦茶遅い

    これは様々な種類のパス名展開を試そうとするのが原因だろうか。
    command 名と同様にキャッシュする様にしても良いのではないだろうか。
    でも少しずつ微妙に異なる引数が沢山ある場合には結局遅い。
    それよりは着色自体の高速化について考えた方が良いのではないか。

    * chat でも遅くなるかどうかについて確認する。
      やはり微妙に遅い様な気がする。

    何が遅くなっている原因化について確認する必要がある。
    例えば fork している可能性はあるだろうか。

2021-01-08

  * syntax: 算術式の quote が変である

    x echo $((a['$hello'])) の $hello は展開対象なのに着色されない。
      →然しこれは文法上の問題なので寧ろ着色しない方が自然である様に思われる。
      (これは eval の引数を着色するのかという問題にも通じる)

    x ((a["$index"])) がエラー着色になっている
      →どうもこれは bash-5.0 から振る舞いが変わったという事の様である。

    x bash-5.1 からは (()) でも ' は quote ではない。

    x 更に言うと a['...'] の ' は a が連想配列の時には必ずしもエラーではない。
      現在はエラー着色になっているがこれは修正するべきの気がする。

2020-12-19

  * Note (#D1435): blehook WINCH を処理している最中に終了したユーザのジョブがあ
    るとその通知が画面に表示されない可能性がある。これは実際に起こりうるのかど
    うか確認していない。

2020-12-14

  * progcomp: progcomp で生成された補完候補を現在 quote している。

    * 生成された候補が既に quote されている場合や展開を含む場合に、
      意図したのと異なる結果になってしまう問題がある。
    * 更に既に入力済みの部分に一致しなくなるので遡って書き換わる可能性もある。
    * 生成された候補が複数の単語に分かれる場合に、
      それが blesh の quote によって一つに結合されてしまう問題もある。

    理想的には生成された候補を改めて simple-word/eval して、
    その結果に基づいて単語を再度挿入し直すという事が考えられるが、
    x 全ての候補に対してこれを実行する事を考えると処理が重くなってしまう。
    x また、\**\* 等を展開すると *** になってしまうので
      その quote を復元する方法についてもちゃんと考えなければならない。

    或いは simple-word element を一つずつ抽出して処理すれば良いのかもしれない。

2020-11-30

  * tui: face editor の TUI の様な物を作っても良いのかもしれない [#T0007]
    というより fish の Web interface の様な物を TUI で提供しても良いのでは。

    2021-04-25 @Alyetama から似たような提案を受けた。
    https://github.com/akinomyoga/ble.sh/issues/80#issuecomment-826194833これは
    初期設定 wizard の様な物を想定している様だが、TUI config ではもっと自由にい
    つでもどの設定でも選んで設定できるのでより自由度は高い。そう言った物でも良
    いかという事を一応確認はしてみる。

    作るとしたら先ずは Color Picker?
    その前に layout engine? 或いは画面の切り替え?

    Window system がどうのこうのという計画があったような。window system に関し
    ては内部バッファだとかスクロールだとか textarea だとか様々の物を内包する物
    であった筈で、此処で必要になる物は其処まで複雑な物ではない。でも一緒に実装
    してしまっても良い様な気もする。

    - Windows system に必要な物。control, window, layout-engine,
      background-buffer, redraw, resize, etc.

      既にある panel, textarea 等を拡張する感じに考えても良いのかもしれない。但
      し、これ以上の ble.sh の肥大化を避ける為に canvas ではなくて新しく
      lib/core-forms.sh 的な物を追加して其処で実装するのが良いのではないか。
      textarea に関しては、forms が或る程度形になってから対応するという形で良い
      気がする。

      control に属する変数の記録方法? これは textarea と同様にしたいが、
      textarea の方も forms に対応しようとすると調整が必要になると考えられるの
      で、最初は既存の枠組みに捕われずに実装するので良い気がする。

    - window: overlay を実現する方法として二つの可能性が考えられる。

      a redraw 関数の方で clip 等を処理する方法。

        これは各 control の実装が複雑になってしまう。というより任意の clip
        region の形状に対応しようとしたら非現実的な実装になってしまう。

      b もう一つは Window の側で buffer を内部に保持し、最終的な描画の際にそれ
        を適当に clip して出力する方法。

        これに関しては内部 buffer の表現方法に工夫が必要になる。

    取り敢えず何も考えず少し実装してみた。clip に関しては redraw の側で適当に処
    理する事にした。また、trace に於いても clip 機能を実装した (#D1493)

    invalidate 範囲を記録できる様にしたい。

    更に、要素のサイズが変更された時、移動した時には親の該当範囲も一緒に
    invalidate する必要がある。


    自身の内容が変化した時、自身に被っている別の要素も一緒に更新する必要が出て
    くる事に注意する。

    a 上に物が被っていない時には clip 領域を勝手に広げて描画しても良いのではな
      いか。描画範囲を広げても良いかどうかについては render.draw の呼び出し元か
      ら指定できる様にすると良いのかもしれない。

    c 或いは、そもそも被らない様にするか、被っている時には更新しない様にすると
      いう手もある。

    d 或いは、render.draw の呼び出し元で一旦シーケンスを取り出して、その上でそ
      れを再度 trace によって clip するという手もあるかもしれない。然し、これは
      描画内容が大量にある場合にとても遅いので実は避けたい。

2020-11-20

  * bash: declare -c や ${var~} 等は 5.2 で削除するとしているが本当だろうか

2020-11-13

  * complete: bash progcomp と ble.sh progcomp の競合問題

    現在は complete:* の方が builtin complete の設定よりも優先される様になって
    いる。これは ble.sh がロードされていない時はbash-completion を使い、ロード
    されている時は ble.sh 様に特化した補完設定を使うという状況を考えると自然で
    ある。

    然し一方でユーザーが自分の好きな設定を builtin complete で設定してもそれが
    反映されないという問題が生じる。やはり builtin complete の方を優先させるべ
    きだろうか。或いは、complete:cd は既定ではロードしない様にして、contrib か
    何かに入れてユーザにロードさせる様にするのが良いのではないかという気もする。
    然し、ユーザにロードさせるとしてもコマンドを一つ一つロードするのではなくて、
    まとめてロードするという状況も考えられる。その場合には、やはり builtin
    complete と complete:* の競合が起こってしまいどちらを優先させたら良いのか分
    からなくなる。

    或いは ble.sh に特化した設定も builtin complete 経由で呼び出す様にする?
    しかしそうすると ble.sh から ble-detach した時に動作しなくなってしまう。

    attach/detach の際に設定を保存・復元するという方向性も考えられる。

    complete を上書きして両方の設定を行える様にするという手もある。この場合には
    attach/detach する時に既に設定した内容を読み取る等の工夫が必要になる?

2020-11-11

  * syntax: $HOME 等の変数展開があるパスに対して simple-word/eval が重い問題

    中でグローバル変数の復元等の複雑な処理をしている。一回呼び出すだけならば良い
    が $HOME/.mwg/src/ble.sh/archive/layers ... 等の様なパスの着色で各ディレクト
    リの階層で展開を試みている場合に、何度も呼び出す事になると遅さがかなり目立つ
    ようになる。

    単語着色では determine-separated-path -> locate-filename ->
    highlight-pathspec という具合に三段で処理していて各段で毎回 eval しているの
    で特に重い。これは処理を統合して高速化する余地もある。コードが汚くなるという
    問題はある。よく考えたら現在の実装では locate-filename は特に eval は実施し
    ていない。単に : で区切っているだけである。なので locate-filename に関しては
    気にしなくても良い。

    或いは複数のパスを一度に eval する機能があっても良いのかもしれない。その場合
    に結果をどの様に返すのかは難しい。複数単語に展開される事を考えて既に一つの
    eval の時点で ret が配列だからである。各パスの最初の単語だけを返す事にするか、
    或いは全ての単語を全部混ぜて一つの配列に返すか。一つの配列に格納する場合には
    各パスに対応する index の範囲を返す事ができるがインターフェイスとしては分か
    りにくい。

  * bashbug: builtin で while という名前の builtin を load すると他の builtin が
    使えなくなる。

    ? 使えなくなるのは、同じ dll の中の物のみなのか或いは全ての dll の loadable
      builtin が使えなくなるのか。

    ? while 以外にも問題を起こす名前は存在するか。

    ? 影響を受ける builtin はキーワードと一致する名前の物のみか或いは全てか。

2020-11-07

  * complete: PATH=path1:path2:path3 の補完

    PATH=path1:path2:path3 の時に着色が最後の要素にしか適用されないし、また補完
    は全然働かない。全く動かないのならばまだしも中途半端に動くのは変なのでちゃん
    と対応したい。

    →着色に関しては #D1409 で議論する。

    complete に関しては元の bash ではちゃんと動いているので尚の事問題である。

  * highlight: 条件コマンドの中での着色が効かない。着色しても良いのではないだろうか。
    今まで実装していなかったのは正しい文法解析や入れ子などの処理が面倒だったから。

    今確認してみると 条件コマンドの中でも ( && || ) などは特別な意味を持つ様であ
    る。更に & や | を使うとエラーになる。<< 等のリダイレクトもエラーである。必
    ずしも空白で単語が区切られる訳ではない様なので、これに関しては文法解釈のレベ
    ルで修正が必要になる。

    今試すと ; も途中に現れると区切りとして取り扱われてエラーになる。

    * |&;<>() は特別に取り扱う必要があるという事。単体の < と > に関しても正し
      い演算子の文脈に現れれば大丈夫だが、二項演算子の現れない場所で使うと構文
      エラーになる。この様な構文エラーまでチェックする必要があるだろうか。或い
      は演算子の結合まではチェックしない事にするか。

    * 括弧の途中で ]] が現れた場合にもエラーになる。

2020-11-06

  * complete/mandb: progcomp で生成したオプションに関してもできれば desc を表示する様にしたい。
    progcomp に候補を生成させてもしオプションが含まれていて、
    かつそれが mandb の中に含まれているという事が分かった時に desc-raw を表示する。

    * git 等の場合には man git で得られるオプションと
      サブコマンドで得られるオプションは異なるので注意する。

  * complete/mandb: bash の場合にはビルトインコマンドのオプションまで混ざって列
    挙されてしまって駄目。bash 固有のオプションについてまとめたファイルを用意し
    ておくべきである。

    bash builtins のオプションに関しては builtin ... --help を使用すれば取得でき
    る。これはこれでまた解析の為のコードを書かなければならないが、bash の
    builtin に限れば形式が定まっているので解析のコードを書くのは難しくはない。

  * complete/mandb: 何と man git は .PP ... .RE 4 ... .RS でオプションを説明している。
    この様に .TP を用いない様な場合にも対応するべきなのだろうか。

  * complete/mandb: 同じ意味を持つオプションについて。
    同じ意味を持つ複数のオプションを分ける時に、
    分けてから sort するのではなくて sort してから分けるべきではないか。
    同じ意味を持つオプションは連続されて表示されて欲しい。

2020-09-07

  * complete: メニュー絞り込みが働いている状態で単一確定ができない場合がある

2020-09-03

  * main: attach 戦略再考 [#T0004]

    attach の戦略に関する議論は以下にある。
      #D1382, #D1124, #D0940, #D0737

    | a 即attach。PS1 表示
    |   x PS1 が後で変更された時に問題。
    |   x 後の設定の出力が消滅する
    |
    | b 即attach。PS1表示はする。出力抑制はしない
    |   x PS1 が後で変更された時に問題。
    |   x 後の設定の出力と混ざる
    |
    | c 即attach。PS1表示はpromptまで遅延
    |   x keymap初期化に時間がかかる
    |
    | d 即attach。PS1表示する。出力は記録して後でdump
    |   x 後の設定が対話的なインターフェイスを起動した時に問題
    |   x 後の設定が /dev/tty に対して出力したら防げない
    |   x 後の設定が初期化進捗などを出力するとそれが実時間で反映されない
    |
    | e PROMPT_COMMAND。trap DEBUG/RETURN を用いて変更検知
    |   関連: #D1124, #D0737
    |   x DEBUG はコマンド直前の実行なので最終行での書き換えは防げない
    |   x RETURN は rcfile 末尾では発生しない
    |
    | f PROMPT_COMMAND の読み書きを hook する(非ネイティブな)手法はあるか?
    |   x ない
    |
    | g 他の hook/trap を用いて適切なタイミングを検出?
    |
    |   a EXIT はシェルが終了する時なので使えない
    |   b command_not_found も使えない
    |   c kill -USR2 $$ によるハンドラは?
    |     x 試すと rcfile 終了を待たずに次のコマンドですぐに実行される
    |     x kill ... & として別プロセスから投稿しても同様
    |   d bash (execute_prompt_command) を確認したが介入点は他になさそう
    |   e PS1 に kill 等を埋め込んで通知させる
    |     x これは PROMPT_COMMAND よりも信頼できない
    |
    | h PROMPT_COMMAND の中の最初のコマンドを DEBUG で検出?

    可能性があるとすれば h の手法である

    * trap DEBUG/RETURN の性質を熟知していないとユーザの設定した
      DEBUG/RETURN と干渉しない様にするのは難しいと考えられる。
      これは DEBUG/RETURN の枠組みを整えてからにする必要がある。

    rcfile で ble.sh をロードした時には rcfile を抜けた後の
    PROMPT_COMMAND 直前でアタッチを行う。

    * "PROMPT_COMMAND の最初のコマンド" は恐らく判定可能である。

      rcfile 及び最初の PROMPT_COMMAND 内にいる時は BASH_LINENO の最後の
      要素は0 になっている。rcfile 内にいる時は FUNCNAME の最後の要素は
      "source" になっている。更に bash-4.4 以降では rcfile から
      PROMPT_COMMAND に移る時に $- に s が追加される。

      PROMPT_COMMAND で何か実行するならば、最初のコマンドは必ず
      FUNCNAME[-1] != source になっている筈である。

    対話シェルで ble.sh をロードした時は "bashrc を抜けた直後" という戦
    略は使えないが、HISTCMD, ${_histcmd@P} を用いてユーザコマンドか
    PROMPT_COMMAND かの判定が可能である。

    * HISTCMD は ユーザコマンドを実行している時には $(history 1) の最初
      の要素に一致する。PROMPT_COMMAND を実行している時には常に 1 になる。

    * HISTCMD が unset されている場合には代わりに _histcmd='\!';
      "${_histcmd@P}" が使える (bash 4.4)。HISTCMD が unset されているか
      どうかは HISTCMD=A して値が変化するかどうかで判定できる。

2020-08-27

  * 真面目に宣伝など考えるべきなのかもしれない。

2020-08-03

  * README: bashrc 設定方法の更新
    関連: #D1382, #T0004

    最終的には bashrc の何処に ble.sh を記述しても動くようにしたい。取
    り敢えず、比較的信頼できる手法が確立するまでは README の load 方法
    はそのままにしておく。

  * macOS で遅いという話 (reported by tigger04)
    https://github.com/akinomyoga/ble.sh/issues/58

    チェック項目は…

    * complete -r の代わりに
      shopt -u progcomp を指定したら改善するか?

    問題になっている可能性がある処理は
    ble/complete/progcomp/.compgen の builtin compgen 経由で呼び出される。
    特にユーザの定義した関数・コマンドは以下の関数経由で呼び出される。
    - ble/complete/progcomp/.compgen-helper-func
    - ble/complete/progcomp/.compgen-helper-prog

    上記の関数に benchmark を設定して stackdump なり何なりを計測する?

    ble/function#advice \
      around ble/complete/progcomp/.compgen-helper-prog \
      ''

    * 対策としては auto_complete の時には progcomp を実行しない
      というオプションを追加するというのが一つの可能性。
      bleopt complete_auto_progcomp=1 という事にするのが良い。

      実現可能性について。
      現在の呼び出し文脈が auto_complete かどうかを判定する必要がある。
      確認してみると comp_type に auto を含めている様である。
      実際にそうなっているのか確認する。

    情報をメールで貰った。
    メールではどの期間だけ complete -r を除いていたか分からないとしているが。

    2020-08-05 05:12:50 IST
    2020-08-05 05:13:27 IST
    2020-08-05 08:43:54 IST
    2020-08-05 08:43:57 IST
    2020-08-05 11:02:53 IST

    まあ、どの期間だけ有効になっていたのかという情報は実はそんなに重要ではない。

    眺めていて気づいた事。

    最後にユーザが入力を行ってから auto-complete が起動するまでに一定の時間がかかっている。
    大体 200ms の様な気がするが、しかし時間帯によって変わっている気もする。
    TAB 補完の場合にはこの delay が存在していない (0.06s) 事を考えると、
    これは history 補完にかかる時間という事だろうか。
    history 補完を無効にしたらこの delay は少なくなると判断して良いだろうか。

    補完が走らずに入力できている部分は history に match している入力であろう。

    どうも後半で時間がかかっているのは history の様に思われる。
    TAB 補完の時には 150ms 程度の遅延だが自動補完の時には 600ms に増えている。
    然し、その後で 200ms 程度に減少したりもしている。
    うーん。或いは単語の展開に時間がかかっているのかもしれない。

    * reject: 取り敢えず history 展開について高速化できないか確認する。

      | search-history-heavy について改善できないか考える。
      |
      | a 特に bash-5.0 以降では history -d range を用いて削除した上で
      |   history -p を実行すれば高速に過去の履歴を読み出す事ができるのではないか。
      |   →と思ったがよく考えたらどの範囲を削除したら良いのか不明である。
      |
      |   !string で一致させてその後その候補が当て嵌まらないと分かったとする。
      |   この時その候補以降の履歴項目を全て削除してから再度 !string で
      |   一致させれば良い様に思うが、最初に一致した候補が何番目の履歴項目か
      |   という情報がないのでどの範囲を削除したら良いのかが分からない。
      |
      |   a 例えば二分法で探索する? と思ったがこれだと二分の一の確率で
      |     サブシェルを生成しなければならない。明らかに非効率的である。
      |     或いは履歴展開に履歴番号も一緒に展開させる方法があったろうか。
      |     ない気がする。
      |   b やはり履歴番号を抽出できないかと思ったが、その様な履歴展開はやはりない。
      |     !string で一致させて単語指示子で履歴番号に置換できれば良かったが
      |     その様な単語指示子は存在しない。
      |   c 或いは、番号を指定しなくても一致した項目以降を削除する方法があれば良い?
      |     然し、history -d の引数はやはり数値であって履歴展開ではない。
      |
      |   この方針は難しいのではないかと思われる。
      |
      | b 或いは、history | grep を用いて最後に一致した項目を取り出す事ができるのではないか。
      |   但し、grep の時の問題は行区切りをどうするのかという事。
      |
      |   grep -z を用いれば NUL 区切りで判定する事が可能。
      |   然し、これは GNU extension である。安易には使えない。

      →うーん。調べてみたがちゃんと history search を呼び出す時に
      stop_check を指定しているのでユーザの入力があった瞬間に復帰する筈である。
      つまりこれ自体に時間がかかっていたとしても動きが遅くなる事はない筈?

      そもそも complete -r で解決したという事を考えると明らかに history は関係ない。

      然し、実際に timing log を見るとユーザの入力が待機されている…という事はない様な気がする。
      やはり現在の情報では history からの自動補完が問題になっていると考える根拠がない。
      従って、(不自然な方法を取ってでも) history 展開の高速化方法について考えるのは不毛である。

    * 再び報告があった。コンピュータ自体の処理が重くなっている時に動かなくなるという事らしい。
      普通に bash を動かしている時には問題ないという事を考えるとファイルアクセスが怪しい。
      ファイルアクセスしている箇所は沢山ある。特に着色のためのパス名展開である。

2020-06-04

  * 行数が極端に少ない時の動作 (横スクロール)
    bash-5.1 では横スクロールモードに移行するそうだ。

    そもそも現状で一行しか使える行がない時に何が起こるか。
    実際に試してみると (line 1) という表示だけになって
    更にその上に何か表示しようとするのでまともに表示できない。
    2行の場合にもまともに動かない。vi-mode の mode name で 1 行消費している為である。
    3行の場合にようやくまともに動く様になるが、それでも vbell が上に被ってしまう。

    横スクロールまで実装しないとしてもまともに動作する様にはしたい。
    そもそも (line N) という表示を省略する様にする?
    現状の実装ではプロンプトは必ず表示する様になっている。
    然し、プロンプトを表示するからこそ変な事になっているのである。

    a 行数が 1 になった時にはそもそもプロンプトを表示しない?
      然し、それだとプロンプトが何も表示されなくなってしまってそれはそれで変だ。

    b プロンプトは固定で残りの部分で文字列を編集する?
      これだとプロンプトが画面よりも長い時に何もできなくなる。

    c プロンプトも一緒に横スクロールする?

      | これに対応する為にはプロンプトの内部の各文字の配置を追跡する必要
      | が出てくる。
      |
      | Bash native でも \[...\] を使っている場合にどうやって数えるのだ
      | ろう? という疑問が残る。
      | →bash の動作を見たところ、prompt も一緒にスクロールする。しかし
      | prompt の途中位置でスクロールが止まる事はない。つまり、prompt は
      | 全体が表示されるか全く表示されないかのどちらかである。
      | →prompt 自体の長さが画面の横幅よりも大きい時には、常に横スクロー
      | ルした状態になってしまい、コマンドの1文字目は常に '<' に隠れて表
      | 示されない状態になる。また表示の乱れも発生する。

      Bash は横スクロールによってプロンプトが表示されるか、全く表示さ
      れないかのどちらかの状態になる。中途半端にプロンプトが表示されて
      いる状態はない。プロンプトの長さが画面の長さよりも大きい場合は対
      応しきれていない。

    * プロンプトが範囲内に収まらない場合には何が起こるのか?
      プロンプトの trace の時に高さを制限していただろうか。
      →駄目。制限はしていない。そもそも制限する事自体が自然な動作なのかも分からない。
      リサイズした時に上に流れた情報を参照したいという場合を考えれば、
      プロンプトは制限せずに上に流れてしまうという振る舞いが自然の気がする。

    現在のスクロールの実装はプロンプト行の次以降で実施する前提になっている。
    つまり画面の高さが1行しかない場合には色々弄らなければならない。
    プロンプトが複数行ある場合にはそれだけ多く画面の高さが必要になる。

    * プロンプトの出力は気にせずに実施する。画面がスクロールしても気にしない。
      →これを実行するとその他の panel の描画位置もずれてしまう事になる。
      他のpanelの内容を上書きしないように事前に空行を挿入しようにも、
      空行を挿入した時点で他の panel の内容が反対側の端から流れてしまう。
      という事を考えると、行数が厳しい時には他の panel は全て潰すのが現実的。

      潰す条件がプロンプトの高さが一行に収まりきらない場合、というのは
      プロンプトとして変な物を指定する場合を考えると制限が強い気もするが、
      その様な場合は余りないと考えればそれでも良い気もする。

      因みにプロンプトの高さが1行に収まらない状況としては、
      プロンプト自体に改行が含まれている場合以外にも、
      プロンプト内に長い文字列が含まれていて何度も折り返す場合を含む。

  * util: ble/dict#* を用意する可能性?

    設定ファイルの自動アップデートの実装に関連して
    ble/dict#* という物を作成しても良いのかもしれないとも思う。
    既に辞書的な構造は ble.sh の各所で個別に実装して使用している。

    辞書の bash-4.0 未満における最適の実装は何だろうか。
    任意の key を取り扱える様にする必要性を考えると、
    : 等を区切りにして scalar に key を格納する訳には行かない。
    そうすると配列に key を格納する必要が出てくる。
    配列が巨大になってくると重くなってくる。

    a 簡単な hash を作るという手もあるだろうか?
      例えば配列サイズが小さい時には最初のバイトだけを使って、
      要素が増えてきたら n 番目のバイトまで使って hash を生成する。
      と思ったがそれだと共通の接頭辞を持つ key が沢山ある時に hash が衝突する。
      例えば /home/murase/... という物が沢山ある場合。

    b 或いは全ての文字を用いて hash を計算する?
      という事にすると今度は長い文字列に対して各文字について文字コードを取得する手間がかかる。
      特に bash-4.0 未満では色々面倒な事をする。何れにしても ble/util/assign を使うので遅い。
      (実際にこれでキャッシュをしていないのは下手にキャッシュするよりも ble/util/assign
      を実行した方が高速であるという事からであろうという気がする。)

    c key の sorted list を管理する。
      文字列で辞書順でどちらが速いかについては [[ str < str ]] で判定できる。
      後はアクセスの度に二分探索を実施すれば良いのである。
      挿入には結構時間がかかりそうな気もするが、まあ、大丈夫。
      然し、よく考えたら bash-4.0 未満の配列はアクセスが線形時間だった気がする。
      という事を考えると二分探索よりも線形探索の方が実は良いのかもしれない。

    使用ケースによって色々なので汎用的な実装はやはり難しい気がする。

    * key が整数の場合には普通に配列を使えば良い。

    * key が有限の単語 (識別子) の集合であれば、
      local apple=1 banana=2 pineapple=3 orange=4 等の様にして、
      普通に arr[apple]=red 等とという風にすれば良い。

      或いは普通に変数に保存すれば良い。
      eval "arr_$key=red" という具合である。
      この場合大量の変数が散らかってしまうが、
      それが気にならなければ最良の気がする。

    * key に ":" が含まれない場合には
      keys にコロン区切りの key の集合を保存しておいて、
      head=${keys%%:$key:*} head=${head//[!:]} 等とすれば
      key が何番目の要素であるかというのを取得する事ができる。

    * key が文字である場合も同様にして
      head=${keys##"$key"*} 等としてから ${#head} で文字数を見れば
      それが何番目の要素であるかというのを判定する事ができる。

    * 辞書をメモ化に用いている場合には実は関数自体の計算時間が
      bash による辞書の模倣よりも速い可能性を考えるべき。
      例えば ble/util/s2c については ble/util/assign printf %d '$c の方が
      下手な辞書よりも高速なのである。

    * key の種類がそんなに沢山でない場合には、
      key を配列に格納して線形探索するというので良い。
      これが最も単純で自然な実装になる。

      key を sorted list に入れて二分探索するという可能性もあるが、
      Bash-4.0 未満の配列のランダムアクセスは線形なので、
      それよりは普通に線形探索で舐めた方が良い気がする (実測すると違うかもしれない)。

    結局使用ケースによって最適な実装方法が異なるという事から統合は難しい。
    ble.sh の内部で使わない以上は用意しても仕方がない様に思われる。
    そもそも ble/dict#... の形式による配列アクセスは文法的にそんなに綺麗でもない。
    等の事を色々考えると、ユーザの為に用意する程でもない。

2020-05-20

  * 破壊的変更と後方互換性

    * done: keymap_vi_nmap_name は keymap_vi_mode_nmap_string 等に改名するかもしれない。
      或いはもっと別の名前? やはり keymap_vi_mode_normal で良いだろうか。
      改名するとしたら complete_stdin_frequency と同様に別名に書き換える様にする。
      実はオプションの改名について枠組みにしてしまっても良いのかもしれないという気がする。

    * 勝手に古い設定を書き換える機能を作っても良いかもしれない。
      毎回一行ずつ書き換えを実行するのではなくて、
      書き換えを実行する sed スクリプトを貯めておいて、一括で書き換えを実行する。
      cp a a.bk && sed "$script" a.bk > a 等の様に実行する。

      sed スクリプトは何処に貯めて於けば良いのだろうか。
      書き換え対象のファイル名と一対一に対応するファイル名にする必要がある。

      a 辞書にファイル名を記録するか或いは hash を用意するか。
        hash は計算に時間がかかるので辞書にファイル名を記録するのが良い気がする。
        然し、bash-4.0 未満ではどの様にするのが良いのか微妙である。

      b 或いは、別に辞書など作らなくても直接ファイルシステム上に書き出しても良い気がする。
        つまり、 "$file.sed" に書き出して置いて、それを適用して削除する。という具合にする。
        問題はファイル名が被らない様にするという事。乱数で決定する事にすると駄目。
        "$file.__BLE_REWRITE__.sed" 的なファイル名にするのが良いのではないか。

    * ble{-edit => }/prompt/{print,process-prompt-string,backslash} についても
      警告を表示する様にする仕組みが必要になる気がする。

2020-05-16

  * TERM=alacritty で何か変な事が起きるらしい。
    https://github.com/rux616/init/commit/b03e7ef3dab5171d1f60aa61323ef823401217d5#diff-0af95dc8119f1c458b7a0fd76dfe8042R37-R39

    調べてみると alacritty:extra/alacritty.info が terminfo らしい。tic -x extra/alacritty.info で入れる。
    然し、何も問題は起きていない様に見える。256color もちゃんと動いている。ずっと使っていると発生する問題だろうか。
    これは時間があれば rux616 に何が起こるのか尋ねても良い。
    所で、いつの間にかに alacritty は jwilm/alacritty から alacritty/alacritty に移動したらしい。

    →cache/alacritty.term を確認した所 ich, ech, dch が空になっている。
    然し、ble.sh は ich, dch は使っていない。ech を使う場合でも、
    [[ $_ble_term_ech ]] の時にのみ有効になる様になっている。

    他に気付いたのは 8-15 の着色が 0-7 と同じになっているという事。
    然し実際に tput で tput setaf 15 とすると CSI 9 7 m になる。
    何かが間違っている。再度実行してみた所、問題なく初期化された。
    と思ったら alacritty.term と xterm-256color.term の内容が同一になった変だ。

    続けて何度試しても問題は発生しない。何が起こったかは謎である。

2020-04-25

  * trap: DEBUG trap を用いて DEBUG trap を再現できるか? [#T0003]
    参考: #M0016

    つまり関数呼び出し毎に DEBUG trap が設定されるというのを実装する必要がある。
    ble.sh が使っていなければ特に問題は発生しないが、
    INT を受信した時に ble.sh が DEBUG trap を設置する事になっている。
    従って、実装できれば実装するのが良いという様に考える。

    要件は以下の通り

    * 何も DEBUG trap が設定されていない時には overhead 0 にする。
      つまり builtin trap で何も設定されていない状態にする。
      ユーザか ble.sh のどちらかが何か設定している時に有効にする。

      実のところ、ble.sh の使い方は一時的な物なのでユーザの trap と
      同レベルの取り扱いで良いという気がする。唯単に trap で列挙されない、
      ユーザの設定した trap も保持する、という事が異なるだけ。

    * 関数呼び出しでの継承・非継承を再現する。
      実はこれはそのまま bash の継承・非継承に従うだけで良い気がする。

    * 呼び出し元への影響についても再現する。
      これは新しく trap DEBUG が呼び出される時に、
      builtin trap DEBUG もやり直せば良い?
      と思ったがそもそもそんな事をする必要もない気がする。
      現在のフレームに既に何か設定してあるという事は
      呼び出し元ではそれが必ず有効という事だから。

      bash-4.3 以下では何れにしても呼び出し元に影響を与える事はできない。
      うーん。bash-4.3 以下では trap DEBUG で保存した trap handler を
      関数が抜ける時に削除する必要があるという気もする。
      これについては実装時に注意深く実装すれば良いだけ。

    * DEBUG trap の中で DEBUG trap は設定できるが発火しない。
      BASH_COMMAND は書き換わらない。

    実の所、DEBUG は C-c の時にしか設定していないので、
    取り敢えず気にしない事にする。

    先ず試験的な実装を作成して見るのが良い気がする。

  * trap: INT
    現在の実装ではユーザの設定した INT で握りつぶしても、
    ble.sh の設定したハンドラによって実行が中断される。
    ユーザが INT を設定している時には握りつぶさない様にするという手もある。

  * [保留] bash-4.4 trap 内無引数 return の修正

    ref #D1350

    bash-4.4 以降では trap 内の無引数 return は trap handler が開始する直前の $? を返す。
    強制的に trap handler の内部での直前の $? を返す様にする方法はあるだろうか。

    * return() { builtin return $?; } とする案
      x 本来の return を実行する方法がない。
        RETURN trap を使って return 関数呼び出し後に builtin return できないか?
        x RETURN trap は抑も終了しようとしている関数内の文脈で実行される。
        x RETURN trap 内部では RETURN は発火しない。
    * alias return で何とか無引数の場合を $? に置き換える事は可能か。
      x 引数がある場合とない場合の両方に alias で対応するのは難しそう。

2020-04-19

  * history: 履歴の管理の枠組みで欲しい物

    1 実行したコマンドを追記で記録する仕組み (勝手に編集したりしない)
      他のシェルと同様に追加の情報も記録する?

      * 実行したディレクトリ。実行した時刻。$$.$LINENO

      * コマンドラインに含まれる有効なファイルパスの集合

        | fish はこの情報を用いて history autosuggestions の時に
        | コマンド履歴のフィルタリングを実行する様だ。
        | 然し疑問なのは echo > a.txt で a.txt など出力ファイルが元から存在していた時には、
        | 新しくファイルを作成したいという時にその履歴が候補に出てこない、
        | という事態になってしまうのではないかという事。
        |
        | その様に考えるとやはり実は個別のコマンド毎に判定した方が良いのではないか。
        | 例えば cd の場合には使い方が決まっているので、
        | 実際にそのコマンドラインを実行した時に成功するか失敗するかはすぐに判定できる。

        自動補完のフィルタリングに関しては完全な判定はできないので
        取り敢えず core でサポートしなくても良い。

      * zsh は実行にかかった時間も記録する様である。

        | 然し、これは微妙。何故ならば bash ではコマンドの実行開始前に履歴を追加するから。
        | 実行後に書き換える仕組みが必要になる。或いは開始の記録と終了の記録を別々にする?
        | そうすると複数のセッションで実行している時に互い違いになってしまう。
        | なので実行するコマンド毎に ID を設定する必要がある気がする。
        | と思ったが ID は $$.$LINENO 等で良い気がする?
        | x と思ったが同じ PID でシェルが起動する事もあるのでは?
        |   o と思ったが同じ PID で複数のコマンドを同時に走らせるという事はないので問題ない。

        開始と終了をそれぞれ記録する。$$.$LINNO でコマンド毎に ID を設定して対応を取る。

    2 記録されたコマンドとは別に bash の履歴で遡れるコマンドのリストを管理する仕組み。
      こちらは長いコマンドを自由に削除したりできる様にする。
      倍加したりすると嫌なので枠組み 1 で得た差分に基づいて更新する?
      差分を取る方法を気をつけないと結局倍加するので、
      ちゃんと同期して差分を取れる様な枠組みを整理する。

2020-04-09

  * 別の bash の枠組みについて
    https://github.com/sio/bash-complete-partial-path
    https://github.com/mgalgs/fuzzy_bash_completion
    https://github.com/brujoand/sbp

2020-04-02

  * test: テストフレームワークの追加機能

    * 単体テストの機能
      * テストを直接本体の関数の近くに書き込める様にする?
        これは mwg_pp.awk の枠組みを用いた対応が必要である。というか出力
        先が ble.osh と分かれている場合を考えると、#%$> の右辺に変数を指
        定するべき? と思ったが #%$> を含む行自体をマクロに入れれば良い。

    * テスト集合の管理
      * 集計・サブシェルで実行した結果も扱える様に。
      * テスト結果のキャッシュ
      * 並列テスト
      * 様々な bash の version の結果を集計

    * 他のフレームワークの機能を確認
      * bats
      * oil/test
      * shellspec
        kcov を用いて coverage が計測できる
        skip を設定できる。前回成功したものをスキップできる。

    * GitHub 用に Travis を設定する。

2020-03-22

  * read -t や read line の戻り値が変だ
    →今試してみると別に変な事はない。-e が入っていても入っていなくても。

    一応 C-c で read -e を止めた時の終了ステータスは 130 の所が
    ble.sh の実装では単に 1 になっているという違いはある。

  * bash-3.0 が malloc array.c botched というエラーが出てクラッシュした。
    これは bash のバグである。そして古いバグなので治りそうにない。
    更に言うと再現性もあるのかどうか微妙である。

  * oilshell で色々説明を行った。
    それらの説明へのリンクを作成して後で纏めるのが良い気がする。
    これは後で実行する。

  * decode: 大量の貼り付けの高速化4 (report by dylankb)

    現状の ble.sh の枠組みの中では大幅に改善した。
    然し、やはり decode を自前でやっている。
    そもそも decode の結果を整数の列にする時点で遅い。

    bracketed paste だと分かった時点で、
    stdin から文字列として読み取って、
    文字列としてそのまま挿入する等の事が可能な筈なのではないか。
    そうすれば無駄な処理をする事なく即座にエディタを起動できる。

    現在の nonblocking-read の実装に
    bracketed paste を検出する機能をつけて
    bracketed paste の処理中にはそれを使って
    良い感じに実行すれば良いのだろうか。

2020-03-11

  * __line_limit__ の実装の制限

    1 replace-limited を直接呼び出している箇所については確認したが、
      replace-limited が .replace-range を通して呼び出している時、
      外側で ind, mark を設定していると計算がずれて範囲外になる可能性がある。
      特に vi で .replace-range を多用しているが面倒なので細かくチェックしていない。

    2 容量超過でもコマンドラインが短縮されていない場合
      (これは isearch の途中などで起こりうる)
      複数のキーから為るキーシーケンスが間に入る __line_limit__
      によって無効化される。

      これの対処方法として mouse_move と同様に特別に
      __line_limit__ を keyseq に属さないキーとして取り扱う方法がある。
      然し、現在ではチェックが非効率になるので対応していない。
      或いは keyseq に属さない keycode の範囲を定義して、
      その範囲で判定できる様にするのが良い気がする。
      (その様なキーは実は沢山ある)

  * history: fish の autosuggestions はファイルが存在しない履歴項目はスキップする (suggested by cole-h)
    https://oilshell.zulipchat.com/#narrow/stream/121540-oil-discuss/topic/autosuggestions

    うーん。どうやら fish は履歴を保存する時にその時に使った有効なパスも一緒に記録する様だ。
    Bash はそれを記録しない。という事は ble.sh が代わりに記録する等の工夫をする必要がある。
    然し、ble.sh が代わりに記録するという事になると履歴の一貫性を保つ為に工夫が必要になる。
    或いは、ble.sh の履歴を本体として bash の history は全部それを元に再構築する?
    その様にするしかない気がする。

    或いは cmdinfo:color の実装が完全であれば、わざわざ履歴を見て
    ファイルパスかどうかを判定しなくても、それが有効な履歴かどうかを判定する事が
    可能になる。特に cd に関しては簡単に判定する事ができる筈である。
    という事を考えるとわざわざ実装する必要はないのかもしれないとも思う。

2020-02-02

  * vi mode の時は read も vi mode になっているべきではないのか?
    と思ったが vi mode にはコマンド実行等の色々と
    危ない機能も沢山ついているので、寧ろ cmap を使うべきで、
    然し、cmap を使うのだとしたらそれは殆ど現状の read の様な物だ。

    これはその内に request があるかもしれない。その時に対応する。

    と思ったが既定の readline では vi-map が使える様になっている。
    コマンド実行等はどの keymap に定義されているだろうか。
    或いは accept-line や edit-and-execute-command の意味を差し替えられる様にするか。
    そちらの方が現実的である様な気がする。

2020-01-26

  * progcolor: 非同期で実行できる様にする可能性?
    場合によっては重い計算が必要になるかもしれないし、
    実は非同期で実行しても良いのではないかという事。

  * progcolor: redirect の場合にも対応したい
    実は補完の時にも redirect をプログラム補完しても良いのでは。
    但し、補完と着色で違うのは補完は一つの単語について呼び出されるのに対して、
    着色は一度に複数の単語を着色する事があるという事。
    補完に関しては引数とリダイレクトを別々に処理すれば良いが、
    着色の場合には一度に処理できる様にしたい。

  * progcolor: here document にも対応したい。
    here document に対応するコマンドを抽出する事は可能か?
    →here document は開始部分に対する参照を確か持っていたのでできる筈。

    実際にユーザは何を提供すれば良いのか。
    ble/cmdinfo/color:XXX を呼び出す様にするのか。
    然し、それだとそのコマンドの引数が変更される度に、
    対応する heredoc を抽出する必要が出てくる。それは面倒だ。
    或いは、heredoc に変更があった時に着色するだけで良いのでは。

    というか heredoc は単語ではない。でも一つの nest ではある。
    うーん。然し wrange に登録しているかは謎。
    その辺りも整理しつつ実装すると良い。

  * progcolor: コマンド自身が書き換えられた時には
    全ての引数について再度着色の確認が必要になるのではないか。

2020-01-23

  * 前々から発生していたが曖昧補完などを実行すると時々ごみが残る。
    これは何故だろうか。そもそもカーソルよりも右に何か文字列が入るはずがないのに?

    再現させようとしても再現できない。
    これは実際に起った時に再度確かめる必要があるのである。

2020-01-21

  * lmorg/murex という新しいシェルの対話環境

    https://github.com/lmorg/murex

    このシェルは POSIX 互換でないので微妙。
    パス名展開をするのに面倒な指定をしなければならない。
    既存の様々なツールと相性が良いかというと微妙な気がする。
    しかし fish や PowerShell よりは unix shell よりである。

    一方で対話インターフェイスに関しては色々工夫している。
    入力していくと一行下に現在入力しているコマンドの説明が表示される。
    何も入力していない場合は git リポジトリの情報を表示している。
    (然し、なにか入力するとすぐに消えてしまうので何処まで使いやすいかは分からない)
    kill まで入力すると補完候補としてプロセス ID を表示してくれる。
    プロセス ID に対してコマンドラインを説明として表示している。

    * 所で ble.sh ではメニューの形式は事前にユーザの側で指定する事になっている。
      然し、これは微妙な気がしてきた。というのも説明文があるかどうかの情報は
      補完生成側が知っている事である。なので、補完候補生成器の側で、
      メニューの表示形式を上書きできる様にするべきなのではないかという気がする。

2020-01-17

  * Minix で無限ループになっている?

    echo と入力しようとすると確率的に無限ループになる。
    (それでも可也高い確率で無限ループになる。)
    auto-complete を off にしても発生する。
    menu-filter を off にしても発生する。
    という事は着色か或いは。。

    調べてみると暴走しているプロセスは別の Bash だという事が分かった。
    恐らく子プロセスで暴走している。何が悪いのだろうか。履歴?
    →履歴はちゃんとロードできている。その後で暴走する。
    →再度確かめたらやはり子プロセスの暴走としか思えない。
      と思ったがよく見ると親プロセスの暴走だった。両方で起こる?

    2020-02-03 新しい ble.sh を実行しているが固まるという現象が再現しない。
    これは新しい ble.sh のお陰だろうか、それとも偶だろうか。
    →暫く使っていたが全く再現しないので以前の ble.sh の問題と思って良いだろう。

    と思っていたら実は裏でちゃんと無限ループになっていた。
    どうも ssh が予期せず切断すると無限ループになる?

    気になるのは暴走していたプロセスは stderr にリアルタイムで
    データを出力し続けていたという事。

    | -rw-r--r--  1 murase  users  14174140 Feb  3 21:58 5726.stderr
    | -rw-r--r--  1 murase  users  14324924 Feb  3 21:59 5726.stderr
    | -rw-r--r--  1 murase  users  14504088 Feb  3 22:01 5726.stderr
    |
    | 出力内容は以下の通り 0d 1b 5b 4b の 4B を繰り返し出力している。
    |   $ < $_ble_base_run/5726.stderr od -t x1
    |   0000000   0d  1b  5b  4b  0d  1b  5b  4b  0d  1b  5b  4b  0d  1b  5b  4b
    |   *
    |   67250220   0d  1b  5b  4b  0d  1b  5b  4b
    |   67250230
    |
    | 0d 1b 5b 4b とは何か? \r\e[K である。CR EL である。うーん。
    | ble.sh の該当しそうな部分を調べてみる。
    |
    | * canvas:344 (negative cup:el)
    |   ble/canvas/put-cup.draw 1 $((x0+1))
    |   ble/canvas/put.draw "$_ble_term_el"
    | * canvas:1928 (negative sgr0:cr:el)
    |   ble/canvas/panel#goto.draw "$index" "$x" "$y"
    |   ble/canvas/put.draw "$_ble_term_el"
    | * edit:1520 (negative sgr0:cr:el)
    |   ble/canvas/panel#goto.draw "$_ble_textarea_panel" "$fminx" $((fminy-new_scroll))
    |   ((new_scroll==0)) &&
    |     x=$fminx ble/textarea#render/.erase-forward-line.draw # ... を消す
    | * edit:1680 (negative sgr0:cr:el)
    |   ble/canvas/panel#goto.draw "$_ble_textarea_panel" $((cols+1)) "$y"
    |   ble/canvas/put.draw "$_ble_term_el"
    | * edit:1696 (negative sgr0:cr:el)
    |   ble/canvas/panel#goto.draw "$_ble_textarea_panel" "${pos[0]}" "${pos[1]}"
    |   ble/canvas/put.draw "$_ble_term_el"
    | * edit:3869 (negative cuf:sp:sp:el)
    |   ble/canvas/put-cuf.draw "$advance"
    |   ble/canvas/put.draw "  $_ble_term_cr$_ble_term_el"
    | * edit:7322 (negative cr:el:sgr)
    |   ble/canvas/put.draw "$_ble_term_cr$_ble_term_el${_ble_term_setaf[9]}"
    |
    | うーん。何れも関係なさそうな気がする。
    | もしかして _ble_term_el2 に CR EL が入っている?→確認したがそうでもない。
    | 上の中で一番怪しいのは panel#goto.draw だと思ったが、
    | sgr0 が消滅している理由が分からないし、
    | 一度 CR を出したら _ble_canvas_x=0 になるのだから、
    | 何度も CR を出力し続けるのは変だ。

    暴走した bash は何れも console ではなくて pty だった。
    接続が途中で落ちると無限ループになるのだろうか。
    hp2019 側及び vmminix 側で nc/sshd を kill -9 しても再現しない。

  * 英語圏のニュースサイトに投稿する可能性 (suggestion by dylankb)
    Hacker News を紹介されたがここが適切なんだろうか?

    reddit に投稿した話がある。
    https://rcmdnk.com/blog/2014/02/23/computer-bash-zsh/

    単にリンクを貼るというのでも良いけれども。
    やはり様々な機能を惜しげもなく紹介する
    長い記事を書くのが良い気がする。

    →返信で自分の作品を投稿する時のルールの頁があった。
      なるほど。やはりルールがあったのである。危ない所である。
      https://news.ycombinator.com/showhn.html

      これによると作品の紹介は一度きりしかできないとの事。
      > The community is comfortable with work that's at an early stage.
      と書かれているがまさかこれは初期の作品でなければならないという訳でもあるまい。
      > Blog posts, sign-up pages, and other reading material can't be tried out
      と書かれているが…。使い方の説明記事の様でも駄目なのだろうか。
      Blog posts でなければ良い? 或いは README を派手に改造してしまうという手もある。

    https://news.ycombinator.com/shownew
    ここを観察していると "Show HN: 作品名 ― 説明" という名前の物が多いが、
    実は "Show HN: 今〇〇なのを作っているんだけど" というタイトルの物の方が upvote が多い。
    "作品名 - 説明" だといかにも宣伝という感じで入る余地がない気がする。
    一方で "〇〇なんだけど" みたいに書くと "自分も何か貢献できるんではないか" と錯覚して人がたくさん来る。
    そういう仕組になっているんだろうという気がする。

    * reject: "Show HN: Bash Line Editor -- syntax highlighting, autosuggestions, etc. in Bash"
      これは普通。つまらない

    * "Show HN: I am developing a line editor in pure Bash script. I'd like to hear your comments!"
      これだと面白そうとは思ってくれるかもしれないけれど使ってくれる人は少なそう。
      後 explicit にコメントが欲しい! という事をタイトルに書いても良いのだろうか?
      眺めてみるとそういう投稿はない。やはり雰囲気が分からないのである。

    * reject: "Show HN: I made syntax highlighting, autosuggestions, etc. in Bash"
      これも普通。つまらない

    * "Show HN: "Bash Line Editor" with syntax highlighting, autosuggestions, ... written in pure Bash!"
      やはり宣伝っぽい。

    * "Show HN: Bash Line Editor -- syntax-highlighting, autosuggestions and vim emulation written in pure Bash"
      vim と書くと他のエディタを使っている人やシェルでは別に vim は使わないという人が敬遠してしまわないか?
      然し話題に乗るという事だけであればその辺りを無視して投稿しても良い気がする。

    * reject: "Show HN: I wrote a line editor (syntax highlighting, autosuggestions, vim amulation, etc.) in pure Bash script"
    * reject: "Show HN: I wrote a line editor in pure Bash script which provides syntax highlighting, autosuggestions, vim emulation, etc. to Bash"
    * reject: "Show HN: Bash Line Editor written in pure Bash script for syntax highlighting, autosuggestions, vim emulation..."
      長い
    * "Show HN: Bash Line Editor totally written in pure Bash script"
      案外これぐらいの方が気を引けるのかもしれないと思う。
    * "Show HN: Bash Line Editor -- a next-generation Bash configuration"
      或いはこんな感じに煽った感じのタイトルにしても良い。zplug の真似
      でも技術的に面白いのは pure Bash script であるという事。

      "with syntax highlighting, autosuggestions, vim emulation" 等は書かなくてよい。
      書かない方が煽りになるのである。本当か? と思ってみんなリンクを開く。
      そしてどんな機能があるのかとみんな確認する。
      少なくともこれだけの物があるのだからがっかりする事はないだろう。

      でも落ち着かなければならない。Bash configuration と書くと、
      従来の PS1 や aliases や functions を包含する物と考えられてしまう。
      その様に考えると、Bash plugin と書いた方が良いか?
      或いは、plugin manager として突貫で他の物を取り込める様にするか、
      或いは README に強調しておくことにするか。

      というか Bash configuration というのが良くない。違う。
      もっと土台になるものなのである。
      実のところ "a next-generation Bash Line Editor" なのだ。
      然し line editor という意味では全然 next-generation ではない。普通だ。
      つまり Bash の設定にしては next-generation なのであって、
      line editor として next-generation な訳ではない。

      a next-generation Bash interface/infrastructure/extension/framework

      Framework としての側面も強調してよいのかもしれない。
      (或いは真面目にライブラリとして独立させても良い。
      decode 部分に関しては大幅に手を入れる必要があるかもしれない?)

    * "Show HN: I wrote a featureful line editor in pure Bash scripts"
      みたいな単純な物の方が気を引けるのではないかという気がする。

    調べるとスタートアップという文字が頻りに見える。
    投稿してみた感想を観察してみるとやはり何かのお誘いがある様である。
    タイトルに文字数制限は在るのだろうか。

    何れにしても今は忙しいので沢山の要望などが来てしまっては困る。
    従って暫くはこのまま放置するというので良い気がする。

2020-01-05

  * Homebrew の設定を作成する?

    先ず Linuxbrew (Homebrew for Linux) を ~/opt/linuxbrew に入れた。
    普通と違う場所に入れようとしたので色々問題が起こって時間を食ってしまった。

    * brew tap について調べてみる事にする。

      % brew tap akinomyoga/ble.sh を実行すると https でダウンロードしようとする。
      % brew tap akinomyoga/ble.sh git@github.com:akinomyoga/ble.sh.git とすれば良い様だ。
      % それから brew install を試そうとするがどうやっても動かない。
      % どれをやってもそんな formula は見つかりませんのエラーになってしまう。
      % もしくは tap を確認すらしない場合もある。不思議だ。
      % $ brew install akinomyoga/ble.sh
      % $ brew install akinomyogable.sh
      % $ brew install akinomyoga/homebrew-ble.sh
      % $ brew install homebrew-ble.sh
      % $ brew install brew-ble.sh
      %
      % $ brew tap
      % を実行してみると。自分が登録した物の他に homebrew/core がある。
      % homebrew/core は中に formula を沢山入れた repo の筈である。
      % もしやと思って調べてみる。
      %
      % https://qiita.com/wkentaro/items/d4981582e08b134f1e1d

      どうも user/name に対応して github.com:user/homebrew-name を作成して、
      その中に formula.rb を入れて置くという事になっている様だ。
      面倒なのでそれよりは直接 core に取り入れてもらった方が楽だ。

    * 自分で formula を作ってみるのを試す

      仕方がないので自分で formula を作ってみるのを試す事にした。
      $ brew create --set-name blesh

      全て自分で記入しなければならない様だ。適当に formula を作成してみる。
      sha256 は何の sha256 を記入すれば良いのか分からないのでコメントアウトする。
      結局分からないので以下を参考にして埋めてみる事にする。
      https://github.com/10sr/homebrew-pkg/blob/813de30c121e8dea970f11e7c1e63e57d3a6a0ed/Formula/ble-sh.rb_
      * ビルドは gawk に依存しているので gawk に依存させてみる。
      * gmake については調べてみた所 macOS ではデフォルトで GNU make だそうなので不要?
        然し、mac ではデフォルトで make が入っているのだろうか。
        或いは自分で追加で入れる必要があったりするのだろうか。よく分からない。

      と思ったが何処にも *.rb が作られていない。
      $ find ~/opt/linuxbrew/ | grep blesh
      で調べてみたら ~/opt/linuxbrew/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/blesh.rb
      に新しく blesh.rb が作成されていた。これを使う事にする。
      試しに $ brew install blesh としてみたら動き出した。
      gawk を入れるためにその依存関係まで全てダウンロードしてインストールしようとしている。

    ? brew では自分で何処かで入手した formula を使うにはどうすればよいのか?

    * homebrew-core に登録する為には test を用意しなければならないようだ。

2019-12-31

  * progcolor: 引数の中の着色 (zsh -c '...' の ... の部分)。

    いつか実装しようと思っていたら fast-syntax-highlighting が既に実装している。

    | fast-syntax-highlighting
    | →引数の中も着色すると思ったら '$(...)' の中も着色を行っている。
    | 然し、zsh -c '...' に関してはちゃんと zsh や -c を認識して着色している様だ。
    | 調べてみると awk もちゃんと文法的なチェックを行っている。
    | (→ うーん gawk --source '...' で文法チェックをできる様だ。)
    | sed に関しては行っていない。何れにしてもコマンド毎の着色を実現している。

    * コマンド毎の着色設定を指定できる様にした #D1245

    | 次に例えば awk に対応する事を考える?
    | 或いはそれよりは sh もしくは bash に対応する方が楽?
    | 色々考えてみたがちゃんと対応するのは可也大変である。
    | 先ず単語が単純単語でない場合にどの様に実装するか。
    | 等、色々難しい。既にある文法構造を利用して何とかできる可能性はある。
    |
    | awk に対応するとしても awk の様々な実装によってオプションなど異なる。
    | このオプションが異なっていると異なった着色になって、
    | ユーザに混乱を齎す。従って対応するとしたら完全に対応している時にだけ有効にする。
    | 何れにしても面倒である。awk よりは先に bash で対応した方が懸命ではないか。
    | awk の対応に関しては自分の blerc の中だけに留めておく。
    | その自分の blerc の中での awk の着色の設定で必要になると
    | 思われる補助機能をble.sh の方で実装する。

    * awk の着色対応を通じて ble.sh 側で支援の必要な機能を実装する。

    * 単純単語に関して。評価値を求める方法。
      評価値の各文字が元の単純単語のどの位置に対応するか。
      或いはその逆? どちらの方が適切だろうか。

      例えば引用符等に関しては対応する文字はないのでそのままの色が良い。
      従って評価後の文字に対応する評価前の範囲を取得すると良い気がする。
      然し、逆に評価前の $a が評価後に沢山の文字列になる事もある。
      その場合には評価後の各文字の色を評価前に割り当てるのは難しい気がする。

    * 対応する物がない文字をそのままの (下の層の) 色にする事は可能だろうか。
      恐らく getg 等で取得しなければならない。面倒である。
      或いは ble/highlight/layer:syntax では少し違う様に処理していた気もする。

    * 複雑な単語に関しては文法構造を利用する事も考える。

    * 現在の layer:syntax の枠組みでは一旦着色情報を wattr に格納してから、
      それを word table に対して適用するという仕組みにしている。
      この様にする事に何の意味があったのだったか?

      直接 word table に適用した方が早いのではないか?
      →これは何度も単語着色を求め直すのを省略する為である。
      つまり、単語着色を決定する部分と実際に適用する部分を分けて、
      前者をできるだけ省略する様にしている。

      実際に適用する必要がある場合でも前回求めた値を
      そのまま使えば良い場合があるという事なのである。

  * fast-syntax-highlighting の機能を確認する
    https://github.com/zdharma/fast-syntax-highlighting

    * コマンド毎の着色。オプションや引数が正しいかのチェックも行う。
      これは丁度 ble.sh で将来的に対応したいと思っている機能である。
    * 括弧の対応に応じた着色
    * gawk --source による文法チェック?

  * theme: 流石に theme を作った方が良い気がしてきた。
    少なくとも枠組みだけでも作って置くと良い気がする。
    と思ったが実際に例がないと枠組みの良い設計も分からない。
    zsh-syntax-highlighting はどうしているのだろうか。
    zsh-syntax-highlighting theme で検索してみる。

    どうも zsh-syntax-highlighting は theme を提供していない様だ。
    https://highlightjs.org/static/demo/
    ここは dark/light の両方を提供している theme があって参考になる。
    但し、ファイル名着色に使う色は色々調整しなければならないが。。

    fish の theme はあるだろうかと思って探すと。
    https://github.com/oh-my-fish/oh-my-fish/blob/master/docs/Themes.md
    どうもシェル業界では theme というのはプロンプトの事を指す様で。
    然し、fish のブラウザ設定画面ではタブは colors となっている物の、
    色々な設定の部分には theme という文字も見える。
    何れにしても theme というのは紛らわしいかもしれない。
    注意書きを書いておく必要があるかもしれない。

  * tui: TUI 設定画面?
    fish はユーザフレンドリーを謳っている。
    ブラウザで設定できるなど (リモートの場合には使えない気がするが)。
    ble.sh ではブラウザでなくても TUI で設定画面を用意しても良いのかもしれない。
    マウスサポートまですればブラウザでなくてもOKなのである。

    →fish の web 設定画面を確認してみた。
      実は theme と prompt が選べるだけだった。
      他は関数・変数・履歴・束縛・略語展開の一覧が見えるだけで、
      何も設定することはできないのだった。
      但し履歴項目の削除はする事ができる。
      略語展開も実は編集することができた。
    →theme に関しては配色が選べるだけで、
      具体的にどの色がどの意味というのは余り考えられていない気がする。
      適当に順番に割り当てただけなのではなかろうか?

    その様に考えると履歴の着色でも良いのかもしれない等と。

  * complete: 重い補完関数に対する対策

    * 曖昧補完の為に何度も progcomp を呼び出していて非効率的
      →無駄があると思ったが実際にどういう補完を行っているか調べると
      様々な補完点を試しているのだった。うーん。
      自動補完の補完候補がすぐに見つかる場合にはそんなにたくさん呼び出されない。
      補完交互が見つからない時には自動補完によって何度も補完が実行されて遅くなる。

      もしかすると自動補完を off にしたいという人は時間のかかる
      補完関数を使っているという事なのかもしれない。
      よく考えたら peco の類を設定している場合大変に面倒な事になるのでは?
      自動補完が実行される度に選択メニューが表示されてしまう。
      そもそも補完に peco を設定している時点で変ではあるが。

      色々な補完点で試すとしても現在の単語を 0 文字または 1 文字しか
      入力していない場合には、同じ状態で呼び出す事もあるだろうという気がする。
      その場合の為に compgen の呼び出し結果をキャッシュする利点はあるだろうか。
      つまり、同じ補完状態で再度呼び出される事を見込めるかどうかが問題になる。

    * 或いは、処理を非同期で呼び出すというのが良いのかもしれない。
      その場合には計算結果を何処かファイルに書き出す様にしなければならない。

      非同期で呼び出すのは -CF が設定されているときだけで良い。
      と思ったが -F の中で環境を変更したいという場合にはどうするのだろう。
      非同期で呼び出すという事にすると環境に対する変更が適用されない。
      これは bleopt で変更できる様にしても良いのではないだろうか。

  * complete: menu-complete 中の通常文字挿入は
    絞り込みに戻すのが良いのではないか。
    というか普通にキャンセルして挿入すれば絞り込みになるのでは?
    と思ったが menu-complete 状態からは抜ける事になる。

    後、suffix を挿入せずに確定する方法がなくなる。
    これについては別の操作方法について考えると良さそう。
    例えばスペースを押すと suffix 挿入を抑制して確定する等。

    →やはりこれは分かりにくいのではないか。
      fish, zsh の動作を確認してみたが menu-complete 中に
      新しい文字を入力すると何れも現在の選択肢を確定させた後に
      続きの文字が入力される様になっている。
      これらのシェルと異なる振る舞いをするのは良くない。

      だとすると絞り込みをする為には明示的に
      絞り込みのモードに入るキーを設定するべきなのでは。
      例えば M-e 等?

      因みに emacs で試してみると M-e, M-a は end/beginning of
      sentence 的な動作をしている様に見える。
      なので上書きしてしまっても良い様な気がする。
      うーん。でも end of line の代わりに使っている人がいるだろうか?

      因みに現在の ble.sh では M-e は何にも紐付いていない。
      うーん。M-e を勝手に補完の絞り込みモードに割り当てる事にする。
      絞り込みモードにいる時にはカーソルの動く範囲と編集範囲を制限する。
      と思ったが vi の様な複雑なモードの場合にそれを実現することは可能か?
      移動だけならば __after_widget__ で範囲外に出た時に
      強制的に範囲内に移動させる事が可能であるが、編集まで入ると困難である。
      編集を禁止しなければならないがそれは難しい。

      だとすると新しいプロンプトで編集させるというのが現実的だろうか。

2019-12-29

  * color: term_true_colors=auto

    自動判定は難しい。screen-4.99.0 が truecolor on/off
    のオプションを持っているので実際にユーザが有効にしているかどうかは
    TERM や DA2 を使っても分からない。結局試しに色を設定して、
    その色を読み出すという事をしなければ判定できないのだろうか。
    然し、これも端末によって問い合わせができたりできなかったり
    (セキュリティ上の都合から)無効になっていたりする気がする。

    以下の優先順位で試すというのが妥当な実装方法の気がする。
    然し 1 の判定を非同期に行わなければならないので面倒である。

    1. 色を設定して問い合わせる

      http://nanno.dip.jp/softlib/man/rlogin/ctrlcode.html
      https://qiita.com/kefir_/items/c2bd46728364bdc7470b
      OSC 10 ; ? ST で前景色RGB問い合わせ、
      OSC 11 ; ? ST で背景色RGB問い合わせの様である。
      応答は OSC 10 ; "rgb:rrrr/gggg/bbbb" ST の形式?

      よく考えたら現在の実装では ESC-[ (CSI) しか特別扱いしていない。
      これに対応する為には "ESC ]" (OSC) についても処理する必要がある。
      これは ble-decode-char/csi/consume の辺りを拡張する必要がある。
      特に BEL または ST (ESC \) で終端する様に処理を書く事に注意する。

    2. DA2 を元に判断する
      然し https://gist.github.com/XVilka/8346728 のページには
      各ターミナルの対応 version が書かれていないので使えない。
      自分で調べ上げるしかないのだろうか。

    3. TERM を元に判断する (*-24bit *-24bits *-truecolor)
    4. terminfo を元に判断する (setf24, setb24, tc, RGB)

2019-10-21

  * ずっと起動していると段々と遅くなっていくのは何故か。

    Ubuntu bash-4.3 (song437) で動かしていて気づいた。
    bash として新しく起動すると速い。
    ble-update や ble-reload をしたり、
    ble-detach / ble-attach しても直らない。

    カーソル移動だけでも遅くなって行くので描画が関係しているとは思われない。
    また、reload しても直らないという事から考えられる事は何か。
    履歴がどんどん溜まって重くなるという事でもない様な気がする。

    或いは変数のアクセスが遅くなって行くという事なのだろうか。
    変数に代入するスクリプトを回してみたが特に遅いという事はない様だ。
    (それにそもそも使用している時間に比例して変数が増えていくという物でもない)

2019-09-24

  * ble.sh で export PATH=aaa:bbb:ccc で最後の部分しか着色されない。
    それぞれ着色するべきなのではないか。

2019-09-22

  * complete: = を含むファイル名を補完すると = 以前の部分が重複して挿入されてしまう。

    →今確かめてみると再現しない。\= としていても = としていても同じ。

    2019-12-31 ./configure の引数で --prefix= を補完している時に
    = が \= になったり --prefix= も丸ごと置換されたりなど変な動作をする。
    一方で、complete -r で progcomp を消してやると変な事は起こらない。
    これは要するに progcomp の仕様の微妙な違いに起因して変な事が起こっている。

2019-07-16

  * complete: パス名展開で複数語に展開される場合の補完に関して
    現在の実装ではパス名展開が起こったとしても展開された最初のファイル名を使って補完を実行する。
    然し、実際には展開された各パス名について補完を実施しても良いのではないだろうか。うーん。

    更に failglob の場合には続きを入力したら一致したかもしれなくても常に展開に失敗してしまう。
    というか現状でそもそも failglob だった時にそれを検出しているのかどうかすら怪しい。
    確認する必要があるのである。

    既に COMPV には複数の値が入る仕組みになっていた。
    それならばと COMPV に入っている値の数だけ source を呼び出せば良いのかと考えたが、
    実際に試してみると全く同じ候補が何度も生成されるだけに終わってしまった。
    よく考えたら progcomp では独自に展開を行っていたのではあるまいか。
    調べてみたらやはりそうである…。これに対応するのは面倒である。

    或いは複数語に展開される場合には先ず始めにその内のどれか一つに絞らせるという可能性もある?
    然しそれはそれで不便な気もする。

2019-07-09

  * history.mlfix: bash-3.0 で実現する方法?
    history -s が使えないので複数行の履歴を登録する事が不可能である。

2019-07-02

  * menu: 複数選択を可能にしても良いのではないか
    C-@ で toggle をする等。抜ける時に全てを挿入する?
    然し使いみちがよく分からない。使いたくなったら追加するというので良い気がする。

2019-06-18

  * history: interactive な history 編集に対応できたらする
    つまりメニューを表示して其処で選択したり削除したりする。
    検索などもできる様にする。遅延で着色をする。

    core-complete に実装されている既存のメニューの枠組みは、
    menu item を配列に格納する。従って容量を食う。
    更に重そうである。これは独自に新しく実装した方が良いだろうか。

2019-05-27

  * 次に機能を追加するとしたらマウスなのだろうという気がする。
    fish は未だマウスに対応していない。
    zsh はそういう拡張があるらしいがちゃんと動くのかは知らない。

    zsh extension: https://unix.stackexchange.com/questions/444601/any-terminal-shell-with-mouse-support
    fish suggestion: https://github.com/fish-shell/fish-shell/issues/4918
    question: https://superuser.com/questions/322367/are-there-any-unix-shells-that-support-mouse-reporting

    マウス対応の問題点はマウスが有効になっていると、
    従来の端末に対するマウス操作(端末に表示されている内容のコピー・ペーストなど)が使えなくなる事である。
    端末に表示されている内容まで全て ble.sh の管理下であればそういう事もできたかもしれない。

    部分的なサポートとして何らかのモードに入っている時だけマウスを有効にするというのはあるかもしれない。
    例えば補完のメニューを出している間だけ、など。然し、それもなかなか分かりにくい気はする。
    或る特定の範囲だけでマウスを有効にするという制御機能があった様な気がする。
    それが使えればそれを使ってマウスを有効にするというのが可能になる気がする。
    何れにしてもこれは考察が必要になるのである。

    2019-07-22 どうも既存の端末では Shift を押しながら操作すると
    Mouse report ではなくてローカルでの端末上でのマウス操作になる、
    というのを採用している物が多い、という話を何処かで見かけた。
    何処で見掛けたかは忘れたし実際にそうなのかの確認はしていないが。

2019-04-21

  * 実は背景色を判定する方法はなくはない様だ。
    https://qiita.com/kefir_/items/c2bd46728364bdc7470b
    しかしそうだからと言って暗い背景用に配色を調整する必要があるので、
    それを実行するまでは対応しても仕方がないかもしれない。

    % というか、調べていたら DECSCNM (SM/RM(?5)) が背景が暗いか明るいかの設定の様だ。
    % という事は DECRQM して DECRPM を受け取れば普通に背景が明るいか暗いか分かるのでは。
    % そして Poderosa や screen の側でもそれを設定すれば良かったのではないか…。
    % と思ったが xterm は明るいか暗いかが反転している。
    % つまり、DECSCNM は飽くまでその端末の既定の背景と比べて反転しているかどうかしか分からない。
    % 既定の背景色が明るいか暗いのかの情報は取る事ができない。

    一方で、背景色の問い合わせで返ってくる色が DECSCNM の影響を受けるのか
    は気にして置かなければならない。

2019-03-23

  * menu: alias select='while myselect $# "$@"' 等として select を上書きできるのでは

    というか現在の ble.sh で select を実行すると悲惨な事になる気がする…。
    と思ったが select は別に readline は使っていない様子だ。
    元の bash でも全然行編集できない感じの入力になっている。
    なので現状で問題が発生しているという訳でもない。

    もし置き換える事ができるのであれば便利かもしれないという程度である。

  * menu: 今後の拡張性

    * 因みにフィルタリング機能は menu-filter を統合・整理する形で実装したい。
      フィルタリング文字列の入力に関しては isearch や iswitchb の様な、
      単に文字を入力するか BS で戻るかだけしかできない様なものでも良い事にする。

      フィルタリングに関してはフィルタリングを実行する関数と、
      フィルタリングを誘発する為の機能を分離して実装する事にする。
      既存の menu-filter の機能は自動的にフィルタリングを呼び出す。
      明示的なフィルタリングの場合には keymap にフィルタリングを紐付ける。

    * cdhist では更にリスト編集機能までついている。
      つまり項目を並び替えたり削除したりと言った事ができる。

      うーん。これをどの様に返すかは微妙かもしれないが、
      _ble_complete_menu_items にある物を呼び出し元で参照してもらうというので良い気がする。
      或いは callback でどの様に並び替えたかを返すという手もあるが分かりにくいだろうか。
      両方という事で良い気がする。使う側で便利そうな方を選んでもらう。
      どの様に並び替えたかの操作が欲しければ callback を使うし、
      最終的な結果だけ欲しければ _ble_complete_menu_items を参照してもらう事にする。

    * callback という事で思ったが、実は accept だとか cancel だとかも
      全て menu_class 経由で定義した方が良いのではないだろうか。
      一つずつ全て callback を変数に設定していくのは面倒である。
      更に、並び替えの callback だとかどんどん増やしていくと際限がない。

2019-03-22

  * menu-filter の使い心地が微妙なのはもしかして
    menu-complete を実行中に絞り込みができないからなのではないか。
    現在は menu-complete を実行している途中に入力をするとその場で確定してしまう。

    では bash の振る舞いはどうなっているだろうか。
    確認してみた所、bash の menu-complete はもうその場所に挿入してしまう。
    そして文字を入力すれば続きに挿入される事になる。

    現在の ble.sh の振る舞いはどうだろうか。
    その場で入力すると addtail 等の処理をせずにいきなり続きから入力されてしまう。
    少なくとも addtail ぐらいはするべきなのではないか。
    また、絞り込みを実行しても良いのではないかという気もする。
    然し、それでも何か違う様な気がする。

    絞り込みの入力欄と現在選択されている内容というのは別に一致している必要はない。

2019-03-19

  * complete: 実装されていない補完関連の rlvar は以下の通りである。
    実際に対応するかどうかも含めて考察する必要がある。

    - set completion-map-case off
    - set disable-completion off
    - set expand-tilde off
    - set horizontal-scroll-mode off
    - set page-completions on
    - set completion-display-width -1
    - set completion-prefix-display-length 0
    - set completion-query-items 100

    うーん。これらの設定は bash の既定値では余り便利ではなかったりする。
    ble.sh で折角実装してもユーザに使ってもらえないのでは仕方がない。
    それならば最初から ble.sh の bleopt として提供してしまった方が良いのでは。
    元々 bash を普通に使っていて設定している人の為に、
    bash の規定値と異なる値を敢えて選択している時に限り
    ble.sh でその効果を再現する様にすれば良い。

2019-02-09

  * main: --attach=prompt の問題は何だったか
    ref #D0940

    何か問題があって現在はこれを使っていないが、それは何だったろうか。
    何処かに記録されていて良い筈なのに何処にも記述がない。
    対応した時の記録は #D0737 にある。
    動かしてみた所、ちゃんと動いている様に見える。

    →恐らく、先ず古い ble.sh の version では使えないという事。
      それから PROMPT_COMMAND を上書きすると使えなくなってしまうからという事。
      ユーザに PROMPT_COMMAND を設定しないように要求するのは面倒である。

2018-09-21

  * [保留] 2018-09-15 complete: 文脈の変更範囲で end0 だけ負になるバグ (ref `#D0818`)
  * [保留] 2018-09-11 complete: 端末が操作を受け付けなくなるバグ (ref `#D0817`)

2018-08-16

  * complete: オーバーレイによる実装?

    現在の実装では仮挿入しているが、
    これによって現在の入力内容でエラー着色するべき所が、
    補完が実行された後の着色になってしまっていて、
    補完前の現状でエラーなのかどうなのかが判別できなくなっている。

    やはり仮挿入ではなくて overlay で実装するべきなのではないか。
    しかし overlay の仕組みを実装するのは面倒である。
    どの様な仕様にするのが良いのかの吟味から実装まで。
    しかし、これについては後回しで良いだろう。

    以下に仮入力の4種類の方法について言及がある。
    https://mattn.kaoriya.net/software/vim/20170905113330.htm

    リンク先は消えている。web archive のリンクを追記 (2018-09-23)。
    https://web.archive.org/web/20110630165743/https://www.mozilla-japan.org/projects/intl/input-method-spec.html

    * 2018-09-23 自動補完時の着色について
      cmplstofB さんからも指摘があった。
      https://github.com/akinomyoga/ble.sh/issues/5

      自動補完の候補文字列は実際に挿入しているので構文着色に影響を与える。
      "現在の内容" で着色するべきなのではないか、ということ。
      そうしないと例えば今入力したコマンドが実際に存在するコマンドなのかどうかが分からない。

2018-08-05

  * edit: set blink-matching-paren on に相当する機能
    対応するならカーソル移動ではなくて着色でやった方が良い。

    | 括弧の対応と region が両方走っていると分かりにくい。
    | 既に region には複数箇所を highlight する機能がある。
    | そういう意味で region を使うという手もある。
    | と思ったが、分かりにくい問題に関しては region の方を上に配置すれば良い。
    | 複数箇所を highlight する機能は実装を参考にするだけで良い。
    | 論理的には全く異なる (region は _ble_edit_mark を参照する) し、
    | それぞれ独立に on/off する事を考えれば別の highlighter にするべき。

    region の複数箇所着色の実装を参考にする可能性も考えつつ、
    region とは独立な highlighter にしたい。
    その時は region の一つ下の層に挿入したい。

    また対応する括弧はどの様に検出するのが良いだろうか。
    やはり文法構造を参照する実装にするしかない様に思われる。
    しかし、括弧の対応には色々ある。引用符の対応、
    括弧の対応、if then else などのキーワードの対応、
    ヒアドキュメントの始まりと終わりの対応である。
    それらは必ずしも記録されていないし、また、記録されているとしても
    様々な形式で記録されている。取り敢えず一番簡単な対応として
    nest に記録されている物を着色するというのが良さそうである。

    2023-03-26 https://github.com/akinomyoga/ble.sh/discussions/308

    対応する request が来た。うーん。もっと最近にも関連した考察をした気がするが、
    メモに記録があるかどうかは覚えていない。

2018-07-29

  * complete: メモ

    - 生成候補のキャッシュを行うとすれば source 内で実装するべきである #D0705

2018-07-19

  * ble-decode: 'set convert-meta on' 的な操作

    ref #D0699 (LANG=C bash で ble.sh をロードすると全く操作できない)

    ble.sh の内部環境では set convert-meta off にしているが
    (そうしてないと特殊文字の受信時に無限ループになる)、
    外部環境で set convert-meta on だった時に、
    それをエミュレートする様な動作を行っても良い。

    外部環境における set convert-meta の状態は
    変数 _ble_term_rl_convert_meta_external に記録してある。

  * 現在の `LC_CTYPE` で表現できない文字を入力した時の `self-insert` の振る舞い

    ref #D0699

    self-insert で入力するのは逆符号化したバイト列であるべきでは?

    というのも LC_CTYPE が正しくない場合でもファイルシステムのファイル名などは
    そのまま謎の文字列として取り扱われるからである。
    然し逆符号化したバイト列は文字列として正しくないかもしれない。
    逆符号化したバイト列を更に一バイトずつ現在の LC_CTYPE に変換すると意味がない。

    これは文字列を編集などしようとすると分からない事になりそうなので、
    取り敢えず現段階では \u???? を出力するという現状の振る舞いを維持する。
    後で落ち着いてから再考する事にする。

    以下の c2s 使用箇所は一貫している必要がある。

    ble/widget/self-insert 編集文字列の入力
    ble/widget/vi-command/search-char.impl/core 検索文字列の入力
    ble/widget/vi_xmap/visual-replace-char.hook 置換に使う文字の入力
    ble/lib/vim-surround.sh/get-char-from-key 囲み文字の入力 (あらゆる遅延入力)

2018-02-21

  * vi-mode: nmap (, ), {, }

    カーソルを N 文元に戻す or 先に進める。N 段落元に戻す or 先に進める。

    これは operator:d,c で "- ではなく "1 に記録するという例外の対象であるので、
    対応したらその例外のリストに登録する必要がある。

    2020-08-27
    https://www.youtube.com/watch?v=hIJh-KlQ7io
    この動画で zsh/bash の vi mode に (){} がない事を嘆いている。
    然し、"文" をどの様に定義するのか。文法的なコマンドで定義するのか、
    或いは、元の vim と同様に . の位置で判断するのか。
    シェルの機能としては . の位置で判断するのは使いようがない。
    一方で、シェル文法の . で移動する様にすると
    vim に使い慣れた人に取っては混乱の元である。

2018-02-12

  * [保留] vi-mode: operators 保留項目 [#tmp0002]

    * 領域折り畳み zf には対応しない。

    * gq の formatexpr, formatprg には未対応である。

2018-02-11

  * [保留] keymap/emacs: 連続する delete-backward-char の場合 undo の記録をまとめる可能性?

    現状では一文字ずつ記録しているので一文字ずつ undo される。
    現在の振る舞いの方が良いのか emacs と同様にまとめた方が良いかは微妙な所である。

2017-11-21

  * syntax: for^J で改行にエラーが設置されるが見えない [#T0005]

    改行のエラーは何らかの方法で見える様にするか、
    或いは、改行位置にエラーがある様な時は、
    その前の文字でエラーが発生する様にチェックを行うべき。

    Note: これは端末によっては表示されたりする。端末による。
    エラー着色はどの様に行われているのか。for の後には FARGX1 に入る。

    これは ble-syntax:bash/ctx-command/.check-delimiter-or-redirect の冒頭部分が怪しい。
    と思ったが FARGX1 に関してはチェックが入っていないのでやはり関係ないだろうか。
    うーん。調べるとやはり文法レベルでの着色になっている。

    2019-03-11

    | rps1 で表示している時に EL を空白で代替していると、
    | 改行の着色が空白に反映される。これでも良いような気がしてきた。
    | 然し、右側が全て着色されるというのもうるさい。
    | 最初の1文字だけ着色して SGR(0) するかと思ったが、
    | そうするとその次にある文字の着色も消えてしまう。
    |
    | それの対策のために _ble_textmap_ichg があるのでは。
    | と思ったが、実装を見てみると違っている様に見える。
    | _ble_textmap_ichg は着色の調整に使っている事は確かだが、
    | _ble_textmap_ichg に登録されている文字の着色を計算しているのであって、
    | _ble_textmap_ichg に登録されている文字の次の文字の着色は計算していない様に見える。
    | うーん。_ble_textmap_ichg は他の箇所では全く使っていない。
    |
    | そうだ。思い出した…。_ble_textmap_ichg に登録されている文字は、
    | 配置の場所によって中身が変わるので、shift が使えないという事だった。
    | 特に、中身が変化している場合には文字を取り出して変更を行うのだった。
    | では以前 ichg に登録されていて、現在位置では ichg に登録されていない文字はどうなるのか。
    | と思ったら既定の文字形は別の所で決定されている様だ。
    | ble/highlight/layer:plain/update/.getch である。

    a 右側の1文字だけ着色される様にする?

      x 問題点はコピーペーストした時に必ず余分な空白が入る事である。
        これは右側の全てを着色させる場合にも同様の問題が生じる。

        また、エラーが有る時にだけ (着色の必要がある時にだけ)
        右側に空白を入れるという方法もある。
        しかし、その為にはその位置にエラーが有るのかないのかを
        外部から取得しなければならない。

        ble/textmap#update は edit.sh だとかの仕組みに依存しない、
        独立した枠組みにしたいので余り変な機能は取り付けたくない。

      x また実装上の問題点として、rps1 が表示されている時に、
        _ble_term_ech を使わない場合、2文字目以降の空白文字を SGR(0)
        でクリアしなければならない事である。この場合、
        改行の次の文字の SGR を復元する為には…

        _ble_textmap_ichg に次の文字の番号も追加するか、
        或いは現在の改行文字の SGR 状態を復元する必要がある。
        しかし textmap の処理をしている間は、
        未だ着色が完了していないので SGR 状態を取得できない。

        或いは着色部分だけ textmap#update よりも前に持ってきても良いのだが、
        その様にしたとしても色情報を textmap#update に伝達する手法が必要である。
        例えば getg なる関数を textmap#update から呼び出してもらう事にするのか。
        或いは呼び出す関数名も外から指定できる様にするのか。

    b やはり改行の前の1文字を描画時に強制的に着色するという手もあるのではないか。
      と思ったが…エラー着色だけ特別扱いするというのも変な話である。

    c その様に考えると初めから改行にはエラー着色はしないというのが正しい気がする。

      改めて調べると ble/syntax:bash/ctx-command-compound-expect がエラーを設置している。
      うーん。for だけの問題では無い様である。他に select, case の時にも同様である。

      ('for'|'select'|'case')
        [[ ${text:i:1} == $'\n' ]] &&
          ((_ble_syntax_attr[i-1]=ATTR_ERR))
        case $word_expanded in
        ('for')    ((ctx=CTX_FARGX1)) ;;
        ('select') ((ctx=CTX_SARGX1)) ;;
        ('case')   ((ctx=CTX_CARGX1)) ;;
        esac
        processed=begin ;;

      実際に上記の様にして見たら見える様になった。
      しかし rps1 が有効になっている時はやはりうるさく感じられる。
      また端末に依っては rps1 が無効になっていても行全体が赤く着色される。
      そういう端末 (mintty など) どういう発想なのかはよく分からないが…。

      更に here documents も行末にエラーを設置する。
      これについても対策したいが、here documents に関しては、
      nest の終端がない事によるエラー着色である。
      これは nest の範囲を変更しないと着色を変更できない。

      何だか中途半端な実装の気がしてきたので取り敢えずこの変更はなかった事にする。

    d うーん。右側の内容の消去は実は改行文字を使って行うのではなくて、
      描画した後に消去するという方法にした方が良いのだろうか。
      しかし、その様にすると、今度は urange の中にある行末というのを列挙して、
      それから各行末について位置を計算して実行するという事をしなければならない。
      textmap さえあれば指定範囲内の行末は二分法によって特定する事が可能である。
      しかし面倒である事に変わりはない。もっとまともな方法はないのだろうか。

    結局実装の面倒さを考えなければ三種類の仕様が考えられる。

    a 右側に1文字赤く表示する
    b 行末まで赤く表示する
    c 行の最後の文字を赤くする
    d 表示されなくても気にしない

2017-11-09

  * complete: 候補の優先順位? 例えば拡張子でフィルタすると絞りすぎることがある。
    拡張子の要件を満たすものを先に表示して、満たさないものを後に表示する。
    満たさないものに関してはサブ候補として、TAB による接頭辞挿入には寄与しない。

    2018-07-28 候補間の優先順位をつける可能性。
    weak な優先順位は、候補を表示する時の順序。
    strong な優先順位は、候補絞り込みの際に一番優先順位の高いものが一つしかない場合にはそれに確定する。

2017-11-05

  * vi-mode

    :help 関連の気になること:

    - v_p v_P: Implementation details に書かれている処理の順序は実際は逆
    - exclusive-linewise: ここの inclusive/linewise になる条件の記述は曖昧だし全く合っていない
    - star: vim-jp の文書だと WORD と書いてあるが、振る舞いは word (しかも \<\> で囲まれる) に近い

    振る舞いで気になること

    - i<C-o><C-c> とすると普通のノーマルモードに移行したように見えるのに、
      モード表示は -- (挿入) -- のままである。これは何故だろう。
      ble.sh ではノーマルモードに完全に移行する。

    - qa<C-c>q とすると ^C が二重に記録される。これは何か?
      ble.sh では単に ^C は入力された通りに一個だけ記録する。

    - C-v <bracketed paste> では矩形挿入にするべきなのではないか。
      ble.sh では矩形挿入を行う。


2017-11-03

  * vi-mode (registers): 各種特殊レジスタの対応

    http://vim-jp.org/vimdoc-ja/change.html#registers

    - done: "% は現在のファイル名を保持するが、これは $HISTFILE の内容を返す事にした。

    - done: ": は一番最後のコマンドラインの内容である。
    コマンドラインを入力し途中でキャンセルした場合などには記録されない。
    空のコマンドラインで確定した時にも記録されない。
    コマンドが入力された場合は、それが存在しないコマンドであっても記録される。
    コマンドが実行されている途中では未だ設定されていない。
    つまり、そのコマンドが実行された後で値が設定される。

    - ". は挿入モードで挿入された文字列を保持する。挿入モードから抜ける時に記録すればよいだろうか。
    と思ったが説明をよく読んでみるとそういう振る舞いという訳でもなさそうだ。
    よく分からないので実際に動かして試してみる必要がある。

    - "# は代替ファイル (副ファイル) の名前だそうだが何か良くわからない。
    C-^ の動作と関係しているそうだ。これは未だ実装しない。

    - "= これは複雑だ
    - "* "+ "~ これは GUI で選択した範囲を表すものだそうだ。

2017-10-31

  * [保留] vi-mode (_ble_keymap_vi_REX_WORD): Unicode categories?

    Bash の正規表現 (<regex.h> ERE) で対応するのは難しい。
    また必ずしも Unicode (UTF-8) で実行されるとは限らない。
    現在は UTF-8 しか対応していないが枠組みとしては
    別の文字コードにも対応できる余地は残して置きたい。

2017-10-12

  * vi-mode まだ対応していない・考えていないコマンドを列挙する

    意外とそんなに残っていないようなので。

    * nmap: C-^ '括弧 `括弧
      C-t C-] M Q ZZ ZQ do dp { }
      [{char} ]{char} z{char} C-w{char}
      g<C-a> g<C-g> g<C-h> g<C-]> g# g* g$ g&
      g` g' g+ g, g- g8 g; g< gD gH gN gP gQ gT gV
      g] ga gd gf gF gh gn gp gq gs gt gw gx g@

  * [保留] vi-mode: xmap <C-]>

    % <C-]> なる物は今見ても存在しない。vivis https://qiita.com/b4b4r07/items/8db0257d2e6f6b19ecb9
    % 辺りに在ったものかとも思ったが、ない。zsh-vimode-visual を見てもない。
    % vim で C-] としてもベルが鳴る。何かの間違いで C-[ を C-] と書いてしまっただけなのかもしれない。
    % と思って改めて vimindex を見ていたら実はあった。

    C-] で "選択した文字のタグ" へジャンプと書かれている。
    タグとは何だろうと思ったら http://vim-jp.org/vimdoc-ja/tagsrch.html に説明がある。
    ctags のタグと同じものと思って良さそうだ。因みに :help ... で表示されるのもタグの様だ。
    またノーマルモードの C-] はカーソル位置の単語を ":ta" で検索と書かれているが、
    実質 xmap の時と同じことのようだ。

    % これについてはシェルの操作としてどの様な意味を持たせるのかというのは微妙な所である。
    % 履歴項目のブックマーク的なものとして利用することはできるかもしれない。
    % しかし、既にコマンドラインに入力されている文字列を元にジャンプをするとなると矢張り微妙だ。
    % 唯一意味がありそうなのは、指定した単語がコマンドライン上で定義された
    % シェル関数だった時にそこにジャンプするという物だが…本当に需要があるのかは微妙である。
    % しかし、シェル関数の定義を確認したいのであれば寧ろ command-help を呼び出せば良い。
    % シェル関数を修正するという目的ならば使えるかもしれない。
    % 然し、必ずしもシェル関数をコマンドラインで定義したとは限らないし、
    % 該当するファイルがあったとしてもそれをコマンドラインで表示する訳にも行かない。

    既に入力した文字列に対応して適切な履歴項目またはコマンドライン中の文字があればそこにジャンプする。
    例えばシェル関数を定義した履歴項目に跳んだり、変数名から declare に移動するなど。
    そういう機能でまともそうなのが定義できればそれを実装する。

2017-09-18

  * vi-mode: operator = [#tmp0001]

    :help = を見ると (設定 equalprog || 内部関数 C-indenting, lisp || 外部コマンド indent) が使われるそうだ。
    但し、indentexpr が非空白の時、indentexpr が使われる (参照: indent-expression)。

    インデントの規則について調べる。
    先ず初めに空行 (空白だけの行) を隔てて前の行に括弧がある場合には、
    それを考慮に入れて初めのインデントが決定される。
    空行を隔てて前の行がインデントされていればそれを継承する。

    結局空行を隔てた前の行のインデントまたは最後の括弧の位置を継承するということ?

    また括弧の種類は () しか見ていない {} や [] は見ていないようだ。
    デフォルトが lisp だからだと思われる。
    これは実のところシェルに適したインデントを実行するようにするべきなのだと思われる。
    しかしながらシェルのインデントはかなり面倒くさい。
    特に if, then, else, while, do, done 等については現在の解析では状態を記録していない。

    関連してコマンドが閉じていない時 RET を押すと改行挿入にするという物がある。
    この機能を実装する為にも現在の入れ子の状態を調べる仕組みが必要になる。
    RET で改行挿入にする機能のほうが幾らか単純なので、
    それを先に実装してからこれを実装する方が良い気がする。

  * vi-mode: 関連して [/ 等の実装についても調べたい。

    既に vim-surround.sh で類似の機能について実装したが、
    [/ についても個別に実装したい所である。

    他にテキストオブジェクトで [{ [} [( [) などと同等の機能も実装している。

    [# [' [( [* [/ [` [D [I [P [p [[ [] [c [d [f [i [m [s [z [{ [<mouse2>
    ]# ]' ]) ]* ]/ ]` ]D ]I ]P ]p ][ ]] ]c ]d ]f ]i ]m ]s ]z ]} ]<mouse2>

  * vim-surround: ds cs インデント

    surround.vim では改行が絡むとき = によるインデントを実行している。
    現在 vim-surround.sh ではインデントを実行していない。

    2017-10-09 追記

    yS ySS でもインデントは起こる様である。
    更に、xmap S でもインデントを行う (xmap gS はインデントは行わない)。

2017-09-17

  * cmplstofB: ビジュアルモード・選択モード?

    関連 #D0672 選択モード対応

    * テキストオブジェクトで範囲を選択し、また範囲を拡大する。

      どうやらテキストオブジェクトの拡大では左右の両端からの拡大を試みるような気がする。
      決して右端からテキストオブジェクトを拡大するというわけではないようだ。

      というのも変なところから初めて (...) の中に右端を移動して、
      その上で ib としてもエラーになるからである。或いは短くなる。
      どうも ib の動作としては左端から外側の ( を見つけて、
      それに対応する ) を右端に直すようである。

      うーん。これはテキストオブジェクトによって動作が異なるのかもしれない。
      aw などは明らかに右に向かって拡大を行っている。
      因みに矩形選択かどうかは気にしないようだ。
      同じ動作をする。行の右端に行くと次に次の行に普通に移動する。

    2018-02-22 現状の xmap におけるテキストオブジェクトの状況について整理する。
    - ble/keymap:vi/text-object/word.impl に於いては既に xmap での振る舞いに対応している様子である。
    - ble/keymap:vi/text-object/quote.impl は明らかに対応していない→対応した #D0670
    - ble/keymap:vi/text-object/block.impl も対応していない→対応した #D2095
    - 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 (実装ログ)
-------------------------------------------------------------------------------

2025-07-22

  * stty: bash out/ble.sh --install で stty を呼び出している (reported by LEI) [#D2376]
    https://github.com/akinomyoga/ble.sh/issues/609

    本来は単にコマンドを実行するだけなので stty 等を変更する必要はない筈。これ
    は再現できたので修正する。

    どうやら EXIT -> ble/util/unload -> ble/term/stty/TRAPEXIT と呼び出している
    様である。そもそも ble/util/unload は実際に line editor として使っていた時
    の unload 用の関数である。という事を考えると、コマンド実行の時には処理する
    必要性はないのではないか? と思ったが諸々の fd の処理や run の cleanup の事
    を考えるとやはり処理の一部は --lib モードであったとしても実行するべき?

    a 一つの方法は --lib モードで読み込んだ場合には unload の処理はスキップする
      という方針。然し

    b もう一つの方法は --lib モードで読み込んだ場合には unload は実行するけれど
      も ble/term/stty/TRAPEXIT は省略するという方針。然し、この場合 --lib で読
      み込んだ後に attach したり、将来的に textarea を部品として用いた時に
      ble/term/stty の設定が残留してしまう原因になる。

    c 或いは、一度でも ble/term/stty で設定を変更した事があれば ble/term/stty
      を使って元に戻す処理を実行する? これの場合には一度でも呼び出されたという
      事を記録しておく必要がある。

      現状はどうなっていただろうか。現在の状態は _ble_term_stty_state で状態を
      管理している。但し、 1 か空文字列かで区別している為、external/internal の
      区別しかなくて、一度でも stty を調整したかどうかについては現状では分から
      ない。

    d 或いは 0 が tty に繋がっていれば強制的に ble/term/stty/TRAPEXIT を実行す
      る。しかし、これだと一度も stty で状態を変更していないのに bash
      out/ble.sh ... を実行しただけで stty の状態が変更されるということになる。
      これは余り好ましくない。stty に関係のない処理を実行するだけで stty を触っ
      てしまうのは良くない。

    取り敢えず c の方針で実装した。_ble_term_stty_state は既定では空文字列で、
    一度でも stty に触れたら 0 または 1 の値を持つように変更する事にした。

2025-07-20

  * util (is-stdin-ready): sudo cmd ... の補完が動かなくなっている (reported by Jai-JAP, darukutsu) [#D2375]
    https://github.com/akinomyoga/ble.sh/discussions/551#discussioncomment-13788273
    https://github.com/akinomyoga/ble.sh/issues/603#issuecomment-3092346258

    set -x によるログを記録する関数を本体に追加してしまう事にする。但し、その時
    の出力先のファイル名はどの様に指定するか? 一つの方法は advice を設定する時
    に指定する方法。もう一つの方法は bleopt 経由で設定できる様にする方法。或い
    は ble/debug/print の出力先を流用する方法。

    * ble/debug/print が既定で stderr に出力するのは不便なので、やはり既定では
      stdout に出力することにして必要があれば呼び出し元でリダイレクトする様にす
      る。

      そもそも ble/debug/setdbg で事前に設定した所に出力する様にするのだって便
      利かどうか分からない。それよりは手動で 9 番か何かに開いておいて明示的に 9
      にリダイレクトする方が自然なのではないかという気がする。

      * 然し、実際の所 ble/debug/setdbg は作って以降一度も使っていないし、実際
        にどういう設計だと便利かというのが分かっていない。なので、実際に使う機
        会が今後あった時により良い設計について考察するべきではないか?

      * と思ったが実際に使う機会が今後訪れるのかも分からない。今は削除してしまっ
        ても良いのではないだろうか?

      うーん。使っていない物を保持する理由もないので削除してしまう事にする。と
      なると ble/debug/print 自体 ble/util/print と等価になるので、この関数自体
      も削除して ble/util/print に統合してしまうことにする。

    * 先ず、何故か動いている方で _comp_complete_longopt のループが二重に働いて
      いる。何故だろう? というより、動いていない方で半分になっている? 丁度半分
      になっているのは偶だろうか。生成されている候補を見てみると、元々動いてい
      た方で多少の重複はある様な気はするが基本的には重複なく処理ができている様
      な気がする。

      つまり、介入者の基本的な処理に於いてループが間違っている?

      或いはこの時点で既に ls ではなくて sudo の補完を実施している? と思ったが
      そういう訳でもないようだ。ちゃんと ls の補完候補を生成していて、しかしそ
      の途中で死んでいる。どうも _comp_complete_longopt のループの途中で強制キャ
      ンセルが走っている?

    * 更に次の diff hunk を見ると is-stdin-ready を明示的に呼び出している。[[
      -t 33 ]] で判定して通過しているが、実際には 0 が redirect されているのだ
      ろう…つまり、ここでは [[ -t 33 ]] ではなくて [[ -t 0 ]] を判定するべきな
      のだ。そもそも stdin==_ble_util_fd_tui_stdin である時点で [[ -t $stdin ]]
      はほぼ確定なのだから、判定対象は [[ -t $stdin ]] ではなくて [[ -t 0 ]] で
      あるべきである。

      これを修正したらすっかり直った。_comp_complete_longopt が中断してしまう問
      題も、内部で行われているこの is-stdin-ready の判定が変な振る舞いをして
      ループを強制キャンセルしたという事なのではないだろうか。

    これは結局単純な判定条件のミスだった。

  * history: "!136 ...: invalid timestamp" (motivated by Strykar) [#D2374]
    https://github.com/akinomyoga/ble.sh/discussions/597#discussioncomment-13561254

    これはエラーメッセージをもっと親切にしても良いのではないか?
    一応 HISTFILE へのパスを表示する様にした。動作確認もした。

  * 2025-06-20 github: nightly の URL が壊れている (reported by TheFozid) [#D2373]
    https://github.com/akinomyoga/ble.sh/discussions/593#discussioncomment-13517431

    github.event.repository.url には何か別の物が含まれている。これを使うように
    したのは一番はじめからだったから途中で変更したことによって破壊したわけでは
    ない。という事は GitHub の側が勝手に URL を変更したのが原因である。

    だとすると正しい URL を含んでいるのは結局何処になるのだろう。検索してもそれ
    に対応する文字列を取得する方法が分からない。結局 github を dump するしかな
    いのだろうか。然しそれだと結局用途も分からないので、将来的に変更される可能
    性についても分からない。

    何れにしても github オブジェクトを dump したいがどの様にすれば良いだろうか。
    → toJSON(github) を実行すれば良い様だ。何れにしてもこれぐらいの基本的な事
    は web 上で分かる様にするべきなのに全然情報が見つからない。実際に使ってみれ
    ば分かるのだからという言い訳も分からなくもないが、これだと各項目に対する説
    明が結局なされないし、将来的に自由に変更次第放題という事で何が信頼できるの
    かどうかも分からない。良くない。

    取り敢えず出力内容を見ると html_url というキーがある様なのでそれを使えば良
    い。

    https://github.com/akinomyoga/ble.sh/issues/603#issuecomment-3094391830
    https://github.com/akinomyoga/ble.sh/issues/609#issuecomment-3094454145

    また別の issue で古い nightly build で --install を使ってインストールしよう
    とすると This is not an interactive session. のエラーメッセージが出るという
    話をしている。そもそも古い version では --install に対応していないのである。
    この場合には、This is not an interactive session ではなくて、オプションを認
    識できませんというエラーメッセージを表示するべきである。

    最新版でも認識できないオプションを指定しても non-interactive session では、
    オプションのエラーを表示する前に単に This is not an interactive session. と
    表示するだけである。これについては最初に真面目に解析するべきだろうか。然し、
    そうすると色々複雑なことを POSIX sh の範囲で実装しなければならなくなる。

    真面目に実装しようとすると -xyz の様な組み合わせフラグにも対応しなければな
    らなくなるし、また、--option 及び --option=* にも対応しなければならなくなる。
    其処までする必要があるだろうか。或いは近似的に知らない --xxxx が何処かに現
    れていたらエラーを出力する? 然しそれだと別の引数の引数に "--xxx" という文字
    列を渡したいだけの時に ble.sh を起動できなくなる。やはり真面目に解析しなけ
    ればならないのだろうか…。

    というよりそれを言い出したら今までだって "--test" がオプション引数等に含ま
    れていた場合には、interactive check を突破してしまう様な振る舞いになってい
    た。そういう意味でも、今回これを厳密に実装するというのには意味があるのかも
    しれない。取り敢えず、実装してみる事にする。POSIX もしくは Bourne の範囲で
    問題が生じる様ならその時点で対処する事にする。

    取り敢えずエラーが発生するという事が分かったら interactive session ではなく
    ても通過させる事にして、後の解析の段階でエラーメッセージを出させて抜ける様
    にする。

    ? ok: 或いは、bash であることを確認したら interactive session であることの
      チェックをするよりも前に直ぐに read-arguments を実施する? と思った
      が、.bashrc で単純にに source ble.sh する人を想定して interactive sessino
      の解析はできるだけ最初にやりたい (実際に現在の実装ではかなり最初にやって
      いる)。一方で、フルのエラー検出及びエラーメッセージの表示をする為には、色々
      関数も使いたいし bash の設定も保存・退避しておく必要がある。ということを
      考えると、現状の様に最初に簡単なチェックをして、後でエラーを表示するとい
      う方式で良いのではないかという気がする。

2025-07-17

  * main: fix the error message of environment check (reported by LecrisUT) [#D2372]
    https://github.com/akinomyoga/ble.sh/issues/606
    Ref #D2349 (df6a4dad)

    最近の修正によるミスで見つからない POSIX コマンドの集合が反転していた。

2025-07-15

  * termux: termux の為に locale check routine を更新する [#D2371]
    https://github.com/akinomyoga/ble.sh/issues/507
    https://github.com/akinomyoga/ble.sh/issues/596
    https://github.com/termux/termux-packages/discussions/23010

    また、termux のスレッドへの誘導を行う。

    * done: USER が存在しない場合や LANG が存在しない場合にもどの様に修正するべ
      きかをユーザーに指示する。

    * termux: gawk の正規表現が壊れている。fatal: unbalanced ( という表示になる。
      うーん。或いはこれは gawk のバグの可能性はあるだろうか?

      $ echo | LC_ALL=C gawk $'/(\xEF\xBC\x9A)/'
      $ echo | LC_ALL=C gawk $'/(\xEB\x8A\x8C)/'
      $ echo | LANG=C gawk $'/(\xEB\x8A\x8C)/'
      $ echo | LANG=C gawk $'/(\xE3\x81\x82)/'
      $ echo | LANG=C gawk '/(あ)/'

      平仮名を入力しても起こる筈。

      Termux 上の gawk は 5.3.1 である。5.3.0 at Fedora 41 問題なし。5.3.2 at
      Arch 問題なし。Fedora 41 上で 5.3.1 を自分でビルドした場合でも問題は発生
      しない。つまり、Termux の上でだけ問題が生じるということ。

      これはやはり Termux の環境が壊れているのがいけないという事にして ble.sh
      の側では修正を入れない事にする。Termux で workaround を入れようとすると無
      駄に複雑になる気がするので。少なくとも保留にする。

  * keymap: C-up, C-down は使われていないから普通に history 移動に割り当てて良いのでは (requested by DJCrashdummy) [#D2370]
    https://github.com/akinomyoga/ble.sh/discussions/440#discussioncomment-13615017

    他の物に使う可能性はあるだろうか? history 移動は通常の履歴項目内移動よりも
    大きい移動という意味で、C-up, C-down で呼び出せるようにするのは理に適ってい
    る気がする。

  * complete: 補完候補の説明が混入する問題 (reported by allenap) [#D2369]
    https://github.com/akinomyoga/ble.sh/issues/603#issuecomment-3057271672

    これは gawk が見つからない (もしくは gawk が awk としてのみインストールされ
    ている) 環境で起こる。この時、filter-and-split-compgen における awk の出力
    を更に sort コマンドに繋げてソートを行う。一方で、mandb により説明を抽出し
    た場合には、その事を調べるために awk が exit 10 することになっている。呼び
    出し元で exit status を確認して説明の付加が実施された場合には、呼び出し元で
    説明を分離することになっている。問題は、この exit 10 が | sort に繋げられて
    いる時には呼び出し元で見えないという事にある。PIPESTATUS[0] から awk の終了
    ステータスを拾うことにした。

  * util: BUG in ble/util/writearray with gawk (reported by allenap, LeonardoMor, aaronjamt, ionesculiviucristian, Gabryx64) [#D2368]
    https://github.com/akinomyoga/ble.sh/issues/603

    単純に gawk 用の awk スクリプトにミスがあった。今まで発現していなかったのが
    不思議だ。後、エラーが起こった時に何も出力がないのではなく、代わりにそのま
    ま内容を出力してしまうのも不思議だ。取り敢えず修正した。

2025-07-02

  * main: --lib オプションの説明が --help の中になかった [#D2367]
    追加した。

  * 5.3: source に明示的に -- を渡す [#D2366]

    5.3 で新しく source にオプションが追加された。なので、オプションに見える様
    なファイルを source する場合の為に -- を指定する必要がある。

    しかし、改めて確認した所、5.2 以前ではオプションは存在しなかった物の、それ
    でもオプションに見える様な引数を渡すとエラーになっていたので、この問題は前
    からあった問題だった。

  * 3.2: USR1 を通じた C-d の検出の振る舞いが色々おかしい [#D2365]

    * fixed: bash-3.2: ble-edit/io/TRAPUSR1 で ble/builtin/trap/invoke USR1 を
      明示的に呼び出しているが、これは ble-edit/io/TRAPUSR1 の呼び出し元
      (.handler) でも呼び出しているので二重に処理されることにならないのか?

      →試してみた所、実際に二重に呼び出されてしまっている。内部の
      ble/builtin/trap/invoke USR1 は削除して良い。

    * done: bash-3.2: ble-edit/io/TRAPUSR1: ユーザーの設定した USR1 は、bash の
      C-d 受信の場合には実は呼び出すべきではないのではないか? C-d が検出できな
      かった時に別の理由で USR1 が発火したとして、その時に限り USR1 を発火させ
      るべきでは?

      実際に動作確認もした。C-d では発火せず、他の理由で外部から kill -USR1 を
      した時にはちゃんとユーザーの USR1 が発火する。

    * fixed: bash-3.2: C-d を使った後、C-u や BS などが使えなくなっている。これ
      は TRAPUSR1 の内部で改めて bind を実行するべきでは? 或いは、内部で bind
      を実行しても無駄なのだろうか? その場合はせめて別のキーを入力した時に修正
      する様にしたい。

      ble/decode/readline/adjust-uvw を呼び出してみたが効果はないみたいだ。と思っ
      たら _ble_decode_bind__uvwflag= の時にしか実際に処理が行われない様
      だ。_ble_decode_bind__uvwflag= を設定したらちゃんと BS 等が動く様になった。

    * 3.2: 複数行の履歴項目がある時に history が初期化される前に C-r で検索する
      と history の内容が dump される?

      うーん。簡単な複数行コマンドだと再現しない。何も変な出力はされていないし、
      履歴も正しく読み込めている。別のバグで履歴にものすごく長い複数行コマンド
      が入ってしまった時に問題が発生していた。だとすると余り気にしなくても良い?
      問題の履歴ファイルを再現しようとしたが難しい…?

      うーん。適当に履歴項目を作成してみても再現できないのでとりあえず放置する
      事にする。

  * 5.3: BASH_TRAPSIG 対応 [#D2364]

    * reject: util.hook.sh の実装で BASH_TRAPSIG が使えるかも? 然し現状でどの
      bash version でも動く様にしていて、bash 5.3 以降でだけ振る舞いを変えるの
      は無駄な複雑化に繋がるし、カスタムの trap の場合にはやはり自前で
      _ble_trap_sig を決定しなければならないので敢えて BASH_TRAPSIG を使う理由
      もない。

    * done: また自前でシグナルを発生させる時に BASH_TRAPSIG を設定するべき?
      ble/builtin/trap/invoke の中で → これには対応した。

  * global: use ble/opts#extract-last-optarg [#D2363]
    類似コードが沢山あるので。

2025-06-27

  * util (ble/util/is-stdin-ready): wt with Git Bash で画面の表示が全然同期しない [#D2362]

    * term_synchronized_update_mode を設定すると多少ましになるような気がする?
      と思ったが、これを有効にしていても依然としてちらつくので気の所為のような
      気がする。

      或いはカーソル非表示にするとそもそも描画されなくなるというバグが存在して
      いる可能性はあるだろうか。うーん。謎だ。

      うーん。調べてみると MSYS2 でも発生している。最新の ble.sh では発生するが
      昔の ble.sh では発生していない。という事はまた fd 周りの取り扱いによる問
      題だろうか。

      どうもこれは WSL では発生しない様だ。つまり wt の中ならば常に発生するとい
      う訳ではない。やはり pcon が関係しているのだろうか。うーん。Cygwin でも何
      か変な振る舞いが発生している様だ。

      bisect すると 29c00fd が原因でこの現象が始まっている。確かに
      ble/util/is-stdin-ready を明示的に変更している修正である。然しこれまでも
      補完に関しては _ble_util_fd_tui_stdin に redirect していたので、これで新
      しく明示的に _ble_util_fd_tui_stdin に redirect したとして何か変化はある
      のだろうか。と思ったが、もしかすると補完以外の場所の
      ble/util/is-stdin-ready が特に問題になっているのかもしれない。特に
      auto_complete を発火するかどうかの判定をしている ble.sh が問題になってい
      る。

      ble/term/stty/enter
      sleep 1
      for i in {1..10}; do
        ble/util/is-stdin-ready; echo "$?"
        builtin read -t 1 x; echo "[$x]"
      done
      ble/term/stty/leave

      これを実行して sleep 1 の間に文字を入力すると最初の
      ble/util/is-stdin-ready の時だけは 0 になるが、それ以降の呼び出しでは常に
      1 になってしまう。特に追加で文字を入力したとしても is-stdin-ready はずっ
      と失敗したままになる。また $x には何も読み込まれない。但し、追加で文字を
      入力すると今までに入力して消えたかに思われた内容も一緒に取得することがで
      きる。

      以下の様に /dev/tty を使っても問題が再現する。

      ng$ (ble/term/stty/enter; sleep 1; for i in {1..10}; do builtin read -t 0 < /dev/tty; echo "$?"; done; ble/term/stty/leave)

      明示的に redirection しない場合は問題は生じない。

      ok$ (ble/term/stty/enter; sleep 1; for i in {1..10}; do builtin read -t 0; echo "$?"; done; ble/term/stty/leave)

      dup でも駄目の様だ。

      ng$ (ble/term/stty/enter; sleep 1; for i in {1..10}; do builtin read -t 0 <&9; echo "$?"; done; ble/term/stty/leave) 9<&0

      何と外側で redirection しておけば問題は生じない。

      ok$ (ble/term/stty/enter; sleep 1; for i in {1..10}; do builtin read -t 0; echo "$?"; done; ble/term/stty/leave) </dev/tty
      ok$ (ble/term/stty/enter; sleep 1; for i in {1..10}; do builtin read -t 0; echo "$?"; done </dev/tty; ble/term/stty/leave)

      これは駄目。

      ng$ (ble/term/stty/enter; sleep 1; ff() { builtin read -t 0; } </dev/tty; for i in {1..10}; do ff; echo "$?"; done; ble/term/stty/leave)
      ng$ (ble/term/stty/enter; sleep 1; ff() { for x in a; do builtin read -t 0; done } </dev/tty; for i in {1..10}; do ff; echo "$?"; done; ble/term/stty/leave)
      ng$ (ble/term/stty/enter; sleep 1; ff() { for x in a; do builtin read -t 0; done </dev/tty; }; for i in {1..10}; do ff; echo "$?"; done; ble/term/stty/leave)

      何故か内部で echo -n "" すると OK? と思ったが常に成功する様になってしまう
      ので判定には使えない。上の判定では動いていた。何が違う?

      NG(0)$ (ble/term/stty/enter; sleep 1; ff() { for x in a; do builtin read -t 0; echo x; done </dev/tty; }; for i in {1..10}; do ff; echo "$?"; done; ble/term/stty/leave)
      NG(0)$ (ble/term/stty/enter; sleep 1; ff() { for x in a; do builtin read -t 0; echo -n x; done </dev/tty; }; for i in {1..10}; do ff; echo "$?"; done; ble/term/stty/leave)
      NG(0)$ (ble/term/stty/enter; sleep 1; ff() { for x in a; do builtin read -t 0; echo -n ""; done </dev/tty; }; for i in {1..10}; do ff; echo "$?"; done; ble/term/stty/leave)
      NG(0)$ (ble/term/stty/enter; sleep 1; ff() { builtin read -t 0; echo -n ""; } </dev/tty; for i in {1..10}; do ff; echo "$?"; done; ble/term/stty/leave)
      NG(0)$ (ble/term/stty/enter; sleep 1; ff() { builtin read -t 0; echo -n "" 1>&0 2>/dev/null; } </dev/tty; for i in {1..10}; do ff; echo "$?"; done; ble/term/stty/leave)
      NG(0)$ (ble/term/stty/enter; sleep 1; ff() { builtin read -t 0 </dev/tty; echo -n "" 1>&0 2>/dev/null; }; for i in {1..10}; do ff; echo "$?"; done; ble/term/stty/leave)
      NG(0)$ (ble/term/stty/enter; sleep 1; ff() { builtin read -t 0 </dev/tty; echo -n "" 1>/dev/tty 2>/dev/null; }; for i in {1..10}; do ff; echo "$?"; done; ble/term/stty/leave)

      途中で echo "$?" する事によって振る舞いが変わっている可能性? と思ったがそ
      うでもない。依然として最初だけ成功してそれ以降は失敗している。

      NG$ (ble/term/stty/enter; sleep 1; x=0; for i in {1..10}; do builtin read -t 0 < /dev/tty; ((x+=$?)); done; ble/term/stty/leave; echo "$x")

      builtin read -u を使った場合には問題は生じていない。

      OK$ (ble/term/stty/enter; sleep 1; x=0; for i in {1..10}; do builtin read -t 0 -u 9; ((x+=$?)); done; ble/term/stty/leave; echo "$x") 9<&0

      と思って is-stdin-ready を -u を使う様に書き換えてみたら完全に応答しなく
      なってしまった。何が起こっているのだろう。調べてみると -u を使うと
      ble/util/is-stdin-ready は常に 0 しか返さなくなってしまう様だ。従って
      ble.sh は次のユーザーの入力を待つために停止してしまう。一方で <& を使った
      時には初回以外は常に 1 しか返さなくなってしまう。然し、上記の例の場合には
      ちゃんと現在の状況に応じて 0 or 1 を返す様になっている。つまり更に別の要
      素によって振る舞いが変化するということ。

    * どうも簡単な場合でテストした結果を ble/util/is-stdin-ready に適用しても一
      貫した振る舞いにならないようなので、ble/util/is-stdin-ready を直接弄って
      振る舞いを観察する事にする。

      予め exec 9<&0 で 9 に保存しておいて 9 にはそれ以降は全く触れないようにし
      て read -u を使ってみたが常に 0 を返してしまって役に立たない。代わりに
      <&9 を使ってみると結局元と振る舞いは同じで瞬間的には 0 になるがそれ以降は
      1 を返す様になる。

      うーん。現在の出力先が -t の時にはそのままそれを使って read -t 0 テストを
      行う? 但し、tui tty が別の tty に繋がっている場合には問題が生じるのではな
      いか???  そもそも internal state の時は 0 は何に繋がっているのだったか。

      先ずコマンドを実行する時には { ...  } <fd_cmd redirections> の内部で実行
      している。なので、通常は fd_tui に繋がっていると考えて良いのではないか。

      問題は fd_cmd redirections が有効である時に is-stdin-ready を呼び出した時
      に何を意図しているのかという事になるが…でも基本的には tui fd を対象とし
      ていて敢えて違う物をテストしたい時には引数に何か指定している筈。
      ble-attach において現在の fd を cmd fd に保存してからシェルの fd を全て
      tui fd に置き換えている。

      使用箇所を調べると殆どの場所で引数は指定していない。指定していたとしても
      0 である。先ず引数が 0 の時には redirection は実行しないで良い。また、引
      数が空の時には tui fd を使う事になるが… redirection によって 0 が tty 以
      外で塞がっている時は仕方がないが、[[ -t 0 ]] の時は基本的に tui tty に繋
      がっていると考えて良いのではないか?

      但し、cmd の中にいる時には cmd fd ではなくて明示的に tui fd を指定する必
      要がある? 一応 _ble_edit_exec_inside_userspace で判定を行う事にする。

    どの様な状況で workaround が必要になるか。

    ? ssh した先では問題は生じるのか? 間に ssh が挟まっているから問題は発生しな
      いのではないか? という気がする。

    ? 逆に他の OS から ssh でログインした時にはどうなるのだろうか? しかし
      Windows では sshd にも色々あるだろうし微妙かもしれない。sshd によっては
      pcon 経由で接続するかもしれない。その場合には wt でなくても問題が発生する
      のでは?

    ? というかそもそも wt でなくても別のコンソールなどから入ってその後で msys2
      や git bash に接続した時にも問題が発生しないか確認する必要があるのではな
      いか? うーん。色々と検証が難しい。

    ? tmux の内部ではどうなるのだろう。tmux はインストールしてみたがどうやって
      も 127 (command not found) で起動できない。何故だろう。/usr/bin/tmux
      --help でも動かないので tmux の内部で他のコマンドが見つからないというより
      は bash が tmux を起動するのに失敗しているという事だろう。同じディレクト
      リにある /usr/bin/gawk --version はちゃんと動く。一方で screen はそもそも
      パッケージが存在しない。contra をビルドする? とも思ったがそもそもコンパイ
      ルできるのだろうか? またデバグが大変だろうからこれはやめる事にする。

    取り敢えずの所は現在の環境が cygwin, msys でかつ一番外側の terminal が wt
    の時に workaround を有効にするという形で良い気がする。もしかしたら tmux や
    screen が間にはさまっている場合には大丈夫の可能性もある。もしくは tmux およ
    び screen 自体が動作不審になってしまう可能性もなくはないが…。

    * ok: 或いは wt でなくても pcon が関係していると遍く問題が発生する?
      disable_pcon が入らない様に mintty を起動してその後で source out/ble.sh
      --norc を実行してみたが特に問題は発生しない様である。なので恐らく wt だけ
      で問題になっている? (しかし mintty 自体が disable_pcon をしている可能性も
      実は捨てきれない。) contra でも問題が発生しないか確認したがやはり問題は発
      生しない。つまり何故だか分からないが wt の中だけで発生する現象という事で
      ある。

    依然として補完関数が入力を食っている様な気がするがこれは別の問題の気がする
    ので項目を分ける。

2025-06-16

  * syntax: "case a in \[C-q][C-j]" を入力すると無限ループになる [#D2361]

    ble/syntax:bash/ctx-command-case-pattern-expect の中で
    ble/syntax:bash/starts-with-delimiter-or-redirect を呼び出した後に
    BASH_REMATCH が設定されている前提になっているが、実際の実装はそうなっていな
    かった。

  * syntax: function キーワードの後の関数名を単語として読み取る [#D2360]

    CTX_FNAMEX を追加した。ATTR_FUNCDEF を CTX_FNAMEI に改名した。
    CTX_TARG{X,I}1 を参考にして実装した。取り敢えず動いている様な気がする。

    * 今回の変更で bash >= 5.1 で "function f (echo)" が許される様になったのに
      も対応している。今までエラーじゃないのにエラー着色になっていた。

    * done: 補完に対応する。CTX_TARG{X,I}1 の実装を参考にする。

    * fixed: 特殊文字が含まれる関数名をエラー検出しても単語着色で通常の色に上書
      きされてしまっている。関数名の単語着色でも同様に関数名の内容をチェックす
      るべき。

    また今まで詳細にチェックしていなかったが "'echo' () { ...; }" などの関数名
    をチェックして正しく棄却する。将来的に Bash 5.4 等で任意の単語が使える様に
    なった時点でそのチェックを外す様にする。

    * done: 今は 50400 にしているがこれは未定なのでもっと大きな値にするべき。取
      り敢えず 99999 みたいな値で良い気がする。

2025-06-05

  * complete: 補完結果に } が混入する (reported by cmndrsp0ck) [#D2359]
    https://github.com/akinomyoga/ble.sh/issues/589
    Ref #D2352

    開発用の ble.sh セッションでは発生しないが新しいセッションで再現する。これ
    は単に最近の変更で発生する様になっただけだった。8bea90d1 (#D2352) の書き換
    えで失敗している。

2025-06-03

  * 2025-05-28 canvas: 複数行プロンプトで startup 時に scrollback にごみが残る (reported by u/JustABro_2321) [#D2358]
    https://www.reddit.com/r/bash/comments/1kwbwmf/ (github AB-boi)

    初期化時にプロンプト再表示の際に前のプロンプトが scrollback buffer に送り込
    まれて、それを気にする人がいる。端末上部での DL の振る舞いが GNOME terminal
    の最近の version で変化している様である。3.44.0/vte:0.68.0 (Linux Mint 21),
    3.50.1/vte:0.74.2 (Fedora 39) では発生しない。3.52.0/vte:0.76.0 (Linux Mint
    22), 3.52.2?/vte:0.76.2? (openSUSE Tumbleweed) では振る舞いが再現する。

    この振る舞いの変更は GNOME/vte #2663 [1] で議論され commit 306e74d9 で適用
    された物と考えられる。この変更は 0.75.0 以降に影響を与えている。

    [1] https://gitlab.gnome.org/GNOME/vte/-/issues/2663
    [2] https://gitlab.gnome.org/GNOME/vte/-/commit/306e74d9d197d63a1ed45edae653a162881bd24d

    これに対する workaround として何が考えられるか。

    a reject: DECSTBM を使うとしても同様に削除された行が scrollback に送り込ま
      れるのではないかと思われるし、そもそも初期化直後は未だ DA2R が返ってきて
      いないので端末依存の手法は使えない。

    b そもそも初期化直後に何故プロンプトの高さを短縮する必要があったのだろうか。
      もし仮に高さを調節する必要があったとしても、0 に潰すのでない限りは 2 行目
      以降で DL を実行すれば済む話なのではないか? 或いは実際に 0 に潰れているの
      だろうか。然しそうだとすると 1 行プロンプトの時に問題が生じないのが不思議
      である。

    c というかそもそも何故プロンプトが同じであるはずなのに panel の高さ調整が走っ
      ているのだろうか。panel の高さ調整自体が起こらない様に最適化できないのか?

    実際の振る舞いを調べてみると高さの調節は起こっていない様に見える。最初のプ
    ロンプトの表示で set-height で高さが 2 に設定されて、その後は高さは変更され
    ていない。それより寧ろ panel の中身を消去する為に DL IL を実行しているのが
    原因ではないかと思われる → ble/canvas/put-clear-lines.draw でそれを実行し
    ていた。

    ble/canvas/put-clear-lines.draw で新旧の高さが両方 1 以上の場合は最初の行は
    必ず EL(2) にして、DL/IL は必ず2行目で行う様に修正した。

  * util: Ubuntu で bash-builtins が検出できていない [#D2357]

    #D2356 のテスト中に気づいた。Ubuntu 22.04 LTS の bash-builtins パッケージに
    loadable builtins が含まれているが、ble/util/load-standard-builtins がそれ
    に含まれている builtin を検出できていない。Ubuntu は /usr/bin/bash ではなく
    て /bin/bash の方が実体になっている為、prefix= と判定されて
    /lib/bash/<builtin> を見に行っているが実際には /usr/lib/bash/<builtin> を確
    認しなければならない。然し、一方で /lib も存在している様だ。

    /usr の下も確認する様に拡張する。また lib ではなくて lib64 にインストールさ
    れている可能性についても考慮にいれる。というか bash-4.4 の
    BASH_LOADABLE_PATHS も考慮に入れるべきなのではないか? → 実装した。

  * util: ble/fd#add-cloexec が正しく動かなくなっている (reported by xlei77) [#D2356]
    https://github.com/akinomyoga/ble.sh/issues/588#issuecomment-2932629707
    Ref #D2328

    どうも #D2328 (6f34012d) 以降 fd search 方式による ble/fd#add-cloexec が正
    しく動かなくなっている。古い ble.sh では問題は発生していない。

    実際に出力する結果を見てみると新しい compgen -G 実装だと新しい fd が増えて
    いる。この fd は ble/util/assign-array による redirection に伴う退避 fd で
    ある。うーん。つまり、新しい fd を作らずに compgen -G の結果を取得しなけれ
    ばならない。うーん。無理の気がする。つまり、compgen -G は使えない。

    5.3 以降は compgen -V ret を使うから OK? 実際に手許で再現して動作確認する必
    要がある → 手許で 5.2 で問題が再現することを確認して修正後にちゃんと動作す
    る事を確認した。5.3 についても修正後にちゃんと動作しているという事を確認し
    た。

  * 2025-05-28 util: VTE の DA2 応答がまた変化している [#D2355]
    https://www.reddit.com/r/bash/comments/1kwbwmf/comment/muo988p/
    Ref #D1620

    GNOME terminal 3.50.1 VTE 0.74.2 では未だ以前の DA2 応答 (65;*;1) である。
    一方で 3.52.0 VTE 0.76.0 では '61;*;1' に変わっている。更新した。

    記録として、過去の VTE の変更に関連するリンクもコード中にコメントを残した。
    また厳密な version についてもチェックする。meson.build の中にバージョンが記
    録されている。どうやら autotools から meson に切り替えたようだ。

2025-06-02

  * "echo <<[TAB]" では補完が開始されるが "<<[TAB]" で補完が開始されない [#D2354]

    これは #D2353 の修正中に気づいたバグ。
    ble/syntax/completion-context/.check-prefix/.test-redirection の呼び出し方
    が間違っている。引数を指定し忘れている。実際に "<<[TAB]" とした時に補完が開
    始されないという振る舞いの不都合を確認した。修正する。

    * 序でに ble/util/assert の中にある shift も削除する。履歴を遡るとこれは最
      初の ble-assert の実装で $* を使って mesasge を出力する時に、最初の引数
      (assert条件) を除外する為だった。$2 を固定して message として使う様に変更
      した今、shift を実行する意味はない。

2025-05-13

  * global: #D2192 で ":" の使用を抑制した筈なのに while :; do がたくさんある [#D2353]

    他にも eval ": ${...}" というものが残っている。うーん。

    ./src/edit.sh:11579:function ble-edit/bind/stdout.on { :;}
    ./src/edit.sh:11581:function ble-edit/bind/stdout.finalize { :;}

    以下も気になる。

    ./lib/core-complete.sh:6761:function ble/complete/candidates/filter:none/test { true; }
    ./lib/core-syntax-def.sh:50:function ble/highlight/layer:syntax/update { true; }
    ./lib/core-syntax-def.sh:53:function ble/highlight/layer:syntax/getg { true; }
    ./lib/core-syntax-def.sh:58:function ble/syntax:bash/is-complete { true; }
    ./lib/test-bash.sh:140:  function f1/sub { true; }
    ./lib/test-main.sh:45:  function ble/test/dummy-1 { true; }
    ./lib/test-main.sh:46:  function ble/test/dummy-2 { true; }
    ./lib/test-main.sh:47:  function ble/test/dummy-3 { true; }

    * "while :; do" に関しては単に "for ((;;)); do" に置き換えようと思ったが、
      どうもそうすると emacs が ;; を case パターンの終わりだと勘違いしてインデ
      ントが壊れてしまう。

      或いは for ((; ;)) にする? もしくは while true にする? 或いは while
      ble/util/setexit 0; にする? 或いは "while ((1)); do" にするしかない? 結局
      今のところ一番無難なのはこれである。或いは "for ((;1;)); do" もあるかもし
      れない? が変だ。

      "while ((1)); do" に置き換える事にした。

    * done: true が未だ何箇所か使われている。後でチェックする → これらは結局
      builtin true / builtin false を使う事にした。

      ./lib/core-syntax.sh:5754:    true
      ./lib/core-syntax.sh:5811:    true
        これらは空の if branch にダミーとして置かれているコマンドである。従って
        ble/util/setexit 0 に置き換えるのも変である。また、if の後に共通処理も
        あるので、単に return する訳にも行かない。

        うーん。取り敢えずそのままにしておく事にする?

      ./src/history.sh:100:      true 100 progressive-weight:timeout=3000:SIGKILL
        これらは conditional-sync の引数である。

        * reject: 実は単に空文字列を渡したら builtin eval -- '' が実行されて最
          終的に true と同じになる? と思ったが空文字列を渡した時 (もしくは条件
          を指定しなかった時) は has-input を用いて判定する様になっていたのだっ
          た。なので空文字列に別の意味を割り当てることはできない。

        これは明示的に ble/util/setexit 0 にしても良い気がするが、そのままでも
        良い様な気がする。というかそれぐらいであれば ble/util/true や
        ble/util/false に対応する? と思ったが、それなら最初から builtin true や
        builtin false を呼び出せば良い。

      ./src/util.sh:7262:      true
        これも空の if branch に対応する様な気がするが、ここでは実際に $? を後で
        使っているので $? を設定する役割がある。

    * 序でに true / false の直接呼び出しも禁止して必ず builtin 経由で呼び出す様
      にする。

  * util (ble/array#fill-range): bash-4.2 で構文着色の振る舞いが変だ [#D2352]

    bash-4.2 だけでおかしい。bash-4.1 及び 4.3 では問題は生じていない。単語着色
    の位置がずれている。構文ベースの属性についてはずれていない。単語着色の範囲
    計算で変な事が起こっている?

    これは bash-4.2 のバグの様だ。a=("") の時に "${a[@]/}" や "${a[@]#$empty}"
    の結果が 0 単語になる。それによって ble/array#fill-range が配列を破壊してい
    た。これについては対策を入れた。

    然し、他にも影響のある箇所があるかもしれない。とは言え、a=("") の時にだけし
    か起こらないバグなので影響範囲は限定されている、というのが微妙な所である。
    発現しにくいので見つかりにくいし、各コードについて事前にそのような状況にな
    らない事を保証するのも難しい。と思ったが、実際に正規表現で検索してみたら影
    響範囲はそんなに大きくなさそうだ。

    * fixed: 実は ble/array#fill-range は patsub_replace に対しても正しく対策で
      きていないという事が分かった。修正した。他にも類似の箇所があった。

    * fixed: 更に ble/fd#list の実装を簡単な物に置き換えたが、その時に bash <
      4.3 で ble/util/getpid を通して BASHPID を取得する必要があるのを忘れてい
      た。修正した。

    * compat42 関連の workaround が分散している。これは関数にまとめるべきではな
      いか。

      * done: add tests for @
      * done: scan に @ を追加

      * ok: test-bash.sh にある 4.3 の \001 は何? 試してみた所普通に再現する。
        これは対策をする必要がある。

        というか a[*] でも同様に発生する。これは #D1570 では検出できていない気
        がする。と思って確認してみた所、既に #D1570 の検出対象だった。

      * done: add tests for map-prefix and map-suffix

      * ok: compat42 の WA を 40300 以上に対して適用しているが、この WA は
        50200 だけで良いのではないか? これはテストで検証

      * ok: map-prefix と map-suffix の実装を統合する? でも余り変な事をすると将
        来的な bash バグ検出が働かなくなるし余り下手な事はしない方が良い様な気
        もする。取り敢えず現状では維持することにして、更に他の種類の展開でも同
        様の workaround を追加しなければならなくなった時に、再度実装の共通化に
        ついて考える → どうも map-prefix と map-suffix だけの様なので取り敢え
        ずこのまま。

    * fixed: 2025-05-15 bleopt にバグがある。

      $ bleopt test{1..9}:=X
      $ bleopt test@=1 test2:=2

      等とすると test@ で内部的に生成した変数名が残っていて test2:=2 が test@
      の全てに適用されてしまう。

    * fixed: 実は benchmark して見たところ fill-range は普通にループで代入した
      方が断然速かった。配列が巨大な場合や代入範囲が大きい場合についても色々確
      認してみたが、やはりループにした方が一貫して速い。実装を切り替える事にす
      る。

  * color: 24-bit black に専用の内部表現を与える (reported by seefood) [#D2351]
    https://github.com/akinomyoga/ble.sh/issues/343#issuecomment-2857492599

    今まで index color 16 に割り当てていたが、勝手にパレットを改造している人が
    いる。xterm 256 color なのにパレットを勝手に変更するのが悪いのだが、端末の
    規格的にはパレットは規定されていないし、寧ろ DEC にパレットを変更するシーケ
    ンスがある。現代の端末アプリケーションではその様な物を使うことはないと思っ
    ていたが、どうも WezTerm がそれを変更するインターフェイスを提供しているせい
    で、実際にパレットを勝手に変更しているユーザーがいる。

    一方で元々の 24-bit color sequence を実際に使って色を設定するとちゃんと黒で
    表示されるので、振る舞いをちゃんと一致させる為には 24-bit black を index 16
    に変換することはできない。24-bit black 専用の表現を割り当てる必要がある。

    x fixed: #000000 に特別のコードを割り当てる方針で実装してみたが色々黒くなっ
      てしまっている。何か間違えている → これは判定式の & 演算子の優先順位が
      低いのを忘れて括弧をつけるのを忘れていた。

    * done: 或いは別の方針として FgIndexed | FgMask の内部での割当方法を変更す
      るという手がある。FgIndexed ではなく Fg24bit にして、また、FgIndexed は
      FgMask の中に住まわせる。うーん。実はその方が自然な実装になるのでは?

      そのあたりの議論は 24-bit 色を導入した時にもした様な気がする。その時の議
      論を参照する。#D1184 (true color support) である。その時の議論だと、内部
      表現はいつでも切り替えられるから気にせずに実装するという事になっている。
      という事は現在の構成に特別の意味があるという訳でもない。内部表現を完全に
      変える事にする。

      変更した。動いている。

  * contrib/integration/fzf: bind も workaround の対象にする [#D2350]
    https://github.com/ajeetdsouza/zoxide/pull/1048#issuecomment-2868556399
    https://github.com/junegunn/fzf/pull/4377

    うーん。zoxide の方も work around を追加する? と思ったが、zoxide の場合には
    単に suppress すれば良い訳ではない。取り敢えず zoxide の内部で動いているみ
    たいなので、取り敢えず現状で良い事にする。

    * done: skim にも同様の修正を適用する必要がある。これは ajeetdsouza に催促
      してみる → これは ajeetdsouza が PR を出した。すぐにマージされた様だ。

      https://github.com/skim-rs/skim/pull/774

    ? うーん。これによって fzf 経由で zoxide completion を呼び出した時に、
      zoxide completion が動かなくなってしまう可能性はないのか?

      そもそも、zoxide 以外であっても bind で DSR(0) を変更する補完が存在したら
      これで動かなくなってしまう (と思ったが、そのような補完は従来の fzf を何れ
      にしても破壊してしまう為、既存の補完設定で広く使われているとは思われない。
      今回の zoxide の様に fzf の設定を外居してしまうので対処を強いられた筈であ
      る。)

      然し、今 fzf は直前に bind する様になったので、今後はそのような設定が増え
      てくるのではないかと思われる。そしてそれらの設定に対しては DSR(0) に対す
      る bind の抑制は適用するべきではない。fzf が自身の処理のために呼び出した
      bind だけ抑制するべきである。

    * 然しそうすると更に printf についてもちゃんと fzf から直接呼び出された時に
      のみ DSR(5) 出力の抑制を行う様にしなければならない。

  * main (ble/bin#freeze-utility-path): command 経由で呼び出すようにする [#D2349]

    * ble/bin#freeze-utility ,etc. "command" 経由で呼び出した方が良いのでは?
      get-path で取得できたという事は関数ではなくファイルという事である。そして、
      関数で上書きされる可能性 (or 既に上書きされている可能性) を考慮したら
      command 経由で呼び出した方が良い気がする。

    * ble/bin#get-path の中で relative path の resolution もするべきでは。
      ble.pp の中の ble/bin#get-path を呼び出している箇所では全てで ./* と ../*
      の修正を呼び出し元で行っている。それ以外の場所でも relative path は絶対パ
      スに変更した方が良いだろう。

    * 未だ type を直接呼び出してコマンド判定している箇所がある。これは
      ble/bin#has に置き換えて良い。

      ./ble.pp:1267:      if ! type "$cmd" &>/dev/null; then
      ./ble.pp:1413:    if [[ $OSTYPE == solaris* ]] && type /usr/xpg4/bin/awk >/dev/null; then

  * main: workaround coreutils stty in macOS (reported by EmilyGraceSeville7cf, sshresthaEG, syuraj, seefood, arc279) [#D2348]
    https://github.com/akinomyoga/ble.sh/issues/63
    https://github.com/akinomyoga/ble.sh/issues/380
    https://github.com/akinomyoga/ble.sh/issues/343#issuecomment-2857492599
    https://x.com/arc279/status/1920306857148649817

    余り多いし面倒なので検出して対策を入れる事にした。

  * edit: display-shell-version で WARNING が表示されなくなっている [#D2347]

    (integration: off) を表示した事によって判定が壊れている。

    2025-05-28 integration/bash-preexec をロードしているのに integration: off
    になっている。何故? → これは ble/util/import/is-loaded
    contrib/bash-preexec を使っていたからだった。bash-preexec は integration/
    の下に移動したのにそれが の path が更新されていなかったのが原因。

  * history: readonly HISTSIZE 対策 (reported by seefood) [#D2346]
    https://github.com/akinomyoga/ble.sh/issues/343#issuecomment-2857492599

    これは先に ble.sh なしで readonly HISTSIZE して、その後で ble.sh をロードし
    た時に問題が発生する。ble.sh を先にロードしている場合には readonly を上書き
    していてので、HISTSIZE を readonly にするのをブロックしているのでこの様な事
    は発生しない。

    然し、一々文句を行ってくる人がいると面倒なので対策を追加する。HISTSIZE は
    readonly にする理由があるような気がするがその他の変数については特に
    readonly にする理由がなければ対策をする必要はない。取り敢えず HISTSIZE だけ
    でも対策をしておく。

    ? ok: HISTIGNORE や HISTCONTROL まで readonly にしてしまう人はいるだろうか。
      よく分からないがその様にする理由も思い浮かばない (例えば Bash-it では他の
      plugin がこれらの変数を調整したいという状況が考えられるだろう) ので対策は
      しなくて良い。

    既存の値が unlimited に相当するかどうかの判定はどの様にするか? ダミーの履歴
    ファイルを作成してそれを使っていろいろな値でテストするしかない? でもどの様
    な値を使ってテストするべきか? bash の source を確認した方が早いのではないか。

  * decode: update でキーボードが入力できなくなる報告がまたあった (reported by teutat3s, bigbruno, giggio, erfan-star-1999) [#D2345]
    https://github.com/akinomyoga/ble.sh/issues/576
    https://github.com/akinomyoga/ble.sh/issues/484

    やっぱり何か対処する必要があるだろうか。

    * 何も入力できなくなったら取り敢えず --clear-cache を試みてもらうというのは
      README に書いても良い。

    それとは別にキャッシュ不整合を検出して強制アップデートするのを実装する? そ
    の為には cmap に version を導入する必要性が出てくる。その version を管理す
    るにはどうするか。

    a 手動で呼び出し元の version と init-cmap.sh の内部の version を一致させる
      様に管理する。

    b 呼び出し元だけで version を指定する。init-cmap.sh は呼び出し元が設定した
      番号をそのまま使ってキャッシュを生成する。

      この方法だと init-cmap.sh が更新された時に自動的にキャッシュを更新すると
      いう機能が使えなくなり不便ではないか? と思ったが、タイムスタンプベースの
      チェックは保持するつもりなのですぐに問題にはならない。単に version を更新
      しないでいると、実際に cache が up-to-date と判定された時の cache version
      不整合の検出ができなくなるというだけの事である。

    c 何か別のファイルに version を定義しておいて、呼び出し元 (decode.sh) と
      (lib/init-cmap.sh) の両方でそのファイルから読み取った version を使う様に
      する。

      この場合にもその「別のファイル」にある version を適宜手動で更新する必要が
      出てくる。或いは repository に登録されている init-cmap.sh の hash を自動
      的に挿入する仕組みにするというのでも良い?

    うーん。lib/init-cmap.sh を見てみたが最近の変更はない? なのに何故最近になっ
    て動かなくなったという報告がたくさん出ているのか? 何れかの変更が問題を起こ
    したという事? 或いは NixOS での利用が増えて問題が起こりやすくなったという事?

    * 実は影響を受けるのは init-cmap.sh だけではない気がする。vi.sh や emacs.sh
      で定義されている keymap のキャッシュも init-cmap.sh が更新したら更新しな
      ければならないし、また vi.sh や emacs.sh 自体が編集された時にもキャッシュ
      を更新する必要がある。

      a キャッシュを生成するのに使っているファイル全てについてそれぞれキャッシュ
        version を管理しなければならなくなる。少なくとも何らかの枠組みを整えて、
        簡単にファイルベースのキャッシュ更新を新規追加できる様にする必要がある。

      b 或いはファイル毎のキャッシュ管理は諦めて ble.sh の version が変われば完
        全にキャッシュを全消しする仕組みにする? 然し、そうすると全く関係ない軽
        微な更新でもキャッシュを計算し直す事になり、余りキャッシュとして賢くな
        い気がする。

    * ok: これを対処するにしても具体的に問題が起こる状況を再現しなければならな
      い気がする。適当に憶測で修正しても仕方がない。なので、様々な version の組
      み合わせで更新を行って問題が発生する組み合わせを特定する必要がある。それ
      を一つ一つ手動で行うのは大変である。なので、少なくとも幾らかの自動化は行
      うべきである。

      またもう一つのヒントとして報告が上がった時期からして、問題が起こる
      version の組み合わせとして、更新後の version は d4c812b7 に固定して良いの
      ではないかという気がする。

      色々試してみたが問題は再現しない。

      ? reject: というか思ったのだが、報告されている減少は必ずしも cache が問題
        ではないのではないか? 例えば ble-reload した時に古い export fd の設定を
        受け継ごうとして失敗していて、入力はできているけれどもそれが反映されな
        いという状態だったりするのではないか?

        と思ったがそれはやはり変だ。cache を clear したら直ったという話なので、
        cache を clear するまでは再起動しても問題が発生していて、 cache を
        clear したら問題が消えたという事になるのでやはり cache が問題だったと考
        えるべきである。

        或いは単に cache を clear する為に一回抜けて、それで cache を clear し
        た後に再度入った事によって問題が解消したというのを勘違いしているという
        可能性もあるが、複数の人から報告がある。少なくとも最初の人のは勘違いで
        はないだろう。

      ble-reload に伴う fd の問題の可能性もあるのかもしれないが、少なくとも
      issue では cache の問題という事になっているし、取り敢えずはそれを解決する
      べきである。fd の問題は独立した項目・issue で論ずるべきである。

      或いはもっとずっと古い version からの update なのか、或いは issue で議論
      している様に実際に複数の ble.sh のインストールを切り替えて使っている人の
      可能性? 後者だったらやはり単純に timestamp を使っているのがいけなくて、
      cache に commit 番号を埋め込む様にしてしまえば良い。

      もっと古い version からの update を確認してみたが特に問題は生じない。とい
      うか、cmap が必ず更新されるのだから古い version の方がより問題が生じなく
      なるのは自然なのではないか。もし問題が起こるとしたら寧ろ最近の commit の
      方が問題になるだろう。最近の commit について重点的に調べる事にした。少な
      くとも cache の更新が走らない最近の物は全て試したが問題は生じていない。た
      だ、キャッシュが走っていると言っても vi.sh/emacs.sh の更新に伴う物であっ
      て init-cmap.sh についてのキャッシュの更新が走っているかどうかまではチェッ
      クしていない。多分、init-cmap.sh についての更新はされていない気がする。そ
      もそも init-cmap.sh はそんなに変更する物でもないので。もし、init-cmap.sh
      が原因だとしたらやはり古い version も含めた広い範囲の version の実験で問
      題が再現しそうな物である。最後に init-cmap.sh を変更したのは 48c7bbee の
      様なのでその周辺でテストしてみたがそれでも問題は生じない。うーん。

      或いは、最近の物をテストする時に --clear-cache せずにやっているから古い
      commit で作成した cache ではなくて最新の物で生成したキャッシュでテストす
      る事になってしまっている可能性? でももしそうだとしたらそもそも DSR(0) も
      受け取れていないはずだからやっぱり関係ない様な気がする。うーん。でも逆方
      向なら受信できるという可能性?

      未だキャッシュ更新条件に問題があった可能性を否定できないが、まあ簡単に再
      現できそうにないし、また、複数バージョンが並立する時に問題が発生する事は
      分かっているので、その問題に対して対策をするという事で良い事にする。

    2025-05-11 再度状況を整理する。通常の更新では報告されている様なキャッシュの
    不整合は観測できなかった。仕方がないので複数バージョンが並立している場合に
    対してだけ対策を実装する方向性で考える。

    * init-cmap.sh だけでなく init-term.sh や vi.sh, emacs.sh などキャッシュに
      は色々あるという事を考慮に入れる必要がある。

      統一的枠組みを作る可能性もある。但し keymap cache に関しては vi.sh,
      emacs.sh (もしくは nano.sh 等将来的に追加されるもの) のように初期化時に即
      座に必要になりかつ沢山の binding が定義されている物だけに留める。それ以外
      の物は遅延してロードされるのでわざわざキャッシュする必要もない。

      或いはキャッシュは全体の version 毎に管理する事にし、それが変化すれば完全
      クリアするという方式。しかし、それはそれでキャッシュの仕組みの意味が半減
      する様な気もする。できれば論理的な管理にしたい。

      或いは、形式に破壊的変更が入る可能性がある devel の間だけ cache を全体の
      hash に基づいて clear するという可能性。うーん。でも、それだと release に
      使う仕組みに対するテストが為されなくなるという事を意味する。また、結局み
      んなに devel を使ってもらうように推奨している感じで、devel の方が寧ろ本体
      の様になっているので、わざわざ release だけで効果のある物を実装する事に意
      味があるのかという事もある。

    各キャッシュごとに id を記録する方式にするとしたらどうするか。

    a 一つの方法は元のソースの hash を id の中に含めるということ。しかし、git
      hash-object 等を使うと、今度はビルドする時に git repository がないと駄目
      なのは駄目だという文句がまた発生する。また色々 export-subst 等の変な枠組
      みを使ってキャッシュ生成に使う各ファイルの hash を export しなければなら
      なくなる。これは避けるべき。

    b 或いは手動で各キャッシュについて番号を発行してそれを更新する方式。これも
      面倒だし、これは更新し忘れて問題が生じる原因になる。

    c 或いは各キャッシュについて番号を割り当てるのを自動化する方式。然し、これ
      にするとしてもその更新を誰が trigger するのかという事になる。

      git commit で自動的に走らせる様にするという手もあるかもしれないが、それは
      それで git clone した後に追加の設定をしなければならなくなるし、他の人が変
      更をする時に変な要求が増えるという事になり、其処までする程の事なのかとい
      う事がつきまとう。

    d 可能性として各ファイルの hash をキャッシュ生成時に自分で計算して記録する
      という手もある。しかし、その hash 計算に外部コマンドを呼び出すコストがあ
      る。元々キャッシュを導入したのは startup 時の遅延を少しでも早くする為だっ
      たので、キャッシュの整合性を保証する為に毎回ファイルのハッシュを計算しな
      ければならないのでは意味がない。

      照合用の id をキャッシュ側で持っていて、また呼び出し元でも照合用の id を
      保持している必要がある。

      * それを make の時に生成すればよいのだろうか。その id の生成には外部コマ
        ンドが必要で、然し、安定して利用できる hash コマンドは実は存在していな
        い。shat256sum ですらないシステムにはない。POSIX は cksum を定義してい
        るが、それを既定で提供していないシステムも存在する。git が一番安定して
        得られる統一的な hash の関数であるが、ビルドシステムが git に対するアク
        セスを制限している場合すらある。結局安定した hash を定義するためには自
        前で hash を実装しなければならなくなる。それだったら手動管理の id の方
        が良いのだろうか。

      * reject: 或いは単純に前回から違いがあったら increment するという仕組みで
        も良いのかもしれない? と思ったが、それだと全ての commit をスキャンしな
        いといけなくなるのではないか。shallow clone で使えない様な物は避けるべ
        きである。

    e 或いはキャッシュ自体をいっその事 repository に含めてしまう? と思ったが
      bash に対する version dependence や TERM 依存性などあるので単純ではない。
      それに巨大で頻繁に変更されるデータを repository に含めたくない。

    元々日付ベースにしたのは変更に伴って自動的にキャッシュの更新の必要性を検出
    して安全に更新がちゃんと起こることを保証するためだった。だとすると手動で id
    を管理する仕組みにするのだとしたら本末転倒である。なので、自動化は必須とい
    う事にする。また、手動で更新を trigger しなければならないのも同様である。
    make の段階で自動的に id を決定するにしても git repository が必要な仕組みは
    問題があるだろうか。git hash-object は一応リポジトリがなくても各ファイルに
    対して計算できるようだが、一方で git の存在しない環境でビルドしようとするパッ
    ケージも存在する様である。更に、普通ではないとかなんとかとか .zip でダウン
    ロードした物からビルドできるべきとか変な文句を言ってくる人がいる。そもそも
    そんな要求してくる人の方がおかしい気がする。其処まで対応する必要があるのか。

    2025-05-12 もう考えるのは面倒だから timestamp & 手動IDベースにする?
    timestamp が変わっていたら更新するが、それに加えて手動の ID も考慮に入れる。
    と思ったが解決する問題が複数 instance があった場合という事であれば、
    timestamp が動かなかった時にどうするかという話で、それだと手動 ID だけで十
    分なのかという話になる。

    或いは ble.sh の hash に従ってキャッシュを更新するしかないのだろうか。もし
    ユーザーがカスタムで変更したりした場合にはおれでも壊れることになる? でも
    timestamp があるから OK?

    うーん。という事を考えると git hash-object を使えば良いという話になるが…。
    仕方がないので色々の fallback つきで hash を呼び出す? 仕方ない。

    https://unix.stackexchange.com/questions/426837/no-sha256sum-in-macos

    * done: lib/init-cmap.sh

    * dnoe: lib/init-bind.sh ... これはキャッシュを生成するのに使っている。生成
      したら何れにしてもファイルを読み込んでいる。これだと二回 source '<cache>'
      を実行する事になるが仕方がない。或いは init-bind.sh の中で source
      "$fbind1" を実行するという手もある? と思ったが分かりにくいのでやはり二回
      source '<cache>' を試みる事にする。

    その他に vi.sh, emacs.sh に関連するチェックはどうするか? どの key も入力で
    きないという様な状況は vi.sh や emacs.sh の問題ではない様な気がする。取り敢
    えず、キャッシュに hash を導入したのでこれで我慢する事にする。

    * done: lib/init-bind.sh で "$fbind1", "$fbind2" のファイルを毎回開いたり閉
      じたりしているのは非効率的な気がする。特定のファイルディスクリプタに割り
      当てて開いてしまいたい。exec を使うとユーザーのファイルディスクリプタを上
      書きしてしまうので関数呼び出しに対する redirection で実装する。

    x 結局呼び出し元 (decode.sh) でキャッシュに含めるべき hash を指定する形にし
      た。しかし、これには穴があるのではないか。

      これだと ble.sh と同じディレクトリにある lib/init-cmap.sh の関係が異なる
      場合に正しく検出できない気がする。例えば、或る lib/init-cmap.sh に対して
      ble.sh を生成したとする。その後で lib/init-cmap.sh を変更して、それから
      ble.sh をロードすると誤った hash を用いてキャッシュが生成されてしまうが、
      それを後で検出することもできなくなってしまう。GNUmakefile で ble.sh が
      lib/init-cmap.sh に依存する様にしたとしても、make を実行する前に ble.sh
      をロードすると終わりである。とは思ったが、そもそも読み込む init-cmap.sh
      は out に配置した物のはずだから、make を実行しない限りは更新されない筈で
      ある。問題は手動で編集がなされた場合であるが、それは自己責任である。

      でも埋め込む場合でもやはり不整合が生じるのではないか。例えば、
      lib/init-cmap.sh だけ更新した場合、ble.sh の側は更新されないままになる。
      この時、lib/init-cmap.sh だけ hash を更新すると ble.sh の側の hash は更新
      されないままになるので、永遠に hash が一致しないという事態になる。改めて
      考えてみれば、ble.sh の側に hash を埋め込むという事は、ble.sh に
      lib/init-cmap.sh に対する依存性が生まれるという事になる。という事は、
      lib/init-cmap.sh に変更がある度に ble.sh も更新する様に GNUmakefile に依
      存性を指定する必要性がある。

    * done: もう一つの不整合の可能性は生成のタイミングによって git / sha256sum
      / openssl 等の利用できるコマンドの種類が異なった場合である。そもそも同時
      に make するのだからその様な事はないはずだが、それでも、異なるツールを使っ
      ていたとしてもできるだけ一貫した値を計算する様にしたい。

      例えば git が見つからなかったとしても sha1sum を使って git と同じ hash を
      計算したい。

    x 2025-05-13 hash ハッシュテーブルが空ですという謎のメッセージが出るように
      なった。と思ったら cmap cache の hash の出力が壊れている。修正した。

2025-05-06

  * edit: ble/edit/get-clipboard のコマンド判定が間違っている [#D2344]
    Ref #D2307

    また初期化時に沢山のコマンドのパスを確認するのは時間がかかるのではないか?
    遅延初期化にする。元々 0.7ms かかっていたのが 0.13ms になった。大した違いで
    はない様な気がするが良い事にする。

    また freeze-utility-path しているにもかかわらず最終的に freeze した path で
    呼び出していない。freeze した path で呼び出す様に変更する。初期化の途中であ
    れば PATH を未だ設定していない事によってユーザーの望まない binary を選択し
    ていた可能性もあったが、今、遅延初期化するようにしたので、PATH は最終的なも
    のになっていると想定して良い。

2025-05-05

  * decode: keyboard-macro 再生時に char -> key の timeout をどう処理するか [#D2343]
    Ref #D2333

    "C-x ( C-x ) C-x e" によるキーボードマクロの記録再生で ble/decode/charlog
    という仕組みが実装されている。文字の列を記録して、それを再生する事で改めて
    同じ操作をするのに使う。

    ここで、文字の列から key の列への変換が一意でない場合がある。これらは普通の
    入力時には timeout で区別している。具体的には或るキーの表現が別のキーの表現
    の接頭辞になっている時に ble/decode/wait-input を用いて timeout したらその
    キーを採択するという事になっている。しかし、charlog では当然時間間隔は記録
    していないし、入力時の遅延まで再現したくはない。現在の愚直な実装だと、キー
    ボードマクロとしての再生だと既に次の文字が来ている事になるので timeout はせ
    ずにより長いキー表現の一致を必ず試みる事になる。結果として実際に生成される
    キーの列が変わってしまうという問題が起こる。

    * この区別は @ESC (IsolatedESC) と ESC の場合には (bash の version に関係な
      く) 記録される char の値レベルで区別されている。

    * 然し、一般のキーについて wait-input を使って区別をしている場合には、マク
      ロ再生時にその区別を再現できない。或いは別の方法として key を直接 CSI u
      形式でエンコードするという手もあるかもしれないが、現在の実装ではキーボー
      ドマクロは実際に入力された文字列を使っている。そうしないとユーザーに対し
      て現在記録しているマクロの内容を提示する時に不都合だからである。

    * 特に "M-O" (ESC O) と "up" (ESC O A, bash <= 4.4) の区別は問題である。通
      常の入力時には "ESC O A" の方については O を @prefixO に変換して読み取ってい
      るので、ちゃんと区別して記録される。一方で、M-O についてはそのまま ESC O
      で受信しているので、本当に M-O として受け取ったのか bash <= 4.4 の
      workaround を使わずに受け取ったのかの区別がつかない。というか bash >= 5.0
      では結局 @prefixO は使わずに完全に timeout だけで判定している。

      もしこれだけ部分的に対応するのだとしたら IsolatedESC ならぬ IsolatedSS3
      もしくは @IsO を定義することになる。もし全般に wait-input の枠組みを設計
      し直すか、それに関する情報を charlog に埋め込む事にするのであれば、特別に
      SS3 (M-O) の対策をする必要もない。

    wait-input で timeout が起こった時にはそれを記録すれば良いのでは? @timeout
    など。但し、次のステップに行く前に @timeout は除去しなければならない。
    @char_timeout 的な名前にするべきだろうか。或いは何にでも @ をつけるのは違う
    かもしれない。どのレベルの物まで @ をつけるのかは微妙。現状では @ESC 及び
    @prefixO は builtin bind レベルの workaround に使われている。一方で @NUL はマク
    ロ再生用の特別な文字の様な気がする。マクロ再生用と思えば @char_timeout もし
    くは @timeout でも良い気がする。

    ? ok: reach が見つからない場合にそれまでに読み取った文字を全て捨てているが
      これは良いのか? 或いは、2 byte 以上の時には必ず reach がたまっているとい
      う保証があるのだろうか?

      _ble_decode_cmap_ を見てみたが別に reach は登録されていない。うーん不思議
      だ。と思ったら、その次の if-branch で一文字目の時には ent に確定情報がな
      くても reach に登録をする様になっていた。なので OK.

    * テストも簡単にした。動いている気がする。

  * complete: auto_complete_enter は長い。ac_enter 等にする? [#D2342]

    ble/debug/keylog の記録で邪魔である。ただ、邪魔というのであれば ac_enter で
    も邪魔と言えば邪魔の気がする。

    ? no: 他にも類似の特別キーは存在する? → 現時点では特にない気がする。

    * reject: auto_complete_enter の定義を decode.sh / core-complete.sh の一方にする?

      気付いたが auto_complete_enter は decode.sh と core-complete.sh の両方で
      定義されている。本来は外部モジュールで勝手に追加しているキーである事を考
      えると core-complete.sh だけで定義するのが妥当の様な気もするが、キャッシュ
      や諸々の事を考えると結局最初に全て番号を確定しておく必要がある。従って、
      decode.sh の中に定義せざるを得ないという事なのだろう。これは将来的にも変
      わらない気がするので、core-complete.sh における定義は削除してしまって良い
      気がする。

      と思って改めて auto_complete_enter の使用について確認してみたが、キャッシュ
      されている keymap では使われていない。つまり、別に固定する必要もないので
      はないかという気がする。では何故現状で key code を固定しているのか?

      →これは commit 2f9a000a で追加された。この commit は __line_limit__ の実
      装を行った物である。その際に序にすでに使っていると分かっているものは登録
      してしまおうという意図で追加したのだろう。

      現状では実は auto_complete_enter を decode.sh の内部で固定する理由はない。
      なので本定義はやはり core-complete.sh の中にあって良い気がする。

    * reject: auto_complete 等の小さな keymap についてもキャッシュする仕組みを作る?

      だとしたら将来的に key を固定する必要も出てくる。

      ? ここでの疑問は小さなkeymap にキャッシュを行う利点は或るのかという話。

      そもそもキャッシュするのは ble-bind の引数解析が意外と遅いという事。そし
      て起動時にキー入力を受け付けられる様になるまでに時間がかかるのが問題だっ
      た。main の keymap は沢山のキーを定義する必要があるし、一瞬でも早く初期化
      を完了したかった。一方で、auto_complete_enter の様な keymap は on demand
      の keymap であり、必要になった時に初期化すれば良い。そして、サイズも小さ
      いので overhead も気にならない筈だ。特に最近の計算機は早いのでそもそも初
      期化時の遅延も大抵は気にならないのでは無いか。

      という事を考えると小さな keymap についてもいちいちキャッシュする利点はな
      い。単にファイルの読み込みが増えるだけだし、キャッシュの不整合の問題が起
      こりやすくなる。わざわざ全ての keymap についてキャッシュをできる仕組みを
      整える程でもない。

  * decode: キーの定義を decode.sh の中ではなく lib/init-cmap.sh の中で行う [#D2341]

    キーの定義を decode.sh の中ではなく独立した registry ファイルの中で行った方
    が明確で管理しやすいのではないかという可能性について。

      a init-cmap.sh も本当はキーが追加された時に更新しなければならなくて、それ
        を手動で init-cmap.sh に日付付コメントを追加することで行っているが、独
        立したファイルにするならばそれも自動的に解決できるのではないだろうか。
        と思ったが、今考えているのは最終的に ble.sh の内部に include する形なの
        で、timestamp を得ることができず、結局 init-cmap.sh の自動更新には使え
        ない。

      b 或いはもう一つの可能性として init-cmap.sh の中にキーの定義も移動してし
        まうという物。そしてキー登録で生成されるデータもキャッシュの一部とする。

      c 更に別の可能性は init-cmap.sh に移動するが、そもそも init-cmap.sh の内
        容をメインの ble.sh の中に含めてしまうという物。実のところファイルサイ
        ズ的には微々たる物の気がする。9 KB である。一方で ble.sh 本体は 1053 KB
        である。1% 程の大きさである…意外と大きかった。

      キーの定義にかかっている時間を計測すると 4ms かかっている。意外と大きな時
      間だ。やっぱり単に parse するのと処理を実行するのでは時間に差があるのだ。

      ロードの仕方によって adict/gdict の二種類がある…と思ったが、これはファイ
      ル名で分ければ良い。すでにその様なキャッシュファイルが存在している。とい
      うより cmap cache が既にその様になっているので、単に cmap cache を拡張す
      れば良いだけでは?

      →確認してみると実は既に cmap cache の中に kbd のデータも含まれている様だ。

      _ble_decode_KCODE_@ も cmap cache に含める様にしたら
      ble-decode-kbd/.initialize を実行しなくても普通に動く様になった。うーん。
      だとするとやはり ble-decode-kbd/.initialize の内容は init-cmap.sh に移動
      してしまって良い気がする。

    cmap/initialize は decode/initialize から呼び出されている。つまり、もし kbd
    の定義を其処まで遅延すると kbd の定義も其処まで遅延される事になる。

    ? ok: 現状で cmap/initialize を decode/initialize まで遅延しているのは問題
      ないだろうか。例えば、ble-bind -k は decode/initialize が呼び出されるより
      も前に実行されるのではないか。そうするとキャッシュされる内容はユーザーが
      修正した後の物になるのではないか? と思ったが改めて確認してみると ble-bind
      の先頭で ble/decode/initialize を実行しているから問題ないのだった。

      つまり、もし kbd についても ble/decode/initialize まで遅延させるのであれ
      ば、ble-decode-kbd や関連する関数からも ble/decode/initialize を呼び出す
      事になるのではないか。

    * reject: というかそもそも cmap/initialize を decode/initialize の中で実行
      する理由は何か。即座に実行してしまっても良いのではないか。

      と思ったが --lib で実行する時にも初期化をする必要があるのかという問題があ
      る。と思ったが本来は decode.sh は実際に使う時にしかロードしないという想定
      ならば、ロードした時点で必要な初期化を実行してしまって良い気がする。単に
      現在の ble.sh --lib 的には使わない module まで全部含まれてしまっていると
      いうだけで、本来は decode.sh は一つの module ファイルとして独立して提供し
      ても良いのだ。

      というか、ble/edit/info に進捗状況を表示しているが、もし decode.sh のロー
      ド時に強制的にcmap/initialize を実行するのであれば、これは表示するべきで
      はない。そもそも ble/edit/info を使っていたのは初期化に時間がかかっていた
      からだと思われるが、allseq の生成を落とした今となっていは処理時間は大した
      事はないのではないか。と思ったが、init-cmap.sh の中自体で色々
      ble/edit/info を表示している。つまり、それぞれ実際に時間がかかるという事
      ではないか。

      実際にどれぐらいの時間がかかるのかについて計測する: 232ms かかっている。
      意外と長いがそれ程長いという訳でもない? 微妙な長さである。遅い計算機では
      より時間がかかるかもしれない。やはり ble/edit/info による表示はあった方が
      良い気がする。

      また --lib で読み込んだ時に使いもしない ble/decode の機能の為にキャッシュ
      が生成されるのもやはり微妙な気がする。という訳なので、やはり
      cmap/initialize は現状の様に ble/decode/initialize が呼び出されてから実行
      するという事にする。

    取り敢えず cmap/initialize の中から呼び出した init-cmap.sh の中で
    ble-decode-kbd の初期化も行う事にした。

    * done: 今やキャッシュしているので kitty の key にも全て keycode を初期化時
      に割り当ててしまって良いのでは。恐らく今まで遅延初期化していたのは単に
      kitty の特別キーが多すぎて初期化に時間がかかると予想されたからであろう。

      と思って固定しようと思ったら既に init-cmap.sh の中で固定している。確認し
      てみると commit fdfe62a4 で何も考えずに固定したという事の気がする。わざわ
      ざ .generate-keycode の呼び出しを改めて呼び出す必要もないので削除する事に
      する。と思ったが何れにしても name から key を得る必要があったので
      .get-keycode を呼び出す必要はあったのだった。

    * csi の関数名が気になるのでこの際なので変更しておく。

  * decode: bashrc の中で ble-bind を使うとキャッシュ初期化時に info が表示され残る [#D2340]
    Ref #D2341

    bashrc の中で ble-bind を実行した時に immediate-show が変な物を表示しないの
    か? → うーん。実際に表示してしまっている。これは対策が必要である。

    a そもそも ble/edit/info の方を修正して未だそのレイアウトでない時には何も表
      示しない様にするか、

      ble/edit/info を確認すると is-command-layout の時にはちゃんと表示しない様
      になっている気がする。つまり、一旦 ble.sh が有効になればユーザーコマンド
      を実行中には余計なメッセージが出ない様になっている。

      調べると他にも _ble_app_render_mode == panel でない時には表示しないなどの
      処理もある。

      という事なのであればそもそも attached じゃない時には表示しないというのも
      同様に実装しても良い様に思われる。

    b 或いは、cmap の呼び出し元の方を修正してメッセージを設定しないようにするか。

    修正してみた。然し、これだとユーザーが .blerc の中に少しでも ble-bind の設
    定を持っていると、初期化の ble/edit/info の進捗状況が表示されない事になる。
    ble-bind を利用するのは対話セッションだけだともし仮定するのだとしたら、やは
    り ble/edit/info を ble-bind の呼び出し時に表示してしまっても良いのではない
    だろうか? とも思ったが、それでもやはりレイアウトが崩れる原因になっている事
    は確かなので微妙である。

    というかこれは以前にキャッシュ更新時に generating ... などの文字列が画面上
    に残るという報告の原因ではないだろうか。

    a 一つの解決法は ble-bind の実際の処理を更に遅延するという事。もし ble-bind
      が keybinding を追加する為のものであれば何れにしても keymap　の初期化まで
      処理を遅延するのだから cmap やその外をその時点で処理する必要はない。

      然し、ble-bind -P 等を初期化時に呼び出した時には結局その場で初期化を実行
      しなければならない。なので、其処でキャッシュ初期化のメッセージを表示した
      くなる。とはいえその様な使用方法は稀なのでその様な場合は初期化メッセージ
      は表示しないというのも手かもしれない。

    b もう一つの解決法は source ble.sh の中で _ble_attached よりも前に表示した
      ble/edit/info のメッセージは source ble.sh の末尾で消去するというもの。

      然し、本来は source ble.sh の最中にメッセージは表示したくない。勘違いして
      エラーメッセージだと思って初期化を停止する window manager が存在するから。
      或いは、出力先が tty の時にだけメッセージを表示する? 無理やり /dev/tty に
      出力するのではなく自然な stderr が tty に繋がっている時にのみ UI を表示す
      る事にするという手。

      初期化時の bash version check の出力先・出力条件については #D2339 に分離
      した。結局 stderr が tty に繋がっている時に stderr に出力する事にした。

      ble-bind に伴う初期化についてはどうだろうか。stderr が tty に繋がっている
      時に其処に出力する?

      ? と思ったが、そもそも --lib で読み込んだ時には _ble_util_fd_tui_* の接続
        先はどうなっているのだろう → util.sh を確認してみた所、--lib かどうか
        に関係なく tty が見つからない場合には _ble_util_fd_tui_stderr 等は元々
        の stderr になる様だ。

      従って、ble/edit/info は _ble_attached ではない時は、
      $_ble_util_fd_tui_stderr が tty かどうかで出力するかしないかを決めるとい
      うので良い気がしてきた。

    c と思ったが b の方針で一時的に info を表示して、 source ble.sh の最後で消
      去するとしても、他のコマンドで端末に何か出力する物があったら結局 layout
      が乱れる事になる。というか関係ないものを削除してしまう恐れがある。という
      事を考えると、attach 前に出力する可能性があるコマンドの直後には
      immediate-clear を何れにしても実行するべきなのではないか。或いは、attach
      前の時に限定して immediate-clear を実行する。

      と思ったら immediate-clear ではなくて immediate-default しかなかった。で
      も default を設定していない限りはこれで clear される筈? でも、既に前の
      attach で set-default が設定されていて、それが残っていたとすると、それが
      再び表示されるのも変な気がする。やはり明示的に clear するべき?

    取り敢えず c の方針で修正した。振る舞いについて確認する。

    x fixed: と思ったが全然消去されない。確認してみると ble/edit/info/show
      clear を呼び出すと実際に空にするのではなくて default の内容が表示されるの
      だった。寧ろ text '' でも出力するべきなのかもしれない? と思ったが、その場
      合でも default が表示される様になっている。

      ? ここでの疑問は何故 default になっているのに内容が消去されないのかという
        事。default にも内容が設定されているという事なのだろうか? うーん。
        default の内容もちゃんと空になっている。

        どうも default はその場ですぐに内容を反映しようとはしない様である。内部
        的に defer を指定している。従って、immediate-show の意向が反映されない
        という事になる。

      即座に反映するオプションを作るべきか、或いは immediate-show の側で show
      と同じ様に分岐して、但し、immediate-default を呼び出す様にするべきなのか。
      うーん。面倒なので immediate-clear を作成する事にした。

      * ok: default に何か設定されていたとしても中身を消去する様にしたい。その
        場合にはどうしたら良いか。やはり clear を呼び出すべきなのだろうか。→こ
        れは immediate-clear を実装してそれを使う様にしたのでOK

    * fixed: imeediate-show の実装を確認してみると結局 save-position 等の為に出
      力を行ってしまうので、ble/edit/info の中だけで出力するかどうかを判定して
      も意味ないのでは。

      これは判定用の関数に分離してそれを immediate-show 側でも参照してその場で
      出力するかしないかを判定する事にした。

    * done: また decode.sh の方にある初期化メッセージの出力やキャッシュ作成コー
      ドも init-cmap.sh の方に移動する。

    * これは以前に何処かの issue で報告された物の様な気もする。後で確認する。→
      探したけれど見つからない。仕方がないので取り敢えずOKという事にする。後で
      見つけたらコメントする。と思ったが見つけた。恐らく以下の物である。しかし
      これは tput cache 更新のメッセージだったので、消せないものであり、関係な
      い。

      https://github.com/akinomyoga/ble.sh/issues/415

  * main: check-bash-debug-version: stderr が tty かチェックして出力する [#D2339]
    Ref #D2341

    そもそも release version チェックの警告を出力している時は出力先が tty かど
    うかチェックしているのだったか。うーん。確認してみた所チェックしていない。

    x fixed: しかも stderr ではなくて stdout に出力している。ble.sh --lib 等の
      様にした時には一行の短いバージョンを出力しているが、何れにしても stdout
      に出力している。

      これだと scp 等に対して問題が生じる (ただ scp は non-interactive なのでや
      はり問題はないかも)。取り敢えず stderr に繋ぎ変える事にした。

    * ble/base/check-bash-debug-version に於いて type once の時以外でも毎回
      base.bash-debug-version-checked.txt を読み出しているが無駄では。これによっ
      て once を指定した時に、「once を指定するよりも前に一度でも警告を表示して
      いればもう表示しない」という具合にする事ができるが、それよりは「once を指
      定してから一度でも警告を表示していればもう表示しない」という振る舞いの方
      が自然ではないか。

    x それに加えて出力先が tty の時にのみ Bash version チェックの結果を出力する
      か? 或いは、ログに残る事を期待して出力先が tty でなくても同様のエラーメッ
      セージを出力する? うーん。難しい。

      少なくとも出力先が tty ではない時には着色はしない様に変更するべきである。

      出力先が tty でない時に出力するべきか出力するべきでないかは微妙である。そ
      もそも、window manager が勝手にチェックをする時にどの様な状況だったか分か
      らない。stderr や stdout が tty だったかどうだったかも分からない。あやふ
      やな理由で決断はできないので過去の記録を探す。

      と思ったが見つからない。done.txt に window manager 以外の言葉で記録が残っ
      ているだろうか。デスクトップ環境も見つからない。カタカナも試すが見つから
      ない。kde や gnome でも見つからない。xfce でも見つからない。GitHub issues
      を検索してみても見つからない。stderr は少なくとも含まれていたはずと思って
      それで検索してみたがなかった。という事はこのエラーは別の project で受け取っ
      た物だったか? 或いは、単に自分で経験した問題で自分で解決したのだった様な
      気もする。うーん。でも誰かに報告を受けたような気がするが気の所為だったか?
      ChatGPT で internet を global に検索していてようやくそれっぽい物が見つかっ
      た。

      https://github.com/Schniz/fnm/issues/164#issuecomment-2216318315

      これは Ubuntu の /etc/gdm3/config-error-dialog.sh が勝手にメッセージを表
      示するという物である。そう思って改めて ble.sh の done.txt を検索したら
      #D1676 が関連項目で、元々以下の issue だったという事が分かった。

      https://github.com/akinomyoga/ble.sh/issues/141

      然しここには stderr が何に繋がっているかまでは調べられていなかった。類似
      の情報について検索したが、何れも実際に stderr が何に繋がっているのかまで
      は書かれていない。うーん。実際に Ubuntu で振る舞いを確認してみる?

      https://discourse.gnome.org/t/are-you-sure-you-want-to-proceed-message-on-login/13758/13

      然し、一般的な対策をするのだとしたら Ubuntu 固有の振る舞いを元に判定する
      のも微妙な気がする。例え Ubuntu で端末でなかったとして、それを使って
      stderr に出力するかどうかを決めるのだとしても、他の distribution で本当に
      端末を作成して情報を読み取ろうとする事もあるかもしれない。うーん。然し、
      たかが bashrc を読み取るだけに端末を作成するというのも変な気がする。

      OK. VM の Ubuntu で再現した。tty には繋がっていない。tty に繋がっていない
      時にエラーを出力すると Ubuntu がエラーメッセージを出力する様になるので何
      も出力しない事にする。

2025-05-04

  * cmap: \e[0n にキー名を割り当てる [#D2338]
    https://github.com/akinomyoga/ble.sh/issues/580
    https://github.com/ajeetdsouza/zoxide/pull/1048#issuecomment-2848727192

    ユーザーに "bleopt decode_error_cseq_discard=" を指定させるのも変なので。他
    にもこれを使おうとするフレームワークが存在しそうなので、これにはキー名を割
    り当てる事にする。

    また、これにより、terminal が 8-bit control sequence "CSI 0 n" を返した時に
    も対応できる様になる。

  * [解決済] 2024-02-01 Konsole MR !951 はどうなった? [#D2337]
    https://invent.kde.org/utilities/konsole/-/merge_requests/951

    2025-05-04 これは既にマージされている。

  * [解決済] 2023-07-31 bash <= 4.4 & contra & mercury で矢印キーが動かない [#D2336]

    bash-4.4 で矢印キーが動かなくなっている。bash-3.2..4.4 の全てで動かなくなっ
    ている。

    % contra では起こるが xterm では起こらない。mintty でも起こらない。contra
    % 特有の可能性もある。bash-5.0 以上では動いているので contra が悪いという事
    % ではない気がする。 ESC O A 等の形式でキーを送信する端末において発生してい
    % る。これは bind の問題の様な気がする。
    %
    % と思ったら再現しなくなった。どうも、一旦 mercury にログインした事のある
    % contra の仮想端末でなければ再現しないという事だろうか。再現しない時には
    % ESC [ A が送信されているが問題が再現する時は ESC O A が送信されている。うー
    % ん。ESC O をその場で処理するかどうかが関係している気がする。然し試してみ
    % たところ mercury にログインしても front1 にログインしても再現しない。再現
    % 条件が分からない。こうなると xterm や mintty で起こらなかったのも偶々の可
    % 能性がある。
    %
    % chat 経由で mercury に入っても再現しない。screen の中から mercury に入っ
    % ても再現しない。chat の中の screen の中の mercury でも再現しない。

    分かっている事: 端末が矢印キーに対して ESC O A を送信する状態になると
    bash-4.4 以下で問題が発生する。然し、どのようにしたら端末が ESC O A を送信
    する状態になるのかの再現方法は不明。

    2023-08-02 再現方法が分かった。screen に入った状態で接続が切れたりして抜け
    ると中途半端な状態になって ESC [ A の代わりに ESC O A が送信される状態にな
    る。更に、この状態では bash-5.0 以降であっても矢印キーの振る舞いが変である。
    複数行コマンドラインに於いて上下キーで行の間を移動したいが、ESC O A になっ
    ている時には履歴項目の間の移動になっている。何故この様な違いが出るのかはよ
    く分からない。kpup などに翻訳されているという事だろうか。また再現した時に
    keylog でどのような受信・翻訳になっているかを確認する事にする。

2025-05-03

  * 2025-04-26: connect_tty に inherit が設定されていても ble.pp の最初のチェックで棄却される [#D2335]

    connect_tty に inherit が設定されていても ble.pp の最初でそれをチェックして
    いないから、結局 >/dev/tty も 1 も 2 も見つからなかった場合には、親 ble.sh
    が記録した tty が未だ生きていても ble.sh のロードがキャンセルされてしまうの
    では。

    これは最近何処かのタイミングで諦める事にしたのだったか? → 調べてみたが始め
    から現在の様な設計になっている様だ。

    取り敢えず connect_tty=inherit の時に fd が export される様なので、それを
    チェックして見る事にした。

  * decode: 古い init-bind.sh の方針は削除して良い気がする [#D2334]

    最近安定しているので今後改めて使うことはないのではないか。

2025-05-02

  * decode: "ESC O A" vs "ESC O" の区別が 4.0 <= bash < 5.0 でついていない [#D2333]

    solaris でキーボードが入力できない。上キーを押すと変な事になる。これは一体
    何が起こっているのだろうか。ESC O D を受け取っている様に見える。元々 ble.sh
    では既定で ESC O D に対応している筈なのに何故失敗するのだろうか?

    或いは vi mode では ESC O を分解する様な処理にしていたのだったか? 何か変更
    をした様な気がするが覚えていない。

    うーん。2023-07-31 の項目と同じ現象と思われる。mercury の上で keylog をして
    みると以下の結果になっている。何故 O が重複しているのだろう? 或いは vi mode
    における再解析の問題?

      ===== bytes =====
      192 155 79 65 192 155 79 67 5 5 5 6 6 6
      6 6 6 127 127 127 127 127 98 107 101 127
       127 108 101 47 100 101 98 117 103 47 10
      7 101 121 108 111 103 35 101 110 100 13

      ===== chars =====
      ESC O O A ESC O O C ENQ ENQ ENQ ACK ACK
      ACK ACK ACK ACK DEL DEL DEL DEL DEL b k
      e DEL DEL l e / d e b u g / k e y l o g
      # e n d RET

      ===== keys =====
      M-O ESC O A auto_complete_enter M-O M-O
      ESC O C C-e C-e C-e C-f C-f C-f C-f C-f
      C-f C-? C-? C-? C-? C-? b k e auto_compl
      ete_enter C-? C-? C-? l auto_complete_en
      ter e / / auto_complete_enter d e b u g
      / / auto_complete_enter k e y l o g # e
      e auto_complete_enter n d C-m C-m

    問題の起こっていないシェルでは以下の様な結果になる。

      ===== bytes =====
      192 155 79 65 127 127 127 127 127 101 11
      0 100 13

      ===== chars =====
      ESC O A DEL DEL DEL DEL DEL e n d RET

      ===== keys =====
      up C-? C-? C-? C-? C-? e auto_complete_e
      nter n d C-m

    chat の上でも bash-4.4 を試すと問題が生じる。

      ===== bytes =====
      192 155 79 65 6 6 6 6 21 21 21 98 108 10
      1 47 100 101 98 117 103 47 107 101 121 1
      08 111 103 35 101 110 100 13

      ===== chars =====
      ESC O O A ACK ACK ACK ACK NAK NAK NAK b
      l e / d e b u g / k e y l o g # e n d RE
      T

      ===== keys =====
      M-O ESC O A C-f C-f C-f C-f C-u C-u C-u
      b l e / auto_complete_enter d e b u g /
      / auto_complete_enter k e y l o g # e e
      auto_complete_enter n d C-m

    受け取っている bytes は同じでもそれを chars にする時に違いが出ている…とい
    う事は decoder の振る舞いがおかしいという事になるのだろうか? 算術式の問題?
    UTF-9 decoder の出力を見たが問題はない様だ。という事は、ble-decode-char の
    処理が問題という事になる?

    問題がある状況での ble-decode-char の呼び出しを見ると以下の様になっている。

      ble-decode-char:1(27)
      27 (27)
      ble-decode-char:1(79)
      79 (79)
      79 (79)

    二つ気づく事がある。

    x ok: 本来は 27 79 が同時に decode されて入ってきて欲しいのにばらばらに受信
      している。これは何故だろう? UTF-8 の decode の時点でばらばらに渡している
      という事だろうか。

      →どうも bash-4.4 では "ESC O ?" に対しては is-stdin-ready が常に失敗する
      様で、それによって各バイトが別々に処理される事になるようだ。但し、各バイ
      トでコマンドライン編集やレンダリングが発生する訳ではないので、これ事態は
      そんなに問題ではない。

    * ok: もう一つ気づく事は ble-decode-char の二回目の呼び出しで受信したのは
      79 単体の筈なのに、それに対するループが二回実行されている → #D2321。

    より詳細に振る舞いを調べる。

      正常な処理

      ble-decode-char:1(27)
      ble-decode-char:1(79)
      ble-decode-char:1(65)
      27 ichar=0 (27 79 65)
      5:ichar=1 ent=(_)
      6:ichar=1
      79 ichar=1 (27 79 65)
      ble-decode-char/.getent: ent=(_)
      _ble_decode_char2_seq=_27
      _ble_decode_char2_reach_key=67108955
      5:ichar=2 ent=(_)
      6:ichar=2
      65 ichar=2 (27 79 65)
      5:ichar=3 ent=(1114161)
      6:ichar=3

      問題の処理

      ble-decode-char:1(27)
      27 ichar=0 (27)
      5:ichar=1 ent=(_)
      6:ichar=1
      ble-decode-char:1(79)
      79 ichar=0 (79)
      ble-decode-char/.getent: ent=() ... うーん。この時点で違う
      _ble_decode_char2_seq=_27
      _ble_decode_char2_reach_key=67108955
      5:ichar=1 ent=()  ... ent が空になっている
        51: rest=(79)   ... $_ble_decode_char2_reach_key のブランチに入っている
        52: chars=(79)
      6:ichar=0
      79 ichar=0 (79)
      5:ichar=1 ent=()
      6:ichar=1

    どうも ble/decode/wait-input の結果が異なっている気がする。bash-4.4 では
    wait-input が常に失敗する事によって M-O 迄で独立したキーとして見做されてい
    る。

    * ok: しかしそうだとしても、未処理の部分として改めて O が処理されてしまうの
      は問題である → これは独立した項目で修正する事にする: #D2332

    | * wait-input の問題に対処する。これは ble-decode-char が一文字ずつ処理さ
    |   れている事とも関係していそうである。というか、is-stdin-ready が壊れてい
    |   る可能性?
    |
    |   ble/decode/process-char/.getent:1: ent=(_)
    |   ble/decode/wait-input:1a
    |   ble/decode/wait-input:2
    |   ble/decode/wait-input:3 -> この後で is-stdin-ready が成功すれば抜ける筈
    |   ble/decode/wait-input:4 -> 抜けていない。つまり is-stdin-ready が false
    |   ble/decode/process-char/.getent:2: ent=()
    |
    |   正常な場合
    |
    |   ble/decode/process-char/.getent:1: ent=(_)
    |   ble/decode/wait-input:1a -> この時点で未処理のバイトがあるので抜ける。
    |   ble/decode/process-char/.getent:2: ent=(_)
    |
    |   つまり、is-stdin-ready が意図通りに動いていないのが原因である。何故だろ
    |   う?  この振る舞いは以前からあったので、実はだいぶ昔から is-stdin-ready
    |   が動かなくなっていた? 不思議だ。
    |
    |   * reject: 或いは既に読み取った後だったりする? うーん。そんな事はない。
    |     実際に受信しているのは O までだけである。A は未だ受信していないので
    |     stream の中に残っている筈。
    |
    |   実際に builtin read -t 0 の振る舞いを調べてみる。_ble_util_fd_tui_stdin
    |   を経由しないようにしても駄目。直接 builtin read -t 0 を呼び出しても駄目。
    |   何故だろう。それだと bash-4.* 全般に auto-complete 等も含めて動かない事
    |   になってしまう気がするが、何故受信されない状態になってしまうのか。
    |
    |   というかそもそもずっと待っていても A が現れない…という事は idle task
    |   が存在しなかったとしても駄目という事? 或いは idle task を待っている所為
    |   でこの様な事態になっている可能性?
    |
    |   と思ったがよく見てみるとそもそも ESC O A の ESC (の ble.sh 内部コード)
    |   を受け取る時点で is-stdin-ready が失敗していて後続がある事をちゃんと検
    |   出できていない。一方で、貼り付けで "hello" 等を一気に入力した場合にはちゃ
    |   んと後続があるという事を検出できている。何故このような違いが生まれるの
    |   だろうか。
    |
    |   * 例えば文字列マクロの処理中だと次の文字を既に読み取った状態になってい
    |     る可能性? マクロの処理中にはそういう変な事になるというのは実は前に認
    |     識していたのでは? と思ったが、でもそれはマクロが終了した後に何も後続
    |     の処理がない場合に、メモリ上にあるマクロの文字列を検出できないから
    |     is-stdin-ready が失敗するという話で、今回の様に更に続きの文字があるの
    |     に受信できないという状況とは別なのでは?
    |
    |     今回の場合とは独立にこれについても対処するべきでは? とも思ったが考え
    |     てみれば char や key の sequence が中途半端である場合には何れにしても
    |     続きの処理は実施されないので、特に overhead になるという事はない筈。
    |     寧ろ、今回の様に M-O から来る ESC O と up から来る ESC O A を見分ける
    |     必要がある場合には "ESC O" だけを見た状態でそれが中途半端な受信状態か
    |     どうかを判定するのには使えない。
    |
    |     また改めて実行してみると _ble_decode_hook の段階では結局正常動作して
    |     いる場合においても、is-stdin-ready は false のままで、キャッシュされ
    |     ずにそのまま実行されている。但し、これは ESC [ A の場合。ESC O A の場
    |     合は振る舞いが異なるのかもしれない。端末の状態が壊れた状態で試さない
    |     と再現できない。
    |
    |     何れにしても受信中に is-stdin-ready になってしまう問題は今回の話と関
    |     係ないかもしれない?
    |
    |   * reject: 今 4.4 では ESC O A の組み合わせに対して bind -x して受信してい
    |     る。と思って改めて確認してみたがその様にはなっていない。何処かのタイミ
    |     ングでその様になってしまうのだろうか。或いは、ログインした時の条件? 或
    |     いは勘違い?
    |
    |   ? ok: 5.3 でも "ESC [ A" については一旦 "M-[" というキーとして解釈され
    |     て、その後で "A" が来た時点で "up" に変化している気がする。何故ちゃん
    |     と変換できている? どうやら csi 処理によってちゃんと続きがあるという事
    |     を検出できている様だ。
    |
    |     もしかすると bash は 1 byte 程度なら先読みしてしまっているのかもしれ
    |     ない? と思ったがそれも何だか変だ。うーん。或いは、CSI seq は認識して
    |     先に読み取りを実行してしまっている可能性? でも CSI sequence に関して
    |     は問題は生じていないという事。
    |
    |     bash-5.x で CSI sequence を認識する処理でも追加されたのかもしれないと
    |     思って bash 5.0 を試してみたが、is-stdin-ready が失敗する動作は bash
    |     5.0 でも同様である。依然として普通の文字列を貼り付けた場合には
    |     bracketed-paste-mode の marker も含めて期待通りに is-stdin-ready が成
    |     功している。これは一体どういう状態なのだろう? 或いは bash 5.0 になる
    |     前から csi sequence についてはずっとそうだったのかもしれない。
    |
    |   * 改めて ESC [ A と ESC O A で系統的に実験する必要がある。
    |
    |     | bash-5.3
    |     |
    |     | ESC O A
    |     |   _ble_decode_hook:(192) ready(tty)=0 read(0)=0,0
    |     |   _ble_decode_hook:(155) ready(tty)=0 read(0)=0,0
    |     |   _ble_decode_hook:(79) ready(tty)=0 read(0)=0,0
    |     |   _ble_decode_hook:(65) ready(tty)=1 read(0)=1,1
    |     |
    |     | ESC [ A
    |     |   _ble_decode_hook:(192) ready(tty)=1 read(0)=1,1
    |     |   _ble_decode_hook:(155) ready(tty)=1 read(0)=1,1
    |     |   ble-decode-char:1(27)
    |     |   ble/decode/process-char/.getent:3: ent=(_)
    |     |   _ble_decode_hook:(91) ready(tty)=1 read(0)=1,1
    |     |   ble-decode-char:1(91)
    |     |   ble/decode/process-char/.getent:1: ent=(_) is-stdin-ready=1
    |     |   ble/decode/process-char/.getent:2: ent=()
    |     |   ble/decode/process-char/.getent:3: ent=(_)
    |     |   _ble_decode_hook:(65) ready(tty)=1 read(0)=1,1
    |     |   ble-decode-char:1(65)
    |     |   ble/decode/process-char/.getent:3: ent=(1114161)
    |     |
    |     | bash-4.4
    |     |
    |     | ESC O A
    |     |   _ble_decode_hook:(192) ready(tty)=1 read(0)=1,1
    |     |   _ble_decode_hook:(155) ready(tty)=1 read(0)=1,1
    |     |   ble-decode-char:1(27)
    |     |   ble/decode/process-char/.getent:3: ent=(_)
    |     |   _ble_decode_hook:(79) ready(tty)=1 read(0)=1,1
    |     |   ble-decode-char:1(79)
    |     |   ble/decode/process-char/.getent:1: ent=(_) is-stdin-ready=1
    |     |   ble/decode/process-char/.getent:2: ent=()
    |     |   ble/decode/process-char/.getent:3: ent=()
    |     |   ble/decode/process-char/.getent:3: ent=()
    |     |
    |     | ESC [ A
    |     |   _ble_decode_hook:(192) ready(tty)=1 read(0)=1,1
    |     |   _ble_decode_hook:(155) ready(tty)=1 read(0)=1,1
    |     |   ble-decode-char:1(27)
    |     |   ble/decode/process-char/.getent:3: ent=(_)
    |     |   _ble_decode_hook:(91) ready(tty)=1 read(0)=1,1
    |     |   ble-decode-char:1(91)
    |     |   ble/decode/process-char/.getent:1: ent=(_) is-stdin-ready=1
    |     |   ble/decode/process-char/.getent:2: ent=()
    |     |   ble/decode/process-char/.getent:3: ent=(_)
    |     |   _ble_decode_hook:(65) ready(tty)=1 read(0)=1,1
    |     |   ble-decode-char:1(65)
    |     |   ble/decode/process-char/.getent:3: ent=(1114161)
    |
    |     ESC [ A については一貫して is-stdin-ready は 1 である。つまり bash は
    |     csi seq を特別に処理していると見るべきである。一方で、ESC O A は
    |     bash-4.4 と 5.3 で振る舞いに違いがある。
    |
    |     これは bash-4.4 の bind 設定の違いによるものだろうか。或いは bash 自
    |     体の振る舞いが変わったのだろうか。取り敢えず binding について確認をす
    |     る→確認してみた所、4.4 と 5.3 で特に違いはない。5.3 で新しい widgets
    |     が幾つも増えたという事ぐらいである。
    |
    |     従って bash 自体の振る舞いが変化して "ESC O x" について特別に処理しな
    |     くなったということの気がする。

    [結論] どうもキー受信時に is-stdin-ready が 1 になってしまう問題は bash-5.3
    でも ESC [ A 等に対して存在している。しかし、これは ble.sh の csi seq 検出
    によってちゃんと続きがあるという事を認識できている。ESC O A については
    bash-4.4 と 5.3 で振る舞いが異なっていて、bash-4.4 の時には ESC [ A と同様
    に先に既に文字列を全て読み取ってしまっている気がする。

    [対処方法] これの対処方法としては "ESC O x" に対しては 4.4 では
    is-stdin-ready が 1 であっても後続の文字があると想定する事? しかしそれだと
    M-O を押した時に動作が固まってしまうという問題が生じる。そもそも端末の状態
    が正しければ "ESC O x" 等を送ってくる事はない筈で、そう思うと M-O を優先さ
    せるべきの様な気もする。

    一つの対策方法は isolated ESC の時と同様に ESC O と ESC O A を両方 bind し
    てしまうという事。以前これ関連の対処をしたようなしないような気がするが何処
    へ行っただろうか。うーん。init-bind.sh を確認する限りは ESC O に対する特別
    の処理は何もしていない。

    これに対応する為には新しく IsolatedESC に類似の IsolatedMetaO 的な物を追加
    する必要がある。

    * 先ず新しいコードを割り当てる必要がある。#D2138 で変更したばかりだが、更に
      新しいコードを割り当てるとしたら何処だろうか。判定的には UTF-8 表現の 1
      byte 目が共通であって欲しい。現在は DF である。然し、UTF-8 の 1 byte 目が
      DF である範囲 U+07C00..U+07FF にはもう空いている文字はない。という事は、
      IsolatedESC も含めて一緒に移動する必要があるのではないか。

    また IsolatedESC と同様に複雑な判定を諸々の場所に追加しなければならなくなる
    可能性について考える。もし無駄に複雑になるのだったら別の方法を考えるか、諦
    める方が良いかもしれない。

    a reject: 例えば IsolatedSS3 にするとそれが後で ESC O の 2 chars に分裂する
      事になるので処理として複雑になる。というより、例えば ESC だけを使った key
      が発行された時にそれに対応する char の記録をどうするのかという問題が生じ
      る。

    b reject: という事を考えると IsolatedO みたいな物を用意する事になるのだろう
      か?  しかしそれはそれで変な気がする。

      →これは d と同じ理由で余り意味がない。

    c reject: それよりは KeySeparator 的な sequence を挿入して其処で一つの key
      としての解釈を強制的に中止するという機能を追加した方が良いのではないか。
      実は IsolatedESC も不要になる?

      と思って実装しかけたがこの方針は駄目だ。何故ならば "ESC O @sep" と "ESC O
      A" で区別する事になり、またもう一つの可能性として bind1B4FXX が有効でない
      場合には "ESC O" が単体で来る。なので "ESC O" の時点では次の文字が来てい
      ることを期待して抜けて良いのかそうでないか判定できない。

    d 或いは IsolatedESC に対応して Meta 確定の ESC として MetaESC 的なものを用
      意する?

      と思って実装仕掛けたがこれも駄目だ。今現れるのは (1) bash >= 5.0 で現れる
      孤立 "ESC O" と、 (2) bash < 5.0 での孤立 "ESC O" と (3) bash < 5.0 での
      "ESC O A" である。(2) だけ区別できる様にしても意味がない。というより (1)
      と (2) は同じに取り扱って良いのだから、寧ろ (3) の場合を区別できる様にす
      る必要がある。

    e つまり「これを受け取ったら次の文字があるという事を示唆する ESC O」なる物
      をどうにか表現しなければならない。ESC を修正するか或いは O を修正するか。
      うーん。PrefixO なる文字を追加する? 或いは O を "@prefix O" みたいに
      encode してどうにかする。と思ったがそれはそれで処理が面倒そうなので取り敢
      えず PrefixO という文字を追加する方向で考える。

    上記の e の方針で実装した。@PrO という文字を追加した。

    2025-05-06 @PrO は @prefixO に改名した

    * done: M-O で esc O を送信する端末でテストを行う (その様な端末は実際に存在
      するか?) なければ自分で適当な端末をそのように設定する? 或いは何か簡単に送
      る仕組みはないだろうか。

      →これは mintty が (modifyOtherKeys を設定していなければ) ESC O を送信す
      ると分かったので term_modifyOtherKeys_internal= を設定してテストしたちゃ
      んと動いている。

    * [保留]: keyboard macro に記録した時、M-O は isolatedSS3 として記録する必
      要があるのではないか。macro の場合には自明に直後に文字が続いているので、
      元々 M-O として解釈された物が後の文字に勝手にくっついて up 等に化けてしま
      う事態が発生するのではないか。

      うーん。結局 IsolatedSS3 も導入する必要が出てくるかもしれない。というか、
      面倒なので、 bash >= 5.0 でも関係なく "SS3 ?" にフルに bind する? と思っ
      たができるだけ clean にしたいのでやはり bash 5.0 以降では普通に
      wait-input で処理する方法を保持したい。と思ったがマクロを考慮に入れるとや
      はり色々考える必要がある?

      然し改めて考えてみると timeout を利用した keybinding がある限りは
      keyboard macro は何れにしても振る舞いが変わってしまうのではないか。そもそ
      も bash の実装ではどうなっていたのか。もし bash の実装でちゃんと timeout
      まで再現していないのだとしたら ble.sh で無理に実装する必要もないのでは?
      と思ったが、別に ble.sh で振る舞いを改良したいという考え方もある。

      ? plain Bash はどう振る舞うのか。うーん。どうやら曖昧なキーがあるとその時
        点で keyboard macro の再生が中断してしまう様だ。また、keyboard macro の
        記録に於いて、bind '"": ""' で新しく挿入された二次的な入力も一緒に記録
        されてしまっていて、二重に挿入が行われる様になってしまう。いろいろな意
        味で plain Bash のキーボードマクロは振る舞いが微妙である。なので余り参
        考にはならない。

      もし対応するにしてもこれは M-O vs SS3 に留まる話ではなくあらゆる曖昧なキー
      に関係してくる。従って個別に対応するのではなくて全体的な枠組みとして処理
      する必要があるのではないか。今回は保留という事にして、別項目を残しておく
      事にする。

    * 対策を bash <= 4.4 で一律にしているがこれは本当に bash <= 4.4 全部で起こ
      る問題なのか? → 実際に試してみたら bash-3.2 では問題は発生しない様だ。つ
      まり、これは 4.0 <= bash < 5.0 で起こる問題である。

    * コードの再配置を忘れていた。DF を DE に変更する。7FC 7FB を 7BC 7BB に変
      更する。2044 を 1980 に変更する。

  * decode: keylog/charlog で接頭辞部分一致で再解析された文字を記録しない [#D2332]
    Ref #D2333

    これは #D2333 の修正の途中で行った変更の内、独立した部分を切り出した物である。

    [まとめ] ble-decode-char で途中まで一致していたが失敗した時に、最長一致の分
    だけ処理してそれ以外を再度解析している。この時 ble/debug/keylog 及び
    ble/decode/charlog に再解析した分だけ重複して記録されてしまう。これはデバグ
    する上で好ましくない。実際に一致した時など処理が決まった段階で
    charlog/keylog に登録する様に変更する事にした。

    * ble-decode-char の二回目の呼び出しで受信したのは 79 単体の筈なのに、それ
      に対するループが二回実行されている。これは何故だろう。例えば ichar の変数
      リークで内容が書き換わっている? と思ったが reach が登録されていてそれが失
      敗する事で残りの処理が改めて実行されるという形になっている?  でも不思議だ。
      試してみると正常に動いている場合にはそもそも reach に入っていない。何が起
      こっているのだろう。

    * 未処理の部分として改めて O が処理されてしまうのは問題である。先ずは少なく
      とも "M-O O A" ではなく "M-O A" として処理される様に修正する必要がある。
      どうも reach key に登録されている内容を見ると "C-[ O A" に分解されている
      様な気がする。しかし、なぜそれが "M-O O A" に変換されてしまうのだろうか。
      send-unmodified-key が何か変換をしているという事だろうか。

      と思って改めて keylog の結果を見てみたら別に M-O の後に再び O が来ている
      訳ではなかった。単に M-O が処理できなくてそれが ESC O に分解されて再処理
      されているだけだった。O が重複して処理されている訳ではなかったのである。

      つまり改めて O についてループが回るのは期待通りの動作である。寧ろ、失敗し
      た時に改めて keylog に登録されてしまうのが変といえば変なのである。

    x fixed: それでもキーボードマクロ記録用の _ble_decode_keylog_chars_enabled
      での記録は実際に問題がある気がする。なので、debug/keylog と共にやはりちゃ
      んとキーが重複しない様に修正する必要がある。

      a reject: ループを回す前に最初に処理をすると処理している途中に新しい文字
        が挿入された場合などに問題がある。なので実際に consume する時に記録する
        必要がある。

        更に記録するか記録しないかの状態が途中で変わった時に、これだと遡って
        off にする事ができない。もしくは遡って追加済の文字を登録する事ができな
        い。

      b reject: 或いはループの中で登録する位置を変える。処理する直前に keylog
        に登録するという手もある? 然し、それだと複数のキーが保留状態になってそ
        れから再処理される状況になった時に対処できない。

      c reject: 或いは reach を使って遡るという事が分かった時点で一旦 keylog に
        登録した文字を全て削除する? でもこれは keylog に対する内部実装に依存す
        る様になってしまう。或いは、末尾から削除するための keylog のインターフェ
        イスを追加するという手もあるかもしれないが、ただこの実装の為だけにその
        ようなインターフェイスを追加する必要があるのかという疑問が残る。

      d という事は keylog の為に一旦未 consume の chars を記録しておく配列また
        は変数が必要になる。

      結局 d の方法で、新しい配列を追加する事にした。

    2025-05-03 キーボードマクロが全く動かなくなっている。と思ったら単に変数リー
    クだった。修正した。

  * util: iTerm2 がまた DA2 を変更している [#D2331]
    https://github.com/akinomyoga/ble.sh/issues/580

    恐らく以下のコードで変更が入ったのだと思われる。

    https://github.com/gnachman/iTerm2/commit/cd9445d59c667cbae57987f1de0100e0a031d666

    emulation level を新しく実装してその過程で今まで vt400 までだったのを vt500
    まで対応する様になり、デフォルトを vt500 に変更した様だ。それに従って 41 の
    代わりに 64 が使われる様になった。

    これだとユーザーが特別の値を指定した時には検出できない事になるが、そもそも
    敢えて vt level を下げる使い方をするのだとしたら vt の範囲を逸脱する機能を
    使った時の問題に対しては責任を持てないとして良いのではないか。そもそも DA2
    を偽装されたらこちらとしては何もできなくなる。

  * edit (display-shell-version): (integration: off) の様な表示もする [#D2330]
    https://github.com/akinomyoga/ble.sh/issues/580

    ble summary の時に zoxide integration off の時にそれを赤く表示するべきでは。
    と思ったが、実は単に未だ補完を試みていないだけだったら微妙? そもそも ble
    summary の zoxide の所に integration on/off の表示がない。表示を追加するべ
    き。

    と思って実装を確認したら、どうも integration がロードされている時はちゃんと
    (integration: on) が表示される様になっている。他の bash-preexec や
    fzf-completion, fzf-key-bindings でもロードされていない時には何も表示しない
    様になっているので zoxide 特有ではない。また、zoxide や bash-preexec や
    fzf-completion については必要に応じて自動的にロードされる様になっているので、
    警告色にするなどして其処までロードされていない事を強調する必要もないのでは
    ないかという気がする。一方で、fzf-key-bindings についてはロードされていない
    時には赤字で表示するべきではないか…と思ったが、ロードされていない時には、
    既に、独立した行で警告を表示する様になっているのでわざわざ (integration:
    no) の表示を赤字強調で出す必要もない。

    一方で、今回の様に zoxide integration の自動ロードしたいがスキップされて問
    題が生じている時にユーザーが気付ける様に (integration: no) みたいな表示はあっ
    て良いのではないか。但し、赤字にするなどの強調はしなくて良い。

    最終的に物凄く小さな変更になってしまったが、何も表示しないよりは良い気がす
    るのでやはりこの変更は入れる事にする。

  * memo: テストコードに文法間違いがある (reported by andychu) [#D2329]
    https://github.com/akinomyoga/ble.sh/issues/565

    これは実際には使われていないコードではあるが何れにしても。

  * util: ble/fd#list で複雑な事をしていたが単に compgen -G を使えば良い [#D2328]

    自前で glob の設定を変更したり色々する必要はなかった。

  * complete: fzf completion が内部で呼び出す補完関数についても adjust する (motivated by tessus) [#D2327]
    https://github.com/akinomyoga/ble.sh/issues/580

    fzf completion の時にはその fzf が内部で呼び出す補完関数についてもチェック
    するべきなのではないか。或いは、補完関数に指定されていなくても関数が定義さ
    れていれば積極的にチェックするべき? と思ったが、候補の関数名について全て
    declare -F でチェックするのは overhead が気になる。やはり fzf の時にだけ特
    別扱いするべき?

    或いはもう一つの方法は integration/zoxide を明示的に呼び出してもらう様に指
    示する。

    或いは fzf の関数自体に介入して他の補完関数を呼び出す直前に介入を行う。
    その為には core-complete の調整する部分だけ分離する必要がある。

    * 丁度 fzf は __fzf_orig_completion_get_orig_func という関数に分離されてい
      るので其処に介入すれば良さそう。

    * それより前の fzf の version ではどの様にするべきか。或いは対応を諦めるべ
      きだろうか。実装を確認した。これについても対処する事にする。取り敢えず既
      に補完設定が読み出されている場合については _fzf_handle_dynamic_completion
      に対して介入を行えば良い。

      未だ読み取っていない場合については bash-completion の _completion_loader
      を呼び出している。(最新版では $_fzf_completion_loader を呼び出しているが、
      最新版では何れにしても __fzf_orig_completion_get_orig_func に対する
      advice で対処できているので気にしなくて良い。また、結局何れも
      bash-completion の loader を最終的には呼び出す様になっているので
      bash-completion の側の対処だけで良い。) これらは bash-completion の側で対
      処するべき。

    * bash-completion の __load_completion 及び _comp_load に対しても同様に介入
      するべき。以前にもそんな事を考えた様な気がするが今
      contrib/integration/bash-completion を確認してみても別にそれらに対しての
      介入はされていない様だ。

      遡ってみるとこれは 2025-02-20 の項目で、未だ対処されていない。というか、
      2025-02-20 の問題は _command_offset 経由の時の問題で、その対処方法として
      _comp_load / __load_completion に介入する事を対処方法の一つとして考えたが、
      既にある補完定義に関してはそれでは対処できないことから断念したのだった。
      2025-02-20 の問題は別に修正する必要がある。

      取り敢えず実装はした。然し、本当に動作するのかどうかについては未だテスト
      していない。取り敢えず parse までうまく行っていることだけ確かめれば十分だ
      ろう。

      何だか呼び出されたり呼び出されなかったりで一定しない。不思議だ。取り敢え
      ずまた試しにテストし直してみたらちゃんとロードされている気がする。sudo 経
      由の時にも、sudo から呼び出されたコマンドについてちゃんと
      adjust-third-party-completion が呼び出されている。取り敢えず OK という事
      にする。

    * skim の方はどうするか。skim の持っている version では
      _skim_handle_dynamic_completion に介入するか或いは
      __skim_orig_completion_filter に介入をする必要がある。後で確認が必要であ
      る。

      更に新しい version を確認すると commit 7df8b777 でまるっきり内容が書き換
      わっている。というか、元々あった shell integration のコードは全てなくなっ
      て代わりに skim 自身の補完関数だけ定義する様になっている。integration
      code は何処か別の所に移動したのだろうか。対応する PR は
      https://github.com/skim-rs/skim/pull/586 で clap に切り替えるということし
      か述べられていない。何も考えずに勘違いで削除した? そもそも切り替えるにし
      ても機能が異なるので置き換えるのは変だ。

      README の completion.{shell} の説明の場所には単に sk の補完設定を提供する
      としか書かれていないと思ったらこの記述はたった 5 日前に追加された物の様で
      ある。元の issue を調べると https://github.com/skim-rs/skim/issues/726 で
      ある。この issue も実に最近に議論が進んでいる。

      と思ったら実は commit f87ff674 で completion.bash の中身は復元されている
      様だ。しかし、元の completion.bash ではなく、key-bindings.bash の方に復元
      されている。うーん。例えば completion.bash は clap が自動生成した物をその
      まま保存しているだけだから其処は編集できないなどの理由があるのだろうか。

      何れにしても skim-completion.bash と skim-key-bindings.bash の両方で調整
      を実行すれば良いのではないか。

      また再度追加されたコードについては新しい fzf のものを元に新たに作ったので
      はなくて、以前の version のものがそのまま追加されただけである。なので、今
      のところは skim に関しては新しい介入ではなくて古い介入だけを追加する事に
      なる。

      取り敢えず skim-{completion,key-bindings}.bash の両方に対処コードを書いて、
      また顛末についてコメントで説明を書いた。

  * 2025-01-21 global: LC_COLLATE=C を設定せずに正規表現で [ -?] 等を使っている箇所がある [#D2326]

    grc '\[ -\?\]' で検索すると LC_COLLATE=C を設定せずに判定している箇所が沢山
    出てくる。これらは大丈夫だろうか? 駄目の気がする。

2025-03-21

  * 2025-02-20 c2w 等の二分探索の高速化 [#D2325]

    c2w 等で二分探索しているのは実は bash indexed array の検索で高速化できたり
    するのでは? でも内部的には線形探索になるだろうから benchmark は必要だろう。

    →実際に musl のテーブル (552 要素) の探索を一発のパラメータ展開で拾える様
    にしてみたが、自前の二分探索の方が高速の様だ。なので今までの実装のままで良
    い。一般に ${a[*]:x:1} は例え抽出要素数が 1 個だったとしても遅いという事だ
    ろうか。或いは単に sparse だと内部の線形探索が遅いという事なのだろうか。うー
    ん、bash の内部実装的に sparse だとかどうだとかは関係ない気がする。やはり単
    に遅いということだろう。

    二分探索の while を再帰算術式に変えた方が速度が向上する。51us -> 45us とい
    う微妙な向上だが折角分かったことなので実装に適用する事にする。

    2025-03-21 bash <= 4.1 以下で無限再帰になってクラッシュするという事が分かっ
    てしまった。bash <= 4.1 では遅延評価になっていないのだった。workaround とし
    て再帰変数を配列要素として参照して、添字に条件を指定することにした。

  * decode (ble-bind): initialize specified keymaps (motivated by quantumfrost) [#D2324]
    https://github.com/akinomyoga/ble.sh/issues/561

    明示的に keymap を指定して print が実行された場合にはその場で keymap を初期
    化してしまう事にする。decode.sh が初期化しきっていない時に keymap の初期化
    をしても大丈夫かという懸念はあるが、内部的には初期化時に ble-bind を print
    の目的で使用する事はないはずだし、もし仮に呼び出されたとしても define 関数
    が定義されていない keymap についてはスキップする様になっているので副作用も
    ないだろう。実際にユーザーが呼び出すのは少なくとも .blerc より後であろう。

    ユーザーがコマンドラインから呼び出す場合にはこれで十分だろう。

    一方で .blerc の中からは core-complete の中で定義されている諸々の keymap は
    見えないのではないかという気がするが、まあ、それは仕方がない。モジュールの
    中で初期化される予定の keymap までここで強制的に (モジュールをロードして)
    初期化する妥当性もない。モジュールは自由に後付で追加できるはずの物だから。

2025-02-26

  * histdb: 現在ディレクトリ消滅時 no such column ... None [#D2323]

    他のセッションでディレクトリを削除するなどして、現在ディレクトリが存在しな
    くなった時に no such column None というエラーが発生する。データを挿入する際
    に git 情報を登録する二つ前の column に None が指定されている。その直前に
    getcwd でエラーが発生したという状態になる。これは何だろう? どうやら inode
    が None になっているのがいけない様だ。inode column は INTEGER で宣言されて
    いる。INTEGER の場合は None にできないという事だろうか。

    調べたら None じゃなくて NULL っぽい。修正した。

2025-02-09

  * main (ble-attach): workaround for Ghostty が動かなくなった (reported by odili) [#D2322]
    https://github.com/akinomyoga/ble.sh/issues/557

    upstream で変数名を変えた様だ。修正する必要がある。一々動作確認するのも面倒
    である。shell integration script を見る限りは、新しい変数名に対応しておけば
    大丈夫だろうという気がする。

  * progcomp: dnf completion の workaround が動かなくなっている (reported by msr8) [#D2321]
    https://github.com/akinomyoga/ble.sh/issues/555

    どうやら dnf の補完設定の実装が切り替わった様だ。また、bash-completion に依
    存した実装になっていたので、contrib/integration/bash-completion の中に実装
    する事にした。dnf の新しい補完は dnf 自体を呼び出す事によって補完候補を生成
    する仕組みになった様なので、この dnf の呼び出しを差し替えれば良い。dnf は直
    接に呼び出しているので "$1" を一時的に上書きすれば良い。同様の処理を既に
    _make, _comp_cmd_make で行っていたのでその .advice を流用する形に変更した。

    実際に試してみると、dnf の補完は単に dnf 自身を呼び出すだけでなく、補完候補
    に説明を添える機能まで付けた様だ。仕方がないので cobraV2 の workaround と同
    様に説明と候補を抽出分離して、ble/complete/cand/yield word "$cand" "$desc"
    を使って流し込む事にした。

2025-01-30

  * 2024-12-23 vi_cmap: :marks の対応。ないと marks のデバグの時に不便 [#D2320]

    * done: ble/string#escape-for-display 等も調整が必要ではないか? Unicode 制
      御文字の対応はどうなっている? これは新しく用意した
      ble/unicode/GraphemeCluster/ControlRepresentation を用いて処理することに
      した。

    * fixed: c2w-edit 及び c2s-edit は未だ判定していない Unicode 制御文字は素通
      りしてしまう。これは問題ではないのか? → 原理的には c2w-edit 及び
      c2s-edit を使用している段階では既に Unicode 制御文字の処理を行っていると
      いう前提? だとすると実は c2s-edit を現在の様に外部から呼び出すのは本当は
      駄目なのでは?

      現在 c2w-edit を使っている箇所は 3 つある。何れも既に処理済みの文字列に対
      する処理と分かっているのだろうか?

      * self-insert については overwrite mode で削除する文字数を決定するのに使っ
        ている。これは、未だ判定していない Unicode 制御文字が来る可能性があるが、
        ずれていたとしても其処まで大した問題にはならないだろうという気がする。

      * .delete-backward-char に関しては、既に登録されている文字に対しての判定
        なので、(rendering 後であれば) Unicode 制御文字として登録されている筈で、
        問題は発生しない筈。

      何れにしても c2w-edit は頻繁に使用されているという訳でもないので、Unicode
      制御文字としての判定を追加しても良いのでは? 少なくとも s2c 等の処理よりは
      軽い様な気がするので其処まで気にしなくて良いのではないかという気がする。

    ? ok: そもそも c2w-edit や c2s-edit は LANG=C の時には全ての unicode 文字に
      ついて ASCII 表現を使用するべきなのではないか? と思ったが、よく考えたら
      LC_CTYPE が unicode でない時にはそもそも code として Unicode 範囲の物が現
      れる事もないので気にしなくて良い? 既存の取り扱いだと self-insert の時点で
      本当に ASCII の文字列に変換されてしまうという物だった様な気がする。なので、
      code として Unicode 範囲の物を受け取ったら常に Unicode が使える前提として
      処理してしまって問題ない?

      これは将来的に "表示に用いる文字コードだけ変更する機能" が必要になった時
      に考えれば良い。

    * global marks と local marks の両方を表示する様にするべき? うーん。と思っ
      たが global marks は全然登録されていない。後で global marks を定義する方
      法について確認して、global marks を定義した上で動作確認する。global marks
      は mA などとすれば作る事ができる → 動作確認した。動いている気がする。

    * 記録されている行頭位置をそのまま表示しているが、行頭位置は行頭の ind なの
      ではないか。これを行番号に変換するべきでは → その様に変換してから表示す
      る様に修正した。

    2025-01-28 動作確認する。うーん。特殊文字の反転がそのままになっている。
    toggle をちゃんと指定しているのに。確認してみると c2s-edit の結果が単に
    sgr1 だけになっている。何故? → これは複数の呼び出しで ret を上書きしていた。
    ちゃんと ret の結果を保持する様にして修正した。

  * keymap.vi: command mode を使った後 marks が消滅する問題 [#D2319]

    #D2320 の :marks のテストをするに当たって、そもそも全然 `[ や `] が登録され
    ていない。

    ? yes: 本当に local marks は制御文字に割り当てられているのだろうか? 実は数
      字だったり或いは普通の文字だったりしないのか。これについては後で確認が必
      要である。そもそも通常の vim ではそのような物は表示されていない様な気がす
      る。通常の数字に割り当てられているのがこれに対応するのか?

    何処か別の所に登録されているのかとも思ったが、そうでもない。と思ったら、ど
    うも :ex モードに入っている間は別の _ble_keymap_vi_mark_local に置き換わっ
    ている? と思ったが、:ex コマンドの実行は元の command line に戻ってから呼び
    出している様に見える。何が起こっているのだろうか。どの様に
    _ble_keymap_vi_mark_local が管理されているのかを確認する必要があ
    る。_ble_syntax_bash を確認すると bash になっているのでちゃんと復元後の状態
    になっている気がする。

    もしかして配列としてではなく scalar として復元されている? しかし、各変数に
    ついて配列かスカラーかを判定して保存・復元している筈。

    うーん。分かった。復元前後を見てみると実は要素の数は同じで index が変化して
    いる。つまり sparse array の保存・復元にはちゃんと対応していないという事。
    これは個別に修正する必要があるのではないか。


    これは edit.sh の _ble_edit_undo_history の保存復元でも問題になるだろう。ど
    の様に対処するべきだろうか。その他の保存・復元している変数も同様に確認が必
    要だろう。

    a. VARNAME の他に SPARSE を用意して其処に記録された変数については別の関数を
      用いて save/restore する。しかし、使い勝手が悪いし今後も似たようなミスを
      してしまう可能性がある。

    b. save/restore の側で sparse array にも対応する? 全ての配列について index
      毎に保存を行う? しかしそれはとても遅いのではないか。

    c. 或いは、sparse なものだけ index 毎に保存を行う様にできるか。その為には配
      列が sparse であるかそうでないかを判定する方法が必要になる。例えば
      "${a[@]:${#a[@]}}" で有限個の要素が発生すれば、それは sparse という事にな
      る。しかし、これだと実際に要素の列を生成する事になる。${a[*]:${#a[@]}} と
      しても結局文字列を生成する事は変わらない。より高速な方法はないだろうか。

      例えば最大の index を高速に取得する方法があればそれと ${#a[@]}-1 を比較す
      れば良い事になるが…。最大の index を取得する為には結局 ${!a[@]} で一旦全
      ての index を列挙してその後で一番最後の要素を取得する必要がある。それなら
      ば最初から ${a[@]:${#a[@]}:1} 等を実行しておいた方が良い。うーん。これで
      判定する事にする。あと ${#a[@]} == 0 の時は特別。

      →実装した。18us で判定できるので処理時間は無視できる。50 配列判定してよ
      うやく 1ms という程度である。

    ble/util/{save,restore}-vars で sparse array に対応した。ちゃんと動いている。

2025-01-20

  * edit: info で SGR 反転が効かなくなっている。何故? [#D2318]
    Ref: #D2291

    trace ではちゃんと parse は出来ている。出力の段階で g.compose を通すと反転
    が消滅している。

    x 実装を確認してみると反転に対する処理を二重に行っている。うーん。これは
      169ed8bc のミスの気がする。169ed8bc のメモによると xor と or の内 xor を
      使うという事に決定している筈である。なのに xor と or の処理を二重に行って
      いる。これによって二回適用されて反転が消滅しているという事だろう。

      うーん。これは個別の修正として適用する事にする。と思ったが既に #D2297 な
      ど関連修正が別項目で行われているのでこれも別項目で処理する事にした。

      と思ったが実際に変更を適用してみると色々動かなくなった。色が全然適用され
      ない。何故? と思って改めて見てみたが、実は元のコードでやはり正しかったの
      である。という事は他に問題があるという事になる。

    改めて動作を調べてみると、g#append で属性を追加する時点で既に reverse 属性
    がついている。これによって対消滅が起こっている。これは何処から来るのかと思っ
    たら、代入対象の変数 g に元々入っていた古い値がそのまま見えている。然し、最
    初に古い値は上書きしてきている筈、と思っていたら (($1=($2))) に於いて $2 が
    空の時にエラーになって何も行っていなかった様だ。これによって $1 に含まれる
    古い値が残り、結果として反転が対消滅していたという事。

2025-01-16

  * vi_nmap: "bind -x" 実行後のカーソルの位置 (requested by miltieIV2) [#D2317]
    https://github.com/akinomyoga/ble.sh/issues/547

    bash ではカーソルを行末などに置いても勝手に調整を行う。

    vi_nmap における complete の時には一体どうしていたか。d7ec488a を見ると特に
    core-complete.sh の側では vi_nmap に対する特別の処理は実装していない様に見
    える。menu_complete に入った後で行末で menu_complete を抜けた後のカーソル位
    置を何処で調節しているのかが分からない。

    * 実際に挿入が起こった時には ble/keymap:vi/complete/insert.hook 経由で調整
      しているのかと思ったが、よく見ると別にカーソル位置の調整はここでは行って
      いない様に見える。

    * と思ったが、実は core-complete.sh の側でちゃんと vi_nmap に対する特別の処
      理を含めている。c106239a で実はその処理が既に追加されていたのだった。

    本当は edit.sh の中に特定の keymap に対する特別処理を余り追加したくないが、
    その為には色々と hook を定義しなければならず微妙である。例えば "bind -x の
    処理が終了した時に呼び出される hook" という物をわざわざ実装する必要があるか
    という話になる。

    因みに現在 edit.sh の中で明示的に vi_nmap を参照している箇所はどれぐらいあ
    るだろうか。結構たくさんある。filter-word.impl, undo,
    {start,end,print}-keyboard-macro, history-search, nsearch, ... うーん。もう
    実装の分離は諦めて良い気がする。

    次に直接 needs-eol-fix を呼び出すべきか、adjust-command-mode を一括で呼び出
    すべきか。adjust-command-mode の処理の中には C-o に対する処理も含まれている。
    つまり、単にカーソル位置を調節するだけでは不十分という事ではないだろうか。

    ? 一方で、vi_nmap の中で C-o に抗う様な物を実装する可能性はあるだろうか。普
      通に考えたら C-o の vi_nmap の中で何か実行してそれに抗うというのは考えに
      くい。と思ったが、例えば引数を追加するコマンドを bind -x の中で実行した場
      合には、引数をそのままにして抜けてしまったら問題になる。うーん。そもそも
      vi_nmap の中の全ての widget が最後に adjust-command-mode を実行するわけで
      はないのだ。

      やはり下手な調整は実行せずにカーソル位置の調整だけに留めるべきなのだろう
      か。

      * 然し現在の実装では実のところ clear-arg をコマンド実行後に呼び出している
        のでそもそも bind -x の中で引数を追加する等のことは想定していない。その
        様な事をしたいのであれば、ble.sh 専用の widget を使うべきという事。そも
        そも Bash では (ble.sh の widget を呼び出して) 引数を調整することはでき
        ないので Bash の bind -x 経由でそれを実行しようとするべきではない。Bash
        でも ble.sh でも動く兼用の設定にしたいとしても、ble.sh では引数を設定し
        て Bash ではそれをしないという様な機能というのも考えにくい。

      という事なので、bind -x の中で引数を設定するだけとか register を設定する
      だけとかそういう物を実装することは想定しないとして、無条件に
      adjust-command-mode を呼び出すという形で良い事にする。

    ? 或いは、C-o に突入する様な機能を実装した時にそれが即座にキャンセルされる
      様な振る舞いになって不都合ではないか。然し、C-o を自前で実装するという事
      があるだろうか…。と思ったが、bind -x の関数の中で ble.sh の widget を順
      番に呼び出して処理をするという可能性もある。という事を考えると C-o に突入
      した直後はそのままという可能性もある。うーん。

      もう一つの可能性は vi_nmap で始まって vi_nmap で終わったら
      adjust-command-mode を呼び出すという事。それ以外の場合には何もしないかカー
      ソル位置の調整だけ行うという可能性。うーん。取り敢えずこれで実装してみた。

2025-01-07

  * integration/zoxide: compopt -o noquote は余分 (reported by tessus) [#D2316]
    https://github.com/akinomyoga/ble.sh/issues/549

    うーん。integration/zoxide.bash で明示的に compopt -o noquote を指定してい
    るのが悪かった。元々何処からこの compopt -o noquote が来たのかと思ったが、
    最初の commit から存在している様だ。そして、どうもこれは
    fzf-completion.bash を zoxide 用に修正した時に、fzf 用の設定をそのまま持っ
    てきたという事の様である。

    そもそも fzf で compopt -o noquote を指定していたのは fzf によって履歴項目
    が補完された時には余分の quote は不要だと判断したからであった。然し、zoxide
    は単にディレクトリ名を指定するだけのコマンドなので compopt -o noquote を指
    定する必要性もない様に思われる。

    更に、fzf に関しては以下の報告によって compopt -o noquote は使用しない形に
    改められた。つまり、その修正の漏れとも言える。

    https://github.com/akinomyoga/ble.sh/issues/250
    https://github.com/akinomyoga/ble.sh/commit/0c6291f0c1609b6159013e6ba4aeae3acb35db14
    https://github.com/akinomyoga/blesh-contrib/commit/e102241466dfda8cf3e7efb6891e223102e0b2a9

    何れにしても単に compopt -o noquote を削除すれば良いだけの話に思われる。

2025-01-05

  * main: 特定の環境で ble-attach の実行を延期する [#D2315]
    https://github.com/akinomyoga/ble.sh/issues/543
    https://github.com/akinomyoga/ble.sh/discussions/524#discussioncomment-11656742

    ghostty も kitty を真似して ENV 経由で初期化して .bashrc をスキップし、手動
    で .bashrc を読み込もうとしている。その後で PS1 を修正している。これによっ
    て問題が発生しているのである。これはマニュアルにある通りに設定していないか
    ら悪いのだと書いたが issue を閉じてくれない。というか説明したのにバグだとか
    主張している。

    実は既に nix shell では ble-attach を延期して prompt-attach に切り替える様
    にしている。なので、ghostty についてもその様に変更する事にする。kitty も同
    様に修正する。更に VS Code terminal でも同様の事をしている為に問題が起こっ
    ていた。これについても修正する。

    ? 或いはトップレベルのファイルで ble-attach しているかどうかをチェックして
      そうでなかったら警告を発生する様にする? 然し、既に関数内部やファイル内部
      から呼び出すように設定している人も多いし、そもそも問題が起こらないように
      ちゃんとしている人もいる。という事を考えると、単にそれで警告を出力するよ
      うに変更するのも気が引ける。

      もしその様にするのであれば最初から警告を出力する様にするべきだった。今に
      なって変更する事はできない。

  * edit (TMOUT): (reported by Anyborr, georglauterbach) [#D2314]
    https://github.com/akinomyoga/ble.sh/issues/424#issuecomment-2016531757
    https://github.com/akinomyoga/ble.sh/issues/548

    "bash: ble/util/idle.clock: No such file or directory" というエラーが出ると
    いう話。これは以前にも報告されていた。今回の別の症状として端末を放置してい
    るといつの間にかに閉じているという物があったので TMOUT が設定されているので
    はないかと思ったら、実際にそうだった。そして、TMOUT を設定すると
    ble/util/idle.clock のエラーも再現するという事が分かった。

    結局 ble/util/idle.sleep が TMOUT の初期化コードから呼び出されているという
    事が分かった。以前調べた時にこれを特定できなかったのは、ble/util/idle#sleep
    という自動生成された関数を通して呼び出されていたからだった。

2024-12-31

  * main: 初期化時刻の表示 (motivated by tessus, Darukutsu) [#D2313]
    https://github.com/akinomyoga/ble.sh/issues/340
    https://forum.atuin.sh/t/atuin-bash-and-ble-sh/175/26?u=akinomyoga

    議論に上る度に修正して自分で計算してまた元に戻すのは面倒なので、parse,
    load, attach, prompt, bind の一連の処理の時間も全て計測して表示する事にした。
    idle についてはユーザーが勘違いしそうなので積極的には表示しない。必要であれ
    ば自分で書き換えて表示して使う事にする。

  * global: ble/util/assign をもっと広く使う [#D2312]

    初期化の段階で $() を使っていた箇所があるが、もっと早く ble/util/assign の
    一時実装を用意して良い筈である。特に bash-5.3 では ${ ...; } を単純に使えば
    良いので最初に定義するのが効率的である。

    そもそも builtin eval -- "$(...)" だって今後は builtin eval -- "${ ...; }"
    に置き換えることができる筈。

2024-12-30

  * decode (bind): print the filename and line in error messages (motivated by excited-bore) [#D2311]
    https://github.com/akinomyoga/ble.sh/issues/534

    bind のエラーメッセージで問題のあった keyseq をエラーメッセージに含める。ま
    た、その呼出に対応するファイル名と行番号もエラーメッセージの中に含める事に
    する。これで少なくともユーザーはそのファイルを確認することができるだろう。

  * util: ble/path#remove-glob で * を指定すると後ろまで全て削除してしまう [#D2310]

    これはとんでもない振る舞いである。元々は恐らく * を使うつもりはなかったが、
    実際のところ例えば WSL2 で /mnt を除外する為に remove-glob PATH '/mnt/*' 等
    を指定するので考慮に入れる必要がある。これは修正するべき。

  * global: avoid raw word splitting [#D2309]

    未だ $bytes 等の様に quote されていない箇所があって気になるので、
    "ble/string#split-words" や "ble/util/assign-words" を使う様に修正する。

  * progcomp: fix a bug that "x" at the end of the last completion is trimmed [#D2308]

    l ~/.opt/tilix を補完しようとすると何故か "~/.opt/tili " になってしまう。色々
    試すと progcomp でファイル名を補完した時に発生する様である。builtin の補完
    生成では発生しない。また、"touch fixfixfix" 等で作った "x" で終わるファイル
    名に対しても発生するという事が分かった。"touch fixfixfix1" 等 "x" 以外で終
    わるファイル名に対しては問題は発生しいない。

    問題は ble/complete/progcomp/.filter-and-split-compgen で発生している様だ。
    この中で x が消滅している。最近修正した mawk bug に対する workaround が問題
    かもしれないと思ったが、その処理よりも前の時点で既に x が失われている様だ。
    と思ったら out=${out%x} として明示的に "x" を消去している場所がある。これは
    その直前に ${out%nlfix} というダミー文字列消去の処理があるので、それの一時
    的な実装の時のコードが残留していたという事の気がする。単純に対象の行を消す
    事にした。

    これは 5.3 compgen -V 対応によって追加されたコードなので殆どのユーザーに対
    しては影響がない物である。

2024-12-24

  * vi_[in]map: rlfunc "paste-from-clipboard" の対応 [#D2307]

    vi_imap は paste-from-clipboard で良さそうな気がする。一方で、vi_nmap に関
    しては特別な配慮が必要になる。面倒なので p を呼び出す様にすれば良い気がする。

    今まで Cygwin 上でしか paste-from-clipboard を友好にしていなかったが、
    rlfunc.txt にあるのに使えないというのも混乱の元なので全ての環境で widget は
    定義する事にした。また、clipboard から抽出する様々の方法を追加する事にした。

2024-12-23

  * 2022-04-13 bash が `vi-edit-and-execute-command' を追加している [#D2306]

    これは自分が以下で報告した事が元になっているのだろう。
    https://lists.gnu.org/archive/html/help-bash/2022-02/msg00031.html

    d70b5339 で追加されている。つまり help-bash で発言した次の日には修正が入っ
    ていたのだった。

    2024-12-23 これはエディタを指定して実行する物。新しく追加する事にした。

    2025-01-20 edit: edit-and-execute-command が動かなくなっていると思ったら
    c395eb33 で壊していた。修正する。

  * edit: bash-5.3 "bash-vi-complete" を実装 [#D2305]

    bash-vi-complete は vi-complete に似た readline bindable function の様だが
    そもそも vi-complete が実装されていない。

    ? vi-complete と complete の違いは何か? これは Bash の実装を確認する必要が
      ある → 実はこれは結構振る舞いが異なるのでは。key によって振る舞いを切り
      替える様になっている。更に bash-vi-complete という物もあって、その違いは
      よく分からない。

    * bash-vi-complete は何なのか説明を探そうとしたが見つからない。そもそも
      readline に備わっている昨日なので man readline には見つからない。一方で、
      devel の man bash の方にも載っていない。ソースコードを見て振る舞いを調べ
      るしかないのか? 一応 bashline.c (bash_vi_complete) の最初にコメントで何か
      書かれているが結局よく分からない。rl_vi_complete との違いは bash の glob
      を使うという事? 或いは、途中の文字列も glob pattern として展開してしまう
      という事?

    取り合えず Bash における両実装を確認する。vi-complete と bash-vi-complete
    は両者とも最初にカーソル位置を修正している。前方が空白でない場合にカーソル
    位置を一つ進めている。

    ? done: うーん。これについては vi_nmap/complete も同様に実装するべき?

      と思ったが、まあ、敢えて vi-complete ではなく complete を選んだ場合には
      やはり vi として consistent な振る舞いということで現在の振る舞いを保持
      する? 勝手にユーザーにとって non-trivial な振る舞いをするのも考え物であ
      る…

      が空白の位置にカーソルが置かれている場合には文字を一つ進めて補完を試み
      るのも変な感じがするのでやはり既定で文字を進めない様にする?


    構造としては類似だが vi-complete と bash-vi-complete では実際に実行する操作
    が全く異なる? よく分からないので先ずは vi-complete について確認する事にする。
    vi-complete では次に key に応じて振る舞いを分けている。`*` -> `*`, `=` ->
    `?`, `\\` -> TAB に変換して rl_internal_complete に渡している。具体的な振る
    舞いについては rl_internal_complete のコメントに書かれている。

    > `*' means insert all of the possible completions.
    > `?' means list the possible completions.
    > TAB means do standard completion.

    うーん。つまり…  `\\` を指定した場合には既存の補完を削除して改めて最初から
    補完を実行するという事? ble/complete/menu/clear を呼び出してから実行すると
    いう事だろうか。

    更に、'*' と '\\' の場合には挿入モードに移行している。どういう事だろうか?

    ? これが POSIX の要求という事なのだろうか? 然し XCU を見ても set -o vi で
      vi editor になるという事が書かれているだけで TAB がどう振る舞うべきか等に
      ついては何も記述されていない気がする? そもそも XCU では補完の話はしていな
      い。completion で色々記述があるが何れも "コマンド実行完了" や "文法として
      のコマンド終わり" を意味している様だ。一方で XCU vi の方を見ても何処にも
      補完の話は書かれていない。<tab> の振る舞いの説明についても書かれていない
      (insert mode で生の tab を入力すること以外は)。<control>-I についての記述
      もない。うーん。謎だ。

    具体的に振る舞いを確認してみても、'*' と '\\' の時にだけ insert-mode に移行
    して、'?' の時などには insert-mode に移行しないようだ。これは変だ。或いは、
    これは話が逆で '?' の時だけ insert-mode に移行しないという事で、その他の場
    合には予期しない呼び出しだから適当に処理しているという事だろうか。

    さて、次に bash-vi-complete の実装を確認する。うーん。これは結局既存の
    widget たちを呼び出している様な気がする。という事は、ble.sh 側の実装でも単
    に opts に context=glob を追加して呼び出せば良い様な気がする。

    bash-vi-complete では他に bigWord に対する処理という物が加わっている。うー
    ん。どうやら現在の単語を抽出して、現在の単語に glob 文字が含まれていなけれ
    ば glob pattern の末尾に * を追加している様だ。うーん。面倒だ。

    ? そもそも現在の実装の context=glob はどの様に振る舞っていたか。先ず展開を
      試みている。それで何も生成されなければ * を追加して再展開を実行している。

      これは bash-vi-complete の動作と同じになるだろうか? うーんならない気がす
      る。例えば glob 文字を含まない場合を考える。この場合は、bash-vi-complete
      だとそれから始まるファイルが全て生成されるが、ble.sh の context=glob では
      完全一致するファイルが存在する時ただ一個の候補が生成されてそれに確定する。
      glob 文字を含む場合には bash-vi-complete だと一致するファイルが存在しない
      時に何もしない事になるが、ble.sh の context=glob では末尾に * をつけて再
      展開を行うのでファイルが生成される場合がある。

      そもそも bash の M-g はどの様に振る舞うのかと調べてみたが glob 文字が含ま
      れていても問答無用で末尾に * をつけて生成している気がする。従って候補が生
      成されなかった時にだけ * を末尾につけて再展開するというのは ble.sh による
      拡張である。

      ? bash の M-g の振る舞いは何処で実装されているのか。もしこれが編集関数に
        よって実装されているのだとしたら bash-vi-complete で * を末尾に付加して
        いるのは果たして必要な物なのだろうか?

        うーん。調べてみると bash は emacs mode でかつ M-g の時だけ * を末尾に
        付加する様である。M-* や C-x* など他の場合には * を末尾には付加しない。
        不思議な仕様だし余り consistent とは言えない。

      うーん。bash の実装が何か変な気がするので、この * が付加される条件は勝手
      に単純化する事にする。

  * edit: more widgets in vi_nmap (requested by excited-bore) [#D2304]
    https://github.com/akinomyoga/ble.sh/issues/534

    先ず最近追加された readline bindable function に対する対応を行う事にする。
    但し spell-correct-word に関しては面倒なので後回しにする。

    [complete]

    menu-complete, menu-complete-backward: これは complete と一緒に対応する必要
    がある。

    * カーソル位置をどの様に処理するのかが微妙だと思ったが、p や insert mode か
      ら戻った時のカーソル移動やその行の最後の文字の右にカーソルをおけない事な
      どを考えると、現在位置の右にある文字も既に入力された文字列の一部として取
      り扱うのが自然である。

    * done: vi_imap/complete が存在しているが rlfunc では使われていない。何故?
      うーん。単に書き換えるのを忘れていただけという事の気がする。これは全て
      vi_imap/complete を使う様に修正した。

      * todo: 或いは menu-complete に入る物に関しては特別に処理する必要がなかっ
        たという可能性もある? そうだとしても分かりにくいので vi_imap/complete
        経由で呼び出す様に修正するが、念の為、後で本当にそうなのか確認する。

    x fixed: menu-complete を vi_nmap の中でキャンセルして vi_nmap を抜けて
      menu が非表示になっても、menu が未だ active の儘になっている。これは変な
      気がする。

      vi_imap で menu-complete をキャンセルして vi_nmap に入った時にはその様な
      事は起こっていない。と思ったが vi_imap から vi_nmap に入った時にキャンセ
      ルされるというよりは menu-filter によって deactivate されていたという事の
      様に見える。うーん。update-mode-indicator で menu を deactivate するのが
      良い?

    * done: `[`] の動作確認
    * done: nmap . の動作確認
    * done: imap-repeat に対する影響は? うーん。期待される動作が何なのかもよく
      分からないが、取り敢えずは現状の振る舞いで良い様な気がする。C-o で補完を
      試みてその後で何か挿入すると、C-o で補完を試みて以降の内容が記録される。
      C-o で補完を試みてその直後に ESC で insert-mode を抜けると、C-o を押す前
      までに入力された内容が挿入される。

    * done: undo が正しく記録されて元に戻すことができるか確認

      undo はちゃんと記録されている。

    * done: menu-complete の時にも同様のテストをするべきなのではないか。

      `[ `] . の 動作確認はした。undo についても動作確認した。まあ良いだろう。

    * fixed: 但し、undo 後のカーソル位置が変かもしれない。しかし、これは今回の
      問題というよりは nmap における undo の実装の問題の気がする。vim ではどの
      ように振る舞っていただろうか。

      % うーん。どうやら vim ではカーソル位置もちゃんと覚えていて u をするとちゃ
      % んと元の位置に戻る様である。つまり、単に編集範囲の先頭もしくは末端にカー
      % ソルを配置するのではなくて、その操作をする前のカーソルの位置に戻る。例
      % えば pu と Pu の結果の違いを観察すると分かる。編集範囲を元にすると両者
      % は異なるカーソル位置になるはずだが、実際にはちゃんと最初のカーソル位置
      % になる。
      %
      % →これは勘違いである。vim は編集範囲を個別に記録していて、カーソル位置
      % は編集範囲の先頭に来る様にする様である。然し pu で元の編集位置に戻るの
      % は何故かは分からない。編集範囲を元々カーソルが居た位置を含むように設定
      % しているという事だろうか? よく分からないがこれは別項目で残す事にする。

      或いは undo_point を適切に設定すれば vim の振る舞いに合わせることができる?

      うーん。改めて vim の振る舞いを見てみると最後の位置を覚えているのではなく
      て単に編集範囲の先頭にカーソルを移動するだけの様である。→微妙に編集範囲
      の特定の振る舞いが異なるがこれは仕方がない事にする。

    [undo]

    vi-undo: これは undo と全く同じで良い。Bash のソースコードを見たら単に undo
    の関数を呼び出しているだけであった。5.2 で新しく vi-undo が追加されたのは、
    Bash の中で存在していた synonym にちゃんと一対一対応する様に名前を付与した
    という事なのだろう。或いは、一覧にリストされる様になったか。

    うーん。全く同じで良いと思ったが vi_imap に於いては imap-repeat との兼ね合
    いを考える必要がある。うーん。imap-repeat において undo をどの様に取り扱う
    べきか。

    a undo 操作自体を繰り返す? しかしそれだと意図しない振る舞いになる可能性はな
      いだろうか。

    b 或いは実際に発生した効果を模倣する?

      undo という事は必然的に実際の挙動としては、既に入力された物を削除する場合
      が考えられる。その場合にどのようにして削除するのかが問題になる。文字数を
      数えて全く同じ文字数だけ削除するのか、或いは、削除された文字列に一致する
      文字列が存在した場合にだけ削除を実施するのか。然し、前者だと全く意図しな
      い振る舞いになる可能性がある。後者の場合にも、削除する事を前提として次の
      操作を続ける可能性もあって、何も発生しないというのはそれはそれとして問題
      である。

      そもそも、直前の操作が実際に同じ文字数だけ文字列を挿入するのかも分からな
      い。例えば p の場合には予測不可能である。然し、結果がどうであれ u で p を
      実行する前の状態に戻したい。その様に考えるとやはり undo は undo 操作自体
      を実行するという事で良い気がする。

    結局 undo 操作を直接呼び出すのが妥当の様な気がする。そうすると emacs/undo
    と全く同じ実装で良さそうだ。

    * reject: emacs/undo という名前はやめて edit.sh に移動して ble/widget/undo
      という事にする? と思ったが emacs/* という名前になっているのは、それによっ
      て ble/edit/undo/add の呼び出しを抑制する目的があった。

    [backward-kill-word]

    これについては既に類似の vi-rlfunc/* という widget が沢山あるのでそれに倣っ
    て実装する事にした。特に vi-rlfunc/kill-word と殆ど同じと思って良いだろう。
    振る舞いを確認してみると特に前の単語の先頭までを削除する様なので丁度 "db"
    を呼び出すのと同様の振る舞いで良いだろう。

    * 実は他にも類似の widget は沢山ある気がする。これらも一緒に対応するのが妥
      当だろう→同様の方法で簡単に対応できる物を幾つか追加で対応した。他にも未
      だ沢山対応していない readline bindable functions はあるが、他のは何れも対
      応は大変そうである。

  * edit: "bleopt undo_point=" にしても直前のカーソル位置に戻らない [#D2303]

    現状の実装では undo_point= 最後から二番目の編集が起こった直後のカーソルの位
    置が復元されて、最後の編集が起こる直前のカーソルの位置が復元される訳ではな
    い。記録するのはその状態での最後のカーソル位置であるべきではないか?  しかし
    C-r の時には操作直後の状態を復元したい気もする。両方記録する?

    x fixed: 動作確認して気付いたが undo/redo を実行しただけで undo の履歴が書
      き換わってしまっている。これによって redo をする事ができなくなっている気
      がする。どうしてこの様な事になるのか? → 単に最終カーソル位置を更新する時
      の配列要素を間違えていた。修正した。

    x fixed: redo をしているのに編集直後の位置ではなくその編集文字列における最
      後のカーソル位置になっている。これは $1 を $2 で参照しようとしていたのが
      原因だった。修正した。

    * done: vi-undo では既定の undo_point の振る舞いを変更する可能性? 然し、
      Bash で同一実装なのだとしたら undo と vi-undo で実装を変えるのも変だ。寧
      ろ、undo の実装も一緒に手を入れるべきなのではないか。

    undo_point に新しく first,last,near,auto を追加して既定の振る舞いは auto と
    する事にした。auto の場合には emacs editing mode と vi editing mode で振る
    舞いを変更する。うーん。vi editing mode でも vi_imap は emacs と同様に振る
    舞うべきではないか…。やはり変更する事にした。vi command modes では beg の
    様に振る舞う事にして、それ以外の場合には near として振る舞う事にする。

  * vi_nmap: C-o の内部で vi_nmap/complete を呼び出すと何だかよく分からない状態になる [#D2302]

    先ず、カーソル位置がちゃんと元に戻っていない。これは C-o の特性だろうか?

    うーん。vim ではそもそも C-o を押した時にカーソルの位置が変化したりはしな
    い。行末に居る時にだけカーソルの位置が後退する様である。先ずはこの振る舞
    いを修正する必要がある気がする→修正した。

    また、vi_nmap/complete で menu_complete 等の特別な状態にならない限りは
    adjust-command-mode を呼び出す様にした。これによりちゃんと一回コマンドを実
    行した後に insert に戻る振る舞いが可能になる。

    改めて試してみたが変な事にはなっていない様なので取り敢えずは良しとすること
    にする?

    ? でも何故 menu-complete になって元に戻った時にちゃんと insert になっている
      のだろうか? vi_imap vi_nmap menu-complete の様な keymap 状態になる訳では
      ないのか? 或いは adjust-command-mode が menu-complete 終了後に実施される
      という事か? うーん。少なくとも complete/insert.hook の中では vi_imap
      vi_nmap menu_complete という状態になっている。という事はその後で vi_imap
      まで状態が pop するという事になる。試しに adjust-command-mode を調べてみ
      ると確かに呼び出されている。何処から呼び出されているのかを確認すると、

      [1]="ble/complete/menu-complete/exit"
      [2]="ble/widget/menu_complete/exit"

      となっている。うーん。これは自分で新しく追加したコードだった。つまり、こ
      れについてもちゃんと対策ができている。

2024-12-20

  * edit: C-c 後の履歴位置が変だ (reported by dezza) [#D2301]
    https://github.com/akinomyoga/ble.sh/discussions/540

    C-c を実行した後は C-m を実行した時と同様に全ての編集をクリアして、履歴位置
    は履歴の末端に移動するべきである。

  * global: rename "ret" not used as REPLY [#D2300]
    Ref #T0009

    将来的に ret -> REPLY の全置換を実施する時に変なことが起こらない為に。

  * global: 実は [:space:] は \v\f\r\n にも一致する。代わりに [:blank:] を使う [#D2299]

    一方で [:blank:] は全く使われていない。実は [:space:] になっている箇所は全
    て [:blank:] なのでは? ただし改行 \n も意図していた可能性があるのでそれにつ
    いては $_ble_term_IFS に置き換える。

    関連して _ble_term_space も _ble_term_blank に改名する。

  * main: work around macOS sed (reported by Mossop) [#D2298]
    https://github.com/akinomyoga/ble.sh/issues/538

    macOS awk と同様の問題があるようだ。バイナリデータがあると問答無用で失敗し
    何も実行しない。取り敢えず locale に C を指定して動くかどうか確認する。もし
    かすると、encoding 固定で locale を C にしても動かない可能性もあるが、もし
    そうだったらそれは macOS が悪い。

2024-12-18

  * edit: 履歴移動を行った時のカーソル位置の設定 (requested by miltieIV2) [#D2297]
    https://github.com/akinomyoga/ble.sh/issues/537

    Note: これにより history_preserve_point -> history_default_point に変更した。

    * fixed: 何と今まで "bleopt edit_line_type" が動いていなかった様だ。

    * fixed: 何と今まで bleopt/check:input_encoding のエラーメッセージの一部が
      表示されていなかった様だ。

      * ok: ble-0.3 では ble/util/print ではなく echo を使っているので問題なかっ
        た。

      * ok: 類似のものは他にはないようだ。

    * done: wiki, blerc

    x fixed: preserve にしても位置が preserve されていない

      これは何処かの時点で壊れたという事だろうか。上に遡る時には必ずカーソルは
      先頭に移動してしまう。また、下に移動する時には前のコマンドラインの末端位
      置に移動しようとする。現在のカーソル位置は全く保持していない。keymap.vi
      特有の問題ではないようだ。emacs モードでも同様の現象が起こっている。

      うーん。呼び出しの順序的に履歴移動が発生しなかった時に正しい位置にカーソ
      ルを移動してエラーメッセージも必要に応じて出力しなければならない。しかし
      現在の枠組みだと履歴移動が発生したかどうかを forward-history-line.impl の
      呼び出し元で知ることができない。

      振る舞いについて確認する forward-history-line.impl は先ず行を追跡して適切
      な履歴項目の位置を探し出している。その後で対応する行が見つかれば其処に移
      動するし、見つからなければ先頭項目か末端項目に移動して終了する。

      * 先ず ble/widget/forward-history-line.impl を呼び出したら、履歴移動が発
        生しなかったとしても、必ずカーソル位置は適切な位置に設置することにする。

    x resolved: forward-history-line etc 等との consistency はどうなっているの
      か?  複数行の時に forward-history-line も位置を調整しようとしている。履歴
      移動後にどの位置にいるのかは実は ble-edit/history/goto で管理するのではな
      くて forward-history-line 等の実装ごとに適切に処理する必要があるのではな
      いか?

      * done: ble-edit/history/goto でもカーソル位置を調整するしその呼び出し元
        でもカーソル位置を調整しているというのは無駄の処理の気がする。→これは
        ble-edit/history/goto で opts を受け取って clear-point が指定されている
        場合には、単に _ble_edit_ind=0 にする事にした。

      forward-history-line 等の行指向の履歴移動の場合には振る舞いを行指向に変更
      した物を別に実装することにした。

    * done: preserve-{,graphical,logical-}column 等も用意するべきではないか?

    * done: clear-point ではなく point=none にする。point=near 等に対応する

    * done: graphical, logical も外から指定できるようにする? graphical-linewise
      もしくは logical-linewise の形で。と思ったが、そもそも
      forward-history-line.impl の時点でどちらか分からないので、これも更に外側
      から種類を受け取る様に修正する必要がある→面倒だと思ったが結局対応した。

    [動作確認]

    x fixed: 全く動かなくなっている。と思ったら graphica/logical の決定による
      point の書き換えに失敗していた。修正した。

    その他は大体動いている様だ。

    2024-12-31 実は keymap.vi の vi motion 経由で呼び出される履歴移動は
    ble/widget/history-{prev,next} を用いていた為に、今回の新しいカーソル位置の
    設定が適用されていなかった? 取り敢えず対応した。

    ? done: と思ったが、本来は ble/widget/history-{prev,next} が正しく位置を設
      定する筈だったのでは…? 何故動いていないのだろう? 後で確認する必要がある。

      →確認した。history-{prev,next} の直後にカーソル位置を手動で設定している
      ので折角 ble/widget/history-{prev,next} がカーソル位置を設定してもそれが
      上書きされていた。その処理を削除されたら期待通りの振る舞いになる事も確認
      できた。然し、更に引数付きで履歴項目内を移動した時には何れにしてもカーソ
      ル位置を調整する必要がある。そもそも処理をよく見てみると
      ble/widget/history-{prev,next} を呼び出す意味はない。単に index を追跡し
      てその都度 get-edited-entry で取り出した文字列に含まれる改行を数えれば良
      いだけである。

      最後に ble-edit/history/goto を一回呼び出すだけにする事にした。

2024-12-12

  * style: prefix:$name の形をしている定義関数の呼び出しのクォートを調整 [#D2296]

    "ble/.../prefix:$name" としている場合と ble/.../prefix:"$name" としている場
    合がある。検索する時に探しにくいので統一したい。特に :"$name" の方が特徴的
    で検索しやすいのでそちらに統一する事にする。但し、関数呼び出し以外の文脈で
    どの様にするかは微妙である。

    * エラーメッセージの一部の場合は全体としてクォートしているので :"$name" の
      様なクォートにはできない。

    * コメントの内部の解説の場合にも微妙である。他にも prefix:"$name" に似た形
      をしているが自動生成したラムダ式などの関数名も存在する。元々、ユーザーな
      どが後付けで定義する時の関数のクォートとして prefix:"$name" を使うので、
      自動生成する関数には適用しない事にする。但し、
      ble/function#advice/original:"$name" 等についてはちゃんと prefix:"$name"
      の形になっているので :"$name" の形式を採用する事にする。

    * ble/is-function 関数名 の場合には関数呼び出しと対になっている事が多いとい
      う事、右辺に関数名が来ることが決まりきっている事などから :"$name" のクォー
      トを採用する事にする。その他の一般の関数の引数 (callback など) として指定
      する場合は微妙だが全体をクォートする事にする。

    * 類似の物として ble/widget/WIDGET_NAME などスラッシュで区切られた物も存在
      する。これについても同様に統一する事にする。

2024-12-11

  * complete: mawk-1.3.4-20230525 以前でプログラム補完が全く効かない (reported by KaKi87) [#D2295]
    https://github.com/akinomyoga/ble.sh/issues/535

    どうも mawk-1.3.4-20230525 以前では関数引数が配列の時に a[] よりも前に
    length(a) があると、勝手にその引数はスカラー文字列と判定してコンパイルを実
    行する様である。そしてこの振る舞いはずっと昔からだった様である。これまで報
    告を受けなかったのは、gawk が入っているシステムでは mawk よりも gawk を優先
    してこの部分の処理で使っていたため。git clone してビルドする方式だと何れに
    しても gawk が要求されるので、殆どのユーザーは gawk をいれていたのだった。
    一方で、報告者は nightly version を使っていた。

    取り敢えず修正した。動作確認もした。

2024-11-28

  * README: README 及び wiki によく行う説明をまとめる [#D2294]

    * auto-complete 関連のエラーに関して説明を何処かに書くべきである。
      CONTRIBUTING か何かに説明を書いてそれを読む様に指示する。

      * done: 問題がこちらでも再現するとは限らないこと。再現することが大事ということ。
      * done: 問題解決のために協力がほしいということ。

      元々 template に書かれている内容についてもそちらに移動する? 取り敢えず最
      低限の内容だけにして其処に記述する事にする。

      * ok: fzf や skim の設定についての説明は何処かの issue comment を参照する
        のが良い。何回かそういう説明をした気がする。

        取り敢えず記述だけはした。改めてリンク先の内容を見て記述漏れの内容や未
        だ書きたいことがないかを確認したら完了という事にする→これは良い気がす
        る。

      * done: また Performance からリンクを貼る: hang しているのは単におかしな
        状態になったからかもしれない。

      * done: auto-complete についての説明の様に書かれているが後半の殆ど全ての
        部分は TAB completion にも当て嵌る事である。構成を調整する必要がある。
        →適当に書き加えた。TAB completion 専用の短い section を追加した。

    * done: 常に ble/widget/display-shell-version の結果を載せる様に要求する?
      但し ble.sh をロードする事ができない、session を開始できない時に限って
      Bash version と ble.sh version を記述する様にする。

    * done: "line_limit_type=editor" の時には history_limit_length も一緒に調整
      するべきという事を wiki, blerc.template に追記する。

    * done: 未解決のまま放置されることとなった巷の問題の一覧を wiki の中に移動する。

      > 溜まってきた "保留" 的な項目については一旦 wiki の何処かにまとめてしまっ
      > て忘れる事にする? 返事のない Issue や再現できない物についてずっと Issue
      > を開いておくのだと際限なく open issue が増えていく事になるが、それらが
      > いつか改めて情報を得て解決されるという事はない様な気がする。また、この
      > note.txt の中にも噂だけで再現しない項目が色々ある。それらについては一つ
      > の文書を用意してその中に記録しておくという事にすれば良い気がする。

      取り敢えず作ったが少ししか記述していない。うーん。また色々 Issues を漁る
      のは大変である。取り敢えず Information Needed の issue は拾って良い気がす
      るがこれも後にする。

    * Performance issue に関連するページも作成すると良いかも。典型的な問題及び
      解決法について。

      https://github.com/akinomyoga/ble.sh/discussions/525

      以下に書いてある様な内容についてまとめる。

      done: https://github.com/akinomyoga/ble.sh/issues/457#issuecomment-2291920637
      done: https://twitter.com/akinomyoga/status/1633101778894958595

      * done: auto-complete に関しては auto-complete で補完生成を turnoff する
        関数や、或いは background で候補生成を実行する様に変更する関数などを用
        意しても良い。それを contrib に入れて於いて呼び出させるなど。或いは、そ
        もそも core-complete.sh の中にある workaround についても、同様の処理は
        実装している筈なのでそのコードを使い回せる様にするべきではないか。

        https://github.com/akinomyoga/ble.sh/issues/522#issuecomment-2425293437

        ここにある設定を記述する? contrib に入れるとしたら何処に入れる?
        complete-utils.bash 的な名前の設定?

      * 返信 https://www.reddit.com/r/bash/comments/1gkv8y1/modern_bash_setup/

        Performance のページを用意する。それに対する pointer を提供する。

        > (i can't even ctrl-c in there)

        Have you checked ble.sh's README for the vi editing mode? Please check
        [the item of `C-c` in the linked
        page](https://github.com/akinomyoga/ble.sh/wiki/Vi-%28Vim%29-editing-mode#normalinsert-mode-c-c-cancel--discard-line).

        と思ったがやはりこれは関係ない事の気がするし、いつの間にかに他の人が色々
        別の話をしているので気にしない事にする。

      * done; 返信 https://www.reddit.com/r/bash/comments/1gzn6gu/blesh_performance_tune_help/?show=original
      * done: 返信 https://github.com/akinomyoga/ble.sh/discussions/525

      * done: profiler の使い方等についても記述するべきではないか。というか、そ
        もそも performance を改善する為にできることはないかと質問しているのは、
        もしかしたら開発者視点での質問かもしれない。ble.sh のコードベースを修正
        する為に何ができるかなどの意味。その為に書けることも実はたくさんあるの
        ではないか。

    x resolved: ble/widget/display-shell-version が set -o posix で正しく動作しない (reported by devidw)

      ユーザーに出力結果の提供を要求する以上は set -o posix であっても動作する
      様にしなければならない。というか、そもそも 5.3 以上では set -o posix の状
      態だと ble/widget/display-shell-version の関数自体呼び出すことができない。

      だとすると C-x C-v で結果を出力するのを主要な方法にするか? 或いは (set +o
      posix; ble/widget/display-shell-version) という形で呼び出してもらう事にす
      るか。然し、それは複雑過ぎる。或いはこれもまた関数名を変更して
      _ble_widget_display_shell_version 等にするべきか。しかしその様にはしたく
      ない。というより ble status とかで表示できる様にするか、或いは ble
      version の中に含めるか。"ble summary" というコマンドで出力できる様にする
      事にした。今後は "ble summary" の結果を出力してもらう事にする。

    x fixed: ble/widget/display-shell-version | cat とした時に _ble_term_bold
      だけ直接使われている為に出力の中に混入する。

    * ok: 実は README 本体は何も更新していない?

      * C で書けだとかシェルで実装するのは云々みたいな批判に対して。これは現時
        点で必要という気もしないので取り敢えず別項目にして後で気が向いたら対応
        する事にする。

      * done: Performance 記事へのリンク。Limitation/Criticism に performance
        を乗せる? 或いは最近頻出なのでもっと上の方に乗せるべきだろうか → うー
        ん。丁度言及できそうな場所が余りない。Limitation という程 limitation で
        もない気がするし、 performance が ble.sh が欠陥の一つとして他の本質的な
        問題と一緒に列挙されるのも嫌な気がする。一番下に troubleshooting の項目
        を乗せてみたがこれだと気づかないかもしれない。Basic settings の丁度上の
        Uninstalling の下に挿入するのが良い気がしてきたので取り敢えずそうする事
        にする。

2024-11-07

  * kitty で _command_offset のエラーが発生する (reported by ozmodeuz) [#D2293]
    https://github.com/akinomyoga/ble.sh/issues/512#issuecomment-2392121827

    これは kitty の側で修正されるべきである。

    ? kitty が bash_completion を load していてしかし何らかの理由で失敗している
      可能性? 実際に g grep で検索してみると bash_completion_script なるものが
      見える。これが何なのか確認する。と思ったがこれは単に kitty が inject して
      いる script のことをそう呼んでいるだけだった。bash-completion に一致する
      文字列はなかった。

    これは kitty に PR を提出したらすぐに merge された。

    →kitty はなかなか新しい version が release されないがこれで解決という事にする。

2024-10-20

  * complete: macOS awk の "towc: multibyte conversion failure on: '...'"エラー (reported by devidw) [#D2292]
    https://github.com/akinomyoga/ble.sh/issues/515

    Ref #D1974

    x fixed: macOS awk の workaround として LC_CTYPE を指定していたが単に local
      を指定しているだけなので呼び出している awk に対してちゃんと環境変数として
      渡せていなかったのではないか。local -x として宣言する必要がある。

      更に LC_CTYPE だけでなく LC_COLLATE についてもちゃんと指定しないと正規表
      現の中にある範囲指定が正しく動作しない (可能性がある)。

      https://github.com/akinomyoga/ble.sh/issues/515#issuecomment-2425177424
      を見る限りは LC_CTYPE さえ指定していれば問題は発生しない様である。なので、
      報告された問題は、本来、前回の workaround の LC_CTYPE が正しく export さ
      れていれば発生しなかった筈の物である。

    x fixed: nawk の判定が正しく動作していない。

      "$path" -W version || "$path" --version

      で version を取得しようとしているが、nawk は "-W" に対応してないというエ
      ラーメッセージが出るにも拘らず 'version' を AWK script だと思って実行し、
      成功する。従って "$path" --version が呼び出されずに version 文字列の取得
      に失敗する。"$path" -W version の実行結果を確認して、それが空だった時は
      "$path" --version を使う様に変更する事にした。

2024-10-19

  * complete: make menu-item styles configurable (requested by simonLeary42) [#D2291]
    https://github.com/akinomyoga/ble.sh/issues/519

    * done: fish の menu 関連の着色を確認する

      HighlightRole::pager_prefix => L!("fish_pager_color_prefix"),
        これが今回の色。

      HighlightRole::pager_progress => L!("fish_pager_color_progress"),
        これは処理中の表示の着色に使う色。

      HighlightRole::pager_background => L!("fish_pager_color_background"),
        全体の背景色? これは必要だろうか? でも secondary や selected などで同様
        のものがある事を考えるとやはりそれぞれの項目の色? でもそれなら普通に
        --background= で指定すれば良いはず。

      HighlightRole::pager_completion => L!("fish_pager_color_completion"),
        謎。fg は全ての候補に適用される。bg は選択された項目だけに適用されてい
        る。background と conflict しないのか?

      HighlightRole::pager_description => L!("fish_pager_color_description"),
        これは既に menu_desc_default がある。

      HighlightRole::pager_secondary_background => L!("fish_pager_color_secondary_background"),
      HighlightRole::pager_secondary_prefix => L!("fish_pager_color_secondary_prefix"),
      HighlightRole::pager_secondary_completion => L!("fish_pager_color_secondary_completion"),
      HighlightRole::pager_secondary_description => L!("fish_pager_color_secondary_description"),

      HighlightRole::pager_selected_background => L!("fish_pager_color_selected_background"),
      HighlightRole::pager_selected_prefix => L!("fish_pager_color_selected_prefix"),
      HighlightRole::pager_selected_completion => L!("fish_pager_color_selected_completion"),
      HighlightRole::pager_selected_description => L!("fish_pager_color_selected_description"),

      意味が分からない。コードを見てみたがそれでも良く分からない。background は
      bg を決定するだけの為に使われている様に見える。そして {selected_,
      secondary_, }background は排他的に指定されている?

      prefix の着色には prefix を、それ以外の部分については completion を使って
      いる。うーん。fg と bg は独立に指定している? ちょっと意味が分からない。
      https://fishshell.com/docs/current/interactive.html に一応説明があった。
      secondary に関しては候補について交互に着色を切り替えるための物らしい。背
      景色ぐらいはこれで指定できる様にして良い気がする。

      fg = prefix || completion で、bg = background || prefix || completion 的
      な優先順位で決まっているという事だろうか。一方で ble.sh では候補毎に着色
      を決められる様にしているのでこれを外部から指定するのは変な気がする (或い
      は何も指定しなかった時の着色をこれにする?)。何れにしてもこれらは

      * prefix の時の追加描画属性
      * 選択時の追加描画属性

      として実装するべきの気がする。背景色については普通に指定すれば良い。
      secondary については背景色は指定できる様にしても良いかもしれないが、文字
      色やスタイルまで変えるのは変な気がする。また、背景色についてはその文字の
      位置だけではなくて領域全体に広がって指定できる様にしたい気がする。

    * done: update wiki for filename_ls_colors #D2213 (e169e31d) で色々修正した
      筈。ln=target と '.'* と '*'?* が追加されている。

    * done: g#append で reverse を xor で合成するべきか、或いは加算的に合成する
      べきか。うーん。地の文の描画属性に対して g#append で部分的な文字列の描画
      属性を作る時には xor で合成するべきである。一方で、face の設定として
      reverse を使う時には微妙である。うーん。xor で良い気がする。そもそも現状
      で g#append を使う時に reverse は使っていない気がするので、振る舞いを変更
      しても問題ないのでは?

      現在の使用箇所について確認を行う。

      * ble/canvas/trace/.put-sgr.draw で trace に指定した地の文に対して esc で
        指定された着色を追加する時に使われている。これは寧ろ xor を使うべきパター
        ンである。

      * ble/highlight/layer:menu_filter/getg において menu_filter_{fixed,input}
        の region 着色を求める時に、下の layer の着色を元にして色を決定している。
        これは xor で良い気がする。というかこれも xor を使うべき?

      * ble/syntax/highlight/ls_colors では face filename_ls_colors で指定した
        着色の上に LS_COLORS 由来の着色を合成している。これは xor ではなくて or
        でも良い様な気がする、というか寧ろ or の方が良いかもしれない、と思うが、
        そもそも LS_COLORS に反転を使うのかという話もあるし、filename_ls_colors
        を用いて一律に反転している時に、元々 LS_COLORS で指定していた物が紛れて
        しまうというのも意図に合致するのか分からない。そう考えると xor でも or
        でも良い様にも思われる。

      現状ではこれだけでしか使われていない。

      * face の合成については将来的に対応するかもしれないが、現状では未実装であ
        る。face の合成については or の方が良いのではとも思ったが、よく考えると
        上記のパターンと同様の使い方をする場合もあるから xor の方が良いパターン
        もあるだろう。という事を考えるとやはり振る舞いは統一して xor にするべき
        である。そもそも合成する場合に reverse を用いるのが非自明である。

    * done; menu_complete_match, menu_complete_selected には対応した。動作も確
      認した。

    * done: .readline-colored-completion-prefix

      うーん。これは現在の LS_COLORS を参照するべきか、或いは bleopt
      filename_ls_colors に指定した値を参照するべきか。filename_ls_colors で対
      応しようと思っていたが、考えてみれば readline は LS_COLORS の値を反映して
      動作するのだった。filename_ls_colors は LS_COLORS という本来は ls の為の
      変数を ble.sh に流用する時に用いる変数だったので、独立した設定にしていた。
      一方で、.readline-colored-completion-prefix は readline 専用の項目なので
      積極的に取り込んで良いのではないか。

      と思ったが、bleopt には bleopt の設定変数があって、指定方法など考えるとそ
      ちらの方を優先したい様にも思う。そもそも
      *.readline-colored-completion-prefix は ble.sh の為ではなくて readline 用
      に設定している場合もあるだろうから、積極的に設定を読みに行くのも問題があ
      る気がする。

      等の事を考えると、やはり filename_ls_colors に明示的に指定した時にだけ着
      色が反映される用にするという事で良い気がする。

      →対応した。

    * reject: 背景色および交互背景色を指定できる様にする? 交互指定については背
      景色にしか対応しない。文字色やスタイルも一緒に変えるのは変だ。

      背景色に関してはその項目の文字列部分だけの背景色ではなくて、desc も含めた
      その項目の領域の背景色にする。逆に言うとその項目の領域を明確に定義する必
      要があるという事。マウスサポート等も考えると元より領域は定義するべきの気
      がするのでこれ自体は問題ない。

      うーん。実装を確認すると例えば align の場合には measure-item で先に各項目
      の esc を生成しつつサイズを測り、その後で配置を決定している。つまり esc
      を生成している時点ではどの様な配置になるか分かっていないという事になる。
      もし交互に背景色を変えようと思ったら配置が決まった後に再度 esc の生成を実
      行しなければならなくなり処理が倍増する。これは実装しなくて良い気がする。

      一方で menu-complete を表示する領域全体の背景色を設定できる様にする可能性
      はあるかもしれない。ただ、だからと言ってそれほど便利な気もしないので取り
      敢えず今は対応しないという事で良い。

    * done: blerc.template 及び wiki に新しく追加した face の説明を追加する。

2024-10-07

  * make: .git に依存しない設定のために (requested by LecrisUT, blackteahamburger) [#D2290]
    https://github.com/akinomyoga/ble.sh/issues/509

    * edit: git archive で .git の代わりに commit-id を埋め込む (requested by LecrisUT)

      issue title は git archive が build できないという物だが、提示されている
      解決法は部分的な解決でしかない。結局 submodule の中身が含まれないので依然
      として build できない。

      .git に対する prerequisites は消す事にする。何故なら別に .git を作成する
      規則を用意している訳でもないので、別に prerequisites のエラーとして処理し
      なければならない必要性もないから。単に $(error ...) でエラーを出色すれば
      良いだけの話である。

      ble.pp の内部で解決するのも面倒なので GNUmakefile の中でまとめて git 関連
      の情報取得を行って、環境変数経由で ble.pp に渡す事にした。

    * 元々 git 前提だし git なしでビルドできる様にするのには色々困難があるので、
      中途半端に対応しても仕方がないと考えていたが、修正しようとする人が余りに
      も多い (しかも何故 .git repository を禁止している package manager がこん
      なにもあるのだろうか) ので或る程度修正する事にした。

    * ble.sh の依存性を git ls-files を用いて抽出しようとする部分があるが、これ
      は out/ble.dep から依存ファイルを抜き出せば良いのでは → 実装した。

  * histdb: calendar の着色が消滅している。何故? [#D2289]

    これは既定の histdb palette の halloween の指定が誤っている為だった。10月に
    なったので halloween の配色を指定する様になったから問題が出るようになったの
    であって昔からあったバグだった。github-light を halloween-light に書き換え
    るべき所を github-halloween に書き換えていたのが問題。

2024-09-25

  * edit: M-x execute-named-command の補完 [#D2288]

    * fixed: histdb-history が auto-complete でコマンドを生成している。うーん。
      調べてみると source:history については .search-light では
      $_ble_history_prefix が設定されている場合には処理をキャンセルする様になっ
      ている。これと同様にするべきである (因みに .search-heavy については直接履
      歴を検索するので問題ない)。

    decode.sh の ble/builtin/bind/rlfunc2widget で配列に読み込んでいる部分を分
    離して別の関数にする。そして、それを用いて現在の入力に合致する候補を生成す
    る。

    うーん。これは ble/widget/complete とは別の枠組みになる? と思ったが同じ枠組
    みで補完できる様になっているべきである。ちゃんとそれに対応できているだろう
    か? これは一般の補完の枠組みの再考にもなる。

    * 既存の実装の syntax/completion-context は現在の言語に関する分岐は何もして
      いない。どのように拡張するべきか。

      check-here は bash の文法について hardcode されていて拡張性がない形になっ
      ている。check-prefix に関しては配列に設定を代入できる様になっているので、
      別の言語の場合にも

      新しい言語に対応させる方法はどの様にするべきだろうか。

      a 現在の文法文脈 ctx に補完を結びつける方法をそのまま拡張して、別の言語で
        も別の文法文脈にしてそれによって補完を生成するべきだろうか。

        x この方法だと現在の言語に応じて同じ文法要素でも生成する候補を切り替え
          たりする様な場合には困るかもしれない。然し実際にそのような状況が存在
          するだろうか。

        x また文法が何もない plain な時の補完についてはこれだと対応できない?

          →しかしその場合には plain な時の補完関数の中で _ble_syntax_lang に応
          じた補完を実行すれば良いのである。拡張の為の interface も用意する。

          →或いは補完を提供するのであればその為だけに新しく ctx を定義しても良
          いのではないか。もし補完を提供するのであればそれと同時に着色も提供し
          たくなる。そうすると更に ctx を提供する理由が出てくる。

      b reject: 或いは、現在の言語 _ble_syntax_lang の値に応じて補完の仕方を変
        更するべきだろうか。

        x 複数の言語が途中で切り替わったり混ざったりする様な状況を考えると、こ
          の方法だと複雑になってしまう。基本的には言語が混ざっている場合にはそ
          の言語に対応する関数を下請けにして呼び出す様にすれば良い気がするが、
          そもそも ctx base で parse した結果として、それぞれの位置がどの言語に
          対応していたのかを後で決定するのは非自明である。

        そもそも _ble_syntax_lang は一番最初の ctx を指定するぐらいの役割しか無
        かったのではないか? だとすると _ble_syntax_lang に基づいて全体的に振る
        舞いを変更するというのも変である。

        実際調べてみると _ble_syntax_lang によって切り替わっている処理は
        ble/syntax:bash/initialize-ctx, ble/syntax:bash/initialize-vars だけの
        様である。だとすれば _ble_syntax_lang で振る舞いを変更するというのは設
        計として不自然である。

    * done: execute-named-command に対応する文脈を追加する

    * done: execute-named-command に対応する着色を提供する

      これについてはもっと考察が必要である。文法解析の辞典で単語の種類まで特定
      し始めるとキー入力をする度に処理が走る事になって遅くなる? なので単語を設
      置して単語着色として単語の種類を決定してそれに基づいて着色する? と思った
      が、よく考えたら文法解析だって連続でユーザーが文字を入力した場合には最後
      の文字を入力するまで suppress されるのだし、別に問題ない。

      また補完の為に単語を設置しようとも思ったが completion-context で word が
      見えるのは単語の途中に解析再開点を設置した時だけである。

      単語を設置しても処理が複雑になるだけなので気にしなくて良い気がする。と思っ
      たが一度実装したので取り敢えずはそのままにしておく?

    * done: execute-named-command に対応する補完を提供する

      * done: check-prefix については取り敢えず実装した。

      * done: check-here についてはどうするか? 特に一番最初の補完ができない。現
        在の枠組みでは check-here は hardcode されている → check-here について
        も check-prefix と同様に配列に登録する形に変更した。

        これも取り敢えず実装した。動いている。

      * done: completion-context/.add は completion-context/add に名前を変更す
        るべきである。

    x fixed: 入れ子で M-x を実行しようとすると assertion failure になる。

      | assertion failure: [[ ! $_ble_edit_async_read_prefix ]]
      | it is already inside the async-read mode.

      うーん。async-read-mode の keymap では execute-named-command を無効化しよ
      うと思ったが、async-read-mode はユーザーが指定した keymap を元にして実行
      できる様になっている。また、既定の keymap は read である。然し、read でも
      execute-named-command を実行したくなる事もあるだろうし、keymap から完全に
      削除するのも微妙な気がする。execute-named-command は keymap に入っていて
      もいいが呼び出した時には無視する様にする事にした。

      と思ったが普通に実行した read -e の中で execute-named-command を実行する
      と描画が変な事になる事が分かった。一応動いている事には動いているが、同じ
      panel を使って処理されている? そして、処理が終わった時に元々の表示済みだっ
      た文字列が再描画されない。という事を考えるとやはり read -e は subprompt
      が発生する様な入力について想定していなかったという事?

      然し plain bash の read -p に関してはちゃんと M-x を正しく処理できている。
      なので、read だからと言って subprompt が出せないという訳には行かない。現
      在の panel の構成は以下の様になっている:

      - panel0 ble/textarea
      - panel1 ble/textarea
      - panel2 ble/edit/info
      - panel3 ble/edit/visible-bell
      - panel4 ble/prompt/status

      read -e は panel1 を使っている。async-read-mode も panel1 を使っている。

      a 更に新しい panel を用意してその上で描画する? わざわざそれだけの為に
        panel を増やしたくない。そもそも本当に必要なのだろうか?

      b 或いはコマンド実行時は read -e は panel0 を使う? 然しこれだと ble.sh
        context の中で read -e をユーザーが設定したスクリプトが使った時に問題に
        なるのでは? と思ったがその場合には panel1 を使うので大丈夫。

        うーん。この方針で良いのではないか? command-layout では panel0 を使い
        M-x は独立した行に表示される。非 command-layout では read は panel1 を
        使い、M-x は同じ位置に置き換える形で描画される。但し、M-x から戻った時
        に元の内容をちゃんと復元する。

      c panel1 の上で上書きする様に実行する。但し、元に戻る時に再描画を要求する。
        これだと read の中で更にコマンドを入力している時に元の入力文字列が一時
        的に見えなくなる。しかし、plain bash の実装が既にその様になっているので
        それは許されるのではないか。

      d やはり read -e の中では execute-named-command は禁止する?

      取り敢えず b の方針で調整する事にした。動作確認した。良い。

    x ok: COMPV 生成方法に関する議論: COMPS -> COMPV に変換するのは COMPV がフィ
      ルタリングに使われる物である事を考えると必要である。然し一方で文脈によっ
      ては COMPS -> COMPV の変換は bash の文法ではなくてその文脈固有の方法で実
      行する必要がある。その様な場合にどの様に処理するべきか。

      | comps_flags や comps_fixed による変な作用も考慮に入れる必要がある。
      | pick-nearest-sources で同じ位置から始まる source を全てまとめてしまって
      | いるが、本当は文法的な取り扱いに応じて分類して同じ分類になる物だけをま
      | とめて実行するようにするべきである。
      |
      | うーん。COMPV の生成は pick-nearest-sources が担っているのでこの関数の
      | 振る舞いさえ調整すれば問題ない筈である。うーん。word-eval の方法を指定
      | できる様にする? どの様に指定できる様にするべきか?
      |
      | a 各 source 毎に word-eval の方法を指定できる様にする。例えば追加の関数
      |   を定義させる等して。この場合には複数の source が混ざっていて、それぞ
      |   れの source が異なる word-eval の規則を要求した時にどうするのか非自明
      |   である。例えば同じ種類の word-eval の物だけまとめて最初に処理する?
      |
      |   またどの様に指定させるのかも非自明である。例えば comp1 の field を拡
      |   張して comp1,word-eval 等の形に指定できる様にする? この様にすれば同じ
      |   種類の補完の grouping は簡単になる。
      |
      | b そもそも word-eval は top-level で実行する必要があるのだったか?
      |   filtering についても生成された候補が主張する文字列で filter すれば良
      |   いのではないのか。例えば complete の時に改めて COMPV を確認する必要が
      |   あったのだったか。改めて COMPV の使われ方について確認する必要がある。
      |
      |   単に速度の問題として共通に使いそうな word-eval を top-level で提供し
      |   ているだけなのだとしたら、実は内部で生成する時に COMPV を好きに上書き
      |   して処理すれば良いので余り気にしなくて良い事になる。
      |
      |   - というか既に fzf 等の補完では COMPV を勝手に書き換えて処理している。
      |     特に問題は発生していないのでそれで良いという事なのでは?
      |
      |   * 実際に実装を確認してみると選択された sources で使われた COMPV を
      |     menu_common_part の着色に使用している。つまり、現在の入力内容に基づ
      |     いて filtering をしてまた候補に着色をする時に、その候補に対応する
      |     word-eval で得られた現在の値を用いて着色を行う必要がある。
      |
      |     これにちゃんと対応するには各候補毎に word-eval の方法を記録して、そ
      |     の候補毎に値を取得して部分着色を実行する必要があるのでは? 大変であ
      |     る。
      |
      |     →確認した所やはり menu_common_part を使っているのは
      |     ble/complete/menu-complete.class/render-item である。他では値を引き
      |     回しているだけで使っているようには見えない。疑問は
      |     menu-filter/auto-menu で incremental に絞っている時に
      |     menu_common_part がどの様に更新されているのかという事。
      |
      |     うーん ble/complete/menu-filter が menu_common_part を再設定してい
      |     る様だ。
      |
      |   ? menu-filter による filter-candidates で無駄に制限されたりしないのだ
      |     ろうか? filter-candidates は COMPV (simple-word/eval) による
      |     filtering を前提にしている。
      |
      |     うーん。 ble/complete/menu-filter/.filter-candidates の中で
      |     ble/complete/candidates/filter#init と
      |     ble/complete/candidates/filter#test のペアを使っているが、此処で候
      |     補毎に compv の取得方法の指定をできる様にしたら良いのではないか? 例
      |     えば ble/complete/candidates/filter#test の第二引数に word-eval の
      |     種類を指定した時は対応する COMPV を特別の方法で取得してそれを使って
      |     制限する様にする。追加で comp_filter_type[index] にキャッシュしても
      |     良い。word-eval の方法と index の対応付は事前に行っておく必要がある。
      |
      |   これは複雑になりそうなので別項目で処理することにする。
      |
      | c 或いは、ble/complete/context:* の側で word-eval の方法を指定する。つ
      |   まり context:syntax の場合には現在の COMPV を生成を用いてそれ以外の時
      |   にはそれぞれに応じた展開・評価を実行する。と思ったが、複数の言語が混
      |   ざる場合などを考えると、ble/complete/context:syntax のレベルでも
      |   source 毎に異なる word-eval の方法を用いたい様な気がする。

      取り敢えず b の方針で考える事にする。然し、現時点で既に menu-filter によ
      る filtering は不完全 (例えば compopt -o ble/syntax-raw で生成された候補
      など) なので、これに対処しようと思うと広範囲にチェックが必要になる。なの
      で、取り敢えず今回の修正では menu-filter の事は考えずに source の内部だけ
      でのみ COMPV を書き換えて評価する事にする。今後の COMPV の様々な評価方法
      への対処については独立した項目として残す事にする。

    * done: compgen -V を使う。というかそもそも compgen 自体を抽象化して良いの
      ではないか?

      既存の compgen の呼び出しも置き換えられるのではないか。と思ったが既にある
      コアの compgen の呼び出しでは compgen -V に対応していない場合には完全に行
      指向の処理として後段の処理を awk で行っていて、それによって効率化している。
      という事を考えると現在の一番外側の compgen の利用の場合には assign-array
      を用いる理由がない。

      一方で個別の処理で assign-array compgen 云々を呼び出している箇所が3箇所ほ
      どある。これらについては新しい関数で置き換える事ができる。

      * うーん。既存の生成で compgen で標準出力に出しているのは compgen -V がな
        かったからではないか。今となっては、実は素直に compgen -V を使うのが良
        いのではないか。

        x と思ったが、依然として古い bash では標準出力を経由する必要がある。
        assign を何回も実行するよりはやはり assign 一回で生成するのが効率が良い。

        うーん。既存の tilde, command の生成では結局 sort -u を実行する必要があ
        るので、わざわざ配列に格納する必要性もない様に思われる。また改行が含ま
        れる候補が生成される場合も考えにくいので、compgen -V を使う理由は効率以
        外にない。結局 sort -u を使うのだとしたら compgen -V にするよりも直接
        stdout に出力した方が効率的である。という事を考えると、これらは当面は現
        状の様に stdout に出力するのが妥当である。

        何か変わるとしたら compgen に "sort -u" の機能がついた時である。

2024-09-24

  * complete: skim integration (reported by cmm) [#D2287]
    https://github.com/akinomyoga/ble.sh/issues/502#event-14354810067

    うーん。内容的にはほぼ fzf と同じである。fzf-completion 及び
    fzf-key-bindings から共通部分を抽出してそれを使うべき? 然し、そうすると
    fzf-completion-lib と fzf-completion, fzf-key-bindings-lib と
    fzf-key-bindings 等のように分離しなければならなくなり、無駄にファイルが増え
    てしまう。或いはほぼすべての実装は fzf-base 等のファイルに定義する事にして、
    fzf-initialize, fzf-completion, fzf-key-bindings では hook だけ定義する様に
    する?

    結局 skim shell settings がどの様に配置されるのかよく分からないので、ロード
    しようと思った時にどの様に場所を特定したらよいのかは謎である。fzf と全く同
    じ方針で探索しておけば良いのだろうか? 或いはもっと別の場所も探すべき? うー
    ん。取り敢えずわからないので fzf と全く同じに処理する? だとすると
    fzf-initialize の処理も共通化する必要がある。

    取り敢えず実装した。fzf-completion 及び fzf-key-bindings は問題なく動いてい
    る。

    x fixed: うーん。#D2285 の変更によってユーザーの指定した
      _ble_contrib_fzf_base が無視される様になってしまっていた。これは修正する
      必要がある。

    * done: skim が実際に動作するかどうかを確認する必要がある。また、fzf や
      skim の completion.bash が直接 source された時に後付けで integration
      script が読み込まれた時にも正しく動作するか確認する必要があるのでは。

      取り敢えず動いている様である。

2024-09-23

  * nsearch: 履歴検索して行を挿入する (motivated by vaab) [#D2286]
    https://github.com/akinomyoga/ble.sh/discussions/499

    * そもそも本当にそのような使い方は理想的な使い方なのか。その使い方は bash
      の限られた機能の上でコマンドラインを編集する為にしみついた bad practice
      のような気がする。例えばテキストエディタでその様な機能を使っているのだろ
      うか?

    * nsearch action=replace-command, action=insert, etc. は便利な気がするので
      この request とは関係なく実装して良い。

      うーん。needle の決め方と一緒に指定するべきの気がする。どの様な needle の
      決め方があるだろうか。

      ? 既存の実装で C-g でキャンセルした時には何が起こるか。どうも C-g に
        _ble_edit_nsearch_stack に状態が記録されている様で、それを使って元の状
        態を復元している。開始時に内容を記録してるという訳ではない様だ。

        そうだとすると「C-g で使っている情報を拡張して書き換えを行う」という方
        法は使えない。全コマンドラインの内容を記録しているのだとしたらどの範囲
        が置換対象なのかの情報などは分からないし、そもそも記録しておく必要もな
        い。_ble_edit_nsearch_stack に記録している全 step で置換範囲を記録して
        おく必要もない

        → と思ったがロードした文字列が挿入されると置換対象の終端点は変わるので
          は? と思ったが、これは一番最初の文字列と一番最初の文字列における置換
          範囲の位置を記録しておけば良い。何も挿入後の状態を使って更に別の挿入
          を行った時の状態を生成しなくても良い。

      動作を実装するうえで何を考えるべきか。

      * needle に関しては初回に決定するのでグローバルに改めて新しく記録する必要
        および記録の仕方を変更する必要性はない。

      * action=load の時は加えて元の文字列と置換対象範囲を記録すれば良い → 取
        り敢えず元の文字列と置換範囲を記録してそれを元に load を行う様に修正し
        た。

      設定の interface はどの様にするべきだろうか。例えば action=load-command
      にした時は現在のカーソルがある位置のコマンドを置き換える様にするなど? そ
      の場合には既に入力済みのコマンドを検索文字列にする。うーん。これが良い気
      がする。その他の行単位にロードするなどの機能は理論的には便利かもしれない
      が微妙の気がする。

    * 或いはもっと単純な interface で良いのではないか? 例えば M-insert で現在位
      置 (履歴番号、カーソル位置) を記録して、その後で履歴の中を移動した末に
      M-w を押すと元の場所に戻ってその場に選択した行を挿入するなど。

      或いは最後に非履歴移動を行った履歴項目を記録しておく。もしくは履歴移動
      widget の chain の中で最初に履歴移動を行った場所を記録しておく。履歴移動
      に関するコマンドの中で常に履歴項目を記録する事にして、但し前回の widget
      も履歴移動だった時には更新を抑制するという形にすれば良い。しかし、up や
      down 等はカーソル移動と履歴移動が組み合わさっている。この場合も履歴項目の
      起点は更新しない様にしたい。という事を考えると、実は最後に編集を行った位
      置を参照すれば良い?

      a _ble_edit_undo_hindex に記録されている筈である。

        と思って実際に実装してみたがどうも _ble_edit_undo_hindex は undo/add が
        実行されていなくても頻繁に更新される様だ? というかそもそも undo を記録
        する為に初期の状態を記録している。なので何れにしても
        _ble_edit_undo_hindex には現在の位置が設定されていると考えるべきである。

        undo は keymap の __before_widget__ で処理されている。なので、last
        modified entry の記録も __before_widget__ を自分で設定する事によって行
        う事になるのだろうか。last modified の検出方法はどの様にするべきだろう
        か。履歴項目が移動した事によって _ble_edit_str が変化したのと編集によっ
        て _ble_edit_str が変化したのは区別する必要がある。履歴項目の移動に関し
        ては比較対象を更新する事にして、widget 実行後に比較対象と現在の値が違っ
        ていたら modified として記録する。auto_complete や menu_complete によっ
        て一時的に挿入されている内容を検出したら駄目の気がするので、これらは基
        底の __after_widget__ で処理するべきだろうか? 然し、
        auto_complete/cancel-default などの場合にちゃんと __after_widget__ が実
        行されるだろうか?

      b 改めてコードを見ていて気付いたが ble-edit/content/reset に対して監視を
        行えば良いのである。変更の reason で履歴移動も除外できる。そもそも
        observer を登録する為の配列 _ble_edit_dirty_observer も用意している →
        これを使って実装したらいい感じに動いている気がする。

  * contrib/fzf-initialize: "fzf --bash" を使う (motivated by louiss0) [#D2285]
    https://github.com/akinomyoga/ble.sh/issues/494

    やはり各ファイルを package に含めてもらうのが一番である。速度もそちらの方が
    速い。然し駄目なパッケージは幾らでも今後出てきそうなので workaround として
    $(fzf --bash) を使う様にする。

    2024-10-10  _ble_contrib_fzf_base が動かなくなっている (reported by 3ximus)
    https://github.com/akinomyoga/blesh-contrib/issues/26

    これは既に気付いて手元では修正していたが、報告があったので記録のために残し
    ておくことにする。

  * contrib/fzf-complete: '\:' が無駄に escape される問題 (reported by mcepl) [#D2284]
    https://github.com/akinomyoga/ble.sh/issues/501

    調べると bash-completion が使っている compgen の出力結果が変化している何の
    条件で結果が変わるのだろうか。関連する変数や引数の内容が全て同一でも異なる
    結果を生成する。そもそも Bash の振る舞いとして、コマンドラインの中身に応じ
    て compgen 自体の振る舞いが変化する。これは一体どういう事だろうか。

    test1 ~/tmp1/a\:b/ が既に入力されていている時には unquoted な結果が生成され
    る。一方で test1 [TAB] を試みると quoted な結果が生成される。特に現在補完対
    象の単語に \ が含まれているかどうかで振る舞いが変化している? 何故補完対象の
    単語に \ が含まれていると quote しなくなるのか? ' の中の文脈と等価に扱おう
    としている?

    しかし、この振る舞いは bash-completion やその他の補完に対しても影響を与える
    のではないか?

    bash の中を見ると最初に何やら dequoting やら何やらしているがこれは関係ない?
    何れの場合でも同様に実行している。結局よく分からない。実際に動かしながら後
    で観察する必要がある。

    ? ok: rl_filename_completion_function の中で convfn を確保した後に
      complete_fncmp が失敗したら free していない気がする。と思ったがずっと後で
      free している。

    うーん。bash-completion に介入するにしても bash の正確な振る舞いが分からな
    いとどう修正したら良いか分からない。例えば、bash-completion の生成するファ
    イル名を常に unquote してしまって良いのかそれとも何らかの条件でそのままにす
    るべきか。

    [Bash の振る舞い]

    bash の中での動きを見るしかない。どうやら rl_filename_completion_function
    の戻り値の段階で quote しているかしていないかが変化する様だ。引数に渡されて
    いる文字列は同じである。rl_filename_rewrite_hook による書き換えかと思ったが
    そういう訳でもない? rl_directory_rewrite_hook が時々 off になっている可能性?
    と思ったが常に有効の様である。うーん。どうやら dirname と users_dirname の
    二種類の変数があって、users_dirname の中身がそのまま候補生成に使われている
    様だ。そして users_dirname が異なる内容になっている。何故だろうか。

    うーん。2回目の呼び出しの時 (bash-completion の通常の状況と一致) の場合には
    rl_completion_found_quote が有効になっていて、この時には
    rl_filename_dequoting_function によって dequoting が実施される。

    うーん。complete.c の rl_complete_internal の中で現在の単語に quote が含ま
    れるかどうかをテストして、もし含まれていた場合には found_quote を 4 にして
    いる。そして、それが rl_completion_found_quote にコピーされて振る舞いが変化
    している。found_quote は " または ' または \ を見ている気がする。つま
    り、'...' や "..." の中にいると勘違いしている? うーん。試してみた所 ' だと
    found_quote = 1 になり、" だと found_quote = 2 になり、\ があると
    found_quote = 4 になる様だ。何れにしても quote の中身だと思って dequoting
    を実行しているという事の様だ。うーん。かなり微妙。

    bash-completion / progcomp の中ではユーザーが \: を入力している場合には ;
    に変換した物が候補として生成される様になっている。これを COMPREPLY に格納し
    た時に最終的に挿入される文字列は? どうも \ が除去された物が挿入されている様
    な気がする。

    - うーん。\ がある時に found_quote になって結果として dequote された物が生
      成され、更にそれがそのまま挿入されるのは bash のバグの気がする。

    - bash-completion は余り関知していない様な気がするが bash 的には compgen で
      quote 済みの文字列を生成して、それをそのまま挿入する想定になっている気が
      する。但し、現在の単語に何らかの quote が含まれる場合には余分な quote を
      避ける為に dequote を実行している。この中途半端な振る舞いが混乱の元になっ
      ている気がする。更に compopt -o filenames を用いてファイル名に一致するか
      どうかで振る舞いを変えたりしていておかしな実装になっている。

      うーん。quote 済みの単語を生成しているつもりなのであれば勝手に quote する
      のは良くない?

    或いはそもそも compgen に \: を含んだ文字列を指定するのがいけないのだろうか?
    然し quote がない状態で compgen に単語を渡すとやはり正しく候補が生成されな
    くなる。うーん。\ ではなくて " で quote する様にすれば良いのか?

    [fzf completion 有効の時だけ問題になる理由]

    うーん。改めて振る舞いを確認すると fzf-completion と組み合わせた時に特に問
    題が生じている。単に bash-completion & blesh では問題は再現しない。何故
    fzf-completion と組み合わせた時にだけ問題が生じるのだろうか? cur の値が変に
    なっている?

    どうやら fzf-completion が有効でない場合には ble.sh の側で実行して言える調
    整 (~/tmp1/a:b -> '/home/tmp1/a:b' の書き換え) によって問題が回避されている
    様である。しかし、fzf-completion は文法レベルで処理をしようとするのでこの
    ble.sh の調整を無効にしている。然し、これが fzf-completion から呼び出してい
    る dynamic completion にも影響を与えているという事。dynamic completion につ
    いては文法に直接作用する調整は必要ない気がする。

    fzf から呼び出される dynamic completion では ble/syntax-raw の処理を外す様
    にしたら問題は発生しなくなった。

  * canvas: Unicode 16.0.0 [#D2283]

    どうやら 2024-09-10 頃に Unicode 16.0.0 が公開された様である。更新する。書
    記素クラスターにまた修正があったかと思ったが、規則は変わっていなくて単にテー
    ブルの割当が更新された事と、説明が丁寧になった事だけの様である。文字幅テー
    ブルについても更新した。emoji のテーブルも更新した。文字幅判定に使う文字も
    追加した。

    過去の Unicode 15.1.0 で他に何か更新していないか確認しようとしたが、スクリ
    プトが大幅に整理されているので何処が更新されたのか・何処を今回も更新するべ
    きかを其処から読み取るのは大変である。取り敢えず自動生成対象のファイルは全
    て更新したので良い事にする。

  * [設定ミス] canvas: alacritty に於いて prompt_status_line が動かなくなっている [#D2282]

    9889 (U+26A1) の文字幅が実際には 2 なのに 1 と判定されている。と思ったら
    char_width_mode=emacs になっていた。auto にしたら直った。

2024-09-22

  * util: check sanity of the locale (WSL2 で日本語を入力すると表示が変になる) [#D2281]

    何故か文字が分割して入力されている。ble/debug/keylog#start で受診した文字列
    を見るとちゃんと日本語の文字として入力されている。うーん。何故そのような事
    になる? と思ったら locale ja_JP.UTF-8 がインストールされていなかった。

    locale が install されていないという事を事前に検出する方法はあるだろうか?
    例えば .utf8 もしくは .UTF-8 が指定されているのにも拘らず ble/util/c2s
    12354; ble/util/s2c の結果が元に戻らないなど? 今どき locale の設定として
    non-ASCII な物はほぼ UTF-8 と想定して良いので UTF-8 の時だけチェックすると
    いう形で問題ない。そもそも親切に警告しなくても良いのだから、UTF-8 以外でも
    警告を表示する強い必要性はない。というかよく考えたら ble.sh は入力 encoding
    として UTF-8 しか対応していないのだからそれ以外の文字コードはそもそも動作保
    証対象外である。e

    ? 問題はどの時点で警告を表示するのかという事。

      a ble.pp の最初の環境チェックで utf8 サポートもチェックする? 然し、ble.pp
        ロード時は ble.sh で使っている Unicode サポートの判定用の関数は未だ定義
        されていない。複雑な処理をしているので、ble.pp 冒頭で同様の判定を行って
        util での処理と一貫する様に管理するのはコストが高い。

      b 或いは ble-attach 時に検出を行う? 然しその場合は普通に stderr 等に警告
        メッセージを出力しても問題ないだろうか? UI を上書きしない様にする為には
        prompt を初めとして何かを出力するよりも前にチェックを行って警告を表示す
        る必要がある。

      更にユーザーが試しに LANG 変数を書き換える等して存在しない locale を指定
      した場合にはどうなるのか? そう思うと ble-attach 時ではなくて、ユーザーが
      コマンドを実行する度にチェックするべき?

      c コマンド実行直後に locale 関連の変数が更新されていたら unicode のチェッ
        クを行う。

        既存の ble/util/.cache/update-locale の更新チェックで一緒に unicode に
        正しく対応できているかを確認しようと思ったが ble.sh util.sh の枠組みで
        色々な場所から is-unicode-output が呼ばれていて、そこから update-locale
        が呼び出されている。ユーザーが呼び出した様々の便利関数 (例えば ble-bind
        -P など) で既に locale が更新されるかもしれない。なので、コマンド実行直
        後の更新が "locale 変数変更直後の最初の update-locale" である事を保証で
        きない。

        →実際に簡単に実装してみて分かったのは、実は bash の起動後に誤った
        locale に設定しようとした時には bash 自体がエラーメッセージを発するとい
        う事。なので ble.sh がわざわざそれを検出して報告する必要はない。寧ろ、
        bash がエラーメッセージを発した後は、bash の実際の LC_CTYPE の状態が現
        在の LANG, LC_CTYPE, LC_ALL などの変数と異なる状態になるので、locale が
        壊れているのかどうか正しく判定する事ができなくなる。偽陰性 (見落とし)
        が発生する可能性がある。偽陽性はないと思われるので一応は現在のチェック
        のままでも問題はないと思われるが。

      そもそも update-locale に於いても、もし unicode support が完全でなかった
      場合には C に fallback するべきである。何れにしても update-locale では現
      在の LC_CTYPE がちゃんと動いている事を確認する必要がある。

    * もし現在指定された locale がシステムでサポートしていないのだとしたら、そ
      れはそれで、それに応じた幅計算を実装するべきではないのか?

      幅計算は ble/util/c2w だが、ble/util/c2w は単に Unicode code point を幅に
      変換しているだけで、もし出力が UTF-8 に対応していないのだったらそもそも
      Unicode code point が生成されないという前提になっている。うーん。対応して
      いない locale の時にコマンド内容の幅計算が壊れるのは何故だろう? 代替表示
      が有効になっているのであればその代替表示の幅が使われるのではないのか? 不
      思議だ。

      ? ok: 問題を簡単に再現しようと思って、単に LANG=C として日本語を入力する
        と入力内容が \u3042 などの表現に置換されてしまい、問題は発生しない。何
        故?

        うーん。M-^A 等の代替表現が現れるのはどういう状況か?  locale 変数が
        UTF-8 等で終わっている事によって、bash も UTF-8 に対応していると勘違い
        して printf が UTF-8 表現を出力する → コマンドラインに UTF-8 bytes が
        raw characters として挿入される → 配置計算で問題を生じるという事。

        LANG=C 等の様に explicit に non UTF-8 の場合には bash printf の時点で
        \u3042 等の様な文字列に変換されるので、実際のコマンドラインには表現でき
        ない文字列は挿入されず、結果として問題が見えないという事。

      * reject: ble/canvas/trace etc の幅調整

        また、vim mode indicator の "-- 挿入 --" の幅計算に失敗している問題につ
        いても、単に locale を C として計算すれば良い訳ではない。これは
        ble/canvas/trace が byte 事に処理を行って幅を決定しているが、utf8 に現
        在の環境が対応していないという事が分かったとしても、どうしようもない。
        実際の端末が utf8 に対応しているのかしていないのか分からない。端末が
        utf8 を処理すると勝手に期待して、出力内容を変更する訳には行かない。結局
        端末にはそのまま元の文字列を送るしかないし、一方で手元の幅計算では現在
        指定された locale に基づいて幅を計算するしかない。事前の
        char_width_mode=auto の結果によって端末が Unicode に対応しているという
        事が分かっていたとしても、現在の locale が UTF-8 を正しく処理できないと
        いう状況で ble/canvas/trace が正しく動作する様に調整するのは困難である。

        或いは現在の locale が壊れている場合には ble/canvas/trace の実装を切り
        替えて LC_CTYPE=C で時前で decode も行いながら処理を行う様にする? 然し
        それはやりすぎであるし、処理がもっと複雑になる。

        結局システムが UTF-8 locale に対応していないとしても端末の側で UTF-8 に
        対応しているかしていないか分からないので、結局正しい幅計算は不可能であ
        る。端末の振る舞いと locale が一致していないという事なので ble.sh の責
        任ではない。これは対応しなくて良い。

      つまり問題はコマンドライン文字列に UTF-8 文字が含まれているが、システムが
      正しくそれを扱えない時に何が起こるのかという事。うーん。或いは、C1 に属す
      る文字に関してはちゃんと代替表現になっているが、それ以外の文字については
      生で文字が出力される事によって文字幅のずれが起こっているという事? 実際 "
      あ" は 3 bytes からなるが端末上の表示では M-^A などの代替表現二つ分子しか
      見えていない。つまり、最初の byte がスキップされて問題になっていた?

      →実際に振る舞いを確認してみたらそうだった。"あ" の最初の文字は直接表示さ
      れて、然しそれが端末によって無視されていたのでカーソル位置計算がずれてい
      たのだった。

      この様な場合にはどうすれば良いのだろうか。例えば、c2s に於いて \u3042 等
      を出力する様に変更する? 既に非 unicode 時には \u3042 等に変換しているとい
      う事を考えるとこれが正しい実装の気がする。

      と思ったが現状の ble/util/c2s.impl の実装では手動で \u3042 等の表現に切り
      替えている訳ではなくて、bash の builtin printf が勝手に \u3042 等の表現を
      出力するのに任せている。今、bash の builtin printf とは別に実装を切り替え
      る様にしようとすると、毎回値についてチェックしなければならなくなり処理が
      遅くなる原因である。とはいえ、結局 ble/util/c2s の結果はキャッシュされて
      いるので余り気にしても仕方がないのかもしれない。

      * うーん Linux で LANG=alpha.UTF-8 等適当な物にしてみたが、その場合にはちゃ
        んと bash builtin printf は \u3042 という文字列を出力してくれる。Cygwin
        でもちゃんと \u3042 になる (というかそもそも Cygwin では変な locale 文
        字列を指定した時には自動的に C に fallback している?)。つまり、これは
        WSL 特有の問題だろうか?

        となると対策は wsl の時にだけ考えれば良い?

    取り敢えず ble-attach 時に locale のチェックを行う事にした。また、WSL では
    locale が壊れている時に、明示的に \uXXXX 及び \UXXXXXXXX を c2s.impl で生成
    する様に振る舞いを上書きする事にした。

    2024-09-23 実際に WSL で試してみたが workaround が動いていない。

    x fixed: そもそも ble/function#advice が設定されていない。と思ったら
      ble/base/is-wsl で WSL をチェックするべき所で ble/util/is-wsl を呼び出し
      ていた。修正する。

    x fixed: 然し、実際に WSL の上で試すとこれでも動く様にならない。advice は今
      度はちゃんと設置されている。と思ったら advice の中では元々の引数は
      ADVICE_WORDS から参照する必要があったのだった。元の ble/function#advice
      の実装を確認したら無引数で関数を呼び出していたので、引数をつけて呼び出す
      様に変更する事にした。これで "$1" でも "${ADVICE_WORDS[1]}" でも引数にア
      クセスする事ができる。

    x fixed: 更に、初回の _ble_util_locale_broken が正しく更新されていない。
      triple はちゃんと設定されている。うーん。何と初期化中は変な locale が設定
      されていたとしてもちゃんと動いてしまう? うーん。不思議だ。LC_CTYPE を明示
      的に設定してもちゃんと動いている。一旦別の LANG に設定してから再び現在の
      LANG に設定し直すと問題が発生する様になる → 明示的に LANG を設定して
      locale をテストする事にした。

    * done: 後気づいたのは、別に壊れた locale にしたとしても必ずしも bash がエ
      ラーメッセージを出力するとは限らないという事。やはり ble.sh も自前で警告
      を出力するべきである。

    x fixed: テストが失敗している。色々の locale 文字列の解釈のテストだったが、
      存在していない物も含めて色々テストしているのがいけなかった。locale が正し
      く動作しているか確認する関数を push で上書きする事にした。

    x fixed: 一気に文字を入力すると結局文字化けしてしまう。うーん。一気に
      Unicode 文字を複数入力した場合には c2s を使わずに挿入されてしまうのだろう
      か? 或いは、受信の時点で壊れているのだろうか? → 受信の時点ではちゃんと正
      しい code points になっている → これは ble/util/chars2s.impl も上書きし
      なければならないのだった。

    今度はちゃんと実際の WSL の上で動作を確認した。

  * complete: generate command names in background with slow WSL2 PATHs (contributed by musou1500) [#D2280]
    https://github.com/akinomyoga/ble.sh/pull/504

    WSL2 で PATH に /mnt/* が含まれている時はコマンド名の生成には
    ble/util/conditional-sync を用いる事にした。

    後 no_empty_cmd_completion は今まで Cygwin における cyg* や x86* に対しても
    適用していたが、元のオプションの意味通りに本当に空の時にのみ補完抑制する様
    に変更する運びとなった。

    * done: https://github.com/akinomyoga/ble.sh/issues/96 のコメントに
      workaround が追加された事について返信する。

  * decode (ble-decode-key/bind): reference the argument to check the widget name (contributed by musou1500) [#D2279]
    https://github.com/akinomyoga/ble.sh/issues/505
    https://github.com/akinomyoga/ble.sh/pull/506

    ble-bind で存在しない widget を指定した時のエラーメッセージで、余分な
    "ble/widget/" を指定した場合の検出で存在しない変数名 command を参照している。
    これはこのチェックを導入した時からずっとその様になっている。と思ったが、何
    故かチェックはちゃんと動いている。と思ったら、外側で定義されている変数名を
    参照していたので動いている様に見えていたが、コードコメントを見る限りはこれ
    は意図した実装ではないだろう。

  * 2024-09-13 complete: failglob があっても glob expansion に基づいた auto-complete が実行されない (reported by mcepl) [#D2278]
    https://github.com/akinomyoga/ble.sh/discussions/498

    またコマンド名についても途中のディレクトリ名に glob pattern があった時に続
    けて補完できない。

    nullglob に対する振る舞いはもっと考えるべき。

    * cd のディレクトリ名の補完候補生成については ble/complete/source:file が担っ
      ている。そして、この関数では
      ble/complete/source:file/.construct-pathname-pattern "$COMPV" を用いてパ
      ターンを生成している。この時の "$COMPV" のパターンはどの様になっているだ
      ろうか。

      →うーん。'*python3'* の様になっている。つまり、pathname expansions は処
      理されない。では何故ちゃんと動いている様に見えるのか。曖昧補完の場合にも
      試してみたがその場合でも '*' という具合に quote されている。

      と思ったが COMPV の時点で既に展開済みの値が渡されている。うーん。何故これ
      で動く? と思ったが単に COMPV= としているから現在ディレクトリの中にある全
      てのファイルが列挙されて、結果として候補を生成できている様に見えただけだっ
      た。また遡った書き換えが起こった理由もこれで分かる。

      ble/complete/candidates/.pick-nearest-sources で eval-simple-word を呼ん
      でいるが、この時点で * を suffix した物を試しても良いのではないか? ただし
      その場合に一致した文字列から元々あった単語に対応する部分を除去する必要が
      ある。これは単純に ${result#$pattern} で特定できるだろうか?


2024-08-29

  * util(ble-import): -C 'if ... fi' を指定すると文法エラーになる [#D2277]

    確認してみると callback は最終的に配列に登録して ble/util/invoke-hook を用
    いて呼び出しているが、この ble/util/invoke-hook が末尾に "${@:2}" を指定し
    て eval しようとしている。確認してみた所、現在、ble/util/invoke-hook の呼び
    出し元で引数を指定しているものは存在しない。従って "${@:2}" はそもそも削除
    してしまって良い。

2024-08-28

  * edit: PROMPT_COMMAND で BLE_PIPESTATUS を参照したい (requested by mattmc3) [#D2276]
    https://github.com/akinomyoga/ble.sh/issues/492

    取り敢えず実装した。というか実行箇所のコードは何れもほぼ同じなので関数にま
    とめるのが良い。また色々の調整も含めて全体を一つの eval の中に入れないと都
    合が悪い事も分かった。

    * ok: DEBUG trap に対する処置が正しく動くのか分からない。実験する必要がある。
      うーん。分からないがそもそも色々とコマンドのパターンが変化していて動かな
      くなっていた。修正したら動く様になった。 exec_restore_pipestatus=1 にして
      もダミーコマンドが出力されるという事もない。何故? subshell だから? 分から
      ないが取り敢えず良い事にする。

  * ble-reload 時に --bash-debug-version=... の設定が保持されない [#D2275]

    最初の source 時に指定したものを保持する様にしてみたが、よく考えてみれば再
    表示する必要はあるだろうか? そもそも一回だけ表示すれば良い物だけれども、も
    う一度出したら良いか分からなくなると困るという意味で起動時に表示する様にし
    ていた。定期的に出す様にしたいが頻度はできるだけ低くしたかったのだ。という
    事を考えると実は ble-reload の時には完全に suppress するという事で良い気が
    する。

  * color: Gogh なる framework から theme のデータベースを導入する (motivated by d4rkb4sh8) [#D2274]
    https://github.com/akinomyoga/blesh-contrib/issues/23

    * スペースを含む名前が指定された場合はスペースは削除して解釈する。

    番号についての返答があった。よく分からないが各ユーザーごとに生成されるデー
    タベースの中の番号ということだろうか。Gogh profiles なる物をコマンド経由で
    取得できたりするのだろうか。謎である。改めて Gogh のページを見るとデモ gif
    動画の中で実はその一覧が表示されていた。デモだと 40 項目しか表示されていな
    い。然しデータベースには全部で 320 余りある。どういう事か。何らかの規則によっ
    て動的に変化するという事だろうか。

    番号で指定できる事に対してどんな意味があるのかと思ったが、もしかすると gogh
    を実行して番号を見て、その番号を指定したいという事なのかもしれない。然しそ
    もそも別のプログラムなので、それを期待されても困る。

    x そもそも、こちらには別のデータベースから取得した palette も沢山存在してい
      るので、gogh に含まれていない palettes の番号はどうするのかという問題が生
      じる。或いは、gogh に欠けている theme を無理やり取り込んでもらうという可
      能性もある? 然し、それでも未だ問題はある。

      同名だけれど色の配置が微妙に異なる palette をどうするのかという問題。

      一旦 gogh と同期を取ったとしても gogh に新しい palette が追加される等して
      番号が変化した時に番号がずれるのはどうしたら良いのかという事。

      d4rkb4sh8 はごにょごにょと意味不明な事を言っているが自分が request した事
      が既に実現されているから、何か恰も新しい提案をしたような雰囲気を作ろうと
      して誤魔化しているだけだろう。

    * done: 空白を含む名前を指定しても空白を除去して対応する theme を検索する。

    * done: iTerm2-Color-Schemes の変換についても color.sample.sh の subcommand
      にする。これは元々 colorglass.bash の中に
      ble/contrib/colorglass/extract-base16-palette-from-iTerm2-Color-Schemes
      として記録していたが分かりにくいので make/color.sample.sh に移動する。

    * done: 前景色と背景色及びカーソル色も colorglass.base16.dat に入れる? 既存
      のデータベースはこれらも一部として持っている。

    * done: 色サンプルで背景色・前景色を使う?

  * highlight(vartype): ${var?...} をエラー着色にする可能性 [#D2273]

    そもそもコマンドラインで使うかどうかは分からないが、他のエラーで停止する機
    能については色で知らせているのにこれは知らせないというのも変な気がするので
    対応する。

  * highlight(vartype): add "ble-face variable_new" [#D2272]

    varname_unset の色は変更したがやはり微妙かもしれない変数を代入する機会は多
    くあるが大体変数は設定されていない。という事を考えると、存在しない変数を灰
    色にするという機能は大体の代入における変数を灰色に表示するという事になる。
    微妙。或いは代入の右辺にある時だけは存在しない変数に対しては "新しい変数"
    を意味する色で着色する?

    varname_new という物を作ってみる? 呼び出し元の文脈で unset を new に置き換
    えれば良い。

    * done: global の状態を取得するかどうかという事を考えていたが、よく見てみる
      と glbal の状態を復元する試みが実は外側で実行されている。これは
      ble/variable#load-user-staet に統合するべきなのでは → 統合した。

  * gexec: 中で source ble.sh --attach=attach を実行すると stderr が失われる (reported by JohEngstrom) [#D2271]
    https://github.com/akinomyoga/ble.sh/discussions/491

    これは ble-attach を強制的に実行した直後は redirect されていて、而もその後
    でその redirect された状態が以前の ble.sh session が保存してしまうからであ
    る。うーん。stdout.off になっている時には保存しない様にするべき? 既に保存し
    ている筈だから。と思ったが、stdout.on か stdout.off かは idempotent になっ
    ていて、現在の状態は特に記録していない。

    x ok:然し変だ。5 から stderr をコピーしている筈なのに何故 redirect された
      stderr が保存されているのだろうか。と思ったがこれは OK。4 5 の redirect
      はユーザーコマンドの実行全体を囲んで行われた物ではなく
      て、_ble_edit_exec_gexec__save_lastarg の呼び出し限定の物なので、4, 5 に
      実際に user space で設定した fd が含まれている。

    2024-08-29 直したと思ったが改めて見てみたら直っていない。というか条件が反転
    している。後 EOF 云々というメッセージがまだ出ている。疑問は途中で session
    を reload した時に EXIT, ERR などの一連の処理を実行するべきかどうかという事
    である。うーん。汚いが失敗した時は ble-import 決め打ちという事にして後の処
    理をキャンセルするべきか。

  * [OK] util(bleopt): BASH_REMATCH が上書きされている。 [#D2270]

    ble.sh --norc では再現しない。上書きされている時の値を見ると

    'prompt_screen_title=\${SCREEN_WINDOW_TITLE}\${SCREEN_WINDOW_TITLE:+ }[\\h] \\j \\q{mshex/screen-pwd}'

    に対して一致が試みられている。うーん。prompt 評価の途中の BASH_REMATCH が記
    録されている? 然し何故? と思ったが別に上書きされている訳ではない様だ。どう
    も bashrc の中で設定した bleopt に於いて BASH_REMATCH が上書きされている?

    bleopt/.read-arguments の中で使われている。これは微妙。そもそも bleopt を
    .blerc の中で呼び出している限りは問題なかった筈である。外側で呼び出している
    のがいけない。然し一方で ble.sh があってもなくても動く設定を作ろうと思った
    ら必然的に ~/.bashrc の中で直接 bleopt を呼び出す事になるのではないか?

  * syntax: $_ が書き換わっている [#D2269]
    Ref: #D2267

    これは #D2267 で導入されたバグである。

    "$_ble_bash_POSIXLY_CORRECT_adjust" の内容が $_ になっている。何処で設定さ
    れているだろうか。うーん。記録自体はちゃんとできている様に見える。問題は復
    元の方にあると思われる。と思ったが、_ble_edit_exec_lastarg の中身を出力して
    みると実際に置き換わってしまっている。何故?

    うーん。bash-5.3 以上で .ble::function#lambda::0 を通して
    attach-from-PROMPT_COMMAND を呼び出す様にしたが、それがいけない。

    x 先ず .ble::function#lambda::0 経由にすると attach-from-PROMPT_COMMAND が
      削除されない。

    x 呼び出された時に $? と $_ が正しく伝播できていない。また、同様の問題が
      bash < 5.1 で既に PROMPT_COMMAND が設定されていた時にも存在する。

    ble::function#lambda 経由で呼び出すのではなくて関数自体をコピーして実行する
    事にした。

    * $_ と $? も vartype の特別扱いの対象とする。特に $_ の着色で前の結果が空
      文字列である事が判定できたら良い。

2024-08-25

  * syntax: FUNCNEST 等待避している変数の存在が構文着色から見えない [#D2268]
    Ref: #D2267

    #D2267 のテスト中に気になった事。

    print-global-definitions から見えないという事か。何故? と思ったが builtin
    unset しているのだから当然の事である。print-global-definitions に於いて待
    避している変数の復元も実行する必要があるだろうか?

    既に何らかの変数について対策しているのではないか? と思ったが分からない。
    確認する。うーん。別に復元はしていない気がする。というか抑々 FUNCNEST だ
    とか POSIXLY_CORRECT だとか危険な変数を復元したら変な事が起こるので不用意
    に復元できない。

    また、確認してみると変数の構文着色では別に print-global-definitions で変
    数の値を復元している訳ではない。

    * _ble_local_predicate_cmd が leak している。修正した。これは 0.3 にも存在
      する leak の様なので別 commit にする。と思ったがこの対応自体を独立した項
      目にする事にしたのでやはり別 commit にしなくても良い。

    新しく ble/variable#load-user-state という関数を用意して、更に待避を行っ
    ている変数について個別に特殊化関数で対応する事にした。動いている。

    うーん。これは varname_unset の色変更 commit の方で対応するべきでは? と思っ
    たが varname_unset の commit は一連の色変更の commit の追加修正として取り扱
    いたい。この変更は独立している気がするので項目は分ける事にする。

  * main: bash-5.3 -o posix で --atatch=prompt に失敗する [#D2267]
    Ref: #D2268, #D2269

    prompt-attach に失敗する。ble-attach を明示的に呼び出した時は問題ない。set
    -o posix の状態管理を再確認する。

    取り敢えず修正した。テストする。

    * fixed: 実は FUNCNEST の方もちゃんと調整が必要なのでは? 修正した。試して見
      るとちゃんと動いている。FUNCNEST=0 でも FUNCNEST=1 でもちゃんと動く。

      そもそも修正が必要だったのか? よく考えたら動かないという事を確認した訳で
      もない → 試してみたら修正前は FUNCNEST=1 などと指定したら動かなかった。
      なのでやはり修正は必要で、実際に今回の修正で動く様になっている。

    ? ok: POSIXLY_CORRECT 及び FUNCNEST の処理では普通に unset -v
      POSIXLY_CORRECT や unset -v FUNCNEST を呼び出しているが、途中でローカル変
      数として定義されている場合はどうなるのか。変数を消去してしまって問題にな
      るのでは? と思ったが、基本的には ble.sh の内部処理は ble.sh 自身の関数呼
      び出しツリーの中で実行されるので POSIXLY_CORRECT 及び FUNCNEST が local
      に設定されている事はない。

      然し様々の ble-face 等のユーザーから呼び出す事を想定している関数について
      は下手をするとユーザーの設定した local POSIXLY_CORRECT を消去する事になる
      のでは? shopt -s localvar_unset を一時的に設定する等して対処した方が良い
      だろうか。然し、それはそれで処理が長くなるし最近の bash でしかできない対
      策になる。気にしない事にする。或いは Limitations にその事を記述する? 然し、
      或る程度は動く様に対策しているという事も含めて書かなければならないので面
      倒である。

    * set -o posix のテストが失敗している @ bash-5.3 → これは単にテストケース
      自体が間違っていた。5.3 以上とそれ以外で分岐しているのにも拘らず、両方と
      も全く同じテスト要件になっていた。期待する終了ステータスが同じになってい
      た。修正した。

  * [OK] canvas: Cygwin 上で char_width_mode test の [xx] の表示が最新版でも見える。何故? [#D2266]

    _ble_term_invis で見えない様にした筈なのに。term_synchronized_update_mode
    は無効になっているので強制的に描画が発生している訳ではない → どうやら
    screen は invis に対応していない様だ。

    またテストが発生する位置は右端にしたのではなかったか? と思ったが右側でテス
    トを行うのは、画面の右上であって更に ble.sh の初期化が終わった後に使われる
    方法だった。そもそも初期化時点では COLUMNS が正しく設定されているかも分から
    ないので右端を使うのは避けていたという事の気がする。

    ? ok: 所で COLUMNS が空の時に 80 と想定して画面の「右上」で処理を行っている
      がこれは問題では。実際にはもっと画面を広くしている可能性もあるし、その時
      に画面の最初の行の途中の文字が消えてしまう事になる。

      % COLUMNS が空なら現在行を用いるべきでは? と思ったが、逆に現在行を用いる
      % と ble.sh の表示している UI と干渉する可能性がある。つまり、最初の行を
      % 使っていたのは、現在行を安全に使えないこと、また、その行が vbell によっ
      % て予約されている行だったから自由に使える事ができたというだけの事である。

  * edit: bash-3.2 がまた動かなくなっている [#D2265]
    Ref: #D2228, #D2217

    https://github.com/akinomyoga/ble.sh/issues/489 の報告を受けてから bash-3.2
    の動作を確認していて気付いた。然し、何故報告者はこの振る舞いについて報告し
    ていなくて代わりにどうでも良い事を報告しているのだろう。一つの可能性は少し
    使っただけで実際には ble.sh を使っていない? 或いは実は bash-3.2 ではなくて
    もっと新しい bash を使っている? 或いは何らかの理由で bash-3.2 でもちゃんと
    動く状況が存在する? よく分からない。

    ble/util/idle.cancel を使おうとしてエラーが発生している。また終了時に
    return に空引数が渡されてエラーメッセージが発生している。C-d で終了できない。

    * ble/uti/idle.cancel に関しては新しい visible-bell の実装がコマンド実行直
      前に visible-bell の表示を消去する時に無条件に呼び出している。
      ble/util/idle.push が有効の時にのみ ble/util/idle.cancel を呼び出す。

    * C-d で終了できないのは、bash-3.2 では C-d の受信を trap USR1 経由で行って
      いて、しかし ble/util/exit は trap 内部での実行を制限しているからだった。
      受信に使っている USR1 の場合には ble/builtin/exit の trap の特別取り扱い
      はしない様に修正する。

    * return にから引数が渡されてエラーになる問題は trap 処理の修正をしたら消え
      てなくなった。ble.sh の unload 処理をした後も処理が続行していたのが問題だっ
      たのかもしれない。

  * README: ble-attach の条件を [[ ! ${BLE_VERSION-} ]] || ble-attach に変更 [#D2264]

    現在の方法 [[ ${BLE_VERSION-} ]] && ble-attach だと ble.sh をロードしていな
    い時の最初のステータスが失敗になる。特にプロンプトで最後の終了ステータスを
    表示する物では最初のステータスが失敗になるのは変である。他の方法として if
    [[ ${BLE_VERSION-} ]]; then ble-attach; fi と記述させる手もあるが、長いしこ
    の様に指示すると [[ ${BLE_VERSION-} ]] && ble-attach に縮めてしまう人もいる
    気がするので、明示的に短い版を提示するのが良い。

    その他の色々の README の指示も含める事にする。

  * color: 変数の色が分かりにくい。unset 変数の色と値を持つ変数の色が近すぎる [#D2263]
    Ref: #D2248, #D2258

    色々試したが見られる色は全て orange に近い。あるいは灰色にする? 245 辺りで
    良いのでは? 他にも意味を考えて再調整が必要な face はあるだろうか。見た感じ
    は他は大丈夫そうな気がする。後で気づいたらその都度修正する

2024-08-24

  * progcomp: var= でエラーメッセージが発生する (reported by blackteahamburger) [#D2262]
    https://github.com/akinomyoga/ble.sh/issues/487
    Ref: regression by #D2257

    complete -I の時にも comp_words=() comp_cword=-1 を指定していたがこれが駄目
    だった。変数代入 var= の時にはコマンドラインが空でなくても complete -I が発
    生して extract-command が失敗する可能性がある。

    では bash では var= に対して complete -I の補完はどの様に振る舞うのだろうか。
    と思ったがそもそも var= が入力されている時点で complete -I が呼び出される事
    はない。ble.sh の拡張で任意のコマンド名補完に対して complete -I を有効にし
    ているからこそ発生する問題である。

    ? ok: 逆に言えばそもそも任意のコマンドの補完の文脈で complete -I を試みる事
      は良いのか? 本当のコマンド名の補完の場所で試すのは良いが、例えば type
      command[TAB] の様な箇所での補完では complete -I は使うべきではない。と思っ
      たがそもそも type command[TAB] の様な状況では source:command は使われない
      ので気にしなくて良い。考えてみれば source:command は ble.sh の
      core-syntax から生成される物であり、core-syntax は文脈に従ってコマンドが
      現れる場所でしか基本的に source:command を指定しないので、基本的に
      source:command では complete -I の補完を試みるという事で妥当の気がする。

    ? ok: 何故 var= [TAB] の位置ではなくて var=[tab] の位置でコマンド補完が発生
      しているのだろうか。check-here だとしたら prefix の幅は 0 になる筈では?
      うーん。check-prefix で呼び出されている。然し chek-prefix は前回の解析開
      始点を基準にしているので "var=" の直前の位置における補完としてコマンド名
      も一緒に生成しているのである。なのでこれは OK

    ? ok: 何故 COMP2 COMP1 が 0 なのに COMPV が有限になっているのだろうか。と思っ
      たが、どうやら曖昧補完の処理として COMP2 を COMP1 で上書きしている様だ。
      COMP1 が 0 の時には COMP1 は空文字列になるみたいだが、これは問題ない。

    色々考えたが $COMPV が有限なのに extract-command に失敗するという状況は既に
    その単語がコマンド名ではない事を意味していて complete -I の対象ではない事を
    意味している様に思われる。もし $COMPV が有限で対象だったら extract-command
    が失敗する筈はない為である。

  * edit: display-shell-version に SHELLOPTS, BASHOPTS も含めるべき? [#D2261]

    追加した。diff が使える時は diff を使って既定のオプションと異なる物だけを指
    定する。

    2024-08-24 変数 diff について local するのを忘れていた。

2024-08-23

  * make: make variable "USE_DOC=no" (requested by blackteahamburger) [#D2260]
    https://github.com/akinomyoga/ble.sh/issues/485

    取り敢えず実装した。USE_DOC=no で指定できる。最初は INSDIR_DOC=none 等を指
    定した時に無効化できるようにしようと思ったが、それだと make install だけし
    か影響を受けない機能のようだし、やはり任意の値を指定できるはずのパス名の設
    定に特別な値を導入するのは良くない気がする。なので、USE_DOC という変数名に
    する事にする。

    * done: README をもう少し詳しく記述する。
    * done: README-ja_JP も同様に更新する。

    * fixed: INSDIR_LICENSE と INSDIR_DOC が同じ場合の対策はしているが、それら
      が INSDIR と一致する場合の対策がされていない気がする。修正する。

    2024-08-24 make install が動かない (reported by Jai-JAP)
    https://aur.archlinux.org/packages/blesh-git
    $(INSDIR_LICENSE)/% に対するルールを独立に定義するかどうかの条件が反転して
    いた。修正する。

    2024-08-24 USE_DOC=doc で licence を INSDIR と同じ場所に入れる (requested by blackteahamburger)
    https://github.com/akinomyoga/ble.sh/issues/485#issuecomment-2308148791
    うーん。既にインストール先決定が複雑になっていてもっと複雑化して大丈夫なの
    か。ユーザー的には色々のオプションを設定した結果としてどうなるのかが予測不
    能になるのではないか。それだったら明示的に指定する様にするべきなのではない
    か。

    2024-09-22 返事はもうないみたいなので現在の make branch の内容で master に
    merge する事にする。

  * contrib: fzf-menu 修正 (reported by pallaswept) [#D2259]
    https://github.com/akinomyoga/ble.sh/issues/479#issuecomment-2305871596
    Ref: #D2251

    実は動かなくなっていた。起動だけ確認して C-c でキャンセルしていたので気づか
    なかった。他にも追加の微調整をする。

  * color: 配色再調整 - 背景色・前景色を両方指定している場合も駄目の様だ [#D2258]
    https://github.com/akinomyoga/ble.sh/issues/478#issuecomment-2304712451
    Ref: #D2248

    改めてサンプルを見てみると明るい背景の上に暗い文字を描画している物が見えな
    い。もしくは、くらい背景の上に白文字を描画している物が見えない。base16 はこ
    ういう意味でも信用できないという事。結局、(黒 vs 他の色) の組み合わせしかちゃ
    んと読めることが保証されないという事になるのだろう。もっと言うと青や紫に関
    しては黒と組み合わせた場合でも読めるように表示できるか分からない。前景色だ
    けを指定している時には、navy,purple,lime,cyan,white,black,silver,gray は避
    ける。前景色と背景色を療法指定する時はどちらか一方が黒になる様にするか、そ
    うでなければ両方とも 256 index colors (>= 16) を指定するべき。

    ? fg=0 なる指定が airline の 3 themes だけで生成されている。その他の base16
      については使われていない。これは何か? 最近の更新で新しく混入したのかもし
      れないと思ったがそうでもなかった。昔からあるようだ。

      ./contrib/airline/distinguished.bash:19:  ble-face -s vim_airline_a_normal_modified            fg=0,bg=166   # fg=0,bg=#d75f00
      ./contrib/airline/distinguished.bash:31:  ble-face -s vim_airline_z_normal_modified            fg=0,bg=166   # fg=0,bg=#d75f00
      ./contrib/airline/papercolor.bash:15:  ble-face -s vim_airline_b_visual                     fg=0,bg=31    # fg=0,bg=#0087af
      ./contrib/airline/supernova.bash:17:  ble-face -s vim_airline_b_visual                     fg=0,bg=240   # fg=0,bg=#585858

      vim からの抽出結果は以下の様になっている (supernova の場合)。

        face visual airline_b '' '#585858' '' '240'

      空欄になっている様である。240 や #585858 は既に暗い色なのでこれを fg=0 に
      してしまうと文字が読めない。その他の theme についても同様である。空欄は白
      に mapping するのが良い気がする。

      更に bg=0 も沢山登場するようだ。こちらに関しては黒という事にしておかない
      と文字が見えなくなる。

      更に更に fg=-1 や bg=-1 等という物も本当にこのままで良いのか怪しい。試し
      に確認してみた所、文字が読めない様な設定が実は普通にある。

      fg=0 bg=0 (元々 '') や fg=-1 bg=-1 (元々 'NONE') について全て一括で既定職
      を割り当てることにする。微妙な色もあるが、テーマごとの雰囲気等を考える事
      なく全て適当に割り当ててしまう事にする。

  * 2021-08-31 complete: -E (_EmptycmD_) に対応していない [#D2257]
    Ref: #D2262

    一方でこれは一体どの様に振る舞うものとして実装すれば良いのか分からない側面
    がある。文字列が本当に空の時にはこれを使って補間するので良い。

    * ; で区切って未だ何も入力していない状況の時にはどう振る舞うべきか。元の
      bash では本当に空文字列の時にだけ呼び出される様である。また -E の用途とし
      て空の時のコマンド候補を生成するという役割もあるかもしれないが、

      というか改めて考えると ; で区切って未だの時には -I が対応する補完になるの
      ではないか。という事を考えると -E はやはり完全に空の時に対応するのではな
      いだろうか。実際に試してみるのが良い気がする。

      complete -F _initial -I, complete -F _empty -E で試してみると ; の次で呼
      び出した補完の場合には _initial が呼び出される。完全に空の時には _empty
      が呼び出されていて一文字でも入力されていれば _initial が呼び出される。入
      力されているのが空文字列であっても同様である。

    実装するとしたらどの様に実装するべきだろうか。単に空の時には新しく -E で呼
    び出す仕組みを作れば良いのだろうか。

    2024-08-23 改めて確認する

    ? "-E" で複数の候補が生成されて曖昧な場合にはどう振る舞うのだろうか。つまり、
      共通部分だけ挿入された状態になってそれ以降は -I の補完が呼び出されるとい
      う事だろうか。それだと不便の気がするが、実際に試してみるとそういう振る舞
      いになっている (-E, -I を両方定義した時は最初だけ -E の補完が実行されて以
      降は -I が呼び出される。-E だけ定義している場合は最初に -E が呼び出されて
      それ以降は tab を押しても何も起こらない)。或いは -I やその他の補完が -E
      の補完候補に対しても責任を持つという事前提なのだろうか。

    ? また、-E で menu-complete を実行した場合はどうなるのだろうか → この場合
      には -E で生成した候補がちゃんと cycle される。

    ? カーソルが先頭にあって然し文字列が既に入力されている場合には何が呼び出さ
      れるのか → -I が定義されていれば -I が呼び出される。そうでなければ普通の
      コマンド名補完が実行される。

    ? 新しい行に移動して其処で補完を実行したらどうなるか → 引数補完になってい
      る。-E でもなければ -I でもなければコマンド補完でもない。これは変な気がす
      る。

    つまり本当にコマンド行が空の時にのみ実行される補完という事。

2024-08-22

  * simple-word: limit the number of expanded words (motivated by orionalves) [#D2256]
    https://github.com/akinomyoga/ble.sh/issues/482

    ブレース展開で巨大な数を入力するとシステムがクラッシュするという報告。正直
    そんな非現実的な物を入力するのが悪いとしか言いようがない。

    ble/syntax:bash/simple-word/eval について limit=COUNT opts を追加して、構文
    着色の際に実施される単語の展開および補完の為の展開について上限を設ける事に
    した。

    但し、単語数の制限は展開の後に行われるので、必ず一回は大量の単語を生成する
    ことになる。単にその後の処理をできるだけ軽くするだけの事であるが、単語着色
    に関しては response はかなり改善したように思う。取り敢えず単語数の上限は既
    定では 200 という事にする。

    テストに使ったコード:

    | if ((${#__ble_ret[@]}>200)); then
    |   echo "count=${#__ble_ret[@]} opts=($__ble_opts)" >/dev/tty
    |   printf -- '- %s\n' "${FUNCNAME[@]}" >/dev/tty
    |   __ble_ret=("${__ble_ret[@]::200}")
    | fi

  * mandb: sudo などから呼び出されたコマンドオプションに説明がつかない [#D2255]
    https://github.com/akinomyoga/ble.sh/issues/480#issuecomment-2298976015

    * ok: _comp_complete_offset で他の補完を呼び出した時に mandb が親コマンドに登録
      されてしまう?

      % これは _comp_command_offset に介入してその中で呼び出された _parse_help
      % に関しては _comp_complete_offset によって設定されたコマンドに対して実行
      % する様に修正すれば良い。
      %
      % コマンド名については ${COMP_WORDS[offset]} を使えば良いが offset の計算
      % 方法については bash-completion の ver 毎に注意が必要である。COMP_CWORD
      % と offset が同じ場合には特別の処置は要らない。
      %
      % ? ok: _comp_command はどうなっているか? → これは内部で
      %   _comp_command_offset を呼び出しているので _comp_command_offset にだけ
      %   対応すれば OK。
      %
      % ? _command_offset 等の bash-completion 2.11 の関数に対しても同様に適用
      %   する必要がある。但し、処置としては同じで良い筈。と思ったが offset の
      %   内部での決定方法が異なるので注意が必要である。

      ? そもそも実際にそういう問題が起こるのかについて確認しておきたい。然し具
        体的に問題を起こすにはどのようにすればよいか。man が優先されるので普通
        のコマンドでは問題が表面化しない気がする。実際にキャッシュの中の
        _parse_help.d の中身を見に行けば良い。

      →どうも親コマンドではなくてちゃんと実際のコマンドのファイルにキャッシュ
      として保存される様である。なのでこれは問題ではない。実際に実装を見ると
      _parse_help.advice は COMP_WORDS[0] を見ている。そして
      _comp_command_offset は COMP_WORDS を調整するので、COMP_WORDS[0] を見てい
      る限りは問題は起こらない。

    うーん。報告だと候補自体が sudo の物だという様になっているが、実際は生成さ
    れている候補はやはりそのコマンドの物で、単に説明が sudo の物に置き換わって
    いるというだけなのでは? と思ったが改めて見ると入力の順序によって表示される
    内容が変わるなど、それでは説明できない現象が報告されている。うーん。

    取り敢えず現在分かっている問題だけでも修正する。

    * 親コマンドのオプションの mandb の説明が付加される

      うーん。mandb を自分で読み取りつつ処理しようと思ったが
      fitler-and-split-compgen に突っ込めば良いだけでは?

      * ok: 先に処理してしまうと -P prefix や -S suffix などの処理がスキップさ
        れる事になるが問題ないか? うーん。然し、_comp_command_offset は sudo な
        ど、途中から呼び出すコマンド及び引数を受け取る前提のコマンドに対する補
        完である。もし -P prefix や -S suffix などで加工するのが前提だとしたら
        そもそも _comp_command_offset は動かないので気にしなくて良い。一方で -X
        で向こうな単語が指定されている場合にはどうだろうか? これについても親コ
        マンドの complete 設定で子コマンドの補完する語を制限するのは不自然であ
        る。という事を考えると考えなくて良いのではないか。

        更に、bash-completion の _comp_command_offset の実装では complete に一
        緒に指定した別のオプションなどは無視して直接 -F func で指定したコマンド
        を実行しているので余り細かい事を気にしても仕方がないのではないかという
        側面もある。

      * compgen -V 対応も一緒にやってしまうか否か。COMPREPLY は元々配列なので
        compgen -V 対応も一緒にやってしまった方が都合が良いのではないか。もしく
        は compgen -V 対応を実装してから、その実装を呼び出す様にするべきではな
        いのか→やはり先に compgen -V 対応を実行する事にする。

    x fixed: 実装してみたが今度は子コマンドの補完が全く生成されなくなってしまっ
      た。うーん。どうも has-input が true になっている。何故?

      * まずどうやら 0 が /dev/null に繋がっていて、ble/complete/has-input が正
        しく判定できていない様だ。また ble/util/is-stdin-ready は /dev/null に
        対して 0 を返す様で、これもまた予期していなかった事である。これについて
        は ble/util/is-stdin-ready に remarks を残しておく事にする。

        →これは ble/util/is-stdin-ready の実装の仕方も含めて別項目で考え直す事
        にする。

      redirection を修正したらちゃんと子コマンドの補完について、desc についても
      ちゃんと動く様になった。今の所壊れる気配はない。

    * done: ble/util/is-stdin-ready を調整するのであれば redirection はキャンセ
      ルする。

    * ok: mandb の為に _comp_command_offset で処理するのはオプションだけにする?
      と思ったが、処理的に複雑になってしまうのでやはりそのままにする事にする。
      filter-and-split で既に様々の処理を実行しているので後で残った物だけ抽出す
      るというのも変である。

    * done: bash-completion に対する対策の部分は contrib/integration に移動して
      も良いのではないか。

  * ble/util/is-stdin-ready で直接 _ble_util_fd_tui_stdin から読み取る? [#D2254]

    うーん。或いは is-stdin-ready で常に tui から読み出す様に変更するべきだ
    ろうか。

    ? "-u fd vs <&fd": redirection はコストが明らかにある。一方で引数解析に対し
      てもコストはある気がするが、syscall よりは流石に軽いだろうと思いたい (或
      いは malloc で syscall 迄行くという可能性もあるが)。うーん。これは後で
      benchmark すれば良い。

      うーん。計測してみた所普通に redirection した方が速い。では -u は何の為に
      あるのだろうか。よく分からないが <&fd の形式を使う事にする。

    ? ble/util/is-stdin-ready を別の目的で使っている箇所はあるだろうか。つまり、
      "現在の stdin" に入力があるかどうかを確認するのに使っている箇所。tes全ての現れる箇所について確認する。

      * lib/test-* については気にしなくて良いだろう。と思ったが、テストの為に
        stdin が置き換えられるという事を仮定している。うーん。これは
        _ble_util_fd_tui_stdin を上書きする事で対処する事にした

        % → やはり引数に fd を受け取る様に修正する事にした。何も指定しない時は
        % _ble_util_fd_tui_stdin を使う。と思ったが、ble/util/is-stdin-ready の
        % 第一引数は既に poll できない場合の既定の exit status として使われてい
        % るのだった。

        既存の ble/util/is-stdin-ready の引数は一箇所でしか使っていない。やはり、
        引数の意味を変える事にする。

      * ./lib/keymap.vi.sh:1195:  if ((depth>=bleopt_keymap_vi_macro_depth)) || ble/util/is-stdin-ready; then
        これは ble/widget/vi_nmap/play-register.hook の中で停止条件を定める物。

      * ./src/decode.sh: 以下の関数の実装で ble/util/is-stdin-ready を使っている

        ble/decode/wait-input

          ./src/decode.sh:1320:    ble/decode/wait-input 5 char || ent=${ent%_}
          ./src/decode.sh:2146:        ble/decode/wait-input "$timeout" || node_type=1

          これらは ble-decode-char の処理で使っている。ユーザー入力の処理なので
          基本的にやはり tui stdin で良い。

        ble/decode/has-input-for-char
        ble/decode/has-input
        ble/decode/has-input-char

          ./lib/core-syntax.sh:1429:      ble/decode/has-input && return 148

          これは simple-word/eval によるチェックである。まあ、tui stdin を見
          に行く動作で妥当だろう。

          ./src/decode.sh:866:  ble/decode/has-input || ble-decode-key/batch/flush
          ./src/decode.sh:1191:      if [[ ! $ble_decode_char_sync ]] && ble/decode/has-input-for-char; then
          ./src/decode.sh:2144:      if (($#==0)) && ! ble/decode/has-input; then
          ./src/decode.sh:2194:    if ! ble/decode/has-input || ((${#_ble_decode_key_batch[@]}>=50)); then
          ./src/decode.sh:2264:      if ble/decode/has-input && builtin eval "[[ \${${dicthead}[_ble_decode_KCODE_BATCH_CHAR]-} ]]"; then

          これは全てユーザー入力の処理関連なのでok

          ./src/edit.sh:7995:  [[ $_ble_edit_str ]] && ble/decode/has-input &&

          これは accept_line_threshold の為のチェック @
          ble-edit/is-single-complete-line。これも tui stdin で良い。

          ./src/edit.sh:11310:    if ble/decode/has-input && ! ble-edit/exec/has-pending-commands; then

          これは ble-decode/EPILOGUE で描画をスキップする為の物。これもユーザー
          入力の関係なので tui stdin で良い。

          ./src/history.sh:2219:      if ((has_stop_check&&isearch_time%isearch_block==0)) && ble/decode/has-input; then
          ./src/history.sh:2270:          ble/decode/has-input && return 148

          これは履歴検索関係。これもまあ tui stdin で良いだろう。現在の所
          ble.sh tui 以外から使う事がある様には思われない。

          ./src/util.sh:4450:  local __ble_continue=${2:-'! ble/decode/has-input'}

          これは ble/util/conditional-sync の既定の条件である。うーん。まあ、そ
          の時の stdin を使いたい場合は ble/util/is-stdin-ready を使う筈で、
          ble/decode/has-input を用いて decode 経由でアクセスしている時点で tui
          stdin を介した確認になっている筈なので、これも tui stdin で良いだろう。
          そういう意味で考えると ble/decode/has-input の呼び出し元をチェックす
          る意味は余りなかったかもしれない。

          ./lib/core-complete.sh:94:    ble/decode/has-input
          ./lib/core-complete.sh:1233:  [[ :$comp_type: != *:sync:* ]] && ble/decode/has-input

          これらは以下の関数の呼び出しである。

          ble/complete/menu#check-cancel

            /lib/core-complete.sh:206:    ble/complete/menu#check-cancel && return 148
            /lib/core-complete.sh:271:    ble/complete/menu#check-cancel && return 148
            /lib/core-complete.sh:338:    ble/complete/menu#check-cancel && return 148
            /lib/core-complete.sh:403:    ble/complete/menu#check-cancel && return 148
            /lib/core-complete.sh:492:      ble/complete/menu#check-cancel && return 148
            /lib/core-complete.sh:510:      ble/complete/menu#check-cancel && return 148

            ble/complete/menu-style:XXX/construct の処理の中断条件で使われてい
            る。微妙だけれどやはり ble/decode 経由の時点で tui stdin で良いだろ
            う。

          ble/complete/check-cancel

            これの呼び出し元はたくさんあるが、やはりこれも tui stdin でOK。補完
            は特に ble.sh tui でしか発生しない (read を使った時にどうなるかは分
            からないが)。

            ./lib/core-complete.sh:1720:    '! ble/complete/check-cancel <&"$_ble_util_fd_tui_stdin"' '' progressive-weight
            ./lib/core-complete.sh:2848:    if ((ext==148)) || ble/complete/check-cancel <&"$_ble_util_fd_tui_stdin"; then
            ./lib/core-complete.sh:3627:    [[ ! -t 0 ]] && ble/complete/check-cancel <&"$_ble_util_fd_tui_stdin" &&
            ./lib/core-complete.sh:3649:        "! ble/complete/check-cancel <&$_ble_util_fd_tui_stdin" 128 progressive-weight:killall
            ./lib/core-complete.sh:4121:        "! ble/complete/check-cancel <&$_ble_util_fd_tui_stdin" 128 progressive-weight:killall'
            ./lib/core-complete.sh:4178:    "! ble/complete/check-cancel <&$_ble_util_fd_tui_stdin" 128 progressive-weight:killall
            ./lib/core-complete.sh:4194:      "! ble/complete/check-cancel <&$_ble_util_fd_tui_stdin" 128 progressive-weight:killall'

            取り敢えずこれらは最早置換すれば良い。これらを置換したら <& は
            core-complete.sh からなくなった。なので、他に
            $_ble_util_fd_tui_stdin を ble/complete/check-cancel の為に余分に
            redirect している箇所はないだろう。

            ./lib/core-complete.sh:2604:        '! ble/complete/check-cancel' 128 progressive-weight

            これは redirection がなかったが恐らく変更忘れか必要なかったか。何れ
            にしても別の stdin をチェックする様な文脈ではないはずなのでこのまま
            で良い。

          以下で検索しても _ble_util_fd_tui_stdin の切り替え自体の処理以外はも
          うない。全て置換できた様な気がする。

          $ grc '<&"?\$_ble_util_fd_tui_stdin


        何れにしても decode 関係は大概ユーザーからの入力を意識していて、何処か
        勝手に用意した所からの入力を待つという事はないと思われる。

        ? fixed: ble/decode/cmap/decode-chars で処理している時に
          ble/util/is-stdin-ready を見に行って大丈夫なのか? これの制御は
          ble_decode_char_sync=1 というローカル変数で行われている様だが部分的に
          しか制御されていない気がする。現状では寧ろ一般には stdin を見に行って
          動作を決定している様な気がする。そもそも decode-chars は現在のユーザー
          の入力と関係なく処理する物のはずだから、ble/util/is-stdin-ready は恰
          も必ず失敗する様に振る舞わなければならない (或いは has-input でチェッ
          クしない)。ble_decode_char_sync が設定されてる時は
          ble/util/is-stdin-ready のチェックは失敗する様に書き換える事にした。

      * ./src/edit.sh:10525:    ble/util/is-stdin-ready && continue
        これは read の実装に使っている。微妙だが、これは 0 を使う様に修正した。

      * ./src/util.sh:5771:  function ble/util/idle/IS_IDLE { ! ble/util/is-stdin-ready; }
        ble/util/idle/IS_IDLE

        ./src/util.sh:5896:    ble/util/idle/IS_IDLE || return 1
        ./src/util.sh:5914:        ble/util/idle/IS_IDLE || break 2
        ./src/util.sh:6034:    ble/util/idle/IS_IDLE || return 148
        ./src/util.sh:6071:      ble/util/idle/IS_IDLE || return 148

        ble/util/idle.do ループの中での利用なのでこれで良いはず。

        ./src/history.sh:373:            [[ $opt_async ]] && ! ble/util/idle/IS_IDLE && return 148
        ./src/history.sh:439:      [[ $opt_async ]] && ! ble/util/idle/IS_IDLE && return 148
        ./src/history.sh:810:            [[ $opt_async ]] && ! ble/util/idle/IS_IDLE && return 148
        ./src/history.sh:824:      [[ $opt_async ]] && ! ble/util/idle/IS_IDLE && return 148

        これらは履歴読み込み及び mlfix の中断に用いている。基本的に idle/util
        と同じ取扱で良いだろう。

  * progcomp: compgen -V による結果取得 (motivated by RBT22, and many) [#D2253]
    https://github.com/akinomyoga/ble.sh/issues/356

    sort -z や sed -z に対応していれば printf '%s\0' を通して結果を入れてそれを
    mapfile -d '' を用いて読み取りたい。それ以外の場合にはどうするか?

    うーん。既存の実装を確認すると ble/util/writearray を結局使う事になりそう。
    というのも printf '%s\0' よりも ble/util/writearray の方が速い実装を提供し
    ているみたいである。

    うーん。mandb の事を考えると結局 awk 等で情報を付加する事になる (bash でそ
    れを別に実装する理由がない。候補が大量になる場合には bash で処理するのは重
    いし、また awk による実装と bash による実装を、振る舞いが一貫する様にしなが
    ら両方 maintenance するのは大変である)。そう思うと awk や sed で結局処理を
    する事になる。だとすると ble/util/writearray は何れにしても使う事になる。

    ? fixed: 既存の実装では ble/filter-by-prefix と workaround-for-git を同時に
      sed で実行している。候補がなくなった場合には 処理前に戻している。これだと、
      ble/filter-by-prefix で候補がすべてなくなった場合に、workaround-for-git
      が適用されなかった物が次の処理に流れるのではないか? 本来は処理を分割する
      べきの気がする。

    或いは処理を分割するぐらいならば一括で awk で処理してしまって良いのではない
    か? sort 以外は一回の awk の呼び出しで処理するべきの気がする。

    * ok: 色々な場合の実装を考えるよりも全部 nlfix で実装してしまうのが楽かもし
      れない → awk が sort に対応していない場合には nlfix の状態で外側で sort
      する事にした。

    処理をするのだと考えると sort を実行するのが良い気がする。

    2024-08-23 古いコードコメントの断片が残っていた。修正する。

2024-08-21

  * contrib: ble/widget/fzf-complete (motivated by 3ximus) [#D2252]
    https://github.com/akinomyoga/blesh-contrib/issues/20

    設定例を contrib に追加するのが良い気がする。これは fzf-completion.bash の
    中に直接追加する事にした。

    2024-08-22 改めて試してみたら空文字列の時の振る舞いが怪しい。修正する。

    2024-08-22 また観察していたら引数をちゃんと使っていない事に気付いた。修正す
    る。また fzf.md に説明を追記する。

  * contrib: fzf-menu (motivated by pallaswept) [#D2251]
    https://github.com/akinomyoga/ble.sh/issues/479

    これについても設定を contrib に追加する事にする。というか既に追加してある。

    2024-08-22 これも説明を fzf.md に追加した。

  * [OK] fzf-key-bindings: M-c binding が動かない (asked by markaacosta) [#D2250]
    https://github.com/akinomyoga/blesh-contrib/issues/21

    M-c は他の binding と比べて設定が異なって見える。最近追加された binding で
    はないか、と思ったが物凄く昔からある。少なくとも 9 年前から存在している。うー
    ん。key-bindings.bash が追加された時から存在している。そしてこれは元々
    install の中にあった。install ²追加されたのは以下の commit である。
    https://github.com/junegunn/fzf/commit/229601317433ee3ca94abdd09232a4b3db2d812c

    という事は最近の ble.sh の側の変更でこの binding が動作しなくなったという事
    なのだろう。

    今まで気付いていなかったのは何なのだろうか。と思って
    contrib/integration/fzf-key-bindings.bash を確認してみたらちゃんと対策がさ
    れている。つまり、このユーザーは説明を読まずに fzf を使っているのではないか
    という事が疑われる。

    結局ユーザーが設定を間違えていただけだった。改めて README を見ていて分かり
    にくかったので README の余分な部分は分離することにした。

    2024-08-22 註の marker が小さくなっていない。小さくする。

    2024-08-23 註本体の方の marker の大きさがそのままだった。修正する。また項目
    の先頭に来る様に位置を変更する。

  * contrib: exec_elapsed_mark 設定 (motivated by paulzzy, TheFantasticWarrior) [#D2249]

    * exec_elapsed_mark からコマンド名を削除する方法
      https://github.com/akinomyoga/ble.sh/issues/481
    * exec_elapsed_mark を non zero exit status でも表示する方法
      https://github.com/akinomyoga/ble.sh/issues/483

    これも設定例を contrib に追加する事にする。対応の過程で共通部分を新しい関数
    ble/exec/time#format-elapsed-time に括りだした。序に ns の分解能での表示に
    対応する事にする。

    2024-08-22 単位が us ではなくて ns になっていた。修正する。

    2024-08-24 bleopt/declare の使い方が間違っているという報告 (contributed by paulzzy)
    https://github.com/akinomyoga/blesh-contrib/pull/22

2024-08-19

  * color: パレット再考 (requested by mattmc3) [#D2248]
    https://github.com/akinomyoga/ble.sh/issues/478
    Ref: #D2258, #D2263

    色弱・色盲の為の色変換の式: https://mk.bcgsc.ca/colorblind/math.mhtml

    greyscale で見える範囲を決定する。色々の見え方について greyscale に変換した
    時に範囲を指定する。→mattmc3 から返信があった。87 .. 198 乃至は 96 .. 174
    との事である。自分の目で見た感じだと 100 .. 200 だと思った。色々範囲を変え
    て見てみると 100..174 でも一応たくさんの色の選択肢があるようなのでこの範囲
    で選ぶ事にする。

    - 26 -> 33
    - 92 -> 99
    - 94 -> 100
    - 124 -> 166
    - navy -> 63
    - purple -> 133

    変更漏れがない様に置換を自動化する様にする。適当に patch を生成して、それを
    確認してから patch -p1 < a.patch で適用する事にする。適用した。動いている。

    * ok: 既存の色と被っていない事も確認した。(airline themes にはあるがこれは
      status line だけでの着色なので被る事はないと考えられるし、そもそも
      airline theme は既定の着色ではなくてユーザーが選択する着色テーマなので気
      にしなくて良い。また、 github265-prompt-path-level-colors.bash でも一つの
      レベルにおける着色に使われているが、これも気にしなくて良い。)

    * base16 専用のテーマも用意して良いのではないかという気がする。いよいよ
      themes を作成する? 読み込みの方法について考える。単に ble-import で読み込
      む形にすると初回しか設定されない。ちゃんと変更した時に適用される為には
      bleopt 経由で読み取る必要があるのでは。或いは、include check なしに強制的
      に読み取る種類の ble-import を実装するか?

      何れにしても bleopt theme があると良い気がする → 簡単に実装した。

      * ok: 取り敢えず一回 ble-import して後は initialize を呼び出す形にしたが、
        そうでない方が良いかもしれない? でもこれは後で考えれば良い気がする。後
        で毎回 source する形にするとしても、source した後で initialize を実行す
        る様にすれば interface を変えなくても、メモリーの問題はない気がする
        (initialize 以外にも様々な関数や変数を作成しない限りは)。

      * fixed: "theme" という名前だと prompt theme を提供する物の様に思える。別
        の名前にできないか。palette など。或いは theme として prompt を提供した
        りしなかったり、face に対する色を提供したりしなかったりなどの自由度を許
        す? 然しそれは分かりにくい。一覧を見てどの palette が利用可能でどの
        prompt が利用可能化が見えるようにしたい。ディレクトリの中を除いた時にそ
        れらが一緒くたになっているのは良くない。

        → theme ではなくて palette に変更した。

      * done: 現在 base16 は基本の配色の上に重ねて適用する前提になっているが、
        既に別の palette が適用されていた場合どうするのか? 前の palette の影響
        が残っても良いのか? 駄目の気がする。

        palette を設定して初期化する前に設定を clear する必要がある気がする。そ
        うすると default palette については空で良いという事になる。

        うーん。基本の face 一覧を clear するというのは palette の側で明示的に
        示した方が分かりやすいのでは。と思ったがやはり palette=name で指定でき
        る様にする以上は干渉する可能性が残っているのは望ましくない。

        然し palette に於いて基本の物以外の face を指定しても良いはずである。そ
        ういう場合には呼び出し元が既定に戻してくれると期待していると変な事にな
        る。

      * done: 既定の配色も palette にするべきか? 一旦 palette を切り替えた後に
        元に戻すことができなくなるのでは? 然し、contrib がなくても動く様にした
        いという事を考えると完全に contrib の中に既定の palette を移動するのは
        したくない。例えば、基本の face については ble-face -r を実行するなど?

        →基本設定は飽くまで本体の中に含めるが形式的に基本設定を復元するコマン
        ドの列 (ble-face -r) として "default" palette を提供する事にした。他の
        palette で基本設定を元にして修正する場合にはこの基本設定を呼び出してか
        ら固有の設定を上書きする事にする。

      ? 既存の theme の値が残っていた時に初期化時に初期化順序で問題が起こらない
        か? と思ったが問題ない様である。初期化の遅延がされないなど多少の問題は
        生じるかもしれないが。

        うーん。やはり face 関連が初期化されるまでは初期化を遅延するべきの気が
        する。初期化が終了した時点で default 以外になっていたら読み込みを実行す
        る事にする。

        と思ったが、改めて実装を確認してみると ble-face や ble/color/face を呼
        び出しても直ちに初期化が実行される訳ではない。初期化前の ble-face の呼
        び出しはを通して行われる様だ。なので気にしなくて良い? うーん。然し処理
        が遅くなる様な気がするのでやはりできるだけ遅延する方が親切だろうか。と
        いうか、ユーザーが個別に設定した ble-face の方を優先させたいと思うとや
        はり同じ様に遅延させるのでは駄目の気がする。

        →bleopt palette に関しては特別に遅延させる事にした。initialize-faces
        で他の ble-face による初期化に先立って実行する。取り敢えず動いている。
        vim-airline を使っていない限りはちゃんと ble-reload でも faces 初期化の
        遅延が動いている。

      x fixed: どうも ble/color/initialize-faces が余分に2回呼び出されていた様
        だ。2回も呼び出す必要はない筈である。修正した。

      x ok: うーん。ble-reload の時に vim-airline の設定によって結局最初に
        initialize-faces が呼び出されている。vim-airline の設定も遅延できないの
        か? うーん。と思ったが前の session で設定した bleopt vim_airline_theme
        を継承していて、それによって "bleopt -I" から initialize-faces が呼び出
        されている。これは仕方がない事の様な気がする。幸いにして初回の実行時に
        はこれは起こらないので余り気にしなくて良い気がする。

      ? done: うーん。theme -> palette にしたがよく考えたら ble palette と被る。
        それに余り良い名前でもなかった気がする。やはり theme に戻すか? →
        scheme に変更する事にした。

        - そもそも prompt の theme については prompt_* という一連の設定が既にあ
          るのだから prompt_theme にするのが良い気がする。

        - また、theme を避けるにしても既に bleopt vim_airline_theme という設定
          を作っているので今更の感じもする (とは言いつつ vim_airline_theme は未
          だ prompt の theme の一部の様な気がする。ただし、配色しか指定していな
          くて各 segment に何を表示するかは vim_airline_theme では指定していな
          い)。

        やはり theme に戻したい。

        →と思ったが theme に戻すとすると contrib/palette は contrib/theme に変
        更するのだろうか。然し、元々は contrib/theme には prompt 用のテーマを格
        納するつもりだった。contrib/prompt は prompt/backslash:* の定義を置く場
        所にしたい。だとすると、prompt 用のテーマを contrib/theme 以外の場所に
        配置するか、配色設定を contrib/theme 以外に配置するかしなければならない。

        他の framework (bash-it, oh-my-bash) との一貫性を考えるとやはり
        contrib/theme には prompt のテーマを置く事にしたい。配色設定を palette
        に置くとするとやはり ble palette との兼ね合いで分かりにくい気がする。何
        より bleopt palette=name で設定できるのだとしたら ble palette で単に端
        末の色表示が見られるだけというのは混乱の元である。

        辞書や ChatGPT で調べてみると配色は color scheme と言ったり colorway と
        言ったりするらしい。iTerm2 云々の repository の名前が scheme だったのは
        そういう事だったのだ。うーん。scheme にするのが良い気がしてきた。bleopt
        は color_scheme で、contrib の下は scheme という事にする。

    * done: 折角 color blindness について調べたのだから colorglass_blindness 等
      について対応しても良いのではないか? その場合には色変換のコードをシェルで
      作成する必要がある。とは言いつつ行列の掛け算だけ実装すれば良い気がする。

    * done: colorglass で使う base16 color について指定する仕組み。というか、
      base16 palette が指定されている時は、変換する時だけでなく、常にその色を使
      うようにするべき。

    * reject: colorglass.base16.dat の md version も追加する? 然し余りにも沢山
      のデータを repository に含めるのはどうなのだろう。documentation はやはり
      wiki に記述するべきなのではないか? 特に自動生成される物については wiki に
      入れるべきの気がする。

      →実際に生成してみて wiki に push して見たがちゃんと表示されない。以下の
      ページによるとどうやら Issue/PR/Discussion でしか有効ではない様だ。Wiki
      はもちろん README などのファイルとして存在する markdown でも対応していな
      い様だ。つまり、GFM の範囲で色サンプルを表示する方法はないという事?

      https://qiita.com/Yarakashi_Kikohshi/items/8b1ebfa798a35dec6154#%E3%82%AB%E3%83%A9%E3%83%BC%E3%83%81%E3%83%83%E3%83%97%E3%81%AE%E8%A1%A8%E7%A4%BA

      gh-pages に載せるしかないという事?

      他に気付いた事は contrib/colorglass.base16.dat.md にファイルを作ったが
      colorglass.base16.dat として表示されてしまう。然し一方で GitHub の Web UI
      からだと contrib/ 以下にファイルを作ることができる気がする。ファイル名の
      対応はどうなっているのだろうか? うーん。
      wiki/contrib/colorglass.base16.dat にアクセスするとファイル作成画面に跳ぶ
      が、其処で slash 入のファイル名を指定しても結局生成されるファイル名は /
      から - に置換された物になってしまう。そして改めて - を / に置き換えた URL
      にアクセスすると再びファイル作成画面が表示される。

      うーん。wiki に変なファイルを追加してしまったがこれを保持しておく必要は全
      くない。colorglass.base16.dat の内容と等価の情報しか表示できていない。削
      除するべき。

      うーん。取り敢えずサンプルの表示は諦める事にする。

      取り敢えず -t html で html を生成できる様にした。

    * done: color.sample.sh: list-safe-colors で .md 形式でも色を出力できる様に
      する。markdown では背景色を任意に設定できないので `#xxxxxx` を沢山 table
      に含めるだけになるだろう。

      →これも GFM で表示できない以上は生成する意味がない気がする。一応生成の為
      のコードだけは作成しておく? → オプション -t で出力形式を切り替えられる様
      にした。plain markdown の出力と html の出力を追加した。実際には html の出
      力で確認するのが妥当だろう。

    * done: contrib/*.md をちゃんとコピーするようにする?

    * done: docs: bleopt colorglass_{blindness,base16_palette}

    * done: wiki, blerc: bleopt color_scheme

    * done: gh-pages: 新しく gh-pages を作る? color.sample.safe-colors.html と
      colorglass.base16.html を追加する? index.html には単純にリンクの一覧を載
      せるだけで良い。colorglass.base16.html については contrib/colorglas.md か
      らリンクを貼る。というか make/README.md からもリンクを貼る。

    2024-08-22 https://github.com/akinomyoga/ble.sh/issues/478#issuecomment-2304599975
    ~/.blerc に color_scheme を記述すると初期化エラーになるという報告。単に初期
    化の順序を間違っていた。

    2024-08-22 colorglass_blindness が clear できない。説明では空文字列で clear
    できる事になっているが、実際の実装では none が color blindness なしという事
    になっている。然し、bleopt/check:color_blindness が間違っている所為で none
    を設定できない。

2024-08-14

  * select: C-o で region 選択が解除されずにコマンドが表示される [#D2247]
    Ref. #D2207

    これはまた面倒そうなので後で考える。と思ったが普通に C-m で実行した時にも同
    様の問題が発生している。うーん。これは起こらない様に調整した様な気がするが、
    改めてまた発生しているという事だろうか?

    →調べてみた所、対応して追加修正した直後 98a2ae15 はちゃんと選択が解除され
    て表示されている。911a4051 で動かなくなっている。911a4051 では
    ble/textarea#render に opts=leave を指定したら _ble_complete_menu_active や
    _ble_edit_overwrite_mode を解除して描画する様に変更している。

    a しかし、それが効いていないという事だろうか?

    b 或いは一旦 _ble_complete_menu_active= で描画した後に再び上書き描画してし
      まっている可能性? 然しそれも変な気がする。

    確認してみた所、そもそも描画更新が発生していない。umin,umax が -1,-1 の儘に
    なっているのでそもそも描画が起こらないという状況である。更に詳しく見ると
    region layer も何も更新がないと報告している。

    region は _ble_edit_mark_active を参照して決めている。とここで気付いたのだ
    がそもそも opts=leave を指定している時に _ble_edit_mark_active を無効化して
    いない。コメントでは _ble_edit_overwrite_mode= に対して layer:region を無効
    化しているという事になっているが、これは明らかに間違ってい
    る。_ble_edit_overwrite_mode で無効化できるのは layer:overwrite_mode であり、
    layer:region を無効化するには _ble_edit_mark_active を空にしなければならな
    い。これは単純に変更ミスと思うべき。

    "local _ble_edit_mark_active=" を ble/textarea#render で指定する様にしたら
    ちゃんと直った。

    * reject: 或いはもう一つの方法として region をそもそも実行時には無効化する?
      → 原因は "region が有効な状態で再度描画される事によって復元する" などで
      はなくて、そもそも region を無効化して描画する時点でちゃんと更新がかかっ
      ていないのが原因だった。

  * highlight: echo $* とすると $* がエラー着色される [#D2246]

    これは何故だろうか。failglob 着色が有効になっているという事?

    うーん。どうやら分かった。 $* を eval している文脈ではその文脈固有の $* が
    存在している。そしてその中には '$*' 自身も含まれている。この '$*' がファイ
    ル名等に一致しない為にエラーになっている。うーん。外側の引数 $* も本当は復
    元して評価するべきの気もするがそれを再現するのは難しい。代わりに空にするの
    が無難の気がする。そもそも対話シェルで $* を設定する人も多くはないだろう。

    実際に一番外側の位置パラメータに裸で参照すると failglob を引き起こす様な物
    があった場合に正しく対応できないが、そもそもそれを言い出すと今までだって動
    いていなかったので気にしても仕方がないだろう。

    * done: 或いは別の可能性として一番外側の位置パラメータの内容を記録するとい
      う手もあるが…。"$@" が set -u でエラーになる場合にどうするのか? →確認し
      てみたが別にエラーにはならない様だ。空配列を参照する時に気を付ければ良い。

      取り敢えず外側の "$@" を保存して simple-word eval の時には復元する様にし
      た。動いている。

    * done: 今度は $1, $2, ... という様に参照した時の変数の着色が気になる。今外
      側の位置パラメータを記録する様にしたので、これについても正しく復元する事
      ができる様になる気がする。

  * mandb: groff が存在しない分岐で groff を使っている [#D2245]

    nroff の存在確認をした分岐の中の処理なのでこれは nroff を意図した物だろう。

  * mandb: _^HX が処理できていない? [#D2244]

    less の mandb でオプションの説明の中に _^HN (N の下線付きを表現する為に _
    を出力した後 ^H を出力して、その後に文字本体を出力) が含まれている。

    →man から抽出した内容に関しては ^H は除去している筈だし、実際に確かめてみ
    ると除去できている。キャッシュを調べてみるとどうやら --help で抽出した内容
    の方に _^H が混入している様だ。実際に less --help を試してみると less は
    less --help の表示についても less を用いるようで、それを他のコマンドにパイ
    プで流し込む様にすると _^HN の形式で下線を引いて出力する様である。

    optarg については元々 control chars が含まれていると escape して見える様に
    表示してしまう様なので削除する。desc に関しては SGR による装飾に変換する事
    にする。

    2024-08-22 テスト用の a.txt に対する出力が残留していた。削除する。

  * main: bash-4.4 で POSIXLY_CORRECT 補正が動いていない (reported by vasi786) [#D2243]
    https://github.com/akinomyoga/ble.sh/issues/477

    Ref. #D2221

    * 48c7bbee (#D2221) より前は動いていたというのは確実

    * 毎回コマンドを実行する時には状態が壊れている。

    * 通常の編集時には状態は壊れていない気がする。しかしそれでも何故か TAB が無
      反応になるという現象は発生する。

    どうも ble/widget/vi_imap/complete の中で "C-i": complete になる様だ。更に
    調べると ble/complete/menu-complete/enter の内部で起こっている。更に
    ble/decode/keymap#load menu_complete の中で発生している。更に辿ると
    ble-decode/keymap:menu_complete/define の中で発生している。とここで分かった。
    ble-decode/keymap:menu_complete/define の中で実行している ble-bind が原因だ
    ろう。ble-bind の中で POSIXLY_CORRECT の調整を行っている。これは今まで無かっ
    た物の筈である。中を確認すると "$_ble_bash_POSIXLY_CORRECT_local_adjust" と
    "$_ble_bash_POSIXLY_CORRECT_local_return" を呼び出している。何もなければ -o
    posix を待避する事もなく、従って workaround-POSIXLY_CORRECT を実行する必要
    すらもない筈だ。しかし、何かが起こっているという事は実際に無条件で
    POSIXLY_CORRECT に触っているという事。

    テスト用に用いた関数:

      function check-posix {
        local ext=$? posix=$(builtin bind -p | grep C-i)
        if [[ $posix != "$_dbg_posix_prev" ]]; then
          echo "${FUNCNAME[1]}${1:+:$1}: state changed (${posix:+C-i broken})" >/dev/tty
          _dbg_posix_prev=$posix
        fi
        return "$ext"
      }

2024-07-29

  * BUG main: _ble_bash が消失している (reported by tessus and Knusper) [#D2242]
    https://github.com/akinomyoga/ble.sh/issues/470#issuecomment-2255357001
    https://github.com/akinomyoga/ble.sh/issues/472#issuecomment-2258653708
    Ref. #D2240

    これは #D2240 の regression. _ble_bash の位置を前方に移動した時に builtin
    unset -v _ble_bash を途中失敗に付加したが、全体で実行する ble/init/clean-up
    にも付加していた事によって全体で _ble_bash が unset される様になってしまっ
    ていた。これは問題だ。急いで修正する。

    2024-07-31 最新版の中で ble-reload した時にエラーが起こるというがどういう事
    だろう。自分の手元で実行すると別にエラーは発生しない。然しその後で ble.sh
    が全く機能しなくなる。やはり _ble_bash が消滅している様だ。未だ _ble_bash
    を削除している箇所があると思ったが見つからない。

    ble-reload の時に発生するという事を考えると ble/util/unload を呼び出してい
    るのでそれによって _ble_bash が削除されている。今まで _ble_bash の初期化を
    遅延していた理由があった様な気がしていたが、それは reload 時の
    ble/util/unload よりも後にしたかったからだろう。

    2024-09-23 古い version から update した時に未だ _ble_bash が消失する。

    | 依然として古い ble.sh の version から update した時に BASHPID のエラーが
    | 発生する
    |
    | うーん。_ble_bash を定義している箇所が ble-unload よりも上になった為に
    | ble-unload によって _ble_bash が削除される様になってしまったという事?

    a9b962d2 で ble/base/unload-for-reload を追加修正したと思ったが、よく考えた
    ら古い version の ble/base/unload-for-reload の方が使われるのだから此処で修
    正しても意味がない。呼び出し元でも _ble_bash を保存する様にした。

    またよく考えたら ble/base/unload-for-reload を拒否された場合に _ble_bash を
    削除しているがこれも駄目だ。元々の ble.sh インスタンスが動かなくなってしま
    う恐らく ble/init/clean-up に関しては大丈夫だろう。この関数は初期化の時に一
    時的に記録した変数を消去するだけの筈だから。

  * main: --clear-cache で長々しい devel version では遅い warning を出力する必要はあるのか [#D2241]
    Ref. #D2222

    この長い version のメッセージを実装した時に意図的にそうしたのだったか? 或い
    は余り考えていなかったのか? → 確認してみたが別に余り考えていなかった様だ。
    新しく _ble_init_command が指定されていた時には長いメッセージの代わりに短い
    メッセージを表示する事にした。

    オプション --bash-debug-version=check を明示的に指定した時には長いものを表
    示する事も考えたが、"long" ではなくて "check" だし、諸々の処理をする時に長
    いメッセージを表示する必要もない気がするので、check を明示した場合でもやは
    り短いメッセージを表示する事にする。

  * util(ble/function#pop): エイリアス展開により push/pop の度に関数がどんどん長くなる (reported by 103sbavert) [#D2240]
    https://github.com/akinomyoga/ble.sh/issues/471

    報告者の場合には報告者が alias ='sudo -v; sudo ' なるエイリアスを設定してい
    たために関数を push/pop する度に sudo の呼び出し回数が 2 倍になって、或る時
    点で関数が長くなりすぎて bash がクラッシュするという状態だった。

    * done: shopt を記録する為の関数を用意する → 用意した。_ble_bash はやはり
      参照したいのでできるだけ始めに初期化してしまう。代わりに ble.sh の初期化
      失敗の折には builtin unset で削除する。

    ? fixed: 類似の事は restore-builtin-wrappers でも発生するのでは?

      →基本的に ble/function#evaldef と同じ実装で良い。然し
      ble/function#evaldef は util.sh まで辿り着かないと定義されない。同じ内容
      の関数が重複するのも嫌なので ble/base/evaldef という関数を ble.pp で定義
      してそれを呼び出す事にした。ble/function#evaldef もその関数をそのまま呼び
      出す。

  * contrib/colorglass: 浮動小数点丸めが正しくない [#D2239]

    後で他の演算についても間違いがないか確認するつもりだったが長らくそのまま放
    置されていたので、今回の機会にこの修正だけでも push する事にする。

  * contrib/bash-preexec: __bp_set_ret_value 等を期待するスクリプトが存在する (reported by Comnenus) [#D2238]
    https://forum.atuin.sh/t/bash-bp-set-ret-value-command-not-found-on-macos-bash-powerline/410

    iTerm2 shell integration が __bp_set_ret_value を使っている。これによってエ
    ラーが発生する。

    ? resolved: iTerm2 shell integration precmd では
      __bp_last_argument_prev_command に $_ が入っている事を期待している様だが、
      bash-preexec.bash の実装を見ると __bp_last_argument_prev_command は
      precmd に対しては設定されていない様に見える。つまり、iTerm2 shell
      integration を実行した後だと $_ が変わってしまうのでは? と思ったが、改め
      て確認してみるとbash-preexec は DEBUG trap で常にこの変数を設定している様
      に見えるので問題ない?

      然し、それはそれで bash-preexec.bash を使っていると $_ が容易に上書きされ
      てしまうという事を意味する。というか、bash でも bind -x 等を実行した時に
      $_ が上書きされてしまう事になるので、それと振る舞いが consistent という事
      だろうか? → 実際試してみた所、bash では bind -x などを通して実行されたコ
      マンドでも $_ を上書きしてしまう。なので、bash-preexec の現在の様な実装で
      あっても、bash の振る舞いとの互換性の為にそうなっているのだと言われればそ
      うなのかもしれない。

      ? とは言いつつ precmd はユーザーのコマンドが実行された直後に実行されるは
        ずだから他の要因で書き換わる事はないのでは? とも思ったがユーザーが空の
        コマンドを実行した場合には更に前の $_ が参照されるのでは。その場合には
        bind -x などによって上書きされた値を拾う可能性が未だある。

      問題は ble.sh でも律儀に bash の振る舞いを模倣するべきかという事になるが、
      恐らく気にしなくて良い。やはり bind -x 経由でコマンドを呼び出したか呼び出
      していないかという対話的操作によってコマンド実行の振る舞いが変わってはい
      けない筈である。

      現在の実装では bash-preexec の実装に倣って preexec では $_ を記録して
      precmd では $_ を記録しない様になっているがこれは駄目だ。bash-preexec で
      は DEBUG の処理の一番初めに $_ を記録していて、preexec を実行する場合でも
      そうでない場合でも $_ を記録する様になっていた。一方で、contrib の
      bash-preexec.bash では本当に PREEXEC の時だけに呼ばれるのでそこで $_ を記
      録しても、precmd で正しく $_ を得ることができない。precmd でも $_ を記録
      する様にする事にする。

      というより precmd で設定するのであれば preexec では
      __bp_last_argument_prev_command は設定しなくて良い気がする。そちらの方が
      他の変数の設定とも一貫している。

    うーん。他にも他のスクリプトが使っていそうな内部関数や変数はあるだろうかと
    思ったがない様な気がする。そもそも __bp_set_ret_value だって他の枠組みが使
    いそうにないような気がする。取り敢えず __bp_set_ret_value は追加し
    て、__bp_last_argument_prev_command も precmd で記録する様にした。他に
    __bp_inside_precmd, __bp_inside_preexec も設定してみる事にしたが実際に参照
    している設定が存在するかは知らない。

  * fzf-git: fzf-git で fzf を呼び出すときに modifyOtherKeys が有効になっている (reported by tessus) [#D2237]
    https://github.com/akinomyoga/ble.sh/issues/470

    これは全然対策していなかった。今まで気づいていなかったのが不思議だ。contra
    は先ず modifyOtherKeys を実装しておらず常に独自のキーを送信する様になってい
    るし、また contrib/integration/fzf-git を使っている人もそもそも余りいないか
    らだろうか。

    * fixed: builtin bind が呼び出されているがこれは本当に意図した物なのだろう
      か。ユーザーが type original を使って fzf-git の初期化をして、更にその初
      期化が遅延で行われた場合に ble.sh 自体の builtin bind を上書きしてしまう
      のではないか。

      そもそもこれは bind に対する make scan のエラーを抑制する為に機械的に適用
      された変更だったりしないか? → 調べてみると 88151ffb で変更が適用されてい
      る。確かに make scan 関係のエラーを抑制する為に色々変更を適用した commit
      に見える。恐らく何も考えずに適用したという事だろう。これは恐らく意図しな
      い変更である。

      修正する。直接の bind の呼び出しにするとまた make scan に引っかかる様になっ
      てしまうので ble/builtin/bind を呼び出す様にする。

    ble-bind -f 経由で呼び出すときについては対策を入れたが他の呼び出し方をした
    場合にも問題になるのではないか? 他の場合も全て対策するのは大変の気がする。

    a 先ず original については直接 _fzf_git_* を呼び出しているのを間接的に別の
      関数を通して呼び出す様にする? その他の場合についても必要に応じて個別に調
      整を行う。

    b 或いは _fzf_git_* の側で端末状態を調節する様にする?

    c 全ての fzf 呼び出しは _fzf_git_fzf 経由で行われている様なのでこの関数で調
      整すれば良い。

      と思ったが subshell の中でこの調整を行っても大丈夫だろうか。例えば

      ? kill された時に不整合が生じないか。

        kill が何処まで伝播するのかという問題の気がする。fzf が中断してもその呼
        び出し元のプロセスが残っていれば良い。

        中断が起こるとすると SIGINT によるものだろう。しかし $(...) の実行中に
        呼び出された SIGINT は何処まで伝播するのか。というかそもそも
        $_ble_term_state == internal の場合には stty で調整がされているので C-c
        で SIGINT が送信される事はない。手動で SIGINT を送る場合には何が起こる
        かについて保証できないので気にしなくて良い。

      ? そもそも、 ble/term/leave-for-widget の必要性を判定する時に
        _ble_term_state を確認しているが更新していない。これによって重複して
        ble/term/leave-for-widget が実行されたりしないのか。

        そもそも ble/term/{leave,enter}-for-widget を呼び出している箇所は少ない。
        bind -x で登録されたコマンドと、integration/*.bash の中でしか使われてい
        ない。なので、"bind -x" 経由で呼び出された時に重複で処理がされない様に
        しておけば十分の様に思われる。

        大体大丈夫の気がするが、ユーザーが直接 gb 等のシェル関数を bind -x の中
        から呼び出した時に問題になる気がする。ble/term/enter-for-widget が呼び
        出されて、bind -x の処理の途中なのに端末の状態が ble.sh internal 用に調
        整された物になってしまう。

        やはり leave-for-widget 用にも状態を管理する変数を追加しなければならな
        いのだろうか。この手の変数が何種類も重複してあって良くない気がするがど
        うにかならないのだろうか。

      x また、既に leave-for-widget した状態の時に subshell の中で調整を行うと
        最終的に enter-for-widget の状態になるが、それが復元されない事になるの
        では。leave-for-widget 専用に状態を変数で管理するとしても subshell の中
        の変更は親シェルに反映されない。

        →これは入れ子で呼び出される事がないようにする。

    x fixed: is_in_git_repo の実装が間違っている気がする。と思ったが fzf-down
      と実装が逆になっていたのだった。入れ替えた。

    ? fixed: _fzf_git_fzf という関数がユーザーによって重複して定義される可能性
      は? 高い。そもそも _fzf_git_fzf という関数に分けているのはユーザーが設定
      を変更できる様にするためであろう。実際にコメントで Redefine this function
      ... という指示が書かれている。という事を思うと現在の修正方法は望ましい物
      ではない。

      結局新しい関数 ble/contrib/integration:fzf-git/git を定義してそれ経由
      で_fzf_git_fzf を呼び出す事にした。

2024-07-09

  * decode: mcfly で "'C-m': 'string'" という形式の keybinding が使われている [#D2236]

    * mcfly: bind "'\C-r': 'string'" の様な形式で呼び出している。調べてみると
      readline はこれをちゃんと処理できる。一方で、ble の bind 実装では処理でき
      ていない。これは対応する必要がある。

      因みに bind -x の場合には readline は '\C-r' を処理できない。エラーになる。
      つまり、bind '...' か bind -x '...' かによって single quotes を処理できた
      りできなかったりする。

      元々エラーになるのであれば追加で対応しても良い気がする。因みに bind -x
      '"\C-t": '"'echo hello'" はちゃんと quote が除去される。

      bind -x '"\C-t": '"'echo '\\''world'" とやると最初の 'echo ' までしか認識
      されない。一方で bind に同じ文字列を与えると "\C-t": "echo '''world" にな
      る。他にも色々試すとどうやら bind の時には '...' の中の escape も処理する
      様だ。

      * done: bind s の場合には '...' の中身も unescape 処理を行う。というか
        \C-m や \r なども処理されている。

        と思ったが本当だろうか。うーん。違う。やはり最初の '...' だけを正しく読
        み取るというところまでは bind x と同じだが、その後に続くごみについて、
        最初の空白文字以前の部分については追加で取り込む仕組みになっている。そ
        してその中身を macro string として解釈している。

        $ bind '"\C-t": '"'hello''world'"; bind -s
        "\C-t": "hello''world"
        $ bind '"\C-t": '"'hello' 'world'"; bind -s
        "\C-t": "hello"
        $ bind '"\C-t": '"'hello''world test'"; bind -s
        "\C-t": "hello''world"

        以上の様な解釈結果になっている。

      * done: bind x の場合には最初の '...' しか認識しない。

      * ok: bind x の : なしの場合には " 以外は受け付けない。

      * ok: keyseq の '\C-m' や '\r' の解釈 (実装済みだった)

        bind s keyseq: うーん。そもそも '...' の形の keyseq もちゃんと処理され
        ていない気がする? '\r' が ' になっている @ bash53。

        と思ったが '\r' が ' になってしまうだけであって '\C-m' や '\C-r' はちゃ
        んと認識されている。これは bash50 でも同様の振る舞いである。何故?

        うーん。また bash のソースコードを確認する? うーん。分かった。 - がある
        場合には最後の - の直後の文字をキーとする仕組みになっている。また、修飾
        については単に C-, M- などの文字列が key に含まれているかどうかで判定し
        ている

        →これについては ble.sh の実装を見る限りはちゃんと同じ結果になる様に実
        装している気がする。builtin/bind/.parse-keyname で実装している。実際に
        試してみた所、ちゃんと bash と同様に振る舞っている様だ。

    * mcfly はそもそも何故この変な指定方法を使っているのか。と思ったが一番最初
      に対応した時から '...' を使っている様である。あと、最初は mcfly ではなく
      て bash_wizard.sh という名前だった様だ。

      https://github.com/cantino/mcfly/commit/006c50b77451f4736a530ca897744d163f89fe30

      bash のソースコードを確認して、やはりこれは正しく処理されていない。'\C-r'
      がちゃんと動いている様に見えるのは偶然である。

      $ bind $'"\x12": \'test1\''; bind -s
      $ bind $'\'\x12\': \'test2\''; bind -s
      "\C-r": "test1"
      "'": "test2"

      うーん。これは後で mcfly に修正を提出する事にする。

2024-07-01

  * main: work around the issue that WSL clears "/tmp" after Bash starts (reported by LeonardoMor) [#D2235]
    https://github.com/akinomyoga/ble.sh/discussions/462
    https://github.com/microsoft/WSL/issues/8441#issuecomment-1139434972

    既に WSL で報告されている様だ。gitstatus が /tmp を作った後に中身が消去され
    ているという問題。報告されていて romkatv は何度も mention しているが、WSL
    での issue は閉じられて無視されている。

  * test: skip tests on "ble/test/chdir" failure [#D2234]

    何らかの理由で ble/test/chdir に失敗した時 (例えば permission の問題でディ
    レクトリを作成できなかった場合) などに、現在ディレクトリに一時ファイルが作
    成されてしまう。ble/test/chdir に失敗した時は一連のテストを失敗する事にする。

2024-06-27

  * 2024-06-19 bash-5.3 で source ble.sh よりも前の user bind が読み取れていない [#D2233]

    atuin を先に初期化して ble.sh を初期化した時に atuin key-bindings が拾えて
    いない。

    これは恐らく bash-5.3 で bind -X の出力形式が変わったのが原因である。実際に
    試してみた所、5.2 では再現しなかった。修正した。

2024-06-24

  * term: カーソル表示・非表示管理の再設計 (motivated by tessus) [#D2232]

    今や手動で civis rmcivis を指定しなくても良いのでは? と思ったが、どうも
    ble/term/enter が rmcivis を含めている為に、ble/util/buffer.flush での囲み
    機能が無効化されている様である。

    更に言うと、無条件でカーソルを消して表す様にしていると、元々カーソルを隠し
    ている状態だった時にカーソルが見える様になってしまう。なので、手動で civis
    rmcivis を設定する方針も動かない。ちゃんと条件付きで囲む必要がある。

    然しそもそも ble/util/buffer.flush が civis を出力するのだとしたら
    ble/term/enter で civis を出力する意味はあるのだろうか。うーん。確認してみ
    た所、内部状態に応じて civis を出力したり rmcivis を出力したり切り替えてい
    る。うーん。一番分かりやすいのは ble/term/enter で rmcivis を最初に出力して
    しまう事? とも思ったがそれだと ble/term/enter よりも前に buffer に入ってい
    た内容に対しては rmcivis が適用されなくなってしまう。もう一つの可能性はやは
    り ble/util/buffer.flush に任せるという事だろうか。しかし、それはそれで 1)
    internal state でないと ble/util/buffer.flush がちゃんと期待する物を出力す
    るかわからない。といって state まで確認して出力内容を変えるのはやりすぎの気
    もする。

    でも char_width auto が手動で civis rmcivis を実行するのにも問題がある。こ
    のシーケンスの後にシーケンスがあった場合にそれに対して civis が適用されない。
    やはり ble/util/buffer.flush の側で隠すべきの気がする。

    * ble/uti/buffer.flush について現在は civis か rmcivis のどちらかが使われて
      いたら囲まない様にしているが、最初の civis は何れにしても出力するべきなの
      では? 既に含まれている内容で最後が civis の時にはそこに rmcivis を付加す
      ると問題になるが。

    * そもそも cursor-hidden では調整を一切せずに buffer.flush でカーソル調整は
      全部するべきか? しかしその時に問題になるのは internal, external の変化に
      ちゃんと追随できるかという事。基本的に 1. internal の時には素直に処理する。
      2. external -> internal の時には何も気にしなくて良い 3. internal ->
      external の時には状態が変わる時に明示的にシーケンスを出力する必要がある。

      と思って改めて確認してみた所、実は _ble_term_cursor_hidden_current にて明
      示的に現在期待している状態を記録している。という事は
      _ble_term_cursor_hidden_current の値に基づいて処理すれば良いだけでは。ま
      た、external の時には元から external の時には何もしなくて良い。internal
      -> external の場合については、実は leave-for-widget の中で current=reveal
      にしてから buffer.flush をしているので、ちゃんと外側の状態になっていると
      いう事は保証される。

    ? ok: iTerm2 では DECSET(2026) はこの CPR による強制描画に対して意味がある
      のか。iTerm2 の最初の DECSET(2026) の説明によると通信の遅延を解消するだけ
      で実際に行われる処理 (内部に含まれる描画の指示) などは実は遅延されない?

      $ esc=$(printf '\e[8m'; printf '\r%s\e[6n%s\e[6n' {1..30}; printf '\e[m')
      $ echo "$esc"
      $ echo $'\e[?2026h'"$esc"$'\e[?2026l'

      これは試してみてみて貰ったところちゃんと描画は抑制はされている。然し、改
      めて見てみるとどうも実行時間に時間がかかるのは変わっていない?

  * main (ble-attach): 端末関連の初期化順序の再考 [#D2231]
    Ref. #D2223 #2232

    char_width_mode=auto の判定で civis / rmcivis を入れようかと思ったが、そも
    そも何故手動で入れなければならないのか。元々自動的に入るようになっていたの
    ではないか?

    * char_width_mode=auto の判定用のシーケンスを構築している場所で確認してみた
      所 _ble_term_state=external だった。一方で受信の時には既に internal になっ
      ている。送信の時点で internal になる様に変更したらどうなるか?

      ? reject: というかそもそも internal の時にしか囲まないのは何故か? 常に色々
        のシーケンスで囲んでも良いのではないか?

        元からあった civis に関しては現在の内部のカーソル表示状態に基づいて出力
        後のカーソル状態を調整していた。一方で、synchronized update については
        内部状態も何もないので常に出力するという形でも問題ないのでは? と思った
        が、もし ble/util/buffer.flush を呼び出す別のシェルプログラムがあったと
        して、そのプログラム自身も synchronized update を用いているとすると、
        ble/util/buffer.flush によってそれが意図せずに解除されて中途半端な所で
        描画が起こってしまう事になる。という事を考えると、やはり
        "ble/util/buffer.flush 経由で全ての描画を行う internal state" だけで
        synchronized update を使うのが自然の気がする。

      ble-attach において ble/canvas/attach を呼び出してから ble/term/enter を
      呼び出している。この順番である必要はあるだろうか。例えば、ble/term/enter
      の中で変更した設定によって端末の文字幅計測の結果が変わる可能性はあるか?

      例えば ble-edit/exec:gexec/.end では ble/term/enter を呼び出したあとに
      ble/util/c2w:auto/check を呼び出している。なので、現状では
      ble/canvas/attach は ble/term/enter よりも後で問題ないはず。

      →改めて確認してみると ble/term/enter の中で buffer.flush を実行している。
      つまり、ble/term/enter よりも後で ble/canvas/attach を実行すると無駄に
      flush を分ける事になるのでは? と思ったが、結局 buffer.flush はその後に実
      行しているので関係ない? うーん。buffer.flush はプロンプトの最初の初期化の
      後に実施しているので、結構時間がかかっている。時間がかかっている間に端末
      の検査は済ませてしまいたいという事を考えると、やはり二段に分けて
      buffer.flush を実行したい。

    調べていて気付いたが char_width_mode=auto の判定だけでなく、STBM のチェック
    や terminal identification (DA2) の処理がランダムな位置で発生している。最初
    の term init の時点で全部処理するべきの気がする。

    端末に対する request は一括して行う様にするべき。

    * STBM の判定の位置の再考

      先ず stbm の判定が ble/util/reset-keymap-of-editing-mode の中から呼び出さ
      れている。何故? と思ったが勘違いだった。ble/term/initialize から出力され
      ているのだった。

      然しこうなると ble/term/initialize の実行順序が気になる。何故
      ble/term/initialize が最初のプロンプトを表示したのよりも後になっているの
      か? ble/term/initialize をもっと先に移動できないか?

      - ok: ble/term/initialize で decode の初期化を待たなければならない処理は
        ないか? 取り敢えずその様な事はない様に思われる。逆に decode の側で
        ble/term/initialize を実行する前にしておかなければならない事はあるか?
        と思ったがそういう雰囲気もない。そもそももしそうだったら現状のコードは
        ble/term/enter を先に呼び出しているので既に壊れている事になる。

      - ok: 一瞬 decstbm の判定を後にしているのは文字幅の判定を終了してから出な
        いといけないからでは? と思ったがよく考えたら非同期に処理していて入力を
        処理し始めるのは ble-attach が完全に終了してからなので、何れにしても
        decstbm の判定用のシーケンスを送信する時点では文字幅は分かっていない。
        なので関係ない。

      - 次にチェックする事は ble/decode/attach が他の場所で呼び出されていないか
        という事と、もしそうだとしたらその呼出元で ble/term/initialize を呼び出
        す様にする必要があるかという事。

        実は ble/decode/attach は複数の箇所で呼び出されている。

        * ble-edit/exec:gexec/TERM/enter で呼び出されている。これは TERM 変数の
          書き換えによって readline bind の状態が書き換わってしまった時に再度状
          態を再調整する為の物。この場合は寧ろ ble/term/initialize は不要である
          様に思う。

          と思ったが対になっている ble/decode/detach で ble/term/finalize を呼
          び出しているので寧ろ initialize が必要なのだろう。然し test-STBM に関
          しては再度実行する必要は全くない。最初の一回実行すれば良いだけの筈で
          ある。

      つまり、現在の ble/term/initialize は寧ろ ble/term/attach 的な物の気がす
      る。そしてそれとは別に ble/term/initialize という関数を用意したい気がする。

      x resolved: うーん。余分に stty/initialize が呼び出されている。然し
        ble/decode/attach に於いて ble/term/attach を呼び出す様にしたとしても、
        何れにしても ble/term/attach で stty を呼び出す必要がある気がするので、
        ble/term/initialize の側では stty は実行するべきでない? うーん。つまり、
        ble/term/initialize では ble/term/enter も実行しないし stty/initialize
        も実行しないという事。

        これは最初は ble/decode/attach の中で初めて stty/initialize を実行しよ
        うと想っていたが、stty echo を早期に解除してユーザーの入力が画面に現れ
        ない様にする為に、やはり最初に実行する事にした (2つ次の項目で議論してい
        る)。

      x ok: しかし、先に initialize を実行してから attach をするという方式だと
        やはり requests は external state の中で実行する事になってしまうので、
        元々この事を考え始めた理由である DECSET(2026) を (ユーザーが明示的に
        bleopt term_synchronized_update=on を指定した時に) 初期化時の request
        の時点で含めるというのは有効にならない。

        うーん。然し、これはまた別の問題の気がする。やはり最初の request の時点
        では attach はしていないと思えば、internal state に即座に移行するのはや
        はり違う気がする。

        これは取り敢えず気にしない事にする。

      x fixed: 2回 stty を実行している事に関して。ble-attach のコメントに 「起
        動時のずれ防止の為」と書かれている。つまり、これはプロンプトの表示より
        も前に stty を実行しておく必要があるという事なのでは? どういう事だろう
        か。例えばユーザーが入力した文字列が echo されるのをできるだけ防ぐ為?
        確認する必要がある。

        48bee3ca5 でこのコメントは導入されている。うーん。何も議論は残っていな
        い。然し、この時に "キー入力を受け入れられる様にする" のと "プロンプト
        の表示する" のの初期化順序をを入れ替えているので、恐らくやはり echo を
        意識しての事だろう。

        うーん。ble/term/attach に関しても重複初期化を避ける為に変数を設定する
        べきだろうか。と思ったが stty も term/enter もそれぞれに guard を持って
        いるから関係ない? と思ったが、 stty に関しては initialize についての
        guard はない。うーん。然し、ble/stty/initialize は結局 ble/term/attach
        からしか呼び出していないので ble/term/attach が窓口になっていると思って
        良いだろう。

        結局 ble/term/attach の側で guard を入れる事にした。

      [現在の方針]

      * ble/term/initialize: test-STBM のみ。後で関連する requests はここに入れ
        るかも。

      * ble/term/attach: stty/initialize & ble/term/enter

      * ble/term/attach は諸々の端末判定リクエストを送信するより前に実行する事
        にする。ガードを導入して重複して実行されない様にする。

      取り敢えず修正した。

    * DA2 要求も ble/decode/attach の中で出力されている。と思ったら
      ble/decode/attach の中に直接書かれていた。これは util.sh の方に移動するべ
      きではないか → 移動した。

    この書き換えで合計で三回の出力を行う様になった。1. 端末問い合わせ -> (初回
    プロンプト計算) -> 2. 初回プロンプト出力 -> (その他の初期化) -> 3. プロンプ
    ト更新及びその他の情報の初期化

    ? ok: やはり何故修正前は internal としてのシーケンスによる囲みがなかったの
      か? 修正前の振る舞いについて改めて確認する必要がある。

      確認してみた所やはり最初は external の状態で出力がされている。というか出
      力回数が断然多い。何故? 分かった。ble/term/enter の中で _ble_term_state=1
      を設定するのが遅い為である。関数の先頭で _ble_term_state=1 を設定する事に
      する。

    ? ok: 何故初期化回数がこんなにも多い? 単純なプロンプトの場合にも同様の問題
      はあるだろうか

      1 元の設定だと6回描画している。git リポジトリの外側だと5回になるので既定
        で1回は git の判定後の更新だろう。実際最後の更新は idle の中から呼び出
        されている

        % →と思ったが勘違いだった? 改めて試してみたら、別に git リポジトリの外
        % 側でも内側でも変わらないし、.blerc を無効にしてもしなくても変わらなかっ
        % た→と思ったが今改めて実行したらちゃんと減っている。うーん。

      .blerc を空にしても5回使っている。最初の3回は ble-attach による物でこれは
      把握している通りである。端末要求・初回プロンプト・ちゃんとしたプロンプト。
      残りの2回は _ble_util_hook の中から呼び出されている。

      % 1回は char_width_version の判定だろう。更に char_width_@ を事前に設定す
      % る様にしたら更に減って 4 回になった。つまり、文字幅のスキームが改めてちゃ
      % んとした物になった事により再配置が起こったという事 → これは実は回数は
      % 減っていなかった。関係ない。

      残り2回は何だろうか。うーん。プロンプトが再描画されているという事は hash
      等も確認するべき? うーん。別にそうでもない。

      | 実際に出力されている中身を見ると、DA2 判定の様である。つまり、screen の
      | 内部にいるので外側の端末の情報を得る為に追加の要求がされているという事。
      | と思ったが、screen の外側でも 4 回だった。よく見ると modifyOtherKeys を
      | 有効にするシーケンスが走っている。

      つまり、追加の DA2 要求と modifyOtherKeys である。これは実際の描画に関係
      する物ではないので余分な描画をしている訳ではない。

      結局以下の通りになっている。

      1 端末要求、2 初回プロンプト、3 ちゃんとしたプロンプト
      4 DA2追加要求 5 modifyOtherKeys 6 prompt-git による遅延更新

      プロンプトは合計3回描画しているだけでこれは意図した範囲内である。

    ? fixed: 初回プロンプトの描画範囲はどうなっている? 二次プロンプトは省略でき
      るのでは → これは確認してみた所、二次プロンプトも最初から表示している様
      である。省略できる筈。省略用の判定を追加した。

2024-06-22

  * mandb: openSUSE Tumbleweed で fzf のオプション抽出が動いていないそうだ (reported by pallaswept) [#D2230]

    openSUSE に行ったら問題は再現する。実際に確かめてみると、どうも 1 の時点で
    の抽出は問題ないが変換後の抽出で失敗している様だ。よく見ると変換後は何故か
    - - help の様にスペースが入ってしまっている? ソースを見ると - が \- の様に
    エスケープされていない。スペースが入ってしまっていると思ったがそうではなく
    て、全角の hyphen になっているのだった。

    これは fzf が問題なのだろうか。それとも distribution で勝手に \- を - に変
    換している? 後でチェックする。もし fzf の時点での問題だったら修正を提出する。

    然し、fzf についてはこれについて修正したとしても、世の中にはまだこの様に間
    違った形式を使った物があるかもしれない。何より大体ちゃんと \- にしていたと
    してもつけ忘れて - になっている物が混入しているかもしれない。なので、特別の
    ハイフン (‐) は - に変換する事にするのが現実的の気がする。他にも hyphen の
    亜種は色々あると思われるので。

2024-06-20

  * vbell: edit_vbell edit_abell の設定を統合する [#D2229]

    * visible bell vs visual bell? ソースコード上は全て visible になっている。
      audible と対象になっている。一方で wiki では visual bell になっている。元
      の GNU Screen では visual bell である。

    * DECSCNM を使った反転にも対応する? これを visual と名付けるのでも良い気が
      する。これについては visible

    これまで visual/visible としていたのは visible に統一する事にして、新しいベ
    ルの形式として GNU screen と同様の方法を用いる visual を導入する事にした。

2024-06-19

  * vbell: panel 内部に表示する (requested by bb010g) [#D2228]
    Ref: #D2265

    類似の事を過去に考えた事がある様な気がする。ToDo 2021-02-23 に sc..rc の親
    シェルと子シェルの conflict について書いてある。結局、complete menu と同じ
    様に実装するとしても似たような問題が生じる。現在の実装では visible-bell を
    後で消去する為にサブシェルを使っている。これは bash-3.2 以下で idle.do が使
    えないからである。#D1495 にも議論が残っている。しかし bash-3.2 以降であって
    も、有限時間経ってから任意のユーザー入力があった時に消去するというので良い
    様な気もする。

    bash-3.2 では visible-bell の timeout を考えない様にする事にする。ユーザー
    の入力時に一定の時間が経っていたら削除する事にする。そのチェックの為に
    idle.do の代わりの hook を入れておく事にする。というか、idle の仕組みを
    sleep だけでも bash-3.2 の為に実装しても良いのかもしれない? と思ったが用途
    が限られるのでやはり別枠で提供するべき。

    さて、新しく対応するとして何処に表示するべきだろうか。例えば status_line の
    位置に表示するべきか。或いは、info の位置に表示するべきか。それとも新しい
    panel を割り当てるべきか。うーん。info の位置に表示するとすると
    menu-complete の途中で visible-bell が発生した時に駄目になる。

    a info に表示するのはしたくない。既に色々複雑になっているし、例えば menu が
      表示された状態で一瞬だけ menu が消滅してその後で表示されるというのも変な
      感じがする。

    b 或いは小ウィンドウを一瞬だけ表示する可能性? 然し、これも line editor の
      mode とは関係なく後で消去されるという事になるので、その間に下に隠れている
      パネルの描画更新があるかもしれない。それにも対応しようと思うとそもそも現
      在の描画の仕組み自体を大きく変更しなければならなくなる。

    c status_line に表示するという手もあるかもしれないと思ったが、やはり vbell
      は他の処理が走った後に消去されるという形になっているので、例えば vbell を
      表示した後に status_line に更新・再描画があったりした時に変な事になるので
      良くない。

    d やはり新しいパネルに表示する? 現在パネルは以下の様になっている。

      _ble_canvas_panel_class=('ble/textarea' 'ble/textarea' 'ble/edit/info' 'ble/prompt/status')

      うーん。ble/edit/info の次か前に入れるのが良い気がする。取り敢えず実装し
      てしまえば良い気がする。

    * subshell 内部で visible-bell が実行された時の処理をどうするか。うーん。
      subshell 内部でそもそも使っているのか分からない。もし subshell の中で使っ
      ていたら従来の方式に fallback するというのも手である。

      うーん。grc 'ble/term/visible-bell ' で検索する限りでは親シェルでしか使わ
      れない。一方で、元の意図としては subshell からでも使える様にしたいという
      物があった。という事を考えると、やはり subshell から呼び出した時に
      fallback する様にするべき? と思ったが、そもそも subshell から呼び出したと
      すると今までの方法でも問題が起こったのではないか?

    取り敢えず実装したが振る舞いが変だ。

    x fixed: 初期化時の高さが壊れている

      よく分からないがどうも _ble_canvas_panel_height に未初期化の要素があると
      問題が生じる様である。インデックスに跳びがある時に問題になりそうな箇所を
      修正したがそれでも振る舞いは変わらない。

      うーん。最初に panel_height に十分な要素を入れておけば問題は発生しない。
      なので確かに疎な配列になっている事によって問題が起きていると見るべき。然
      し、使用箇所を見ても何処に問題があるのか分からない。

      ble/array#fill-range が怪しいと思ったが、そうでもなかった。呼び出し方的に
      0..#class で初期化しているので、元々あった値が影響を与えるという事はない。

      →色々試して分かった。つまり ${arr[@]:offset:length} は元の index に対し
      て行われるのではなくて、展開した後のリストに対して作用する。因みに連想配
      列でも同様の振る舞いだった。つまり、連想配列でも offset:length は意味を持
      つという事。

      修正は色々考えらえれる。

      a ble/arithmetic/sum を呼び出す前に密になるように修正する。これは難しい。
        ループしてチェックするのだとしたら普通に足せば良かったという事になる。
        普通にループして足した時よりも高速に密になる様に変換する方法は存在しな
        い様に思う。

      b 疎でも動く様に ble/arithmetic/sum の使い方を考える。然し本等の index の
        範囲で filter する方法は存在しないのでこれも難しいと思われる。

      c 初期化の時点でちゃんと密になる様にする。或いは何処かの段階で密になる様
        に補正する。うーん。結局 class を代入した時点で一緒に初期化する様にする
        べきの気がする。それが一番自然である。

      OK. c の方法で修正した。動いている。

    x ok: async-2.idle の待ち時間が変だ。着色が解除されていないのに消される。何
      故?

      これは screen が abell を受け取った時に処理をブロックするのが原因だった。
      実際に処理・出力が行われている時刻を確認した所、ちゃんとタスクはキャンセ
      ルされているみたいだし、最後の描画から消去までの時間も 2s だけちゃんと遅
      延されている。bleopt edit_abell= としたらちゃんと 2s だけ待ってから消去さ
      れているのが確認できた。

    一番上の行を用意しなくても良いのではないかという話もあったが、subshell やそ
    の他の文脈で vbell を表示する時は結局既存の枠組みを使いたいので一番上の行は
    やはり確保しておく事にする。

    * vbell_align の既定値を right に変更した。というか wiki では既定値が right
      になっているのに実際の実装では left になっていた。これは変更するべき。

      ? 今まで何故問題になっていなかったのかと思ったら実は vbell は既定では有効
      ではなかった様だ。ユーザーが単に vbell を有効にすると左上に表示されて内容
      が消されるという事。

    * done: doc: blerc.template ok, wiki en ok, wiki jp

    ----

    2024-08-25 #D2265 bash-3.2 で ble/edit/visible-bell#collapse が
    ble/util/idle.cancel を呼び出してエラーが発生する様になっていた。bash-3.2
    ではそもそも ble/util/idle を使わないので ble/util/idle.cancel を呼び出す必
    要もない。

  * 2024-06-12 util: fdflags を呼び出した時点で bash がクラッシュしている [#D2227]

    何故か分からないが現在の bash と関係ない BASH が設定されていて、その上で互
    換性のない fdflags がロードされて、いざ実際に呼び出しを実行しようとした時点
    で失敗している。

    * fixed: loadable-builtin のチェックとして実際に呼び出してみるというのも追
      加するべきなのか? 実際に確認してみたがやはり enable 時点では問題が起きて
      いなくても実際に呼び出そうとした時点で valid_number がないというエラーに
      なっている。うーん。fdflags --help の場合にはどうなるだろう? うーん。呼び
      出せている…。実際に valid_number を呼び出す段階まで行かないと駄目という
      事か?

      取り敢えず fdflags 0 が成功する事を builtin fdflags を使う条件にする事に
      した。

    * そもそも何故関係ない BASH が設定されているのか? mc の中だけで発生している
      様である。しかも .bashrc の最初からその値になっているという事を考えると誰
      かが勝手に BASH を書き換えたという訳でもない? 然し mc の中だけで値が化け
      ている。mc のソースコードを確認したが別に環境変数を弄るなどのことはしてい
      ない様に思われる。

      不思議だ。

      何故 mc の中で BASH が現在の bash と異なる値になるのか? これは謎に満ちて
      いる → bash は BASH を初期化する上で argv[0] を用いる。一方で mc は
      argv[0] に単に "bash" を指定して bash を起動するので、bash は仕方なく
      PATH から path を拾う。これは mc に patch を送った。詳細は
      akinomyoga/bug-report/mc/report1 にて。

2024-06-17

  * util: DECSET 2026 の対応について考える [#D2226]

    うーん。xterm のちらつきを抑えられると思ったが別に xterm は対応していなかっ
    た。xterm の最近の変更についても確認したが ?1014 (fastScroll) と ?1045 とい
    う新しいモードが増えているが ?2026 は増えていない。fastScroll は関係あるか
    もしれないと思ったが関係なかった。LINES 行スクロールする毎に再描画するモー
    ドで、既定で on になっているそうだ。

    対応はしてみたけれどテストの仕方が分からない。うーん。既存のターミナルの表
    示を破壊している可能性もある。どれかの端末で動作を確認できれば良いが。
    mintty で試してみる事にする。取り敢えず問題なく動いている様に見えるが見た目
    に違いはよく分からない。

    cxxmatrix に実装して振る舞いを見てちゃんと動いているか確認してみる。うーん。
    Alacritty 及び mintty で振る舞いを見たが余りよく分からない。途中で描画され
    てしまう問題は治っていないし寧ろ表示が遅くなっている。途中で描画されてしま
    う問題は実は X11 の遅延の問題かもしれない。一方で、遅くなるのは恐らく余計に
    描画が実行されているからだろう。DECSET 2026 が解除された時に強制的に描画が
    発生するので。近くのホストで試しても同様だった。うーん。屹度 GPU based
    rendering だと常に raster で画面を送ってくるから遅くなるのだろう。

    代わりに手動で適当な printf & sleep で振る舞いを見ると一応ちゃんと期待通り
    に振る舞っているので良いという事にする。

  * mandb: rg に対応する (motivated by pallaswept) [#D2225]

    少し弄ったら git が解析できなくなってしまった。何故? ちゃんと調べる必要があ
    る。或いは mode = "none" にせずにだらだらと解析するべきだったのか? と思った
    ら単純な書き換えミスだった。修正した。

    取り敢えず対応した。未だ抽出できていない物があるが、それらはどうもそもそも
    man に明示的に現れていない様なので諦める事にする。

2024-06-14

  * term: iTerm2 identification [#D2224]

    iTerm2 identification は LC_TERMINAL でできる? 但し ssh で入った時はできな
    いだろう (sshd_config を変更していない限り)。

    LC_TERMINAL=iTerm2 LC_TERMINAL_VERSION=3.4.15 xterm:95 (0;95;0)
    LC_TERMINAL=iTerm2 LC_TERMINAL_VERSION=3.4.16 xterm:95 (0;95;0)
    LC_TERMINAL=iTerm2 LC_TERMINAL_VERSION=3.4.20 応答なし?
    LC_TERMINAL=iTerm2 LC_TERMINAL_VERSION=3.5.0beta10 xterm:2500 (41;2500;0)

    | うーん。0;95;0 は iTerm2 を疑うべき。ローカルで動かしているのであれば
    | LC_TERMINAL をチェックするので OK? 一方で、ssh で入っている時は DA2 を使
    | う? と思ったが、iTerm2 の中から更に別の端末を立ち上げた時に LC_TERMINAL
    | が残っていて影響を与える可能性がある。また、ssh で入っているかの判定をす
    | る時に terminal multiplexer を使っている場合には別の接続時の
    | SSH_CONNECTION が残っている等して判定に失敗する可能性がある。結局信頼でき
    | るのは DA2 だけの気がする。
    |
    | iTerm2 の実装を見ると {0,1,41};xterm-ver;0 を送る様になっている。そして、
    | xterm-ver は設定で変更可能になっている。ソースコードの既定値を見ると今は
    | 2500 になっている。説明が書かれていて pre 3.4.10 は 95 と書かれている。
    | commit 2fef3881 で導入されている。然し commit を見るとこれが最初に入った
    | のは 3.5.0beta である。3.4.11 以降でも別に入っていない。
    |
    | https://github.com/gnachman/iTerm2/commit/2fef388179057cf0090d536350ed644c7d4499d7
    |
    | それ以降は別に変更していない様である。
    |
    | 一方で vtLevel {0,1,41} はどうやって決まるのか。setTermType を元に決定さ
    | れていて、setTermType は _termVariable から来ている。_termVariable は
    | setTermVariable から設定されていて、これは [iTermProfilePreferences
    | stringForKey:KEY_TERMINAL_TYPE inProfile:aDict] から取り出している。これ
    | も規定値は "xterm" っぽい。辿ると VT100, VT2, VT3 の時はそれぞれ 0, 1, 1
    | になり、それ以外は 41 になる気がする。
    |
    | 変更の履歴を辿ると termVariable が xterm になったのは commit 6ee4169c 10
    | 年前 (2.9.2015) からである。関係なさそう。
    |
    | * 2019-05-13 commit d1645a9c では始めて vtLevel が導入された。VT100 =
    |   100, else 200.
    |
    | * 2021-08-14 commit 6c923fab (3.5.0beta) で 0;*;0 をそれまで報告していた
    |   のを <vt>;*;0 に変更している。この時は vtLevel 100 = 0, else 1 で処理し
    |   ていた。
    |
    | * 2021-10-08 commit 33ca789f で vtLevel 400 と対応する vt = 41 を追加して
    |   いる。
    |
    | * 2021-10-08 commit 33ca789f で termType -> vtLevel に於いて、 VT4 -> 400
    |   を追加している。
    |
    | * 2021-10-13 commit 05dd9859 で termType -> vtLevel への変換が変わってい
    |   る。VT100 = 100, VT4 = 400, else 200. だったのを現在の方法に変更してい
    |   る。

    つまり、3.5.0 より前は 0;<xterm ver>;0 だったのが、3.5.0 以降で <vt>;<xterm
    ver>;0 に変更され、更に <vt> は termType <- termVariable <-
    KEY_TERMINAL_TYPE を通して決定され設定で変更可能である (6c923fab)。既定値は
    xterm ver については 95 だったのが 2500 に変更された (2fef3881)。また、vt
    については vt = 41 <- vtlevel = 400 <- termType = xterm <- termVariable =
    xterm <- KEY_TERMINAL_TYPE = xterm と決まっている。

  * canvas: 初期化時の文字幅テストの文字が表示される (motivated by tessus) [#D2223]

    * 文字色を背景色に合わせる可能性について書いたがよく考えると端末の背景色を
      取得する方法はないし、文字色を背景色に合わせる為の指定もない。寧ろ実質
      invis がそれに対応していると見ることができる。

    * reject: DECSET 2026 に関しては対応している端末に対しては入れた方が表示の
      点滅が減って良くなるだろうが、端末側の実装によってカーソル位置の更新をし
      ないまま CPR を戻してくるという事があると動かなくなってしまう。と思ったが
      杞憂かもしれない。しかし実際の端末の実装を全てを調べるのは面倒だ。一方で
      通常の buffer.flush の場合には DECSET 2026 で囲んでも問題ない気がする。な
      ので後で考えても良い。と思ったが buffer.flush の段階で付加するとなると、
      初期化テストも影響を受けてしまう。なので結局端末の振る舞いを調べる必要が
      ある気がする。何れにしても既知の端末でのみ DECSET 2026 を有効にするべきで
      ある。

      (と思ったが文字幅判定をしている時点では通常は端末が分かっていない状態なの
      で DECSET 2026 で CPR が壊れる可能性は少ない? でも改めてユーザーが auto
      を設定した時のこと等を考えると、やはり実際の振る舞いを検証した方が良い気
      がする。)

      →何れにしても DECSET 2026 は独立した項目で処理する事にする

    * reject: 文字幅テストを実行する位置を変更してもよいのでは。起動時 に
      COLUMNS は設定されているのだろうか現在の実装では既定で first-line で画面
      一番上の右端を使っている様な気がする。然し、報告を見ると別にそういう訳で
      もない。うーん。実際に自分の手元で試してみると起動時の検査では現在行を用
      いている様だ。起動した後の追加の判定の時にのみ first-line を用いる様だ。

      起動後の判定の位置を変更できないか? 例えば現在行や最終行など。然し、考え
      てみると現在行の右プロンプトを上書きしてしまうかもしれないし、また、最終
      行も status line を消してしまうかもしれないし、status line が表示されてい
      なかったとしてもプロンプトが画面の一番下にあるかもしれない。そう考えると
      端末の右上というのは実は丁度良い。

      一方でこれは別枠で処理している visible-bell の位置変更とも関係がある? も
      し visible-bell で位置変更をして一番上の行を確保しなくするのだとしたら、
      この判定の為に一番上の行の右端を使う事はできなくなる。と思ったが、そもそ
      も現時点で RI を実行している訳でもないので、その様な状況では何れにしても
      上書きしていたので気にしなくて良いのでは。それに実際に計測を実行するのは
      恐らくコマンドを実行した直後だろうから現在のプロンプトを上書きするという
      事は基本的にない様に思われる。

    取り敢えず invis で実装した。invis は terminfo には解除用のシーケンスが登録
    されていない。ANSI 的には 28 で解除できる筈だが、terminfo にないとなると対
    応していない端末も多いという事になる。結局 sgr0 を実行しなければならないだ
    ろう。幸い sc/rc を用いているので sgr も一緒に保存・復元されると期待したい
    (端末によってはそれすらも正しく実装していない可能性もあるが)。

    ----------

    2024-06-23 未だカーソルが表示されるという報告。
    https://github.com/akinomyoga/ble.sh/issues/460#issuecomment-2184054170

    然し、よく考えたら元々 terminfo を使って civis を指定している筈なのに何故カー
    ソルが表示されているのだろうか。文字幅計測用のシーケンスを送信している時点
    で未だ外側の文脈にいるという事だろうか → 実際そうだった。考えている内に端
    末に関する初期化を整理したくなったので独立した項目にする → #D2231

    ? fixed: 然しやはり変だ。やはり ble/util/buffer.flush は internal の状態で
      出力される筈なので civis や DECSET(2026) は有効になっていた筈ではないのか?
      また後で確認が必要である → #D2231 で修正した。

2024-06-11

  * main: 5.3 check. 表示しない様にするオプションを追加する。説明追加 [#D2222]

    * "bleopt init_check_debug_bash" 等にする? 然し、このチェックを行っている時
      点では未だ bleopt/declare の仕組みを整えていないし、blerc も実行していな
      い。だとすると、この表示を無効化するには source する時の引数として

        source /path/to/ble.sh -o init_check_debug_bash=false

      等としなければならない。或いは設定ではなくてオプションにしてしまう?

      うーん。そちらの方が自然の気がしてきた。

      然し、各 version で最低一回は表示する様にしようと思ったら結局
      _ble_base_cache の初期化後にしなければならないので、それならば .blerc を
      実行してからでも良いのでは? 現在の指定方法の候補は:

        bleopt init_bash_debug_version={check,check-once,ignore}
        ble.sh --bash-debug-version={check,check-once,ignore}

      等の様すれば良い。うーん。初期化時だけに有効という事であればやはりオプショ
      ンで良いのではないか。bleopt にしてもそのセッションでそれ以降に参照する事
      はない。そして、_ble_base_cache が初期化できたらその後に実行すれば良い気
      がする。

2024-06-05

  * global: bash-5.3 posix function name with slashes in POSIX mode [#D2221]

    * done: ble/base/adjust-POSIXLY_CORRECT 削除
    * done: ble/base/unset-POSIXLY_CORRECT 削除

    * done: ble/base/adjust-builtin-wrappers-1 のコメントが気になる。つまり、
      ble/base/adjust-builtin-wrappers-1 を呼び出すと POSIXLY_CORRECT が入った
      儘になってしまう可能性? だとすると ble/base/adjust-builtin-wrappers-1 の
      直後で unset を明示的に呼び出す必要がある?

      履歴を遡る。commit 0860be04 で edit.sh から ble.pp に移動している。
      b3b06f71 cd1826e3 は単なる微修正。366a49a4 で導入されている。一方でこの時
      点では unset POSIXLY_CORRECT は 1 と 2 の間に挟んでいない。

      うーん。間に挟まる様になったのは 07ae3cc2 (#D0871) である。この時には間で
      unset POSIXLY_CORRECT する必要があったというよりも、問題のある unset : だ
      け unset POSIXLY_CORRECT よりも後に移動したという形だった様だ。という事は、
      今、unset POSIXLY_CORRECT を最初に持ってきたので -1 の直後に -2 を持って
      きても問題ないのではないか。

      →再び ble/base/adjust-builtin-wrappers に統合する事にした。

    * done: うーん。 ble-decode/.hook はいよいよ _ble_decode_hook に変更しなけ
      ればならないのだろうか。一応古い実装との互換性の為に ble-decode/.hook も
      残しておく? と思ったが、ユーザーが直接使いそうな物はない気がする。

      →取り敢えず変更した。bind -X の解析などのチェックしている箇所も更新する。

      それより cache に色々残る様なのでちゃんと更新される様にする

      →これもちゃんと更新される様に init-cmap.sh に追記した。init-bind.sh の方
      についてはこのファイル自体が変更されるので自動的に更新される。

    * done: 様々の builtin emulation で adjust/restore をする必要があるのでは?
      しかも nest level も考慮しなければならないのでは? 或いは、外側の状況を再
      現すれば良いので、local に状態を記録すれば OK?

      というか単に local POSIXLY_CORRECT を宣言すれば良いだけの話では? (但し
      localvar_inherit には注意) と思ったが試してみた所、3.0..4.3 で
      POSIXLY_CORRECT の place holder が存在するだけで POSIXLY_CORRECT が有効だ
      と判断される様だ。なので local POSIXLY_CORRECT する訳には行かない。

      加えて 3.0..3.1 では関数内で local POSIXLY_CORRECT するとその効果が関数を
      出ても持続してしまう。

      対象の builtin: bind exit history read readonly sleep trap

      更に function ble 及び其処から呼び出されている物にも対応した。
      一方で、更に他にも関数がある。

      - ble-color-defface
      - ble-color-setface
      - ble-color-show

        これらは deprecated なので対応しない。と思ったが adjust-bash-options に
        ついてはちゃんと対応しているみたいなので POSIXLY_CORRECT についても序で
        として対応する事にした。

      - ble-decode-byte
      - ble-decode-char
      - ble-decode-kbd
      - ble-decode-key
      - ble-decode-unkbd

        これらは内部で使っている関数なので対応しない。その内に関数名を変更した
        い。

      - ble-import
      - ble-autoload
      - ble-measure
      - ble-append-line

        これらには対応した。コマンドラインから呼び出す事がありそう。

      - ble-assert
      - ble-stackdump

        これもどちらかと言うと内部で使う関数の気がする。対応しない事にする。うー
        ん。然し、内部で使うのは ble/util/{assert,stackdump} である。という事を
        考えるとやはり対応するべきの気がする。

        取り敢えず内部で ble-assert を使っている箇所が二箇所あったのでそれは
        ble/util/assert に置き換える。一方で、ble-stackdump は内部敵意は何処に
        も使っていなかった。

      - ble-histdb
      - ble-histdb-*

        これは ble-histdb だけ対応すれば良い気がする。と思ったが他の関数はそも
        そも古い histdb.bash に含まれている関数であって現在のバージョンにはなかっ
        た。ble-histdb で対応した。

    * gexec の .save-lastarg 及び .epilogue はちゃんと / のない関数名にする必要
      がある → 関数名を変えた。これは仕方がない。諦める。

    x reload 時に以下の様なエラーが出た。然し再び実行しても出ない。古い version
      から新しい version に更新する時に出るのだろうか?e

      > bash: unalias: builtin: 見つかりません
      > ...
      > bash: unalias: function: 見つかりません
      > bash: alias: :: 見つかりません
      > bash: unalias: :: 見つかりません

      これは恐らく ble/base/unload-for-reload の時点で
      adjust-builtin-wrappers-{1,2} が置き換わっているが、未だそれを直接呼び出
      しているコードが残っている為に起こっているのだろう。対策の方法は二つある。

      a adjust-builtin-wrappers-{1,2} の関数名を変更する。関数に非互換な変更を
        与えたのに同じ名前を使っているせいで、以前の版が上書きされてしまうのが
        問題である。

      b 或いは adjust-bultin-wrappers-{1,2} で引き続き 2>/dev/null を実行する。

      一旦は b で対処したが a の方針で修正するべきの気がしてきた→修正した。

  * 2024-03-23 main: SUSE で何故か正しく初期化できない (reported by Anyborr) [#D2220]
    https://github.com/akinomyoga/ble.sh/issues/424

    SUSE という事なので /etc/inputrc を疑ったが関係なさそうだ。bultin bind -spX
    の内容を確認したが \C-x\C-x -> 24 という余分な物が含まれている事以外は特に
    問題は無いように見える。

    * ok: 何故 \C-x\C-x -> 24 になっているのか? emacs editing mode 特有の問題か
      もしれない → そうだった。emacs editing mode では \C-x\C-x が 24 になって
      いた。これについては後で振る舞いを確認する必要がある?

      →複数の bash versions で確認した所この現象が起こっているのは bash-4.4 だ
      けである。以前にこれについて色々試して bash44 では仕方がないとした事の様
      な気もしないでもない。後で確認する → init-bind.sh を見ると explicit に
      bash-4.4 で emacs mode の時にだけ C-x C-x に 24 を割り当てている。コメン
      トに依ると insert dummy entry in cmd_xmap と書いてある。上のコメントの
      [対処法 3] の部分に説明が書かれている。一旦 \C-x\C-x で 24 を設定してから
      bind -r で削除するという事らしい。これで timeout で C-x が受け取れる様に
      なるらしい。builtin bind -X の出力に残っているのは古い bash で cmd_xmap
      に登録した物が二度と削除されない問題があった為である。

    * どうも受信時はちゃんと 192 になっているが decoder の途中で NUL に化けてし
      まっている様である。うーん。UTF-8 decoder が壊れているという事? と思った
      が 192 91 67 を受信している。ESC は 192 ではない。自分の手元 (bash-4.4,
      emacs editing mode) で試す限りは 192 155 91 65 等が受信される。つまり 155
      の受信に失敗しているという事。builtin bind -spX を見る限りは特に違いはな
      い筈なのである。

      うーん。例えば /etc/inputrc でおかしな設定がある事によって状態が壊れて、
      その上で bind を色々実行しても bultin bind -spX に現れない所で壊れていて
      ちゃんと動かないという可能性?

      Readline が /etc/inputrc を読み取らない様にする事は可能だろうか?

      * セッションがスタートした後に source ble.sh する場合は手遅れなので何もし
        ない。

      * まだ readline が初期化されていない状態で INPUTRC=/etc/inputrc を読み込
        まない様にするにはどうすれば良いか? 最初に builtin bind を実行する時点
        で INPUTRC=/dev/null を指定しておけば良いのではないか→試してみた所これ
        で /etc/inputrc は読み込まなくなる。

        | diff --git a/ble.pp b/ble.pp
        | index 41bde79a..f7ec6efa 100644
        | --- a/ble.pp
        | +++ b/ble.pp
        | @@ -610,7 +610,16 @@ function ble/base/recover-bash-options {
        |
        |  { ble/base/adjust-bash-options; } &>/dev/null # set -x 対策 #D0930
        |
        | -builtin bind &>/dev/null # force to load .inputrc
        | +if [[ $OSTYPE == *suse* && -s /etc/inputrc.keys && -r /etc/os-release ]] &&
        | +     ((BASH_VERSINFO[0]*10000+BASH_VERSINFO[1]*100<50100)) &&
        | +     [[ $(< /etc/os-release) == *'SUSE'* ]]
        | +then
        | +  # Note (#2189): SUSE /etc/inputrc.keys may break even Readline's internal
        | +  # state, so we suppress loading /etc/inputrc in SUSE by specifying INPUTRC.
        | +  INPUTRC=/dev/null builtin bind &>/dev/null
        | +else
        | +  builtin bind &>/dev/null # force to load .inputrc
        | +fi
        |
        |  # WA #D1534 workaround for msys2 .inputrc
        |  if [[ $OSTYPE == msys* ]]; then

        x と思ったが、そもそも bashrc の中で source out/ble.sh を実行した時には
          問題は起こっていない? うーん。不思議だ。そうだとするとこの workaround
          を追加する意味がない。

    応答がないがこのままだとずっと新しい version を push することができない。元々
    中途半端な修正で push したくなかったがもう返事もなさそうなので現状の対策で
    push することにする? と思ったがこの修正自体ほぼ修正も何も含まれていない
    commit なのでやはり余り push したくない。順番を skip するか?

    2024-06-05 これもずっと pending になっていて返事もないので現状の小さな修正
    を取り敢えず master に入れる事にする。

  * 2024-05-27 zellij で panel が消えない (reported by gvlassis) [#D2219]
    https://github.com/akinomyoga/ble.sh/issues/450

    confirmed

    これは zellij 自体の問題に違いないという気がする。

    どうやら分かった。DECSTBM に実装していないのに実装していると判定されている?
    確認すると実装している様に見える。

    % * 先ず、zellij は \e[;r を \e[1;1r と解釈する様になっている様だ。
    %
    %   なので単に \e[1;1r が無視されるだけでなく、更に別の設定になってしまって
    %   いるという事。従って単に 2 行目に居るかどうかで判定はできない。
    %
    %   と思ったが試してみた所ちゃんと 3 行目に移動する事ができている。うーん。
    %   或いは初めから範囲外に CUP で移動しているので DECSTBM が動作していない
    %   という事? 代わりに \e[;r に設定して先頭から CUD してみたがちゃんとカー
    %   ソルは下に移動する。また、振る舞い的に \e[1;1r とは異なる様だ。具体的に
    %   どの様に振る舞っているのか確認する必要がある。
    %
    %   うーん。よく分からないので zellij 自体に手を入れてデバグ使用と思ったが
    %   ビルドに滅茶苦茶時間がかかる。リンクだけで4分かかる。然しデバグビルドに
    %   すると今度はそもそも使えないぐらいに遅くなるのだろう。
    %
    %   どうやら bottom は usize ではなくて Option<usize> の様だ。つまり、None
    %   が入っていると考えるべき。None が入っている時の振る舞いは一体どうなって
    %   いるのだろうか。単に 1 等を指定した時と違うのだろうか。とにかく zellij
    %   での振る舞いを確認して、可能であれば zellij の振る舞いに合わせて範囲を
    %   設定するし、そうでなければ DECSTBM 自体の使用を zellij では諦める。

    * どうも単に \e[1;1r となっているのではなくて \e[1;r になっている様だ。この
      時の振る舞いは何も設定しないのと比べて何か違いが出るのだろうか。うーん。
      例えば端末の一番下に行った時の振る舞いが違うという事? 然しそれはそれで変
      な気もする。スクロールしなくなるという事なのでは?

      取り敢えず変な動作一つ目を発見した。どうやら \e[1;r とすると、二つ目のフィー
      ルドは terminal の高さに設定される様だが、この高さは LINES とは一致しない
      様だ。

      $ printf '\e[1;r'                 ; seq 999; printf '\e[r' ... これは駄目
      $ printf '\e[1;%dr' "$LINES"      ; seq 999; printf '\e[r' ... これは OK
      $ printf '\e[1;%dr' "$((LINES+1))"; seq 999; printf '\e[r' ... これは駄目

      恐らく内部的な高さと LINES が一致していなくて変な範囲を scroll しようとし
      てこうなっているのではないかという気がする。

      またソースコードを見て気付いた。index となっているのに直接 height を代入
      している。これは -1 しなければ変な事になる。バグ一つ目。

    しかしこれを修正したとしても本質的な問題は変わっていない気がする。何故? 改
    めて振る舞いについて調べる。うーん。治った? と思ったがやっぱり治っていない。

    ビルドに一々時間がかかるのでよく分からない。しかも cargo xtask build などが
    ちゃんと動いているのかもよく分からない。cargo install --locked --force
    zellij としても修正前の物がインストールされている? 弄っているのは
    zellij-server なので。

    * 振る舞いを調べたら簡単に再現できた。というかそもそも panel を消去するのに
      ble.sh は大した事もしていなかった。\e[20M をしているだけで、しかしこれが
      zellij は処理できていない。

      reproducer も簡単だった。

      $ seq 10; printf '\e[10A\e[10MHello, world\n'

      以下の commit が怪しいがよく分からない。

      https://github.com/zellij-org/zellij/commit/cd5ddd1d2995fd7495b223e17809247b19cfc4dd#diff-eee6f90451a46a505ddbce570e7aa27ed44e8bfe38f0ff928061861cfb5602efL1246

    修正を zellij に提出してマージされた。然し、肝心の報告者から返信がない。

    2024-06-05 返事がないが面倒なのでもう done の方に送る事にする。util.sh を微
    妙に修正仕掛けたが結局 zellij の実装の問題であって、検出するのも難しそうだ
    し、zellij の古い version を使い続ける人もいない気がするので良い事にする。
    zellij の検出もしない事にする?

    > diff --git a/src/util.sh b/src/util.sh
    > index 5fbdb3b2..6b671183 100644
    > --- a/src/util.sh
    > +++ b/src/util.sh
    > @@ -7091,32 +7091,41 @@ function ble/term/quote-passthrough {
    >
    >  _ble_term_DECSTBM=
    >  _ble_term_DECSTBM_reset=
    > -function ble/term/test-DECSTBM.hook1 {
    > -  (($1==2)) && _ble_term_DECSTBM=$'\e[%s;%sr'
    > -}
    > -function ble/term/test-DECSTBM.hook2 {
    > -  if [[ $_ble_term_DECSTBM ]]; then
    > -    if (($1==2)); then
    > -      # Failed to reset DECSTBM with \e[;r
    > -      _ble_term_DECSTBM_reset=$'\e[r'
    > -    else
    > -      _ble_term_DECSTBM_reset=$'\e[;r'
    > -    fi
    > +_ble_term_DECSTBM_test=()
    > +function ble/term/test-DECSTBM.hook {
    > +  ble/array#push _ble_term_DECSTBM_test "$1"
    > +  if ((${#_ble_term_DECSTBM_test[@]}==2)); then
    > +    local test1=${_ble_term_DECSTBM_test[0]}
    > +    local test2=${_ble_term_DECSTBM_test[1]}
    > +    case $test1:$test2 in
    > +    (2:3)
    > +      # \e[;r is working as expected to reset the range.
    > +      _ble_term_DECSTBM=$'\e[%s;%sr'
    > +      _ble_term_DECSTBM_reset=$'\e[;r' ;;
    > +    (2:*)
    > +      # Otherwise, the terminal is expected to not support the overloading of
    > +      # DECSTBM and SCORC for "CSI r", and thus we expect \e[r can be used to
    > +      # reset the scrolling region.
    > +      _ble_term_DECSTBM=$'\e[%s;%sr'
    > +      _ble_term_DECSTBM_reset=$'\e[r' ;;
    > +    esac
    >    fi
    >  }
    >  function ble/term/test-DECSTBM {
    >    # Note: kitty 及び wezterm では SCORC と区別できる形の \e[;r では復
    >    # 帰できない。
    > +  _ble_term_DECSTBM_test=()
    > +
    >    local -a DRAW_BUFF=()
    >    ble/canvas/panel/goto-top-dock.draw
    >    ble/canvas/put.draw "$_ble_term_sc"$'\e[1;2r'
    >    ble/canvas/put-cup.draw 2 1
    >    ble/canvas/put-cud.draw 1
    > -  ble/term/CPR/request.draw ble/term/test-DECSTBM.hook1
    > +  ble/term/CPR/request.draw ble/term/test-DECSTBM.hook
    >    ble/canvas/put.draw $'\e[;r'
    >    ble/canvas/put-cup.draw 2 1
    >    ble/canvas/put-cud.draw 1
    > -  ble/term/CPR/request.draw ble/term/test-DECSTBM.hook2
    > +  ble/term/CPR/request.draw ble/term/test-DECSTBM.hook
    >    ble/canvas/put.draw $'\e[r'"$_ble_term_rc"
    >    ble/canvas/bflush.draw
    >  }

    但し terminal id については zellij と alacritty でもう少し頑張っても良いか
    もしれない。zellij は 4001 等の様な感じにしている。Alacritty も似たような物
    だが zellij は既に 40 に行っているのに対して alacritty はそんなに上がる気配
    がない。取り敢えず適当な値で判定する事にした。コメントに詳しく書く。

2024-06-03

  * util: ble/util/buffer.flush >&2 の redirection を既定で行う [#D2218]

    そもそも ble/util/buffer.flush を毎回手で redirection しているがこれは
    ble/util/buffer.flush 自身が tui に対して redirect するべきなのでは?
    ble/util/buffer.flush の初期化の順序などもちゃんと考慮に入れる。

    →呼び出し元をチェックしてみると test を除いて全て >&2 を指定している。これ
    は ble/util/buffer.flush 自体に tui_stderr への redirection 含めてしまうの
    が自然である。或いは、別の関数を用意する。ble/util/buffer.tflush か
    ble/util/buffer.flush-tui か ble/util/buffer.

    うーん。結局 ble/util/buffer.flush の振る舞い自体を変更する事にした。色々カー
    ソルを隠すなどの非自明な処理もしているので元より TUI 専用の関数になっている
    気がする。

    * ok: 初期化順序も大丈夫。stderr は L3487 で変数にコピーしていて、
      ble/util/buffer の初期化は L4646 である。なので、_ble_util_fd_tui_stderr
      は自由に使える。

    * done: 1>&2 は >&2 に標準化する。

  * edit: fix standard streams in EXIT trap with ble/widget/exit [#D2217]
    Ref: #D2265

    EXIT trap 実行時に tui streams にリダイレクトする?

    [結論] EXIT trap が exit 呼び出し文脈の標準ストリームで呼び出されるのは
    bash の昔からの動作である。Bash-4.4..5.1 でだけトップレベルの標準ストリーム
    で呼び出されていた。従って、EXIT trap 時に呼び出し文脈の標準ストリームを用
    いる動作は保持する。一方で ble/widget/exit や ble/prompt/timeout については
    呼び出し文脈の標準ストリームが潰されていたので修正した。その他細かい修正が
    幾つかある。

    ----

    ble/debug/profiler で EXIT で終端処理をする時も progress を表示する様に変更
    しようと思ってコードを確認してみた所、別に意図的に隠していた訳ではないとい
    う事が分かった。bash の EXIT trap の処理の仕方の変更によって出力が外に伝達
    しない様になっていたのだった。というか、EXIT の trap の処理側で /dev/tty に
    繋ぎ直すべきなのでは。

    最近色々と問題があった様な気がするのでその時の対策は一旦解除する? と思った
    が最近の変更は bash のもっと別の振る舞いに関係する物であって関係なかった。

    その他の _ble_util_fd_.*_std.* 等にリダイレクトしている箇所で振る舞いを確認
    する。

    * 影響確認: 一つずつ関係のありそうな部分を拾っていく。特に EXIT の内部での
      振る舞いを調整する目的の redirect を確認する。

      先ず、 ble.pp の中の unload における redirection が関係ある。

      →修正しなければならないと思ったが、unload に関しては実はユーザーが直接呼
        び出した時に redirect されていても変な事になるので、EXIT で呼び出されて
        いるかどうかに関係なくやはり redirection しなければならないのではないか。

      contrib/integration の fzf, nix completion に関しては EXIT には関係ないだ
      ろう。

      util.sh の term/update-winsize でリダイレクトしている。EXIT の中で呼ばれ
      る事もあるのでは? と思ったがこれは unload の中で呼ばれる気がするのでここ
      で気にしなくても良い気がする。

      history.sh の利用は bash-3.2 以下で builtin history が無限ループになるの
      を防ぐ目的の workaround で使われている。これは EXIT には関係してこないだ
      ろう。

      core-complete.sh の check-cancel に関しても同様に関数の側で redirection
      するべきなのではないか? と思ったがリダイレクトが必ずしも必要とは限らない。
      これらの redirection は別の理由で suppress されているのを拾う為の物?  後
      で調べる → 見た限り様々な箇所で check-cancel はそのままで呼び出されてい
      る。という事を考えるとやはり現状のままで良い気がしてきた。わざわざ新しい
      関数を用意する程でもない様に思われる。

      edit.sh の prompt のエラーメッセージに関しては EXIT とは直接関係ない。

      edit.sh の prompt/timeout/process に関しては idle.do の内部で実行される物
      なので EXIT の redirection の問題にはならない。

      ble-edit/attach/TRAPWINCH は状況は似ているが EXIT は関係ない。

      ble-edit/exec:gexec/.TRAPDEBUG の中の redirection は INT の処理の部分なの
      で関係ない。ble-edit/exec:gexec/.TRAPINT も同様に関係ない。

      ble-edit/exec:gexec/invoke-hook-with-setexit については今回と類似の理由で
      ユーザーが設定した hook に対して redirection を実行している。これは tui
      に繋いでいる。ble-edit/exec:gexec/.prologue の中で PS0 の出力を tui に繋
      いでいるのは、この時点で既に cmd に繋いでしまっているのでそれを回避する為
      である。実は invoke-hook-with-setexit の redirections も同じ理由だったと
      思われる。

      →それなら一括で外側で redirections するか cmd のリダイレクションも毎回実
      行する様にすれば良かったのでは? と思ったが add-cloexec 等の処理も考えると、
      まあ現在の様な処理でも仕方がない気もする。

      ble-edit/exec:gexec/.epilogue で buffer が redirection しているのは関係な
      い。

      ble/exec/time/times.parse-time の redirection はよく分からない。この関数
      は何も出力していない気がする。或いはデバグの為にエラーメッセージを取り出
      そうとした物が残留している?

      →別に更に外側で 2 を読み取っているという訳でもない様だ。この redirection
        は初めに時間計測に対応した時 2b28bece #D1756 の時から存在していた様だ。

      ble/exec/time#calibrate でも何も出力しない筈のリダイレクトしているが、こ
      れは単に 2 を別の用途 (時間計測) で使っていて関係ない出力が混入しない様に
      する為の物である。だからと言って、何故外側の 2 ではなくて /dev/tty なのか
      は不明であるが。

      ? ok: これは外側の 2 に繋ぐ様に修正するべきではないか? と思ったが、どうも
        見てみるとこれは実際に gexec でコマンドを実行する時の redirection の形
        を再現しようとしている様だ。なので、今のままで良い。

        意図がわかる様にコメントを加えた。また現在の設定に近くなる様に
        redirection を更新した。(但し、測定開始と測定終了の外側での処理なので実
        際にどれだけ影響があるのかは分からない)

      * fixed: core-complete.sh の ble/complete/util/eval-pathname-expansion で
        行われているリダイレクトは何だろう? これは check-cancel に渡す /dev/tty
        を stdin vs stderr で間違えていたりしないか? これは確認する必要がある。
        commit c89aa2377 で /dev/tty の redirection が追加されている。同時に
        check-cancel が追加されている。

        > diff --git a/lib/core-complete.sh b/lib/core-complete.sh
        > index 8a11d28e..afcb7caf 100644
        > --- a/lib/core-complete.sh
        > +++ b/lib/core-complete.sh
        > @@ -1753,11 +1753,13 @@ function ble/complete/util/eval-pathname-expansion {
        >      local sync_opts=progressive-weight
        >      [[ :$comp_type: == *:auto:* && $bleopt_complete_timeout_auto ]] &&
        >        sync_opts=$sync_opts:timeout=$((bleopt_complete_timeout_auto))
        > +
        >      local def
        >      ble/util/assign def 'ble/util/conditional-sync "$sync_command" "" "" "$sync_opts"' &>/dev/null; local ext=$?
        >      ((ext==148)) && return 148
        > +    ble/complete/check-cancel && return 148
        >      builtin eval -- "$def"
        > -  fi
        > +  fi 2>/dev/tty
        >
        >    ble/array#reverse dtor
        >    ble/util/invoke-hook dtor

        これは如何にも怪しい。多分間違いだ。修正する。

      * done: /dev/tty に直接 redirect している箇所は他にないか? →ない様である。
        何れもコメント内部か、初期化時の確認か、或いは初期化時の /dev/tty の記
        録でしか使っていない。或いは、contrib の中の処理。

    ? また別の疑問として、もし EXIT が trap EXIT を置き換える物なのだとしたら勝
      手に redirection するのは良くないのでは? と思いつつ、従来の設定ではトップ
      レベルで呼び出される事を想定していたのだろうし、通常は EXIT に登録する
      hook は一番外側に std streams が繋がっている事を想定するだろう。変な物に
      繋がっていたとしてもそれを有効に使う方法が存在するとは思えない。なので、
      EXIT トラップの側でリダイレクトを実行してしまって問題ない。

      一方で、EXIT トラップの側でリダイレクトを実行するとしてそれが tui 側に繋
      がっているべきか cmd 側に繋がっているべきかは謎である。例えば端末の状態を
      元に戻す為のシーケンスを送るとして、それはどちらの端末に送るべきか?  それ
      がコマンド実行時の端末に向けてのシーケンスだった場合にはそちらに送るべき
      だし、或いは、プロンプトを含めたシェル設定に対しての物だったら tui 側に送
      るべきである。

      うーん。ble.sh 的には自分の tui に関連して端末の設定が変に変更されている
      という事は想定したくないので、ユーザーが設定するのは cmd に対する処理と想
      定して良い気がする。その場合には結局現在の unload の redirection は削除で
      きないのではないか? 然しその場合に ble.sh session がなくなった後にもその
      端末が持続するのかという別の疑問もある。うーん。面倒なので tui 側に繋ぐと
      いう事で良い気がする。

      OK 取り敢えず tui 側に繋ぐという事で良い事にする。

    EXIT を呼び出している箇所を探す。うーん。EXIT 特有の処理を行っているという
    訳でもない様だ。うーん。EXIT の時には外側の standard streams に関係なく、も
    う勝手にリセットしてしまって良いのではないか。EXIT trap が実行された後に何
    かコマンドが実行されるとも思えないので。

    →と思って修正しようとしたら逆向きの redirection が実は既にあった。昔は
    EXIT は最後に呼び出した場所での standard streams になっていた様だ。4.4..5.1
    でトップレベルで実行される様になって不都合が生じた。という事になっている。
    だとすれば、やはり EXIT は exit が呼び出された瞬間の streams に繋いだ状態で
    実行するべき? そもそもそうしないと行けなかったのは何故だったか?

    これは #D1782 (f62fc04f) で説明されていた。とにかくトップレベルの streams
    に繋がっているのは 4.4..5.1 だけで、他は基本的に関数内で exit が実行されて
    いた様だ。然し、別に積極的に exit の呼び出し文脈の streams に繋ぎ直す必要は
    ない様に思われる。一番外側に繋いで置けば良かったのではないか? 然し、わざわ
    ざユーザーの設定した EXIT に対する振る舞いを変える程でもない様な気がしてき
    たので、やはり EXIT に関しては各 hook が時前でちゃんと redirect する様にす
    る事にした。

    ? fixed: 然し、exit 呼び出し文脈での streams を復元しているのだとすれば、何
      故 profiler/stop from EXIT で外側に出力されなかったのだろうか。

      →これは ble/widget/exit から直接 builtin exit 0 &>/dev/null を実行してい
      るからだった。ble/widget/exit の中からでもちゃんと終了する為に
      ble/builtin/exit を用いて終了する事にした。重複したジョブのチェックをスキッ
      プする為に _ble_builtin_exit_processing=1 を設定して呼び出す。

    ----

    2024-08-25 #D2265 bash-3.2 で C-d で終了できなくなっていた。bash-3.2 は
    trap で C-d を受信するが、trap 内では ble/builtin/exit の動作が制限されてい
    る。この修正で明示的な builtin exit の呼び出しを ble/builtin/exit に置き換
    えた事で問題が発生していた。bash-3.2 の trap USR1 経由の trap handler 内部
    では trap 用の特別処理を無効にする事にした。

  * debug: 関数呼び出しツリー [#D2216]
    Ref #D2207

    取り敢えず D2207.measure.sh から移植した。

    * done: C0 を一括で変換してしまっているが主だった文字については ^[, ^G, ^H,
      ^I, ^K, ^L, ^M 等に変換して良いのではないか?

    * done: html 形式の時のラベルに esc で色がついている。これらは除去するべき。
      また、末尾の : も邪魔である。

    * ok: 終了時も progress を表示する → これは別の問題という事が分かった
      #D2217

    * ok: flame graph も追加する? これは TUI で表現するのも難しいので取り敢えず
      は別項目にする事にする。

    * done: func も html 形式に対応しないとバランスが悪い気がする。というか、本
      来はfunc の方が html で見たい物なのではないか。

    * debug_profiler_opts の documentation
      * done: blerc
      * done: wiki

  * 2024-05-25 mc でまた動かなくなっている (reported by u/satanicllamaplaza) [#D2215]
    https://www.reddit.com/r/linux4noobs/comments/1cz5kd7/midnight_commander_help/

    | コメントで 785267e1 で動かなくなったと返信した。単に add-cloexec の処理を
    | 外しても問題は解決しない。
    |
    | 或いは具体的に処理がどの様に進んでいるのかを確認したら分かるだろうか? 調
    | べてみた感じだとコマンドの実行まではちゃんとできている。
    |
    | うーん。或いは prompt の出力先が変になっている可能性?
    |
    | * 何故か ble.sh の開発に使っている shell から起動した場合には問題はなく
    |   mc を起動する事ができる。起動できる場合と起動できない場合の違いは何だろ
    |   う。更に同じくらい古そうな別のタブでは起動できない。
    |
    |   * _ble_util_fd_{tty,tui,cmd}_std{in,out,err} の接続先を確認してみたが別
    |     に異常はない。起動できる場合と起動できない場合で比較してみたが本質的
    |     な違いはない様に見える。
    |
    |   * 或いは環境変数が異なる可能性? 動く環境では READLINE_LINE
    |     READLINE_POINT が存在する。_fzf_git_cat 及び fzf の PATH が登録されて
    |     いる。PWD/OLDPWD/LINENO (bash) が異なる。WINDOW (screen) が異な
    |     る。_ble_util_fdlist_cloexit が異なる。
    |
    |   何と環境変数をロードしてから起動したら動く。と思ったが違った。何も修正
    |   しなくても動く。ディレクトリが同じだったから動いただけ? そうでもない。
    |   別の新しいセッションで実行しても別に違いは見られない。
    |
    |   * 改めてほぼ同じ session で違いを見てみるとどうも fd 10 が何処に繋がっ
    |     ているのかが異なる気がする。或いはその他に違いはあるだろうか。
    |
    |     然し、ls /proc/self/fd で表示すると何れの fd も閉じられているので関係
    |     ない気がする。
    |
    |   % うーん。そもそも exec 10>/dev/null 等として bashrc で開いて置いた物が
    |   % histdb の fd によって上書きされてしまっている。どういう事か? うーん。
    |   % これは単に 10 が既に ble.sh で使われている fd であって ble.sh が
    |   % cloexec に指定している為に、ble.sh が残留 fd と思って削除しているだけ
    |   % だった。
    |
    | * 改めて add-cloexec を除いた時にどうなるか確認する。うーん。やはり
    |   add-cloexec を何もしない関数に置き換えても問題は解決しない。
    |
    |   また、stdout/stderr/stdin の特別なコピーをやめて単に 0,1,2 から exec で
    |   コピーする様に変更しても問題は変わらない。
    |
    | * どうやら問題のあるセッションからだと bashrc が空だったとしても mc の起
    |   動に失敗する様だ (DEBUG=1 mc)。一旦空の bash を途中で起動すると、その中
    |   では mc の起動に成功する (DEBUG=1 bash [RET] mc)。また、ble-detach した
    |   環境で mc を実行しても問題は発生する。
    |
    | 呼び出し元の bash セッションで fdflags を使っているかどうかで違いが生まれ
    | る様だ。また、fdflags を使わない実装でも cloexec を付加していると問題が生
    | じる。
    |
    | fdflags を使って 10, 11 に +cloexec を実行すると mc が起動しなくなる。一
    | 方で、その後に 10, 11 から cloexec を取り除くと動く様になる。不思議だ。10
    | と 11 のどちらが効いているのか調べる。うーん。10 か 11 のどちらか一方でも
    | cloexec がついていると失敗する。
    |
    | plain Bash でも再現するか試してみた。まず、fd を全て閉じていたとしても問
    | 題のあるセッションから起動した bash --norc の中では結局問題が持続している。
    |
    | - 一度 exec で 10 と 11 に何か割り当てると問題がなくなる。
    |   - 然し、そこで再び fd で何か割り当てると失敗する様になる。
    |   - 代わりにまた exec 10>&- 11>&- で fd を削除すると動かなくなる。
    |
    | うーん。mc 自体が 10, 11 に fd が存在しているという事を期待しているという
    | 事なのだろうか? うーん。mc-wrapper の redirection か何かが悪さをしている
    | かと思ったが /usr/bin/mc で試しても症状は変わらない。
    |
    | そうなると次の疑問は普通にログインした時に 10, 11 がなかったらどうなるの
    | かという事。うーん。別にちゃんと mc は動いている。しかも、この場合には
    | 10, 11 が cloexec を持っているかどうかは関係なくて、mc の中で ble.sh が初
    | 期化されているかどうかで振る舞いが変わっている? うーん。
    |
    | とここで何だか分かった様な気がする。mc が用意した fd が 10, 11 に割り当て
    | られているが、_ble_util_fdlist_cloexec に登録されている物と被っている為に
    | ble.sh が勝手に削除してしまっている? 初期化時に fd 10 11 等が何処に繋がっ
    | ているかを確認する必要がある。
    |
    | 確認した。これだった。

    % デバグ用コード
    %
    % if [[ $command == *PS1* ]]; then
    %   #ble/debug/print-variables -t "$FUNCNAME" _ble_edit_str KEYS CHARS >> ~/a.txt 2>&1
    %   #ble/debug/print-variables -t "$FUNCNAME" _ble_util_fd_{tty,tui,cmd}_{stdin,stdout,stderr} >> ~/a.txt 2>&1
    %   for v in _ble_util_fd_{tty,tui,cmd}_{stdin,stdout,stderr}; do
    %     echo "$v"
    %     ls -la "/proc/$$/fd/${!v}"
    %   done
    % fi >> ~/a.txt 2>&1

    [まとめ] 発生条件は、外側のシェルで cloexec 指定した fd を
    _ble_util_fdlist_cloexit で export している時に、mc の内側で ble.sh を初期
    化すると発生する。cloexec している fd は自動的に閉じられて、その後で mc が
    自分で準備した fd が _ble_util_fdlist_cloexit で閉じられた fd と一致する値
    に割り当てられる。この状態で ble.sh を初期化すると、mc が用意した fd を勘違
    いして閉じてしまう。mc が用意した fd に対しては pwd や
    READLINE_LINE,BASH_VERSINFO,READLINE_POINT 等が書き込まれる筈だがこれが受信
    できないので mc は初期化に失敗したと見做す。

    修正について

    * done: 先ず、_ble_util_fdlist_cloexit が他の場所で使われていないか確認する。
      うーん。別の用途で使われている。分離するべきの気がす
      る。_ble_util_fdlist_cloexec を用意する事にする。

    * done: cloexit に登録している fd が tty の時には tty である事のチェックも
      行う。

      先ずこちらの修正を行う事にする。これでテストしようと思ったが、どうも 10,
      11 に来るのは histdb の pipe の様なので単に tty かどうかだけでは判定する
      事はできない。

      * done: うーん。或いは readlink を使ってチェックするというのもありなのか
        もしれない。そちらの方が確実である。これで procfs が利用できるシステム
        ではかなり確実に判定できる様になっただろう。何れにしても fd#add-cloexec
        がちゃんと動いている限りは問題ない筈。

    * done: cloexec に対応している場合には _ble_util_fdlist_cloexit に登録しな
      い。

      _ble_util_fdlist_cloexit を使っている他の箇所はないか? その場所ではちゃん
      と閉じる様にしなければならない。

2024-06-01

  * decode: kitty で ESC が動かなくなった (reported by gvlassis, 10b14224cc, lokxii) [#D2214]
    https://github.com/akinomyoga/ble.sh/issues/445#issuecomment-2131223529
    https://github.com/akinomyoga/ble.sh/issues/454
    Ref #D2210

    どういう時に ESC を Meta として解釈してどういう時に C-[ として扱い、どうい
    う時に ESC として扱えば良いのか分からなくなった。

    今までは C-[ か M- かの二種類の解釈しかなかった。ここで ESC になる事も許そ
    うと思うとどうしたら良いのか。ESC ESC が入ってきた時に M-ESC になる可能性も
    残しておく必要がある?

    現在の処理だと 27 が単発で来た時には C-[ に変換されてから unmodified-key に
    入ってくる? もし ble-bind -k で map されている場合には ESC の儘入ってくる?
    どちらの場合であっても正しく処理する為に key を見るのではなくて seq を見て
    ESC である可能性について調べている。

    或いは @ESC として受信した場合にはどうするのか。この場合には

    ? ble-bind -k ESC ESC とした場合に Meta として活性を @ESC と同程度までに落
      とす必要はあるだろうか。うーん。というか、そもそも ESC で受信した物は
      ble-bind -k ESC で翻訳できるのかという問題もある。ble-bind -k ESC ESC を
      実行してもこれに引っかかるのは、prefix として使用された ESC だけである。
      なので、ble-bind -k ESC ESC が修飾としての役割を抑制するのだとしたら、こ
      れを実行しても孤立 ESC に対して何も効果がないどころか、修飾 ESC も動かな
      くなってしまう。

      ble-bind -k ESC ESC を実行しても Meta としての役割は保持する様にするべき。

      そう思うとやはり meta の判定は元の seq に対して行うべきである。一方で、複
      数の文字から翻訳によって得られた ESC に関しては一括で IsolatedESC として
      取り扱うべきの気がする。

    ? 一方で、いざ通常キーとして処理する事になった時に C-[ を送出するべきか ESC
      を送出するべきか。今までは一括で C-[ を送っていたが、新しい実装では ESC
      を生成した場合には ESC を送るべきなのではないか。これはどの様にして判定す
      るべきか。

      修飾 ESC が来て通常通りに処理された時は key = C-[ になっている筈なのでそ
      れを使えば良い。ユーザーが ble-bind -k ESC ESC を設定している時には key =
      ESC のままになっている筈なのでこれもそのまま使えば良い。CSI seq によって
      ESC が指定で生成された時にはどうすれば良いか。これは ESC のままで良いので
      はないか。そしてこの場合も key は既に ESC になっているので敢えて修正しな
      くて良いのでは? と思ったが現在の実装だと @ESC になっている可能性があるの
      でそれを ESC か C-[ のどちらかに翻訳する必要がある。

      うーん。key = @ESC だった時に二つの可能性がある。CSI seq から ESC が生成
      された時にそれを @ESC に変換した物だとすれば、実際に送るべきは ESC の気が
      する。一方で、@ESC として初めから readline から受け取った場合には、受診時
      には単独の 27 だったという事を暗示しているので C-[ に変換したい。一方で、
      ユーザーが明示的に ble-bind -k ESC ESC としている場合にはそのまま C-[ に
      変換しても良いのだろうか? 或いは ble-bind -k @ESC ESC とすると、今度は修
      飾ESCとして扱われる様になってしまう。

    期待する動作について改めて整理する。

    通常の設定の場合には ESC が来たらそれは meta 修飾で解釈する。連続で来る等し
    て修飾ではなくキーとして解釈する場合には C-[ で解釈する。@ESC が来たらそれ
    は @ESC として解釈する。これもキーとして解釈する時には C-[ で解釈する。CSI
    u などにより ESC を受け取った時は修飾としては @ESC として取り扱い、キーとし
    て解釈する時は ESC として取り扱う。ble-bind -k ESC ESC 等によって変換されて
    いる時には meta 修飾で解釈し、キーとして解釈する場合には ESC で解釈する。

    ? ble-bind -k @ESC X 等と変換している時に、@ESC は Meta 修飾になる事を許す
      か? うーん。これは際どいが、@ESC を明示的に X に変換しているのだとしたら、
      単体 ESC の作用としての M- を削除していると考えられるので、charseq=(@ESC)
      は @ESC として扱わないのが自然の気がする。

    (charseq, key) の組を見ればこれらの振る舞いをちゃんと実装できるだろうか。例
    えば、

    * 前段階で char ESC は単体で key C-[ に変換する。もし ble-bind -k ESC ESC
      が設定されている時には key ESC になる。charseq=(27) になる筈なので、何れ
      の場合においても meta 修飾として働くかどうかは charseq=(27) である事を確
      認すれば良い。

      もし既に M- が設定されていて修飾として働かないという場合には、そのまま
      C-[ もしくは ESC の解釈に対して M- を設定して M-C-[ もしくは M-ESC とすれ
      ば良い。既に key には変換された値が入っているのでそのまま通常文字の如くに
      処理を進めれば良い。

      char @ESC が来た時にはそのまま key @ESC になっている筈。もしユーザーがe、
      ble-bind -k @ESC X で敢えて別のキーに変換している時には @ESC としての振る
      舞いは失効させるというので良い。なので、@ESC に関しては key だけ確認すれ
      ば良い。

      CSI u を通して受信した ESC の取り扱いはどうするか。現在は CSI 受診の側で
      強制的に @ESC に変換しているが、寧ろ ESC を処理する側で 2 文字以上のシー
      ケンスで ESC を生成した場合は常に @ESC として取り扱うという規則でも良いの
      ではないか。その方が例外的な処理が CSI decoder の側で減らせて都合が良い気
      がする。

    ? ユーザーが ble-bind -k ESC X 等として変換したい時に単体 ESC を変換できな
      いという文句が出た時にどうするか? そもそも -k は char に対する変換操作な
      ので、 CSI u で送られてきた ESC に対しては作用しないのは作用しない。一方
      で、ユーザーは ble-bind -k @ESC ... を実行する事はできる。

    * mc が vi mode indicator をプロンプトとして抽出してしまっている。ちゃんと
      mc である事は検出できていて、 _ble_edit_integration_mc_precmd_stop=1 も設
      定されている。然し、それでも表示されてしまう。調べてみると、
      _ble_edit_integration_mc_precmd_stop を参照して
      keymap:vi/update-mode-indicator が呼び出されて内容を更新するが、そもそも
      update-mode-indicator が呼び出されるのがコマンドを実行した後に
      leave-command-layout を実行して、更にその後で ble/application/render が走っ
      た後である。一方で、leave-command-layout を実行した時点で info の再表示が
      実行されるので、その瞬間に既に設定していた mode indicator が表示されてし
      まう。mc はそれを拾ってしまう。

    * ble/widget/display-shell-version で MC_SID もチェックする。

2024-05-24

  * syntax: LS_COLORS='ln=target' (requested by akhilkedia) [#D2213]
    https://github.com/akinomyoga/ble.sh/issues/449

    対策はする。一方でこれに対応するべきだろうか。

    * そもそもこの機能は何なのか。ちゃんと公式で定義された機能なのか。もし何処
      かの勝手なプロジェクトがランダムに実装した物だったら、ble.sh がこれに対応
      する事によってユーザーが LS_COLORS に ln=target を設定して余計に問題が増
      える可能性がある。

      検索すると色々なプロジェクトに対応していないという文句が立っている。どう
      もGNU ls の独自機能であって undocumented という事が exa の issue に書かれ
      ている。

      - 2023-07-29 eza 対応? https://github.com/eza-community/eza/pull/52
      - 2021-09-24 exa 未対応  https://github.com/ogham/exa/pull/960
      - 2021-07-05 tcsh-6.23.00 対応 https://bugs.astron.com/view.php?id=258 これは bash の対応を受けて
      - 2019-08-10 xonsh-0.9.10 対応 https://xon.sh/changelog.html#v0-9-10
      - 2015-03-21 bash 対応 https://lists.gnu.org/archive/html/bug-bash/2015-03/msg00122.html
      - < 2004-08 GNU coreutils ls?

        と思ったが検索すると GNU ls 自体も別に独自に実装した訳ではなくて誰かが
        要求したのを修正している?

        > * Noteworthy changes in release 8.14 (2011-10-12) [stable]
        > ** Bug fixes
        >   ls --dereference no longer outputs erroneous "argetm" strings for
        >   dangling symlinks when an 'ln=target' entry is in $LS_COLORS.
        >   [bug introduced in fileutils-4.0]

        と思ったがこれよりも前に dangling でない symlinks については動作してい
        たという事? もっと遡ると 6.9.90 に言及がある。6.0 で導入されたバグとい
        う事になっているので、6.0 よりも前に実は ln=target は存在したという事な
        のだろうか。或いは単にランダムな文字列は昔は無視していたというだけの可
        能性もあるが。

        > * Noteworthy changes in release 6.9.90 (2007-12-01) [beta]
        > ** Bug fixes
        >   ls --color, (with a custom LS_COLORS envvar value including the
        >   ln=target attribute) would mistakenly output the string "target"
        >   before the name of each symlink.  [introduced in coreutils-6.0]

        それより前にはメーリングリスト上での言及はない様である。と思ったが別のメー
        リングリスト上で登場している。

        https://lists.gnu.org/archive/html/bug-coreutils/2004-08/msg00024.html
        https://lists.gnu.org/archive/html/bug-coreutils/2007-04/msg00048.html
        https://lists.gnu.org/archive/html/bug-coreutils/2008-04/msg00122.html

        ソースコード上には既に 2004-08 の時点で存在していた。

      - https://superuser.com/questions/225799/ ここでは 2010 年の段階で既に
        ln=target を使っている人がいる。

      然し、そもそも LS_COLORS どdocumentation が何処にあるのかも謎である。man
      dir_colors に dircolors の設定ファイルの記述方法が書かれている。

      [まとめ] 何処が出どころかは分からないが、 GNU coreutils ls では大分昔から
      コードの中に存在していた様である。undocumented であるという話も見られたが、
      そもそも LS_COLORS 自体が文書化されていない気がする。

    * 他にも対応していないものはあるだろうか。

      man dir_colors に変換元のファイルの形式の説明が幾らかある。実際に適当な設
      定を書いてどのように翻訳されるかを見ることで、どういう機能があるかを確認
      する事ができる。

      * reject: SGR の制御シーケンスを他の物にする機能?

        lc=1
        rc=2
        ec=3

        これらはそもそもその他の色指定の方法の時にも適用するべきかどうか考える
        必要がある。ls_colors のレベルで対応しても仕方がないので気にしない事に
        する。

      * reject: ファイル名以外の色を指定する機能
        <del>デフォルトのファイルの色を指定する機能</del>

        no=109 NORM (NORMAL)

        % これは既にble.sh の中で別枠で指定する事になっている? と思ったがそうで
        % もない様だ。後で確認する。
        %
        % うーん。別で指定する様になっているとしても、他のファイルタイプと同様
        % に filename_ls_colors で上書きできる様になっていても良いのではないか。
        %
        % 確認すると filename_other という face が存在していて、これは
        % ATTR_FILE_FILE に紐づけられている。そして ATTR_FILE_FILE は
        % dir_colors の 'fi' に紐づけられている。では fi と no の違いは何だろう
        % か。
        %
        % man dir_colors を改めて確認すると FILE (fi) は通常のファイルに使われ
        % る色で、NORMAL (no) はそもそもファイル名ですらない部分の着色という事
        % の様である。これは実装しなくて良い気がする。
        %
        % ? no: というか、そもそもこれは sgr0 の別名という事なのでは? とも思っ
        %   たがそうでもない。ec が sgr0 に対応している筈である。

        これはファイル名ではない通常テキストを表示するものである。通常ファイル
        名に使う色ではない。考えない事にする。

      * 特殊なファイルの種類

        do=110 DOOR
        mi=111 MISSING
        tw=112 OWT (STICKY_OTHER_WRITABLE)
        ow=113 OWR (OTHER_WRITABLE)

        これらはそもそも現れないか、判定できないか、判定に時間がかかるので実装
        しない物。

      * うーん。どうも *~ なども指定できる様だ。以前に試した時には LS_COLORS は
        *~ を解釈しないと判断した筈だがそうでもない? 或いは実装によって対応して
        いなかったとしても ble.sh では対応する事にしても良いのではないか。

        問題はこれに対応するとすると最長一致を判定するのが面倒になるという事。
        殆どの接尾辞が . で始まると想定して処理を分けるというのが現実的の気がす
        る。拡張子 (. で始まる物) の最長を求め、また別にそれ以外の接尾辞の最長
        一致を求め、両方の最長で判定を行う。或いはそれ以外の接尾辞の長さについ
        ては

        一方で dir_colors で対応されていないのは任意の glob パターンの様である。

        実際に GNU ls で試してみた所 *~ 等もちゃんと suffix として動いている。

    * done: ln=target には対応した。

    * done: 任意の suffix については追加で実装する事にする。

      * done: _ble_syntax_highlight_lscolors_ext の key に . を含める様に修正す
        る。修正した。他に参照している箇所がない事も確認した。

      動作確認。

      x fixed: 全く着色されなくなっている。と思ったら .match-suffix が引数を受
        け取っていない。修正した。

      他は問題なく動いている様子である。

      ? *~ とファイルの属性のどちらが優先されるのだろうか。現在の ble.sh の実装
        だと例えばファイルが実行属性を持っているとするとその時点で実行ファイル
        の着色が適用される事になり、ファイル名パターンによる着色はされない。

        GNU ls の振る舞いも同様だったので現在の振る舞いで良い事にする。

2024-05-22

  * 2024-03-19 auto-complete 中の C-right は自分の操作体系と干渉する [#D2212]
    Refs: #D2127 (0c4b6772)
    https://github.com/akinomyoga/ble.sh/issues/397

    一番右にいる時にだけ有効にするべきの気がする。現在の振る舞いは [1] #D2127
    で導入した物である。

    [1] https://github.com/akinomyoga/ble.sh/issues/397

    そもそも C-e だとか C-f に関しても行末以外での振る舞いが非直感的である。うー
    ん。というか元の設計の方針を思い出すと、C-e 及び C-f などの移動コマンドは
    auto_complete が急に popup したとしても振る舞いを変更しないという事だった。
    現在もそうなっている。然し、今新しく C-right 等で単語挿入を行う様にした為、
    C-e 及び C-f でも auto_complete の挿入ができるような錯覚を受けて変な操作を
    して失敗している様な気がする。

    今改めて C-right などの移動コマンドで挿入をしない様に変更し、別の方法で単語
    挿入を行う仕組みにできないだろうか。或いは、行の途中にいる時は C-right 等は
    通常の動作をする様に変更する。うーん。これが自然の気がする。

  * decode(ble-bind): combined options 対応 [#D2211]

    #D2210 の対応中に気になったが #D2210 の中に含めるには大きいので分ける事にし
    た。実際 #D2210 の変更とは overlap が全くない。簡単にテストした。

  * decode (ble-bind): ble-bind -k TAB TAB で TAB をそのまま透過する様にできたら良い気がする (motivated by gvlassis) [#D2210]
    https://github.com/akinomyoga/ble.sh/issues/445

    現在の実装を確認すると ble-bind -k は _ble_decode_cmap_* のテーブルにキーを
    登録する様になっている。実際の decode の順序としては 1. (.getent) まず最初
    に単体キーを _ble_decode_cmap_ の中に見つけて、その後で
    2. (send-unmodified-key) 修飾などの処理を行う様になっている。TAB -> C-i の
    変換は二段目の修飾等の処理を行う時点で実行される事になっている。これが問題
    である。

    C0 の変換に関しては send-unmodified-key の呼び出し元で処理するべきなのでは
    ないか? send-unmodified-key の呼び出し元は3箇所ある。.getent で何も見つから
    なかった場合 (2箇所の send-unmodified-key の呼び出し) には現在の処理のまま
    で良い。一方で、.getent で \d+ で見つかった時の send-unmodified-key に関し
    ては変換を抑制する機能があっても良い。実装方法には複数の選択肢がある。

    a. send-unmodified-key の外側で変換を行う。

      この場合処理の順序が変わる事になるのでそれによって変な問題が起こらないか
      考える必要がある。改めて処理を確認してみると変換の前に処理しているのは単
      に CHARS (_ble_decode_key__chars を介して渡される) に格納する為の
      isolatedESC の翻訳の様なので問題はない。

      少し見て send-unmodified-key の呼び出し箇所に応じて変換を実行すれば良いと
      思ったが、reach で保存されているキーを取り出す時に .getent で見つかったキー
      なのか或いは fallback として名前の値が入っていたのかを区別する方法がない。
      状態が区別できる様にする必要がある。もしくは、reach に格納する前に変換を
      既に実行する様にするべきか。

    b. send-unmodified-key にオプションとして変換抑制を指示する物を追加する。

    ? ok: ble-bind -k を通して登録した C0 が変換されない様な設定で問題が起こる
      可能性は? もし本当に C-h 等に変換して欲しいのであれば、ble-bind -k seq BS
      等ではなく初めから ble-bind -k seq C-h と記述する筈だから問題ない気がする。

      では今まで M-TAB 等として受信した物は M-C-i 等に変換していなかったのか?
      → 確認してみた所変換していない。よく考えてみれば当然だ。例えば C-TAB 等
      として受信したのだとしたらそれは恐らく modifyOtherKeys 等を介して受信した
      物だろうから更に変換されてしまっては困る。それに C-TAB を変換すると C-C-i
      つまり C-i に等価になってしまって意味がない。

    手元の端末では正確にはチェックできないが ble-bind -k TAB TAB を実行した時に
    ちゃんと TAB のまま保持される事を確認した。

    x 動いていると思っていたら M-* 関連の keybinding が全て動かなくなっていた。
      確認してみると send-unmodified-key は ESC / IsolatedESC を見てそれを M-
      に変換しているのだった。なので send-unmodified-key に渡す前に C-[ に変換
      されていると処理できなくなってしまう。

      では C-[ に変換された物を M- にすれば良いのかというとそうでもない。そうす
      ると今度は本当に C-[ と入力した物まで M- に変換されてしまうから。

      仕方がないので meta を意味するかどうかの判定として seq として単体の文字を
      受け取った時にその文字を直接判定に使う事にした。

  * keymap/vi: vi での既定の C-w の振る舞いがおかしい [#D2208]

    うーん。色々衝撃な事が分かった。

    * Bash では set -o vi の時には C-w の結果は累積されない。

      これに関しては累積された方が便利の気がするので意図的に ble.sh では emacs
      と同様に累積する様にする事にする。

      と思ったが、vi_imap/kill-backward-word が xword の枠組みとは別に実装され
      ている以上は累積される様にするのも面倒だし、 Bash での実装が累積する様に
      なっていないのであれば、累積する様に実装するのも面倒なので、現在の様に
      vi_imap/kill-backward-wor で処理するという形で問題ない気がする。

    * ble.sh の既定では C-w はそもそも単語 "削除" になっているので、消した単語
      は C-y をしても貼り付ける事ができない。

      見ると元々は settings overwritten by bash というセクションにあって、後で
      C-w を上書きするという事になっていたみたいだ。

      更に遡ると 2c7aee5c6 (2017-10-31) #D0551 で単語の振る舞いを変更している。
      その時に単語の範囲の決定方法の違いに着目するばかりに kill と delete の振
      る舞いの変化に気付いていなかったという事の気がする。改めて delete ではな
      く kill に変更するべきの気がする。しかもこれは古い間違いなので、独立した
      commit にした方が良い気がする。

      先ず #0551 で実装された単語の振る舞いについて確認する。できれば現在の
      xword の枠組みに取り込んでしまいたい。と思って確認したが正規表現を使って
      いて、これは vword で用いている物である。そして vword に関連する操作は完
      全に独自に実装されている。何故なら繰り返しが起こった時の詳細な振る舞いな
      どを完全に再現しようとしているから。なので、既存の xword の枠組みに完全に
      載せるのはできない。そう思うと delete-backward-word を独自に実装したのは
      理解できる。

      ? 互換性を考えると vi_imap/delete-backward-word を今から削除するのは問題
        なのでは。残しておきたい。一方で、完全に実装を残すか、それとも kill と
        実装を共通化するか。うーん。copy 等の事も考えると実装を共通化するのが自
        然の気がする。

2024-05-20

  * accept-line: RET からコマンド実行までの時間 (motivated by pallaswept) [#D2207]
    https://github.com/akinomyoga/ble.sh/issues/447

    そこを短縮する事に何の意味があるのか分からない。

    調べてみると PS1 が再計算されている。何故? 調べてみると $_ble_prompt_hash
    == "$version" の計算で version に history count が含まれている。考えてみれ
    ば最近 ble/prompt/update と履歴登録の順序を交換した気がする。

    #D1925 (44d9e104) で変更されている。最近の様な気がしていたが 2023-01-31 で
    ある。順番を入れ替えても問題ない気がするといって入れ替えている。更に #D1938
    (00cae745) で gexec に対する register も順番を変更しているが、これも
    2023-02-03 で最近の話ではない。

    これだと必要もないのにほぼ毎回 PS1 を2回実行する事になっていて明らかに無駄
    である。順番をやはり元に戻したいが、そもそも順番を入れ替えたのには理由があっ
    た筈である。それを確認する必要がある。

    (背景) histdb は ADDHISTORY の中で文法情報を参照したい。newline ->
    histexpand -> ADDHISTORY -> ble/history/add だと ADDHISTORY の中で文法情報
    が参照できない。何故なら文法情報は既に newline によって消去されているから。
    従って、histexpand -> ADDHISTORY -> newline の順にしなければならない。一方
    で、ADDHISTORY は ble/history/add の中で呼び出されているので、これだと
    histoexpand -> ADDHISTORY -> newline の順序にする必要がある。

    a ADDHISTORY の中で文法情報を参照できるようにするのが問題? ADDHISTORY とは
      別の hook を用意して histdb はその中で文法情報を抽出する様にする?

    b ADDHISTORY は ble/history/add の外側で実行する?

      コマンド履歴に関係する ble/history/add が呼び出されているのは二箇所のみで
      ある。accept-line と edit-and-execute-command である。

      ? ble/history/add の中で複雑なフィルタリングをした上で ADDHISTORY を呼び
      出しているのだとすれば単純に分割はできないのではないか? と思って実装を確
      認してみたが別に複雑な事はしていなくて最初に ADDHISTORY を呼び出している
      のだった。但し、 _ble_history_prefix を参照している。つまり、コマンド履歴
      に追加するモードではない場合についても考慮に入れる必要がある。

      x また分割するにしてもインターフェイス的に不自然になる。一体どういう説明
      にするべきだろうか。

    c 或いは最終プロンプトの表示と新しい行に移行するステップを分割するべきなの
      ではないか? 順番的には (最終プロンプトの表示) → (履歴登録) → (次のコマ
      ンドラインに移行) の気がする。というかそもそも諸々の展開を実行するよりも
      前に最終プロンプトは表示するべきなのではないか?

    結局論理的に c が自然なので実装が多少複雑でも c の方針で行く事にした。書き
    換えも現実的な範囲で可能だと判断した。

    .newline は以下の場所で呼び出されている。

      ./src/edit.sh:7474:  _ble_edit_line_disabled=1 ble/widget/.newline keep-info
      ./src/edit.sh:7586:    ble/widget/.newline keep-info
      ./src/edit.sh:7676:  _ble_edit_CMD=$old_cmd ble/widget/.newline # #D1800 register
      ./src/edit.sh:7767:    _ble_edit_line_disabled=1 ble/widget/.newline # #D1800 (呼び出し元で exec/register)

    うーん。実際に処理をしているのは .insert-newline の様である。.insert-newline
    はより多くの箇所で呼び出されている。

      ./lib/test-keymap.vi.sh:678:    _ble_edit_line_disabled=1 ble/widget/.insert-newline # #D1800 pair=leave-command-layout
      ./src/edit.sh:7480:  _ble_complete_menu_active= _ble_edit_overwrite_mode= ble/widget/.insert-newline "$opts" # #D1800 checked=.newline
      ./src/edit.sh:7581:  _ble_edit_line_disabled=1 ble/widget/.insert-newline keep-info
      ./src/edit.sh:10284:      ble/widget/.insert-newline # #D1800 (既に外部状態なのでOK)
      ./src/edit.sh:10286:      _ble_edit_line_disabled=1 ble/widget/.insert-newline # #D1800 (既に外部状態なのでOK)
      ./src/edit.sh:11069:  _ble_edit_line_disabled=1 ble/widget/.insert-newline # #D1800 pair=leave-command-layout
      ./src/edit.sh:11118:    _ble_edit_line_disabled=1 ble/widget/.insert-newline keep-info
      ./src/edit.sh:11123:  _ble_edit_line_disabled=1 ble/widget/.insert-newline # #D1800 pair=exec/register

    .insert-newline の中で ble/textarea#render leave と trim-prompt を呼び出
    している。

    * done: うーん。trim-prompt は textarea#render の中に含めるのが自然である。
      →修正した。

    さて沢山ある呼び出し元の全てで ble/textarea#render leave を呼び出すのは非
    現実的な気がする。

    a 例えば追加のオプションを実装して ble/textarea#render leave を抑制する?

    b 或いは関数名を .insert-newline => .update-prompt-and-insert-newline 的
      にして、それぞれ分割して実行したい時には ble/textarea#render と
      .insert-newline をそれぞれ呼び出す?

    * done: 関数名の整理・変更

      そもそも何故 .newline と .insert-newline に分かれているのだったか。関数名
      的に違いが分からない。

      うーん。.insert-newline は現在の command line の内容を保持したまま次の行
      に行く機能で、例えば履歴展開を失敗した時などにユーザーに再入力を求める時
      にはこれだけを呼び出す。一方で .newline は本当に新しいコマンド行に移動す
      る機能である。LINENO が実際に増える。.insert-newline は寧ろ .new-prompt
      なのかもしれない。然し、実際には新しいプロンプトを表示するのではなくて単
      に端末的に次の行に移動するだけである。

      つまり .newline はコマンドラインの概念的な新しい行で、.insert-newline は
      表示上の行の話をしている。

      いつも分からなくなるので関数名を工夫した方が良い気がする。

      * .newline / .insert-newline
      * .new-command-line / .next-display-line

      * .newline / ble/textarea#newline
        別に textarea だけでなく全体のレイアウトも変更している。

      * .newline / new-display-line

      * .go-to-newline = 最終描画・新しい描画領域・初期化
        .newline = 新しい描画領域・初期化
        .new-rendering-area = 最終描画・新しい描画領域
        .shift-rendering-area = 新しい描画領域

        うーん。最終描画をするかどうかと、初期化をするかどうかの二つの軸がある。
        それぞれに勝手に名前をつけるのではなく、系統的な名前にしたい。

        例えば最終描画をするのは go-to/switch-to/move-to で単に新しい描画領域を
        用意するのは create/insert などにする。二つの単語に分かれているのは余り
        綺麗でない。synonym を調べると visit appear catch show haunt alternate
        shift transform substitute swap convert divert replace turn veer
        advance carry change blow cross drift flow migrate push proceed propel
        relocate remove run ship transfer transport travel walk withdraw。うー
        ん。余り良い物はやはりない。 relocate は rendering-area に対して使うと
        良い様な気がする (relocate-rendering-area / insert-rendering-area)。と
        思ったが前の prompt の更新も "rendering-area" の操作対象とするのはやは
        り変な気がする。"switch-panel-area" とかにする? 然しそうすると
        insert-panel-area も何だか変な気がする (textarea だけ更新してその他のパ
        ネルは前の物と共有しているので)。それならば寧ろ、switch-textarea /
        insert-textarea とかの方が良い? でも textarea を即座に render する訳で
        もないので switch-textarea はやはり変?

        newline
        relocate-textarea
        insert-textarea

        うーん。newline は textarea#render は実行しないという事にして実行する
        version も用意しない事にする。

      prefix についても ble/widget ではなくて別の名前を与えたい。ble/textarea
      は特定のパネルの話だし、かといって ble/canvas/panel にお邪魔するのも変な
      気がする。ble/application は一応 edit.sh の管轄だがより一般の枠組みを意図
      した物の様な気がする。ble/edit の以下に直接置いても良いのかもしれない。或
      いは ble/edit/panel もしくは ble/edit/rendering-area か。取り敢えず
      ble/edit 直下で考える。

    * done: .newline では _ble_complete_menu_active= _ble_edit_overwrite_mode=
      を指定して .insert-newline を呼び出していたが、他の場所では呼び出さないの
      だろうか。そもそも ble/textarea#render leave の中で一括で指定するべきなの
      ではないか。

      既にある .relocate-textarea (.insert-newline 改名後) も見たが何れも
      _ble_complete_menu_active= 及び _ble_edit_overwrite_mode= は指定するべき
      の気がする。何れにしても _ble_edit_line_disbaled=1 を指定していたので隠れ
      て見えなかったのかもしれないが。

    x fixed: ble/widget/edit-and-execute-command の実装を見ると accept-line の
      中と、様々なステップの実行の順序が変わってしまっている。これも
      accept-line に合わせる形で修正する必要がある。

      特にこの場合には (最終プロンプト表示) → (編集) → (展開) → (履歴登録)
      なので insert-line を先に実行する事は不可能である。一方で、この場合には
      histdb が文法情報は参照しないのは自然である。

    * done: ちゃんと無駄な PS1 の評価が消えているかを確認する → OK

2024-05-18

  * complete_menu_complete_opts で insert-selection を外した時のカーソル位置 (reported by gvlassis) [#D2206]
    https://github.com/akinomyoga/ble.sh/issues/445

    Ref #D1911 https://github.com/akinomyoga/ble.sh/discussions/252

    単語の最初に位置しているがこれで良いのか? 処理は
    ble/complete/menu-complete.class/onselect で明示的に行われている。一時挿入
    時のカーソルの位置指定に関しては一番はじめの実装からそうなっている。これは
    元々 GitHub#252 の要望で実装された物で、要望を出した人は it perfectly works
    と言っている。

    https://github.com/akinomyoga/ble.sh/discussions/252#discussioncomment-4347042

    或いはテストした時には空の単語でしか試していなくて OK と言っただけなのかも
    しれない。後で変な振る舞いに気づいたとしてももう ble.sh を使っていなかった
    か、或いは perfectly と言った手前追加で要望を出すのを諦めたのかもしれない。

    修正としては適切な位置にカーソルを設定するか、或いは全く位置を移動しないと
    いう事。そもそも一次挿入する時の挿入範囲を決定するのに _ble_edit_ind を参照
    しているので _ble_edit_ind は元より補完終了点を指している様に見える。むしろ
    補完開始時の補完終了点を参照すると、内容が既に変わっている時に変な事が起こ
    る可能性がある。と思うと、そのまま _ble_edit_ind を保持するのが良い気がする。
    単に _ble_edit_ind の更新をしないようにすれば良い。

  * C-w で切り取られた単語が累積されなくなっている (reported by 3ximus) [#D2205]
    https://github.com/akinomyoga/ble.sh/issues/446

    以前は動いていたが最近になって動かない事に気づいたそうだ。aa92b42 (#D2144)
    で発生する様になった。一見して関係しそうな変更はないように見える。但し、
    WIDGET の値を決定する方法が微妙に変わっている。例えば : などの特別の文字に
    対して quote がされるようになった? と思ったが現状の widget 名にはそのような
    特別な文字は含まれていないはずだし、もし以前と違った値になるようになったと
    しても LASTWIDGET には WIDGET から値をコピーするから問題ないのではないか。

    或いは、C-w の実装は kill-region-or で処理しているので widget の置換に失敗
    しているという事も可能性としてある。或いはそもそも C-w が余り考えずに実装し
    ていた為に微妙な違いで振る舞いが壊れてしまったという可能性? 何れにしても問
    題は再現しているので時間をかければ原因は分かる。

    うーん。quote-words は必要がある時にだけ quote する物かと思っていたがそうで
    はない様だ。常に '...' の形に quote する物だった。その為、ble/widget/kill-*
    は皆 'ble/widget/kill-*' になってしまい、それが LASTWIDGET に渡るので
    $LASTWIDGET == ble/widget/kill-* の様な判定が動かなくなっていたのだった。
    quote-command を使う様に戻す事にした (但し ble/widget/ が指定されていない時
    の対応については保持する)。

    x 気づいたのだが vi モードでは C-w で削った文字列の順序が反転している。
      emacs モードでは問題ない。これは何故だろうか。これも一緒に修正するべきの
      気がする。

      これは keymap.vi の既定の設定ではなくて自分が使っている設定の時の振る舞い
      と分かった。自分の設定では kill-region-or kill-uword を用いているが、切り
      取りを行う順序が反転しているという事。と思ったが、どうも kill-region-or
      kill-backward-uword だと動くが kill-region-or kill-uword だと反転するとい
      う事の様だ。

      kill-uword の時には大体は backward だが前に単語が見つからない場合には
      forward になる。なので、一律で prepend にする訳にも行かない。仕方がないの
      でやはり kill-uword については一律に append という事にしようかと思ったが、
      確認してみるとどうも位置 _ble_edit_ind を変える前に範囲を切り取る気がする
      ので、_ble_edit_ind と切り取り範囲の位置関係で判定できないだろうか。

      と思ったが切り取り範囲ではなくて文字列を指定しているので _ble_edit_ind と
      の関係は特定できない。取り敢えずオプションで範囲も第三引数として受け取れ
      る様にした。或いは、呼び出し元で切り取りの方向性 (forward, backward) が分
      かっている場合にはそれを指定する。keymap.vi.sh からの呼び出しは
      operator:y による呼び出しなので基本的には方向性を決定するのは難しい。これ
      まで通り WIDGET からの推測で良い事にした。

      →動作確認した。コマンドの途中から始めた場合でもちゃんと元の単語の順序を
      完全に保持できている事を確認した。OK

    うーん。vi での ble.sh の既定の振る舞いがおかしいという事が分かった。これは
    #D2205 で別に処理する事にする。

2024-05-15

  * airline: 複数の theme で初期化時に存在しない face を設定しようとしてエラーが出る (reported by alexalekseyenko) [#D2204]
    https://github.com/akinomyoga/blesh-contrib/issues/19

    ref #D1589

    今まで気づいていなかったのが不思議だ。持っている複数の theme で試したけれど
    も、全部は試していなかったという事。

    * _default という face を参照している様だが、これは vim-airline.sh では定義
      されていない。contrib/theme/*.bash の生成スクリプトを見ると *_default と
      いう face を辞書に入れている様だが、どうもこれは _default のついていない
      名前の face の既定値を入れているだけの様だ。これを face を比較する為に同
      じ辞書に入れているだけだった。

      この比較用のダミーの face は除外するべき。本来は (*) continue ;; で除外す
      るつもりだったのかもしれないが、その前の (*_*) に結局引っかかるので意味が
      ないという事だろう。

    * 改めて走らせようと思ったらエラーが出る。rgb.txt が存在しない。これは色名
      を #rrggbb 値に変換する為のテーブルとして使っている様だ。:help rgb.txt を
      見ると、色名は $VIMRUNTIME/colors/lists/default.vim に移行した様だ。その
      ファイルを読み取る様に変更することにした。

      色の詳細な値がまた変わったようだ。16 が 235 などになっている。然し、16 も
      結局 6x6x6 cube の色であって、terminal 16 colors の一部ではないのでこの変
      化は問題にはならないだろう。

    * 他に色々ハードコードされていたパスや年などについて、ファイルの先頭で定義
      できる様にした。

    * done: 生成用スクリプトは移動するべき。使い方も記述する。

      というか使い方について確認する必要がある。特に .vim の法の使い方が分から
      ない。

      改めてデータを生成した所、biogoo theme で色が特定できなくなっている。vim
      のバージョンの相性もあるかもしれないので、昔に生成した dump データをやは
      り使う事にした。

    * done: 最新版に更新する。前後の commit を記録する。

      * vim-airline-themes 97cf3e6 -> a9aa25c
        以下の themes が更新されている: base16 blood_red (new) cyberpunk (new)
        jellybeans light onedark selenized supernova

      * vim-airline be5bda1 -> ff0f9a4
        唯一の theme "dark" も更新されている。

      * landscape dcdd360 変更なし

      ライセンスも更新する。と思ったがライセンスファイルは全く更新されていない
      様だ。なので更新しない事にする。

      再生成してみたがやはり biogoo は色々と設定が消滅している様だ。新しく追加
      された項目はそのままにして、既存の項目はそのままにする事にした。

2024-04-28

  * keymap/vi (relative-line.impl): fix uninitialized nmove [#D2203]

    これも spell check の時に見つけた物。これは大分前からあるバグである
    (a9a1638a)。元々存在していた変数 nmove を削除していた。これは大分遡る。

  * util.hook: run user DEBUG trap at the top-level context [#D2202]

    spell check の間に見つけた物。存在しない変数を参照していた。 a22c25b54 で
    user-trap-in-postproc が追加された時から誤っている。書き換えの途中でそのま
    まになっていた物の様に思われる。これは遡って適用する。しかも a5b10e8b1 で修
    正しようとした形跡があるがその修正が完全でなかった (install_opts という変数
    が新しく導入されているが何処からも参照されていない気がする)。

    影響としては user DEBUG trap が一番外側で評価される事になっていたのが動いて
    いなかった。trap handler の内部で実行されていた。

  * global: spelling mistakes [#D2201]
    typo がある。修正する。似たような物がないか確認して一括で修正する事にする。
    ソースコード中の特にコメントやメッセージなどに typo が多い。

  * prompt: clear list for the cylic dependency detection (reported by micimize, neilbags) [#D2200]
    https://github.com/akinomyoga/ble.sh/issues/359
    https://github.com/akinomyoga/ble.sh/issues/442

    どちらも初期化時に発生する。前者は starship と一緒に使っている時のエラーだっ
    たが、後者は starship は使っていない。代わりに atuin を使っている。

    PS1 の中で循環参照が起こっているのではないかと思ったが、通常の設定である限
    りは unit#update が PS1 によって (間接的であるにしても) 呼び出されるのは変
    である。或いは winch を介してプロンプトの初期化をしている間に、また
    ble/prompt/update が入れ子で呼び出されているのかもしれない。その場合に何が
    起こるか確認する。循環参照の検出には ble_prompt_unit_mark というローカル変
    数を使っている。これは存在していなければその場で作るという形になっている。
    つまり、一番外側の unit#update で空の物を用意するという訳ではない様だ。

    ble/prompt/update で明示的に空に初期化する事にする。これで PS1 を処理してい
    る間に ble/prompt/update が入れ子で呼び出されたとしても問題ない筈。

    2024-05-15 pending の修正を追加する。

2024-04-24

  * menu-complete: support hiding menu (requested by CamRatliff) [#D2199]
    https://github.com/akinomyoga/ble.sh/discussions/439

    * done: menu-style を toggle/rotate する機能。

      途中で切り替えた時にページを再構築する機能が必要。

      ページの再表示は ble/complete/menu/show に filter 及び menu-source を指定し
      て実行されている様に見える。然し、何故 filter と menu-source の二種類がある
      のだろうか。両者の動作の違いは何なのか。load-filtered-data とは何か。

    * done: refactor ble/complete/menu/show

      ble/complete/menu/show の内部の opts を元にしている条件分岐が意味不明であ
      る。opts の名前に沿っている様にも思えないし、皆類似していて何がどう異なる
      のかもよく分からない。load-filtered-data と filter は常に一緒に使われるの
      か。それとも filter だけ使われる事もあるのだろうか。どの様に使われている
      かを調べて改めて適切な振る舞いについて考える事にする。

      filter

        ble/complete/menu/show filter で load-filtered-data なしで呼び出してい
        る箇所がある。うーん。filter で load-filtered-data なしなのは
        menu-filter の初回の呼び出しの時だけ? と思ったがそうでもない。
        menu-filter が実行される度にこれで既存の結果を置き換えている。これは実
        際に menu-filter でフィルタリングをして cand_pack を準備した直後に呼び
        出されている。フィルタリングを計算する度に項目の更新が必要になるのでこ
        れは妥当である。

        filter を指定した時の振る舞いの効能としては前回の menu-style を継承する
        という事。それから _ble_complete_menu_* に対する諸々のデータの格納をス
        キップするという事。

      filter:load-filtered-data

        load-filtered-data は menu#select から呼び出されていて、一緒に filter
        が指定されている。然し、何がどう filter なのかはよく分からない。呼び出
        し元の文脈的に filter は関係ないのではないかという気がする。だとすると
        と、元々 filter が指定された時の特別な振る舞いを想定して流用したという
        事だろうか?

        この場合は filter を指定した時に加えて COMP? や comp_* comps_*
        cand_pack 等の変数を前の menu/show の呼び出しの時に使った物を元にして初
        期化する。逆に言えば、これを指定していない時には、これらの変数を呼び出
        し元が適切に準備する必要がある。

      menu-source

        その他の ble/complete/menu/show の呼び出しとして "$menu_show_opts" を渡
        している箇所が複数あるが、これらは menu-source を含む可能性があるという
        だけである。

        この場合は既に存在している _ble_complete_menu{,0}_* を更新しない? でも
        呼び出し元の変数を参照する。何の為の物かよく分からない。

        既に menu が表示されている状態で ble/widget/complete が呼び出されると
        (background の menu filter が有効でなければ) menu-filter を実施してから
        候補生成を行う (実はこの時点で menu が既に表示されている筈)。その上で
        更に enter_menu や show_menu 等で menu を表示するという処理の時に、処理
        をスキップするのに使っている。特に filter 前の候補の情報を削除しない為
        に? 然し全く何もしないかというとそうではなくて、現在の編集状況に応じて
        "補完開始前の状態" に対応する情報を更新している。

      処理の流れについて整理する。呼び出し方が四種類ある。

      - 通常。

        1. widget/complete で候補を生成しメニュー項目の情報を変数に入れる
        2. menu_style は bleopt から拾う。
        3. menu を表示する。
        4. 補完開始の文脈を記録する

        変更: これは opts=init という事にする。

      - update [menu-source (menu が表示されている状態での更なる補完?)]

        1. 既存の menu から補完候補の情報を復元する。
        2. menu_style は bleopt から拾う。
        3. menu を表示する。
        4. 補完開始時の文脈 (コマンドラインの補完対象以外の部分) を更新する。

        変更: これは opts=update-context:update-items:update-style で処理する。

      - filter

        1. 既存のメニュー項目を元に filter した cand_pack を生成する。
        2. menu_style は既存の物を使う。
        3. menu を表示する。この時 _ble_complete_menu_items は更新される。
        4. 何も新しく記録しない。

        変更: これは opts=update-items という事にする。

      - filter:load-filtered-data

        1. 呼び出し元では何も生成しない。
        2. 既存のフィルター済みのデータを元にして menu を表示する。
        3. 何も記録しない。

        変更: これは opts= という事にする。

      作り直した。何かミスをしていないかは気になる。

    * done: 現在は menu-style:hidden として実装しているが style と visibility
      に分けて実装するべきではないか? 例えば、source:option で desc が要求され
      て complete_menu_style が設定された時にそれは hidden を上書きするべきなの
      か?  上書きするのは変である。しかし、かといって hidden の時に何もしないと
      いう事にすると、いざ menu-style を switch して表示した時に menu-style が
      source:option が意図した物と異なるという事態になってしまう。

      しかしそうすると表示していない時でも裏で layout 計算を実行するという事に
      なるのだろうか? 或いは表示・非表示を切り替える度に layout 計算を実行する
      のか? 或いは必要になった時に初めて layout 計算をする事にして、現在 page
      layout が計算されているかそうでないかをまた別の変数で管理する様にする?

      →取り敢えず実装した。

    * done: switch-style で bleopt complete_menu_style も変更するべきの気がする。

    * done: bleopt complete_menu_opts を追加したがよく見たら既に
      complete_menu_complete_opts というオプションが存在している。統合する。

    x fixed: 隠した状態で初めて menu-style を変更してから表示しても menu-style
      が反映されない。_ble_complete_menu_version を使ってキャッシュの style を
      一致させようとしていたが、_ble_complete_menu_version は hidden であっても
      更新される。なので、キャッシュを保持していると記録されている物とのずれが
      生じる。

    x fixed: 隠した状態で巡回しようとしても項目が挿入されない → これは hidden
      の場合に menu_class が設定されないまま menu#construct が終了していたのが
      原因。ちゃんと全ての変数を設定する必要がある。

    * done: bleopt complete_menu_complete_opts=hidden とすると、何も表示されな
      くなって変な事になるので、hidden を指定している時は insert-selection を自
      動的に有効にする様にする。

    * done: "complete show_menu" としても何も表示されない。show_menu が指定され
      た時は強制的に表示するべきでは。

    * done: "toggle_menu" も追加するべきの気がする。

2024-04-20

  * BUG complete: sabbrev が動かなくなっている (reported by dgudim) [#D2198]
    https://github.com/akinomyoga/ble.sh/issues/437

    明らかに #D2191 で導入した suffix sabbrev の影響である。refactoring の際に
    色々変わって動かなくなっていたのだった。特に、sabbrev#get 内のミスで全く動
    かなくなっていた。

2024-04-17

  * term: linux console で cursor が表示されなくなっている [#D2197]

    これは civis に \e[?1c という物が含まれていてこれを戻す為には \e[?0c を指定
    する必要がある為。これはカーソルのスタイルを変更するシーケンスの気がするの
    で \e[?<Pn>c は使わない様にする。

    実際の linux で動作確認した。これで良い事にする。

  * README: bleopt prompt_command_changes_layout=1 について記述する [#D2196]
    記述した。

  * main: WSL で /run/user/* を使っていると突然 permission がなくなったりする (reported by antonioetv and geoffreyvanwyk) [#D2195]
    https://github.com/akinomyoga/ble.sh/issues/426

    複数の report が出ているのでこれは明らかに WSL の問題である。報告されている
    期間が 2023-09 周辺に集中しているのでもしかすると修正済みかもしれない。一方
    で、同様の問題はより昔からちらほらと報告はされていたみたいなので、類似の異
    なる問題が複数あるのかもしれない。その場合に全てが修正されたのかは分からな
    い。

    面倒なので何れにしても WSL では /run/user は使わない様にする。

  * global: 組み込みコマンドで -- を指定するべきところでちゃんと指定する [#D2194]

    * util(is-function): use "declare -F --" to check function names

    これは物凄く些細な変更の気がするが backport した方が良い気がするので独立し
    た commit にする。

    他に類似の物がないか調べるのも面倒なので declare 単体の修正で良いのでは。或
    いは少なくとも make_command.sh でチェックしている builtin に関しては -- を
    指定する必要があるかどうか確認する。eval については既に対策しているので問題
    ない。他の builtin についてはそもそも正しい使い方をしている限りはオプション
    と紛らわしい引数は現れない気がするので気にしない事にする。

    * main(ble/bin#has): use "builtin type -t -- ..."
    * main(ble/bin#get-path): use "builtin type -P -- ..."

    と思ったら type は builtin を通して呼び出す物の内に入っていなかった。以前
    omb において (Windows の type を似せる為に) alias type=cat として問題を起こ
    した人がいたので、type も builtin をつけて呼び出すべきの気がする。

    うーん。type は様々な箇所でまちまちのやり方で使われている。既に ble/bin#has
    は関数の判定にも使われている。なので、一般のコマンド存在判定として使って良
    い。存在判定には一律で ble/bin#has を使う事にする。また、ファイルコマンドの
    パスの取得については一律で builtin type -P -- を使うこととして、これも
    ble/bin#get-path という新しい関数を通して呼び出すことにした。

    最終的に結構大きな commit になってしまった。

  * complete: support ble-face menu_desc_* (requested by romaia) [#D2193]
    https://github.com/akinomyoga/ble.sh/discussions/433

    これは実装してみたらとても簡単だった。

  * global: avoid using the builtin ":" [#D2192]

    "function fun { :; }" は "function fun { return 0; }" で良いし、": >|
    filename" は単に ">| filename" で良いのではないか。

    * 一方でその他の場所で使っている ble/util/setexit 0 的な役割の ((1)) につい
      ては簡単に置き換えて良いかは微妙。ble/ で始まる関数が他で定義されたコマン
      ド名と被って問題になる事はないと思われるが、関数呼び出しが増えるし、特に
      初期化の部分で使っている物に関しては return よりも ((..)) の方が安全であ
      る。

    * 初期化の時の ((1)) >/dev/tty は単に >/dev/tty にしても動くのではないかと
      いう気がする。これは実験して試してみる事にする。うーん。単に >/dev/tty で
      もちゃんとテストできる様だ。直前のコマンドの終了ステータスが 1 だったとし
      ても、それがそのまま残るという事も起こらない。リダイレクトが成功すれば $?
      は 0 になる。

2024-03-24

  * 2023-03-09 sabbrev: suffix alias in Zsh (拡張子で実行形式を選択) [#D2191]
    https://github.com/akinomyoga/ble.sh/discussions/421#discussioncomment-8715045

    コマンド名補間も一緒に対応する必要がある。
    つまり suffix alias がある時には対応する拡張子を持つファイルも候補に表示する。

    * done: 補完候補生成。コマンド名補完の時に現在のファイル名から suffix 候補
      も生成する。

      * source:file を拡張すれば良い気がする。と思ったが、source:file は現在入
        力済みの単語を元に既にパス名展開を行っているので、単に suffix sabbrev
        から生成させたパターンに一致させれば良いという訳ではない。同時に複数の
        グロブパターンに一致させることはできない。!(!(xxx)|!(yyy)) を使えば原理
        的にできるかもしれないが Bash の実装的にとても重い。

      或いは source:file で一旦生成してからフィルターするというのも手かもしれな
      い → source:file にフィルターを渡して処理させることにした。取り敢えず候
      補生成は動いている。

    * fixed: quote されている単語もちゃんと補完されなければ困る → と思ったら単
      にバグだった。初めからその様に意図した実装になっていたが safe-eval に引数
      を渡すのを忘れていた。

    * done: suffix alias に一致している時に着色する必要があるのではないか? と思っ
      たが現状ではそもそも通常の sabbrev に一致している時の着色もない。なので余
      り気にしなくても良い様な気もする。

      と思ったが実際に使ってみるとかなり気になる。というかこれはコマンド着色の
      レベルで処理するべきの気がする。また新しい face を追加する必要がある気が
      する。

      取り敢えず動いている。一般の単語の sabbrev 着色については独立項目で考える
      事にする。

      * done: docs: face:command_suffix を追加する。command_directory 辺りを検
        索して同様の記述を追加する。

    * done: 存在するコマンド名に一致する場合は展開するべきではないのでは?

    * done: 存在するコマンド名に一致する場合は展開されないので補完候補から除外
      するべきではないのか?

    * ok: magic-accept の時の振る舞いも確認する。着色は sabbrev expansion が有
      効の時だけ? と思ったが何れにしても magic space では有効なので着色はいつも
      する。

    * ok: コマンド名に一致する時に展開されないという事をチェックする。

    * reject: 厳密一致の場合の展開もあって良いのでは? 例えば Makefile だとか
      bashrc だとか。と思ったがこれらはよく考えれば alias である。なので必要な
      い (厳密には sabbrev と alias では展開のタイミングが違うなど違いがあるが、
      機能的には alias を使った方が上である)。

    * done: wiki: ble-sabbrev の項目に追記する。

    * ok: .tar.xz などの二重拡張子で最長一致するか? これはちゃんとその様に実装
      している。ちゃんと動いている。OK

  * 2024-03-10 complete: cd の補完について cdable_vars に対応するべきではないか? [#D2190]

    現在の所は cdable_vars は参照していない。complete:cd/.impl で実装している。
    pushd や他のコマンドも同様に cdable_vars が使えるのかどうかは振る舞いを確認
    する。cdable_vars に対応している bash version は幾つか?

    ? yes: 変数名が quote されていても効くのか? →効く。変数展開などの結果とし
      て変数名が生成された場合でも効く。

    ? yes: pushd でも効くのか? → pushd でも効くようだ。

    取り敢えず実装した。

    x fixed: 改めて見てみると shopt -s cdable_vars が有効かどうかに関係なく補完
      している。cdable_vars が有効でない時は変数名が補完しない。

  * util: initialize ble/util/idle.clock (reported by Anyborr) [#D2189]
    https://github.com/akinomyoga/ble.sh/issues/424#issuecomment-2016531757

    ble/util/idle.clock が見付からないというエラーが生じている様だ。
    ble/util/idle.clock は idle.do の中で遅延初期化されている。それにも関わらず
    idle.push やその他の関数から呼び出されている。

    最近 idle.push などの中で ble/util/idle.clock を呼び出す様にしたのが原因だ
    ろうと思って確認してみたが、新しく ble/util/idle.clock を呼び出す様になった
    のは idle.push --sleep の中だけである。そして idle.push --sleep 自体は
    e0566bdc によって新しく追加された機能であり呼び出し元は ble/util/bgproc の
    みである。そして bgproc は histdb と config/github302-perlre-server でしか
    使われていない。

    その他の idle.push の呼び出し元は全て idle.do の中で使われる関数のみである。

    * idle.push 以外は idle.do の中から呼び出される事が前提の関数なので気にしな
      くて良い。idle.push の中で ble/util/idle.clock を呼び出す前に
      ble/util/idle.clock/.initialize を呼び出す事にした。

    * 報告者の環境で何故エラーが発生しているのか謎である

      報告者は histdb を呼び出しているという事なのだろうか? だとすると何故自分
      の histdb では問題が起こっていない? → と思ったが自分は ble-import -d
      histdb で遅延しているから問題が起こっていないのだろう。と思って
      ble-import histdb で即時読み込む様にしてみたがそれでも問題は発生しない。
      不思議だ。そもそも histdb ではその場では何も sqlite 関連の処理は行わない。
      sqlite3.open を idle.push するか、或いは blehook exec_register に登録する
      だけである。idle.push 経由の場合にはそもそもそれが発火する時点で
      idle.clock が初期化されるので問題は起こらない。一方で blehook
      exec_register の場合には即時コマンドを実行する様になっていないと問題は発
      生しない筈。

      或いは config/github302-perlre-server だろうか? と思ったが、こちらはこち
      らで初期化した時にメッセージを表示する様になっているみたいなので
      ble/util/idle.clock が見付からないというエラーメッセージだけ発生するのは
      変である。

    これも正直に謎に包まれているというか完全に解決したとは言い難い。然しながら、
    これに関しては少なくとも意味のある修正が含まれているので現時点で push して
    しまう事にする。と思ったがやはりこの修正は物凄く小さな修正だし、そもそもこ
    れで報告者の所で発生していたエラーメッセージが解決するのかも分からない。微
    妙だが取り敢えずは push する事にする。

2024-03-22

  * main: BLE_SESSION_ID を export する [#D2188]
    Ref https://github.com/atuinsh/atuin/pull/1856

    他の framework が現在の ble.sh session が有効になっているかどうか検出できる
    様にする為。やはり正直何故これが必要になるのか分からない気がするが、atuin
    doctor で検出する為に必要という主張である。他のツールも検出したい可能性があ
    るとか何とか言っているが ble.sh session の内部で実行する必要があるのかかな
    り怪しい。

    ? というか shell integration のレベルでシェル関数を定義した方が早いし確実な
      のではないか? 現在のshell の状態を正しく確実に調べるのにはそうするしかな
      い。

      x 然し、この方法の問題点は Atuin shell integration がそもそもちゃんと設定
        されていない時に動かないという事 (でもこれは先ずユーザーにちゃんと
        shell integration をインストールする様にお願いすれば良いだけの気もする)。

      x また、これだと各シェル毎に一々実装する必要があってメンテナンス性が悪い。
        でも第一の目的が Bash の状態を検出する事だというのであれば、仕方がない。

    ? reject: 現在の BLE_SESSION_ID に加えて SHLVL も追加するべき? そうしないと
      環境変数を見たツールが現在のシェルなのかどうなのか判定する事ができない。
      一方で、元々 BLE_SESSION_ID は history などでセッション固有の ID を割り当
      てる事が目的であったのであって、現在の情報で一意になっていると期待できる
      筈である。其処に余分な情報として SHLVL を追加する必要があるのか? 特に親シェ
      ルが死んでいるのに子シェルが存在するという事は考えにくいので、同じ PID に
      なるとは考えにくく PID の他に SHLVL を含める理由がない。

      単に中で動いているツールが確認できる為だけに SHLVL を BLE_SESSION_ID に含
      める必要性があるのだろうか? atuin の用法を考えなければその様な必要性は全
      くない様に思われる。

      一方で、もし仮に含めるとした場合の影響範囲についても確認しておく。特に
      BLE_SESSION_ID の内部構造を仮定したコードはあるだろうか? そもそも
      BLE_SESSION_ID は export されているだけで基本的に使われていない。使われて
      いるのは _ble_base_session である。BLE_SESSION_ID の方は history.sh の
      bgproc で起動されるコマンド引数に含めるために使われているだけである。これ
      は _ble_base_session に置き換えて良い気がする。

      * 一方で _ble_base_session は history.sh で使われていて、最初のフィールド
        が start_time である事が想定されている様に見える。それ以降がどうなって
        いるかについては何も使っていない。また、ble.sh 自身の中でそれが /$$ で
        終わっているかどうかの判定を行っている。そう思うと compatible な拡張と
        言えば start_time/.../PID となるが、これは拡張性を考えると不自然な気が
        する。末尾にどんどん追加していく形が望ましい。

      * BLE_SESSION_ID と _ble_base_session の内容は必ずしも同じでなくて良いの
        ではないか、と思ったがそれはそれで複数種類の session id が存在する事に
        なってしまい話がややこしくなるので避けたい。

      今後現在の ble.sh セッションを厳密に決定する必要が生じるとも思えないので、
      わざわざ現時点で BLE_SESSION_ID 乃至は _ble_base_session を変更する必要は
      ない気がする。

    * done: 将来の拡張性を考えると atuin の側で BLE_SESSION_ID の二番目の要素を
      抜き出す様に修正するべきの気がする。然し、上記で議論した様に後方互換性を
      考えると現在の実装の様に一番最後のフィールドを使うという実装のままの方が
      良いだろうか。

      % そもそも将来的に拡張を行うかどうか分からない。現時点で考える事ではない
      % 気がする。今の内に考えておけば後の migration で面倒な事を考えなくて済む
      % かもしれないが、拡張を start_time/pid/xxxx とするか start_time/xxxx/pid
      % とするかは今の所よく分からない。

      と思ったがやはり start_time/pid/.... と拡張する方向で修正する事にした。現
      状では内部構造を参照しているのは一箇所しかないので、今の内にここを修正し
      ておけば将来的に拡張したくなった時に、前方互換性のあるバージョンに全て置
      き換わるまで待たなくて良くなる。

2024-03-10

  * complete: autocd を magic expansion の一部に組み込む (motivated by Jai-JAP) [#D2187]
    https://github.com/akinomyoga/ble.sh/discussions/421

    ? cdable_vars を設定している時、ディレクトリ名を含んでいる変数名だけでも移
      動できたりするか? → 移動できない。なので cdable_vars に関しては気にしな
      くて良い。

  * 2024-02-13 github: Node.js 20 に伴う action 更新 [#D2186]
    https://github.com/akinomyoga/ble.sh/actions/runs/7883231577

    テストを覗いたら警告が出ている。checkout@v3 については checkout@v4 にすれば
    良いらしい。softprops/action-gh-release@v1 に関しては repository に見に行っ
    たら丁度先週 node20 に切り替えた所らしく、しかし v1 は v1 のままである。

    https://github.com/softprops/action-gh-release

    Issue を見てみたら報告が3日前にある。

    https://github.com/softprops/action-gh-release/issues/410

    一方で merge された側では @v2 にしたらいいとか何とか maintainer が言ってい
    て、然しそう言いながら何もしていない。それより寧ろ commit id を使う事を提案
    している。謎だ。

    https://github.com/softprops/action-gh-release/pull/406

    と思ってまた読んだら、maintainer は softprops で、言っている人は自身が
    action owner と言っている。何れにしてもよく分からないが、softprops が何かを
    しなければならない。別に softprops は inactive という訳ではない。上記 #406
    を merge したのは他ならぬ softprops である。

    うーん。これは動きがあるまで暫くは凍結の気がする。返信があった。解雇されて
    色々と大変だそうだ。これは待つことにする。

    どうやらタグがついた様なので GitHub Action を更新する事にする。

    2024-03-11 未だエラーが発生する。未だ @v3 を参照している箇所がある。全部で3
    箇所で参照していたのだった。一つのファイルに高々一個だと思って油断していた。

2024-03-04

  * edit: C-l 及び clear が効かなくなる (reported by cmndrsp0ck) [#D2185]
    https://github.com/akinomyoga/ble.sh/issues/417

    そもそも clear も効かなくなるというのがどういう状況なのか分からない。
    standard streams が ble-detach / ble-attach が壊れるのが原因かと思ったが、
    自分の手元では再現しない。そもそも報告だと ble-detach する前から問題があっ
    た様な書き方になっている。

    これは一体どういう事だろうか。

    と思って次の返答を見たら、どうも scrollback buffer の話をしているらしい。然
    し、clear を detached state で実行した時には scrollback buffer までは削除さ
    れないという。不思議だ。

2024-02-29

  * util: term_stty_restore が動かない (reported by TheFantasticWarrior) [#D2184]
    https://github.com/akinomyoga/ble.sh/issues/412#issuecomment-1968941175

    #D2170

    Bash 5.2 で試したら確かに自分で設定した stty が反映されない。
    ble/term/stty/enter を確認したら全く別の実装になっている。検索してみたら、
    そう言えば Bash 5.2 で checkwinsize が動かない問題の解決の為に
    ble/term/stty/enter を上書きしていたのだった。この上書きするコードも同時に
    更新する必要があった。

    自分で試してみたが未だ問題がある。最初の initialize の呼び出しの時点で stty
    -a の内容が undef になっている。別に internal state で initialize が呼び出
    されている訳でもない。と思ったが PROMPT_COMMAND で attach している時には
    readline が用意した internal state で実行されるので stty -a の内容が undef
    になっているのである。また bashrc で stty -a をした限りだと、 bashrc を実行
    している段階では stty -a の内容は external になっている。
    term_stty_restore=1 の時には bashrc の中で external state を保存しておく必
    要がある気がする。

    x うーん。でも term_stty_restore=1 は blerc で設定されると思うと util.sh の
      読み込みの時点では term_stty_restore=1 になるか分からないのでその場で読み
      取る訳には行かない。blerc を実行した後にまたチェックするのもコードが分散
      して嫌だし、ユーザーが .bashrc で設定を書いた場合に対応できない。

    term_stty_restore=1 の setter に hook すればこれらの問題は解決するが、

    x PROMPT_COMMAND の中で term_stty_restore=1 を実行された場合にはやはり問題
      が生じる。取り敢えず、PROMPT_COMMAND の中で最初の term_setty_restore=1 を
      実行する場合は考えない事にする。

    * 最初から term_stty_restore が設定されている場合については bleopt -I を実
      行した時点で処理される筈。"bleopt -I" は util.sh の読み込みよりも後にある
      のでOK。

    ble-detach してから stty を変更して再び ble-attach する場合にはまた問題が生
    じる様な気がするが余り気にしない? 或いは問題は簡単に回避できるだろうか?
    finalize で clear しておけば問題は生じない。次の initialize の時に設定を読
    み取るから。しかし、その様にすると source ~/.bashrc して新しい ble.sh
    session が始まった時にどうなるか不明。うーん。source ~/.bashrc を
    PROMPT_COMMAND の中で実行されると困るが (そして実際にその様な事をする人が過
    去にあった)、そうでなければ問題は起きない気がする。

    うーん。一応注意書きは何処かに書いておく事にする。

2024-02-25

  * 2024-02-19 _ble_util_fd_cmd_std* は ble-attach の時の物を覚えるべき [#D2183]

    prompt attach ではそちらの方が安全。警告メッセージが嫌で source ble.sh
    2>/dev/null とする人がいるので。というか ble-attach の時に改めて tui から
    fd を dup するべき。

  * 2024-02-08 bleopt: wildcard @ は 0文字以上に一致するべきでは [#D2182]
    Ref #D1568 #D1861

    現在一文字以上に一致しているが ${!prefix_@} の類推だと0文字以上に一致に変更
    するべきではないか? 他にも % で一文字に一致するべきではないかだとか色々の考
    察があった様な気がするが、その議論は何処かに行ってしまった。
    bleopt/expand-variable-pattern を導入したのは #D1568 だが其処には何も記録さ
    れていない。blehook でも使える様に対応したのが #D1861 だが其処にも記録はさ
    れていない。思っていただけで書いていないという事か?

    元々 @ を使ったのは ${!prefix@} 展開が由来である。一方で % は Makefile で使
    われる。実際に試してみる限り % も 0 文字以上に一致する様である。? を使いた
    い所だが、これは無駄に quote をしなければならないので余り使い勝手は良くない。
    と思ったが、現在の実装で実は既に ? は使えるのではないか? と思ったが解析の段
    階で除外している様だ。

    もし quote する事を受け入れれば *? は普通に使えて良い気がする。少なくとも
    quote しなければ使えないのだから対応しない理由もない。対応に入れる事にした。

  * vbell: 新しい内容で既存の内容を上書きする時、前の vbell の内容が残ってしまう [#D2181]

    menu-complete のページ番号表示。これ以上進めませんのエラーメッセージが表示
    されている内に元のページに戻ると visible-bell erase がキャンセルされてエラー
    メッセージが残留する。然し、ページ番号表示の visible-bell との境界が分から
    なくて見にくくなる。visible-bell で既に表示している物を上書きする時は、前に
    表示していた物を一旦消去してから上書きするべきでは。

    調べるとちゃんと clear は呼び出されている様だが、消す対象の情報を確認したら
    前の情報ではなく新しい vbell の内容の情報が格納されていた。新しい vbell の
    内容で初期化を実施する前に、前の vbell を erase する必要がある。処理の順序
    を入れ替えたら直った。

  * history: 初期化した瞬間の履歴番号が間違っている気がする。一個多い [#D2180]
    Ref #D2153

    履歴がロードされた段階で正しいものに置き換わるが瞬間的に何か操作をすると何
    か変な事になりそうな気がする。

    調べると \q{history-index} を使っていて、これは _ble_history_INDEX を使って
    いる。これは ble/string#split-words の代わりに ble/string#split を間違って
    使っていたのが悪い。#D2153 の regression である。

  * [解消] 2024-02-14 README: exec_exit_mark も disable features に入れる [#D2179]
    https://forum.atuin.sh/t/atuin-bash-and-ble-sh/175/12
    → commit 2635afae で対応済み

    fzf についての注記はもっと強調する。

  * edit: support "bleopt edit_magic_accept=verify-syntax" [#D2178]

    履歴展開で文法的におかしな事になる事も結構ある。展開後に文法的に壊れていた
    ら一旦停止する様にするべきではないか。

    * done: blerc.template
    * done: wiki
    * done: これは既定のオプションにする。こうするとbash/readline の振る舞いと
      異なって、文法チェックの為に必ずコマンドラインが置き換わる形になるが、ま
      あ元の振る舞いの方が良い訳でもないのでこれで良い。元の振る舞いが良い人は
      verify-syntax を外してもらう事にする。

  * main: BLE_VER 対応 [#D2177]

    wezterm や atuin integration で _ble_version を参照するのも忍びない。かと言っ
    て BLE_VERSINFO は実際の所使いにくい。変数名は微妙だが __cplusplus や
    MSCVER や GCCVER の様に一つの整数に纏めた物という事で BLEVER が良さそうな気
    がする。然し名前空間的に BLE_VER の方が良い。

  * [外部] edit: wezterm で prompt_status_line にカーソルが被さる? [#D2176]
    https://github.com/akinomyoga/ble.sh/issues/413

    ? yes: PROMPT_COMMAND で改行を出力すると計算がずれる?

      | 最初は wezterm の integration で勝手に改行を挿入するのが悪いと思ったが、
      | よく考えたら PROMPT_COMMAND で何かメッセージを出力する設定があったらそ
      | れでも壊れるのではないか。status line を表示するのは PROMPT_COMMAND よ
      | りも後にしなければならない気がする。
      |
      | 実際に問題が起こるかどうかを確認する→と思ったがそうでもない様だ。不思
      | 議だ。何故 wezterm の中だと問題が起こるのだろうか。何かの同期の都合でず
      | れているのだろうか。ble.sh は buffering を行っているので、ずれる? と思っ
      | たが、PROMPT_COMMAND を実行する前に flush している筈だし、wezterm
      | precmd は直接 printf しているので遅延される事もない筈だ。或いは wezterm
      | は FreshLineAndStartPrompt に於いて何か特別の事をしているのだろうか?
      | WezTerm 自体が改行調整を遅延するとは思えない。
      |
      | 別に ble.sh は PROMPT_COMMAND から出てくる出力を勝手に buffering したり
      | はしていない。
      |
      | 或いは wezterm の中限定で PROMPT_COMMAND で何か出力するとずれてしまうと
      | いう事なのか? wezterm の上で試す必要がある気がする。

      色々試して分かった。先ず wezterm での問題は空行に対して RET を押した時に
      だけ発生する。そして、wezterm でなくても PROMPT_COMMAND の中で何かを出力
      したりすると同じ現象が発生する。従って、これは wezterm 特有の問題ではない。

    ? そもそも PROMPT_COMMAND 評価は ble.sh を使っていない時には空行に対して発
      生するのだったか? そこからして振る舞いが違う可能性?

    よく見たら当に bleopt prompt_command_changes_layout というオプションが存在
    していた。なので本来はこれを指定すれば済む話である。但し、wezterm の場合に
    は実際にやって見た所、status line を一旦消して PROMPT_COMMAND を評価してま
    た表示するという具合になって余り滑らかでなくなってしまうのでやはり
    FreshLine を省略する方向で行けないか質問をする事にする。

    * wezterm: PS1, PS2 がそれぞれ左プロンプト・右プロンプトという具合になって
      いるが本当か? 実際には使われていない様なので関係ないかもしれないが。また、
      その他の prompt_status_line についても値を割り当てるべきか。そもそも
      wezterm は status line の様な変な所に表示するプロンプトの存在を想定してい
      るか。どの様に使われるのかの説明はあるだろうか。

    * wezterm に於いて _ble_version を参照したいがこれは如何にも内部変数である。
      スカラー値として BLE_VER なる物を導入して 0.3 にも backport したい気がす
      る。因みに別に backport していなくても、0.4 以上というチェックであれば問
      題はない筈。問題は BLE_VER を今導入したとしても少なくとも devel release
      を一回はして、更にその後暫く待ってからでないと行けないという事。という事
      を考えると暫くは内部変数ではあるが _ble_version を使う様にした方が良い気
      がする。

      BLE_ATTACHED を参照する可能性も考えたが、そもそも BLE_VERSION が設定され
      ている時には bash-preexec が登録されていないので何も動作しない。なので、
      常に BLE_ATTACHED になっているという想定で良い気がする。

  * 2021-09-20 sabbrev: accept-line の時にも展開する可能性について (requested by pl643, bkerin) [#D2175]
    https://github.com/akinomyoga/ble.sh/discussions/138
    https://github.com/akinomyoga/ble.sh/issues/406#issuecomment-1939461192

    * zsh-abbr の振る舞いについても確認する。

    * 振る舞いについての考察

      a グローバルに全ての合致する単語を置換する。

        x 先ず、意図しない物まで展開されてしまう可能性がある。

        x 展開を意図する単語があったとしても、通常は magic-space によって既に展
          開されていると期待するべき。なのでわざわざグローバルな展開を試みるま
          でもない。

      b 或いはその場所にある単語だけを展開する magic-accept 的な物。

      元の要求が結局どのような物だったかは返事がないので不明だが、考えて見るに
      b の方が良い。


    2024-02-25 bkerin が似た様な事を Recipes に書いていた。確認を取ったら #138
    に返信をくれた。なので実装する事にする。やはりその場にある単語だけを展開す
    る事にする。

    * bleopt edit_magic_accept: 展開の種類 sabbrev/alias/etc を設定できる
      様にする? これは履歴展開の処理の箇所で同時にした方が良い。shopt -s
      histverify 等の影響も受ける様にする。と思ったがやはり有効な展開の種類を設
      定するリストに verify という opt も入れる事にした。

      * done: wiki に追加する
      * done: blerc.template に追加する

    * done: ble-edit/hist_expanded.update は現在内部で [[ -o histexpand ]] を
      チェックする事になっている。然し、set -H の設定に関係なく外から呼び出した
      い。なので、呼び出し元でチェックする様にしないか。

      既存の使用場所は accept-line の他に ble/widget/insert-arg.impl と
      history-expand-line の系列 (他に history-and-alias-expand-line,
      history-expand-backward-line) がある。

      * ok: insert-arg に関しては実は set -H の設定に関係なく展開して欲しい状況
        の気がする。今の実装には問題がある。修正する。

      * ok: history-expand-line に関しては bash の振る舞いを見ると set -H を設
        定しないと何も実行しないみたいだ。然し、これは実装上の都合なのか意図的
        な物なのかはよく分からない。というか、明示的に呼び出しているのだから履
        歴展開を一時的に有効にしても良いのではないかという気がする。

        この際 history-expand-line は set +H でも展開を実施する様に変更する事に
        する。

      * done: そもそも history -p '!!' は set -H が指定されていないと何も実行し
        ない様だ。恐らくこれが histexpand のチェックが
        ble-edit/hist_expanded.update の内部にあった理由だろう。

        自前で set -H を保存・復元する事にする。$- を保存すれば良い。

      * done: 関数名を色々変える。展開結果は hist_expanded ではなく ret を通し
        て返す様に変更する。hist_expanded がもう残っていないか確認する。

    ----

    完成したと思ってすぐに push してしまったがテストするのを忘れていた。通常の
    展開に関してはいい感じに動いているが verify が全く動いていない。どうも
    magic-space から実装を持ってきた時に type-status を sabbrev/expand に指定し
    たままになっていたので、常に sabbrev expansion が失敗した取り扱いになってい
    て、然し sabbrev expansion は inline で _ble_edit_str を書き換えるのでその
    まま動いている感じになっていたという事。

    * is_line_expanded=1 を設定していたが、これだとインラインで展開してコマンド
      ラインが既に書き換わっているのに改めて展開結果を表示する形になって変であ
      る。然しだからと言って _ble_edit_str を展開前に保持したまま、展開結果を味
      気ない [ble: expand] で表示するのも変な感じがする。なので
      is_line_expanded=1 は履歴展開だけで有効にする事にした。

    * verify の時に何も起こらずにその場で展開だけ起こるのも少し変な気がするので、
      履歴展開と同様に次の行に移動する事にした。

2024-02-24

  * util(joblist): 5.3 でまた色々沢山 foreground dead jobs が表示される [#D2174]

    5.3 ではより多くの foreground dead jobs が表示される様になってしまった。仕
    方がないので取り敢えず表示された物から順に __suppress__ を指定していく事に
    する。色々 todo が溜まっているので小さな変更だが、もう処理してしまう事にす
    る。

  * edit: macOS 3.2 で C-d が効かないという話 (reported by gregwalters) [#D2173]
    https://github.com/akinomyoga/ble.sh/issues/416#event-11897058166

    これは tessus の VM があるのでチェックはできるのでは? と思って振る舞いを確
    認したが tessus の vm 上では問題は再現しない。別に普通に C-d でログアウトで
    きる。

    * decode: 一方で bash-3.2 では left right の SS3 によるキー入力表現が正しく
      処理できないという現象が発生している。一方で bash-5 で受信した場合には
      SS3 による入力でもちゃんと解釈できている。何故だろう。

      bash-3.2$ ble/debug/keylog#end
      ===== bytes =====
      192 155 79 68

      ===== chars =====
      ESC O O D

      ===== keys =====
      M-O D

      bash-5.2$ ble/debug/keylog#end
      ===== bytes =====
      192 155 79 68

      ===== chars =====
      ESC O D

      ===== keys =====
      left

      うーん。登録済みの SS3 keyseq に一致する所で失敗している? declare -p
      _ble_decode_cmap__27_79 を見る限りは 27:79:68 はちゃんと登録されている。
      うーん。ble-decode/char/.getent で wait-input しているがこれが常に失敗す
      るので _ble_decode_cmap_* に登録されたキーが全く動かなくなっていた。これ
      は修正する。is-stdin-ready に既定の終了ステータスを指定できる様にした。

  * [解消] integration/fzf-git: 選択できない branch がある? (reported by dgudim) [#D2172]
    https://github.com/akinomyoga/blesh-contrib/issues/18#issue-2149755976

    Ref #D2166

    然し自分の手元で試してみる限りは特にそういう事は起きていない様に見える。と
    思ったが追っての報告でやっぱり大丈夫という話だ。

    https://github.com/akinomyoga/blesh-contrib/issues/18#issuecomment-1961770147

    先の修正で直ったか、それとも何かの勘違いだったのか。恐らく、エラーメッセー
    ジが表示された事で表示位置がずれて変な物が表示されていたという事なのだろう。

  * edit: [SIGINT] のメッセージはデフォルトで表示しない様にする (motivated by tessus) [#D2171]
    https://forum.atuin.sh/t/issues-and-logging-with-bash/156/14

    これは元々 INT/DEBUG が正しく動いているか分からないからそれの確認の為に表示
    していた。然し、スタックトレースと見るには不完全である。外部コマンドの実行
    時には結局表示されないし、また、関数内で実行している場合でも DEBUG を用いて
    いる事から関数内で一番最後のコマンドを実行していた場合には DEBUG が呼び出さ
    れずに関数を抜けるのでそのフレームは抜ける。RETURN も一緒に trap すれば原理
    的にはそのフレームの情報を抜き出せるが、其処までする程の事でもない。ユーザー
    的には別に見てもよく分からないし、既定で off で良い気がする。

  * util(stty): support `bleopt term_stty_restore` (requested by TheFantasticWarrior) [#D2170]
    https://github.com/akinomyoga/ble.sh/issues/412

    意味不明な設定をしたいから全ての設定を列挙しろと言っているが曖昧である。そ
    もそも全ての設定が何を意味するのかも謎に満ちている。

  * main: source blesh-nightly/ble.sh --install [#D2169]
    instruction が長すぎるので。試しに実装してみたが別に instruction はそんなに
    短くなっていない。でも、少なくとも cp や rm を入力するよりは分かりやすくなっ
    た気がするので良い事にする。

    テストしていなかった。改めて実行してみたら全然動かなかった。急いで修正を行
    う。序でに #D2171 の ^C についても省略する様にする変更を適用する。

2024-02-23

  * 2023-06-12 [解消] stty: bash-5.2 以上 exit 後の stty 状態を正しく復元する手法? [#D2168]
    Refs #D2046 #D2153

    呼び出し元の端末が ble.sh であれば呼び出し元で改めて stty を呼び出すから問
    題ないが、そうでなければ壊れた stty 状態のままになって問題になる。呼び出し
    元が ble.sh であっても、連続で複数の対話コマンドを実行した場合には後続の対
    話コマンドの動作に影響を与える。

    これは bash-5.2 以降で EXIT trap が終了直前ではなく exit を呼び出した
    context で呼び出されるようになったのが原因である。bash-5.2 でもちゃんと終了
    時に stty を正しく設定する方法を考える必要がある。

    a 単に stty を遅延して呼び出すようにするのだと race condition で stty が間
      に合わなかったり、逆に次のコマンドが stty を調整した後にそれを上書きして
      しまったりする事になる。

    b DEBUG trap でトップレベルまで抜けてから exit を実行する? 然し、依然として
      bind の中で exit が実行される事には他ならないので問題はそのままである。

      a 例えば #D2046 の a で考えた様に一旦キー入力を介する必要がある。例えば
        DSR を送信して返事が来たら終了するという手がある。DSR に対応しているか
        どうかについては端末自動判定の結果があるかどうかで判定する事ができる。
        応答がない場合の可能性も考えると何か一つキーが来たらその内容に関わらず
        終了する。但し、CSI を途中で切ってしまうと中途半端な内容が stdin に残っ
        て問題になるので byte または char ではなく key に対して hook をかける必
        要がある。

      b 或いは stdin を潰してしまえばその場で終了するのではないか? と思ったがそ
        の場合に正しく端末の状態が復元されるのかは非自明である。更に exit に指
        定した exit status を反映させる方法が存在しない。

  * histdb の色々を実装する [#D2167]

    様々の関数が必要になる。ble/util/time は既に追加した。ble/util/mktime に修
    正を入れた。ble/color/convert-rgb24-to-color256 の類は少しでも色があると
    6x6x6 cube に切り替わるが 6 段階しか白黒がない。6x6x6 の対角色になる場合に
    は代わりに 24 grayscale に切り替える事にした。

    新しい機能に関しては何時までも改善・追加したい事があるので何処か適当な所で
    修正をやめて push した方が良い。残りの機能について独立した項目で議論する事
    にすれば良い。

    色々たまって来たのでいい加減今の状態で push する事にする。

  * integration/fzf-git: "ble/util/print" のエラーが出る (reported by dgudim) [#D2166]
    https://github.com/akinomyoga/blesh-contrib/issues/18

    これは最近の make scan 修正で不用意に echo を ble/util/print に書き換えたの
    が問題だった。fzf-git は自分自身をコマンドとしても実行するので
    ble/util/print の様な物は使えないのだった。代わりに printf '%s\n' を直接使
    う事にした。ble/contrib/.../print の様なコマンドを定義すると長くなり過ぎる。

    * ok: 最初は ble-import の source で勝手に引数が継承されているのかもしれな
      いと思ったが、ble/util/import では既にちゃんと対策がされていたので関係な
      い。

  * util: macOS で stderr が消失する問題 (reported by tessus, jon-hotaisle) [#D2165]

    macOS で stderr が消滅している。というか、現象的には bash-3.1 で起きていた
    現象と酷似している。

    ? 実は file descriptor の rediraction に失敗しているという可能性? 今まで動
      いていたのは bash-3.2 用の wa である 32>&- 32>redir 等の方法がカバーして
      いたから等の可能性。

      調べてみると stdin の処理を実行した後に /dev/null に置き換わっている。こ
      れは如何にも bash-3.2 以下で発生していたのと同じ現象である。だとすると
      .nextfd が怪しい? #D2164 を確認してみると _ble_util_fd_null の初期化の時
      点で置き換わると書いてあるが、現在の振る舞いは stdin の初期化までは大丈夫
      である。但し、#D2164 に対する修正をした事によって状況が微妙に異なっている
      だけの可能性もあるので、やはり同じ原因である可能性は高い様な気がする。

      どうも発生する条件がある様だが謎である。常に起こる訳では無い。この点は
      3.1 とは異なる。然し、最終的にはやはり ble/fd#is-open に於ける 2 の待避に
      失敗している。exec 32>&2 ができないという事。

    何か変な事が起きている。調整を行った後に fd 2 が消滅している。どういう事だ
    ろう。更にそれがどうして後々に /dev/null に置き換わるのかも謎である。取り敢
    えず fd が 2 に置き換わる所は確認しておきたい。

    FreeBSD でも同じ現象が起こっている。minix では起こっていない。

    * 因みに ble.sh のテストは全てクリアしている。

    最終的に以下の bash スクリプトで問題が再現する。

      #!/usr/bin/env bash
      exec 51>1.txt
      exec 10>&-; { exec 52<&10; } 51</dev/null; exec 51<&52
      exec 50>&51
      exec 50>2.txt
      echo hi >&50
      ls -l 1.txt 2.txt

    どうやら以前通りに一旦 fd を閉じておけば失敗はしないみたいなので、常に fd
    は閉じる事にする。

    * ok: macOS では C.UTF-8 が効かない様だ。と思って対策しようと思ったが既に
      C.UTF-8 が使われている所は皆 2>/dev/null 等がされていた。CentOS 7 の為に
      同様の対策をしていてそれが未だ壊れていなかったという事。コメントで CentOS
      7 に加えて macOS も言及した。

    * fixed: CI で tty を使ったテストが失敗していたので、tty を開けない場合には
      テストをスキップする様にする。修正した。

    * fixed: そもそも test-bash のテストカウントがずれている。修正する。

    ----

    2024-02-24 引き続き FreeBSD の上で振る舞いを調べる。strace の結果を元にして
    簡単なプログラムを書いても変な振る舞いは再現しない。bash-5.2.21 のソースの
    中で一体どうなっているか見ていく事にする。どうも一旦は dup2 を実行してちゃ
    んと redirect をしているが、後に undo されている様だ。add_undo_redirect を
    潰すとちゃんと動く様になるので undo redirect が原因である事は確実。+cloexec
    がなければ undo は起こらないので、何らかの条件で何かが失敗して、結果として
    undo が起こるという事?

    どうやら add_undo_redirect で "experimental: ..." if (fd >= SHELL_FD_BASE
    && ri != r_close_this && clexec_flag) と称している if 文の中で登録されてい
    る undo redirect が exec の成否に関わらず実行される様だ。

    →然し疑問は何故 Linux でこれが発火しないのかという事。Linux では何らかの条
    件が満たされずにこの分岐に入らないという事? 然し条件は全部満たす様な気がす
    る。改めて試してみたら実は Linux でも同様の問題がある? 何故 Linux では OK
    と思ったのだったか。また、何故実際に問題が表面化していなかったのか。謎であ
    る。何れにしても Linux で同様の振る舞いだとだとすると他の疑問点は色々解消し
    てなくなる。

    とにかく問題は O_CLOEXEC のある fd に対しては常に発生する様である。以下が更
    に単純化した test case である。

      #!/usr/bin/env bash
      enable -f ~/opt/bash/dev/lib/bash/fdflags fdflags
      exec 50>1.txt
      fdflags -s +cloexec 50
      exec 50>2.txt
      echo hi >&50
      ls -l 1.txt 2.txt

    問題はこの bash の振る舞いは修正するべき物なのかそれとも意図的な物なのかと
    いう事である。うーん。色々説明されているし何らかの意図があるのだろう。面倒
    なのでこれはこれで良い事にする。但し、macOS/FreeBSD 特有の現象ではない事が
    分かったのでコメントは修正する必要がある。

2024-02-18

  * util: bash-3.1 でプロンプトが表示されなくなっている [#D2164]

    元々 #D2159 のテストの過程で見つけて確かに #2159 以降で顕在化した問題だが、
    これは bash-3.1 のバグによって引き起こされていて実際にはもっと影響範囲が広
    い様に思われるので独立した項目とする。

    x bash-3.1 でプロンプトが表示されない。bash-3.2 では発生しない。何が起こっ
      ているのだろうか? これは次の項目にある fd#add-cloexec を呼び出さない様に
      しても変化しない。先ずはこれを修正したい。

      プロンプトは恐らく表示されている。然し、stderr が正しい所に繋がっていない。
      そもそも source ble.sh した直後に stderr に何か出力しても何も出ない。実際
      に ls -l /proc/$$/fd で確認してみると /dev/null に繋がっている。

      また、沢山の fd が既にこの時点でできている。うーん。ble/fd#add-cloexec を
      完全に潰すと fd が増える問題は発生しなくなるがやはり /dev/null に繋がって
      しまう問題は変わっていにない。他に気づくのは 3.1 だと 40, 41 が
      /dev/null, /dev/tty に繋がっているという事。/dev/tty が開いているという事
      は -t のテストに失敗しているという事だろうか?

      調べていくとどうも最初から /dev/null に繋がっている。何故?
      _ble_util_fd_null を初期化した時点で /dev/null に繋がっている様だ。

    ? ok: 一方で、そうだとしても最初のプロンプトの表示までは tui に繋げておくべ
      きでは? と思ったが既にそういう実装になっている。

    | 何故か関数の外ではちゃんとtty に繋がっていて、関数の中に入った途端に
    | stderr は /dev/null に繋がっている様だ。謎だ。或いは 3.1 では関数内では必
    | ず /dev/null に繋がるのだろうか? それとも ble.sh という特殊なスクリプトが
    | そうさせている?
    |
    | うーん。調べると別に関数を抜けたら元に戻るというのは再現しなくなった。勘
    | 違いかもしれない。それよりも nextfd を呼び出すと 2 が /dev/null に繋がっ
    | た状態になってしまうという事が分かった。
    |
    | 更に ble/fd#is-open でも発生する事が分かった。もしかして redir に失敗する
    | と関数の実行自体がキャンセルされる?
    |
    | うーん。辿って行ったらそもそも exec 33>&- で stream を閉じるのに失敗して
    | いる。その所為で 33 が /dev/null に繋がった儘になり、また bash-3.1 の別の
    | バグにより exec 33>&2 でも 33 が更新されずに /dev/null のままになる。それ
    | が 2 に書き戻されて /dev/null に置き換わってしまうという事の様だ。
    |
    | 何故 33>&- で閉じないのか? うーん。一応 99>&33- 等としたら閉じはする。然
    | しこれだと更にもう一つの fd 99 が必要になる。と思ったが 99 は置き換わって
    | いない様なので実は既存の物でも良いのかもしれない。
    |
    | 然し前にテストした時にはちゃんと動いていた気がする。不思議だ。もっと単純
    | な設定で問題が再現するのか確認する → ble.sh なしで再現する。もっと単純化
    | しても発生する。というか 33>&- の形だと常に発生する。以前は bash-3.1 でも
    | これを使えば 33>&- 33>&XX とする事ができるのではなかったか? 探してみると
    | fd#alloc にコメントが残っていて #D0857 を参照している。然し其処を見ると
    | 3.2 と書いてあるし、何だか別の問題について話している様に見える。但し、対
    | 策としては一貫している。

    まとめると、bash-3.1 では 33>&- 等としても file descriptor が閉じないバグが
    あって、更に既知のバグである 33>redir で 33 が閉じていないと失敗する
    (#D0857) というバグが組み合わさって面倒な事になっている。#D0857 の
    workaround は exec 33>&- 33>redir とする事であったが、実はこれは 3.2 では動
    いても 3.1 では動かないという事が判明してしまった。

    fd を閉じようと思ったら move_fd 99>&33- を実行するしかない様だ。一方で、移
    動先の 99 として何を選ぶのかは微妙である。3.1 だけでこの対策をするのだとし
    たら、99>/dev/null として置いて、後はこれに対して redir を実行すれば良い様
    に見える。何故なら実験した限りだと 99>&33- としても 99 に対するコピーは失敗
    して単に 33 が閉じられるだけに見えるので。然し、これは他の version だと成功
    してしまって 99 が置き換わってしまうので使えない方法である。

    うーん。これは設計を改めて考え直す必要がある気がする。また、この微妙な振
    る舞いは ble-0.3 の alloc/openat の実装にも影響があるのではないか。別項目
    で議論するべきの気がする。

    x fixed: bash-3.2 でエラーが出る様になった。と思ったが今まで出ていた
      ~/.bashrc のテスト用コードのエラーが見えていなかったのが見える様になった
      だけの気がする。或いは今まで bash-3.2 で ~/.bashrc を実行していなかった。

    x ok: この修正をしたら 3.2 で cloexec が効かなくなっている。うーん。修正前
      は動いていた筈

      →と思って結構遡ってみたが別に古い物でも cloexec はちゃんと働いていない様
      だ。#D2158 でも 3.2 についてちゃんと動作を確認した様な事は書かれていない。
      恐らく単にテストしていなかっただけ。また、様々の環境のテストでも msys1 以
      外は 4.0 以降だったのだろうという気がする。

      4.0 で動いているのは procfs があるからかもしれない。procfs がない場合でも
      ちゃんと cloexec が動くかは現在の codebase でも確かめるべき → procfs を
      使わない場合でもちゃんと 4.0 で cloexec は付加できている。つまり、cloexec
      のアプローチの問題という訳ではない。

      bash-3.2 に於ける振る舞いについて確認するべきか? 手元で bash-3.2 --norc
      で確認する限りは 3.2 でも cloexec を付加する事は可能の様に思われる。何故
      ble.sh では動かない? 試しに ble/fd#add-cloexec を色々の fd に適用してみた
      が全く効果がない。

      実際に ble/fd#add-cloexec の実装を抜き出して各箇所で振る舞いを見てみたが、
      undo fd を見つけて exec する所までは良い。然し、undo fd にどうやら
      cloexec がついていない様だ。 ls self で見ても残っている。手で clone した
      時との違いは何だろうか。

      うーん。改めて norc で試してみたが cloexec は付加されていない。付加されて
      いる様な気がしたのは勘違いだろうか? そもそもコピー元の undo fd に cloexec
      がついていない様に見える。不思議だ。

      % と思ったが自分でやった限りは undo fd にちゃんと cloexec がついている。
      % という事は .probe で見つけた fd が実は undo fd ではないという可能性? 然
      % し、何れにしても undo fd から exec で移すと cloexec は消滅する様に見え
      % る。
      %
      % $ exec 50>/dev/null
      % $ { ls /proc/$$/fd; ls /proc/self/fd; exec 51>&10; } 50>/dev/tty
      % $ ls /proc/$$/fd; ls /proc/self/fd
      %
      % 以下の様に mv で移したとしても cloexec は消えている。
      %
      % $ exec 50>/dev/null
      % $ { ls /proc/$$/fd; ls /proc/self/fd; exec 51>&10-; exec 10>&51; } 50>/dev/tty
      % $ ls /proc/$$/fd; ls /proc/self/fd
      %
      % と思ったがよく見ると別に undo fd (10) に cloexec はついていない。改めて
      % 自分で確認する。うーん。やはり undo fd が bash-3.2 では子プロセスに継承
      % されている。どうも cloexec がついていると思ったのは勘違いの様である。何
      % 故こんなに勘違いするのかは分からない。

      これは bash-3.2 特有なのだろうか? それとも 3.0 や 3.1 でも同じ?  → 3.0
      や 3.1 でも同じ振る舞いだった。つまり、3.0 や 3.1 では undo fd でも
      cloexec がついていないので undo fd を clone する作戦は全く使えない。

      [結論] bash-3.x では undo fd にも cloexec がついていないので、undo fd を
      dup しても当然 cloexec はつかない。従って、この方針はそもそも使えない。

    * done: m scan test を追加してコードを修正する必要がある

    x reject: そもそもコマンドを実行する度にどんどん使っている fd の数が増えて
      いく。overwrite が効いていないのだろうか。これは ble/fd#add-cloexec を実
      行しない限りは問題にならない。一方で 3.1 に於ける ble/fd#add-cloexec の実
      装について考える必要がある。

      ble/fd#add-cloexec 対応は諦める。2つ前の調査の結果 bash-3.2 以下では
      O_CLOEXEC に対応する事は不可能なので、そもそも fd#add-cloexec は実装しな
      い事にした。ble/fd#add-cloexec を試みない限りは問題は発生しない様なので取
      り敢えず気にしない事にする。

    ----

    2024-02-21 msys1 を再びテストしようと思ったら再び bad fd のエラーが出る様に
    なった。やはり fd の取り扱いを大きく書き換えてまたバグができたのだろうか。
    先ず何処でエラーが発生しているか確認する。

    どうも /dev/null に繋いだ筈の fd 30 が駄目の様だ。うーん。自分で直接 30 を
    開いたりする時には問題は発生しない。bash-3.1 なら chat でも再現する。.close
    で exec 30<&"$1"- を実行している所でエラーになっている。或いは、既に閉じて
    いる fd について move を試みると発生する? →確かにエラーが発生する。これは
    潰す必要がある。

    然し、疑問は何故 bad fd のメッセージが行き先の 30 についてなのかという事。
    30<&31- を実行しようとして 31 が存在しないのだったら 31 に対してエラーメッ
    セージが発生するべきなのでは? 実際に bash-3.1 で手で実行すると 31 の方でエ
    ラーメッセージになる。うーん。分かった。 exec 30<&"$v"- の形式だと fd $v が
    開いていなかった時のエラーメッセージが 30 に対してになる。

    取り敢えず対策はした。最新の bash でも似たようなエラーメッセージの問題はあ
    るのだろうか → 何と現在の bash でも同じ問題がある。

2024-02-17

  * msys1 をテストの為に久しぶりに使ってみたが色々と問題が発生する [#D2163]

    動作確認を行う。

    * fixed: 先ず普通に bash をダブルクリックして起動すると . を通してしか基本
      ユーティリティーを見つけられない。その時に ./stty 等という形で登録されて
      しまうので cd するともう動かなくなってしまう。freeze-utility-path の時点
      で . が出たら絶対パスに翻訳しておく必要がある。

      然し、そうだとしても cd して他のディレクトリに行った瞬間に ble.sh は動か
      なくならないとしてもユーザーが呼び出す通常ユーティリティーが全部動かない。
      然し、これは ble.sh が感知する所ではない様にも思う。

    * fixed: HOME が正しく取得できていない。取得できていないのに取得できた事に
      なっている。先ず getent が存在していないので正しく取得できていない。そし
      て、空になっても空のディレクトリとして認識されていたのは判定が甘かったか
      ら。判定については修正した。

    * fixed: そもそも tput が存在しないので例えば _ble_term_colors=256 になって
      いる。TERM=cygwin の時だけは tput が存在しない場合の既定値を 8 にして良い
      のでは? と思ったが、よく考えたらそもそも既定値が 256 というのも変な気がす
      る。普通の環境では必ず tput が存在するので、そもそもこの既定値が使われる
      事はないので 256 としていても普通はより少ない色数になる。逆に tput すらな
      い環境でフルの着色に対応しているとは思われないし、もし対応していたとして
      もその様な環境でユーザーが果たして 256 色の着色を期待するだろうか。色々考
      えるとそもそもの既定値を 256 にする意義が薄い。既定値は 8 にする事にする。

    * fixed: そもそも /dev/zero は msys1 では dup できない様だ。MSYS1 では
      /dev/zero は開かない事にした。また、msys1 の判定コードもメインの方に移動
      する事にした。

    * fixed: __ble_time__ が履歴に追加される問題は現れなくなった。再現する為に
      特に特別な事が必要だった様な気もしないので、何かを直したら直ったのだろう。
      パスの問題だったのだろうか。もしまた発生したらその時に調べる。

      と思ったら再現した。~/.bash_history の permission が壊れて書き換えできな
      くなっていた。sed -i を使うと permission が変わってしまう様だ。

      うーん。よく分からないが HISTTIMESTAMP __ble_time_%s__ を設定しているとこ
      ろが、%s が空文字列に展開されているという事のようだ。一方で history.sh で
      は [0-9]+ になるという事を想定している。

      然しこれは bash-3.1 で常に発生する事なのだろうか。それとも msys1 だけで起
      こる事なのだろうか。chatoyancy の上で 3.1 で試してみた限りでは
      __ble_time___ の除去に失敗しているという事はないので、msys1 特有の問題の
      気がする → __ble_time_[0-9]*__ で一致させる様にして問題が解消した事を確
      認した。

    * ok: ble/widget/display-shell-[TAB] で補完を試みると変なエラーが出る

      ble/[tab] でも問題が発生する。chatoyancy の上の bash 3.1 では発生しない。
      →これは windows の sort を先に見つけていたからと分かった。windows の
      sort に対して sort -u としてエラーになっていた。msys.bat から開いた時には
      ちゃんと /bin/sort を使っていた。

    * ok: C-d が効かない

      そもそも裏で動かしている筈の補助プロセスが起動していない。うーん。
      msys.bat から起動したらちゃんとコンパイルもできて裏で起動している。然し、
      それでも C-d は効かない。そもそも C-d を受け取るための物だったのかも怪し
      いが→確認した見たがやはり C-d を受け取る為の物だったと思って良さそう。特
      に fname2.buff に出力された内容を読み取ってそれをシェル関数に渡す関数になっ
      ている様だ。シェル関数で実装しなかったのは何故? non-blocking な読み取りが
      できないから? → fifo が存在しないからそれの代わりにしようとした様に見える。

      或いは今ならもっと別の方法があるだろうか。とにかくファイルに書き込んでお
      いて、それを定期的に読み出す。十分可能の気がする。何故 C でやっていたのだっ
      たか。Sleep が重いからだろうか。当時の記録を探しても良い。#D1273 に記録が
      残っている。うーん。色々同期の問題や sleep の重さの問題の様な気がする。何
      れにしても一度は動いていた物だから余り変更を加えずにまた動く様にしたい。

      調べてみるとそもそも gcc が存在していないから helper がコンパイルされてい
      ないのだった。msys.bat というファイルが実は msys の root に存在して家そこ
      から起動したらちゃんと background でプロセスが起動する様になった。然しそ
      れでも C-d は効かない。

      →と思ったが今実行するとちゃんと C-d も動いている。一旦コンパイルしたから
      だろうか。或いは、パソコンを再起動したから? よく分からないが元々積極的に
      サポートする必要があるかも分からないし、だいたい動けば良いのでこれで良い
      事にする。

    * fixed: 終了時に何かエラーメッセージが一瞬現れる

      →これはどうも sh で起動していて最後の unset -f
      ble-edit/bind/load-editing-mode:* と unset -f ble/util/import/guard:* の
      実行時に関数名が不正であるとのエラーが出ているという事の様だ。うーん。
      POSIX mode 等を一旦元に戻して hook を実行するべきではないか?
      ble/base/adjust-* を一通り実行してから hook 等を呼び出す事にした。エラー
      メッセージは消えた。

2024-02-16

  * util,complete: Solaris nawk は /= で始まる正規表現を字句解析できない [#D2162]

    これは ble/fd#add-cloexec の実装検証時に気づいた。ble/fd#add-cloexec の実装
    とは全く関係ないし、遡って適用した方が良いかもしれないので独立した修正にす
    る。

    ----

    nawk が /=.../ という正規表現に対応していない? 以下でも問題が起こる。

    echo = | nawk 'sub(/=/, "")'
    echo = | nawk '$0 ~ /=/'

    repository 内部には以下の様な例がある。これだけかは不明。

    $ git grep -E '(g?sub|match)\(.*/=| !?~ /='

    これは別項目で処理するべきか?

    WA として何ができるか? sub("=", "") とすれば良い? 括弧で囲めば問題ない
    様だ。digraph か何かに引っ掛かっていたという事なのか? と思ったがそうい
    う digraph はない。或いは /= operator があるという事? と思ったがこれは
    単に除算代入演算子である。つまり /= で始まる正規表現リテラルは古い nawk
    では使えないという事。

  * util: ble/util/time が bash 4.2 未満で値を返していない [#D2161]

    bash-4.1 以下で histdb の sqlite3 文法エラーが出ると思ったら、ble/util/time
    が何も値を返していなかった。修正した。

  * edit: BLE_COMMAND_ID が 2 から始まっている [#D2160]

    何故? 中で BLE_COMMAND_ID を参照しても同様。command id は ++_ble_edit_CMD
    で決定している。初期化はどうなっているかというと _ble_edit_LINENO+1 になっ
    ている。実際 \# で参照する時はそうなっている筈。

    なので _ble_edit_CMD の値は正しくて、それをコマンドに反映させる時の cmd id
    が変なのである。++_ble_edit_CMD ではなく _ble_edit_CMD++ に変更した。動いて
    いる。

2024-02-15

  * 2024-02-11 Bad file descriptor 33 のメッセージが出る (reported by ragnarov) [#D2159]
    https://github.com/akinomyoga/ble.sh/issues/401#issuecomment-1937040118

    再起動したら直ったというが、これはちゃんと対策した筈なのに出ているのが気に
    なる。再現するかどうかから確かめる事にする。うーん。例え記録したら fd が閉
    じていたり、関係ない物に繋がっていたとしても大丈夫の筈なのだが。少なくとも、
    標準入出力が tty に繋がっている限りは大丈夫の筈である。不思議である。或いは
    2>/dev/tty みたいな事をしていると駄目になるが…。

    少なくとも自分で試す限りは問題は発生しない。

    試してみたら普通に発生する。何が起こっているかというと

    1. _ble_util_fd_null が >/dev/null に繋がって export されているが、元の
      /dev/null stream は既に消滅している (何故?)

    2. この状態で他の fd の保存処理で同じ番号が使われる → _ble_util_fd_null が
      その別の stream に繋がっていると判定されて再利用される。

    現在は新しく確保する様にしているから問題ないのでは? と思ったが、オプション
    で connect_tty=inherit をした時にはやはり既存の物を使おうとする実装になって
    いる。(何故新しく同じ番号に開くのではなく再利用しようとする?) もし既存の物
    を使うのではなくて overwrite にするとしても、他の目的で開いた stream を潰す
    事になるので問題になる。

    そもそも _ble_util_fd_ で始まる変数は全て有効性をチェックするべきでは?

  * util: ble/fd#cloexec (kitty tab が時々閉じない) [#D2158]
    https://github.com/akinomyoga/ble.sh/issues/402

    自分の所では再現できないが他の人が同じ現象があると言っている。或いは最新版
    の kitty でしか起こらない可能性? と思ったが自分も最新版で試した様な気がする。
    或いは、bash の version が古いのかもしれない。後でまた試す。

    報告の ps を見て気づいたがどうやら Wayland application は開始時に端末を切断
    するらしい。それでも fd を保持している事があって、それで tab が閉じないとい
    う現象になるらしい。

    しかし ble.sh を使っている時にのみ起こるとはどういう事かと思っていたが、よ
    く考えてみたら ble.sh は tty を他の fd に dup している。それが残留している
    という事の気がする。然し子プロセスで fd が消える様にする為には O_CLOEXEC を
    付けなければならないが、シェルスクリプトではできない。fdflags 等がひつよう
    になる。

    [cloexec 実装]

    もしかすると cloexec を付加する trick を見つけたかもしれない

    * ble/fd#cloexec

      既に cloexec がついている fd は exec で dup しても cloexec がついたままで
      ある。そして redirection の時の bookkeeping は cloexec がつくのでこれで
      cloexec をつける事ができる。

      * reject: nextfd において procfs が使える場合はそれを使う可能性? glob
        expansion で整数を生成して判定する方が高速に scan できる可能性? 然し現
        在の実装は前回 allocate した物の次に使える物を最初に試す実装になってい
        るので、そもそも最初から空いている可能性が高く単に redirection を一回実
        行するだけで大体の場合成功すると期待している。なので、わざわざ procfs
        にアクセスして glob expan を実行するよりも高速ではないか。

        $ ble-measure "ble/util/eval-pathname-expansion '/proc/$$/fd/*'"
            100.832 usec/eval: ble/util/eval-pathname-expansion '/proc/3555952/fd/*' (x1000)
        $ ble-measure ble/fd#is-open '50'
             20.285 usec/eval: ble/fd#is-open 50 (x5000)

        実際に計測してみると pathname-expansion を実行してもそれ程時間がかかる
        訳ではない様だ。但し展開結果に対してループで処理をしなければならない事
        を思うと、そちらの処理のほうが断然時間がかかるのではないかと思われる。

      * bash が何処に bookkeeping するか予測する必要がある。先ず、redirection に
        於いて fnctl で dup する時の探索範囲を調べる。bash は cloexec は
        SET_CLOSE_ON_EXEC というマクロを呼び出して実行している様だ。

        うーん。SHELL_FD_BASE で色々 F_DUPFD している様に見える。然し、このマク
        ロの値は 10 である。なのに、実際に自動で割り当てられた fd は 11, 12 等
        が空いているのにも関わらず 39 等に割り当てている。何故?

        ? fcntl は必ずしも使える最小を選択する訳ではなく、現在割り当てられてい
          る物の最大の次の fd を使うという事なのだろうか? 然し実際に 50 に適当
          な fd を割り当てて見ても別に 51 に割り当てる様になったりはしない。な
          のでこの可能性があるとしてももっと複雑な条件に思われる。

        ? 或いは redirection の処理の瞬間には 10..29 が全て埋まっているという可
          能性? でもそれも変である。そんなに沢山の fd が存在するとは考えにくい
          し、例えあったとしても丁度ぴったり 29 に収まっていて 39 以降には一時
          的な fd が存在していないというのは考えにくい。

        何れにしても予測が正しいとは限らない。言える事は前後の fd のリストを調
        べて増えた fd を特定する必要が何れにしてもあるという事。procfs があれば
        簡単で、もしなければ自前で候補となる fd を探す必要がある。

        よく見たらもっと複雑な事をしている気がする。SHELL_FD_BASE を使っている
        のは {var}> redirections の時だけの様に見える。と思ったが、よく見ると結
        局最終的には SHELL_FD_BASE の様な気がする。具体的に元の fd を保存してい
        るのは add_undo_redirect であり、引数で base を受け取っている。然し、呼
        び出し元では fdbase として -1 を使っている気がする。

        うーん。add_undo_redirect の呼び出しを見てみたら fdbase=30 による呼び出
        しが存在している。引数を指定しているのは唯一箇所である redir.c:1106。うー
        ん。どうやら N>&M の場合は M 以上の値にするという規則の様だ。この取り扱
        いは 8c2fef191 (2011) で導入されている。つまり、古い bash ではそうとは
        限らないという事。4.0 では今の振る舞い。3.2 では振る舞い。然しそれも何
        だか変だ。patch は 2011 なのに何故 4.0 が直っている? bash-4.0.0 で試し
        ても同じだ。4.1, 4.2, 4.3 も同様だった。

        どのバージョンであったとしても候補として 10+ または M+ の両方を確認して
        おけば良い気がする。

      実装してみたが候補の fd がずれるし ble/fd#is-open も振る舞いが怪しいと思っ
      たがよく考えたら ble/fd#is-open 自体の redirection によって一時的に存在し
      ている fd に当たってそれで成功している気がする。

      x ble/fd#is-open 自己衝突の修正

        どの様にしたら良いか? 判定の為に stdout を redirect しているがよく考え
        たらどの fd でも良い気がする。なので、単に 99 だとか重複の可能性が低い
        fd を使って判定すれば良い気がする。

        99にしたがやはり正しく判定できていない。と思ったがよく考えたら stderr
        も redirect しているのでそれを待避した先に fd が作られているという事。
        では、どうやって stderr を処理しつつ is-open を正しく判定すれば良いのか?
        stderr を塞ぐという事はそれまで其処にあった stream を必ず何処かに移動し
        なければならない。

        ble/fd#is-open は、既に使われている物を使っていないと判定する事はないが、
        使われていない物を使っていると判定する事はあるという事。今までの使い方
        的には確実に使われていない物を判定するのが目的だったので大丈夫だったと
        いう事。

        一つの方法は外側で 2>/dev/null に繋いで置いて内側では ble/fd#is-open の
        2 の redirect は実行しないという事の気がするが、根本的解決になっていな
        い。他の ble/fd#is-open を使っている箇所の実装も本当に大丈夫なのか怪し
        い。ble/fd#is-open の実装自体を procfs を使った物に切り替えるという手が
        ある。でもできれば使わないで実装したい。

        例えば exec で 2 を何処か固定位置に移動してしまえば良いのでは? と思った
        が、fd#is-open を呼び出した文脈での 2 が自分の思っている物が分からない
        し微妙な気がする。或いは、fd#is-open 専用の fd num を2つ確保してしまえ
        ば良い?

      ? /dev/null に繋ぐとしたらどの様にするのが最も効率が良い?

        $ ble-measure 'exec 91>/dev/null'
               9.336 usec/eval: exec 91>/dev/null (x10000)
        $ ble-measure 'exec 91>/dev/null 92>&91'
              13.217 usec/eval: exec 91>/dev/null 92>&91 (x10000)
        $ ble-measure 'exec 91>/dev/null 92>/dev/null'
              16.471 usec/eval: exec 91>/dev/null 92>/dev/null (x5000)

        これを見ると 92>&91 には 3.9us かかり、92>/dev/null には 7.1us かかる。
        やはり単純な dup の方が速いがそれ程の差がある訳でもない。

      取り敢えず新しい trick による ble/fd#cloexec は動く様になった。

      * procfs を用いた実装についても行う。と思ったが動かない。

        よく考えたら /proc/$$/fd/* の展開を行う為に使っている
        eval-pathname-expansion や ble/util/assign 自体が fd を色々に変えるので
        単純ではない。redirections を全く使わないでパス名展開を確実に行う方法が
        必要である。GLOBIGNORE が設定されていると困るので空にすると今度は
        dotglob を保存・復元しなければならない。nullglob は良いとしても
        failglob にもちゃんと注意が必要である。eval-pathname-expansion のエラー
        メッセージを抑制しない version が必要になる? また、
        eval-pathname-expansion が定義されるのは実は後の方なので、すぐには使え
        ないというのも非自明な点である。

      然し実際にコマンド入出力に使っている stream については毎回 standard
      streams からコピーする為に、cloexec を設定しても消えてしまう。また、考え
      てみたら tui 用の fd であっても cloexec を付加してしまうと tui から起動し
      た別コマンドの入出力が壊れてしまうのではないか? うーん。何故か分からない
      が問題にはなっていない様だ。bash は 0-2 に対しては cloexec を伝播しないと
      いう事?

      cloexec を除去する方法がないと困る気がする。cloexec のない物を何処かに保
      存しておくという訳にも行かない → と思ったが一旦標準入出力にコピーすれば
      cloexec は外す事ができる様だ。

    * ble/fd#alloc で特に export や preserve 等しなければ cloexec を付加する事
      にした。

      然し不思議なのは redirection を元に戻した時に cloexec がちゃんと外れてい
      るという事。やはり exec で cloexec もコピーできるというのは勘違いか? と思っ
      て自分で試してみるとちゃんと cloexec が付く。と思ったが見ていたのは
      cmd_stdout だった。これは後で標準ストリームから再度コピーされるので元に戻っ
      てしまうのである。

      取り敢えず動いている。次に確認する事は ble.sh tui で動いている時に
      cloexec が標準入出力に働く事がないかという事→動いている。気にしなくて良
      さそう。

    ----

    [テスト]

    新しい実装は壊れると大変な事になるので各環境でのテストを実行する必要がある。
    procfs がある場合でもない場合のテストを実行する。

    * cygwin: ok
    * msys2: ok
    * freebsd: ok
    * solaris: ok

      procfs がある。

      nawk が /=.../ という正規表現に対応していないエラーを発して動かなくなった。
      これは別項目 #D2162 で修正した。

      x procfs を使わないとエラーになる。ble/fd#is-open の時点で駄目の気がする。
        と思ったが違った。cache が壊れておかしな事が起こっているだけ? 上記のエ
        ラーを先に修正する必要がある。

        上のエラーを修正したら何も問題は発生しなくなった。cloexec もちゃんと動
        いている。

    * minix: /dev/tty が壊れていて gitlab から pull できない。そもそも鍵認証に
      失敗しているのは何故? 後で github に dev を瞬間的に push してそれから
      pull する事にする。

      取り敢えず動いている。procfs による fd の提供はないので、実装的には一番原
      始的な物になっている筈だが、使われている fd の範囲を見ると、子セッション
      に行っても変わらない様なので問題ないだろうという気がする。

      x fixed: と思ったが、32 というファイルが沢山できている。これは修正しなけ
        ればならない。取り敢えず他の環境で最初に再現するか見る。再現する。
        fd#is-open が怪しい。と思ったら普通に簡単なミスだった。修正した。

    * msys1? うーん。msys1 は msys1 で対策をする必要がある気がする。先に msys
      の諸々の問題を解決する事にする。

      特に msys1 特有の事情に関しては #D2163 で独立して議論・修正する事にした。

      x fixed: is-open の新しい実装を見て思ったが問い合わせる先の fd が fd1,
        fd2, _ble_util_fd_null と被ると問題になるのでは? fd1, fd2,
        _ble_util_fd_null に関しては別に判定する事にした。

      x fixed: ble/fd#is-open "$_ble_util_fd_zero" で /dev/zero を開いているか
        判定しているコードがある。然し、これだと /dev/zero が存在しないシステム
        で $_ble_util_fd_zero が空だった時に変な事が起こる。ちゃんと渡された引
        数が空でない事を確認する必要がある。というか数字でなければならない。

      x fixed: stderr が消滅している。これは自前で改めて redirect しても駄目。
        これは実は chatoyancy の上でも発生する問題の様だ→これは #D2164 で修正
        した。

      x ok: history の各項目の先頭に起動する度に __ble_time__ が付加されていく。
        shopt -u histappend の状態である。chatoyancy の上で同様の処理をしたが問
        題は発生していない。

      ? done: test も走らせるべきの気がする。

    古い version の bash も試す必要がある。

    →これは全て #D2164 で対処する事にした。

    新しく pull した時に bad fd のエラーが出るのはどうするか? これは古い commit
    を引いて来て一回再現させて修正する。どれか一つの環境で再現させれば十分に思
    われる。

    x fixed: ファイル名が交換されていた影響で bad fd が出る。これについてはそも
      そも変数名を変える必要がある様に思われる。或いは対策を入れる。修正した。

    x 一つ前の push とそれより前の version の間でも問題が起きていた筈。これも再
      現させる。再現したら同じ問題が最新版でもあるかどうか確認すれば良い。

    * wiki: 更新した。blerc は既に更新してある。

    ----

    2024-02-16 exec time の取得ができなくなっている。全部同じ値になっている。何
    故? fd の取り扱い変更が原因か?

    redirection の error が実は裏で発生していてそのエラーメッセージが time の出
    力に混入していた様だ。取り敢えず既存の怪しい session の影響のある
    exec_time_* については再構築できる物については埋めて他は全て 0 埋めする事に
    した。

    原因は何かと思ったら単に ble/fd#is-open が壊れていた。/proc ではなくて
    /porc を参照していたのだった。修正した。然し直らない。と思ったら判定が -f
    になっていた。然し pipe は -f ではない。-e で判定する。

2024-02-14

  * util(joblist): fix job detection in bash-5.3 [#D2157]

    bash-dev で job が走っているから終了できないという感じになる。

    うーん。joblist の中には終了したジョブが入っている。本来は終了したジョブは
    排除されるべきである。joblist の実装を確認すると二回連続で jobs を実行して
    消滅しなかった物が生きている job と判定している。

    うーん。${ jobs; } で実行すると notified にならないという事なのだろうか? →
    実際に昔の ble/util/assign の実装に切り替えたらちゃんとすぐに終了する様になっ
    た。つまり、これは ${ ...; } の新しい実装の特性という事になる。

    取り敢えず J_NOTIFIED は付加される様である。然し、何度でも出力される。
    J_NOTIFIED な jobs を消すのは何処で行われているか? うーん。
    cleanup_dead_jobs で行われているが、その冒頭に jobs_list_frozen という条件
    が書かれている。これが有効になっているという事か。実際に試してみた所有効に
    なっている。ble/util/assign の実装を切り替えると無効になる。然し、何故前に
    テストした時には気づかなかったのか。或いは何らかの request によって後で変更
    されたのか。

    うーん。subst.c:6978 の fubsub の関数の中から freeze_jobs_list という関数が
    呼び出されている。そしてこれは最初の実装から存在している。うーん。以前テス
    トした時は subshell を呼び出していなかったしていなかったから問題にならなかっ
    た? 問題のプロセスは conditional-sync による kill pid と、bgpid による起動
    だった。つまり、両方とも histdb が関係している。

    * うーん。最初のプロセスは __ble_suppress_joblist__ を宣言している。なのに
      何故残っている? 改めて確認してみたが __ble_supress_joblist__ は出力時に処
      理している。しかし、そもそも split の時点で除外してしまって良い気がする。

      →その様に書き換えたら二つあった dead jobs が両方とも表示されなくなった。
      conditional-sync の方でも __ble_supress_joblist__ を指定していたのかと思っ
      て改めて確認してみたがそんな事はない。不思議だ。と思ったら単純に
      joblist.split の書き換えミスだ。修正した。

      conditional-sync の中にも __ble_suppress_joblist__ を指定する事にした。と
      思ったが何処に指定するか微妙である。勝手に関数の使わない引数に指定したり
      していたが、これは勘違いの物になる。或いは ble/util/setexit 0
      __ble_suppress_joblist__ にする? 或いは常に true を返す関数でも作ってその
      引数に指定する事にすれば良いだろうか? と思ったがそういう風にするぐらいな
      らば、ble/util/joblist/__suppress__ 的な空の関数を用意して呼び出す事にす
      れば良い。現在 __ble_suppress_joblist__ を呼び出している箇所は二箇所しか
      無いので、大きな変更にはならない。方針を変更する事にする。

      書き換えた。conditional-sync もちゃんと除外される様になった。

    * https://github.com/akinomyoga/ble.sh/issues/100
      そう言えばこの Issue は今まで気づかなかったが、 __ble_suppress_joblist__
      によって work around できるのではないか。根本原因の解明には繋がらないが
      bind -x 内部での bash の job 管理は結構微妙な事が多いという事が判明したの
      で、普通に考えて問題のないコードでも起こりそうである。なので、明らかなバ
      グがあるという訳でもないと考えられる。従って workaround で十分という事に
      する。

      と思って改めて関連するコードを確認したがそもそも現在のコードは構造が完全
      に異なる気がする。少なくとも関数へ分離されている。報告されたのは commit
      0506df2 である。その当時のコードについて確認してみる事にする。→確認して
      みたが別に subshell を明示的に使っている訳では無い。パイプになっていた。
      つまり、パイプであってもジョブが残るという事? そもそも awk 自体の呼び出し
      が jobs に残る可能性だってある。という事を考えて行くと再現がない。

      結局そもそもの原因が分からず闇雲に __suppress__ を記述して行っても、fork
      を実行している所はいたる所にあるし、__suppress__ marker を付加できない物
      も当然あるだろう。色々考えるとこれが発生する条件を特定しない限りは
      GitHub#100 の解決を宣言する事はできない気がする。

      そもそもよく見ると GitHub#100 ではおまけで /usr/bin/stty も jobs に含まれ
      ている。これは当に __suppress__ を付加できないかつそこら中で呼び出される
      可能性のある物の例になっている。

    * ble/util/joblist/__suppress__ を増やしたとは言え、対応は不完全ではない様
      に思われる。また、foreground dead jobs がずっと保持されてずっと除外されず
      に残るのも良くない様に思われる。bash >= 5.2 以上では明示的に jobs を普通
      に呼び出して joblist を clear する事にする (或いはこの時だけ旧来の
      ble/util/assign を使うという手も考えられなくはないが、やはり一時ファイル
      の作成は >/dev/null よりもコストが高い気がするので jobs を余分に呼び出す
      事にする)。

      追加した。また、funsub による振る舞いの違いは他にもあった気がするので何処
      かにまとめておく。と思ったが今探しても議論が見つからない。或いはまた頭の
      中で思っていただけで何処にも書いていないという事か? うーん。$() と ${()}
      の違いだった様な気もする。そしてそれは明らかに set -m である。

      然しもっと違った気もする。_ble_bash と 50300 で検索してみたが見つからない。
      というか funsub 関係なく単に subshell の話だったかもしれない。或いは CI
      の失敗に関係していたかもしれない。うーん。CIが失敗する話だったのではない
      か。そしてそれは interactive session でのテストとコマンド実行によるテスト
      での振る舞いの違いだったのでは。うーん。#D2131 の様な気もするが、分からな
      い。#D2123 にも履歴展開のついて書かれているが対話シェルと非対話シェルでの
      違いは単に set -H の有無である様にも見える。取り敢えず思い出せないので良
      い事にする。

  * progcomp: 動的に追加された plusdirs の実装が不完全 [#D2156]

    現在の実装だと COMPREPLY=() で compopt -o plusdirs だけ指定した時に何も生成
    されないのでは? bash でどう振る舞うのか確認する。

    先ず compgen にそもそも plusdirs が指定されていた時にはわざわざ plusdirs を
    実行しなくても既に候補が生成されている筈。では completion function の中で
    plusdirs を指定した場合にはどうなるか? どうやらその場合にも bash は最終的に
    ディレクトリ名を生成する様である。

    重複をちゃんと除去する事などを考えると追加生成するべきの気がする。これまで
    は重複除去やソートなどは行っていなくて、その事がコメントに書かれていた。

  * progcomp: ble/no-default, default, dirnames, bashdefault 再考 [#D2155]

    ble/no-default の取り扱いが微妙である。そもそも ble/no-default を実装した時
    に、何故 bashdefault を最初から comp_opts に入れておくという実装にしなかっ
    たのか。導入したのは #D1789 である。この時の議論をみると comp_opts に初めか
    ら bashdefault を入れておくというアイディアは考慮すらしていない。

    然し、確かに bashdefault を既定で入れる様にしてしまうと問題になるのかもしれ
    ない。例えば complete +o bashdefault foo としても complete -p には反映され
    ないので、ble.sh によって bashdefault が追加されてしまう。という事を考える
    と、やはり default, bashdefault と ble.sh の default は独立に扱うべきなのか
    もしれない。

    或いはそもそも ble/no-default という反転オプションを入れたのも問題だったか
    もしれない。本来は ble/default であるべきだったのでは? 或いは
    ble/no-default は他の source による候補生成も抑制する物だったか? と思ったが
    実装を見る限りはその様な処理はない。

    うーん。空だった時のオプションが bash には dirnames, default, bashdefault
    と三種類も存在している。これらの包摂関係がどうなっているのか分からない。色々
    の組み合わせで振る舞いを見る必要がある気がする。bashdefault は compgen に対
    しては何も変化がない。どういう効果があるのかは不明である。context-dependent
    な処理なのかもしれない。例えば変数名の補完など。

    実際にコマンドの補完設定に追加して試してみた所、default はファイル名を生成
    する物で、bashdefault は $B 等に対して変数名を補完する物で overlap はない様
    だ。両方設定した時が最も多くの場合に補完ができる様になる。dirnames もちゃん
    と default とは独立に存在している意味がある様だ。まとめると以下の様な順に補
    完が実行される様に思われる。

    1 その他の指定による候補生成
    2 (1. で何も生成されない時) dirnames による候補生成
    3 (2. までに何も生成されない時) default による候補生成
    4 (3. までに何も生成されない時) bashdefault による候補生成

    ? resolved: "候補が見付からない場合 (または曖昧補完で COMPV に / が含まれる
      場合)" というコードコメントは一体どういう事なのか。と思って履歴を探ると、
      713e95d61 で / の件が追加されている。項目 #D0841 は当に曖昧補完の時の取り
      扱いについての修正である。現在の処理が一体どうなっているのかは不明である。
      然しながら今もちゃんと当時問題にしていた状況で候補は生成できている様であ
      る。

      当時の修正の本質は filtering を source の呼び出し元ではなくて、source の
      中で実行する事によって "何も生成されない時" という条件を正しく取り扱うと
      いう事だった。なので、"(または曖昧補完で COMPV に / が含まれる場合)" とい
      うのはより正確には "(候補が見付からないという状況には、候補が生成されたが
      曖昧補完によるフィルタリングで全て棄却された場合も含む)" という事であろう。

      現在の実装では曖昧補完によるフィルタリングは ble/complete/cand/yield の段
      階で処理されているので、そもそも二段階処理になっていないので関係ない。こ
      のコメントは消して良い。

    * done: ble/no-default は ble/default に反転した。

    * reject: 一部の ble/syntax-raw の条件分岐が無意味である。分岐した後の処理
      が全く一緒である。何故? 歴史的に違ったのを同じ処理になる様に変更した? と
      思ったがよく見たら違った。COMPS を使ってフィルタするか COMPV を使ってフィ
      ルタするかという事。

  * progcomp: compopt のより詳細な対応 (reported by bkerin) [#D2154]
    https://lists.gnu.org/archive/html/help-bash/2024-02/msg00056.html

    取り敢えず実装した。但し、不完全な所は未だある。

    * 例えば現在の実装では +o のオプションを表示していない。これに対応する為に
      は現在の bash の version に応じて含んでいない全ての compopt を覚えておく
      必要がある。もしくは、何らかの手法で取得しておく必要がある。

    * また、拡張オプション ble/* を結果に含めるべきかどうかという問題もある。現
      在は含めている。その方が自然な実装である。しかし、拡張オプションは動的に
      しか追加できない。つまり、既存のコマンドに対する設定は bash が記録してい
      るのでこれらの拡張オプションを含めることはできない。そういう意味で
      compopt の出力結果を再利用しようとするスクリプトがあると失敗する。

    * ok: 無効なオプションや対応していないオプションを指定してもチェックなしに
      成功する。もし、既存の補完スクリプトが「xxxx のオプションに対応していたら
      それを使い、対応していなかったら fallback する」という実装になっていた場
      合その実装は動かない可能性がある。

      最新の bash に存在しているオプションについては、ble.sh の側で対応していな
      い場合には失敗するべきだろうか? しかし物によっては対応していると言うべき
      かどうか微妙な物も存在する → 確認してみた所 bash-5.2 の compopt について
      は default, bashdefault 以外は曲がりなりにも全て対応している。

      default については補完候補が空の時に readline のファイル名補完を実行する
      という物で、bashdefault については空の時に bash の補完を実行するという物
      である。後者の方が上位互換では? 然し、ble.sh 的には何も指定しなくても元よ
      りそういう振る舞いである。うーん。

      fullquote については元からそういう振る舞いなので指定されたとしても特に何
      もしなくて良い。

      そういう意味で存在している名前に関しては全て対応しているのでエラーにはな
      らない。また、そもそも bash が対応していないオプション名に関しては、正し
      い設定から指定されるとは想定しにくいので常に成功しても問題はない気がする。

    x ok: 現在の実装だと一個ずつしか削除されないのでは?
      →と思ったがよく見てみたらそもそも追加する時点で重複がない様になっている?
        →と思ったが、内部使用のオプションについては気にしていない気がする。
          →と思ったが、内部仕様のオプションを追加しているのは既存実装に対する
            WA の場合だけで、これはユーザー関数よりも前の呼び出しなので、
            comp_opts には重複する設定がないという事は保証されているのでOK。

    x fixed: 空の候補に関しては流石に除外しておかないと、ble/opts#remove による
      実装だと +o '' で前後の : が消えてしまう。と思ったが、そもそも
      ble/opts#remove を使わなくても良い事がわかったので気にしなくて良い? とは
      言いつつ空を受け入れるのも変なのでチェックした方が自然だ。

    x fixed: 寧ろ ":" がオプション名に含まれている時に問題である。重複チェック
      などもすり抜けてしまう。

2024-02-13

  * util: bash-5.2 EXIT で stty が効かなかったのは #D2142 で直ったかもしれない [#D2153]
    https://github.com/akinomyoga/ble.sh/issues/401#issuecomment-1937040118
    Refs. 2023-06-12, #D2142, #D2046

    だとすると終了時の stty sane は要求しなくても良いかもしれない。

    先ず前のバージョンで問題が再現する事を確認して、それから同じ設定で新しいバー
    ジョンで sttys sane しなくても問題が再現しない事を確認できれば良い。

    確認してみたが新しいバージョンでもやはり stty sane を実行しないと変な状態に
    なる。

    ? 或いは、EXIT trap の中で外側の端末を切断してしまえば問題は起こらないので
      は? 但し、これは EXIT が途中で中断した時に致命的の気もする。

      と思ったが unload は redirection を用いて外側にアクセスしているので切断し
      ても関数を抜けたらまた繋がってしまう。或いは close-all-tty を用いて絨毯爆
      撃するしかないのか?

      取り敢えず実験的にじゅうたん爆撃してみる事にする。

      if [[ $1 == EXIT ]]; then
        ble/fd#close-all-tty
      fi

      試しに close-all-tty を終了時に呼び出す様にしてみたがそれでも TTY 状態は
      壊れた儘であった。ls -la /proc/$$/fd >> ~/a.txt をして見たらちゃんと全て
      /dev/null になっていて tty に繋がっている tty は一つもなくなっていたので
      え、close-all-tty が呼び出されていなかったり失敗している訳では無い。

      これが意味する事は何だろうか? Bash は現在の端末を /dev/tty から開き直して
      tty の状態を調節している? 或いは、unload を呼び出すよりも前に stty を実行
      している? と思ったがもしそうだったら変な状態にそもそもならない筈である。
      或いは unload は stty に対して何もしていない可能性? 或いは、tty の状態は
      もっと下層で制御・更新されている? でもだとしたら 5.1 までちゃんと stty 状
      態が元に戻っていて 5.2 以降で動かなくなった理由が説明できない。

      →うーん。どうもそもそも stty が呼び出されていなかった疑惑が浮上してきた。
      unload の中で stty sane を実行したら問題は発生しなくなった。

    ? 何故 stty sane に相当する操作が行われていないのか? うーん。やはり呼び出し
      ている様な気がする。或いは、stty sane を実行する必要があるのだろうか?
      stty echo では駄目?

      そもそも問題のメッセージは ble/term/stty/TRAPEXIT の中から出力されている
      ので、この関数が呼び出されていないという事はないだろう。

      うーん。どうも stty sane をより上で実行しても効果がない様だ。つまり、何処
      かの関数が ble/bin/stty を呼び出して変な設定に直している?

      どうやら blehook/invoke unload を実行した後で stty sane しないと効果がな
      い。つまり、blehook/unvoke unload が何か変な物を呼び出しているという事。
      どうも blehook unload='ble/history:bash/unload.hook' の後で問題が発生する。

      うーん。stty -a の出力を見ると実際に unload.hook の呼び出し前後で設定が変
      わっている。やっている事は履歴項目の登録だけの筈なのに。行まで特定できた
      がそれ以降が謎だ。

      * builtin history | head の組み合わせだけで起こる。
      * echo line | head では起こらないし、
      * builtin history | cat でも起こらない。
      * echo ' 1 iptables' | head -n 1 でも起こらない。謎に満ちている。
      * head の代わりに sed '1{p;q;}' や ble/bin/sed -n 'n{p;q;}' でも発生する。
      * builtin history を subshell の中で実行しても問題は発生する。
      * builtin history | cat | head -1 でも発生する。
      * 一旦ファイルに書き出してから読み取った場合には発生しない。

      もしかして history が SIGPIPE を受け取ると発生するという事? うーん。これだ。

      * builtin history | { head -1; cat >/dev/null; } だと問題ない。
      * builtin history | ble/bin/sed -n 1p でも問題ない。

      次の疑問はこの振る舞いを ble.sh の外で再現する事が可能かという事。

      $ bash --norc
      $ trap trapexit EXIT
      $ trapexit() { builtin history | head -1; }
      $ bind -x '"\C-t": exit'

      うーん。これでは再現しない。

      $ bash --norc
      $ trap trapexit EXIT
      $ trapexit() { builtin history | head -1; }
      $ bind -x '"\C-t": exit'
      $ bind -x '"\C-u": stty -echo'
      $ [C-u][C-t]

      これも再現しない。

      $ bash --norc
      $ trap trapexit EXIT
      $ trapexit() { builtin history | head -1; }
      $ bind -x '"\C-t": myexit'
      $ myexit() { exit; }

      これも再現しない。謎だ。history に対して複雑な事をしている必要があるのか?

      * (ble/fd#close-all-tty; builtin history) | head -1 でも再現する。

      実は C-d で終了した時にのみ問題が発生する。これが意味する所は stty -echo
      の時に trap exit が発生してそこから終了した時に問題が発生する事という気が
      する。

    うーん。分からないので bash の中で振る舞いを見る必要がある? 取り敢えず本当
    に builtin history が問題なのかという疑問もある。subshell が SIGPIPE を起こ
    したら常にこれが発生するという可能性もなくはない。然し、それをちゃんと確か
    める方法は謎。

    * OK: { cat ~/a.txt; echo 1; } | head -1 でも再現した。

    つまり builtin history の問題ではない。

    * { cat ~/a.txt; echo 1; } | head -1 でも再現した。
    * { echo 1; sleep 1; echo 1; } | head -1 でも再現する。
    * { echo 1; sleep 1; } | head -1 では発生しない。
    * { sleep 0.5; echo 1; } | true でも再現する。

    うーん。SIGPIPE を subshell が受け取ると stty の状態を変えようとするという
    事?

    * ({ sleep 0.5; echo 1; } | true) の場合には問題は発生しない。

    だとすると実際に何か変な事をしているのは PIPESTATUS を初期化している親シェ
    ルの可能性が出てきた。特に、中で close-all-tty を実行しても問題が再現した事
    から、パイプを作っている親のシェルが怪しい気がする。

    $ grc '\bioctl\b.*TIOCSET' をするとそんなにたくさんの所で呼び出されている訳
    では無い。なので、これら全てに DPF で引っ掛ければ引っかかるかもしれない。と
    思ったが全く引っかからない。関係ない場所ですら引っかからない。何故? 捕まえ
    た。set_tty_state を通過している。どうもコンパイラオプションで違ったりする?
    或いは別の方法で端末の設定を変えているという事か。問題が起こらない時には
    set_tty_state を通過しない事も確かめた。つまり、これが原因である。

    jobs.c:3122 で呼び出している。うーん。コメントに色々書かれている。とにかく
    interactive top-level で pipeline が失敗したら set_tty_state を呼び出すとい
    う仕様らしい。そしてこのコードは少なくとも 27 年前から存在している。何故こ
    れまで問題が発生しなかったのかは謎である。

    これは結果として不可解な動作に見えたが、仕様として考えると理解できなくもな
    い。なので bash の仕様として受け入れるしかない。回避方法としては最後まで読
    み切るか、或いは subshell で評価するかである。

    * OK 動いている。
    * Cygwin でも問題ないか確認する必要がある気がする。

  * 2024-02-11 histdb: varleak している。ret が時刻を含んでいる [#D2152]

    norc では再現しない。histdb が怪しい。後でチェックする → 修正した。その他
    の leak は今の所は起こっていない様だ。長時間使っている訳では無いので分から
    ないが、todo 項目が増えて大変なのでこの時点で終結という事にする。また時間が
    ある時、または実際に別の leak が判明した時に再度確認する事にする。

  * edit: shift selection で delete-selection が起こらない (reported by cmndrsp0ck) [#D2151]
    https://github.com/akinomyoga/ble.sh/issues/409
    Ref #D2139

    delete や文字挿入が効かなくなってしまったという報告。確かに考えてみればそう
    だ。選択解除は処理を実行してからでなければならない筈だ。どの様に実装するべ
    きか。安直には dispatch の後で selection が残っていたら解除するという形にな
    る。然し、それで大丈夫だろうか。

    * 例えば、もし他の機能によって selection が設定された場合に無視して解除して
      良いのか。例えば _ble_edit_mark_active=S の時にだけ解除するというのでこの
      パターンは回避できる。

    * 或いは、再び shift selection を開始した場合にはどうなるのか? これについて
      は keymap を確認すれば良い気がする。keymap が selection になっていたら保
      持する。それ以外ならば解除する。selection から更に他のモードに入る事はな
      いと仮定して良い。

      というかそういう事であればそもそも _ble_edit_mark_active の値は気にせずに
      現在の keymap の値だけを見て解除すれば良いのでは? と思ったがそれだと他の
      仕組みで選択を開始した時にも解除されてしまってそれは問題だ。

    つまりどの様に判定すれば良いかというと、_ble_edit_mark_active == S かつ
    _ble_decode_keymap != selection の時に解除する様にすれば良い。

    ? ok: これに関係する考察を #D2139 でしているか? 何か落とし穴はないか? →改
      めて見てみたが他の実装方法についての考察はあるが現在の実装についての詳細
      な議論は残っていない。多分何も考えていなかった。気にしなくて良い気がする。

  * complete: docker completion bash が遅いかもしれない [#D2150]

    docker completion は __docker_q という関数を持っているみたいなので、この関
    数に advice を追加すれば良い気がする。既に _dnf_command_helper に対して似た
    様な修正がされていたので、その修正を関数に分離して docker の場合にはそれを
    適用する事にした。

    ? 全ての補完で dnf の function#advice を実行するのは非効率である。先に
      comp_func で条件判定するべきではないか?

      元々 dnf の function#advice を追加した時の議論・文脈もチェックする必要が
      ある。これは a4a779e4 (#D1807, GitHub#193) にて ssh に対する同様の修正と
      一緒に追加された物である。dnf は元の報告に含まれてはいなかったが序でに修
      正した物だ。

      手元にある bash-completion の設定を参照して追加した物と思われる。_dnf は
      bash-completion 本体で提供している物ではないので _comp_cmd_dnf の様な名前
      変更の対象ではない。なので、実際に _dnf だけチェックすれば問題ない?

    取り敢えずその様に実装する。

2024-02-09

  * test: add tests for bash array bugs [#D2149]

    何かの修正の時に関係あるかもしれないと思ってテストを追加したが結局関係なかっ
    た。後でもっと拡張して追加しようと思っていたが忙しいので、keymap.vi に対す
    る修正があった今もうまとめて入れてしまう事にする。

  * decode: fix test failure by cached @ESC [#D2148]

    テストが失敗する様になった。何処にも昔の @ESC はない様に見えるのに昔の @ESC
    が現れる。と思ったらキャッシュが残っていた。init-cmap.sh を更新するのを忘れ
    ていた。また、keymap.vi のテストが失敗した時の行番号などの表示がヘルパー関
    数の物になっていたのを直した。

  * histdb: ok ok という謎のメッセージが時々出る [#D2147]

    と思っていたが、これはどうやら histdb のバックアップを生成する時に表示され
    ている様だ。ok ok という表示が出た直後に ~/.local/state/blesh の中を見たら
    history のバックアップファイルが作られたばかりだった。

    PRAGMA quick_check を実行した時に表示される。標準出力に出している様だ。標準
    出力を潰す事にする。

2024-02-08

  * keymap/vi: vi_imap C-RET が書き換わっている (reported by 10b14224cc) [#D2146]
    https://github.com/akinomyoga/ble.sh/issues/405

    返信した通り C-RET は最初は history-expand-line になっていたが、vi-mode の
    実装時に newline に変えて、暫くしてから一括で色々の keymap で共通して
    accept-line になる様に変えた。然し、後の並び替えで誤って newline に戻ってし
    まったのではないかと思われる。accept-line に修正した。他にも後で事故りそう
    な物がコメントになっていたが、それを消してコメントで conflict について記述
    する事にした。

  * rlfunc: vi_nmap shell-expand-line に対応する [#D2145]

    fzf の様に闇雲に設定する枠組みが合っても不思議ではない。但し、fzf に関して
    は一旦 emacs mode に移動してから shell-expand-line を実行するので関係ない。

    或いはその場で vi_imap に移行するべき?

    改めて vi_nmap-rlfunc.txt を見ていたら vi_nmap/@edit という物を使って
    expand 系統の処理を行っている。なので、shell-expand-line もこれを使ったら良
    い気がする → その様にした。

    x fixed: 然し実際に試してみると eolfix がされていない気がする。他の widget
      の実装を見た感じだとやはり必要である。呼び出す事にした。
      mark/end-edit-area に関しては _ble_edit_ind は参照していない様なのでどち
      らを先に呼び出しても関係ない。

  * edit: 新しい widgets in 5.3 の対応 [#D2144]

    * そう言えば chet が何か bindable function を呼び出す事ができる widget を追
      加するとか言っていた気がする、と思って改めて調べてみたが、単に emacs の
      M-x が実装されただけだった。M-x さえ残っていれば任意の widget を安全に呼
      び出せるという意味では有用ではある様な気がするが、然し一方で元々の議論で
      欲しかったスクリプトから widget を呼び出す機能の代替にはならない。

      というか、bind '"\M-x<widget-name>\r": <widget-name>' をしておけば良いだ
      けの気がするので新しく bindable function として実装する利点は余りないので
      はないかという気がする。

      追加の入力を受け付ける必要があるので interface を考えなければならない。
      history-nsearch-backward の実装を確認してみた所、これは read -ep を内部で
      呼び出していた。うーん。これだと bind のマクロの様な使い方をした時に動か
      ない。常に標準入力からの読み取りを行おうとするので。代わりに vi の
      async-command-mode の様にしなければならない。

      * done: emacs でも使える async-command-mode を作る必要がある。その為には
        keymapを定義しなければならない? と思ったが、実は read を流用すれば良い
        のでは?

        問題は hook を導入しなければならないという事?

      * done: rlfunc を参照して翻訳する必要がある

      * TODO: completion も対応したい。然しこれは別項目になる気がする。

    * fetch-history

      emacs, vi_imap には既定で用意した。nmap については元々 end-of-history 等
      も対応していなかった。一方で history-next についてはちゃんと設定されてい
      る。うーん。どういう事だろうか。history-next がちゃんと動くのであれば
      end-of-history も動くのではないのか?

      * reject: また既存 widget で ble/history/initialize を呼び出している物と
        呼び出していない物がある。確認すると ble/history/goto の関数内の一番最
        初で ble/history/initialize を呼び出しているので、呼び出す必要はない。
        恐らく昔はなかったけれども後で追加されたという事だろう。取り敢えず無駄
        に呼び出しているのは削除する事にした。

        と思ったが、_ble_history_INDEX と _ble_history_COUNT を参照する為に必要
        だったのだ。

      ? fixed: vi-fetch-history は vi-command/history-end で良いのか? 実装を見
        ると単に rl_fetch_history を呼び出している。修正した。

      * done: adjust-command-mode を呼び出さないと single command mode で imap
        に落ちないのではないか。失敗した時でもちゃんと呼び出される様に留意する。
        →これは .bell を vi-command/bell に置き換えれば良かった。他のパスは全
        て adjust-command-mode を呼び出している。

      * done: keymap:vi/history-goto という名前にしているがこれは
        vi-command/history-goto 等にするべきなのではないか?

2024-02-07

  * main: 残留バックグラウンドプロセスの問題 [#D2143]

    やはり sqlite3 プロセスが残留する。何が原因だろうか。何処かに何が起こってい
    るのかを記録するべきの気がする。先ず、bgproc#close が呼び出された上で残留し
    てしまっているのか、或いは pidfile による自動的な cleanup に失敗しているの
    か等を確認したい。

    * 2024-02-03 発生した。ログを確認してみる。

      1706848491.611146/2746674 ble/util/bgproc#open 2746792
      1706849965.126224/2749048 runtime-dir detected .pid for pid='-2746792'

      open したきりそれ以降の処理が為されていない。一方で他のプロセスが検知して
      いる。つまり、.pid ファイルはちゃんと作られていたという事。一方で検知した
      のに正しく終了ができていないのが問題の様に思われる。

      うーん。単に kill しているがそれでは駄目という事だろうか。試してみる事に
      する。と思ったが、負の引数だから駄目なのだった。kill -- "$pid" とすればちゃ
      んと残留しているプロセスは殺された。然し、現在の実装だと SIGINT で消えな
      いプロセスの時に駄目の気がする。何回か kill -0 で確認して死ななければ
      kill -9するべきなのではないか?

      取り敢えず修正したのでまた暫く様子見する。

    * 2024-02-04 未だ発生している。

      再び chatoyancy の接続が悪くなって何度も接続が切れて、そうしたらまた問題
      が発生している。但し、もしかするとこれは古い version の ble.sh によって
      pid ファイルが削除されて起こっている可能性もある? うーん。分からない。一
      旦全て閉じる事にする。開き直した。

      やはり発生する。昨日の修正をする前と全く同じである。.pid ファイルは検出で
      きているがその後プロセスを終了する事ができていない。或いは使っている
      conditional-sync が駄目なのだろうか?

      と思って改めて確認してみたらそもそも run_pid の形式チェックの時点で -PGID
      の形式が除外されていた。

      うーん。形式チェックをちゃんとする為には clean-up は後回しにしたい。そも
      そも終了時に実行しているのであれば初期化時に実行する必要はないのでは? そ
      もそも初期化時間を短縮したいのにここで始末をするというのも変な事である。
      というか idle.push してしまえば良い気がする。bash-3 では動かないが、何れ
      にしても終了時には処理が走るので気にしなくて良い気がする。

    * 2024-02-05 また残留する sqlite3 があるのを確認したが新しい bash session
      を開始したら削除された。

      ? 残留していたのは先程接続が切断した時にできた物だろうか。しかしだとする
        と、何故再ログインした時に削除されなかったのだろうか。と思ったが、再ロ
        グインした時には未だ接続が切れた事が確定していなくて端末及びシェルが残
        存していたのだろう。暫くしてから端末が消えてシェルが消えたのだろう。

      然し、削除した時に以下のエラーメッセージが出た。

        kill: (-3154745) - そのようなプロセスはありません

      残留プロセスは以下の物だったのでプロセス番号は正しい。これは恐らく削除確
      認の為に実行している kill が出力している物だろう。

        murase 3154745 0.0 0.0 16036 5592 ? S 13:33 0:00 /usr/bin/sqlite3 ...

      何れにしてもエラーメッセージが出るという事はちゃんと削除の為のコードが動
      いているという事なので良い。修正した。

    もうこれで良いかなという気がしないでもないが、やはり一回もちゃんと動いた事
    がない状態ではまた変な問題が発生しているかもしれないので駄目な気がする。も
    う少し待つ事にする。

    * 2024-02-07 ble/base/clean-up-runtime-directory の中で ble/util/msleep を
      使う様に実装したがこれは大丈夫なのか。

      この関数の呼び出しの直前で ble/fd#finalize を呼び出している。すると
      clean-up-runtime-directory の中で呼び出している ble/util/msleep が動かな
      い事になる。更に、conditional-sync を subshell で呼び出しているが、これも
      ble/util/msleep を使用する。

      msleep 用の fd は finalize しても消さない様にしようと思って ble/fd#alloc
      に preserve を追加したが、よく考えたら単純に clean-up-runtime-directory
      の後に ble/fd#finalize を実行すれば良い。bg で動いている conditional-sync
      の事を気にしていたが、よく考えたら subshell で動いているので親シェルで
      ble/fd#alloc を実行しても特に影響はない。

    大分振る舞いは良好である。そもそも常駐している sqlite3 の数も最小限になって
    いる。但し、これは単に screen の中で開いているウィンドウの数が少ないからか
    もしれない。それでも以前は幾つか tty を失った sqlite3 が残っていたような気
    がする。これはそろそろこれで良い事にする。

  * edit: コマンド実行終了後にコマンドが変えたカーソルスタイルが戻っていない (reported by ragnarov) [#D2142]
    https://github.com/akinomyoga/ble.sh/issues/401#issuecomment-1925705940

    bash で子 ble.sh セッションから抜けた後に戻らない。
    どうも一番最初のコマンド実行だけで発生する様だ。

    うーん。これに関しては確認してみた所、_ble_term_cursor_current=default とい
    う値が設定されている事によって処理がスキップされていて、またコメントが書か
    れている (#D1873)。

    * 先ず ble.sh が一度もカーソルを変更していない場合には外部コマンドがカーソ
      ルを元の形に戻すという事が仮定になっている様だ (実際にそれが可能かはさて
      おき)。

      つまり ble.sh が終了する時に (一旦 ble.sh 自身によってカーソル形状を変更
      したのにも関わらず) カーソル形状を戻さないのが問題とも言える。然し、実装
      を見ると term/leave でちゃんと bleopt term_cursor_external が 0 になって
      いて、これは既定のカーソル形状という事の筈である。何故元に戻さずに終了し
      ているのだろう?

      うーん。振る舞いがよく分からない。分からない事が二種類ある。

      * ok: 先ず、_ble_term_cursor_current が知らない所で箇所で書き換わっている?
        0 に一旦変更している筈なのにその後でまた 2 に戻ったりしている→これは動
        作確認の為に出力した内容がプロンプトなどによって上書きされて消えている
        からだったのだろうという気がする。別の端末に出力する様にしたら取り敢え
        ずは変な結果はなくなった。

      * 更に最終的に 0 に変更している筈なのに何故か exit した後のカーソルの形が
        block に戻ってしまっている。これは別の端末に出力してちゃんとログが残る
        ようにしても変わらなかった。ble/util/buffer に物が入ったまま終了してし
        まって最終的に端末に届いていないという事だろうか? 然し
        ble/util/buffer.flush は最終的に実行している筈である。

        取り敢えず flush をその場で実行して振る舞いが変化するか確認する。→
        flush したら問題が発生しなくなった。つまり、ble/util/buffer の問題であ
        る。呼び出し元を確認する。

          ble/term/cursor-state/.update
          ble/term/leave-for-widget
          ble/term/leave
          ble/base/unload
          ble/builtin/trap/.handler
          ble/widget/exit
          ble/widget/vi-command:q
          ...

        うーん。ble/base/unload でちゃんと flush している。但し、2 に対して出力
        している。これは実は exit が潰しているのではないか?

        つまり、前の bash の version では EXIT trap はリダイレクトの中で実行さ
        れていたが、新しい Bash では終了処理が発生した文脈で EXIT が実行される
        為に、stderr が潰された儘になっていたという事。ble/base/unload で tui
        std streams に繋ぎ変える事にした。ble/base/unload もしくは EXIT の実行
        環境はそもそも制御できない物だから。

    * ok: コマンド実行後のカーソル形状が変わっているかもしれないという事に関し
      て。ble.sh が一度もカーソル形状を変更していない時は、もし仮にコマンドによっ
      てカーソルが変更されていたとしてもカーソルを元に戻さない様になっている。
      然し、これは良いのか? うーん。でも ble.sh の枠組み上でカーソル形状を変え
      た事がないというのであれば、ble.sh は飽くまでカーソル形状を知らない line
      editor として透過的に振る舞うべきと考えれば今の振る舞いで自然の気もする。

    ? invalid: 何故二行目以降のコマンドではちゃんと元に戻すのだろうか。謎である。
      と思ったが改めて試してみたら別に二行目のコマンドでも同様に問題が生じる。
      単に一回でもカーソル形状を変えた事があるかどうかという事の気がする。

    2024-02-07 keymap.vi のテストで選択された状態が残留する様になっている。最初
    は selection mode の導入に伴うバグかと思ったらそうではない様だ。そもそもこ
    れまでもこの現象は内部的には発生していたが、最後の ble/util/buffer.flush が
    >/dev/null に繋がっていた為に表面上現れていなかったという事の気がする。今回
    ちゃんと最後の ble/util/buffer.flush が端末に繋がる様に変更したことで、今ま
    で隠れていた物が現れる様になった。

    そして何が表示されていたのかというと検索インターフェイスの検索一致範囲の表
    示だった様だ。これは確かに即時描画されるから _ble_util_buffer に何かが出力
    される。検索のテストの時には _ble_util_buffer を local に宣言する事で、外側
    に描画内容が残らないようにし、テスト中に生成された検索インターフェイスが後
    で表示されない様にする。

    これをすると仮にテスト中にカーソル形状や表示・非表示の変更が為された場合に、
    ble.sh 内部で把握している状態と実際の端末の状態に齟齬が生じて問題になるかも
    しれない。然し、検索インターフェイスで状態を変えるというのも考えにくいし、
    テストはそもそも対話セッションの中ではそんなに呼び出さない気がするので気に
    しなくて良い。

    2024-02-09 気づいていなかったが実はこれは
    https://github.com/akinomyoga/ble.sh/issues/401#issuecomment-1925705940 で
    報告されていた問題と同根であった。実際にこの修正の前後で報告されている問題
    も起こらなくなった事を確認した。5.2 での EXIT trap の context 変更に伴って
    発生した問題という感じに説明しておく事にする。

  * decode: keymap_*_load hooks に於ける既定の keymap [#D2141]

    Wiki では keymap_*_load の中で ble-bind を実行する様に説明を書いているが、
    実際の所 keymap のファイルが他の keymap の初期化時に呼び出される可能性もあ
    る。その時に他の keymap に設定してしまうのではないか?

    うーん。これは keymap_*_load hooks は特別に扱って既定の keymap 指定の上で
    blehook を呼び出す様にするべきの気がする。

    元々は keymap_*_load hooks は更に廃止して ble-import -C に移行する事を考え
    ていたが、ble-import -C については単にロード時に呼び出すだけの機能であって
    ble-bind の既定の keymap を指定する等の処理は別に挿入する必要がある。なので、
    結局 keymap_*_load hook を使うべきの気がする。

2024-02-06

  * main: bleopt connect_tty (fd/tty 管理再考) [#D2140]

    ? ok: 現在の fd 初期化の実装で暗黙に端末の fd は常に読み書き療養になってい
      ると想定していないか? そうだとすると、例えば読み取り専用だった物を書き込
      みにコピーするとエラーが生じて駄目な事になるのではないか?

      →確認してみると他の fd を流用しようとしているのは 2 を初期化する時に 1
      を参照しているだけで、読み込み用の fd と書き出し用の fd を混ぜている訳で
      はなかった。なのでそういう意味での問題はない。

    * 現在の実装だと bash -i &> a.txt 等で開始した時の振る舞いが微妙な気がする。
      プロンプトだけは a.txt に出力されてしまう? 本来はプロンプト等は全部端末の
      方に出力するべきである。うーん。2 に出力している所を全部
      _ble_util_fd_stderr に出力する様にすれば完結の気もするが…。

      また stdin についても切り替えが起こって欲しい気はする (但し、cat 等を実行
      した時に何が起こるのかは不明。止める事できないのでは?)。うーん。でも C-c
      が伝達される様にしておけば良い筈。なので stty の調整を行った後に繋ぎ変え
      を実行すれば良い。というかそもそも現在の実装で繋ぎ替えは何処で行っている
      のだろう。

      或いは繋ぎ替えは全く行っていない? 0,2 が本物の端末に繋がっていて、1 が初
      期化時の stdout に繋がっている? だとするとエラーメッセージは何処に出力さ
      れる?  →確かめてみたら普通に表示される。つまり繋ぎ替えは全然していなくて、
      2 に全部出力されているという事の気がする。

    実装した。動いている。例えば、

    $ echo hello world | bash -i &> a.txt

    として開始すれば hello world の内容を処理するコマンドを記述する事ができる。

    ? 然し、これは本当に期待する振る舞いなのかというと微妙な気がしてきた。コマン
      ドラインからこれを実行している場合には良いが、

      x 例えば nRF Connect の様に対話セッションの bash にコマンドを送信してその
        結果を取得したい、という場合には、勝手に stdin を TTY に変更すると意図
        しない動作という事になる。

      x 或いは、プロンプトを stderr から読み取りたいと思っている時に、stderr を
        /dev/tty に繋ぎ変えた場合もプロンプトを取得できずに終わる事になる。更に
        また別の可能性として、

      x Bash 自体が出力する stdout を読み出したいという事があるのかは分からない
        が、特別な設定を行ってその上で標準出力に何かを出させて (例えば初期化時
        に表示するメッセージなど?) それを読み取りたい場合には、やはり stdout も
        元の物に繋がっていて欲しい。

      といった事を考えると勝手に変な振る舞いをすると他が壊れてしまう。敢えてこ
      の様な動作になる様に指定した場合にだけこの様に振る舞うべきなのではないか。
      然し、どうやって指定するのかは謎である。環境変数経由で指定するしかない。
      bash を起動する時に ble.sh に指定する引数やオプションを間接的に指定する方
      法は他にあるだろうか。

      うーん。或いは寧ろコマンドの中から bash -i で起動した時にこの様に振る舞う
      べき? うーん。例えば #!/bin/bash -i という shebang のスクリプトの中で
      source ble.sh -O connect_tty=1 等とする。

      逆に今までの振る舞いは本当に大丈夫なのかというのも気になる。取り敢えず最
      初のコマンドラインは良いが、_ble_util_fd_stdin を指定している箇所は沢山あ
      る。現在の設計的には ble.sh が相互作用する相手は _ble_util_fd_stdin とい
      う事になっているので、実は現在の振る舞いは変な副作用を起こしても仕方がな
      い。うーん。

    やはり現在の実装は微妙な気がする。要請としては

    * stdxxx は常に TTY に繋がっている。これは fd の export 等の場面で想定して
      いる。

    * ble.sh は常に stdxxx とコミュニケーションする。これは様々な箇所のリダイレ
      クションで想定している。

    然し、例えば ble.sh に TTY でない物とコミュニケーションさせたい場合には上記
    の二つの想定は矛盾してしまう事になる。

    a だとしたら常に TTY に繋がっている fd と ble.sh がコミュニケーションを取る
      fd と、コマンド実行の時に使う fd を区別する必要がある。

    b 或いは、そもそもそういう状況は想定しないという手もある。つまり、ble.sh が
      TTY じゃない物とコミュニケーションする様な事態になるという時は呼び出し元
      が何らかの想定をしていて readline とコミュニケーションしたという状況と判
      断し、ble.sh は有効化しない。

    何れにしても現在の状態は中途半端なのでどちらかの振る舞いになる様にする。オ
    プションで切り替えられる様にして、どちらの振る舞いもできる様にする。オプショ
    ンはどの様に指定するのかは謎だが、例えば bleopt で export して置けば良い気
    がする。

    取り敢えず簡単に実装した。また fd の確保の部分を整理した。
    bleopt_connect_tty についてはオプション名をちゃんと考えて declare しておく。
    また、このオプション自体を export する。オプション名はまた悩ましい。

    x fixed: 現在の実装だと exec が効かないのでは? 何処かで再度
      _ble_util_fd_cmd_std* を上書きするべきなのではないか? だとするとやはり
      _ble_util_fd_cmd_std* のそれぞれに対してもちゃんと dup して独立した番号を
      与えるべきの気がする。

      →cmd_std* のそれぞれに対してちゃんと番号を割り当てる事にした

    --------

    2024-02-08 不正な fd ですという表示がされる様になった。確認してみると、(1)
    環境変数には fd が記録されているが既に消滅している (2) 既に消滅しているので
    別の目的で fd が使用される (3) 別の所に繋がった fd を継承する、という具合の
    事が発生している様である。

    この可能性を考えると実は fd を継承するのは不可能という事にならないか? 環境
    変数を通して指定された fd が別の fd に置き換わっているかもしれない。その事
    を確かめる術はない。なので、実際には継承はできないと考えるべきではないか。
    寧ろ /dev/tty も開けないという緊急事態の時に記録されている fd が tty だった
    ら使用を試みるという具合 (然し、そうだとしても読み書きのどちらの fd かとい
    うのは分からない)。

    - 子 ble.sh session に継承した (と思っている) file descriptor var の一覧も
      export し、初期化時に未だ開いているかどうかを確認し、もし消えていたら
      fdvar の内容をクリアする。もしくは unset する。

    - 子 ble.sh session で close するべき fd の一覧を作る。これは無駄に file
      descriptor が子 bash 達で増えていくのを防ぐ為。

      →これは最初は cloexec で個別に指定できる様にしようと考えてみたが、色々考
      えて見るに現在の preserve と異なる物にする必要性がない様に思われるので個
      別のリストにはしない事にした。

    ----

    2024-02-08 fdlist と close を個別に管理する必要はないのではないか? close の
    方に統一するべきではないか? → 統一した。

    現在の変数名は長い。また環境変数であるという事が名前から分かると良い気がす
    る。

    0 _ble_util_openat_fdlist
      元の名前
    a _ble_util_fd_inheritance_close, _ble_util_fd_inheritance_export
      格納されているデータの種類が分からないし、変数名が似ているのに中身が違う
      のはややこしい。
    b _ble_env_fdlist_cloexit, _ble_env_fdvars_export
      元々名前空間に何となく沿っていたのから離れてしまっている。何処に属してい
      るかの情報がないので不安になる。
    c _ble_util_fd_fdlist_cloexit, _ble_util_fd_fdvars_export
      fd が重複している様な気がする。
    d _ble_util_fd_env_fdlist_cloexit, _ble_util_fd_env_fdvars_export
      長い気がする
    e _ble_util_fdalloc_fdlist_cloexit, _ble_util_fdalloc_fdvars_export
      fdalloc が fd#alloc を意味しているというのは微妙
    f _ble_util_fd_env_fdlist_cloexit, _ble_util_fd_env_fdvars_export
      離れていたとしても fd が重複している感じは変わらない。
    g _ble_util_fd_list_cloexit, _ble_util_fd_vars_export
      これも中身が分かりにくい。
    h _ble_util_fdlist_cloexit, _ble_util_fdvars_export
      これが良い気がする。

  * edit: CUA copy/cut/paste keybindings 及び selection mode [#D2139]
    https://en.wikipedia.org/wiki/IBM_Common_User_Access

    どうも CUA copy/cut/paste は C-insert S-delete S-insert らしい。何れも現在
    の ble.sh では使っていないので普通に含めても良い気がする。

    然し一方で C-c C-x C-v という組み合わせもあって、これを CUA と勘違いしてい
    る人もいる様だ。というか Emacs の cua mode なる物は C-c C-x C-v を CUA だと
    思っている様だ。

    https://superuser.com/questions/1293908/
    https://ayatakesi.github.io/emacs/26.1/html/CUA-Bindings.html

    これについては既存の機能と conflict するので例えば contrib/config の中で提
    供する事も可能である。但し名前をどうするのかは謎。或いは中途半端に
    contrib/config を作るのではなく新しい独立した keymap としてしまっても良い様
    な気がする。nano editor mode とかいう名前でも良い。

    * superuser.com のコメントで選択がある時にだけ C-c/C-x を有効にするという提
      案がされている。

      うーん。これでもやはり Emacs binding と矛盾する気がするが、その選択が
      shift 移動によって行われた物である時に限って C-c / C-x で copy/cut をする
      という様に変更しても良い気がする。同様に、 C-c/C-x で copy/cut した物が
      kill ring にいる時に限って C-v を paste として扱うという具合にして良い気
      がする。うーん。これは実装するべき。

      と、思ったが C-x は prefix key なので binding は単純ではない。或いは S-移
      動 を開始した時点で特別のモードに入るべきなのかもしれない。そちらの方が自
      然ではないか? どうせ @nomarked をつけるぐらいならば @marked を集めた
      keymap にすれば良い気がする。

      x うーん。問題になるのは一度 cua copy をしてしまうとその他の kill の仕方
        をしない限り C-v が quoted-insert に戻る事はないという事。

      x また逆にユーザーが想定しない形で kill が発生して C-x した内容が失われて
        しまうといった事態になる可能性もある。

      x そもそも C-y と別に対して機能として違いがある訳では無い。コピーが M-w
        である事と比べたらキーボードによらずに C-y は押しやすい方である。

      うーん。やはり実装しても混乱の元の様な気がする。そもそも他にも物凄く色々
      な振る舞いの違いがある。C-a で全選択、C-z/C-y で元に戻す・やり直す、など。
      C-x C-c C-v だけ中途半端に似せても余り嬉しくない様な気がする。C-s で保存
      とか。

      これは別項目として残しておく事にする。

    * 然し、shift で始めた選択を解除するべきなのに保持している箇所が沢山ありす
      ぎる気がする。改めて widget を全部確認するべきではないか。本当は、もっと
      別の枠組みを用意して、デフォルトで解除する様にして例外的に指定した widget
      だけで keep する様にするべきなのかもしれないが。

      例えば本体の keymap で @marked な物を使うと selection mode に入り、
      selection mode に存在している widget で移動を行った時にのみモードがキープ
      される。それ以外の操作については元の keymap に落ちてくると行った具合にす
      る。そちらの方が自然の気がするし、ユーザーが細かに振る舞いを制御する事が
      できる。

      この実装に切り替える場合、@nomarked は nop にする? 或いは selection
      keymap だったら pop をする様にする? うーん。nop に置き換えてしまって良い
      気がする。

      * reject: .stop-selection in forward-word, transpose-words,
        transpose-chars, zap-to-char, etc. これらは今までの実装でちゃんと shift
        selection 解除の事を考えていなかった。これの振る舞いを考える時に選択を
        解除するかどうかという問題がある。

        うーん。振る舞いの変化として、これまで選択の事を考えていなかった widget
        で移動や編集が起こった時に選択解除が行われる様になる。これは意図的な変
        更である。一方で失敗して移動や編集が行われなかった時にも選択解除が起こ
        るのかどうかというのは非自明である。取り敢えず現在の実装方法だと失敗し
        たと分かる時には既に解除が行われているので、常に解除するしかない。

        失敗した時に解除されるのは考えてみれば自然な気もするが、もし失敗した時
        には何も変化がない方が望ましいという場合にはどうするのか? と思ったが別
        にその場合はユーザーが個別に selection keymap に binding を追加すれば良
        いのでは?

        うーん。というかそもそも @nomarked な keybinding の時には移動に失敗する
        場合でも解除されていたのだから、解除されない振る舞いについて考える必要
        はない。

      ? reject: default の中で S- がついていたら自動的に上の keymap で処理して
        からまた戻ってくる様にする可能性? → これはやり過ぎである。S-insert 等
        の場合には S + insert に分解したら全く異なる意味になってしまうし、また、
        単に @marked を実行しただけで本当に戻ってくる事ができるのかも非自明であ
        る。

      取り敢えず実装した。

      * wiki を更新する必要がある。取り敢えず @marked に関係する既定の binding
        は更新した。selection keymap を追加する必要があるだろうか。また、
        C-insert S-delete S-insert 等について記述する。全部追加した。

      * @nomarked は deprecated か何かに移動する → 移動した。

    ----

    2024-02-09 selection mode で変な選択が時々されると思っていたが
    isearch/exit-with-region という widget があって、_ble_edit_mark_active=S を
    設定して抜ける様になっている。これをキャンセルする物がなくなってしまったの
    が問題か?

    exit-with-region は exit-default から呼び出されている。exit-default は
    __default__ で呼び出されている。分かった。確かに再現する。

2024-02-05

  * decode: Isolated ESC のコードの変更 [#D2138]

    今気づいた事に isolated ESC に用いている U+07FF は使われている。2018-06-05
    に出た Unicode 11.0 で割り当てられた様だ。一方で isolated ESC を使い始めた
    のは 2017-11-12 だったので一応使い始めた時には未だ Unicode では使われていな
    かったのである。これは変更する必要がある。

    U+05F? や U+07B? に結構長い領域があるがこういう所には再び新しい文字が割り当
    てられる可能性が高いので避けたい。特にこういう領域があると末端から順に割り
    当てられる傾向がある様に思われるので U+038F 辺りは特に危ない。そう考えると
    中途半端に残った U+07FB, U+07FC 辺りが狙い目の気がする。また、IsolatedESC
    の表現に依存して hardcode されている部分もある様だからできるだけ U+07FF に
    近い所、という意味でも U+07FB U+07FC 辺りは良い気がする。

    意外と変更箇所は少なかった。変更する必要がありそうな所はコメントがちゃんと
    書かれている様に思うので。コメントが書かれていないが具体的な表現に依存して
    いる所がないとは言えないが、雰囲気なさそうな気がする。取り敢えずこれで様子
    を見る事にする。

2024-02-04

  * decode: bind '"keyseq": ""' で keyseq が正しく解析されていない [#D2137]

    atuin の macro chain の実験中に ble.sh が変な挙動をする

    結構無理な事をしているから仕方がないとは言え何故この様な振る舞いをするのか
    については確認しておきたい。keylog を見ると C-x が重複して受信されて それか
    ら SS3 が重複した形になっている何故だろうか。

    .MACRO は ble-decode-char に対してデータを送っている様だ。ble-decode-char
    が受け取っているシーケンスを見る限りは何も問題ない気がする。但し、macro
    chain の為に中で新しい keyseq を解析しているのでその解析が途中で入っている。

    ? reject: 或いはその途中の解析が状態を破壊している可能性?

      ble-decode-key が受け取っているシーケンスも問題ない気がする、と思ったがよ
      く見ると 143 (\M-\C-o) を重複して受け取っている。これは内部で解析を行った
      直後である。そう言えば最近 ble-decode-key の解析を修正して新しい状態変数
      を導入したのだった。ちゃんとその状態変数は localize できているのか? blame
      で確認するとその変数は _ble_decode_char2_modseq である。bind の為の呼び出
      しは以下の経路で行われている。

        'ble-decode-char'
        'ble/decode/cmap/decode-chars'
        'ble/builtin/bind/.initialize-keys-and-value'
        'ble/builtin/bind/option:-'
        'ble/builtin/bind/.process'
        'ble/builtin/bind'
        'bind'

      然し _ble_decode_char2_modseq を localize しても問題は直らない。他にも途
      中状態が破壊されている箇所があるという事の気がする。decode-chars の呼び出
      し元で確認する必要がある気がする → 呼び出し元で declare で全変数を dump
      して前後比較してみたが _ と keys しか変わっていない。前者は元々変わる物で
      後者は今回目的の変更対象なので期待している通りである。他の状態は何も変更
      されていない。

      或いは全く bind を実行しなくても問題が発生するのだろうか? 試してみる →
      再現した。つまり ble/decode/cmap/decode-chars は関係ない。

    実は以下の設定だけで問題が再現した。不思議なのは何故最後から二番目だけ問題
    が発生しているのかという事。うーん。keyseq の一致に失敗しているという事だと
    思われるが?

      bind '"\e[A": "\C-x\xC0\x96\C-x\xC0\x8F\C-x\xC0\x8D"'
      bind '"\C-x\xC0\x96": ""'
      bind '"\C-x\xC0\x8F": ""'
      bind '"\C-x\xC0\x8D": ""'

    うーん。keyseq の一致を確認してみると、そもそも \C-x\xC0 の時点で
    keybinding が見つかっている。そして \C-x\xC0\x8F に対応する keybinding が存
    在しない事になっている。何故? つまり、bind を実行した時点での問題の気がする。

    改めて .initialize-keys-and-value の結果を確認する。

      keyseq='"\C-x\xC0\x96"' chars=('24' '192' '150') keys=('67108984' '192' '150')
      keyseq='"\C-x\xC0\x8F"' chars=('24' '192' '143') keys=('67108984' '192')
      keyseq='"\C-x\xC0\x8D"' chars=('24' '192' '141') keys=('67108984' '192' '141')

    分かった。つまり、最後の C-o が処理されずに中途半端な状態になっているので、
    keys の中に反映されていないという事。decode-chars では中途半端に pending に
    なっている物を flush する機能が必要なのではないか?

    うーん。読んだがよく分からない。ent を取得する部分で何の sequence にも属さ
    ない文字を無理やり入れたらいい感じに残留している物がなくなるまで吐き出され
    る様な気がする。丁度 __ignore__ というのがあるのでそれを入れて、その上で
    __ignore__ を削除すれば良いのでは? と思って試してみたら動く。しかも
    __ignore__ は結果に混入していない。

    ? ok: 然し __ignore__ が消えるのは今回は好ましい振る舞いだが何故だろう? 通
      常文字として挿入されたりしないのか? と思ったが元より __ignore__ は
      csistat の処理の途中で無視するべき (or 処理済み) のキーが発生した時にそれ
      にお着替えているのだから、今回の場合も M-__ignore__ みたいな物が生成され
      ない限りは __ignore__ も生成されないのである。

    ? fixed: だとすると、"\e" を正しく処理する事はできるのだろうか? meta
      modifier は未だ flush されずに残留する様な気がする。

        keyseq='"\e"' chars=('27') keys=()

      やっぱり駄目だ。ちゃんと処理できていない。修正が必要である。

      % コードを読む限りは未だ処理されていない modifier の key 列は
      % _ble_decode_char2_modseq に記録されている。特に失敗した時には全てこれを
      % 直接 ble-decode-key に流し込んでいるので、_ble_decode_char2_modseq の中
      % 身をそのまま keys に追加すれば問題ない気がする。
      %
      %   keyseq='"\e"' chars=('27') keys=('27')
      %
      % 動いている。と、思ったが C-[ に変換しなくて良いのだろうか? うーん。然し
      % 最終的に同じ key 列を出力している限りは特に問題はないのでは? 問題は
      % __ignore__ が発生しない状況で本当に同じキー列が生成されるのかという事。
      % うーん。そもそも 27 に関しては失敗する事がないから、中途半端な 27 があ
      % る keybinding はそもそも意味がない? 改めてコードを見る。

      うーん。別に _ble_decode_char2_modseq を直接 ble-decode-key に渡している
      訳では無い様だ。寧ろ _ble_decode_char2_modkcode の方を渡していて、その時
      にその key を生成するのに使った char の列として _ble_decode_char2_modseq
      が使われているのに過ぎない。

        keyseq='"\e"' chars=('27') keys=('67108955')

      改めてそれに倣って見た所、元よりちゃんと C-[ への変換は実施されていた様だ。
      OK。取り敢えずこれでOK \e\e の時の振る舞いもチェックしておく。

        keyseq='"\e\e"' chars=('27' '27') keys=('201326683')

      問題なさそうだ。

    ? ok: 閉じていない CSI シーケンスはちゃんと分解されてから処理される?

        keyseq='"\e[123"' chars=('27' '91' '49' '50' '51') keys=('134217819' '49' '50' '51')

  * contrib: execmark が colorglass に対応していない [#D2136]

    確認してみた所、これは元々 trace を使って一気に error と elapsed を処理して
    いたのをやはり二行に分ける事にして、然しその時に error の方を直接出力する様
    に変更したのが原因だった。

    error の方は ansi ではなくて直接端末用の sgr を構築しようと思ったが、SGR 解
    除等を使っている為面倒な事になる。trace はその辺りを全部やってくれていたの
    で良かった。やはり error の方も一旦 trace にかける事にした。

  * make: make scan で contrib の中のファイルについて検出できていない? [#D2135]

    確認してみたら実は list-command の段階で contrib を除外していたのだった。除
    外しているのを外してみるとたくさん見つかったが今までチェックしていなかった
    割には少なかった。適用した。

  * prompt: invalidate status line on the change of face prompt_status_line (motivated by Vosjedev) [#D2134]
    https://github.com/akinomyoga/ble.sh/issues/400#issuecomment-1924495499

    face prompt_status_line の設定がすぐに反映されない。
    _ble_face__prompt_status_line も _ble_prompt_status の hash に加えるべきの
    気がする → 加えたが反映されない。どうも trace_hash も更新を阻害している様
    だ。展開後の文字列が全く同じなので、更新しなくても良いと判断している。g0 の
    設定も trace 結果に影響を与えるのだから、g0 も trace_hash に加えるべきであ
    る。加えたら動く様になった。

    * wiki の bleopt prompt_status_line の項目で face prompt_status_line も言及
      するべきではないか。と思ったが既に連続して並んでいるし、次の項目
      prompt_status_align を言及せずに face だけ言及するのも変である。然しだか
      らと言ってすぐ隣にある物に言及するのも変だし、今度はその他の項目から
      bleopt prompt_status_line を言及しないのかという話になる。うーん。

      取り敢えず seel also で参照してくおく事にした。実は将来的には全て関連する
      物を cross link しても良いのかもしれない。或いは status line だけ一つの
      subsection に分けるという手もなくはないが、そうするとその他の prompt につ
      いても同じレベルの subsection を作らなければならなくなるが、大体一項目し
      かないので都合が悪い。

    2024-02-05 https://github.com/akinomyoga/ble.sh/issues/400#issuecomment-1925795331

    blerc.template になかったから無いと思ったと言っている。一応 face 一覧の箇所
    に載せてはいるが prompt_status_line の場所になければないと思うのは自然であ
    る。そもそも face を一箇所にまとめて置く必要もないので移動する事にする。

  * util: add "ble/util/{time,timeval,mktime}" [#D2133]

    histdb の色々な機能を実装する上で時刻の関数を整理したい。また、今まで使って
    いた %s は実は POSIX ではない。Issue 8 Draft では追加されているが未だ発行さ
    れていないし、古いシステムでやはり問題になる可能性がある。

    histdb の為に ble/util/mktime を実装するのであれば %s についての対策も
    ble/util/mktime を使って実装してしまえば良い。

    * ble/util/mktime

      gawk 及び mawk には mktime 関数が存在する。しかし bc, awk, m4 には POSIX
      では時刻に関連する機能は定義されていない様だ。また、GNU date にある date
      -d '...' も別に定義されている訳ではない。またこれらの関数を呼び出すのは
      spawn コストがかかる。もし対応できない環境があるのだとすれば、いっその事
      自前で算術式で実装してしまえば良いのではないか? 面倒な閏秒などがあっても
      テーブルにして無理やり実装すれば良い。

      少し試してみる。今まで勘違いしていたが unix time は別に UTC で挿入される
      閏秒などに対応している訳ではない。なので一日の長さは常に 86400 であり、気
      紛れに挿入される閏秒の事を考慮に入れる必要はない。

      ko1nksm さんが時刻の取り扱いに関する記事を書いていたような気がする。と思っ
      て検索してみたらそのものが出てきた。其処に載っているフェアフィールド公式
      なる物を見てみたがよく分からない。2月が対応できているのか不思議だ。

        [1] https://qiita.com/ko1nksm/items/e61728f863c1b2bc829d
        [2] https://qiita.com/ko1nksm/items/a4da288edba955725ada

      と思ってフェアフィールド公式で検索してみたら m は 3..14 に修正してから計
      算式を当てはめるのだそうだ。

        [3] https://manabitimes.jp/math/999

      読み飛ばしたかと思って改めて [2] を見るが、数式の所には m についての但し
      書きはない様だ。取り敢えず考えるのも面倒なのでこの数式をそのまま使う事に
      する。但し 1970 より前の日付に関してはちゃんと検証が必要だろう。

      後 timezone は一体どうすれば良いのか? これは printf '%(%F %T)T\n' 86400
      とか何とかやって求めた値を改めて解析するするしかない。或いは %z の結果を
      使えば良い。gawk/mawk 実装の mktime は timezone を考慮しているのか? と思っ
      て試してみたらちゃんと考慮している様である。うーん。%z の結果をどうやって
      取得するのかは謎である。date +%z で大丈夫なのだろうか? これは現在の時刻対
      して取得されるがサマータイム等を考えると目的の時刻を -d で指定しなければ
      ならないのではないか? 然し、面倒なので其処までは考えなくて良い事にする。
      そもそも正確な実装が欲しいわけではないのである。

    * ble/util/time

      printf %(%s)T 及び date +%s の実装で %s を使っているがこれは大丈夫なのか。

      * 先ず date +%s に関しては POSIX では定義されていない様だ。Issue 8 Draft
        では strftime を参照する様になっていて strftime(3) は Issue 8 Draft で
        %s が追加されている。ble/file#mtime 及び ble/util/clock でも同様の問題
        があるのでは? 余り気にしない事にする? 或いはやはり %s が定義されていな
        い環境の事を考える?

      * printf %(%s)T は Bash builtin だが Bash これをどのように実装しているの
        だろうか。%s は printf %()T で常に使えると思って良いのか? つまり、シス
        テムに依存するのか。bash によってサポートされているのか? bash の実装を
        見ると strftime(3) を呼び出している。そして strftime(3) は現行 POSIX で
        は %s には対応していない。Issue 8 Draft では定義されている。

      このような環境で一体どうすれば良いのかは謎である。time 関数がある言語を探
      す?  m4 など?  m4, awk, bc にはそういう機能は入っていない。と思ったが、%F
      %T %z にはどの環境も対応していると想定して良いので、そこから
      ble/util/mktime を使って変換すれば良いのである。問題は %s に対応している
      かどうかをどの様に見分けるのかという話である。

2024-02-01

  * highlight: tab_width を変更したら rendering と一致していない (reported by dgudim) [#D2132]
    https://github.com/akinomyoga/ble.sh/issues/396

    tab 文字が直接出力されているのではないか? もしくは tab_width を使うべきとこ
    ろで it を使っている箇所がある? textmap が怪しい。確認してみたが textmap の
    処理ではちゃんと空白になっていて文字幅も正しく計算されている。

    次に疑う箇所は着色レイヤーである。うーん。各レイヤーの配列は f11 で表示して
    いた筈。確認する。うーん。plain layer の時点で 8 空白になっている。うーん。
    どうやら、plain layer は普通に基本の空白幅で生成して、その後で textmap ichg
    を参照して置き換えるという作戦だったのではないかという気がする。しかし、tab
    に関しては現在の幅設定さえ分かっていれば事前に予測可能な物であるから、ichg
    には登録しなかったという事の気がする。どの様に対処するか。

    a ichg に登録する事にする? 然し余分な処理が増えるしタブ幅は文字の位置によっ
      て勝手に変化したりする物でもない。また、この箇所だけ直接 _ble_term_it を
      参照しているのも変な気がする。

    b 或いは plain layer の生成時点で bleopt tab_width の設定を反映して生成する。
      この時の問題は設定が動的に変化した場合に何が起こるのかという事である。
      plain layer を参照しているのは何処かというと、他の layer 及び rendering
      部分である。

      dirty-range さえ設定しておけば全部更新されて問題なくなるだろうか。文字列
      内容的に同じだからと処理がスキップされてしまう可能性は? うーん。plain
      layer の中身を参照して前回と内容が同じかどうかの判定する箇所はない筈であ
      る。すると問題が起こるとしても plain layer の更新に入る前に dirty-range
      が減少する可能性しかない。一方で dirty-range は例え reset-and-check-dirty
      を実行したとしても既に設定したものを改めて縮める様なことはないように設計
      している筈である。なので、dirty-range さえ設定すればOKの筈である。

    考えるに b の方法で問題なさそうな気がするのでこれでOK。

    _ble_term_it を使っている他の箇所も確認する→うーん。実は今回の修正箇所が唯
    一の直接 _ble_term_it を指定した箇所だった様だ。また一箇所だけ
    ${_ble_term_it:-8} としているがこれは何だろう。一応 init-term.sh の中で
    _ble_term_it が 0 だったら 8 を代入する様にしている。うーん。気になるので単
    に $_ble_term_it を使う方向に統一する事にする。

  * test: bash-3.2 での test-bash.sh が CI で失敗している [#D2131]

    macOS で失敗している。新しく追加したテストは bash version に依存する気がす
    る。どうやら履歴展開に失敗した時に元の文字列を返すのは bash-4.1 以降の話の
    様である。

    make scan すると新しいテスト項目に対しても何件か警告が出ているのでそれも修
    正する。これらは既に push してしまっているので元の commit には含められない。

2024-01-31

  * term: カーソルが設定していないのに点滅する (reported by n87) [#D2130]
    https://github.com/akinomyoga/ble.sh/issues/393

    報告を受けた Q4 の設定で問題が再現した。cursor-state/.update を潰しても問題
    は発生する。他のカーソル関係の出力を全て消しても問題は発生する。何故だろう?
    ble/util/buffer に介入して実際に出力したシーケンスをそのまま cat しても問題
    は再現するのか? → 再現した。どんどん短くしていくと \e[34l というシーケンス
    が残った。screen-256color の infocmp 的には cvvis である。

    うーん。大体何が起こっているのかは分かった。先ず初めに \e[34l は二種類の意
    味が歴史的にある様だという事。点滅と非表示。screen, screen-256color では
    cvvis として \e[34l が割り当てられている。そして tmux は恐らく 34l を点滅と
    して解釈する。

    一方で tput cvvis は更に微妙。xterm や alacritty では \e[?12;25h という物が
    割り当てられているが、これは 25 で表示すると共に 12 で点滅もつけている。一
    方で xterm と alacritty の中の tmux で \e[?25h を実行した時には別に点滅が
    on になる事はない。つまり、tmux は terminfo cvvis を信用していないという事。
    そもそも cvvis は何かと思って確認してみると make cursor very visible となっ
    ている。実は civis-cnorm-cvvis の組になっている様だ。

    screen
    - civis ^[[?25l
    - cvvis ^[[34l
    - cnorm ^[[34h^[[?25h

    xterm
    - civis ^[[?25l
    - cvvis ^[[?12;25h
    - cnorm ^[[?12l^[[?25h

    うーん。非対称になっている理由が分かって来た。つまり表示・非表示を制御した
    ければ civis とその逆を使うべきであって cvvis は無視するべきという事。

    _ble_term_cvvis は _ble_term_civis から決定する事にした。分からない時はカー
    ソルを隠す機能自体を諦める。うーん。実は _ble_term_cvvis という名前はやめる
    べきの気がする。これは将来的に混乱を起こす元である。うーん。reset_civis だ
    ろうか。或いは rm_civis, rmivis, rstivis, rmcivis, rstcivis 等 → rmcivis
    を使う事にした。

    * 提示されたテストケースの env -i に於いて HOME が空である為に変な所にディ
      レクトリを作ろうとしている。これは良くないので初期化時に HOME が空であれ
      ば取り敢えずの HOME を設定する事にする。

  * main: nRF Connect workaround (requested by liyafe1997) [#D2129]
    https://github.com/akinomyoga/ble.sh/issues/392

    取り敢えず問題が発生する所までは行けた。また、nRF Connect は複数行コマンド
    を送ってくる様だ。ここまでもOK。然し、accept_line_threshold を -1 に設定し
    ても問題は持続する。ble-bind -f C-m accept-line にしても解決しない。

    % bashrc を ble.sh だけにしても変わらない。ble-decode/.hook に仕掛けてみた
    % がこれも呼び出されていない。ble-attach が呼び出されているか確認した所、そ
    % もそも呼び出されていない。.blerc は呼び出されている。PROMPT_COMMAND も実
    % 行されている。

    と思ったがそもそも make していなかった。make したらちゃんと hook の類も呼び
    出されている事を確認した。うーん /dev/pts/3 に繋ぎ変えて振る舞いを見てみる
    事にする。うーん。何と 83 行も入力されている。どうした事か。うーん。

    hook で受け取った内容を確認すると、2000回も改行を書き込んでいる。どうした事
    か。これが CPU 100% になる原因である。と思ったが、これは VS Code を閉じた時
    に書き込まれる様である。つまり、待っている間に "bash -i" が 100% になるのと
    は異なる現象である。或いは、報告者が色々試す中で閉じたり開いたりしている内
    に前のセッションの bash -i がたまって悪さをしていたのではないか。

    調べてみるとどうやらコマンド実行の所までは進んでいる様だ。先ず hook を調べ
    たらちゃんと受信できている。_ble_edit_str に何も反映されていないと思ったが
    is-stdin-ready である為に受信を先に処理していたのであった。実際の処理は一番
    最後にちゃんと始まっている。終わりもちゃんと通過している事が分かったが
    _ble_edit_str は依然として空である。どうも gexec で処理されて空になっていて、
    これは正しい動作である。更に gexec のしかけた hook もちゃんと実行されている。
    然し、ble/builtin/exit が実行されていない様だ。exit の定義を見たが別に変わっ
    ていない。POSIXLY_CORRECT も設定されていない。

    或いは eval が上書きされている可能性? 取り敢えず内側の eval の中がそもそも
    実行されているのかを確認する。うーん。実行されていないっぽい。不思議だ。
    eval や time が上書きされているかというとそうでもない。eval の中が実行され
    ているかをチェックするコードだけにするとちゃんと動いている。

    うーん。どうもリダイレクトに失敗している? うーん。何と _ble_util_fd_stderr
    が空である。空である事を確認した。また初期化の時点でちゃんと初期化できてい
    ない事も確認した。

    しかしそもそもどうやら nRF Connect は bash を interactive に使ってコマンド
    実行させようとしている訳ではなくて、単に interactive shell の設定を読み取り
    たいだけである。という事ならば ble.sh をロードする必要もない訳である。mc の
    時とは状況が異なる。なので、nix の時と同様にロード時点で排除すれば良いので
    はないか→と思ったが nix の時はやはり interactive session に drop する可能
    性があったのでやはりロードしている。

    ---------------------------------------------------------------------------
    2024-02-05 nRF Connect で exec >/dev/tty/0 2>&1 した時に環境変数が全て出力
    されていたのは何だったのか?

    改めて確認しようとしたら再現できないが (何処かに declare か export を書いた
    まま忘れていたのかもしれない)、一方で改めて [[ -t 0 ]] などで確認してみたら
    0..2 の何れも tty ではない様だ。ls -la /proc/$$/fd で見てみると socket に繋
    がっている。一方で tty に接続できていた様な気がするがどういう事になっている
    のか、と思って tty を実行してみたら not a tty と表示される。それにも関わら
    ず true > /dev/tty が成功する。そもそも !((1)) >/dev/tty の判定は実際に端末
    が割り当てられているかどうかの判定に使える物なのだろうか?

    * 以下のページによるとやはり皆実際に開いてみれば分かると考えている様だ。

      https://stackoverflow.com/questions/69075612/

      然し其処に書かれている (exec < /dev/tty) 等を試してみても別に問題は発生し
      ない。うーん。エラーメッセージは出ているのだろうか (でも bash が成功のス
      テータスを出しているという事は、エラーメッセージを出しているのは bash な
      のだから、やはりエラーメッセージは出ていないのではないかという気がする)。
      stderr をリダイレクトするのを忘れていた。

    或いはやはりセッションに紐づいた tty が存在していて、但し 0..2 が塞がれてい
    るために tty コマンドが "not a tty" 等と出力していただけなのだろうか?

    改めて試してみたらやはり実際に /dev/tty で端末を開く事ができるみたいだ。そ
    して一度 /dev/tty を開けば [[ -t 0 ]] などは 成功する様になる。

    * ok: 然し一方で変なのは ls -la /proc/$$/fd で見てみると接続先が /dev/tty
      になっている。普通の端末で実行すると Ubuntu WSL でもちゃんと /dev/pts/2
      等の様になっている。

      この振る舞いは変ではないかと思って linux で試してみたら linux でもそうだっ
      た。/dev/tty と表示される様になる。また /dev/tty は symlink という訳でも
      ない。他に気づいた事は exec >/dev/tty で開いた端末は書き込みに対応してい
      ないという事。exec 1>&0 としてから何か出力しようとすると失敗する。

    ? tty が何も出力していなかった。どういう事だろうか? クラッシュしているのか、
      それとも成功した上で何も出力していないのか、或いは失敗して何も出力してい
      ないのか? と思ったら単に stderr をリダイレクトするのを忘れていただけだった。

      或いは echo で >/dev/tty に書き込みをしようとしたら何が起こるのか? 普通に
      書き込みできるのか?

      →試した。先ず、tty は失敗していない。単に /dev/tty という出力をしている
      のだった。然し、これは普通なのだろうか? 本来の tty を表示する物ではないの
      か?

      Ubuntu WSL のコンソールで exec >/dev/tty 2>/dev/tty 0</dev/tty を実行して
      から tty を実行してみたら普通に /dev/tty と表示される。つまり、/dev/tty
      からつなぎ直すと (最終的には元の端末に繋がっているのにも関わらず)
      /dev/tty という名前になってしまう? 実はこれは Linux の上でも同様だった。
      だとすると元の tty の名前を取得する方法はないという事なのだろうか? 調べる
      と以下の報告があって、然し POSIX はこれを許容しているとの事。しかしだとす
      れば ttyname が存在している理由は何なのだろう。本質的に "/dev/tty" という
      文字列リテラルで十分ではないかという事になってしまわないのか?

      https://linux.debian.bugs.dist.narkive.com/x30lM5y8/bug-682972-ttyname-and-bin-tty-on-dev-tty-return-dev-tty

      然し同じ事を以前も調べて同じ記事を見た様な気がする。

    結局 nRF Connect の中で得られる /dev/tty の振る舞いは Linux のそれと全く同
    じであり、別におかしな /dev/tty が開かれたとは断定できない。寧ろ、本当に
    nRF Connect が TTY を初期化している可能性が出てきた。うーん。

    ? 一方で、ps はプロセス毎に tty 名を表示している。これは何を元にしているの
      だろうか。/proc/pid/fd/0 辺りを参考にしている? (だとすると /dev/tty を開
      いたプロセスでは ps で表示されるのは /dev/tty という事になってしまう)。

      →何と ps は 0,1,2 を /dev/tty にしてしまっても、ちゃんと元の ttyname を
      表示している。という事は tty を取得する方法はやはりちゃんとあるという事に
      なる。念の為、他の fd に残っている /dev/pts/5 も全て閉じたがちゃんと ps
      は一連のプロセスが /dev/pts/5 に属しているという事を言い当てている。

      Linux 上でも同様に振る舞うか確かめた。ちゃんと同じ様に振る舞っている。特
      に /dev/pts/0 を持っているプロセスが全くなくなっても ps はちゃんと言い当
      てている。うーん。ps は /proc/$$/sessionid を元にして何とか取得しているの
      だろうか。

    ? nRF Connect から呼び出された bash の中で ps を実行したら tty を取得できる
      か? うーん。/dev/pts/1 が割り当てられている様に見えるが、結果が truncate
      されている為にどのプロセスが一番最初のプロセス化が見えない。少なくとも結
      構親が遠い様に見える。

  * 2024-01-26 Konsole shell integration (reported by mcarans) [#D2128]
    https://github.com/akinomyoga/ble.sh/issues/391

    Konsole と DomTerm でそもそも設定が異なる様に思われる。なのに何故動いたとい
    う報告になっているのだろうか。そもそもこの shell integration については統一
    された仕様が存在するのだろうか。また DomTerm では動くのだろうか。

    PS1='\[\e]133;L\a\]\[\e]133;D;$?\]\[\e]133;A\a\]'$PS1'\[\e]133;B\a\]';
    PS2='\[\e]133;A\a\]'$PS2'\[\e]133;B\a\]';
    PS0='\[\e]133;C\a\]'

    先ず使用が存在しないか探す事にする。先ず紹介されたページだがこれは Konsole
    の機能紹介のページであって、制御シーケンスなどの実装の詳細については何も書
    いていない。

      https://docs.kde.org/stable5/en/konsole/konsole/semantic-shell-integration.html

    semantic shell integration で調べると Konsole のページが一番最初に出てくる。

      https://www.reddit.com/r/kde/comments/zf1ehj/psa_konsole_2208_now_supports_semantic_shell/

    tmux の Issue に feature request が出ているが対応しているのかしていないのか
    よく分からない感じで閉じられている。多分、要求されたとおりには実装していな
    いのだろう。

      https://github.com/tmux/tmux/issues/3064

    "The spec can be found here" として示されているのが DomTerm の作者が TWG に
    作成した以下の文書である。というか proposal 段階なのに "spec" と言っている
    のは駄目な事である。確かに spec ではあるが、authoritative な物ではないとい
    う事に注意するべきである。

      https://gitlab.freedesktop.org/Per_Bothner/specifications/blob/master/proposals/semantic-prompts.md

    実際の振る舞いを確認してみようと思ったがそもそも plain bash でも動かない。
    Konsole の version が古いからだろうか。然し、C-M-] でちゃんと出力されるので
    semantic integration に関してはすでに対応しているはずである。或いはクリック
    して移動できる機能というのは、もっと新しい ver でないと駄目なのだろうか。或
    いは有効化するオプションが別に存在する可能性?

      取り敢えず手元のバージョンは konsole 23.08.4 である。

    * 最初の対応 (22.08) の時の reddit の投稿では click したら移動できるという
      様な話は書いていない。というかそもそも詳細について何も述べていないのでこ
      の時点で何に対応していたのかは不明である。

    ---------------------------------------------------------------------------

    向こうの報告を見て改めてテストしてみたら konsole の変な振る舞いについて確認
    できた。konsole をビルドして確認してみる。konsole をビルドしようとしたら
    konsole が依存しているライブラリが新しすぎて Fedora の toolchain では駄目の
    様だ。仕方がないので konsole の version を巻き戻して確認してみる事にする。
    fedora の konsole は 23.08 なので、release/23.08 をビルドしてみる。

    $ mkdir build
    $ cd build
    $ cmake ..

    とすると依存関係のエラーが発生する。dnf で以下をインストールした。

      kf5-kbookmarks-devel
      kf5-kconfig-devel
      kf5-kconfigwidgets-devel
      kf5-kcoreaddons-devel
      kf5-kcrash-devel
      kf5-kdbusaddons-devel
      kf5-kguiaddons-devel
      kf5-ki18n-devel
      kf5-kiconthemes-devel
      kf5-kio-devel
      kf5-knewstuff-devel
      kf5-knotifications-devel
      kf5-knotifyconfig-devel
      kf5-kparts-devel
      kf5-kservice-devel
      kf5-ktextwidgets-devel
      kf5-kwidgetsaddons-devel
      kf5-kwindowsystem-devel
      kf5-kxmlgui-devel

    更に以下も追加で入れたらコンパイルできた。

      kf5-kglobalaccel-devel
      kf5-kpty-devel

    自前でビルドした物でも問題を再現できた。調べてみると Profile の読み取りはで
    きている。マウスをクリックした時の判定もちゃんと動いている。

    改めて返答があって plain Bash でも echo を最初に実行しない限り問題が発生す
    るとの事。自分で試してみると確かにそうだ。もしかすると端末の最初の行だと動
    かないのではと思って試して見たらそうだった。初期化順序の問題かと思って
    Konsole のソースコードに printf を仕込んで色々振る舞いを見てみたが、ちゃん
    と初期化はされてイベントは検出・送信されている。しかし、途中で範囲チェック
    で引っかかって無視されている。関数の想定する座標の原点が (0,0) か (1,1) か
    でずれている様だ。最初に submit された時からずれている。その時から範囲チェッ
    クがあったので最初から動かなかったのだろう。色々調べた結果は GitHub の方に
    書き込んだ。Konsole の方に MR を提出した。

    https://invent.kde.org/utilities/konsole/-/merge_requests/951

    ---------------------------------------------------------------------------
    https://github.com/akinomyoga/ble.sh/issues/391#issuecomment-1915834867

    [症状]

    * 初期化順序の問題で動いたり動かなかったりするらしい。当然の事ながら
      ble-attach はプロンプトや precmd に対して修正が入るよりも前でなければなら
      ない。

    * また bash-it の loading だと動かないそうだ。bash-it の blesh はどういう初
      期化をしているのかと確認してみたが別にその場で ble-attach している訳では
      ない。prompt attach を明示的に指定している。

    [再現]

    bash-preexec とのロードの順番についても過去にちゃんと動く様にした筈である。
    これは取り敢えず実験する必要がある。自分の手元で試す限りは問題は発生しない
    様である。と思ったら一回コマンドを実行した後で問題が起こるらしい。調べてみ
    ると preexc/precmd がそれぞれ2回ずつ実行されていて問題が再現する。

    [原因]

    少なくとも二重に実行されているのは修正する必要がある。bash-preexec は検出さ
    れてちゃんと integration/bash-preexec はロードされているみたいだ。一方で、
    既存の bash-preexec が正しく除去できていないのが問題の様に思われる。

    ? 以前これは bash-preexec をどの順番で初期化しても動く様にした筈である。そ
      の時から何が変わったのか。bash-preexec 対応を行ったのは #D1744 (e85f52cb)
      である。

      うーん。e85f52cb もちゃんと動いていない。具体的には source ble.sh してか
      ら source bash-preexec すると二重に実行される様になる。prompt attach でも
      manual attach でも同様である。bash-preexec の変更によって正しく動作しなく
      なったという事だろうか

      →どうやらその様だ。古い bash-preexec だとちゃんと一回ずつに修正が入って
      いる。但し、二回目のプロンプトでは preexec が二重に実行されている。
      bash-preexec 7ad48e1 の修正以降で二重に実行される様になった様だ。というか
      これは自分が提出した修正である。何が起こっているのか確認する必要がある。

    別に bash-preexec 7ad48e1 の修正によって毎回強制的に PROMPT_COMMAND を調整
    するという処理が入っているという訳でもない (それにもし bash-preexec を適切
    に除去する事ができているのだとしたら、そもそも PROMPT_COMMAND を再調整する
    という処理すら入らないはずである)。代わりにインストールの構成が変化したので
    あった。単に、PROMPT_COMMAND に登録する仕方が変化しただけである。uninstall
    がいけないのか或いは検出部分がいけないのか分からないが確認する。

    検出に関しては bash-preexec のチェックを ATTACH と POSTEXEC で行っている。
    うーん。bash-preexec の除去は bashrc の末尾ではちゃんとできている様に見える
    (配列である事を除けば)。最初のコマンド実行の時点でもちゃんと PROMPT_COMMAND
    は空になっている様だ。然し、１つ目のコマンドを実行する時点で中身が復活する。
    何故?

    と思ったら PROMPT_COMMAND の内容が _ble_edit_PROMPT_COMMAND に待避されてい
    る様だ。ble-edit/adjust-PS1 が保存している。うーん。つまり、ble.sh 内部
    (hook を含む) から PROMPT_COMMAND を弄れない仕組みになっている。これは何故?
    #D1772 ec2a67aa7 で待避の振る舞いが追加されている。

    これが意味する所は ble.sh の hook からは PROMPT_COMMAND が変更できないとい
    う事なのではないか? と思ったが、恐らく POSTEXEC や PRECMD 等基本的な物に関
    しては大丈夫の筈。うーん。PRECMD と PREEXEC に関してはちゃんと PS1,
    PROMPT_COMMAND に干渉できるが、POSTEXEC では干渉できない様になっている。
    adjust された状態で POSTEXEC が呼び出されている。ERREXEC についてもそうであ
    る。少なくとも PS1 にはアクセスできるべきなので これらは修正するべきである。

    * done: POSTEXEC 及び ERREXEC が restore-PS1 context で実行される様にする。

    然し、それとは別にそもそも PROMPT_COMMAND を待避している理由は何なのかとそ
    れが本当に必要なのかという事。#D1772 の状況はとても複雑の様に見える。うーん。
    何れにしてもユーザーの hook が実行される瞬間というのは PS1 も見えているべき
    なので、adjust-PS1 文脈で hook を呼び出すのは間違っている気がする。という事
    を考えれば余り考えずに単に restore-PS1 を ATTACH 及び POSTEXEC の前で実行す
    るべきの気がする。

    * done: ATTACH も restore-PS1 context で実行する様にする。

    * done: __bp_imported 及び bash_preexec_imported を
      integration/bash-preexec.bash で設定してしまうべきなのではないか。これが
      一番簡単な解の様な気がする。但し、実際に共存してしまった時の対策もちゃん
      としておきたい。

      と思ったが、そもそも bash-preexec がロードされるまでは
      integration/bash-preexec.bash もロードされないのでこれは動かない。

      然し一方で二重にロードされるのを防ぐという意味では良いのではないか? と思っ
      たが bash-preexec 自身の二重ロードチェックがちゃんと動いている限りは気に
      しなくて良いのでは。うーん。でもユーザーが手動で integration/bash-preexec
      を導入している場合にはやはり guard があった方が良い気がする。

      一方で integration/bash-preexec で __bp_imported などを定義する様にすると、
      今度は bash-preexec.sh が新しくロードされた事をどの様に検出するのかという
      問題が生じる。或いは、一度 integration/bash-preexec がロードされたら
      bash-preexec.sh は決してロードされないという様に仮定して良いか?

      うーん。ble-reload の時に何が起こるのかについては考えるべき。或いは無駄に
      attach.hook が実行されても問題がないかという事。恐らく問題はない。

    試してみたら綺麗に動く様になった。初期化時に preexec/precmd が重複するかも
    しれないと思ったがそういう事もなくちゃんと期待された回数だけ動いている。

  * complete: auto-complete の部分 accept をする他の関数 (requested by Tommimon) [#D2127]
    https://github.com/akinomyoga/ble.sh/issues/397

    forward-xword に対応する一連の widget を追加しても良いのでは。
    auto_complete/insert-{e,c,u,s,f}word を追加した。動作テストもした。取り敢え
    ず動いている気がする。

    binding に関しては C-right は insert-cword で登録する。edit.sh の方で他にそ
    れらしい forward-xword は登録しているか? 確認すると forward-sword と
    forward-cword しかない。また、M-f は forward-cword である。一貫性を考えると
    M-f は forward-cword に変更するべきである。変更する事にする。幸い Q&A や
    Manual (complete_auto_wordbreaks)などでは [M-f] については言及していない。

2024-01-28

  * complete: "'bin'/cmd [TAB]" で単語が補完されない [#D2126]

    補完設定取得の為のコマンド名を外部から設定する様にして bin/cmd などに対して
    は動く様になったが 'bin'/cmd に対しては結局動かない。更に一文字でも引数が入
    力されていれば動く。何故だろう。quote がなければ一文字も入力していなくても
    動く。

    $ 'bin'/test1 [TAB] 動かない
    $ 'bin'/test1 a[TAB] 動く
    $ bin/test1 [TAB] 動く

    そもそも ble/complete/progcomp が呼び出されていない。うーん。
    source:argument の時点で呼び出されていない。completion-context の生成で失敗
    しているという事。

    ? ok: 振る舞いを見ると何だかよく分からない。そもそも "echo [TAB]" の時点で
      completion context のチェックに於いて next-command が生成されている。

      何故 next-argument でないのか? "echo hello [TAB]" の時にはちゃんと
      next-argument が生成されている。そして何故 next-command であるのにも関わ
      らずちゃんと補完を実行できている様に見えるのか。うーん。check-prefix は一
      旦候補を生成した後にそれが現在のカーソル位置まで継続しているかチェックす
      る。単語の先頭の場合には check-prefix で生成した物は結局使われないという
      事の気がする。

      →これは check-prefix の候補生成なので問題ない。この文脈では本来の処理は
      check-here の方から生成される。

    どうも "echo [TAB]" の場合には check-prefix による source が一つも生成され
    ないので check-here の方に処理が流れてくるが、"'bin'/test1 [TAB]" の時には
    何故か "command 0" というのが source として生成される為に check-here まで処
    理が流れてこない様だ。

    では何故 "command 0" 等という source が生成されてしまうのか。

    a 何と inside-command の方では単語が終わっていない事をチェックするのを忘れ
      ている。と思ったが単語が終わっているかどうかをどうやって判定するのか?

      単純な単語であれば良いが、複雑な構造を持つ単語の場合には simple-word では
      判定できない。check-prefix で simple-word を使って判定できていたのは、単
      語の文脈を保ったまま一回の解析中断点で進めるのは単純単語に限られたからな
      のではないか? と思ったが $((...)) の場合にはどうだろうか。

      ? ok: inside-argument の方でも同様のチェックが必要になるのではないか?

        と思ったが引数の場合には check-prefix は単語の終端を当てる気がする。→
        実際に確認してみた所、引数の場合には終端にはちゃんと解析中断点が設置さ
        れるので問題ない。

    b 或いは内部構造が存在している時点で関数名とはならないのだから解析中断点を
      置けば良いのではないか?

      x ok: と思ったが編集の途中でたまたま解析状態が一致して更新がされない等の
        事は発生するだろうか? うーん。例えば内部構造がある状態から内部構造がな
        い場合に移行する場合には何が起こるかというと単語の最初から解析し直す。
        その場合には一気に単語の末尾及び続く空白まで読み取る事になるので、解析
        中断点が予期せず残るという状況にはならない。或いは、内部構造がない状態
        から内部構造が発生した場合にはどうなるかというと、それまでは空白の終わ
        りまで一気に読んでいたので空白の終わりに到達する迄は解析状態が一致する
        事もなく、ちゃんと空白の終わりまで解析がやり直される。

      なので、内部状態の有無によって (或いはもっと正確には関数名候補になるかど
      うかに応じて) 解析中断点を設置するというのは一つの手である。

      ? 然し本当に有効な関数名は単純単語である事が保証されるのだろうか?

        例えば履歴展開。現在の実装だと a!b の様な関数名も許容している。これによっ
        て履歴展開が発動するとしても (実際に試してみたが履歴展開があるとやはり
        関数名の位置にあっても履歴展開が発生して変な事になる)。うーんでも、実際
        に例えば前のコマンドの最後の単語を関数名にしたい等という時には関数名の
        位置にそういった物を含ませる事を許容して良い気がする。

        うーん。対応する履歴が見つからない場合には結局 ! を含む関数をそのまま定
        義できてしまうみたいである。なので、やはり履歴展開があっても関数として
        の解釈を中断する訳には行かない。

        一方で $((...)) の様な物は関数の中には含められない。有効な識別子ではあ
        りませんというエラーになる。

    c 或いはそもそもコマンド名に関しては単純単語でない物は補完しない可能性

      例えば安全に評価できるより複雑なものがあるのだとしたらそれを単純単語に取
      り入れてしまえば良い。と思ったがユーザーがユーザー固有の安全な単語を考え
      ている場合などを考えるとそういった物も許しておいてユーザーの側でユーザー
      の好みに応じた拡張的な補完を定義できても原理的に良い。或いは、既存のコマ
      ンド名を遡って消して新しい物を挿入する可能性だってある。なので、単純単語
      ベースの判定はやはり不完全な気がする。

      それに構文解析しているのだから文法構造を反映して補完文脈は抽出したいもの
      である。という事を考えるとやはり b の方針になる気がする。

    d 或いは更にもう一つの可能性はコマンド名の終端ではやはり解析中断点を設置す
      る事にして但し lookahead を設定しておくという事。そうすれば "func ()" が
      "func x" に書き換わった場合などでもちゃんと再処理される。

      然しこの方法について過去にさんざん考察したはずで、過去の考察で何が問題だっ
      たのかもう忘れている。改めて過去の議論を調べるのは大変である。

      [これまでの実装]

      関数定義の実装は歴史的にどうなっていたか。e1e87c2c (記録なし) で func()
      が導入されたがこの時点で既に空白を余分に読み取っていた。8717767e (#D0225)
      で function func が導入された。多少コードに変更があるが本質的には変わらな
      い。26219e4f (#D0590) は単なる refactoring である。然し、関数の解析に関連
      する問題が度々発生して修正した筈である。今検索して見つかるのは #D1848 と
      #D0210 である ("関数定義" で検索した)。

      * 前者は function aaa bbb ... の着色についてで、文法エラー着色がされてい
        るのにも関わらず関数定義およびコマンド名の単語着色でエラー着色が上書き
        されているという物。

      * 後者は shift の時に単語が stat と一緒にあると仮定していた所為で起こった
        バグについてであって、これに関しては今回は気にしなくて良い。

      他にもっと問題が継続して発生した事があった様な気がするけれど議論が見つか
      らない。/syntax\(\.sh\)?:.*関数/ で検索してみたが見つからない。或いは、最
      初に実装した時に暫く使ってそれで色々修正したというだけかもしれない。だい
      ぶ初期に実装したのでその時は未だ全てを記録していたわけではないのである。

      [実装]

      然しこれまでの実装は実装として、そもそもの設計理念にさえ従っていれば本当
      は問題は発生しないはずである。という事を考えれば、今回の場合も別に途中に
      解析中断点を置いたからと言って本来は問題は起こらない筈なのではないか。昔
      実装した時には未だ lookahead の機能がなかっただけである。とは言いつつ、
      completion-context だとかその他の機能で stat を参照している物が影響を受け
      る可能性は残っている。うーん。

      もしかしたら問題が発生するかもしれないが取り敢えず lookahead を設定する方
      向に変更する事にした。簡単に試した限りでは問題は起こっていない。これで暫
      く様子見する。

    結局 d の方針で解析中断点を設置する事にした。ちゃんと補完が動くようになった
    か確かめた。最初は動いていないと思ったが make し直したら動く様になった。
    make し忘れてテストしていたのかもしれない。

  * complete: ./manage.py で呼び出した補完が動かない (reported by REmerald) [#D2125]

    どうも補完設定的には complete manage.py で登録しているけれども、受け取った
    $1 を使ってコマンドを呼び出して補完候補を取得するらしい。

    一方で、ble.sh では登録されているコマンドを呼び出す様にしていた筈。何故かと
    いうと、

    * $1 に quote 等が含まれていると動かなくなるから。

    * また、$1 が純粋なコマンド名でない場合 (/ が含まれている場合) に正しく対応
      できていない場合にもちゃんと動く様にしたかったというのがある。然し、これ
      については実際に問題になる場合があった訳ではないし、この様に逆方向に問題
      が起きる可能性があるのであれば気にしない事にする。

    ? もう一つの問題点はこの様な補完設定は安全なのかという問題もある。つまり、
      悪意のある ./manage.py を含むディレクトリに入って ./manage.py を入力して
      補完を実行したらその時点でその悪意のあるファイルが実行されてしまう。然し、
      これは ./manage.py を実行した時点で覚悟するべき事なのかもしれない。とは言
      いつつもしユーザーが実際に [TAB] を押さない限りは大丈夫だと誤認していた時
      に問題が発生する。しかし、これは django の設定の問題の気がするので ble.sh
      が気にすることではない気がする。

    とにかく関連するコードを探して其処に何らかの考察が書き残されていないか確認
    する事にする。どうも comp_words の時点で既に調整されている様である。
    comp_words を生成した時点ではちゃんとそのままの文字列が含まれている。
    ble/complete/progcomp 関数の中で見つかった補完設定に応じてコマンド名を再
    quote されたコマンド名本体に書き換えられている。うーん。

    多少履歴を辿って見ることにする。どうも */ の除去は dbe87c35 (2021-05-29) で
    導入されてそのままの様である。試してみると ble-0.3 では確かに bin/test1 と
    すれば bin/test1 というコマンド名が各配列に入っている。dbe87c35 の関連する
    項目は #D1581, #D1583 だが何れも */ を除くか除かないかの議論に関しては触れ
    られていない。それよりは quote 除去について議論している。つまり、歴史的には
    */ を除去しているのは大した理由があった訳ではないという事。

    ? そもそも bash はどの様に振る舞うのか? cmd cur prev を補完関数に渡すが cmd
      に渡されるのは quote されているのかされていないのか。/ が含まれるのか含ま
      れないのか。

      うーん。先ず bash は quote されていると補完がそもそも起動しない。
      'bin'/test1 等の様にすれば test1 が登録されていれば補完が呼び出されるが、
      その場合でも 'bin' に対する quote が自動で外される等の事はない。また、
      bash は COMP_WORDS に対しても $1 (cmd) に対してもユーザーが入力した物をそ
      のまま指定する様だ。

    仕方がないので取り敢えずは */ で除去するのはやめる事にした。

    x すると今度は */* に対してそもそも補完が動かなくなった。どうやら .compgen
      の現在の実装は complete -p "${comp_words[@]}" が設定されている事が前提に
      なっている様だ (という事は今までも quote が必要な場合には complete -p で
      登録されている物と comp_words[0] に格納される物が異なって補完が呼び出され
      なかったのではないか?)。

      コメントを見ると .compgen は cmd という外部変数を通して補完設定取得に用い
      るコマンド名を得る事になっているが現在の実装ではそうはなっていない
      (progcomp はなっている)。この記述の使用を復活させる事にする。呼び出し元で
      cmd という変数が設定されているかどうかを確認する。調べてみた所呼び出し元
      は本質的には ble/complete/progcomp だけである。他の場所で呼び出しているの
      は initial かdefault を指定しているので cmd は何れにしても参照されないの
      で気にしなくて良い。

2024-01-27

  * edit: display-shell-version に atuin を追加する [#D2124]

    特に ble.sh との相互運用が強くなってきたので問題が起こった時に情報として含
    まれていた方が良い。

  * test: interactive での ble check が正しく動いていない [#D2123]

    test-bash で振る舞いが異なる物がある。また util の途中で hang して応答がな
    くなる。

    * test-bash で発生していた問題はそもそも今までの非対話シェルでのテストがちゃ
      んと動いていなかった。set -H をしておかないと history -p "..." は失敗する
      のだった。何も出力しなかったのは失敗したからであって、本来は履歴展開に失
      敗したとしても history -p 自体は失敗しなくて展開前の文字列を出力する筈な
      のであった。これはテストの内部で set -H と指定すれば直った。

    * util の途中で hang して応答がなくなったのは idle で対話シェルで設定されて
      いる sleep をずっと待機していたからだった。テストを行うサブシェルの中では
      抑制して良いので ble/util/idle.clearという関数を追加してそれで中身を空に
      してからテストを行う事にした。

    * 次の問題はテストが終了した時に hang するという事。プロンプトが表示されて
      いないがそれ以外の info 等は表示した状態で固まる。応答は受け付けなくなる。
      top で見ると 10% ぐらいでずっと CPU を使っているので何かが無限ループになっ
      ている可能性。idle.do の一番外側のループは別に回っていない。

      ble/util/idle/IS_IDLE も subshell の中で設定しているだけだから外側に影響
      があるとは思えない。

      ble check {bash,main,util} では問題は発生しない。ble check keymap.vi で問
      題が生じる。_ble_decode_keymap_stack や _ble_decode_keymap が壊れた状態に
      なるのかと思ったがそうでもない。ble/decode/initialize が悪いのかと思った
      が ble/decode/initialize だけ実行した時は問題は発生しない。テストを実行し
      た時にだけ問題が発生している。テストをサブシェルの中で実行すると問題は発
      生しない。つまり、テストが内部状態を破壊している。

      うーん。プロンプトが表示されていない問題と応答がなくなる問題は別のようだ。

      * プロンプトが表示されなくなる問題は ble/keymap:vi_test/section:search に
        よって引き起こされる。恐らくプロンプトまたはコマンドラインの描画が走っ
        ているのだろう。これは ble/textarea#invalidate を呼び出したら直ったので
        良い事にする。

      * 応答がなくなる問題は ble/keymap:vi_test/section:macro によって引き起こ
        されている。と思ったら ble/function#push ble/util/is-stdin-ready したの
        を pop していなかった。

      そもそもクラッシュする可能性のあるテストを親シェルの中で実行するべきなの
      かという疑問もある。ただ、今の所はクラッシュしていないし、この様に後に影
      響が残るという事は何らかのバグを抱えている事の指標になるかもしれないので
      取り敢えずはこのまま親シェルで実行する事にする。

  * complete: kubectl のエイリアスに対する補完が動かない (reported by dragonde, georglauterbach) [#D2122]
    https://github.com/akinomyoga/ble.sh/issues/394

    また kubectl の alias の補完が効かないとの報告があった。うーん。実際に
    kubectl コマンド (mock) は呼び出されていないみたいだ。

    提供されたコードを観察して見ると最近対策を行った cobraV2 と同様の形をしてい
    る。eval で COMP_WORDS に含まれていたコマンド名を呼び出している。実際に試し
    てみると plain bash の補完の場合には alias の展開はなされている。ble.sh の
    補完関数の中では alias 展開が実行されないのかと思ったがそうでもないようだ。
    自分で簡単な補完関数を作って中で eval "..." とした場合ちゃんと ... に対して
    alias 展開が適用される。


    最近 cobraV2 に対して行った対策を眺めてみると kubectl に対してもちゃんと対
    策が適用される筈である。然し、よく見てみると対策を行ったのはブロックする場
    合に対してであって alias に対してではなかった。受け取ったコマンドは
    conditional-sync 経由で呼び出している。conditional-sync を呼び出す前の補助
    関数の時点でコマンド名が消滅しているか変質している? と思って
    conditional-sync の直前で eval を実行してみたが、そこでもちゃんと alias 展
    開は実行される様だ。

    という事はサブシェルで呼び出している為に alias 展開が無効化されているという
    事? と思って自前で作った関数の中でサブシェルを作って実行してみたがそれでも
    alias 展開はちゃんと実行されている様だ。bg で起動しても振る舞いは変わらない。
    ちゃんと動く。不思議だ。

    或いは conditional-sync がそもそもコマンドを呼び出していない? と思ったが
    kubectl の補完の時にはちゃんと動いているというのだから関係ない筈である。
    conditional-sync を実際に自前のテストの補完関数の中から呼び出したら確かに
    alias 展開が抑制されている。何故だろう。eval を入れ子にしているのがいけない
    のかと思ってそれを直してみたが関係なかった。

    改めて conditional-sync の実装を見ると subshell の中で更に bg で起動してい
    る。これがいけないのだろうか。そうでもない。自前で試してみたがちゃんとalias
    は展開されている。conditoinal-sync を reduce して行ったらどうも [[ str ]]
    && eval "e xxxx" & の様な構造が問題の再現に必要の様である。不思議だ。

    * bash-bug: どうも bash が変な振る舞いをする様だという事が分かった。然し、
      コードコメントによるとこれは意図的な動作の一部の様である (余り consistent
      ではないが)。

      また、これはコマンドラインでも再現するのだろうか。→再現する。もっと簡単
      なコマンドでも再現した。一方で if 条件; then eval ...; fi では問題は発生
      しない様だ。

      $ alias e=echo
      $ eval e            # ok
      $ eval e &          # ok
      $ true && eval e &  # NG
      $ true && e &       # ok

      うーん。調べてみた限り一番古い bash-1.14 からこの振る舞いの様である。
      yash, zsh, ksh93u+m, mksh では再現しない。全部ちゃんと展開される。やはり
      これは bash のバグなのではないかという気がする。

      bash のソースコードを観察する。parse.y:5647 (commit 10702735) で展開する
      かどうかは判定されている。実際に true && eval 'e' & の場合に
      expand_aliases が false になっていて展開が阻害されている事を確認した。で
      はそもそも何故 expand_aliases = 0 になっているのか。振る舞いを見る限り瞬
      間的に 0 になっているだけの様に見える。

      うーん。eval_builtin が呼びされた段階で既に expand_aliases が 0 になって
      いる様だ。調べていくとどうもコメントが書かれていて、意図的な動作の様だ。

      https://git.savannah.gnu.org/cgit/bash.git/tree/execute_cmd.c?h=devel&id=138f3cc3591163d18ee4b6390ecd6894d5d16977#n1583

      つまり、(command) & の時にはエイリアス展開を off にしたいが、ユーザーが意
      図的に shopt -s expand_aliases を non-interactive shell の中でした時には、
      (command) & の中でもエイリアス展開を有効にすると書かれている。(じゃあ、
      interactive shell の中で shopt -s expand_aliases を実行した時には
      (command) & の中でエイリアス展開をしなくて良いのか、等色々おかしいがいつ
      もの事である。)

    * bash のおかしな動作とは別に現在の conditional-sync の 条件 && eval cmd &
      は構文として使い方が変なのではないか。本来は "条件 && { eval cmd & }" の
      積もりであるが、これだと "{ 条件 && eval e; } &" になってしまっている気が
      する。"echo $BASHPID && echo $BASHPID &" の実行結果を見る限りは & は全体
      にかかっている。

      というか現在の実装だと __ble_pid に値を指定していてもそれが無視されて上書
      きされてしまう様になっている。これは問題である。しかもこれは 0.3 に対して
      も適用する必要がある。

      取り敢えずこれに対する修正を行ったら自動的に bash の変な振る舞いも回避す
      る事になっているのでこの修正で良い事にする。実際に問題が発生しない事を確
      認した。

      また、このバグは今までの histdb の sqlite3 プロセスが何故か残ってしまう問
      題にも関係している気がする。また暫く使ってみて様子見という事にする。一旦
      端末は全て閉じた方が良さそう。

    * 序でで余分に eval をしている部分を簡単にした。

    * test-bash.sh に今回の振る舞いについてテストケースを追加しておく。

2024-01-22

  * edit: 日本語が混ざっている時の単語移動 (cword) がおかしい [#D2121]

    他の単語についてはどうだろうか。fword, sword, uword は問題ない様に見える。
    一方で eword は振る舞いが cword と同様に変だ。つまり cword と eword は単語
    を構成する文字以外は全て空白文字と同様に扱っているという事? 本来は 空白・対
    象文字・その他の文字の三種類に分けて検出を行うべき。

2024-01-21

  * complete: zoxide TAB completion が動かない (reported by 6801318d8d) [#D2120]
    https://github.com/akinomyoga/ble.sh/issues/390
    Ref #D1907

    core-complete.sh の zoxide の検出コードを見てみたら $comp_func == _z しか確
    認していない。確認してみると現在 (zoxide 0.9.2) の補完関数の名前は
    __zoxide_z_complete である。一方で、 contrib/integration/zoxide では既にこ
    の新しい名前に対応している。恐らく #D1907 だろう。然し、この時に検出コード
    の方の更新を忘れていたという事である。

    自分の手元の arch で試してみると zoxide の検出ができていない。一方で報告さ
    れた display-shell-version の結果ではちゃんと zoxide が検出できている。何故
    だろう。改めて zoxide のチェックを行っている所を見ると何故か使われていない
    starship バイナリの位置の検出コードが紛れ込んでいる。check:starship の中に
    あるのと全く同じであって、zoxide 様に調整しているという事もない。starship
    が存在しないのでこの部分で引っ掛かって zoxide の検出が中断されていたみたい
    だ。修正した。

    それから starship の検出部分に starship という変数の variable leak がある。
    check:zoxide の該当部分は消してしまうので問題ないが echeck:starship の方に全
    く同じコードがあるのでそちらを直す。

2024-01-20

  * C-v C-[ a などと入力すると ESC a ではなく \M-a らしき物が入力される [#D2119]

    どうも入力するキーの種類に関係なく同じ文字が挿入される。
    C-v の後にキーを読み取る時の isolated ESC の取り扱いを確認する必要がある気
    がする。時間を置いていれば isoalted ESC として受信できて良いはずだが? と思っ
    たが isolated ESC だからこそ isolated ESC として使っているコードがそのまま
    挿入されているという事なのだろうか? 確認する必要がある。

    ? isolated ESC だとすると何にも使っていない文字を使っている筈なのに何故よく
      分からない文字が表示されるのだろうか? やはり isolated ESC でもない別の文
      字が挿入されているのだろうか。

    * どうも vi mode ではちゃんと処理される。emacs mode だけで発生する問題の様
      だ。逆に言えば結構長い期間この変な振る舞いがあったという事になるのかもし
      れない。

    isolated ESC の処理は ble-decode-char で行われている。

    % 一方で quoted-insert が使っているのは _ble_decode_char__hook なので
    % ble-decode-char の処理よりも前に isolated ESC を受け取る事になる。という
    % かこの処理だと xterm 等で普通の C-v C-v 等の入力もできなくなるのでは?
    %
    % でも実際には vi mode ではちゃんと処理できている気がする。vi mode では別の
    % 実装方法になっているのだったか? key の方を受信してからそれを逆方向に翻訳
    % していた様な気がする→確認してみると vi mode の quoted-insert では
    % _ble_decode_key__hook を使っている。でも最終的に使っているのはやはり
    % ble/widget/quoted-insert.hook である。

    改めて見たら emacs でも vi でもちゃんと _ble_decode_key__hook 経由で呼び出
    していた。_ble_decode_char__hook を使っていたのはまた別の widget である
    quoted-insert-char だった。

    ? ok: 所で、quoted-insert-char は既定では使われているのか? →使われていない。
      なのでユーザーが意図的にこれを使おうとしなければ C-v C-v が意図通りの結果
      にならない等の現象にはならない。

    振る舞いを調べてみると quoted-insert は M-a を受け取っている。これを
    batch-insert にそのまま渡している。

    % という事は batch-insert がこれをどの様に処理するのかにかかっている。
    % overwrite-mode の時には self-insert で一文字ずつ処理する。それ以外の場合
    % には chars2s で文字列に変換してから insert-string でそのまま挿入している。
    % chars2s は printf \U... を使って文字コードを直接文字列に変換しているだけ
    % なので modifiers の処理などは全く行っていない。
    %
    % * 先ず初めに chars2s に渡す前に処理をするべきではないのか? 例えば C-1 や
    %   C-2 等はどの様に処理するのか?
    %
    % ? 何故 C-1 や C-2 はちゃんと keyseq に変換されて処理されているのだろう?
    %   batch-insert で処理されている様だが…。と思ったら分かった。

    batch-insert に渡しているのは key ではなくて CHARS である。つまり現在の key
    を生成するのに至った文字の列を batch-insert に渡している。そして M-a に対応
    するのは CHARS=(2047 97) になっていて、つまり IsolatedESC a である。

    ここで修正するべきは CHARS の値の気がする。IsolatedESC は widget から CHARS
    経由で見えてはいけない。なので CHARS に格納する時点で 2047 は 27 に変換して
    おくべきなのである。一方で CHARS は何処から来ているかというと
    ble-decode-char の内部状態を記録している seq, mseq という変数に入っている気
    がする。これらは _ble_decode_char2_seq に記録されている物である。

    ? reject: _ble_decode_char2_seq に記録する時点で IsolatedESC を 27 に書き換
      えれば良いのでは?

      % % 該当する key 用の文字シーケンスの一致に失敗した時に最長一致または最初
      % % の文字を除外して、改めて文字を最初から処理し直すので、 IsolatedESC は
      % % そのままに保持しておく必要がある。二文字目以降の IsolatedESC は ESC
      % % に直してしまっていいかというとそうでもない。
      % %
      % % うーん。実際にその様な事があるだろうか。つまり、IsolatedESC が key を
      % % 表現する文字シーケンスの一部 (2文字目以降) になるという事があるだろう
      % % か。そもそも ESC だって有効なシーケンスの二文字目以降に現れるとは思え
      % % ない。
      % %
      % % と思ったが M-up などでは ESC ESC [ A という事になる。これを手動で入力
      % % して再現しようとする事も原理的には可能な筈である。例えばユーザーが
      % % @ESC @ESC q 等と入力した時に、一致に失敗して改めて @ESC q を再処理し
      % % ようとする時に ESC q になって欲しいのに M-q になってしまうという問題
      % % が起こる?  と思ったが、@ESC は (@ESC を esc として処理するモードでは)
      % % すぐに通常文字として取り扱われるので最初に @ESC が来てそれで始まる文
      % % 字シーケンスが記録される事はない。では ESC @ESC が可能かというと、こ
      % % れも2つ目の @ESC を受け取った時点で M-C-[ に翻訳されてしまうので文字
      % % シーケンスの中に登録される事はない。結局、文字シーケンスの内部に @ESC
      % % が混入するのは @ESC を ESC と同等に処理するモードだけではないのか。
      %
      % まとめると、@ESC が有効な時 (ESC と区別して、孤立 ESC として取り扱う必
      % 要があるモード の時) は、@ESC が文字シーケンスの prefix の中に含まれる
      % 事はありえないので、そもそも文字シーケンスの中に含まれる事はない。従っ
      % て、@ESC が文字シーケンスの中に含まれているという事は、ESC と区別しない
      % モードにあるという事であり、だとすれば文字シーケンスに登録する時点で
      % @ESC を ESC に変換してしまって良い。
      %
      % というより寧ろ変換するべきである。実は今までは @ESC のまま記録されてい
      % た為に手動で ESC ESC [ A とした時に M-up になるべきなのが正しく処理され
      % ていなかったのでは? → 改めて確認したところ現在の実装では @ESC を Meta
      % として扱うのはそれが先頭に来た時だけで、既に Meta が予約されている時に
      % は @ESC が来たら即座に C-M-[ になる様だ。その意味で実は @ESC を meta と
      % して取り扱うモードであったとしても ESC と @ESC の取り扱うは微妙に異なる。
      %
      % うーん。つまり現在の実装だと @ESC は @ESC が不活性のモードであっても文
      % 字シーケンス prefix の二文字目以降に来ることはないという事の気がする。

      [用語定義] isolated ESC (以降 @ESC) の取り扱いに複数のモードがある。モー
      ドによって @ESC が独立した入力として取り扱われるか Meta modifier 候補とし
      て取り扱われるかが切り替わる。前者になった時を "@ESC が活性の時" とし後者
      を "@ESC が不活性の時" と呼ぶ事にする。不活性 @ESC は文字シーケンスの先頭
      に現れて meta modifier になる事ができるが、それ以外の時には孤立 ESC とし
      て扱われ、特殊キーの文字シーケンスの一部として取り扱われる事はない。

      活性 @ESC は文字シーケンスの prefix に含まれる事はない。何故なら活性 @ESC
      は常に特殊キーの如くに扱われ、それが現れたら文字シーケンスが終了するから
      である。不活性 @ESC は文字シーケンスの最初に現れて暫定 meta modifier とな
      る。

        不活性 @ESC が文字シーケンスの二文字目以降に現れる事も実はない。不活性
        とは言っても通常の ESC と同じではなく、meta modifier 以外で文字シーケン
        スの一部にはならないからである。

        つまり @ESC は文字シーケンス prefix の先頭にしか現れない。処理し直しに
        なったとしても必ず一文字は consume されるので、処理し直す文字に @ESC が
        混入する事はない。なので、実は _ble_decode_char2_seq に記録する時点で
        ESC に変換しても特に問題が発生する訳ではない。

      然し、それでも処理の仕組み的には _ble_decode_char2_seq には直接受け取った
      物を記録しておくのが自然の気がする。逆に先頭にしか @ESC が記録されないの
      であれば、CHARS を設定する時に先頭の @ESC を ESC に変えれば良いだけの話で
      ある。

      % どうも改めてコードを見ると (特殊なmodifierシーケンス) が前につく事があっ
      % て、その場合には @ESC が二文字目以降に現れる事もある。但し、"特殊な
      % modifier シーケンス" は _ble_decode_char2_seq ではなく
      % て _ble_decode_char2_modseq の中に記録される。
      %
      % ? うーん。処理し直す時に modseq は含めてなくても良いのか? →処理し直す
      %   時には modifier をクリアする訳ではないので modseq は再処理の対象では
      %   ない。

    modifier の処理とその前の段階の処理は分けて考えれば良い。

      chars -> unmodified-keys -> keys

      ※unmodified-keys は修飾シーケンス (M- など) もしくはキーシーケンス (a,
        up, や C-up など) を含む。unmodified-keys とは言ってもキーシーケンスの
        時点で最初から修飾されている物もあるが、修飾シーケンスによって追加で修
        飾される。

    という具合にシーケンスを変換していて一つ目の -> の段階における seq では@ESC
    は必ず先頭にしか現れない。なので一つ目の -> の確定時 (.send-modified-key 呼
    び出し時) に seq を配列に変換して、最初の文字が@ESC だったらそれを ESC に変
    える事にすれば良い。

    * done: .send-modified-key は send-unmodified-key に改名する事にした。元は
      受け取った unmodified-key を処理して modified-key を送るという意味で名付
      けたが、send-xxxx となっていれば関数の引数に指定するものが xxxx であると
      思うのが自然である。ややこしいので ble-decode-char -> ble/decode/* の名前
      空間の移動の序でに変更する事にした。

    ? ok: 文字シーケンス失敗した時の consume でちゃんと ESC に翻訳されるか? →
      確認したら一文字目は何れにしても (iESC も) そのまま
      _ble_decode_char2_reach_key に記録されるが、その後に失敗が判明した時に
      .send-modifier-key 経由で処理されるのでちゃんと翻訳される。

    ? ok: ところで @ESC を使って keybinding を処理する事はできたのだったか? →
      これは単に C-[ を使って keyseq を指定すれば良いのではないか? そもそも
      keybinding の指定は keyseq であって charseq ではない。なので、
      ble-decode-char の処理ではなくて ble-decode-key の処理である。そして
      ble-decode-key に渡る頃には @ESC は C-[ か M- に変換されているので、@ESC
      が現れる事はない。なので、keyseq に @ESC を指定しても意味がない。代わりに
      C-[ と指定するのと等価である。

    ? ok: _ble_decode_char__hook の時の @ESC の処理はどうなっているのか? 翻訳す
      るべきなのではないか? 実際に bash が受け取っているのは @ESC に変換する前
      の ESC なのだから → 確認した所既にちゃんと翻訳する様になっていた。

    ? done: CHARS は ble-decode-key の呼び出し前に設定されている。単体で
      ble-decode-key を実行した時に問題になるのではないか。現在の実装だとユーザー
      が設定した変数と交じるかもしれないので、ble-decode-key を呼び出す前に設定
      する変数は _ble_decode_char_seq などの別の変数名にして、ble-decode-key の
      内部で CHARS を改めて設定する。もし ble-decode-key の中
      で_ble_decode_char_seq が空だったらその場でキーに対応する char seq を適当
      に生成する?

      x 文字+修飾に関しては特殊キーの場合に対応するシーケンスをどの様に生成する
        のかは非自明である。up/down/right/left は標準的な方法を用いるとしても、
        変な端末にしかない特殊な文字に関してはどうするのか?

      ? ok: 実際に入力したのとは別のシーケンスを挿入してしまっても問題ないのか?
        と思ったがそもそも ble-decode-key を手動で呼び出している時点で対応する
        シーケンスは存在していない。何か別の物にすり替えたという訳ではないので
        問題ない気がする。

      やはり ble-decode-key の段階では、直接 ble-decode-key を呼び出した場合に
      は CHARS=() という事にするのが自然の気がする。そもそも CHARS を復元したと
      しても実際に使われる可能性は可也低い。それならば実際に CHARS を参照する側
      が、CHARS が空だった時に KEYS から CHARS を生成するのが自然の気がする。

      key から chars を逆に生成するコードは vi のマクロ関係の処理にあった気がす
      るのでそれを流用するか参考にする。必要があれば decode にコードを移動する。
      →確認してみたが vi macro で使っていたのは charlog であった。
      ble/decode/charlog#encode も NUL を escape しているだけだった。キーから文
      字列への逆変換は実装した様な気がするが最終的には採用されなかったのかもし
      れない。

      うーん。やはり decode の側で自動的に代表的なシーケンスを記録する仕組みを
      作っておくべき気がする。特に一番最初に登録された物を採用するのが自然の気
      がする。

      キャッシュする仕組みが必要である。これは現在の ble-bind -D で出力する配列
      を増やして、また init-cmap.sh のキャッシュを生成している場所でフィルター
      する配列を追加すれば良い。

      * 取り敢えず csi で系統的に修飾されている物は登録する事にした。

      * それ以外の ble-bind -k で登録される物も考えようと思ったが、そういった物
        は何れにしても端末間で統一された物ではないのでわざわざ翻訳しても仕方が
        ない気がするのでやめる事にした。

      * kp1 等が登録されている為に C-1 を入力すると kp1 による function key
        modification がされてしまっているがまあ気にしなくて良い。ble.sh 的には
        同じ取扱になるのだから。

  * util: EXIT stty 必要性の検出方法の改善 [#D2118]

    bash-5.2 以降の終了時の stty 云々の表示は SHLVL を参照すれば良いのでは。
    SHLVL 1 の時には何も表示しなくて良い。

    | * ok: と思ったが、ssh で入った時には駄目の気がする。壊れたままになってし
    |   まう可能性が残る。
    |
    |   →ssh に関しては実際に試してみた所問題は起こらない様だ。恐らく ssh が良
    |   い様に調整してくれている。
    |
    |     よく考えたら remote のシェルが見ている tty は remote で ssh が割り当
    |     てた tty なのだから設定が直接 local の tty に反映される訳では無い。
    |     remote の tty による filter がかかった後のデータが local の tty に送
    |     られて来るだけである。
    |
    |     もし local にも同じ設定を適用してしまったら二重に filter されて変な事
    |     になってしまう。仮に local の tty に設定をコピーするという使い方をし
    |     ようと思うと、ssh が local tty の設定を全て設定するそばから解除して
    |     local の tty に適用し直し、かつ remote を raw に設定して local に全部
    |     受け渡すという事をしなければならず、それは不自然である。
    |
    |     なので local の tty に影響がないというのは自然な事である。
    |
    |   現在の実装では親プロセスの tty を調べていて、どうやら ssh で入ったシェ
    |   ルの直接の親には tty が割り当てられていないので、自分自身が一番上にある
    |   という事を検出できていて、なので "stty sane" のメッセージは表示されない。
    |   結果として問題ない振る舞いになっている。
    |
    | * ok: screen についてもシェルは直接大本の SCREEN にぶら下がるので tty は
    |   親プロセスとは異なる物になっていて "stty sane" のメッセージが無駄に表示
    |   される事はない。
    |
    | x 端末については現在ちゃんと検出できていない → これは cygwin における
    |   tty 判定がちゃんと動いていなかったのが原因だった。

    別に SHLVL を参照しなくても tty の判定だけで十分という事になった。

    * reject: 但し、SHLVL > 1 の時には ps -o によるチェックをスキップできるので
      は? と思ったが、間に screen が挟まっている場合でも SHLVL > 1 になるので
      SHLVL > 1 だからと言って必ずしも "stty sane" を出力する必要があるとは限ら
      ない。

    * 逆に SHLVL == 1 の時には常に "stty sane" の表示は不要ではないか?  ssh が
      一つの懸念だったが ssh の場合には間に remote の tty が挟まるのでやはり
      "stty sane" しなくても良い。

    それとは別に Cygwin で発生している問題を解決する。

    * Cygwin で端末の中で起動した bash が "stty sane" の案内を終了時に出力する
      現在の実装では親プロセスと tty が同じかどうか確認しているが、それでもトッ
      プレベルの端末の終了時にエラーメッセージが表示されてしまう。

      どうも tty のチェックに用いている ps -o が Cygwin で期待通りに動作してい
      ないだけである。ps -o の代わりになる物は cygwin にあるだろうか。そもそも
      procps が実装されていない。と思ったが一応 proc はあった。/proc/$$/ctty を
      見たら tty を取得できた。

      cygwin では /proc/$$/ctty を参照して親プロセスの tty を取得する→実装した。

2024-01-15

  * complete: 大きなリポジトリで make の反応が遅い (reported by blackteahamburger) [#D2117]
    https://github.com/akinomyoga/ble.sh/issues/389

    そもそもこれは補完設定の方が悪い様な気がするし、或いはそのような巨大な物を
    想定するというのが酷なことである様に思うが対応できるので対応する事にする。
    取り敢えず憶測で実装した物がちゃんと動くという事を確かめて貰ったので含める
    事にする。

2024-01-07

  * main: set -u で外側の文脈で ble-import integration/bash-preexec すると unset エラーが出る [#D2116]

    bash: _ble_bash_BASH_REMATCH: 未割り当ての変数です
    bash: _ble_edit_LINENO: 未割り当ての変数です

    これらを直接 integration/bash-preexec で参照している訳ではない。ble-import
    の際の save/restore が関係しているのではないか。

    うーん。一つ目に関しては ble-import 時の待避が関係している。後者はもっと後
    で発生している様だ。

    * 結局前者は ble/base/restore-BASH_REMATCH の実装に於いて
      _ble_bash_BASH_REMATCH の最初の要素を参照するつもりで直接書いていたのが駄
      目だった。配列 _ble_bash_BASH_REMATCH 自体は存在していても、前回の一致が
      失敗した時には空の配列になるので ${_ble_bash_BASH_REMATCH} で参照しようと
      すると nounset に引っかかる。

    x fixed: またテストしていて気づいたが _ble_bash_BASH_REMATCH の待避に関して
      は bash-5.1 以降で単純に保存・復元するだけにしたつもりだったが _ble_bash
      を初期化する前に参照していたので常に古い実装が使われていた。_ble_bash を
      使わない version 判定にする。

    * 後者に関しては _ble_edit_LINENO が最初に設定されるのは
      ble-edit/attach/.attach の瞬間である。それよりも前にこれを参照している箇
      所があるという事だろうか。うーん。attach するより前に
      invoke-hook-with-setexit を呼び出していて、この関数は既に attach している
      事を想定にしているという事。内部で行番号を参照している。attach する前は
      BASH_LINENO の最後の要素を参照する事にした。

  * README: magic-slash について追記する (motivated by dgudim) [#D2115]
    https://github.com/akinomyoga/ble.sh/issues/388

    * wiki も inline sabbrev 等の種別について記述する。

  * global: 再び leakvar が幾つか出ているので修正する [#D2114]

    isubcmd を見返して気づいた。序でなので改めて調べる。

    ble/debug/leakvar#list で確認してみると version が leak している。histdb で
    一箇所 local 忘れがあって直したがそれでも未だ version がある (変数の内容は
    変化したので histdb からも leak していたのは間違いない)。"assign version"
    で検索したら ble.pp の awk version 検出部分で local 忘れしている箇所が見つ
    かった。

    その他、description を表示すると g x1 x2 y1 y2 が leak している→これは
    menu prefix の処理が問題だった。幅を計測する関数と実際に描画シーケンスを生
    成する関数の二つがあったが、両方で g が leak していた。x1 x2 y1 y2 について
    は描画する関数の方では使わないので measure-bbox をつけていたのが余分だった。
    修正した。

    他に j と insert_flags が怪しい。j に関しては core-syntax.sh に於いて
    locate-filenames の中のループ変数に対応する local j が抜けていた。
    insert_flags に関しては auto-complete/source:syntax に於いて
    ble/complete/action:"$ACTION"/complete を呼び出しているが、insert_flags や
    insert_beg, insert_end 等の変数を宣言していなかった。何れも修正した。

    rex も leak している箇所がある様だ。内容を見ると ^"([^\"]|\\.)*" になってい
    る。このコードが自体は古いものだが rex が leak する様になったのは最近の修正
    によってそれより前にあった rex を修正・改名したからである。

  * test: CI で未だ bind 関連の警告が発生している [#D2113]

    何処かの bind でちゃんと stderr を抑えきれていない。改めて何処で発生してい
    るか確かめる事にする。恐らく read-user-settings 関連である → 確かめた所や
    はり再構築したユーザー設定の eval の場所でエラーメッセージが表示されている。
    再構築したユーザー設定は単に bind -m ... '...' の連続である。eval 全体を
    2>/dev/null してしまって良い気がする。

    その他にも bash: no job control in this shell というエラーメッセージが出て
    いる→これは bash の既定の keymap を取得する時に起動している bash -i から出
    ていた。一緒に出ていた ioctl だとか controlling terminial のエラーも此処か
    ら発生していた。

2024-01-05

  * mandb: git のオプションの説明は man git-subcommand から取得するべき (motivated by bkerin) [#D2112]
    https://github.com/akinomyoga/ble.sh/issues/386

    果たしてこれが報告者の意図していた事かは分からないがその様に読めなくもない。
    何れにしてもこれは対応できる様な気がするので対応する事にする。

    ? 先ず、mandb から説明を補填するかどうかの判定条件に $compcmd ==
      ${comp_words[0]} がある。これは一体何を意味しているのか。compcmd の初期化
      を辿ってみると、先ず -D や -I の特別な場合を除き ${comp_words[0]}} を代入
      している。そして、その後で simple-word の時には eval した値で置き換えてい
      る。eval したかどうかで振る舞いを変えるというのは変な気がするので、これは
      単に -D や -I ではないという事を確認する為の物だろうか。

      一応コードの履歴を確認する事にする。判定は c1cd666b で最初に progcomp に
      対する説明付加が導入された時から存在しているが、大した議論は残っていない。
      特に意図があってこの様な判定にしたという訳でもない気がするので、気にしな
      い事にする。単に -D または -I ではないという事を確認する為のコードと思う
      事にする。

      然し、-D だったとしても man ${comp_words[0]} で候補を探索しても良いのでは
      ないか? うーん。改めて ${comp_words[0]} を展開しなおしてしまっても良いの
      では?

    うーん。取り敢えず progcomp で生成したオプションに説明を付加する部分と、
    source:option の generate-for-command で対応した。

    x ok: generate-for-command の alias 展開 & 変数代入読み飛ばし部分で
      words[iret] になっていた。修正した。

    * done: ble/complete/mandb:bash-completion/inject の対象である
      _comp_longopt は _comp_complete_longopt に改名された。一応両方に対応でき
      る様にしておく。

      また __load_completion は _comp_load -D に変わった。今回の場合には -D は
      欲しくないので _comp_load で呼び出す (わざわざ -D を bash-completion で導
      入したのは ble.sh を使う事を念頭に置いての物)。

    x done: git format-patch --output-directory に関しては元々は = が入っていた
      が、man git-format-patch には = が含まれていない為に単なる空白に変わって
      しまっている。git が suggest する内容に = が含まれている場合には = を保持
      する様にできないか? → その様に修正した。

    * done: simple-word/safe-eval を使える箇所は置き換える。

  * progcomp: git の補完するオプションで --option= の後に空白が挿入される (reported by bkerin) [#D2111]
    https://github.com/akinomyoga/ble.sh/issues/387

    調べてみるとそもそも git の補完に関してはどの程度 quote したら良いかも不明
    という事なので、末尾の空白を消してその後に空白を付加するという実装になって
    いる。特に git の補完が付加した compopt -o nospace を除去している。これを生
    成された候補に応じて nospace を保持する様にするべきなのでは?

    一つでも末尾空白がない物があれば nospace を保持するのか、或いは全ての生成候
    補について末尾空白がない場合に nospace を保持するのか、どちらが良いか? 曖昧
    である場合には付加しないという観点から言えば一つでも末尾空白がない物があれ
    ば nospace を保持するべきである。

  * mandb: git の説明の抽出が変 (reported by bkerin) [#D2110]
    https://github.com/akinomyoga/ble.sh/issues/386

    コードを見たら物凄く単純なミスだった。man ping の解析をする為に導入したコー
    ドが励起していて、その時点で複数行の説明の場合にも対応する様に書いていたが、
    変数に新しい行を追加する時に前の行内容を入れるのを忘れていたので、最終的に
    最終行しか残っていなかった。単純な修正だった。

    x ok: 修正したら今度は --config-env= 等の候補が表示されなくなってしまった。
      と思ったが元々表示されていなかった。git completion の時点で config-env は
      候補として表示していない様だ。然し一方で complete -r した後でも表示されな
      いのは不思議である。と思ったが unset -f __load_completion 等したらちゃん
      と生成される様になった。つまり、--config-env が表示されないのは git
      completion による意図的な物という事。

2023-12-31

  * [棄却] PREEXEC で一定時間以上時間をかけるとコマンド実行前後に 0.1ms の遅延が生じる [#D2109]

    Note: これはどうしようもない気がするので気にしない事にする。

    atuin による時間計測を観察していて気づいた。atuin がなくても以下の簡単な設
    定で観察できる。sleep 0.1 の時間を縮めて行くと突然遅延はなくなる。また
    sleep 0.1 の時間を長くして行っても遅延が長くなる訳ではない。直後のコマンド
    実行にのみ影響を与える様である。

    $ blehook PREEXEC='sleep 0.1'
    $ blehook POSTEXEC='echo beg=$_ble_exec_time_beg:ret=$ret:end=$_ble_exec_time_end:ata=$_ble_exec_time_ata'
    $ ret=$EPOCHREALTIME

    色々詳細に時間を計測すると ble-edit/exec:gexec/.restore-lastarg から抜ける
    時に時間がかかっている様に見える。うーん。何に時間がかかっているのか本当に
    気になる。

    bash の execute_cmd.c (execute_function) に DPF を埋め込んでそれぞれのコー
    ドの呼び出し時間を計測する。

               | w/PREEXEC           | w/o PREEXEC
      ---------+---------------------+---------------------
      b1  まで | 33,31,30    avg 31  | 8,9,8,9     avg 9
      b2  まで | 55,62,64    avg 60  | 20,20,21,21 avg 21
      b3  まで | 32,36,39    avg 35  | 11,11,11,12 avg 11
      b4  まで | 31,34,34    avg 32  | 11,10,10,10 avg 10
      c4  まで | 30,33,33    avg 32  | 10,11,10,10 avg 10
      c3  まで | 45,31.33    avg 36  | 11,10,11,11 avg 11
      c31 まで | 32,39,33    avg 35  | 11,11,10,11 avg 11
      c32 まで | 69,75,76    avg 73  | 25,24,24,24 avg 24
      c2  まで | 34,42,54    avg 43  | 13,12,13,13 avg 13
      c1  まで | 35,53,51    avg 46  | 11,11,11,10 avg 11
      実行まで | ?                   |
      end まで | 265,323,291 avg 293 | 57,59,56,56 avg 57

    分かる事は全体に遅くなっているという事。これは OS レベルの話なのだろうか。
    また、b2 と c32 が元より遅くて、更にとても遅くなっているという事。然し、b2
    は単に result = return_catch_value; という文を実行しているだけである。一方
    で、c32 は run_unwind_frame ("function_calling") を実行している。

    うーん。何処かに特に問題があるというよりは全体に遅くなっているという事。こ
    れはどういう事なのか謎である。何か CPU のキャッシュの問題だろうか。外部プロ
    セスから復帰した瞬間は色々メモリアクセスが遅くなっているという可能性? しか
    しそうだとしても DPF が毎回 10us かかっていてその速度が回数を重ねても改善し
    ないのは変だ。だとするとメモリアクセスは関係ない?

      | --- a/execute_cmd.c
      | +++ b/execute_cmd.c
      | @@ -5292,13 +5292,18 @@ execute_function (SHELL_VAR *var, WORD_LIST *words, int flags, struct fd_bitmap
      |    return_catch_flag++;
      |    return_val = setjmp_nosigs (return_catch);
      |
      | +int dbg1 = strcmp(var->name, "ble-edit/exec:gexec/.restore-lastarg")==0;
      |    if (return_val)
      |      {
      | +if (dbg1) DPF("b1 %s", var->name);
      |        result = return_catch_value;
      |        /* Run the RETURN trap in the function's context. */
      | +if (dbg1) DPF("b2 %s", var->name);
      |        save_current = currently_executing_command;
      | +if (dbg1) DPF("b3 %s", var->name);
      |        if (from_return_trap == 0)
      |  ^Irun_return_trap ();
      | +if (dbg1) DPF("b4 %s", var->name);
      |        currently_executing_command = save_current;
      |      }
      |    else
      | @@ -5308,6 +5313,7 @@ execute_function (SHELL_VAR *var, WORD_LIST *words, int flags, struct fd_bitmap
      |        showing_function_line = 1;
      |        save_current = currently_executing_command;
      |        result = run_debug_trap ();
      | +if (dbg1) DPF("a %s", var->name);
      |  #if defined (DEBUGGER)
      |        /* In debugging mode, if the DEBUG trap returns a non-zero status, we
      |  ^I skip the command. */
      | @@ -5315,7 +5321,9 @@ execute_function (SHELL_VAR *var, WORD_LIST *words, int flags, struct fd_bitmap
      |  ^I{
      |  ^I  showing_function_line = 0;
      |  ^I  currently_executing_command = save_current;
      | +if (dbg1) DPF("a1 %s", var->name);
      |  ^I  result = execute_command_internal (fc, 0, NO_PIPE, NO_PIPE, fds_to_close);
      | +if (dbg1) DPF("a2 %s", var->name);
      |
      |  ^I  /* Run the RETURN trap in the function's context */
      |  ^I  save_current = currently_executing_command;
      | @@ -5332,13 +5340,18 @@ execute_function (SHELL_VAR *var, WORD_LIST *words, int flags, struct fd_bitmap
      |        showing_function_line = 0;
      |      }
      |
      | +if (dbg1) DPF("c4");
      |    /* If we have a local copy of OPTIND, note it in the saved getopts state. */
      |    gv = find_variable ("OPTIND");
      |    if (gv && gv->context == variable_context)
      |      gs->gs_flags |= 1;
      |
      | -  if (subshell == 0)
      | +if (dbg1) DPF("c3 %d", subshell);
      | +  if (subshell == 0) {
      | +if (dbg1) DPF("c31");
      |      run_unwind_frame ("function_calling");
      | +if (dbg1) DPF("c32");
      | +  }
      |  #if defined (ARRAY_VARS)
      |    else
      |      {
      | @@ -5349,7 +5362,9 @@ execute_function (SHELL_VAR *var, WORD_LIST *words, int flags, struct fd_bitmap
      |      }
      |  #endif
      |
      | +if (dbg1) DPF("c2 %s", var->name);
      |    function_misc_cleanup ();
      | +if (dbg1) DPF("c1 %s", var->name);
      |    return (result);
      |  }

    謎に包まれている。bash-5.0 でも同様の現象がある。bash-4.4 以前については
    EPOCHREALTIME が存在していないので振る舞いを調べる事はできない。また、
    version で違うという事を期待する理由もない気がする。

2023-12-30

  * 2023-12-26 gexec: LINENO が更新されなくなっている [#D2108]

    LINENO=... eval '...' では駄目なのか? どうも調べてみるとこれでは eval の一
    番最初のコマンドしか LINENO が適用されない様である。やはり unset -v するし
    かないのだろうか。todo にこの事は記録されていないのか? → 検索する限りは残
    されていない。

    と思ったら #D1824 に書かれていた。どうもこれは bash のバグである。他の変数
    でも全く同じ現象を再現できた。これに依存している他の全ての変数について問題
    が生じるのではないか? これを回避する方法はないのか? 例えば二重に eval した
    ら? → 駄目だった。

    - このバグを最初に見つけたのは f1 help の表示で LESS だか MANPATH だかを指
      定した物だった筈。更に今回のこれ。他にも declare 関係であった気がする。

    * 現状の対策としてはやはり LINENO は unset して明示的に設定するという事。但
      し、他の BASH_COMMAND 等については対策できない。

    改めて #D1824 を読んでみると builtin eval ではなく eval を使うと書いてある。
    対応する commit は f629698e5 (2022-06-27) である。確かに確認してみると
    builtin を外している。然し、現在の master を見ると builtin eval になってい
    る。つまり、この変更を導入した時点ではちゃんとこの問題について意識していて
    その対策をしたという事。しかし、後で make scan か何かの結果を見て上書きして
    しまったという事。

    調べてみると #D1938 (commit 00cae745b2023-02-03) で書き換えられている。
    LINENO として ble.sh 内部の変数を直接参照していたために、コマンド発行時の値
    ではない値になるという問題があって、コマンド発行時に記録した lineno を使う
    様に変更したのだった。その時に builtin が抜けていると思って再度 builtin を
    追加してしまったのが問題である。

  * decode(bind): ble-bind -P に含まれる制御文字・bind の引数解析の修正 [#D2107]

    * fixed: ble-bind -P でコマンドの出力時に制御文字をちゃんと $'...' の形式で
      出力する必要があるのではないか?

      →実装を確認した所ちゃんと ble/string#quote-word を呼び出している。実際に
      改行等の制御文字については $'...' の形式に切り替わる。どうも、通常の制御
      文字に関しては対応していない様だ。というか、そもそも
      ble/string#escape-for-bash-escape-string からして任意の制御文字には対応し
      ていない。

      ble/string#escape-for-bash-escape-string 及び ble/string#quote-word の両
      方とも一般の制御文字 (C0 および DEL) の escape に対応する事にした。C1 に
      ついては少なくとも今は対応しない。

    * fixed: 現在の実装だと bind -x'"\C-t": ...' を正しく処理できていない。bash
      はちゃんと処理できている。真面目に実装する必要がある。

      うーん。これは独立した項目にして backport した方が良い気がする。という事
      を考えると前の項目の ble/string#quote-word も同様である。修正した。そんな
      に難しくなかった。

  * 2023-07-18 Grisha が bind -X の出力形式を修正している [#D2106]
    https://lists.gnu.org/archive/html/bug-bash/2023-07/msg00076.html

    現在の ble.sh は間違っている事を前提として問答無用で前後の "" を削除してい
    たはず。これの削除をなかった事にする。取り敢えず Grisha は "" で囲まない様
    に変更している気がする。なので、ble.sh はこのままで大丈夫の筈だが後で振る舞
    いをチェックする。

    →今確認した所 : が出力されなくなっている。何故? 一方で quote の数は変わっ
    ていない。元からちゃんと quote されていたという事の気がする。よく分からない
    が新しい形式として "keyseq" "command" という物が追加された様だ。また、この
    追加によって今まで可能だった bind -x '"keyseq" : "command"' が動かなくなっ
    ている

      →そもそも元々のコードでは "keyseq"anything: "command" でも動いていた。こ
      の振る舞いを潰すという事で考えるのであれば "keyseq" : も同様に潰すという
      考えでも良い気がする。

    うーん。そもそも色々振る舞いが違うかもしれない。振る舞いについて確認する。
    調べる限りでは quote して登録する事によって特別に変な事が起こるわけでもない
    気がする。\C-a 等の escape が削除されたという訳でもない。

    * done: bind -X を dump している箇所の修正は OK

    * done: bind の emulation をしている箇所も修正する必要がある。

      うーん。decompose-pair のインターフェイスを変更する? 目的に応じて振る舞い
      を変更するしかないのか?

      先ず ble/builtin/bind/.decompose-pair を呼び出しているのは
      ble/builtin/bind/.initialize-keys-and-value だけである。そして
      initialize-keys-and-value を呼び出しているのは ble/builtin/bind/option:x
      と ble/builtin/bind/option:- だけである。value を設定しているのは
      .decompose-pair であり、.initialize-keys-and-value は value には触ってい
      ない。option:- では囲みの "..." を除去しているのは option:- の中である。
      それは "macro" と rlfunc を区別する為に必要である。option:x の場合には最
      終的に全部文字列として取り扱うのだから関係ない?

      動作確認を行う。

      o ok: "\C-t": "echo hello " の形は大丈夫。元々末尾の空白が削除されていた
        がそれもちゃんと処理される様になった。

      x fixed: 余分な文字列が末尾にくっついている時に警告を表示する様にしている
        がそれが表示されない。何故か? どうやら suppress local error をしている
        為にちゃんと表示されていないという事の様だ。ちゃんと redirect して出力
        される様にした。

      o ok: "\C-t": "echo \"hello の様に閉じていない場合もちゃんとエラーが出力
        されている。

      o ok: "\C-t" "echo \"hello\"" などもちゃんとできている。"\C-t": echo
        \"hello\" もちゃんと動いている。

      ? ok: うーん。ble.sh の実装では "\C-t" "echo \"hello" は 'echo "hello' と
        解釈されているが bash-dev ではどうだろうか。'echo \"hello' にはならない
        のか? →試してみた所ちゃんと echo "hello" という感じになっている。echo
        \"hello\" の様にはなっていない。

      o ok: bind '"\C-t": "self-insert"' 及び bind '"\C-t": self-insert' もチェッ
        クした。周りに空白がある場合も動作確認した。

    x ok: そもそも ble/builtin/bind/option:x における value の解釈が怪しい。
      bash は "" の中にある escape をちゃんと処理している気がするが、ble.sh の
      実装では escape がそのまま残ってしまう。

      →改めて bash の振る舞いを確認してみたが別に処理していなかった。単にコマ
      ンドを実行する時の eval で処理されているのであって、bind -x で登録された
      文字列は未だ escape が処理される前の物である。

2023-12-24

  * github: CIテストが失敗している [#D2105]

    そもそもどの commit で失敗する様になったのかを特定する。

    或いは tolower や toupper が動かなくなっている可能性? と思ったが test-util
    を見てみると既に tolower や toupper についてのテストは完備している。二つの
    テストの失敗は独立な物の様である。

    * idle の方はテストフレームワークの変更によって引き起こされている気がする。
      と思ったがそうではない。idle は単に ble-import のテストに使っていた物であっ
      て、idle.do の時点で遅延されたロードが実行される事を期待していたのが実行
      されないという問題である。

      そして ble/util/idle/IS_IDLE がテスト環境では特別な状態になっている可能性?
      IS_IDLE は既定では ! stdin/is-ready 的な何かになっているが、それが常に成
      功するのだとしたら IS_IDLE は常に偽になり期待した物にならない。そもそもテ
      ストがその時の状態に依存しているのがいけないのだから IS_IDLE を上書きする
      べきである。

    * macro のテストの失敗については、これは元々テストフレームワークに載せてい
      なかったので前はチェックできていなかっただけで、実は前からこういう振る舞
      いだったと思われる。これの修正については色々試してどういう状態になってい
      るのか調べる必要がある。

      と思ったらマクロ再生部分に ble/util/is-stdin-ready が真だった時に失敗する
      様に書かれている。これが悪い。

    両方とも修正した。動く様になった。またテスト全体の成功失敗の判定を修正した。
    これまでの実装だと複数の section がある場合や source test-*.sh の最後が
    end-section でない時に正しく失敗が検出できていなかった。end-section 毎に失
    敗 section 数をインクリメントする事にした。

    2024-01-01 未だ失敗している。macos で失敗している。windows では一応成功はし
    ているが変なエラーが発生している。macos の方については単に bash-3.2 だった
    ので ble/util/idle.do が空実装になっていてそれを使ったテストが通っていない
    だけだった。

    windows の方についてはどうも rlfunc.txt の各行の末尾に \r がついているのが
    原因の様だ。然し、調べてみるとその他のファイルについても全部 \r がついてい
    る様に見える。何故問題になっていないのか。bash が読み取る時にいい具合にして
    くれるという事なのだろうか。

    ? その他の自前で読み書きしているファイルについては大丈夫なのだろうか?  →調
      べてみた所、自前で生成したファイルについては大丈夫だった。

      注意しなければならないファイルは rlfunc.txt, ignoreeof-messages.txt,
      vi_digraph.txt である。rlfunc.txt については対策はできた。
      ignoreeof-messages.txt については行内の何処かに一致していれば良いという作
      戦なので、余分な \r がついていてもちゃんと動作する。vi_digraph.txt につい
      ては mapfile で読み取っているのでちゃんと調整が必要になる。

    ? 或いは読み取る時の方法によって \r が除去されたりされなかったりする等の事
      があるのだろうか? もし mapfile だけで問題が起きるのだとしたらそれについて
      もちゃんと対策をする必要が出てくる。

      既存のファイル keymap.vi_digraph.txt を使って確かめてみる事にした。実際に
      keymap.vi_digraph.txt の中身も \r が付加されていて、更に read で読み取っ
      たとしても \r が混入してしまうという事が確認できた。つまり、mapfile を使っ
      たから悪いという訳ではない。

    修正した。

  * edit: history-search-backward に関する振る舞いに対する要望 (reported by blackteahamburger) [#D2104]
    https://github.com/akinomyoga/ble.sh/issues/382

    実際に自分で適当に以下の設定を試してみた所、空文字列で検索した時であっても
    (表面上はただの up と同様に振る舞っている様に見えつつも)、二回 enter を押さ
    ないと反応しない。

      bind '"\e[A": history-search-backward'
      bind '"\e[B": history-search-forward'

    lib/core-decode.*.rlfunc.txt を確認してみたがちゃんと対応表には
    empty=emulate-readline が指定されている。然し emulate-readline の実装を見て
    みても特に immediate-accept は指定されていない。emulate-readline が導入され
    たのは d68ba6196 (2021-09-23 #D1661 GitHub#139) であるが enter を押した時の
    振る舞いについては何も議論されていない。因みに immediate-accept は
    912579585 (2021-04-29 #D1517 GitHub#101,80) で導入されているので、
    emulate-readline が導入された時には既に存在していた筈。

2023-12-22

  * util(readonly): work around non-standard collation order (reported by dongxi8) [#D2103]
    https://github.com/akinomyoga/ble.sh/issues/335#issuecomment-1598485650

    恐らく中国語の collation order は aAbBcC 的な何かになっている。なので小文字
    である事を判定するのに [a-z] とすると失敗する。

    他に類似の物があるだろうかと思ったが多くの場合には [a-zA-Z] となっているの
    で即座に問題は置きない。但し、diacritical marks のついているアルファベット
    が混ざっている場合は多くあってそれが混入すると困る場合は実は結構ある。そう
    いう場合には対応しきれていない気がする。

    以下は既に対策済みだった物。よく考えた見たら _ble_util_string_lower_list 等
    の変数に全てのアルファベットを格納しているのだから単にそれを使って判定すれ
    ば良い。26文字の一文字ずつについて判定するのが大変に思うかもしれないが、
    locale の切り替えの方が格段に重いので、寧ろその様にした方が高速である。関数
    として ble/string#isupper, ble/string#islower を用意する事にした。指定した
    引数が一文字かつ大文字または小文字であるかを判定する。

      ./src/util.sh:928:[[ $ch == [A-Z] ]]
      ./src/util.sh:931:[[ $ch == [a-z] ]]
      ./src/util.sh:955:[[ $ch == [A-Z] ]]
      ./src/util.sh:969:[[ $ch == [a-z] ]]

    これは encode-rot13 での判定である。そして上と同様なので、単に
    ble/string#isupper もしくは ble/string#islower を使えば良い。

      ./lib/keymap.vi.sh:93:[[ $ch == [a-z] ]]

    これも ble/string#isupper を用いれば良い。

      ./src/edit.sh:745:[[ $c == [A-Z] ]]

    以下はそれぞれ a または A を除くアルファベットという物だった。範囲の指定の
    仕方を工夫して予期せぬ一致を回避する事にした。範囲指定を修正した。但し、
    LC_COLLATE を調整しない限りは diacritical mark のついている変な物も原理上範
    囲に含まれてしまうが、そもそも一致対象の文字列は declare -p の出力なので変
    な文字が含まれている可能性は排除して良い。

      ./src/util.sh:515:[b-zA-Z]
      ./src/util.sh:523:[a-zB-Z]

    これはそもそも使用文脈が限られているので小文字しかチェックしていなかったが
    大文字が混入しても良いもの。ややこしいので A-Z0-9 も許容する事にする。

      ./src/util.sh:3403:[12])(-[a-z]+)?$'; [[ $msleep_type =~ $rex ]]
      ./ble.pp:2131:[-a-z0-9]

    これは今回の問題箇所。外側で LC_COLLATE を調整する事で対策した。

      ./src/util.sh:7194:[[ $1 != *[a-z]* ]]

    これらは blehook において lowercase letter が含まれる hook 名は private
    hook として既定で除外する機能の為に使われている物である。blehook でも
    LC_COLLATE の調整を行う事にした。

      ./src/util.hook.sh:140:[[ $pat == *[a-z]* || $flags == *a* ]]
      ./src/util.hook.sh:141:[a-z]
      ./src/util.hook.sh:164:[[ $pat == *[a-z]* || $flags == *a* ]]
      ./src/util.hook.sh:165:[a-z]
      ./src/util.hook.sh:209:[[ $flags == *a* ]] || ble/array#remove-by-glob print '_ble_hook_h_*[a-z]

    これは awk スクリプトに含まれる物だった。他の方法で小文字判定をする事にした。

      ./lib/core-complete.sh:7115:[a-z]

    これは https:// 等の URL 先頭のスキームを検出するのに使っている。大文字を含
    んでいる物も一致させると C: 等の様な物も一致してしまって不都合である。なの
    で、小文字に限定したい。然し毎回 LC_COLLATE 等を調整するのは面倒なので
    ble/string#match-safe という関数を新しく追加する事にした。

      ./lib/core-syntax.sh:1661:[a-z]
      ./lib/core-syntax.sh:1729:[a-z]
      ./lib/core-syntax.sh:1754:[a-z]

    これは簡易判定に用いている物であって後でまたちゃんと判定し直しているので気
    にしなくて良い。

      ./lib/core-syntax.sh:3530:[a-z]+|^\[\[?|^[{}!]'; [[ $tail =~ $rex ]]

    make_command.sh に関してはスクリプト全体で LC_COLLATE=C を設定すれば良い。

      ./make_command.sh:235:[/[:space:]<>"'\''][a-z]\.txt|/dev/(pts/|pty)[0-9]
      ./make_command.sh:303:[A-Z]
      ./make_command.sh:491:[A-Z]
      ./make_command.sh:492:[_A-Z0-9]
      ./make_command.sh:493:[_A-Z0-9]
      ./make_command.sh:494:[_A-Z0-9]
      ./make_command.sh:496:[_A-Z0-9]
      ./make_command.sh:497:[_A-Z0-9]
      ./make_command.sh:617:[a-z]

    実験用スクリプトについては気にしない

      ./memo/D1341.locale-and-casematch.sh:7:[[ A == [a-z] ]]
      ./memo/D1341.locale-and-casematch.sh:27:[[ A == [a-z] ]]
      ./memo/D1760.fzf-completion-reduced.sh:10:[[a-z0-9.,:-]
      ./memo/D1760.fzf-completion-reduced.sh:27:[[a-z0-9.,:-]
      ./memo/benchmark/array-is-array.sh:84:[b-zA-Z]

    これは LC_COLLATE=C を設定する事にした。subshell なので解除しなくて良い。設
    定する時にはコマンドを何も指定せずに変数代入だけで LC_COLLATE=C 2>/dev/null
    としてもエラーを抑制できない。代わりに export LC_COLLATE=C という形で指定す
    る事にした。

      ./lib/test-util.sh:920:[a-zX-Z]
      ./lib/test-util.sh:921:[a-zX-Z]
      ./lib/test-util.sh:922:[a-zX-Z]
      ./lib/test-util.sh:929:[a-zX-Z]
      ./lib/test-util.sh:930:[a-zX-Z]
      ./lib/test-util.sh:931:[a-zX-Z]

2023-12-17

  * 2023-12-11 ble-import に関する説明を書く? (motivated by Dominiquini) [#D2102]
    https://github.com/akinomyoga/blesh-contrib/issues/16

    * ble-import -d の意味と、もし中の関数をすぐに使う必要があるのであれば、-d
      を指定しないという事を何処かに書いておく (何処かに既に説明を書いた様な気
      がしたが、改めて contrib README を見てみても -d についての説明は何処にも
      書かれていない)。

      取り敢えず書いた。分かりにくいかもしれないが。

    * また ble/util/import/eval-after-load の interface を ble-import のオプショ
      ンとして実装する可能性? 然し、これは変な気もする。つまり、オプション -H
      script を指定する事で、指定した通常引数をロードする代わりに、ロードされた
      時の付加動作を定義する事になっている。これは混乱の元の気がする。一方で、-q
      はロードしたかどうかを判定する物になっているので、既に指定したファイル名
      を必ずしもロードする訳では無い状況にはなっている。何れにしても、指定され
      た引数はモジュール名という事になっているので或る意味一貫している。

      これは mapfile と同様に -C callback というオプションとして実装する事にする。

2023-12-16

  * 2023-12-11 keymap.vi_test: テスト項目を ble/test を用いた物に書き換える [#D2101]

    後 leave-command-layout を呼んでいるのに行が再描画されない。何故? どうも
    ble/widget/vi-command:check-vi-mode/search を呼び出すと消える様だ。search
    に使っている info が干渉して内容が消滅する等している可能性? 一応
    ble/textarea#invalidate を enter-command-layout の後に実行すれば問題はない。
    うーん。どうやら、search の途中で描画を実行してしまうのでその時点で
    ble/textarea#invalidate の効果が消えてなくなってしまっているという事だろう。

    そもそも通常のテストの一部として取り組む事はできないか?

2023-12-13

  * keymap/vi: text objects for brackets が omap でも変 (reported by Darukutsu) [#D2100]

    恐らく真面目に実装していなかったという事? 最初に block.impl を導入したのは
    441ed955 だがこの commit の段階では not yet implemented 等と書かれている。
    とは言いつつ現在の処理が大体書かれている。

    % ? no: という事を考えると暫定実装がそのまま残っていたという事だろうか?
    %   ca0fc1ac まで行くと not yet implemented という文字列は消えてなくなって
    %   いるが、実装に本質的な変更がある様には見えない。not yet implemented が
    %   置き換わっているのは bd392394c だが、これは単に bell をまとめただけの様
    %   に見える。余り本質的な変更ではない。そもそも not yet implemented と書い
    %   ていたのは本体の処理ではなくて bell の部分だったので、妥当である。
    %
    %   → not yet implemented と書かれていたのは bell の処理であって本体の処理
    %   についてではない。

    ちゃんとした記録は残っていないが成立の経緯を考えると恐らく適当に最初に実装
    したのがそのまま残っていただけ。ちゃんと振る舞いを観察して実装し直すという
    事をするべき。先ずはテストから書く必要がある。

    取り敢えず実装した。xmap の実装も含めて繰り返しが多いので整理する。未だ動い
    ている。取り敢えずこれで良い事にする。

  * docs: CONTRIBUTING の BNF に間違いがある [#D2099]

    と思って修正したが他にも英語の間違いがある。これを機に全体的に Grammarly を
    適用してみたら沢山の間違いがあるので修正する事にした。

  * edit: undo が正しくできていない (reported by Darukutsu) [#D2098]
    https://github.com/akinomyoga/ble.sh/issues/377#issuecomment-1852503847

    記録の時点では問題はない。復元の時の読み取りも問題ない。然し、カーソル移動
    を決定する為に文字列の変化していない部分を検出する上で、共通部分を除いた後
    の文字列の内容がおかしい。と思ったら致命的な間違いをしている。何故今まで動
    いている様に見えたのかが謎である。実際にこの処理の結果として使っているのは
    共通接頭辞・共通接尾辞の長さだけなので大体問題なく動いていたという事だろう
    か。

    然し、そうだとしても echo 'fo'' になるのは謎である → 確認してみて分かった。
    "echo 'fo" + "''" という結合の仕方をしている。やはりちゃんと今まで大体 undo
    できていたのは不思議である。

  * decode,syntax: quote `$#` in arguments properly [#D2097]

    何故か裸の $# が残っていたのでちゃんと quote する。恐らく ${#...}  の形式及
    び $((...)) の形式しかチェックしていなかったのが原因。他のパターンは取り敢
    えずすぐには思いつかない。

2023-12-12

  * complete: suffix a space to non-filenames with compopt -o filenames (reported by Dominiquini) [#D2096]
    https://github.com/akinomyoga/ble.sh/issues/378

    一番最初の実装 (ce223f73) から action:file/complete はファイル名だけにしか
    ' ' や '/' は付加していない。その後に progcomp の compopt -o filenames が指
    定された時は候補を action:file/complete で処理する様になっていた。変更の歴
    史の中でも一時的に「全てに空白をつける」みたいな時期はなかったみたいだ (そ
    んな様な気もしたが気の所為か一時的に実験しただけという事だろうか)。

    分からないが bash の振る舞いが、compopt -o filenames を指定していたとしても
    非ファイル名に対して空白を挿入しているのでそれと同様になる様に修正する。こ
    の修正をしただけでちゃんと期待通りに動く様になった。

  * keymap/vi: text-object/block.impl を xmap に対応する (requested by Darukutsu) [#D2095]
    https://github.com/akinomyoga/ble.sh/issues/377#issuecomment-1850082254

    先ず初期状態として、現在のカーソル位置と他の端点の二つを考慮に入れる必要が
    ある。

    現在のカーソル位置を @ として他の端点を * とする。

    (1) @ と * が同じ位置にある場合。取り敢えず [bbb(ccc)] を区切りとしてその中
    から括弧の部分を探し出す振る舞いの様だ。気になったので確認したが取り敢えず
    ib i( i) の間に違いはない。

    | 引数がある場合には括弧の入れ子を考慮して外側に段々と広がる。1ib は ib と
    | 同じ。後、 ( (foo) b@ar (baz) ) に対して ib を実行すると " bar " ではなく
    | て外側の括弧の内側が選択される。つまり、現在の入れ子が一番外側でないので
    | あれば、" bar " ではなくて一つ外の括弧を選択するという事。
    |
    | ? "(foo) b@ar (baz)" で "ib" すると baz が選択されるが、"(foo) (b@ar)
    |   (baz)" で "2ib" だと baz が選択されるという事はないのか? → そういう事
    |   はない。つまり、一番最初に現在の文脈が何らかの括弧の中にあるかを判定し
    |   て、そうでなければ、次の括弧に行く。もしそうであれば現在位置が属する場
    |   所を探す。
    |
    | 現在閉じていない括弧の文脈にある場合にはどう頑張っても何も起こらない。
    |
    | * 途中に改行があっても関係ない。'...' とは違って行ごとの処理ではない様で
    |   ある。
    |
    | * 対応する始まりがない終わり括弧の直上にいる時には次の括弧に移動する。対
    |   応する始まりがない括弧の前にいる時には失敗する。

    ? todo: そもそも '...' だって実は改行は関係ない可能性もある? これは動作を確
      認する必要がある → 改めて試してみたがやはり '...' に関しては行内で完結し
      ている様である。

    (2) _ble_edit_ind > _ble_edit_mark の場合について調べる。うーん。ルールはよ
      く分からない。取り敢えず開始点 _ble_edit_mark で結構振る舞いが定まってい
      る様に思われる。但し、_ble_edit_ind も微妙に振る舞いに影響を与える。

    先ず mark より左側に開き括弧がある場合には全て忘れてその括弧に対応する部分
    を囲む様になっている様に思われる。

    (3) _ble_edit_ind < _ble_edit_mark の場合も色々試してみたが、 (2) の場合と
    振る舞いに違いは全くない。単に _ble_edit_ind と _ble_edit_mark を swap して
    処理すれば良い。

2023-12-11

  * vi: text-object:quote の振る舞いが xmap 内で正確ではない (reported by Darukutsu) [#D2094]
    https://github.com/akinomyoga/ble.sh/issues/377#issuecomment-1849550762

    vi_xmap for i' の振る舞いが異なるとの事。

    これは実装していない奴ではないかと思ったが、実際に確認してみると実装されて
    いる。単に手で規則を試した時の漏れという事の気がする。その他の微妙に異なる
    状況に関してはちゃんと vim の振る舞いを再現できている。

    ? no: 或いは vim の古い version と新しい version で振る舞いが違うという事な
      のかもしれないと思ったが、Ubuntu 16.04 の vim 7.4 (少なくとも 2013年には
      あった) の振る舞いを見る限りは、以前からそうであった。という事なのでやは
      り見落としである。

    修正は意外とコンパクトになった。

    * テスト項目を追加する。と思ったが長らく動かしていなかった。そもそもテスト
      が動かなくなっているかもしれない。と思って試しに走らせてみたらちょうど今
      回振る舞いを修正した所でエラーになっている。

      うーん。これは今回新しく修正した事によってテストが失敗する様になったのか?
      →実際に master で試してみるとテストは全て通る。という事はテスト項目自体
      が駄目だったという事になる。テスト項目を修正した。

  * vi: text-object を別の文字に割り当てようとしている人がいる (requested by Darukutsu) [#D2093]
    https://github.com/akinomyoga/ble.sh/issues/377

    元々は text-object a も i も同じ一つの widget で処理していてユーザーのキー
    入力が a か i かに応じて振る舞いを変更していた。然し、別の文字に
    text-object を割り当てようとすると i でも a でもないのでエラーになってしま
    う。

    元の Vim script ではどうなっているのか確認したが noremap で設定している限り
    は、実際に i や a がどう設定されているかどうかに関係なく、 i と指定すれば
    inner text-object になるし a と指定すれば outer text-object になる。なので、
    noremap を使っている限りは類似の問題は生じない。

    仕方ないので今回は text-object widget を text-object-inner と
    text-object-outer に分解する事にする。

    実装を考え直した。text-object をそのまま引数を受け取る様に拡張する方が良い。
    i と a の binding は分かりやすさの為にそれぞれ text-object-inner と
    text-object-outer のままにしておくが、text-object.impl という widget を新設
    するよりは元より text-object で引数に対応する事にして、
    text-object-{inner,outer} はその widget を呼び出す様にする。こちらの方が無
    駄な diff がなく良い。

2023-12-08

  * ble/array#*: nocasematch の時に _ble_local_script の ARR 置換が arr を誤爆 (reported by jkemp814) [#D2092]
    https://github.com/akinomyoga/ble.sh/discussions/376

    同様の処理をしている所は他にもある。態々 nocasematch を記録して外して置換を
    してからまた復元するというのは面倒である。変数名を置換するだけで問題が発生
    しなくなるのだから、全て変数名を置換するべきである。

    これ迄は配列名は全て ARR に統一していた。三文字と短くてまた分かりやすいと思っ
    ていたがこれは ble/array#* の arr 等にも一致している。NAME にしたが或いは
    ANAMEの方が良かっただろうか。でも短い方が良いし、NAME は既に使われている。
    ARR は配列名であるという事が分かりやすくて良いと考えていたが、改めて考えて
    みればそこでそれを強調する強い理由も余りない気がする。

    <ARR> という可能性も考えてみたがこれはこれで bash の文法的に読みにくくなっ
    てしまうので避けたい。__1__ は別に短くないし _1_ だとやはり誤爆しそうである。
    また _ で囲む方式にすると元々 _ で区切っている名前 (例えば _ble_xxx_ARR) な
    どの _ と紛らわしいので避けたい。その他の証とししなさそうなランダムな文字列
    を使うというのも却って分かりにくい気がする。色々考えるとやはり NAME ぐらい
    で良い。

    但し、NAME が他の NAME や name を衝突する場合には気を付けなければならない。
    LAYER は NAMEにすると同じ script 内にある _VARNAMES を誤って置換してしまう
    事になるので LNAME にする事にした。他により良い名前はあるだろうか。
    LAYERNAME だと長いし、LAYERID は余り他で使っていない名前の付け方である。
    LNAME ぐらいで我慢するのが良い気がする。

    * 因みに、nocasematch が ${var/pat} の振る舞いに影響を与える様になったのは
      bash-4.4 以降の様である。

    * done: 序に _ble_script という変数名で実装していたのが一箇所だけあったので
      を _ble_local_script に改名する事にした。他に code だとか script だとか使っ
      ている箇所もあるがこれらは変数名に制限があるか或いはその変数名を直接用い
      る訳ではなくて常に suffix や prefix がついている場合の様なので、変数名の
      衝突などは考えなくて良い。

    * done: opts 関連は注意するべきである。

    * done: core-complete の compopt は諦めた。別にオプション名が大文字・小文字
      で縮退するという事はない気がするし、今後勝手に追加する時には気をつける事
      にすれば良い。

    * ok: bash-preexec.bash の BP_INSTALL_STRING に関しては十分に複雑な文字列だ
      し大文字・小文字が違う文字列で他の用途の物が混入するとも思われない。更に、
      ここで修正しても仕方がない。upstream でも同時に修正を行う必要がある。然し
      一方で upstream でこの様な実際に起こるとは思い難い状況の為に nocasematch
      の保存復元をするコードが accept されるとは思えない。なのでこれは放置する
      のが適当である様に思われる。

      BP_PROMPT_COMMAND_PREFIX も同様の理由で考えない事にする。

    * done: ble/cmdinfo/complete/yield-flag は流石にユーザーの指定したオプショ
      ンの大文字・小文字を区別しないのは変なので対策する事にする。

    * done: 置換で他に類似の物はないだろうか。記号しか来ないと分かっている箇所
      は気にしなくて良い ($q や或いは文字の置換を行っている時の $a など)。'%d'
      等で置換をしようとしている箇所も、元々の文字列に変な % が入ってこないとい
      う事を前提にしている箇所の気がするので除外して良い。また変数の側で紛らわ
      しい文字列が入っていないという事が保証できる場合も気にしなくて良い。

    と此処まで修正して気づいたがそもそも nocasematch は adjust-bash-options で
    調整しているなので、ランダムなタイミングで発生する事はない筈なのである。

    何故この様な事が発生していたのかというとユーザーが自分で
    ble/array#insert-before 云々を呼び出したからである。特に custom layer を自
    分で定義して入れる事を提案したのでそれが問題になっている気がする。然し、そ
    うだとしてもその設定は ble.sh の中で呼び出されるべきではないのか。何故変な
    タイミングで ble/array#insert-before が呼び出されているのだろうか。

    改めて各変更について適用するかどうかを選別しなければならない。

    * 取り敢えず util.sh に関してはユーザーが通常の文脈で使用する可能性もあるの
      で簡単に回避できる nocasematch の穴に関しては塞いでおく。ARR から NAME の
      書き換えはそれに含まれるので、類似するものは他のファイルにも適用する。

    * edit.sh での変更は棄却する。ble/textarea#* の関数なので外部で直接使うとは
      考えられない。core-complete.sh の compopt の変更も棄却する。の一時的な
      compopt は ble.sh の文脈の中でしか使わない。

    * ok: keymap.vi に含まれている置換については何れも widget として実行される
      場所で使われているので nocasematch に関しては気にしなくて良い。

    * ble-bind に関しては adjust-bash-options した方が良いのではないか? 然し、
      大体 ble-bind は何度も実行するので余り遅くなるのは嫌である。

      オプション解析を自前で行っているが -d と -D 等を区別しなければならない筈
      →と思って改めて確認してみた所 -d は後方互換性の為に残されているだけだった
      ので現在のインターフェイスでは実は nocasematch であってもオプション解析に
      関しては問題は発生しないはず。

      % 一方で adjust-bash-options にもちゃんとカウントがあるのでカウンターの増
      % 減程度の overhead しかないと言えばない。それよりも寧ろ read-arguments
      % 関連のループの方が重いはずである。という事を考えると
      % adjust-bash-options の呼び出しは無視できるぐらい軽いのではないか。
      %
      % 改めて確認してみると ble/base/.adjust-bash-options と
      % ble/base/adjust-bash-options の二種類があって前者は毎回必ず処理を実行す
      % る物で指定した変数に記録を行う。後者は現在の文脈を見て外側にいる時にの
      % み処理を行うという物である。加えて様々の変数の記録・復元も行っている。
      % 前者は ble/builtin/history で使われている。他の builtin でも前者が使わ
      % れている。というか後者は元々あった状態が分からなくなってしまうので一時
      % 的な待避には使えない。何処かに入れ子レベルをカウントして何かを待避する
      % コードがあった様な気がするが、もしかすると別の処理だったかもしれない。
      % 或いは、その運用は問題があるという事で現在の様なローカル変数を用いる方
      % 法に変更したのだったかもしれない。
      %
      % 6a946f0a7 は .adjust-bash-options の処理を切り離して blehook に対して適
      % 用している。うーん。実際に多くの .adjust-bash-options を追加しているの
      % は 001c59588 である。然し、何れも既存の枠組みを置き換えたという訳ではな
      % くて単に今までなかった物を追加した形になっている。
      %
      % ここでの問題は ble/base/.adjust-bash-options の処理を毎回完全に処理する
      % と遅いのではないかという事である。既に外側で adjust 状態になっているの
      % であれば改めてわざわざ処理をする必要もないのである。
      %
      % a. 例えば ble/base/.adjust-bash-options についても adjust しているかそ
      %   うでないかを記録する変数を定義する? そしてその変数を毎回 local にして
      %   stack 上に記録する? と思ったが local にすると一つ上の階層の記録を参照
      %   できなくなるし、一つ上の階層の状態を引数で渡すとしても事前に別の変数
      %   に状態をコピーして置かなければならない。subshell で unset -v して剥が
      %   すのは重すぎる。という事を考えるとインターフェイス的に良くない気がす
      %   る。
      %
      %   | local set shopt adjusted=$_ble_bash_options_adjusted _ble_bash_options_adjusted
      %   | ble/base/.adjust-bash-options set shopt "$adjusted"
      %   |
      %   | ...
      %   |
      %   | ble/base/.restore-bash-options set shopt "$adjusted"
      %
      %   或いは、local も含めた呼び出しを変数に入れておいて eval させる? 然し、
      %   それだと記録に用いる変数の変数名を指定できない。別々に記録する?
      %
      %   | local set shopt
      %   | builtin eval -- "$_ble_bash_options_declare_adjusted"
      %   | ble/base/.adjust-bash-options set shopt "$adjusted"
      %   |
      %   | ...
      %   |
      %   | ble/base/.restore-bash-options set shopt "$adjusted"
      %
      %   或いは set, shopt という変数名も固定にしてしまって全部文字列で記録す
      %   る?
      %
      %   | builtin eval -- "$_ble_bash_options_adjust"
      %   |
      %   | ...
      %   |
      %   | builtin eval -- "$_ble_bash_options_restore"
      %
      %   これだと毎回 eval する分だけ遅くなるのではないかという懸念もあったが、
      %   実のところ bash は $() に関しては毎回 parse している訳だし、eval の分
      %   だけ処理を省略しても余り速度や効率に影響はない様な気もする。
      %
      %   →と思ったが実際に使用箇所を見てみると意外と set, shopt 以外の変数名
      %   を使っている箇所がある。固定する事はできない? とも思ったが、良く考え
      %   たら set shopt という単純な変数名を使う理由もな
      %   い。_ble_bash_options_set 等長い変数名でも実は良い。或いは
      %   _ble_bash_options_state という名前の配列にしてしまって、3つの値を其処
      %   に全部格納してしまっても良いのである。
      %
      %   | local _ble_bash_options_old_adjusted=${_ble_bash_options_state[2]}
      %   | local -a _ble_bash_options_state
      %   | ble/base/.adjust-bash-options '_ble_bash_options_state[0]' '_ble_bash_options_state[1]' "$_ble_bash_options_old_adjusted"
      %   |
      %   | ...
      %   |
      %   | ble/base/.restore-bash-options '_ble_bash_options_state[0]' '_ble_bash_options_state[1]' "$_ble_bash_options_old_adjusted"
      %
      % b. やはりローカル変数を使うが、呼び出し元で adjust されているかどうかを
      %   チェックして adjust していなかったら local 宣言と共に
      %   .adjust-bash-options を呼び出す様にする。この方法だと呼び出し元が複雑
      %   になり過ぎる気がする。実際に /.adjust-bash-options を呼び出している全
      %   ての箇所でこれを実行する必要がある。また .restore-bash-options をする
      %   かどうかを判定する為に .adjust-bash-options をしたかどうかをまた別の
      %   変数に記録して置かなければならない気がする。
      %
      %   | local set shopt adjusted=
      %   | if ble/base/.adjust-bash-options set shopt; then
      %   |   local _ble_bash_options_adjusted=1
      %   |   adjusted=1
      %   | fi
      %   |
      %   | ...
      %   |
      %   | if [[ $adjusted ]]; then
      %   |   ble/base/.restore-bash-options set shopt
      %   | fi
      %
      %   この方法を取るのであれば a の方法の方が良い。
      %
      % c. 或いは local で被覆されるのが問題という事なのであれば配列にして記録
      %   するというのでも良いかもしれない。然し、その場合には C-c 等で処理が中
      %   断された時に adjust 状態が永続化してしまうという事である。これは致命
      %   的である。local を使った時には何が起こっても local 変数が残留するとい
      %   う事はないので問題にはならなかったが、グローバル変数だとその辺りの処
      %   理もちゃんとしなければならない。
      %
      % * BASH_REMATCH 実装の観察。実際に count 方式で実装して何か問題が起こっ
      %   たのだった様な気もする。然し、それが bash-options についてだったかど
      %   うかは分からない。取り敢えずソースコードを見ると
      %   _ble_bash_BASH_REMATCH_level が見つかる。これの編集履歴について確認し
      %   てみる。689534de で導入されている。うーん。単に BASH_REMATCH の待避を
      %   attach 時に入れ子で行って前に記録した結果が消滅するなどの問題が生じた
      %   からレベルを導入したという事?
      %
      %   ? 何故単に adjusted=1 で判定しないのか? と思ったがこの方法は入れ子で
      %     呼び出される場合に使えない。restore は一番最後の restore の呼び出し
      %     で実際に発生する必要があるが、一番最後である事を判定する為には
      %     count をする必要があるから。
      %
      %   ? この方法だと入れ子カウントが壊れた時に問題になるのではないかと思っ
      %     たが、今のところは問題は発生していない様に思われる。そう思うとやは
      %     り別にカウント方式でも大きな問題にはならないのかもしれない。
      %
      % * ble/base/xtrace/adjust も呼び出し毎に記録していて一番外側にいる時にだ
      %   け処理をする様な実装になっている。然し、restore が実行されなかった時
      %   などの例外的な状況には対応していない様に見える。
      %
      % どうにも判定しづらいのでそれぞれについて使用例を考えて使いやすさについ
      % て考える事にする。
      %
      % d. よく考えたが各 frame で adjusted かどうかを記録しておく必要はない気
      %   がする。何故なら一番外側以外は adjusted だから。という事を考えると、
      %
      %   | local set shopt
      %   | local _ble_bash_options_adjsut_level=$((_ble_bash_options_adjsut_level+1))
      %   | ble/base/.adjust-bash-options
      %   | ...
      %   | ble/base/.restore-bash-options
      %
      %   で良いのではないかという気がしてくる。何れにしても呼び出し元は書き直
      %   さなければならないし、また複雑である。やはりマクロにしなければならな
      %   いのだろうか。
      %
      %   この方法は単純に level++ level-- するよりは安全である様に思われる。一
      %   方で色々宣言しなければならなくて大変である。或いは以下の様にしてしまっ
      %   ても良いのかもしれない。
      %
      %   | local _ble_bash_shopt_state=$_ble_bash_shopt_state
      %   | ble/base/.adjust-bash-options
      %   |
      %   | ...
      %   |
      %   | ble/base/.restore-bash-options
      %
      %   今まで local set shopt としていたのが上の様に自己代入する形に変化する
      %   だけである。また set shopt に当たる変数を _ble_bash_shopt_state を配
      %   列に昇格して記録してしまう事にすれば問題ない気がする。
      %
      % うーん。d の方針で実際に書き換えを実施してしまう事にする。
      %
      % ? 懸念は今まで使い分けていた set shopt と _ble_local_set
      %   _ble_local_shopt と _ble_trap_set _ble_trap_shopt である。これらが衝
      %   突する可能性はあるだろうか。先ず、set と _ble_local_set に関しては実
      %   は後者に統一して良い筈である。というのも set というのは外部から変数名
      %   を受け取る関数としては変数名の衝突の可能性があるから避けたくて、それ
      %   で _ble_local_set を使っているだけの筈だからである。特に set と
      %   _ble_local_set が両方とも local だったとしてどちらかを使い分けたり区
      %   別したりする様な事はない筈である。_ble_trap_set についてはもう少し複
      %   雑になる様な気もするが、考えてみれば ble/base/.adjust-bash-options は
      %   現在の使い方だと必ず外側で宣言した変数をそのまま参照するだけであって、
      %   それ以外の文脈で待避された変数を参照する事はない。という事を考えると、
      %   ローカル変数に関してはこれらの変数名の選択にはそれ程の意味はないはず
      %   なのである。単に他のユーザーが使っている変数名と衝突さえしなければ良
      %   い。
      %
      % ? もうひとつの衝突の可能性に関してはグローバルに保存している状態とロー
      %   カルで管理している変数で変数名を共有して良いのかという事である。先ず
      %   ble/base/.adjust-bash-options を自身の処理の為に使っている諸々の関数
      %   については、必ず自身から抜ける際に .restore を呼び出すので問題ない。
      %
      % x restore に失敗した場合 (restore が呼び出されなかった場合) に何が起こ
      %   るか?
      %
      %   現在の実装だと restore に失敗した時にその状態が持続してしまって問題に
      %   なるのではないか? つまり状態が解除されているのにも拘わらず
      %   _ble_bash_shopt=0 という状態になっているので、次の呼び出しで restore
      %   を実行しなければならない状況であっても restore が実行されないという事
      %   になるのではないか? と思ったが、そもそも次のチェックポイントに到達す
      %   る為には adjust が来てから restore が来なければならない。adjust が来
      %   た時点で adjust 状態になっている事を期待するからその時点で解除するの
      %   は変である。その後で restore を実行すれば良い。と思ったが、ここで問題
      %   になるのは記録された set/shopt 状態が誤った物になるという事である。結
      %   局 "restore し忘れた状態" を記録してそれを復元してしまうので本来の状
      %   態は失われてしまう。ローカル変数に記録していた時点で消えてしまうので
      %   ある。然し、それを言い出すと以前の実装でも同じ問題はあった。元々の状
      %   態をローカル変数に記録しているのでそれの復元に失敗した時点で元々の状
      %   態は失われてしまう。
      %
      %   うーん。でもグローバルの状態に関してはグローバル変数に記録していたの
      %   で復元に失敗した時点で消えている訳ではない。問題は次に adjust した時
      %   にそれが上書きされて消滅してなくなるという事である。
      %
      %   うーん。そもそも現在の様に呼び出し毎にちゃんと状態を記録して解除する
      %   というデザインになっているのは builtin 関数たちはユーザーが自分のコー
      %   ドで呼び出すからである。なので、その時その時の shopt/set の状態を記録
      %   したい。そしてそれは ble.sh がグローバル状態として記録する物とは違う
      %   かもしれない。そういう意味で記録する変数の変数名を変えていたのではな
      %   かったか。と思ったが、もしそれが目的だとしたらやはり変数名は同じでも
      %   良いのではないか?
      %
      %   ble.sh 文脈の中ではユーザーは勝手に set だとか shopt を変えないと期待
      %   している。但し、一時的に (関数内で) set shopt を変更してから builtin
      %   を呼び出す可能性があって、それで問題が起こる可能性がある? それに関し
      %   ては現在の実装で対応できている。一方で restore に失敗した時に何が起こ
      %   るのかは分からない。例えば C-c によって全 stack の状態が失われた時に
      %   どの様にするべきか。先ずシェルの状態は内側の adjusted 状態で残る。
      %
      %   a もしこれが ble.sh 文脈だった場合にはグローバル変数に状態が記録され
      %     ているので、それを使って復元ができるのではないか? 次に adjust が呼
      %     び出された時点で adjust が行われているかどうかを判定して既に行われ
      %     ている様であれば何もしない。_ble_bash_shopt には元々の値を代入する?
      %     然し内側だと _ble_bash_shopt の元の値というのは分からない。
      %
      %   b これがユーザー文脈だったとしたら C-c 等のトラブルが起こった場合に中
      %     途半端な状態で残ってしまうのは仕方がないと思う事にして良い気がする。
      %     通常の builtin だったらそんな事は起こらないが、そもそも C-c にしろ
      %     何にしろ中途半端な状態で中断して何か変な状態になった場合は仕方がな
      %     い気がする。
      %
      %   何れにしても上の 2 つの項目は今までの実装でもそうだった。今回の実装で
      %   特に新しい問題として発生する訳では無い。
      %
      % ? 元々 ble.sh の文脈の中でも nocasematch だとか set -uvx だとかを勝手に
      %   変更した時に問題が発生しない様にこの様な設定にしたのではなかったか?
      %   と思ったが、考えて見るにその様な状況は考えにくいしもし敢えてその様に
      %   設定するのだとしたら影響範囲が最小限になる様にその場で注意する筈であ
      %   る。寧ろ、set -vx を設定した場合には builtin の内部にも伝播していく事
      %   を期待するのではないか? なので気にしなくて良い? やっぱり期待する実装
      %   が良く分からない。
      %
      %   うーん。set -vx に関しては良いが set -eu に関しては実際にスクリプトが
      %   停止する原因になり、かつ ble.sh の文脈の中であってもユーザーが一時的
      %   に有効にする可能性はあるからやはりちゃんと待避しておく必要がある様に
      %   思われる。そう思うとやはり ble-bind であっても毎回
      %   adjust-bash-options による待避を実行しなければならない気がする。

      結論としては builtins で個別に毎回 adjust-bash-options をしていたのは、ユー
      ザーが内部で一時的に set -ue を実行して builtin 等を呼び出した時に ble で
      実装した builtin が失敗するのを防ぐ為である。その為、一番外側で adjust は
      既にしているから内部では adjust/restore はしないという実装にはできない。
      なので処理の省略は行わない。

      また、restore に失敗した時にどうなるのかに関しては現在の実装では其処まで
      考えていない。restore に失敗したのであればその時点で状態が変わってしまっ
      ても仕方がないと考えて、また、各 builtin は自身が呼び出された時の状態をちゃ
      んと復元するという事に集中している。ユーザーコマンドの文脈に関しては、先
      ず C-c は ble.sh が封じているのでそれで完全に restore 処理が抜けてしまう
      という事は考えにくい。ちゃんと一番外側の restore は発動する様になっている。

      今回の ble-bind に関しては

      a nocasematch の待避だけ考える? set -eu 等に対する対策がちゃんとしている
        のかは確認する必要がある、と思ったがそもそも今まで何も待避していなかっ
        たのだからちゃんと対策はされていると考えるべきでは?

      b 或いは nocasematch が設定されていたとしても動く様に設計する? 今の実装だ
        と D を deprecated な d の試験よりも先にテストしているので、deprecated
        behavior が誤って先に出てくる事はない。

        と思ったが更に入れ子で呼び出している関数全てに nocasematch が適用される
        事を考えるとやはり現実的でない気がする。全ての関数で nocasematch に左右
        されない実装になっている事を確かめるのは大変だし、一回それを確認したと
        しても全ての関数について将来的な変更でそれを毎回忘れずに確認するのは困
        難である。という事を考えるとやはり少なくとも nocasematch は調整する必要
        がある。

      c 或いはやはり ble/base/.adjust-bash-options を呼び出して環境に問題がない
        という事を保証した上で実行するべき? 実際に待避しているものは
        nocasematch だけではない。動作に関係しそうな物が幾つもある。 -k は影響
        が大きいし、+B もブレース展開を色々な所で使っているので危ない。実際にそ
        の様な破壊的な設定にする人がいるのかは分からないが。

      d 或いはそもそも変な環境で実行しているの悪いのだと突っぱねるのが良いのだ
        ろうか。

      e うーん。ble.sh 文脈の内側か外側かで振る舞いを変更するというのも手かもし
        れない。つまり、_ble_bash_options_adjusted が設定されていたらわざわざ待
        避などはしないという事。ble-bind は builtin ではないのでユーザーが無闇
        に使う事を想定しなくても良いのではないかという事。と思ったが、ユーザー
        が勝手に ble.sh の処理の内部で set -eu 等を設定してその上で ble-bind を
        呼び出すという事もあるのではないか? その場合に設定を待避しない事によっ
        て誤作動が起こったらどうするのか? やはり毎回待避・復元を実行するべきだ
        ろうか?

      分からないので overhead について確認しておく事にする。速度を測ってみる。

      - 何もせずに adjust/restore をするのに 200-250us かかる。ble-bind -P | wc
        とすると 2500 項目ある。例えば 2500 回呼び出すと 625ms の余計な時間がか
        かる事になる。

      - ble-bind を実際に読み出すと -f Q という単純な keyseq の場合には
        adjust/restore なしの時には 500us で adjust/restore すると 670-770us に
        なる。遅延は 170-270us ある。2500 項目における overhead は 425-675ms で
        ある。

      - ble-bind -f 'C-x q' self-insert の様な2文字の keyseq の場合には
        adjust/restore なしの時は 570us で、adjust/restore ありでは 740-840us
        である。overhead に関しては -f Q の時と全く同じである。

      また nocasematch だけを保存・復元した場合についても確認する。段々複雑になっ
      てきたので表にまとめる事にする。

        |           | なし  | nocasematch    | adjust/restore    |
        |:----------|:------|:---------------|:------------------|
        | "Q"       | 500us |  500-540us     |  670-770us        |
        |   遅延    |       |  +0-40us (8%)  |  +170-270us (54%) |
        | "C-x q"   | 570us |  570-630us     |  740-840us        |
        |   遅延    |       |  +0-60us (11%) |  +170-270us (47%) |

      うーん。数項目ならば無視できる量の様に思われるが大量に定義する場合には
      (例えば 100 項目) 20ms 程度の遅延になる。但し、これはより新しい計算機では
      短くなる傾向にあると思われる。逆に言えば遅い計算機では遅延がもっと顕著に
      なる様な気がする。悩ましい。

      やはり adjust/restore の overhead は大きい。実際に必要になる状況が限られ
      ているというのにちゃんと毎回 adjust/restore するのは割に合わない気がする。
      ble.sh 文脈の中で勝手に nocasematch だとか set -eu して変な処理をするのは
      それが悪いと判断するので良い気がする。

      ∵そもそもそういう事をするスクリプトに限ってちゃんと設定を元に戻してくれ
        るとは限らないし、そうだとすると何れにしても ble.sh は機能不全になるの
        で ble-bind どころの話ではない。

      ∵逆にちゃんと状態の復元をしてくれるのであれば外部フレームワークの関数を
        その特殊な設定のままで呼び出す事に問題があるだろうという事は理解して然
        るべきである。そうでなくても、問題はこちらの側にあるのではなくて呼び出
        し元の特殊な環境設定にあるという事は理解してもらえるだろう。

      という訳で e の方針で実装する事にする。

    * ble/widget/display-shell-version は特別にユーザーの環境を質問する為に実行
      してもらっているので、adjust は必要である。ble-bind と同様の対策をする事
      にした。

      ? reject: と思ったが、実は adjusted の状態に関係なく常に adjust しても良
        いのでは? と思ったが、でも通常の文脈では直接呼び出そうとは思わないし、
        元々 widget としては何の adjust も実行していなかったのだから、今さら
        ble.sh 文脈の中でも adjust を実行するという必要もない。なので、やはり
        ble-bind と同様に adjusted の外にいる時にだけ .adjust を実行する事にす
        る。

    * ble-color-setface, ble-color-defface, ble-face についても同様に対策を加え
      た。何れも ble-bind と同様に [[ $_ble_bash_options_adjusted ]] のチェック
      を入れたが入れ過ぎかもしれない。とは言いつつもしやはり冗長だと思うのであ
      ればまた後で修正すれば良い。ble/base/.adjust-bash-options の呼び出しは少
      ないし、特に [[ $_ble_bash_options_adjusted ]] のチェックを入れている行は
      簡単に検出できるので後で入れ替えるのは簡単だろう。

    ? no: もしかして restore-bash-options は source .blerc よりも前に行われる可
      能性?  と思ったが別にそんな事はなかった。ble.pp の最後の最後に呼び 出され
      ている cleun-up の内部で restore-bash-options は呼び出されている。

      →なのでやはり ble.sh の設定を blerc の中に書いている限りは問題は起こらな
      い筈なのである。貰った設定を見る限りは layer に直接介入しているのだから恐
      らく contrib/layer/pattern.bash の設定を使ってみたという事なのではないか
      という気がする。その説明は contrib/layer/pattern.bash の中にコメントとし
      てある。其処ではちゃんと blerc と書いている。その他には特に設定は書いてい
      ない。

    * 他にも ${var#pat} 等に於いて nocasematch の影響が出てきそうな気もするが、
      調べだすと再現がないので取り敢えずは考えない事にする。

      うーん。実は ble から呼び出している ble-update, ble-reload, bleopt,
      ble-sabbrev, ble-palette 辺りも本当は shell options を待避しなければなら
      ない気がする。これは独立した項目として残す事にする。

    --------

    jkemp814 からの返事がないので、そもそもどういう状況で問題が発生しているか分
    からない。取り敢えず jkemp814 の設定の再現を試みる。どうも pattern.bash を
    使っている気がするので、それに関する設定を探してみる事にする。

    https://github.com/akinomyoga/ble.sh/discussions/362 で例示されている。例え
    ばこれを omb と一緒に組み合わせて使ったら何か問題が発生するだろうか。確認す
    る。取り敢えず pattern の設定を直接 bashrc に記述したら問題は再現した。

    x ok: また、対策を施した ble.sh で試しても未だ別の問題が発生している。と思っ
      たが今回対策を行ったのは util.sh にある一般 utility だけである。つまり、
      pattern.bash 自体には対策していない。更に対策するつもりもない。

      これは気にしない事にする。

2023-12-06

  * reject: 自動アンインストール機能? (motivated by BeastOfCaerbannog) [#D2091]
    https://askubuntu.com/questions/1493857/powershell-like-history-auto-suggestion-for-bash

    これは毎回確認を取ってから削除していくのが良い気がする。

    アンインストールのスクリプトは独立したファイルであるべき? でも ble.sh 自体
    を開きながら bash が処理すると考えれば途中で unlink してもちゃんと動く筈。

    と思ったが実装するのは結構面倒そうな気がする。

    x 先ず初めに複数の場所に ble.sh がインストールされていてその内の一つだけを
      削除したいという時にどうすれば良いのか? 何処にあるのかも分からない他の
      ble.sh のコピーを見つけるのは困難である。という事を考えると現在の ble.sh
      コピーに関連する物だけを削除するしかない。

      ユーザーに尋ねるとしてもユーザーは尋ねられれば、他の ble.sh コピーに関係
      なく削除しても良いと勘違いする可能性もある。

    x また state 等の情報に関しては勝手に削除しない方が良い様に思われる。ユーザー
      自身が記述した設定に関しても勝手に削除する訳にはいかない。.bashrc の中の
      記述を勝手に修正するのも困難だし不自然である。結局勝手に削除しても良いと
      思われるのは ble.sh 本体のディレクトリとキャッシュディレクトリと tmp ディ
      レクトリである。

    結局 ble.sh 本体のディレクトリを削除する事ぐらいしか安全に自動化できない。
    インストールディレクトリを検出するぐらいならできるかもしれないが、堅牢に検
    出できるかわからないしそれ程便利でもない様な気がする。

    取り敢えず README は更新した。

  * wiki,blerc: TAB で auto-complete を確定させる方法 (motivated by TehFunkWagnalls) [#D2090]
    https://www.reddit.com/r/fishshell/comments/17xn8zs/comment/kbsrm2e/?utm_source=reddit&utm_medium=web2x&context=3

    blerc.template には追記した。一方で wiki の方にはそもそもそういう事を書いて
    ある記事はない。Edit の中に例として記述するべきか? Vim 関連に関しては vim
    editing mode 用の記事に書かれている。そもそも Edit は Manual の一部なので具
    体的な設定の例を載せるのも変な気がする。だとすれば新しい記事を作るべきだろ
    うか? というか Q&A の頁があった気がする。Q&A のページに書き加えた。

    ? 同時に Q&A にある設定例が blerc に反映されているか、及び逆はどうなのだろ
      うか。確認してみると共有されている物は一個あったがそれ以外は全く共有され
      ていない。

      Q&A には複雑な物も含まれているので全てを blerc.template に転記するのは適
      切でない気がする。取り敢えず RET で accept-line にするのは転記した。他は
      blerc.template に入れる程のものでもない気がする。

      一方で、blerc.template に含まれている物で Q&A に載せたら良さそうな物はあ
      るか? →一つ転記した。一方で magic-slash 及び magic-space の無効化に関し
      てはそういう Q&A がそうそう出てくるとも思えないので取り敢えずは転記しない
      事にする。

  * make: termux 内部でビルドできない (reported by rashil2000) [#D2089]
    https://github.com/akinomyoga/ble.sh/issues/374

    最初再現しなかったが pkg update を実行したら再現する様になった。背景: そも
    そも gawk を入れたら pkg 的には 5.3.0 になっているのに type で見つかる gawk
    は 5.1.1 になっているという矛盾があって、pkg info -a gawk としてみたら何故
    か2つのパッケージがインストールされているという状態になっていた。それで pkg
    update を実行したら無事に gawk 5.3.0 だけになった。

    具体的に termux の中の make の中で変数にどういう値が入っているか確認してみ
    た所、"type -p gawk" の実行結果としてエラーが出力されていた。どうやら sh が
    何が別の物になっていて type -p gawk を認識していない様だ。エラーメッセージ
    を見ると dash で実行した時と同様のエラーが発生している。

    ? ここでの疑問点は sh が dash な他の環境では今まで問題が発生した事がないと
      いう事である。自分で試してみた時も問題はなかったし、また、他に報告を受け
      てもいない。巷の話題にも挙げられていない。さすがに Ubuntu でビルドに失敗
      していたら誰かが書き込みをしている筈である。dash が使われる為の条件が何か
      あるのだろうか。

      例えば GNU make 自体が bash が見つかる場合には自動的に bash を使うのかも
      しれない。然し、/usr/bin/bash に見つからなければ /bin/sh を使うという事な
      のかもしれない?

      →恐らく Ubuntu には既定で which が存在するので先に which が実行されて
      type -p の方には行っていないという事の気がする。

    * 因みに SHELL 変数は指定されていなかった。とは言いつつ、SHELL は絶対パスで
      指定する物なので、bash の絶対パスが分からない時には使えない。command -V
      も余計な出力を行うので使えない。

    結局直接 bash を指定してコマンドを呼び出す事にした。既存の make_command.sh
    の呼び出しと同様である。

    ? which を使っているが、which こそ POSIX ではないし全ての環境にある訳ではな
      い。と思ったが上記の様に Ubuntu の様な例もあるので現状の通り which を最初
      に試みるというので問題はないだろう。

    因みに https://github.com/starship/starship/pull/4902 については気づいてい
    るだろうか。

2023-11-22

  * complete: 'x?' に対する補完設定読み取りに失敗する (reported by maheis) [#D2088]
    https://github.com/akinomyoga/ble.sh/issues/371#issuecomment-1820927585

    complete -p の出力の解析に失敗している。

    ? reject: というか bash-5.2 以降では普通に eval すれば OK なのでは?

      と思ったが解析コードを書き直すのが面倒なので既存のコードをできるだけ使う
      事にする。

      過去の記録を見ると #D1535 で議論している。この時には 5.2 は未だ登場してい
      なくて 5.1 以下の振る舞いについて纏められている。5.2 では更に振る舞いが変
      わった (というか patch を送った気がする) ので、それに応じて修正が必要とい
      う事。

    現在の処理では末尾のコマンド名を削除してから文字列的に -F の引数を抽出する
    形になっているが、先ず、末尾のコマンド名の削除に失敗しているのでコマンド名
    が -F の引数の中に混入している。更に、-F の引数の quoting が削除できていな
    い。bash-5.2 以降では -F の引数やコマンド名も quote される様になったので実
    は単純に eval すれば良い。

    x ok: 更に関数定義の途中でもエラーが発生する。"x?() { echo [TAB]" 等を実行
      している途中で以下のエラーメッセージが出る。

        bash: _minimal 'x?()': コマンドが見つかりません

      これも実は上の修正で直った。

  * 2022-06-14 eterm: Emacs に実装されている M-x term 若しくは M-x ansi-term [#D2087]

    端末実装が色々滅茶苦茶である。infocmp にて対応している事になっている機能で
    も振る舞いが変である。

    * 先ず、IL, DL は行の途中で実行するとおかしな事になる。IL はその位置に改行
      を挿入して行を2つに分ける機能を持っている。DL は一方で emacs 内部で C-k
      をするのと同じ機能である。即ちその位置以降の文字列を消去するか、行末にい
      る場合には次の行と結合する。これは一応行頭に移動すれば問題ない気がする。

    * RI に関しては端末の一番下にいる時に全体を scroll down し、端末の一番上に
      いる時には何も実行しない。

      > diff --git a/lib/init-term.sh b/lib/init-term.sh
      > index d49cee5f..57f660e3 100644
      > --- a/lib/init-term.sh
      > +++ b/lib/init-term.sh
      > @@ -102,7 +102,9 @@ function ble/init:term/initialize {
      >    ble/init:term/define-cap.2 _ble_term_ind $'\n' ind:sf # $'\eD'
      >    ble/init:term/define-cap   _ble_term_ri  ''    ri:sr  # $'\eM'
      >    ble/init:term/define-cap   _ble_term_cr  $'\r' cr:cr
      > -  if [[ $OSTYPE == msys && ! $_ble_term_CR ]]; then # msys-1.0
      > +  if [[ ${TERM%%-*} == eterm ]]; then
      > +    _ble_term_ri=
      > +  elif [[ $OSTYPE == msys && ! $_ble_term_CR ]]; then # msys-1.0
      >      [[ $_ble_term_cr ]] || _ble_term_cr=$'\e[G'
      >      if [[ $TERM == cygwin ]]; then
      >        [[ $_ble_term_ind == $'\eD' ]] && _ble_term_ind=$'\n'

      2023-11-13 改めて試してみたら RI は動く様になっていた (GNU Emacs 28.2)。
      然し、二回連続で実行したりすると振る舞いが変だ。例えば以下のコマンドの結
      果が他の端末と異なる。他の端末では [1]..[4] が階段状に表示されるが、eterm
      の内部では [4] だけしか表示されない。

      $ printf $'\e[H[1]\eM[2]\eM[3]\eM[4]\n\n\n\n'

      取り敢えず再び RI は有効化する。

    * 2023-11-13 bracketed paste がちゃんと動かない。解除コードが認識されていな
      い? 手動で ESC [201~ を入力するとまた制御が戻ってくる。

      もっと調べてみるとどうやら bash の側の時点で \e[200~ や \e[201~ を受信で
      きていない様だ。emacs の側で処理していて、それがちゃんと処理できていない
      という事の気がする。

      そうすると plain Bash でも動かないのではないか? →実際に plain Bash でも
      問題になるという事を確認した。誰か報告していたりするか? 或いは、contra だ
      けで起こっている可能性もある? → mintty でも同様の問題が発生する事を確認
      した。

      これは emacs の側のバグである。ble.sh の側で bracketed paste を off にし
      ていたとしても \e[200~ が送られてくるので変な状態に突入する。

    未だちゃんと動かない。これは後でちゃんと調べる必要がある。

    2023-11-22 取り敢えず現在は動いている様な気がする。未だ変な振る舞いはあるが
    これらは eterm の側のバグなので気にしない事にする。eterm のバグについては
    wiki の方に纏める事にする。

2023-11-16

  * 2023-09-02 wiki: tmux の外側の端末が取得できていない [#D2086]
    https://github.com/akinomyoga/ble.sh/issues/359

    自分の手元でも問題は再現する。何処かの時点で tmux の振る舞いが変わったとい
    う事なのだろうか。padparadscha の tmux 2.9a ではちゃんと動いている。
    chatoyancy の tmux 3.3a では動いていない。これは tmux version の問題だろう
    か。調べると 3.1, 3.2 では動いている。3.3 の CHANGES を見ていたら
    passthrough sequence を既定で off にしたと書かれている。以下の commit

    https://github.com/tmux/tmux/commit/eabbc80b75ef8e02653c2728d7f646fc6a8f558f

    なので set -g allow-passthrough on にしてもらわないと外側の端末を検出する事
    ができないのである。とは言いつつもし DECSCUSR をちゃんと tmux が外側に伝播
    するのであれば問題は起きないはず。

    * 結局これはユーザーに適切に設定してもらうしか方法はない。wiki に
      allow-passthrough を設定する様に説明を書くしかない。然し一方で何処に書け
      ば良いのかは謎である。端末検出について記述している箇所は今の所ない。
      widget display-shell-version についても単に表内に現れるだけである。tmux
      に対する言及も各項目で必要がある場所で行っているのみである。

      ? reject: うーん。結局 --cursor の箇所で一緒に記述する事にする? と思った
        が問題が起こるのは tmux-3.3 以降であって、一方で tmux 3.4 以降では単に
        cursor-style を指定すれば良くて、tmux 3.3 では allow-passthrough と
        cursor-style を両方指定したとしても結局動かない。

    x と思ったが、どうもDECSCUSR に関しては 3.1でもちゃんと動いていない気がする。
      微妙に外側にカーソル形状変更が伝わっているが一旦ブロックになると元に戻ら
      ない。この振る舞いは遡っても変わらない (2.6 20170830 まで試した)。screen
      の中では動いている。更に 3.3 になると次のコマンドラインに行ってもカーソル
      形状は復元されなくなっている。

      改めて確認してみると screen は DECSCUSR をちゃんと外側に伝播する様である。
      2.9a 及び 3.1 で既にちゃんと伝播している。現在の 3.3a もちゃんと伝播して
      いる。なので気にしなくて良いだろう。

      うーん。現在の実装だと quote-passthrough DECSCUSR '' all でシーケンスを構
      築して外側に送信している気がする。手動で実際に quote-passthrough でシーケ
      ンスを構築して結果を送ってみるとちゃんと正しく DECSCUSR が適用されている
      様に見える。screen も全く同じ筈なのに screen に関してはちゃんと動いている。
      何が問題なのだろうか。

      →何が問題なのか分かった。DECSCUSR(0) を送信すると勝手に tmux が、tmux が
      既定だと思う 1 に変換してしまうのである。0 を指定したらちゃんと 0 として
      記録しておいてそれを外側の term に送信する様にして欲しい物である。

      実装を確認してみたが最初の実装[1]から 0 は個別に取り扱っている様に見える。
      何故現在の実装ではそう振る舞っていない様に見えるのだろうか。因みに
      tmux-1.7 の時点で DECSCUSR に対応していて、おそらく外側の端末にちゃんと伝
      播している。現在の実装の設定部分[2]を見ても0だったらそのまま0になる気がす
      る。改めて tmux の動作を確認するが 3.3a でも 3.1 でもやはり echo $'\E[3
      q' してから echo $'\E[0 q' とすると block カーソルに変化してしまう。一方
      で passthrough させれば contra は 0 に対して事前にユーザーが設定した物に
      リセットする。それでも実装を見る限りは SCREEN_CURSOR_DEFAULT は 0 で
      BLOCK とは区別されているような気がする。

      [1] https://github.com/tmux/tmux/commit/3ea5e06bfb04278fa53885e551bc363a84bad8d1
      [2] https://github.com/tmux/tmux/blob/bdf8e614af34ba1eaa8243d3a818c8546cb21812/input.c#L1639-L1643

      最新の master でも同じ振る舞いである。具体的にソースを弄って内部状態を調
      べてみる。どうも cstyle はちゃんと指定された物になっているが、mode が異な
      る物になっている様である。flag 0x80 が立っている。これは何だろうか。
      0x80 は MODE_CURSOR_BLINKING の様である。

      うーん。分かった。[3] 明示的に s->default_cstyle に書き換えてから更新を行っ
      ている。default_cstyle は何処で設定されているかというと、[4] で
      cursor-style というオプションから設定されている。例えば自分の場合には
      cursor-style を 4 辺りに設定しておけば良い。因みに cursor-style というオ
      プションは[5]を受けて[5]で追加された物で、3.3 からしか使えない。

      [3] https://github.com/tmux/tmux/blob/bdf8e614af34ba1eaa8243d3a818c8546cb21812/tty.c#L760
      [4] https://github.com/tmux/tmux/blob/bdf8e614af34ba1eaa8243d3a818c8546cb21812/window.c#L1660-L1662
      [5] https://github.com/tmux/tmux/pull/2960
      [6] https://github.com/tmux/tmux/commit/57100376cc70739f53a1f8a4bacf192b8cdcd124

      取り敢えず wiki にどの様に設定するべきかについて記述した。

      x fixed: と思ったが cursor-style 4 を指定しても動かない。エラーが出る。
        どうやら underline 等の文字列で指定する必要がある様だ。

      x ok: ちゃんと underline と指定しても動かない。blinking block になってし
        まう。うーん。何が悪いのだろう。やはり cursor-style は関係ないのだろう
        か。

        と思って master の tmux で試してみたらちゃんと動く。うーん。

        試しに自前コンパイルの 3.3a についても動作を確認しておく事にする→動か
        ない。という事は何処かで修正されたという事だろう。仕方がないので bisect
        を手動で行う事にする。bisect したら d9f84854 で修正されていた。どうやら
        単にバグだった様だ。なので実際に動く様になるのは 3.4 以降になる。

      ? no: cursor-style に default (0) を指定する事もできる様になっている気が
        する。然し元々既定で 0 なので default にしても変わらず、結局
        blinking-block になってしまうのだろうか。或いは明示的に 0 を指定してお
        けばちゃんと外側の端末に対して 0 を送ってくれるのだろうか。

        →実際に default を指定してみたが blinking-block になってしまう。これが
        意味する所は結局何処かで 0 はすり変わって1が出力されてしまうという事だ
        ろう。

        うーん。if (tty->cstyle != SCREEN_CURSOR_DEFAULT) という条件が満たされ
        た時にのみ 0 が送信される事になっている様だ。うーん。つまり、0 は決して
        送信されないという事? これはどういう事だろうか? → 確認してみたが完全に
        dead code という訳でもない。何だかよく分からないが深入りはしない事にす
        る。

        何れにしても現在の cstyle が 0 であっても default_cstyle が 0 であって
        も、実際に DECSCUSR(0) が出力される状況はとても限定されているという事。
        特に default_cstyle が 0 の場合には何も出力されずに終わるという事。

      wiki には underline 以外の指定例についても全て載せる事にした。3.3 ではな
      く 3.4 が必要である事も記述した。set -g cursor-style default を指定しても
      駄目な事も記述した。

  * complete: " {," まで入力すると mandb 関連のエラーが表示される [#D2085]

    エラーメッセージは以下の通り

      bash: /home/murase/.mwg/src/ble.sh/out/cache.d/1000/complete.mandb/ja_JP.UTF-8/: ディレクトリです

    これは何処から発生しているエラーだろうか。うーん。調べてみると
    ble/complete/mandb/generate-cache でコマンド名をファイル名として生成したオ
    プション一覧をキャッシュしている。そもそも空のコマンド名に対して補完が試み
    られる理由が分からない…と思ったが "{," でも同様のエラーが発生する様なので
    現在入力している単語がコマンド名だと思われていて "{,}" の展開結果が空文字列
    だから空のコマンド名で mandb が呼びされているという事の気がする。

    x と思ったら今度は BASH_ALIASES にて "誤った添字の配列" のエラーになる。こ
      れらは ble/alias#* 関連について、空のコマンド名についてチェックしてから
      BASH_ALIASES を確認すれば良い。修正した。動いている。

  * complete(kubectl): 補完で hang する。timeout は 32s ある (reported by sebhoss) [#D2084]
    https://github.com/akinomyoga/ble.sh/issues/353#issuecomment-1811985511

    提供された補完設定を確認する限りは cobraV2 による補完設定の様である。実際に
    binary を呼んでいる箇所を conditional-sync に置き換えれば十分だろう。binary
    は words[0] を使って読み取っている。基本的には words[0] を置き換えるだけで
    処理を摩り替える事ができるだろう。実装した。

    動作確認も行った。kubectl に対しては確認していないが gh に対して gh を
    sleep 5 に置き換える事によって遅い時の振る舞いのテストを行った。置き換える
    前はちゃんと動いていて、置き換えた後も補完は動かないが block する事なく入力
    する事ができる。OK

2023-11-10

  * contrib/integration/fzf-git: エラーメッセージが出る (reported by dgudim) [#D2083]

    どうも fzf-git の一部の binding は自身を独立したシェルスクリプトとして起動
    して何か処理を実行しようとする様である。元の fzf-git の repository を見ると
    確かにそういう機能があって、それ自身で呼び出して使っている。使わない機能だ
    と思って勝手に porting をスキップしたのが駄目だった。

    取り敢えずそのままコピーして来て体裁を整える。

    * 序に元からあった部分で自身のスクリプトの位置 __fzf_git を特定するのに使っ
      ている readlink を自前の readlink に置き換える事にした。動いている。

2023-11-08

  * 2023-10-25 M-z zap-to-char に対する試みが help-bash に挙げられている [#D2082]

    ble.sh でも直接対応する事にした。取り敢えずは対応した。

    現状では M-z は fg になっているが悩ましい所である。取り敢えず fg の儘にして
    置いて、自分の手元で使った感じで良さそうであれば置き換える事にする。うーん。
    それならこの commit 自体を devel の中に保持して暫く使うのが良い気がする。

2023-11-01

  * 2023-10-04 ok: complete -I の補完は大丈夫だろうか [#D2081]

    手元で確認した限りだとコマンド名の補完に用いられる様である → 改めて
    core-complete.sh を確認してみたらちゃんと source:command に於いて候補を生成
    する様になっていた。

2023-11-01

  * github: 寄付に関して (requested by gvlassis) [#D2080]
    https://github.com/akinomyoga/ble.sh/issues/367

    よく分からないが取り敢えず設定してみた。

2023-10-29

  * edit: [ble: exit] を off にしたいという要望 (requested by gvlassis) [#D2079]
    https://github.com/akinomyoga/ble.sh/issues/366

    編集し始めて気づいたが似たようなメッセージは他にも沢山ある。[ble:
    detached], [ble: fc], [ble: auto-logout], [ble: reload], [ble: expand] 及び、
    remaining jobs のメッセージもこれを使っている。これらを全て一括で off にす
    るのは明らかに変だ。然し、一方で個別に on/off できる様にするほどの物なのか
    というのも怪しい。

    既に [ble: EOF] 及び [ble: elapsed ...] は設定で変更できる様になっている。

    [ble: exit] は日常で頻繁に起こるという意味で特別だという事で、わざわざ表示
    してなくても良いという考え方もある。そういう意味で exit だけ設定で off にで
    きる様にするというのは手である。

    * それとは別にこれらの mark のスタイルを一括で指定できる方法があっても良い
      かもしれないとは思う。然し、interface は難しい。

      a 全て [ble: %s] に置き換えるとしても、既に設定可能にしてある物についてど
        う取り扱うのかは難しい。単に既定の設定と一致していたら [ble: %s] で設定
        されている物を流用するという形で良いだろうか。

      b 或いは関数で処理させる事にすれば、表示の理由に応じてユーザーは自由に表
        示を有効化・無効化する事ができる。然し、そこまでして設定を変更できる様
        にする程のものなのかという気もする。

        或いは内部的には marker を instantiate する関数として実装しておいて必ず
        その関数を通して実体化する様にする。もしユーザーが本当に一括で変更した
        いのであればその関数を適宜置き換えてもらう事にする。というのが良い気が
        する。

      以前にその様な事を考えた事があるような気がするが取り敢えず note.txt の中
      には記録は残っていない様だ。頭の中で考えただけで記録しなかったという事の
      気もする。

    取り合えず簡単に動作確認を行った。改めて動作確認を一つ一つ確認する必要があ
    る気がする。

    ? edit_marker が空の時の振る舞いについて確認する。

      x fixed: [ble: fc] が空になってしまっている → うーん。fallback の文字列
        がそもそも空になっていて、単に着色しただけになっていた。fallback として
        既定の文字列を指定する事にした。

2023-10-01

  * canvas: Unicode 15.1.0 対応 [#D2078]

    対応してみたのは良いが GraphemeCluster でテストが失敗する様になった。U+924
    がどうも GraphemeClusterBreak では通常文字という事になっているが、test では
    extend であるかの様な振る舞いを要求する様になっている。どういう事だろうか。

    先ず GraphemeBreakProperty.txt に関しては 15.0.0 と 15.1.0 で変化はない。一
    方で GraphemeBreakTest.txt に関しては大幅に追加されている。その中で U+924
    に関しては combining とされている。と思ったが違った。どうも間に挟まっている
    文字が何か新しい規則に組み込まれた様だ? 何やらおかしな property が割り当て
    られている気がする。

    Extend_ConjunctLinkingScripts_ConjunctLinker_ExtCccZwj

    うーん。UAX #29 の変化を調べてみると実は 15.1.0 で新しく色々と追加されてい
    るという事が分かった。これはまた対応に時間がかかりそうだ。

    * InCB=Linker 及び InCB=Extend の直前で切れてしまうのではないか疑惑

      現在の Unicode の定義だとInCB=Consonant | InCB=LinkerEx が離れるし、
      InCB=LinkerEx | InCB=LinkerEx も離れるのではないか?

      或いはちゃんと InCB=Linker や InCB=Extend は Extend でもあるのだろうか?
      generate-table.sh では検出できていないから InCB={Linker,Extend} は何の
      GraphemeClusterBreak も持っていないのではないかと疑われる。ZWJ も
      InCB=Extend に含まれていそうなのに検出できていないのは何故?

      →と思って改めて確かめて見た所、どうやらちゃんと検出して沢山エラーが発生
      していた。改めて確認する必要がある。重複は Extend と ZWJ のみで発生してい
      る。また、全ての InCB=Linker 及び InCB=Extend は同時に Extend または ZWJ
      でもあった。特に ZWJ は InCB=Extend であった。つまり、以下の様な三種類に
      分類する事ができる。

      - Extend (1) InCB=None
      - Extend (2) InCB=Extend
      - Extend (3) InCB=Linker
      - ZWJ        InCB=Extend

    * 結局 GraphemeCluster の中に Indic_Conjunct_Break も埋め込まれた形になって
      しまったので、IndicConjunctBreak のテーブルは最早不要の気がする。

      * 既に実装した分について IndicConjunctBreak を参照しない形に書き換える→
        書き換えた。簡単だった。

      * 本当に GraphemeClusterBreak だけで実装できるのか確認する。実際に実装し
        てみる。

      * 以下はもう使わなくなった IndicConjunctBreak を取得するコード。

        後で使いたくなった時の為に何処かに取っておいた方が良いだろうか。うーん。
        然し、これはほぼ GraphemeCluster/c2break と実装は同じなので敢えて分かり
        やすい所に取って置く必要もない。なので、ここに残しておくだけにする。

        | #%< canvas.IndicConjunctBreak.sh
        |
        | function ble/unicode/IndicConjunctBreak {
        |   local code=$1
        |   ret=${_ble_unicode_IndicConjunctBreak[code]}
        |   [[ $ret ]] && return 0
        |   ((ret>_ble_unicode_IndicConjunctBreak_MaxCode)) && { ret=0; return 0; }
        |
        |   local l=0 u=${#_ble_unicode_IndicConjunctBreak_ranges[@]} m
        |   while ((l+1<u)); do
        |     ((_ble_unicode_IndicConjunctBreak_ranges[m=(l+u)/2]<=code?(l=m):(u=m)))
        |   done
        |
        |   ret=${_ble_unicode_IndicConjunctBreak[_ble_unicode_IndicConjunctBreak_ranges[l]]:-0}
        |   _ble_unicode_IndicConjunctBreak[code]=$ret
        |   return 0
        | }
        |
        | ## @fn ble/unicode/IndicConjunctBreak/get-left str index [opts]
        | ##   @var[ret] InCB 参考特性の値を返します。
        | ##   他は ble/unicode/GraphemeClusterBreak/s2break-left と同じです。
        | function ble/unicode/IndicConjunctBreak/get-left {
        |   local s=$1 i=$2 opts=$3
        |   if [[ $opts != *:code:* ]]; then
        |     local code
        |     opts=$opts:code
        |   fi
        |   ble/unicode/GraphemeClusterBreak/s2break-left "$s" "$i" "$opts"; local ext=$?
        |   ble/unicode/IndicConjunctBreak "$code"
        |   return "$ext"
        | }

    2023-10-02 push してから気づいたが detection を更新するのを忘れていた。

    2023-10-02 更に emoji table についても更新するのを忘れていた。但し、15.0 と
    15.1 には本質的な違いは存在しない様だ。

    2023-10-02 blerc.template を更新する。

    2023-10-02 GraphemeCluster が legacy が extended かで conjunctCluster を処
    理するかどうかも切り替えるべきでは→条件式を追加する事にした。

  * ext/fzf: $() は blink-matching-paren on の時 `` より遅い [#D2077]
    https://github.com/junegunn/fzf/commit/e0b29e437be458066fca4dab39b282dfc11466f6

    という謎情報があるが GitHub のエラーで現在ページが見えない。

    →これは単に fzf の実装が bind マクロを通じて実装されている為に、$() が実際
    にマクロで入力される文字列の中に含まれていると blink-matching-paren on の時
    に bash が sleep を挟んで一致する括弧の highlighting を実行するという話だっ
    た。

    そもそも ble.sh では blink-matching-paren に対応していないし、対応するとし
    ても delay は入れない様にするだろうし、またマクロを通じた実装もできるだけ避
    ける様にしたい (とは言いつつ bash-3.? with ble.sh で fzf key-bindings を使
    おうとすると結局マクロによって文字列を入力する様になる)。

  * canvas: ｼﾞｮﾝ 等の文字列の幅が端末と整合していない [#D2076]

    "ｼﾞｮﾝ" 文字幅が正しく計算されていない。emacs はちゃんと処理できている様だ。
    つまり、規則に従うと濁点は前の文字に吸収される事になっているが実際にはそう
    ではないという事。これは規則の穴として処理するべき事の気がする。

    →実際に ble/util/s2w で計測してみた所、幅3という事になっている。そもそも何
    故そのような事になっているのだろうか。処理を確認する。うーん。grapheme
    cluster として読み取っている。そしてその grapheme cluster の大きさを台字の
    大きさをそのまま返す様にしているのが問題の様である。

    ? そもそも他の端末では正しく実装できているのだろうか (もしくはどの様に実装
      しているのか)

      →うーん。他の端末ではちゃんと濁点も幅を持って描画されるし、論理的にも内
      部では半角の幅を持って計算されている様である。更に言うならば行末での振る
      舞いを見る限りは grapheme cluster としての認識もされていない。

      xterm, terminology, lxterminal で確認した。可能な限り Unicode に書かれて
      いる物をそのまま実装しようとしている kitty ですらも半角カナの濁点・半濁点
      に関しては GraphemeCluster の Extend ではなく独立した文字として行折返し等
      を処理している様だ。

    つまり、そもそも grapheme cluster として取り扱わない様に修正するべきである。
    念の為、濁点がどの様なカテゴリになっているのかについて確認する。
    ble/unicode/GraphemeCluster/c2break の出力を確認すると濁点は
    GraphemeClusterBreak Extend という事になっている。

    [修正方法]

    make/canvas.emoji.sh を確認してみると中で _ble_unicode_GraphemeClusterBreak
    に値を設定しているので、これに倣って値を上書きして良いのではないかという気
    がする。周辺の文字で Extend になっている文字の一覧を見ることができれば良い。
    元にしているデータベースの方を先ずは確認する

    * 元にしているデータの時点で Extend になっている。

    * 半角カナ周辺では濁点と半濁点だけが Extend になっている様に見える。
      FE20..FE2F に combining ligature というのがあるが、これは明示的に前の文字
      を修飾する物なので、半角カナの様な特別な取り扱いは不要である。

      →取り敢えず半角カナの濁点と半濁点だけを修正の対象とする事にする。

    * recjt: もう一つ気づいた事は、元の GraphemeClusterProperty.txt では一緒に
      GeneralCategory も表示していてカタカナの濁点・反濁点は Lm になっていて他
      の Extend と異なっている。或いは、GeneralCategory が L? の時には特別扱い
      して表を修正するという事も考えたがそれはやめておく事にする。

      x 勝手に GraphemeClusterBreak を変更すると他の用途で参照した時に変更され
        たデータベースを参照する事になって混乱の元である。

      x Extend / L? が全て同様の取り扱いで良いのか分からない → と思ったが
        "Extend # L" で検索してみると半角カナの濁点・反濁点しか存在しなかった。
        そういう意味で GeneralCategory と組み合わせて判定しても良いのかもしれな
        い、と思ったがそもそも処置が必要な文字が半角カナしか現状で存在しないの
        であれば、無闇に将来追加されるかもしれない他の Extend # L? にも影響が出
        る様な実装にするべきではない。

    * 因みに make/canvas.emoji.sh の中で多くの端末で例外的な振る舞いとなってい
      る 0x1F3F{B..F} の範囲の文字についても、この際、既定で修正を加える様にで
      きないだろうか。

    2023-10-01 手で弄る様にしたら Unicode の例から自動生成したテストが失敗する
    様になってしまった。将来的な事を考えると端末毎に修正した
    GraphemeClusterBreak を切り替えたりする事なども考えられるので、直接元の
    GraphemeClusterBreak を弄るのも避けるべきだろうか。代わりに
    _ble_unicode_GraphemeClusterBreak_custom という配列に修正した
    GraphemeClusterBreak を記録する事にした。

    x これにより多少 GraphemeClusterBreak を読み取る時間が伸びてしまうのではな
      いかと思うが、ASCII に関しては処理をスキップして効率化しているので余り気
      にしなくても良い気がする。

2023-09-20

  * complete: auto_complete 内容を入力しきっても auto_complete mode の中にいる [#D2075]

    auto_complete 候補が全然ないのに何故か auto_complete mode に入っている気が
    する? 何故? と思って改めて調べてみたが特に enter が呼び出されている気配はな
    い。

    提示された文字列が全てユーザーによって入力された時に auto_complete mode
    から抜ける機能は実装されていないという事だろうか。うーん。然し、既に
    auto_complete mode に入った状態だったのだからそのままでも良い気がする。と
    思って実装を確認したら既に同じ状態になったら自動的に抜ける様に処理してい
    る気がする。と思ったら実装が変だ。修正する事にする。

    これは ble-0.3 にも影響するので独立した項目にしたほうが良い。

2023-09-18

  * layer: pattern で指定する layer に対するリクエスト (requested by johnalotoski) [#D2074]
    https://github.com/akinomyoga/ble.sh/discussions/362

    問題は効率よく実装できるかという事。部分更新ができれば良いが簡単かどうか分
    からない。

    また、一個のパターンもしくは有限個のパターンしか登録できないのは困る。

    a 一つの layer で一つの pattern という事にして複数のlayer を登録する事を想
      定するとますます遅くなる様な気がするし、またパターンを増やす毎に layer 定
      義の clone をしなければならくなり、また記録対象に関しても prefix 等を使っ
      て load/store しなければならくなり効率が悪くなり、管理が面倒になる。

    b 一方で、一つの layer で複数の pattern に対応しようとすると実装が複雑にな
      る。結局合成の処理は実装しなければならないし、部分更新を考えるのだったら
      結局各 pattern について前回の一致を記録する必要がある。そうでなくても全部
      記録してそれから調べるという事になる気がする。

    またどうせ実装的には region の複数 region 対応と同じ様な実装になる様な気が
    するので実装を共有する事ができる様な気がする。multi-range 的な base layer
    として実装するのが良い気がする。だとすれば結局 store/load 的な事はしなけれ
    ばならないので a の方針でも良いのではないかという事になってくる。

    但し、実質的に a 的な実装になるとしても layer の配列に登録するのが面倒とい
    う事を考えると b 的な内部インターフェイスにするというのは可能性としてありで
    ある。その場合には複数 layer をまとめる機能として実装するのか sublayer 的な
    物として実装するのか区別するのが良い。

    * 入れ子の配色パターンを指定したり、一致の仕方によって色を切り替える事がで
      きるようにしたり、より高度な指定を考えることはできるだろうか。

      これを突き詰めていくと実質 parse に近い事ができてしまう様な気もするが、そ
      うなった場合既存の構文解析の実装とどちらの方が良いのかという事にならない
      か? と思ったが、さすがに既存の構文解析の方は無限の階層を作ることができる
      し (単なる正規表現ではできない) 効率に関しても single pass (既存) と
      multi pass (入れ子着色) なので既存の方法の方が速いだろう。

    取り敢えず region の実装をコピーして観察してみるのが良い気がする。と思った
    が、今回実装しようとしているのは部分更新も必要になってくるので単に region
    の実装を一般化するだけでは全然足りない。やはり一から実装し直した方が良いの
    ではないかという気もする。

    ? うーん。正規表現を採用している限りは部分更新は不可能なのではないか。例え
      ば a(.{9}x)? というパターンに対して、前回の文字列が a2a4a6a8a0z だったと
      すると (0-1 2-3 4-5 6-7 8-9) という一致になる。z を x に書き換えると
      dirty range は 10-11 だけであるが、最終的な一致は (0-11) にならなければな
      らない。つまり、dirty range が幾ら後ろの方にあったとして、既に確定してい
      る一致が幾つあったとしても、それらを上書きする形で新しい一致が現れる可能
      性を常に排除できない。

      正規表現の表現能力が高すぎるからだろうか。先ず、extglob の時にも同様の事
      が当てはまる。

      glob (extglob なし) の時にはどうだろうか。* の最長一致を考える事にすると
      やはり問題は起こる気がする。但し、複数のパターンを跨いで遡らなければなら
      ないという事はない。単一のパターンしか考えていないのであれば。然し、今後
      の拡張性などを考えると単一の単純 glob パターンだけで着色を行うというのは
      制限が大きすぎる。それにそんなに便利そうではない。

      glob の最小一致という事にしておけば一度確定した一致は内容が変わらない限り
      は安定である。これに関しては複数パターンを組み合わせたとしても論理的な問
      題は生じなさそうである。一方で、複数パターンを組み合わせた実装にする為に
      は「各位置についてそれぞれパターンを試して行く」か「全てのパターンについ
      て最近接で次に現れる位置を計算して一番近い物から順に適用していく」などの
      実装を行う必要が出てくる。前者は重すぎて駄目であり、後者は余りに複雑であ
      る。

      などの事を考えると、表現力においても実装の複雑さや効率においても、正規表
      現を使うのが妥当と思われる。部分更新を諦める必要はあるがその方がすっきり
      して良いのかもしれない。

      取り敢えず単一正規表現の場合について考えれば良い。毎回先頭から末尾まで正
      規表現で範囲を抽出する事にする。

    * done: 先ずは着色範囲を決定する必要がある。

      取り敢えず実装した。着色範囲を決定したら後は region を拡張する形で実装し、
      一般化も行った。と言っても region との違いは各 selection に色を割り当てら
      れるという事と、複数の selection が接している可能性があるという事。然し、
      それだけだと速度的に遅くなってしまうかもしれないので、範囲決定について複
      数 selection がある場合でもちゃんと各要素について検査する様にした。

      動いている気がする。region も新しい枠組みの方に乗り換える事にした。少し修
      正した。ちゃんと動いている気がする。

    * done: later:{pattern} として実装した。これを呼び出して使う様にすれば良い。

    * done: _ble_highlight_layer__list は _ble_highlight_layer_list に改名する。

    * done: 使い方を簡単に base.pattern.bash の中にも記述する。例を config の中
      に入れようかとも思ったが単純すぎるのでわざわざ登録する程でもないだろうか。

    * done: base.pattern.bash から pattern.bash に変える

      {pattern} という名前にしたがこれを継承して新しい layer を定義するという訳
      でもないから pattern にした方が良い? と思ったが、ユーザーからは見えないだ
      けで内部的にはこれから派生した layer を自動的に定義している。そういう意味
      で {pattern} という名前は OK。

      一方でファイル名が base.pattern.bash になっているが、これについては
      pattern.bash で良いのではないかという気がする。ユーザーが明示的に自分で派
      生する事は想定していないのだから。

    * done: うーん。zsh syntax highlighting の highlighter を見たら pattern が
      glob で regexp が正規表現を使った物である様だ。なので regexp に改名するべ
      きではないだろうか。一方で glob を用いた実装についても考える余地がある。
      但し、glob を用いた物は単に正規表現に変換して適用すれば良いだけの気がする
      が。

      https://github.com/zsh-users/zsh-syntax-highlighting/tree/master/highlighters
      https://github.com/zsh-users/zsh-syntax-highlighting/tree/master/docs/highlighters

      glob に関しては最長一致と最短一致の二種類が考えられる。色々考えると実装は
      似た様な物になるだろうし一緒に実装してしまった方が良い気がする。

      →結局 {pattern} で regexp/glob 全てに対応する事にした。

    * done: 現在の実装だと regex を追加した順序が保たれないのではないか→これは
      修正した。独立した配列に順番に記録する。

    * done: auto_complete で仮挿入されている物に対してまで着色パターンが適用さ
      れている。仮挿入部分に対しては一致するべきではないのではないか。仮挿入部
      分を削除した物に対して選択範囲の決定を行って、その後で sel の中身を修正す
      る事にする。

      と思ってその様に実装してみたら更新されない事がある。どうやら
      auto_complete で予想された内容と同じ内容しか入力していない場合には DMIN<0
      になるので処理がスキップされてしまう。処理は前回の text の内容と一致する
      時にのみスキップするべきなのである。その様に実装した。

      →前回の text を記録していて問題になる可能性はあるか? もしそれで問題にな
        るのであればその他のあらゆる情報の記録で問題が発生する可能性がある気が
        するので気にしない事にする。

    * done: やはり /initialize-vars と /declare は分離するべきでは?
      /initialize-vars で VARNAMES がクリアされてしまうのは都合が悪い。といって
      毎回全て構築するのも無駄な処理の気がする。

2023-09-17

  * memo: テストに使用した bashrc を独立させる [#D2073]

    色々の試行錯誤が bashrc の中に溜まっていくが後で参照する為に、各議論項目に
    対応する bashrc を残したい。各番号に割当を行う事にする。

    また一つの番号で複数ファイル memo/ 以下にあるものについてはまとめたい。二つ
    だと微妙だが三つ以上は全部まとめる事にする。note.txt や done.txt の中に参照
    がある場合にはそれも更新する (といってもほんの少ししかなかった)。

  * global: make scan したら問題が沢山出ている [#D2072]

    久しぶりに実行したら問題が沢山あるので修正する。今まで test-*.sh を検査の対
    象にしていなかったのを含めたのが原因の一つである。ble/test に指定しているコ
    マンドの中では builtin の使用に対するチェックを省略する事にした。他に累積で
    様々の見落としができていたので修正した。

  * github: windows-latest で CI テストが失敗する問題 [#D2071]
    https://github.com/akinomyoga/ble.sh/pull/363 test

    symbolic link の振る舞いが変わってしまっている。手元の mingw を更新して振る
    舞いを確認してみることにする。msys2 で pacman で最新版に更新する。エラーは
    発生しない。という事は github のテスト環境だけで起こる問題なのだろうか。

    * それとは別に interactive session で ble check bash すると履歴展開の振る舞
      いで結果が異なる事に気付いた。これについても修正しなければならない。
      interactive session と外で history -p の振る舞いが違うのだろうか。

      $ export q=\' line='$'$q'\'$q'!!'$q'\'$q
      $ bash -Hc 'builtin history -s histentry; builtin history -p "$line"'
      $'\'!!'\'
      $ bash -c 'builtin history -s histentry; builtin history -p "$line"'
      $'\'histentry'\'
      $ (set -H; builtin history -s histentry; builtin history -p "$line")
      $'\'!!'\'
      $ (set +H; builtin history -s histentry; builtin history -p "$line")
      $'\'!!'\'
      $ builtin history -s histentry; builtin history -p "$line"
      $'\'!!'\'
      $ set +H; builtin history -s histentry; builtin history -p "$line"; set -H
      $'\'!!'\'

      よく分からないが -H のコマンド実行の時にだけ問題が生じる様だ。他の文脈で
      は -H をつけても外しても問題の振る舞いは見られない。

      更に別の version も調べてみたら振る舞いは色々の様だ。

      bash -c xxx  3.0 展開失敗; 3.1..dev 展開
      bash -Hc xxx 3.0 展開失敗; 3.1..4.0 展開, 4.1..None
      (xxx)        3.0 現在コマンドに展開; 3.1..4.0 展開; 4.1..None
      (set +H;xxx) 3.0 現在コマンドに展開; 3.1..4.0 展開; 4.1..None

      xxx = builtin history -s histentry; builtin history -p "$line"

      Note: bash -c '(xxx)' および bash -Hc '(xxx)' はそれぞれ () のない場合と
      振る舞いは同じだった。

      然し、この振る舞いは現在観測している振る舞いと一致していない? と思ったが、
      スクリプトとして実行する場合にはちゃんと動いているというという事はスクリ
      プトとして実行している時は bash -c と一緒の振る舞いということで、これは自
      然である。一方で、ble session で ble check した時に失敗するのは ble
      session の中では常に展開されずに !! のままだということで、これも
      consistent である。

      さて、この振る舞いの違いが何処から来るのかについて確認したい。単に
      interactive かどうかで判定するだけでは駄目である。 bash -Hc の時にも振る
      舞いが変化する。逆に set +H の時に振る舞いが変わるという訳でもない。シェ
      ルかサブシェルかでは切り替わらない様に見える。今の所分かっている条件は i
      も H もない場合にのみ 4.1..dev で展開が発生する。

    [原因]

    | GitHub の blesh-test repository (private) を使ってまたテストを実行する事
    | にした。どうもそもそも symbolic link 自体が作られていない気がする。find
    | で見る限りは ln で作ったファイルが全て通常のファイルになってしまっている。
    |
    | 調べてみたが msys2 や Git for Windows 辺りで最近 symbolic link 周りが変更
    | されたという話も見当たらない。
    |
    | a msys2 ではなくて Windows の ln ls readlink find 等のツールを拾ってしまっ
    |   ている? と思って type -p でパスを確認してみたがちゃんと msys のを呼び出
    |   している気がする。(そもそも windows のものを呼び出していたら、使い方が
    |   違うので、別のエラーメッセージが発生しそうなものである)
    |
    | b 一方で Git for Windows の release note を見ると winsymlinks に加えて
    |   sysfile または nativestrict を指定する必要がある様な感じに書かれている。
    |   然し、sysfile を追加しても振る舞いに変化はない。
    |   https://github.com/git-for-windows/build-extra/blob/main/ReleaseNotes.md
    |
    | c 或いは一旦システムを開始した後に個々のコマンドで振る舞いを変更したい場
    |   合は MSYSTEM という環境変数を使えという話が以下のリンクで言及されていた。
    |
    |   https://github.com/msys2/MSYS2-packages/issues/3941#issuecomment-1680093862
    |
    |   これは最近のコメント (2023-08-16) だが最近変更でもあったのだろうか。其
    |   処で MSYSTEM にも MSYS の値をコピーして試してみたが振る舞いに変化はない。
    |
    |   そもそもこの Issue の報告者は lnk を MSYS に指定している。
    |
    |   https://github.com/msys2/MSYS2-packages/issues/3941
    |
    |   これはどういう意味だろうか。試しに lnk を追加してみたがやはり振る舞いに
    |   変化はない。
    |
    | d また Git for Windows の release note に戻ると winsymilnks:nativestrict
    |   (NTFS junction を用いた物) についても言及されていたのでそれも試してみた
    |   がやはり振る舞いは変わらない。
    |
    | 突然動かなくなったがこれはどういう事だろうか。取り敢えず test3.sh の中に
    | は ble.sh の中で最近変更した物は含まれていない様に思われる。それに問題は
    | 明らかに windows において ln がリンクを作れていない事によっている。その他
    | の要素がこの振る舞いに影響しているとは思えない。念の為 windows-2019 で振
    | る舞いが変わるかどうか確認する。
    |
    | e もう一つの可能性は MSYS はコロン区切りの筈だけれど、実際には何故か : が
    |   入っていると winsymlinks はちゃんと動かない。そして、今までは MSYS が空
    |   だったので問題が起こっていなかったが、新しく disable_pcon が追加された
    |   事で正しく認識されなくなってしまった?
    |
    |   →実際に MSYS=winsymlinks を試してみたら動く様になった。謎である。lnk,
    |   sysfile, nativestrict 等と組み合わせて指定してもちゃんと動く。
    |   hello_world という存在しない設定を指定しても動く。何と
    |   winsymlinks:disable_pcon の順番でもちゃんと動く。これが意味する所は
    |   MSYS の winsymlinks が設定されているかどうかをチェックする部分のコード
    |   が間違っているのではないかという事。念の為 disable_pcon:winsymlinks を
    |   自分で代入した場合も試してみる。期待通り動かない。sysfile:winsymlinks
    |   の場合でも動かない。
    |
    |   本体のテストの方は ble/path#append ではなくて ble/path#prepend を使えば
    |   何とかなりそうだ。
    |
    |   一方で、手元の msys2 では disable_pcon を MSYS に設定していても別にテス
    |   トは失敗しない。中では disable_pcon:winsymlinks の様な形になっている筈
    |   である。
    |
    | 取り敢えず workaround は分かったが winsymlinks の指定位置で振る舞いが変化
    | するのは理解できない。この振る舞いを制御しているのは何処だろうか。どうも
    | Cygwin のソースの中自体に winsymlinks というのが隠れている?
    |
    | 実は CYGWIN 環境変数は : 区切りではなくて ' ' 区切りの可能性?

    環境変数 MSYS (そして upstream の CYGWIN) は実はコロン区切りではなくて空白
    区切りである。今までの GitHub workflow では MSYS が空だったので単に
    winsymlinks が追加される形になって問題は発生していなかった。所が、最近 MSYS
    として disable_pcon が既定で設定される様になった。ここで winsymlinks を追加
    する為に : を使用した為にちゃんと winsymlinks が認識されなくなったのが問題
    の原因であった。この為にそもそも全く symbolic links が作られなくなったのが
    テストが失敗する様になった原因であった。

2023-09-14

  * bashbug: "convert-meta on" の時 job 関連の bash の警告が出る [#D2070]
    Ref #D2069
    Ref memo/D2070.bashrc

    bash: DEBUG warning: mark_dead_jobs_as_notified: ndead (0) != js.j_ndead (1)

    色々試してみたがどうも bash-bisect の中でビルドすると問題が発生しなくて、
    bash-dev の中でビルドすると問題が発生する。何が悪いのだろうか。と思ったが、
    そうではない。release ビルドにしているから問題が発生しないのである。という
    事はそもそもこの問題がどこで発生するようになったのかも定かではない。もしか
    すると bash-5.2 の時点でも問題として存在しているのかもしれない。

    そもそもこのエラーはどのタイミングで発生するのだろうか。問題発生のテストケー
    スを最小化する事は可能だろうか。

    うーん。convert-meta が関係しているというのも何だか不思議な事である。単に
    locale が間違っているという事で起きているのではない。locale が間違っていて
    も convert-meta が off であればこのエラーは生じない。convert-meta on で
    bind 関連の問題が生じている時に限ってこの警告が発生する。

    最小ケースを作るか或いは bash に直接修正を入れるかのどちらかという事になる。
    先ずエラーが検出されているのは mark_dead_jobs_as_notified (jobs.c:4858) で
    あり、変数の値の不一致である。しかしこの不一致がどの時点で発生したのかとい
    うのは明らかではない。更に、convert-meta の関連性は更に不明である。或いは
    convert-meta がうまく行かない時の無限ループに関係があるのだろうか。意図的に
    マクロの convert-meta を介した無限ループを作ってみたら readline: maximum
    macro execution nesting level exceeded というメッセージが表示される。うーん。

    ? マクロ無限ループのメッセージが出たらそれに対して vbell を出そうとしてそれ
      で job のエラーが表示されているという可能性はあるだろうか。受け取った CSI
      の数 (19) と比べてみようと思ったがそれよりは警告が出る回数 (14) は少ない
      様である。visible-bell を潰してもやはり問題は出る。なので visible-bell は
      関係ないだろう。

    ? 次に確認するべきことは果たしてどのタイミングでメッセージが表示されている
      のかという事。文字列の受信が始まってから問題が発生している様な気がする。
      ble-decode/.hook -> ble-decode/EPILOGUE -> ble-edit/bind/.tail ->
      ble/util/idle.do -> ble/complete/auto-complete.idle ->
      ble/complete/auto-complete.impl ->
      ble/complete/auto-complete/source:syntax ->
      ble/complete/candidates/generate ->
      ble/complete/candidates/generate-with-filter substr ->
      ble/complete/source:command -> ble/complete/source:command/gen ->
      ble/complete/source:command/gen.1 -> ble/util/conditional-sync

      うーん。どうやら ble/util/assign の中で conditional-sync を実行しようとす
      ると問題が生じる様子である。更に言うと locale は関係ない。

    取り敢えず最小再現は以下まで小さくなった。この設定で C-t を二回押すと問題が
    再現する。locale などは関係ない。

      source out/ble.sh --norc --attach=none
      builtin bind -x '"\C-t": v=${ sleep 0.1 & }'

    以下が最小再現コードである。ble.sh と関係なく再現する。ここから少しでも減ら
    そうとすると何か変な事が起こる。謎である。

      enable -f /home/murase/opt/bash/dev/lib/bash/sleep sleep
      function f1 {
        for a; do :; done
        builtin sleep 0.1
      }
      builtin bind -x '"\C-t": v=${ f1 a & }'

      job error caused by funsub + bind + loadable builtin

    これに関して言えば ble.sh の側でできる事はないし、そもそも bash-5.3 はリリー
    スされていないし、問題はデバグ中に発生しただけで実際の構成では発生しないの
    で気にしなくて良い。

  * decode: "convert-meta on" in bash >= 5.2 with broken locale (reported by 3ximus) [#D2069]
    https://github.com/akinomyoga/ble.sh/issues/361
    Ref memo/D2069.bashrc

    kalilinux で存在しない locale を使っていると left/right が使えない

    そもそもこれは kalilinux 特有の問題なのだろうか。或いは locale が壊れていた
    ら常に起こる問題なのだろうか。一つの可能性は locale が見つからない事によっ
    て bash readline の meta 云々の設定が変わってしまって、それが理由で矢印キー
    が認識されなくなっている可能性。

    自分の手元の Arch で問題を再現することができた。起こっている現象としては
    ESC (27) が全く受信できていないという事。ble/decode/.hook の呼び出しを直接
    観察しても受信されていない。

    * reject: 実行した初回の bind -spX の出力が違う C-? C-u C-w がちゃんと bind
      されていない。然しこれは関係があるのだろうか。

      --- debug.0.txt^I2023-09-14 06:09:29.718861055 +0900
      +++ debug.1.txt^I2023-09-14 06:08:15.982192253 +0900
      @@ -5,7 +5,7 @@
       # arrow-key-prefix (not bound)
       # backward-byte (not bound)
       # backward-char (not bound)
      -# backward-delete-char (not bound)
      +"\C-?": backward-delete-char
       # backward-kill-line (not bound)
       # backward-kill-word (not bound)
       # backward-word (not bound)
      @@ -112,7 +112,7 @@
       # undo (not bound)
       # universal-argument (not bound)
       # unix-filename-rubout (not bound)
      -# unix-line-discard (not bound)
      +"\C-u": unix-line-discard
       # unix-word-rubout (not bound)
       # upcase-word (not bound)
       # vi-append-eol (not bound)
      @@ -162,7 +162,7 @@
       # vi-subst (not bound)
       # vi-tilde-expand (not bound)
       # vi-undo (not bound)
      -# vi-unix-word-rubout (not bound)
      +"\C-w": vi-unix-word-rubout
       # vi-yank-arg (not bound)
       # vi-yank-pop (not bound)
       # vi-yank-to (not bound)

      うーん。正常に動いている場合でも最初はこの様な状態になっている様なのでこ
      れは関係ないという気がする。

    起動した後に LANG='en_CA.UTF-8' を設定しても特に問題は発生しない。やはり起
    動時の初回のプロンプトで問題が起こるという事なのだろうか。


    * 更に手元の chatoyancy でも単に以下の bashrc で起動するだけで再現する。

      LANG='en_XY.UTF-8'
      source out/ble.sh --norc

      更に bash-4.0..5.1 まで問題は発生しない。bash-5.2 で実行すると core dump
      する。システムの bash で発生する。bash-dev でも同じ問題が発生している (そ
      れに加えて job 関連の警告が locale によって出る)。

      問題発生ケースの最小化について。これは bind 関係の問題だから bind を何と
      か色々やる事で再現できないだろうか。しかし、一回コマンドを実行すると直る
      事などを考えると単純ではない様に思われる。何らかの発生条件があるというこ
      と。取り敢えず手動 attach した時にも再現するかどうかを確認する。

      →手動 attach でも再現する。prompt の中で実行するとちゃんと受信できないと
      かそういう事なのだろうか? と思ったがそれも変だ。一文字でも入力したら
      prompt attach であっても PROMPT_COMMAND の外側に出てちゃんと bind の中で
      処理をする様になるので。

      という事を考えると、一回コマンドを実行すると問題が発生しなくなるという所
      に重点を置いて調べるべきだろうか。

      * 取り敢えず空のコマンドを実行しても問題は継続する。
      * C-x C-v で表示を行っても問題は継続している。
      * execute-command 経由でコマンドを実行すると直るが、これは普通にコマンド
        として実行するのと同じ様なものであるので、新しいことがわかったとは言え
        ない。

        或いは具体的に bash の中で何が起こっているのか追跡するべきなのかも知れ
        ない。特に keymap 関連の処理で受信された 27 がどの様に消えてしまうのか
        を確認する。コマンドを実行すると直るという事はやはり keymap のデータ構
        造が壊れているとかそういう事なのだろうか。或いは、コマンド実行時に戻し
        きれていない何らかの設定が存在している?

      * external-command を実行した時にどうなるかも確認する → 実は
        external-command を実行した場合でも問題は再現しなくなる。
      * ble/term/{leave,enter} の実行だけでも問題はなくなる。
      * ble/term/rl-convert-meta/{leave,enter} で問題が解消する。

        然し何故問題が発生するのだろうか。_ble_term_rl_convert_meta_adjusted の
        値はちゃんと最初から 1 になっている。つまりどこかで adjust が実行された
        筈ということ。PROMPT_COMMAND の内部から attach した時は readline の設定
        が復元して戻ってしまうという事だろうか。

        実際に振る舞いを確認してみると初回だけ convert-meta on になっていた。
        bash-5.1 以下ではちゃんと off になっている。

        prompt attach でも直 attach でも問題は発生する。つまり、attach のタイミ
        ングで回避できる物ではない様に思われる。

      うーん。これを回避する為には最初のキーの受信の時点で convert-meta off を
      明示的に実行するべきだろうか。然しそうだとしても最初の最初のキーが 27 の
      時にそれが欠けてしまうという問題が残る。或いは attach した直後に
      convert-meta off を実行すれば問題はなくなるのだろうか? と思ったが実際に
      attach の時に ble/term/enter を実行している筈なのでちゃんと convert-meta
      off は実行されている筈である。

      _ble_term_rl_convert_meta_adjusted の初期値は? → OK。ちゃんと空である。
      つまり、1 が設定されていた時点で何処かでちゃんと convert-meta off が実行
      されていたという事。それにも関わらず convert-meta が何らかのタイミングで
      on になってしまう。

      ? 特に、手動 attach をした場合でも問題が再現するというのは変だ。更にわかっ
        た事は、ble-bind -f C-t ... を実行していると手動 attach では問題が発生
        しなくなるが、prompt attach では問題が継続するという事。ble-bind を実行
        しているかしていないかで変わるというのも不思議な挙動である。

      ? もうひとつ不思議なのは convert-meta 絡みなのに LANG=C の時には問題が生
        じていないという事。locale の初期化に失敗した時にだけ勝手に
        convert-meta on になるという事なのだろうか。

      readline 最初の locale の初期化の際にエラーが起こると convert-meta を設定
      するという動作になっているのだろうか。その時点で convert-meta を off に戻
      す必要があるが、readline が最初に受け取った byte というのが消滅するのであ
      ればそれをスクリプトの設定の側から検出する事ができない。最初に受け取った
      文字を見て勝手に 27 が前に存在していたという事を推測するのは堅牢でない。
      ユーザーが入力した文字を勘違いする可能性がある。

      a bash に対する修正要求をする? 或いは過去に convert-meta を設定したのであ
        れば後で bash が勝手に convert-meta を変更するのは変だという事にはなら
        ないか。例えば convert-meta の状態を内部的には auto on off の３つにして
        おいて、既定値は auto で、ユーザーから一回でも指定があったら on/off に
        して、locale 失敗時には auto の場合にのみ convert-meta を再設定する。

        或いは、auto on off は保持しておいて、内部的な既定値を locale 失敗時に
        設定する。auto の時には内部的な既定値を参照する。という具合の実装に
        bash が変更してくれれば問題は解決する。

      b 別の方法としては readline の locale の初期化を強制的に実行する方法を考
        える。その後であれば勝手に convert-meta が設定される事もないだろう。

        と思ったが本当だろうか。普通に開始したとしても壊れた locale を設定した
        直後は readline の振る舞いが変になるのではないか → 少なくともユーザー
        コマンドとして LANG=en_ZZ.utf8 などの値を設定しても特に振る舞いが壊れる
        という事もないようだ。

        a read -e xxx </dev/null 等として強制的に readline の locale の初期化を
          済ませられないかと思って試してみたが振る舞いに変化はなかった。と思っ
          たが、よく考えたら read -e は ble.sh が上書きして subshell の内部で自
          前の read loop で実行するので何れにしても readline は呼び出さない様に
          なっている

        b 今度は builtin read -e xxx </dev/null として見たがそれでも駄目。

        c builtin read -e xxx <<< yyy としてみても駄目。一応変数 xxx には期待し
          た文字列が格納されている。 -e を指定しても読み取り元が tty でなければ
          readline は初期化されないという事なのかもしれない。

        d 今度は builtin read -et 0.1 xxx としてみたらどうやら動く様になった。
          builtin read -et 0.000001 でもちゃんと動く。builtin read -et 0.000001
          </dev/tty でも動く。

          但し、ble-bind -f ... で何かを設定しないとちゃんとは動かない。
          ble-bind -f を指定する事によって何かが初期化されてそれとの順番との兼
          ね合いだろうか。うーん。builtin read -et 0.000001 よりも前に ble-bind
          -f を実行している必要がある。順番を逆にするとやはり問題が発生する。
          ble-bind の中の何らかの操作が関係しているのだろうと思って調べてみると、
          単に ble/decode/initialize だった。然し、ble/decode/initialize が
          bash の振る舞いに影響を与えるというのも不思議といえば不思議である。更
          に調べると _ble_decode_initialize_inputrc=none だと
          ble/decode/initialize を呼び出しても問題が継続する。diff にすると収ま
          る。ble/builtin/bind/read-user-settings を呼び出すと収まる。
          ble/builtin/bind/read-user-settings/.reconstruct を呼び出すと収まる。
          然し、ble/builtin/bind/read-user-settings/.collect を呼び出しても収ま
          らない。不思議だ。と思ったら、.reconstruct の中で呼び出している
          LC_ALL= LC_CTYPE=C ble/bin/awk なのかもしれない → これだった。単に
          LC_ALL= LC_CTYPE=C で何かのコマンドを呼び出せばよかった様だ。

        e 今度は builtin read -et 0 xxx とした場合には動かない

      うーん。遅延で手動で attach する場合には、最初から convert-meta on になっ
      ていて、自分で convert-meta off に設定してから ble-attach すれば問題は生
      じない。

      まとめると最初のプロンプトを表示した後に locale の初期化とそれに応じた
      convert-meta の設定が行われる様である(本当か?)。

      存在しない locale が設定されている時に何処かのタイミングで convert-meta
      on に設定されるのが問題である。

      ? convert-meta on が設定されている時に ESC (もしくは ESC [ の組み合わせ)
        が完全に消滅するのは何故なのか。

        | 別の形で受信される等の事も起こっていない。素直に考えると M-[ という組
        | み合わせの文字に変換されても良い気がするのに、それすらも受信されない。
        |
        | 実は bash-5.1 以下では M-[ という形で受信できている可能性もある? と思っ
        | て確かめてみたが bash-5.1 以下では最初から convert-meta off になって
        | いた。やはり convert-meta on の時には ESC [ が受信ができない状態になっ
        | ていると考えるべき。
        |
        | 取り敢えず bash のソースコードを調べてみると convert-meta on の時はど
        | うも M-[ を ESC [ に分解する機能なのではないかという気がする。だとす
        | ると、そもそも ble/decode/.hook で 27 を受信できないという問題は独立
        | の様な気がする。何故振る舞いが変わるのだろうか。そもそも本当に
        | convert-meta は bash の _rl_convert_meta_chars_to_ascii に対応してい
        | るのだろうか? → bind.c を確認してみる限りはちゃんと対応している筈。
        |
        | 参照している箇所を少しずつ潰して行った所
        | _rl_function_of_keyseq_internal での取り扱いが振る舞いに影響を与えて
        | いる様だ (然し blame で見る限りこの部分は 12 年間変更されていないので
        | 他の部分の変更が波及してここでの振る舞いに変化をもたらしていると考え
        | られる)。うーん。readline.c の中の convert_meta を参照している所
        | (_rl_dispatch_subseq) も同時に振る舞いに影響を与えている。どちらか一
        | 方だけ潰しても問題は発生しない。両方をコメントあうとした時に問題が生
        | じなくなる。
        |
        | →分かった気がする。ble.sh は isolated ESC を区別する為に ESC ... を
        | C0 9B ... に変換して受信している。この時 convert-meta on だと C0 が変
        | な風に分解されてしまう (というか無限ループになる?)。結果として何も受
        | 信できずに終わるということの気がする。
        |
        | つまり "ESC [" → "C0 9B [" → "ESC @ 9B [" → "C0 9B @ 9B [" → …
        | という具合に無限ループになって恐らく中断されて何も受信できないという
        | 事になっている。

        ble.sh は isolated ESC と区別する為に ESC [ を C0 9B [ に変換している。
        一方で C0 は convert-meta の時には ESC @ に分解される
        (_rl_dispatch_subseq)。ESC @ は isolated ESC と区別する為に C0 9B @ に
        変換される。というのを繰り返して先頭の文字に対して無限の展開が起こって
        しまう。恐らくこれが強制的に中断される結果として ESC [ が全く受信されな
        いのだろうと思われる。_rl_function_of_keyseq_internal の中でも同様にし
        て C0 が ESC @ に分解される事によって振る舞いが変になっている。

    取り敢えず半ば偶然ではあるが workaround が見つかったのでそれを実装する事に
    する。これは ble.pp の環境確認の段階で実行するのが良さそうである。

  * make uninstall を提供するべきではないか [#D2068]

    そしてそれはそんなに難しくないはず。インストール対象は全て変数に入っている。
    ただし、INSDIR, PREFIX 等の変数を指定した時には、インストール時と全く同じ設
    定を覚えておく必要がある。然し、変数に依存するとしても対応するのは自然の気
    がする。

  * prompt: prompt ruler の位置は elapsed marker よりも後であるべきでは (motivated by U-Labs) [#D2067]
    https://www.youtube.com/watch?v=OS3I1cCCw_Q

    * ok: というか printf EOF などに対する振る舞いもちゃんとしているのだろうか?
      → これは試してみた所ちゃんと処理されている。

    これは ble-edit/exec/.adjust-eol の中で 呼び出しているのが問題である。呼び
    出し箇所を変更することにした。 ble-edit/exec/.adjust-eol は一箇所でしか呼び
    出されていないのでその呼出元に移動すれば十分である。

2023-08-26

  * menu: append-arg で対応する項目がない時 bell (motivated by bkerin) [#D2066]
    https://github.com/akinomyoga/ble.sh/issues/354

    2023-09-14 色々考えたがやはり bell を鳴らすのを既定の動作とする事にした。

2023-08-17

  * Makefile: github/workflows の macos-latest で失敗する [#D2065]

    色々実験した結果、どうやら make-3.81 では以下の規則があった時に三つ目に合致
    するファイル名の時であっても、一つ目の規則を適用してしまう様である。3.82 で
    はちゃんと問題なく動作する。

    | $(OUTDIR)/doc/%: % | $(OUTDIR)/doc
    | 	$(CP) $< $@
    | $(OUTDIR)/doc/%: docs/% | $(OUTDIR)/doc
    | 	$(CP) $< $@
    | $(OUTDIR)/doc/contrib/%.md: contrib/%.md | $(OUTDIR)/doc/contrib
    | 	$(CP) $< $@

    よく見てみるとこの make-3.81 における問題は contrib.mk にも既に書かれていた。
    contrib.mk における回避方法は三番目の規則をより詳しくすると言う物だったが、
    実は一つ目の規則を消して代わりにファイルを一つずつ記述する方が現実的の気が
    する。その様に変更する事にする。

    x contrib.mk で定義されているマクロ名に綴り間違いがある。序でにこれも修正し
      ておく。

2023-08-16

  * PKGBUILD: 色々とけちがついているので修正する (requested by willemw) [#D2064]
    https://aur.archlinux.org/packages/blesh-git#comment-929483

    * provides & conflicts を修正した
    * depends & makedepends の修正
    * /usr/share/licenses/blesh に配置するライセンス

  * external: bash-3.2 初期化で無限ループになる  [#D2063]

    bash --norc で開始した後に source out/ble.sh しても問題は発生しない。

    →これは単に ~/.bashrc の方のバグだった。ble/util/idle.push のサポートが無
    い時に ble-import -d 経由で無限ループが明示的にできていた。

2023-08-15

  * 2023-07-24 mc-4.8.29 で動かなくなっている (reported by mooreye) [#D2062]
    https://github.com/akinomyoga/ble.sh/issues/62#issuecomment-1646969652

    以下の内容を受信している。以前は単一行を受信していたのに複数行に分かれたの
    が問題という事だろうか。

    | declare -- _ble_edit_str=" mc_print_command_buffer () { printf \"%s\\\\n\" \"\$READLINE_LINE\" >&13; }"
    | declare -- _ble_edit_str=" bind -x '\"\\e_\":\"mc_print_command_buffer\"'"
    | declare -- _ble_edit_str=" bind -x '\"\\e+\":\"echo \$BASH_VERSINFO:\$READLINE_POINT >&13\"'"
    | declare -- _ble_edit_str=" PROMPT_COMMAND=\${PROMPT_COMMAND:+\$PROMPT_COMMAND"
    | declare -- _ble_edit_str="}'pwd>&11;kill -STOP \$\$'"
    | declare -- _ble_edit_str="PS1='\\u@\\h:\\w\\\$ '"

    然し、遡ってみてもこの部分の変更が行われたのは 4.8.26 ととても古い。一方で
    4.8.28 では遅延なく mc が開始される事は確認した。何故だろう。と思ったが後で
    気づいたのだが mc 4.8.28 でも ble.sh は正しく起動していなかった。代わりに
    sh に fallback していたが遅延なく失敗していたという事の気がする (mc の側で
    待ち時間を変更したのかもしれないし或いは出力内容によっては ble.sh session
    がクラッシュしていた可能性もある?)。

    取り敢えず accept-line で LINENO の上限を上げてみるとちゃんと起動する様になっ
    た。mc の中で ble.sh も一応動作している様だ。然し色々と問題がある。

    x fixed: 現在は取り敢えず $_ble_edit_LINENO -le 5 で判定しているが本来はもっ
      とちゃんと判定するべき。例えば、_ble_edit_str に含まれている文字列も検査
      してユーザーコマンドを誤って実行しないように対策をしておく事にする。新し
      い関数に分離した方が良いかもしれない。

      →これは PROMPT_COMMAND=${PROMPT_COMMAND... という時にのみ特別扱いをする
      様に変更した。その他の場合には別に通常通りにコマンドを強制実行しても問題
      ない。

    x fixed: C-o が何かの拍子に効かなくなる。どうやら C-o をエスケープシーケン
      スで送信するモードに入ってその後で戻らなくなってしまう事があるようだ
      (xterm)。

      set -o emacs を実行してモードを変更すると問題が発生する。sleep 1 の実行中
      に C-o 等のキーを入力すると状態が元に戻る。

      →mc の内部では modifyOtherKeys の調整を強制的に無効にすることにした。然
      し、それでも set -o emacs にすると C-o に対して待ち時間が発生する様になる。
      これは単に M-+, M-_ に対する応答がないからだと思われる。これについては
      ble.sh の側で M-+ および M-_ に対して現在のモードに関係なく応答する様に調
      整すれば良い様な気もするが、其処までする程の事でもないし plain Bash でも
      同様の問題が発生するのだから取り敢えずは考えない事にする。

    x fixed: mc がプロンプトの抽出に失敗している気がする

      | →これは罫線描画の問題でもあった。mc が考える罫線の幅と端末の罫線の幅が
      | 一致していなかった為に描画が乱れていたのだった。実際には、 "-- 挿入 --"
      | という文字列がプロンプトとして取り扱われていたのだった。また、"-- 挿入
      | --" がプロンプト文字列という想定の元ではちゃんと C-o を押した時の振る舞
      | いも正しくなっていた。
      |
      | 問題は "-- 挿入 --" を表示したままで mc に本物の方をプロンプトとして認
      | 識させる事は可能なのかという事。現在のカーソル位置はちゃんと本物の方の
      | 行にあるのでカーソル位置を合わせても恐らくちゃんとは認識してくれない。
      |
      | mc がプロンプトを抽出する瞬間だけ "-- 挿入 --" を消すという事も考えたが、
      | そもそも mc はどの瞬間にプロンプトを抽出しているのだろうか。というか、
      | そもそもどの瞬間にコマンドが終了してプロンプトが表示されたと判定してい
      | るのだろうか。PROMPT_COMMAND の段階では未だ何も表示されていない筈。うー
      | ん。\e+ または \e_ に対して応答した時点での内容を見ているという事なのだ
      | ろうか。
      |
      | 実際に試してみると C-o C-o を連続して押すと M-_ M-+ SP C-h というキーが
      | 送信されてくる様だ。更に振る舞いを見ると C-o で mc に戻る時に M-_ M-+
      | が送信されて、次の C-o で端末画面に移動する時に SP C-h が送信される様で
      | ある。
      |
      | 然し C-o "sleep 1" LF "sleep 1" LF C-o として見たがその途中でプロンプト
      | を更新している筈なのに M-_ も M-+ も何も受信していない。という事を考え
      | ると実は純粋に最後の出力内容でプロンプトを決めているという事なのだろう
      | か。
      |
      | * mode-indicator がなくてもプロンプト抽出できない
      |
      |   mode-indicator を修正して MC_SID が設定されている時には何も表示されな
      |   い様にした。しかしそれでもちゃんと抽出できていない。C-o から実行した
      |   時にはちゃんとプロンプトを抽出できているが、mc から直接コマンドを実行
      |   した時にはプロンプトがそもそも表示されていないのである。これはどうい
      |   う事だろうか。
      |
      |   調べてみると一応は mc からコマンドを実行する時でも ble.sh の gexec を
      |   経由してコマンドが実行されている様である。一方で何故プロンプトが表示
      |   されないのか、というと…。
      |
      |   mc の内部からコマンドを実行した時にコマンドの終了をどう検出しているの
      |   だろうか。例えば、M-+ 等のキーを予め設定して置いてそれによる処理が呼
      |   び出されたらその時点でプロンプトを読み出すのだろうか。と思って確認し
      |   てみたが mc の内部から実行した時には無駄な入力は一切していない。とい
      |   う事を考えると、PROMPT_COMMAND から呼び出している pwd 及び kill -STOP
      |   が怪しい。うーん。普通の bash だと kill -STOP が処理されるのはプロン
      |   プトが表示されてからと言う事なのだろうか。
      |
      |   →取り敢えず kill -STOP はPROMPT_COMMAND から削除して自前で kill
      |   -STOP を呼び出す様に変更する事にする。一旦は動いた様に見えたが単純に
      |   コードが壊れて ble.sh が開始していなかっただけだった。終了しても良い
      |   のかもしれない。
      |
      |   kill -STOP の実行をプロンプト表示の直後にしてもやはり問題が生じる。
      |
      | * done: 初回の実行に関しては gexec/.end で kill -STOP を実行しても初回
      |   の PROMPT_COMMAND に対応する処理は実行できない気がするので、寧ろ
      |   PROMPT_COMMAND の中で変数を設定してそれを読み取って kill -STOP を
      |   ble/textarea#render の最後で実行する様にした。然し振る舞いは変わらな
      |   い。よく考えたら mc は直接コマンドを入力して PROMPT_COMMAND を修正す
      |   るのだから、gexec/.end は何れにしても呼び出されるのだった。余り意味が
      |   ないのだったが、元の動作を考えるとこちらの方がより近いのでよしという
      |   事にする。
      |
      | * done: pwd のタイミングも遅延してみる? pwd の方のタイミングも関係して
      |   いるのかもしれないと思って、pwd の方も描画の後に実行する事にしてみた
      |   が振る舞いに違いはない。と思ったら ble/util/buffer.flush を実行してい
      |   なかった。これを実行する様にしたらちゃんと画面にはプロンプトが表示さ
      |   れる様になったが、mc は依然として拾ってくれない。
      |
      | * プロンプトの後に改行が挿入されている問題: どうも表示したプロンプトの
      |   次に改行が入って、そこから文字列が入力される状態になってい
      |   る。_ble_util_buffer の中身を見ても変な改行は含まれていない。plain の
      |   bash での振る舞いを見ると mc 内部からコマンドを実行した時には余分な改
      |   行が出力されている。どうやら mc は STOP でシェルが停止した後に改行を
      |   挿入して、更にその後でシェルにプロンプトを描画させてそれを拾っている
      |   様な気がする。
      |
      |   然し STOP の直後にプロンプトを表示する様にしても画面に何も表示されな
      |   くなってしまう。pwd だけ先に実行して直後に出力して、その後に STOP を
      |   実行する様にしても改行が次に表示されてしまう。
      |
      |   plain bash で PROMPT_COMMAND='echo -n 1 >&2;pwd>&16;echo -n 2
      |   >&2;kill -STOP $$;echo -n 3 >&2' 等として見ると 2 だけがプロンプトと
      |   して中執されている。これが意味するところは、pwd を実行してから停止す
      |   る迄に出力された内容を mc はプロンプトだと考えているという事ではない
      |   だろうか。では、なぜ現在の実装でそれが正しく抽出できていないのだろう
      |   か。
      |
      |   | そもそも微妙なタイミングの違いで出力されるされないが変わっている気
      |   | がする。色々実験した結果、pwd よりも前に出力した結果は画面に現れる。
      |   | 然し、pwd よりも後に出力した結果は表示される事もあるしされない事も
      |   | ある。直後に単に echo -n "..." >&2 で出力すると表示される場合が多い
      |   | が、一行でも IFS= eval 'local text=${arr[*]}' 的な事を挟むとそれだ
      |   | けで表示されなくなってしまう。この事から、本来は mc の意図としては
      |   | pwd の結果を受信したら bash の出力は捨てるモードに移行するのではな
      |   | いかという事。
      |
      |   → pwd ... kill -STOP の間に出力された内容は基本的には失われる。タイ
      |   ミングの都合で pwd 直後だとすり抜ける事がある。
      |
      |   kill -STOP の後に出力した内容は期間を置いても基本的には失われる。mc
      |   がどうやって plain bash のプロンプトを抽出しているのかは謎である。或
      |   いは、pwd の内容が変化した時にだけ読み取っているという可能性?
      |
      | * もう mc の振る舞いが全く分からない。プロンプトの抽出を mc がどのよう
      |   に実行しているかを調べるべきなのかもしれない。
      |
      |   1 read_subshell_prompt という関数があったから其処で何を受信しているか
      |     を調べてみたらカーソル表示・非表示の出力を拾っていた。どうも一番最
      |     初に受信した socket のブロックをプロンプトと考えているという事?
      |
      |     →何故か分からないが、ble/util/buffer で何も出力する物がない時には
      |     カーソル表示・非表示のシーケンスも含めて何も表示しない様にしたら、
      |     mc の中からコマンドを実行した時のプロンプトに関してはちゃんと正しい
      |     配置になる様になった。
      |
      |     どうも改行が勝手に挿入されていたのは空の ble/util/buffer の出力を
      |     mc が受信した時に勝手に改行を追加していたからではないだろうか。
      |
      |   2 それでも正しいプロンプトを抽出できていないと思ったら、どうもまた別
      |     の制御シーケンスの集合をプロンプトと思って受信している様だ。そもそ
      |     もプロンプトに対応する文字列をどうやって判定しているのかが気になる。
      |     タイミングの問題だろうか。或いは、改行以降を抽出しているという事な
      |     のか。
      |
      |     ble/util/buffer の出力している内容と read_subshell_prompt で受信して
      |     いる内容が一致しないと思っていたらどうやら一番最初だけしか
      |     read_subshell_prompt は呼び出されていない様だ。
      |
      |     内部の動作を確認してみるとそもそもプロンプトの更新をしていない。何
      |     故だろうか。should_read_new_prompt が設定された状態で次の出力が来た
      |     ら読み取る仕組みになっている。should_read_new_prompt は設定されてい
      |     る。然し、設定されてから次の出力を受信する前に関数が終了している。
      |     次に関数が呼びされる時には関数の初めで
      |     should_read_new_subshell_prompt がクリアされるので結局新しいプロン
      |     プトに更新するという処理が行われる事はないのである。
      |
      |     →何だか分からないが応急処置で色々変な事をしていたのを削除したら動
      |     く様になった。但し、vi.sh の mode-indicator "-- 挿入 --" は表示しな
      |     い様にしないとちゃんと動かない。色々弄ったのは
      |     memo/D2062/delay-mc-STOP.patch に残して置く事にする。

      [まとめ]

      * 表示が崩れる原因の一つは罫線の文字幅が一致していない事。これは単に端末
        の問題なので xterm を使えば問題は発生しない。

      * プロンプトの抽出に失敗していたののもう一つの原因は、
        ble/util/buffer.flush において出力内容が空であってもカーソル表示・非表
        示の端末制御シーケンスを ble.sh が必ず出力していた事がある。(というか今
        まで全ての bind/.tail でこれを必ず出力していた事になる?) これは出力内容
        がある時にだけ付加する様に変更する異にした。

      * また vi における mode-indicator for vi_imap を勝手にプロンプトと勘違い
        するので、mc の中では vi_imap に対してだけは mode-indicator は表示しな
        い様に変更する異にした。

    x ok: C-o を押した直後のカーソルの位置がおかしい。これはプロンプト抽出失
      敗とも関係しているのかもしれない。

      →これは問題はプロンプト抽出が直ってからは発生していない。

    x fixed: と思ったが、何度か C-o を押して画面を行き来すると結局プロンプトが
      消えてまたカーソル位置もおかしくなる。

      これは plain Bash の中では発生していない。というか plain Bash の中だと何
      度か C-o を押すと plain Bash が表示したプロンプトに置き換わる (mc が代わ
      りに表示するのは SGR が削除されて黒いのでそれとは区別できる)。

      M-_ M-+ を受信しているだけなのでその時にプロンプトを表示しなければならな
      い。というか、そもそも ble.sh は再描画している筈なのに表示されないのは何
      故だろうか。

      振る舞いを見ると M-_ 及び M-+ が受信されるのは C-o で端末に戻った時ではな
      くて、mc に戻った時の様である。うーん。つまり、mc に戻る直前の状態を mc
      が覚えておいてそれが端末に戻った時に復元されるということ? そして少しでも
      遅延があると mc に出力を食われて何も表示されずに終わってしまう。

      取り敢えず M-_ M-+ で mc に何かを送信するよりも前に必ず render & flush を
      実行する様にしたら問題が発生しなくなった。M-_ の方は render & flush しな
      くても良いが、M-+ の方は必ず render & flush しなければならない。

    2023-08-16 mc の外でも "-- INSERT --" の表示が無くなっていると思ったら、mc
    の時にだけ 1 に設定される筈変数の初期値が 1 になっていた。修正する。

2023-08-13

  * history: bash-5.3 history -anrw で何処にも書き込まない [#D2061]
    https://lists.gnu.org/archive/html/bug-bash/2023-07/msg00165.html
    https://lists.gnu.org/archive/html/bug-bash/2023-08/msg00007.html

    bash/ChangeLog
    |                     8/2
    |                     ---
    | [...]
    | doc/{bash.1,bashref.texi},lib/readline/doc/hsuser.texi
    |     - history: document that if filename is not supplied, and HISTFILE is
    |       unset or null, the [-anrw] options have no effect

    と思ったが元からそういう振る舞いになっていた。議論を参照してみるとどうやら
    これまでの bash では何も設定されていないと ~/.history というファイルを勝手
    に作って其処に書き込む様になっていた様だ。

    * reject: 今までの bash の振る舞いを再現する様に書き換えるという手もあるか
      もしれないが振る舞いとしてやはり不自然なので ble.sh では bash-5.3 以降と
      同様に何も書き込まない事にする。

    * reject: history -anrw で HISTFILE が空の時にはエラーも出力しない?  ble.sh
      では HISTFILE が設定されていなくて -anrw を呼び出した時にエラーメッセージ
      を出力する様になっているが、bash-5.3 では何も出力しない様である。これにつ
      いてはやはりエラーメッセージを出力する方が自然の気がするので取り敢えずは
      エラーメッセージは表示する事にする。ユーザーが何かエラーメッセージを出力
      しない前提の使い方をしているという報告があった時にまた考える事にする。

    * done: エラーメッセージが常に history -a になっている。-anrw に応じて適切
      なオプション名を表示するべきではないか → FUNCNAME[1] の最後の文字から抽
      出する様に修正した。

    * done: ble/builtin/history/.get-histfile: 制御パス的に必ず true になる場所
      で [[ $histfile ]] で終了ステータスを設定している → 単純に削除する事にし
      た。

2023-08-11

  * complete: faces menu_filter_* を設定しようとすると見つからない (reported by anuramat) [#D2060]
    https://github.com/akinomyoga/ble.sh/issues/352

    これは complete がロードされてから設定しなければならない。と思ったが、他の
    complete の face はロードする前でもちゃんと動く様になっている。という事は
    menu_filter_* についてもメインのファイルに移動する事にした方が良い気がする。

    その他には ble.sh の外で defface しているのは vim-airline だけである。これ
    についてはちゃんと vim-airline が読み込まれてから設定を行う様に
    blerc.template に書かれているので大丈夫のはず。

2023-07-27

  * auto-complete: overwrite mode の時に self-insert が後続の文字を消去しない [#D2059]

    insert mode で表示されている auto-complete と一致する入力を
    そのまま確定するのは変ではないか。入力した文字数文だけ元々あった物を削除す
    る必要がある。

    一方で auto-complete を確定する時に元々ある文字列を上書きするのかどうかとい
    うのは微妙な問題である。現在の実装では insert mode かどうかに関係なくそのま
    ま挿入している。これはこの様な振る舞いの方が自然である。

    auto-complete 確定時の振る舞いを考えるとやはり auto-complete mode の時には
    上書きしないで挿入する様にする方が自然だろうかと思ったが、改めて考えると普
    通に入力した時の結果が auto-complete が background で走っているかどうかで降
    るまいが変わるのは問題である。auto-complete の確定は比較的非自明な操作をし
    た時にのみ起こるという事を考えたら、ac も起こらずに入力した時と一貫している
    必要はないが、通常の文字挿入に関しては ac が起こらずに入力した時と一致して
    いる必要がある。なので、やはり overwrite mode の時には auto-complete は一旦
    元の keymap に戻って入力を処理する事にする。

2023-07-26

  * make: work around ecryptfs (reported by juanejot) [#D2058]
    https://github.com/akinomyoga/ble.sh/issues/347

    cp -p をすると mtime の秒以下が切り捨てられてしまうのでいつまで経ってもコピー
    元よりもコピー先の方が新しいという事にならない。

    a 一つの方法は cp -p をやめて直接 cp を実行するという事。これによって
      timestamp が更新されるので、いつの時点のファイルが其処にあるのかというの
      が分かりにくくなる。一方で、ファイルに変更がないのにファイルが新しくなっ
      た事によってキャッシュの再生成が起こるのではないかというのが気になる。

      →古いバージョンに一旦戻して動作を確かめるという時には寧ろ更新したほうが
      良いのではないか? と思ったが古いバージョンに戻す時には何れにしても git で
      戻した時にタイムスタンプが最新版になるので気にしなくても良い気がする。

    b 或いは常に 1s だけ加算してコピーするという事。然し、1s 加算するというのを
      実装するのが POSIX の範囲内で行おうとすると結構面倒である。それにファイル
      を一つコピーするのに一々幾つもコマンドを起動したくない。

    c 或いは問題のある filesystem の上で実行している時に限りコマンドを切り替える。

      ファイルシステムの検出方法は信用できるものはない様だ。例えば df -T /dir
      で表示できるが -T は標準化されていない。Linux の stat だと stat -f -c
      '%T' /dir としたらファイルシステムの名前が表示される。しかし BSD stat に
      はそもそも filesystem についての情報を表示する機能がない。mount -l につい
      てもシステムによって存在するかわからないし存在したとしても形式が同じかも
      分からない。また mount point を指定する必要があるので最初に df などを使っ
      て mount point を抽出しておく必要がある。

      或いは bash が入っているのであれば実際に cp -p してみて振る舞いを調べると
      いうのも手かもしれない。

      更にもう一つの問題は問題のある filesystem の上でどの様にして更新を行うの
      かという事である。touch によって時刻をコピーしたらちゃんと秒以下も反映さ
      れるのだろうか。また、touch -r はどのシステムでもサポートしている物なのだ
      ろうか。→ touch -r は標準化されている様だ。然し、やはり touch でも秒以下
      の情報は消滅してしまう様である。という事を考えると最新の時刻に更新するし
      かない。

    何れにしても pp を噛ませるファイル生成に関しては生成時刻がファイル時刻になっ
    ていた。という事を考えるとただコピーを行うだけのファイルの場合にも、コピー
    時点での時刻になっていても問題ないのだろうという気がする。

2023-07-24

  * complete: cobraV2 の対策が動いていない (reported by 3ximus) [#D2057]
    https://github.com/akinomyoga/ble.sh/issues/348

    添付された生成コードを観察してみると completions に生成された候補が入ってい
    る。一方で core-complete.sh の .cobraV2.patch は out に生成されたデータが入っ
    ているという前提になっていて、out を修正しているが completions は修正してい
    ない。

    何処かの時点でコード生成が変更されたという事だろうか。cobra の方の実装を確
    認する必要がある。調べてみると [1] で変更が加えられている。
    __XX_extract_activeHelp が定義されている時に振る舞いを変更する様にすれば良
    さそうだ。

    [1] https://github.com/spf13/cobra/pull/1482/files#diff-ccbad943e447c0dbcf310892446819dea78bd471093c627e4aeb211c6ebb1b63

    実際に bb というコマンドを持っていないので正確には動作確認できないが適当に
    bb の出力を真似て実行してみた所、問題が再現できるという事と、対策したコード
    で問題が再現しない事を確認した。

    | --- gh348.sh~^I2023-07-24 06:31:13.884693063 +0900
    | +++ gh348.sh^I2023-07-24 07:00:07.415045133 +0900
    | @@ -57,6 +57,11 @@
    |      fi
    |      __bb_debug "The completion directive is: ${directive}"
    |      __bb_debug "The completions are: ${out}"
    | +
    | +out='hello^I(fdsafdsafdsa)
    | +world^I(test test test)
    | +aaaaa^Ixxxxxxx
    | +fdsafdsa'
    |  }
    |
    |  __bb_process_completion_results() {

    ? 問題が発生するのは desc がついていない候補も一緒に生成された時だけだが、
      報告では desc がついていない候補は生成されていない様に見える。何故だろう
      か?

      例えば空の候補が生成されている可能性? → 取り敢えず末尾に空行が含まれてい
      る場合にも問題が再現するという事は確認した。

2023-07-18

  * docs: styleguide の追加 (motivated by bkerin) [#D2056]
    https://github.com/akinomyoga/blesh-contrib/pull/12#issuecomment-1507719943
    https://github.com/akinomyoga/ble.sh/pull/317

  * mawk in Ubuntu 16.04 LTS (reported by dongxi8, Frezrik) [#D2055]
    https://github.com/akinomyoga/ble.sh/issues/335

    Ref. #D2037

    mawk の version が古い。そして Ubuntu 16.04 LTS はこの古い mawk を使ってい
    る様だ。mawk が失敗するとどうやら全く操作ができなくなる様だ。これは良くない。

    x reject: 後テストしていて気づいたが --clear-cache が効いていない。

      もしくはそのまま ble.sh が起動してしまう。例えば bash out/ble.sh
      --clear-cache とするとそのまま新しい interactive session が始まってしまう。
      何故? chatoyancy 上でやっても再現しない。と思ったが勘違いだった。

      それでも既に ble.sh がロードされているセッションで source out/ble.sh
      --clear-cache を実行した時に ble.sh をリロードするのかリロードせずに既に
      ロードされている ble.sh で指定されたコマンドを実行するのかは非自明 → こ
      れに関しては新しい物をリロードした上でコマンドを実行するという現在の振る
      舞いで良い気がする。

      ble.sh がロードされていない時にsource out/ble.sh --clear-cache をした時に
      勝手に attach してしまうのは変だろう、と思ったが実際にはそのような振る舞
      いはしていなかった。勘違いだった。

      結局何れも勘違いだった。

    2023-07-18 更にまた別の人からも報告があった。 Ubuntu 18.04 LTS も 1.3.3 を
    使っているらしい。仕方がないので対応する事にする。

    mawk がダメという事は何処かに記録していた気がするけれど何処かに行ってしまっ
    た。と思ったが、mawk-regex.sh (2023-05-19 12:09:13) というスクリプトファイ
    ルが残っていた。此処に#D2037 の時に実験したコードが残っている。

    * ところで ko1nksm さんに確認を取ってみても良いかもしれない。もしかしたら既
      に記事にしているかもしれない、と思って調べてみたが結局よく分からない。取
      り敢えず {m,n} については何かの記事に書いていた気がすると思って Qiita で
      検索したら以下のページが見つかった (Google で検索しても出なかった)。

      https://qiita.com/ko1nksm/items/17b8105f793953dc83c7

      更に Qiita で検索をしていたら以下のページも見つけた。このページには正規表
      現にまつわる互換性問題がまとめられている。然しここにも {m,n} は言及されて
      いるけれども、mawk の [:class:] に関しては言及されていない。

      https://qiita.com/ko1nksm/items/53abc144558b9bb5629f

2023-07-03

  * contrib/fzf-git: fzf-git 更新 (motivated by arnoldmashava) [#D2054]
    https://github.com/akinomyoga/ble.sh/issues/338

    gh という関数が gh (GitHub CLI client) と衝突している。fzf-git の upstream
    を見に言ったらいつの間にかに _gh に関数名を変更している。これが意味するとこ
    ろは元よりユーザーから呼び出すことは想定していなかったという事だろうか。更
    に、gist から github の通常の repository に移行している様だった。移行先では
    もっと大幅な refactoring が加えられている。移行先を track する様に変更する
    事にした。

  * history: history -w で空ファイルが書き込まれないという報告 (requested by Jai-JAP) [#D2053]
    https://github.com/akinomyoga/ble.sh/discussions/339

    先ず既に history が initialized されている時にはちゃんと書き込まれる筈の気
    がする。確認してみると _ble_builtin_history_initialized は初期化フェーズで
    設定される訳ではなくて飽くまで ble/builtin/history の初回呼び出しの時に設定
    される様である。

    そもそも何故この様な設計にしていたかを遡る必要がある。初期化フェーズに履歴
    が倍加したりする問題を避ける為にこの様な設計になっていた筈。

    #D1314 でこの辺りの振る舞いを導入していた。やはり履歴倍加問題の回避の為にこ
    の様に振る舞っている。

    * reject: 一応報告されたのは明示的に history -c を実行した後の問題であるか
      ら、其処で _ble_builtin_history_initialized=1 を設定してしまえば問題ない
      気がする。

    x ok: option:c で単に initialized=1 を設定すれば良い気がする。と思ったが
      bashrc の内部で history -c を実行した分は無視されて結局後で読み込まれる事
      になるので、その分は加味しないと行けないのではないのか。

      と思ったが既にそういう実装になっていた。問題は、 option:c であっても初期
      化前はスキップする仕組みになっているという事。

    こうなってくるとやはり以前の決断の通りに bashrc の内部では history の様々の
    操作は完全に無視する事にするしかない。一方で bashrc の内部にいるという判定
    をもっと厳しくする事はできるのではないかという気がする。

    1 bashrc の中かどうかの判定を行うのだとしたら最初にキー入力を受け付けた以降
      は bashrc の中ではないと判断できるのではないか。

    2 ok: 最初に bashrc の外で history -c を実行したという事が分かった時点で、
      それ以降は履歴が空であっても通常通りに処理するべきなのではないか。と思っ
      たがそれは元からそういう振る舞いだった。

    3 或いは単に ble-decode/.hook の内部から呼び出されているという事だけ見れば
      良いのではないか? と思ったが実際のコマンド実行は ble-decode/.hook の後で
      呼び出される hook 変数だった。それよりは edit.sh の .head と .tail の間に
      いる事を判定すれば良い気がする。然し、そういう変数は敢えて設定していない。
      見るとすれば stdout.on/stdout.off の状態だろうか。と思ったがこちらも敢え
      て状態管理はしていない。

      a だとすると .head 及び .tail の側に明示的に状態を設定する変数を新しく設
        置する?

      或いは既にある枠組みで何とかならないだろうか。decode.sh 関連は
      _ble_decode_bind_hook の内部で実行されるコマンドをカバーできないので駄
      目。_ble_attached だと、bashrc の中で attach して未だ抜けていない状態の時
      に駄目。edit.sh のコマンド実行関連だと、コマンド実行の外で実行されるコマ
      ンド (trap や PROMPT_COMMAND や bind -x など) がやはり漏れてしまうので駄
      目である。

      それを言い出したら .head/.tail に関しても、その外側で処理が走る場合がある
      のではないかという気もするが、今のところはその様な事はない気がする。Bash
      側のコマンド実行も行わないので余分なコードは全く実行されない。然し、将来
      的に異なるコマンド実行の枠組みができた時に .head/.tail の外側で実行して振
      る舞いが変だったという事になるのも嫌なのでちゃんと設計しておきたい気がす
      る。

      そもそも今欲しいのは .head/.tail の中かどうかという事ではなくて bashrc の
      外にいるかという事を判定する方法である。なので、それ専用の関数を作ってそ
      の他の場所に対する変更は最小限に留めるべきである。なので、.head, .tail を
      わざわざ状態に記録しなくても最初の .head の呼び出しまたは
      ble-decode/.hook 受信の時に変数を設定してしまえば良いだけである。

      b 既に keylog があるのであればその初回実行時に値を記録すれば良いのでは。
        と思ったがこれはループの大分内側にある様だ。やはり最初の PROLOGUE 呼び
        出しの辺りで何か値を設定するべきなのだろうか。

        うーん。ble-decode/.hook 自体に何回呼び出されたかの回数として
        _ble_decode_hook_count を記録する事にした。こうなってはコスト的には余り
        変わらない。

    取り敢えず _ble_decode_hook_count を導入し、それを参照して bashrc 内部でな
    い事が保証できる場合には history の処理をちゃんと実行する様にした。

    或いは PROMPT_COMMAND でそれが実行される事もあるだろうか? 然し、その場合に
    は ble-attach を bashrc から実行してその中から PROMPT_COMMAND を呼び出す場
    合を考えるとやはり履歴が初期化されていることを保証できないので、やはり
    history -cw は初回の PROMPT_COMMAND では無視される事になる。なので初回の
    PROMPT_COMMAND は動作保証しないという事にする。

    2023-07-03 実際に試してみたら動かない。history -w を実行しても何も書き出し
    がされない。うーん。 .write の実装を見たらそもそも histapp が空の時には何も
    実行しない様になっていた。これが原因である。

2023-06-29

  * edit (.newline): overwrite mode の表示は消すべき (requested by mozirilla213) [#D2052]
    https://github.com/akinomyoga/ble.sh/issues/337

    元々 overwrite のマーカーは実際に着色しているつもりでいた。これをカーソルだ
    と思っているのだとしたら確かに残るのは変だ。これは単に region 着色を解除す
    れば良いだけだろうか。と思ったが overwrite_mode はまた独立した layer だった。
    実装方法には二種類ある。

    a overwrite mode を解除してからコマンドを実行する

      overwrite mode は _ble_edit_overwrite_mode で管理されている。

    b もしくは _ble_edit_line_disabled と同様にして再描画の際に無効化するか。と
      思ったが、_ble_edit_line_disabled は C-c 等で灰色にする場合の物であって、
      最終描画に使う物ではない。しかも _ble_edit_line_disabled は各 layer を
      off にする機能ではなくて、disabled という layer を一番上に被せるという形
      で実装されていた。

2023-06-26

  * syntax: $(()) の中で "" が含められないということ (reported by mozirilla213) [#D2051]
    https://github.com/akinomyoga/ble.sh/issues/336

    動作を確認してみたら 4.3 では駄目だったが 4.4 以降では動く様だ。(()) ではど
    のバージョンでも動く。

    更に別の問題についても気づいてしまった。$((\10)) はどのバージョンでも失敗す
    るが、ble.sh は常に許容している。一方で、((\10)) は 5.0 までは動いていた。
    5.1 から動かなくなっている。また色々調べるともっと複雑である。

    context        expr = \10    expr = "10"    ASSIGNED NTYPE
    ------------   ------------  -------------  --------------
    $((expr))      false         bash >= 4.4    expr-paren-ax
    $[expr]        false         bash >= 4.4    expr-paren-ax
    $((a[expr]))   bash < 4.4    true           expr-brack-ai
    $[a[expr]]     bash < 4.4    true           expr-brack-ai

    ((expr))       bash < 5.1    true           expr-paren
    ((a[expr]))    bash < 5.1    true           expr-brack

    a[expr]        bash < 4.4    true           expr-paren-ai
    b[a[expr]]     bash < 4.4    true           expr-brack-ai
    ${a[expr]}     bash < 4.4    true           expr-paren-ai
    ${a[b[expr]]}  bash < 4.4    true           expr-brack-ai
    printf -v a[x] bash < 4.4    true           expr-paren-ai
    printf -v a[b[ bash < 4.4    true           expr-brack-ai

    ${v:expr}      false         bash >= 5.2    expr-paren-br?
    "${v:expr}"    false         bash >= 5.2    expr-paren-br?
    ${v:a[expr]}   bash < 4.4    true           expr-brack-ai
    "${v:a[expr]}" bash < 4.4    true           expr-brack-ai

    a=([expr]=)    true          true           expr-paren-di
    a=([b[x]]=)    true          true           expr-brack-di

    ? $["10"] はどうなのか → 4.4 以降では動く。うーん。全体的に改めてどの様な
      文脈で quote が許されるのか確認する必要がある。

    * うーん。'NQ(' の導入は割と古くて #D0375 である。取り敢えず新しい文脈を導
      入してしまう事にする。取り敢えず実装した。思ったがちゃんと反映されていな
      い。

    x fixed: $((\10)) でエラー着色になっていない。と思ったら単に新しく用意した
      関数 ctx-expr/.check-plain-with-escape を呼び出していなかった。呼び出す様
      にしたら期待通りに動作する様になった。

    * single quote 等の振る舞いは大丈夫なのか? → 調べてみた所 \10 と全く同じ振
      る舞いである。

    x 気づいてしまったのだが算術式中の a[expr] は更にそれがどの文脈だったかによっ
      て振る舞いが変わる。

    x reject: うーん。面倒な事に気づいた。${} や (()) の中では現在は [] の入れ
      子は追跡していない。しかし実際には quote の取り扱いが変わるのでそこまでちゃ
      んと対応しようと思ったらちゃんと追跡する必要が出てくる。しかし、一方で
      ${} や (()) の中では [] の入れ子は ${} および (()) 全体の終了に対しては考
      慮されない。うーん。

      これはまた two-pass parsing の問題である。((...)) を抽出する時には [ を無
      視して、次の解析で [ の入れ子を処理している。これはどうしようもないので対
      応しない事にする。

      → ページ上部の構文解析を諦めたものに追加した。

    * うーん。振る舞いが複雑すぎるのでテストを用意するべきの気がする →
      memo/D2051.sh に作った。

    x fixed: Bash では `echo 10` はいつでも有効の様だ。これに対応できていない。
      →対応した。

  * util: ble/builtin/readonly が bash options で壊れる (reported by dongxi8) [#D2050]
    https://github.com/akinomyoga/ble.sh/issues/335#issuecomment-1598485650

    readonly builtin: readonly BASH_COMPLETION_COMPAT_DIR がエラーになる。これ
    は何故だろう。Ubuntu 16.04 LTS でも再現しない。

    nocasematch? → これは nocasematch だった。nocasematch に対して耐性のある書
    き方をするか、或いは ble/builtin/readonly を他の ble/builtin と同じ様に
    bash オプションの保存・復元を行うかする必要がある。というか、set -xv 等の事
    を考えるとやはり保存・復元は実行するべきだ。

    ble/builtin/readonly の最初と最後で呼び出す事にした。

    ? 既に adjust-bash-options されている状態で呼び出しても問題ないのか気になる
      が、既に様々の関数でその様にしている事を思うと問題はないはずである。特に
      これらの関数は外側の状態を (グローバル変数ではなく) ローカル変数に記録し
      てそれをまた復元するという形を取っている。なので問題ない筈。

    2023-08-17 まだ問題があるという。然し問題が起こる理由が分からない。

    古い ble.sh をロードしてから後で新しい ble.sh をロードしている可能性もある
    のではないか。取り敢えず nocasematch / nocaseglob が怪しくてそれを修正した
    ら手元では再現しなくなった。

    a その他の可能性は bash-4.3 では問題が依然として発生するという事→再現しな
      い。

    b 或いは、Ubuntu 16.04 LTS だと問題が発生するという可能性→これも再現しない。

    c oh-my-bash と組み合わせると問題が発生するという可能性? → 特に問題は発生
      していない。

2023-06-12

  * complete: fzf-completion で生成された path が full path になる (reported by teutat3s) [#D2049]
    https://github.com/akinomyoga/ble.sh/issues/329

    これは fzf-completion が raw command line を利用して raw insert を意図した
    候補を生成するからそれに合わせて振る舞いを調整した事に関係している。然し、
    依然として一部の path 名に関しては bash は PREFIX を取り出して処理する様だ。
    例えば common prefix を取り出してその / 以前の部分を削除してしまえば良いの
    だろうか。或いは、COMPS について / 以前の部分を common prefix にしてしまえ
    ば良い気がする。

    →うーん。調べてみると既に compopt -o filenames が指定されている場合には
    progcomp 側で自動的に COMP_PREFIX を指定して補完が実行される事になっている。
    そして、fzf completion 側でも実際に compopt -o filenames を指定している様だ。
    然し、問題は COMP_PREFIX が COMPV を元にして構築されている為に正しく prefix
    除去が動いていないという事だった。ble/syntax-raw が指定されている場合には
    COMPS を元にして COMP_PREFIX を決定する様に変更する。

    x fixed: sabbrev 候補生成が通常候補生成よりも後になっているので、
      fzf-completion で何も入力がない状態から何か候補を選択したとしても、一意確
      定せずに sabbrev と fzf-completion で選択した候補の選択画面になってしまう。
      以前は sabbrev 候補をより前に生成していたので単純に既に生成された候補を全
      削除すれば良かったが、 #D2011 により候補の生成順序を変更した。

      sabbrev 生成も抑制する仕組みが必要になるのではないか。

      a -o bashdefault に代わる何か? → bashdefault は何も生成されなかった時に
        既定の補完を行うものなので関係ない。

      b compopt の拡張を行おうとしたら、どうやら既に ble/no-default というオプ
        ションが実装されている様だ。これは補完候補が生成されなかった時に
        fallback で既定の補完を実施しないという意味であるが、補完候補が生成され
        た場合の振る舞いにも拡張する事ができる。これを fzf-completion 側で呼び
        出させて、sabbrev 候補生成は ble/no-default が指定されなかった時に呼び
        出す様にすれば良い。

  * complete: support `bleopt complete_requote_threshold` (requested by rauldipeas) [#D2048]
    https://github.com/akinomyoga/ble.sh/issues/332

    本当に必要な機能なのか怪しいが面倒なので実装する事にする。

2023-05-23

  * [棄却] builtin: logout コマンドは上書きしなくても大丈夫なのか [#D2047]

    % 試しに logout を実行してみたらログインシェルではないという具合いにエラーに
    % なって何も起こらなかった。bind -x の内部からだと logout は実行できない仕組
    % みになっているのかもしれない→と思ったが本当にログインシェルでないと logout
    % は実行できない様だ。つまり SHLVL==1 という事か?

    実際にログインシェルで実行してみた所ちゃんと終了する。ジョブが残っている場
    合にもちゃんと一旦停止はする様だ。

    a 現在の振る舞いのままで良いだろうか。unload がちゃんと実行されているのか確
      認する必要がある→ちゃんと unload は実行される様だ。

    b 単に ble/builtin/exit に置き換えれば良いのだろうか。或いは、ble-detach と
      同じ様に logout という状態を設定して、その上で処理が終わった段階で終了を
      行うか。

      → ble/builtin/exit に置き換えるとログインシェルかどうかのチェックもなく
      振る舞いが変わってしまう。特に問題がない限りは logout はそのままでも良い
      気がしてきた。

      特に exit に介入している理由の一つは nix 等の設定で EXIT trap の中で更に
      exit を呼び出している場合など変な事をしている場合に無限ループになったりな
      どの問題が起こらない様にするための物である。

    取り敢えず現状のままという事にする。

  * stty: exit 後の stty 状態が壊れている in bash-5.2+ [#D2046]

    | 何故か bash --norc, bash, exit とした後に端末状態が壊れる様になった。何時
    | から起こる様になったのかを先ずは調べる。ble-0.3 では問題は発生していない。
    | つまり、やはり ble.sh の側の何らかの設定が関係していると思われる。
    |
    | 調べてみると 5b351e89 (2022-08-24) から発生する様になっている。今までずっ
    | と気付かなかったのも不思議であるが、たまたま bash --norc から bash を起動
    | する事がなかっただけなのかもしれない。或いはまた別の設定経由で動かなくなっ
    | たという事だろうか。問題は何だろうか。例えば exit trap が起動していない可
    | 能性がある? だとすると bgproc が放置されている事の原因も分かる。
    |
    | 取り敢えず stty がちゃんと呼び出されているかだけ確認する。どうやら最近ま
    | で気付かなかった理由が分かった。bash-5.1 では問題が発生しない。bash-5.2
    | および dev で問題が発生している。違いは bash-5.1 の中では EXIT trap は全
    | ての関数が抜けた後に発生しているのに対して bash-5.2 の中では EXIT trap が
    | 即座に実行されている事の様である。
    |
    | * うーん。stty 実行時に stdout,stderr が redirect されているのが原因かと
    |   も思ったがそうでもない様だ。stty 実行時に全てを /dev/tty に繋ぎ直したと
    |   しても問題は解決しなかった。
    |
    |   元々 stdin が残っていたがこれだけでもちゃんと動く筈という事の気がする。
    |   5.1 で stdout/stderr を潰しても動くか試してみる。うーん。5.1 だと
    |   stdin/stdout/stderr の全てを潰しても問題は発生しない。つまり、stty がちゃ
    |   んと効いているかどうかというのは実は今見ている問題とは関係がないという
    |   事だろうか。
    |
    |   うーん。やはり readline の終了時に stty を何か元の状態に復元する段階で
    |   変な事になっている気がする。然しそうだとしても ble.sh による再調整が走っ
    |   ているという訳でもない気がする。
    |
    | そもそも ble-detach で抜けた時には問題は発生していないか→ble-detach で抜
    | けた時には特に問題は発生していない。ble-detach で抜けた時には echo はちゃ
    | んと入っている様だ。一方で改行も無駄に echo されている気がする。

    [まとめ] この問題は bash-5.2 以降で trap EXIT がその場で実行される様になっ
    た事で、trap EXIT が bind -x の内部で実行される様になり、内部で実行した
    stty 復元の効果が bind -x 終了時に元に戻されてしまう事によって起こる。bind
    -x の外で trap EXIT を実行する方法があれば良いが今の所はその様な方法は見つ
    かっていない。

    a 可能性として一旦 detach してから exit するという可能性? C-d で終了を試み
      る場合には一旦 detach (もしくは ble/term/stty/finalize だけ実行) してから
      終了するのは技術的には不可能ではない気がする。然し、exit を実行された場合
      にはその様に一旦 readline に制御を戻す余裕もない。

      exit を強制的にキャンセルして、exit を emulate して top-level に戻り、更
      に detach を行ってから自前で exit をするという事も技術的には可能だろうか。
      然し、exit の振る舞いを正確に再現するのは難しいのではないかという気がする。
      特に redirections 等の復元はどうするのかなど。

      % というか一旦 trap EXIT が発火した時点でキャンセルする方法はない気がする。
      % と思ったが現在の議論はユーザーは上書きされた exit か logout を用いて終
      % 了するという想定をしている。

    b 或いは subshell で遅延してから stty を実行するという手があるだろうか? 然
      し、それだと例えば呼び出し元の shell がやはり ble.sh だった時に、遅延され
      て stty が実行されて stty が予期しない状態になってしまう。readline の収量
      処理が終わった後にその subshell が終了するまでブロックする仕組みが必要に
      なるが、その様な方法はない気がする。

    c 或いは諦めて呼び出し元が ble.sh session でない場合には stty sane を実行す
      る様に指示するメッセージを出す? 然し、端末の top-level だと常に表示されて
      しまい一々報告が来る事になる気がする。

      tty の一番大元であるかどうかを判定する方法はあるか?

      a reject: SHLVL? と思ったがこれは tty とは関係なく入れ子のレベルをカウン
        トするので screen や tmux でもカウントされてしまう。やはり端末の
        top-level かどうかを判定する必要がある気がする。

      b reject: 現在の session leader かどうかを調べれば良いのだろうか。然し、
        現在のプロセスが session leader かどうかを判定する方法はあるのか。
        session id がそのまま process id であれば良い様だ。session id は procfs
        があれば /proc/$$/sessionid から読み取れる様だ。然し、これを調べてみる
        と screen では単に screen が起動した session の id が全ての buffer に継
        承されている様に見える。なので使い物にならない。

      c 或いは単に PPID の tty をチェックすれば良いのかもしれない。と思ったが
        pid から tty を抽出する方法がよく分からない。ps ができているのだから
        procfs でのやり方はある筈と思ったがよく分からない。単に /proc/$$/fd/0
        を読み取るしかないのだろうか。でもその為には readlink を呼び出す必要が
        ある。外部コマンドを呼び出す必要があるのであれば単に ps を呼び出すのが
        早い。

      或いは tty の大元であるという判定ができるのであれば、その上でもっと積極的
      な修正を試みる可能性もある?

      * reject: サブシェルから stty sane? もし親プロセスが ble.sh でないのであ
        れば問答無用でサブシェルから stty sane を実行してしまっても良い様な気も
        するが、親プロセスが即終了して更に更に親プロセスに制御を戻す場合に、そ
        の更なる親プロセスに stty sane が影響を与えないかどうかは非自明である。
        というかそもそも親プロセスだって raw モードで文字列を読み出したいと思っ
        ている可能性もある。という事を色々考えるとサブシェルから stty sane を呼
        び出すのはやはり問題がある。

    仕方がないので取り敢えずは c の方針で stty sane を実行する様にメッセージを
    出す事にした。結局現状では疑わしい状況の時にメッセージを出すだけであるが仕
    方がない。

2023-05-21

  * syntax: bash-5.3 ${ list; } 対応 [#D2045]

    * ble/util/assign の置き換え

      * set -m 等をして独立した PGID が作られるかの確認。この振る舞いが
        util.bgproc からの要求になっている。

        echo "$(set -m; sleep 5 >/dev/null & pid=$!; ps -o pid,ppid,pgid "$$" "$pid")"

        これは作られないと分かっている。

        echo "${(set -m; sleep 5 >/dev/null & pid=$!; ps -o pid,ppid,pgid "$$" "$pid")}"

        これはちゃんと作られる。OK。因みに

        echo "$( (set -m; sleep 5 >/dev/null & pid=$!; ps -o pid,ppid,pgid "$$" "$pid") )"

        も作られる。なので元々其処まで気にしなくても良かったのかもしれない。

      取り敢えず ble/util/assing を ble/util/assing に置き換えてみたがこれで実
      行するとエラーが沢山発生する。これは既に報告されているエラーである。これ
      が修正されるのを待って改めて置き換えて動作確認を行う。

      取り敢えず Oguz の報告した以下の問題が解決されたようである。今のところは
      何の問題もなく動いている。取り敢えず push して良い気がする。
      https://lists.gnu.org/archive/html/bug-bash/2023-05/msg00045.html

    * syntax 対応

      * 振る舞いについて調べる

        説明に書かれているのには反して ${(echo);(echo)} も動くし ${(echo) } も
        動く。ちゃんと直感的な実装になっている。

        ${ { list; } } もちゃんと {} の入れ子を考慮した実装になっている。一方で
        これを ble.sh の側で対応しようとすると {} の入れ子を追跡していない。

      [実装]

      a 改行判定の時と同じ様に {} の数を数えて処理すれば良いかとも思ったが、そ
        うすると解析状態とは別の状態に依存する様になってしまうので駄目。

      b 或いは nest の中に {} のカウントを保存する?

      c もしくは解析状態に {} の入れ子を記録する。

      d 或いは {} の入れ子もちゃんと処理する様に変更する。

      現実的に d の方向で実装するしかない様な気がする。或いは

      e ${ ... } の内部の {} の時にのみ入れ子を数える。

      うーん。算術式ですら [] で nest を作成しているのだから {} で入れ子構造を
      作るのが妥当の気がする。

      何れにしても取り敢えずは実装を考える。

      うーん。やはり単純に数える方が実装が楽なのではないか。現在の実装だと for
      ... { ... } 等に於いて for と } を組みにしてちゃんと構文が閉じているかを
      判定している。ここで {} を入れ子にして解析する事にすると、for も一緒に入
      れ子解析を実装しなければならなくなる。然し、単純に数える実装にするとやは
      り状態をどのように記録するのかという問題が生じる。或いは、{} で nest 構造
      を作るにしても keyword の begin/end は今までと同じ様に取り扱う。それで良
      い気がする。

      最終的に d で実装したが実は簡単だった。

    2023-06-12 結局 ${( は対応しない事になったようなので削除する。もしかすると
    これは zsh の attributes との互換性を考えての可能性もある。

2023-05-16

  * main: --inputrc=TYPE の設定を適用する前に read-inputrc を呼んでいる [#D2044]

    osh を実行していて気づいたが --inputrc=none が効いていない。一方で最近の
    issue のデバグで効果があった様に見えたのは謎である。
    https://github.com/akinomyoga/ble.sh/issues/322#issuecomment-1539265410

    取り敢えず修正は適用しておく事にする。

  * util: idle.do 無限ループ [#D2043]
    Ref #D1980 (2023-02-27)

    Ubuntu で idle.do が無限ループになっている。どうやらファイル待ち状態になっ
    ているが sleep を全くしていない様である。これは 559d64b8 の regression であ
    る。条件式が微妙に間違っている。

    また、これが最近 bash の処理量が多い理由なのではないかという気がする。約二ヶ
    月半の間、idle.do が無駄に無限ループしていたという事になる。

    * それとは別に何故ファイルが作られずに失敗しているのかという問題がある。うー
      ん。VM の中であることによって何らかの事故によって git がクラッシュしてい
      る等?

    * それから core-debug-def.sh が ble/debug/profiler/end を export しているが
      実際に定義されるのは ble/debug/profiler/stop である。修正した。

    2023-05-16 無限ループは直っていない。と思ったら物凄く簡単なミスをしていた。
    修正する。

2023-05-14

  * progcomp: _parse_help 経由で生成された項目に uniq をかける? [#D2042]

    bash-completion が重複したオプション項目を出した時に ble.sh はそれにそのま
    ま記述を追加してメニューに表示するので同じ候補が二つ表示されてしまう。

    sed --e[TAB]

    うーん。既に uniq はかけられている。問題は bash-completion が --expression
    と --expression= を両方出すが、ble.sh が --expression を mandb によって補填
    して --expression= に変換する事である。そもそも bash-completion が両方出す
    のも変な事なので、どちらか一方を出力するので問題ない。

    オプション候補に対して説明を付加する時点で = を除いた状態で重複がないかチェッ
    クして、その上で出力する様に修正する事にした。

2023-05-13

  * progcomp: _parse_help の代わりに新しい _comp_compgen_help に介入 [#D2041]

    新しい実装は _parse_help ではなく新しい関数名に対して advice を仕掛ける必要
    がある。

    うーん。

    x fixed: 今までの実装で _parse_help - に対しての介入がちゃんと動いているか
      怪しい。この実装だと本来 _parse_help が読み取る筈だった stdin を盗んでし
      まうのではないか。キャッシュが一旦出来上がればもう読み取らないので問題な
      い。

    * ok: 実装チェック。bash-completion 2.11 の iperf -[TAB] が _parse_help -
      を呼び出す。ちゃんと動いている。その他の場合についても

      $ awk -F "$_ble_term_FS" '{print $1}' "$subcache" >/dev/tty
      $ echo $(awk -F "$_ble_term_FS" '{print $1}' "$subcache") >/dev/tty

      でチェックする。sed -[TAB] は _longopt で smartctl -[TAB] は _parse_help
      "$1" のテストになる。bind -[TAB] は _parse_usage のテストになる。取り敢え
      ず何れも期待どおりに動いている。

      bash-completion 2.12 の方でもちゃんと動く事を確認した。

  * cmdspec: その他の builtin のオプションの対応 (motivated by EmilySeville7cfg) [#D2040]
    https://github.com/akinomyoga/ble.sh/issues/325#issuecomment-1545474274

    これらは bash builtin なので man で情報を正しく抽出できない。代わりに help
    builtin で取得する必要があるが、これは明示的に指定する必要がある。

    * reject: builtin コマンドに対する既定の cmdspec を定義する? 或いは type で
      builtin だったら fallback として builtin 用の cmdspec を既定で適用する可
      能性? と思ったが ble/cmdspec/opts は補完専用の枠組みという訳でもなく、必
      要もないのに type で builtin かどうかを確認するのを既定で行うのも憚られる。
      やはり、一つ一つ全部指定した方が良い様に思われる。

    * done: pushd, popd, dirs の -N/+N の実装

      pushd に関しては既に core-complete の中で cd と一緒に実装していた。それに
      追加する形で popd と dirs も実装する。

    * mandb-help=@-- が認識されていないのは何故か。どうも明示的に無視されている
      様である。同じ mandb-help=@ に指定していても -- だけは認識されていない。

      或いは実装上の都合で意図的に -- を除外しているのだったか? と思ったが思い
      当たる事はない。実際に動作を追っていくと mandb の段階では -- はちゃんと生
      成されている。何処かで消滅しているという事だろうか。

    取り敢えず対応した。

    x ok: pwd の man-disable-man が効いていない気がする。man pwd から拾ってきた
      オプションを表示している。と思ったが単にキャッシュが更新されていないだけ
      だった。

    x test の disable-double-hyphen が効いていない。と思ったら
      disable-double-hyphen は別の用途だった。新しく mandb-exclude という項目を
      作る事にした。

2023-05-12

  * progcomp: cd の short flag 補完で文字そのものを候補として表示しているが分からにくい (requested by EmilySeville7cfg) [#D2039]
    https://github.com/akinomyoga/ble.sh/issues/325#issuecomment-1545474274

    cd の short option 実装で -xxx の中に含まれる short option を選べる様にしよ
    うとしている。この関係で表示される候補は -c ではなくて文字そのもの c である。

    * done: 表示文字列は -c の形にする。ここで実際に挿入される文字列はともかく
      として表示状は -c 等の様にする事はできるだろうか。或いは最初のオプション
      だけは - 付きで表示して、short flags の二つ目以降はその文字その物を補完す
      る様にするのが簡単で良いだろうか。しかしその文字だけを表示するのも何だか
      変な気がするし、絞り込みをする際にも何だか変な気がする。という事を考える
      とやはり表示状は常に - になる様にするのが良いだろうか。→取り敢えず表示さ
      れる文字列に関しては - をつける事にした。

    * done: 本来は desciption を help から拾って来たい。mandb を呼び出して一緒
      に表示する様にしたい。取り敢えず実装した。

      これは汎用性があるので関数に分離したい気がする。分離した。

    x reject: 一意確定を mandb を用いて行うと補完確定時に空白が挿入されない。
      word だとちゃんと挿入される。何故か。と思って改めて実行してみたらちゃんと
      動いている。何かの勘違いか。

    * fixed: -@ に対する説明を抽出できていない。

      これは実装を調べていたら _ble_complete_option_chars という変数でオプショ
      ンとして許される文字の集合が管理されていた。これに @ を追加すれば良い。

    * fixed: -P に対する説明が help 出力の関係ない部分を拾っている。それらしい
      物が複数見つかった時にどちらを優先させるのかについて決める必要がある。例
      えばより長く空白が間に入っていたものを優先させるなど。現在の実装だと引数
      らしい物がくっついていた場合にそれを優先する様になっているがそれは変だ。

      或いは空白が複数続いている物を優先させる等の処置が必要かもしれない。単一
      空白しか行内に含まれていない物については優先度を下げるなど。完全に排除し
      てしまうとそれはそれで説明抽出できない物が発生するかもしれない。

      優先順位を計算して記録する仕組みを作るのは大変だと思ったが改めて実装を確
      認したら既にそのような仕組みが実装されていた。但し、インデントベースで決
      定されている。つまり、インデントの深さが浅い物を優先させる様になっている。
      空白が一つも含まれていない行の場合には優先順位を 100 だけ下げるのような感
      じの処置を追加で実装すれば良い。

      実装した。動いている。

    x CAND を勝手に変更して実装しているが本当にそれで良いのか? CAND は
      menu-filter にも使われれているので実際に挿入する物と異なる物を設定すると
      メニュー項目が消滅する等して面倒な事になるのではないか。

      本来は固有の action を割り当てて表示の時に内容を書き換えるべきなのではな
      いか。

      改めて実装を見てみたら表示の時に prefix を設定できる。という事は - を追加
      するのも簡単である。新しい action mandb.flag を定義して実装した。動いてい
      る様に見える…が座標位置の計算がずれてしまう。

    2023-05-14 オプションの着色にも @ を含めるべきではないのか。これは
    ble/progcolor/word:default/.is-option で判定している。正規表現を確認すると
    alnum _ しかチェックしていない。

    x menu-filter による再描画で prefix が表示されず、更に座標位置がずれる。

      どうも menu-filter による再描画の際に prefix が正しく描画されていないのが
      原因の様である。menu-complete による選択時には問題はない。という事は再描
      画の際にやはり問題になっているという事。

      →うーん。分かった。一致着色部分を構築する時に local out= を実行してしまっ
      ている所為で prefix の中身が消えてしまっている。修正した。

      これは 0.3 では影響ないだろうか → うーん。0.3 でも影響がある。修正する必
      要がある。独立した commit にするべきの気がする。

  * mandb: Ubuntu で echo に対する解析結果でオプションと説明の単語がくっつく (reported by EmilySeville7cfg) [#D2038]
    https://github.com/akinomyoga/ble.sh/issues/325

    制御文字を全て削除する段階でくっついてしまう様だ。何故か環境によって TAB を
    使ってオプション名と説明の間を区切っていたりそうでなかったりする様だ。取り
    敢えず TAB は空白に変換する事にした。空白一つに変換すると距離が近すぎる事に
    よってオプション引数と間違われる。2つでもオプション引数と解釈する様なので 3
    つ以上である必要がある。きりの良い 4 空白に置換する事にする。

  * main: Ubuntu では nawk という名前で gawk が入っている [#D2037]
    https://github.com/akinomyoga/ble.sh/issues/322#issuecomment-1543766152

    こういうおかしな事をするから Ubuntu は駄目だ。他の os はそんな事はしていな
    い。取り敢えずバージョン文字列を nawk に対してはチェックする事にした。

    バージョン抽出する為に awk --version のような具合にしていたがこれだと mawk
    が動かない。-W version と --version の両方を試す事にした。また、nawk は単に
    nawk -W version とすると標準入力を読み取る状態になってしまって固まってしま
    うので </dev/null をリダイレクトする事にした。

    但し、これを修正しても echo の補完の問題 #D2038 は解消していない。echo の補
    完の問題に関しては独立にちゃんと修正する必要がある。独立な項目で修正する。

2023-04-12

  * 2023-03-24 histdb: sqlite3 がクラッシュする? [#D2036]

    或いは timeout した物の情報が同期されていなかった可能性? timeout をより短く
    して再現するかどうか確認する必要がある。

    2023-04-12 これは頻繁に起こっている。と思って改めてコードを確認してみたが、
    どうもクラッシュしていても自動で停止していても #alive は false になるので、
    #alive でなかったからと言ってクラッシュしたという訳ではない。クラッシュした
    かどうかの判定をしたければまた別の関数を作るしかない。然し、わざわざ別の関
    数を作ってチェックする必要があるのかも分からない。然し、現在はテスト段階で
    もあるしやはり微妙な失敗でもちゃんと検索して表示する様にしたい。

2023-04-09

  * chore: 古いテスト用のファイルや説明用のサンプルを保存する [#D2035]

    * gitignore を更新して表示から除外するものを増やした
    * e.sh は refact.sh に合流。

    未だ幾つか残っているが取り敢えずはそのままにする。

  * bgproc, conditional-sync: support opts "kill9-timeout=TIMEOUT" [#D2034]

    * fix(conditional-sync): pid が opts で指定されていない時に、グローバルの
      __ble_pid を変更してしまう問題の修正。色々書き換えている時に残ってしまっ
      た && を削除する。

    ? OK: kill -9 の 9 はシステムに依存しないと思って良いのか?  POSIX の kill
      によると SIGKILL は 9 であると定められている様だ。なので気にしなくて良い。
      https://pubs.opengroup.org/onlinepubs/9699919799/utilities/kill.html

    * bgproc: kill9-timeout で SIGKILL までの timeout を指定できる様にした。

  * 2023-04-05 bgproc: exec に関する説明を書く [#D2033]
    https://github.com/akinomyoga/ble.sh/discussions/309#discussioncomment-5527375

    またサブシェルに fd が継承されるという事についても述べる。

    →色々書き加えた。

  * 2023-04-05 README: Guix package のリンクが壊れている [#D2032]

2023-04-08

  * util (conditoinal-sync): opts に指定した pid=PID/-PGID が動かない (contributed by bkerin) [#D2031]
    https://github.com/akinomyoga/ble.sh/discussions/309#discussioncomment-5556211
    https://github.com/akinomyoga/ble.sh/pull/313

    これは conditional-sync を弄って外部から pid を指定できる様にした時のバグ
    https://github.com/akinomyoga/ble.sh/commit/8d623c1927c2c4e381bd484bcc51def3213890f6

    先ず PGID を指定すると kill がシグナルと勘違いして動かない。次に timeout=0
    を一緒に指定すると既存の pid があっても kill を試行せずにそのまま終了してし
    まう。

    提案では負の時にだけそのまま終了する様になっていたが、負であっても pid が指
    定されていればちゃんと kill して終了する様にしたい。調整する。

    ----

    2023-04-09 GitHub CI で Windows が失敗している。手元の cygwin で試すと何故
    か sleep 10 を kill しても全く効果がない。然し、プロンプトを跨いで kill を
    実行するとちゃんとその場で動く。色々実験した結果 subshell を少なくとも一回
    以上立ち上げた後だと kill が効く様である。これは kill -- でも kill -9 でも
    同様である。

    $ tkill() { kill -9 "$p"; ((count++)); sleep 0.01; }
    $ sleep 10 & p=$!; count=0
    $ (true)    # <-- これがあるかないかで必要な kill 回数が変わる
    $ tkill; while kill -0 "$p"; do tkill; done; date +'%s.%N':$count

    然し、CI test に関しては単に delay を入れるだけで解決してしまった。然し、場
    合によってはやはり kill できないという状況になると行けないので念の為
    Windows では subshell を一つ作る事にする。
