note.txt

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

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

  * Konsole MR !951 はどうなった?

  * 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-07-31

  * bash <= 4.4 & contra & mercury で矢印キーが動かない

    bash-4.4 で矢印キーが動かなくなっている。bash-3.2..4.4 の全てで動かなくなっ
    ている。

    % contra では起こるが xterm では起こらない。mintty でも起こらない。contra
    % 特有の可能性もある。bash-5.0 以上では動いているので contra が悪いという事
    % ではない気がする。 ESC O A 等の形式でキーを送信する端末において発生してい
    % る。これは bind の問題の様な気がする。
    %
    % と思ったら再現しなくなった。どうも、一旦 mercury にログインした事のある
    % contra の仮想端末でなければ再現しないという事だろうか。再現しない時には
    % ESC [ A が送信されているが問題が再現する時は ESC O A が送信されている。うー
    % ん。ESC O をその場で処理するかどうかが関係している気がする。然し試してみ
    % たところ mercury にログインしても front1 にログインしても再現しない。再現
    % 条件が分からない。こうなると xterm や mintty で起こらなかったのも偶々の可
    % 能性がある。
    %
    % chat 経由で mercury に入っても再現しない。screen の中から mercury に入っ
    % ても再現しない。chat の中の screen の中の mercury でも再現しない。

    分かっている事: 端末が矢印キーに対して ESC O A を送信する状態になると
    bash-4.4 以下で問題が発生する。然し、どのようにしたら端末が ESC O A を送信
    する状態になるのかの再現方法は不明。

    2023-08-02 再現方法が分かった。screen に入った状態で接続が切れたりして抜け
    ると中途半端な状態になって ESC [ A の代わりに ESC O A が送信される状態にな
    る。更に、この状態では bash-5.0 以降であっても矢印キーの振る舞いが変である。
    複数行コマンドラインに於いて上下キーで行の間を移動したいが、ESC O A になっ
    ている時には履歴項目の間の移動になっている。何故この様な違いが出るのかはよ
    く分からない。kpup などに翻訳されているという事だろうか。また再現した時に
    keylog でどのような受信・翻訳になっているかを確認する事にする。

2023-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-04-13

  * bash が `vi-edit-and-execute-command' を追加している。

    これは自分が以下で報告した事が元になっているのだろう。
    https://lists.gnu.org/archive/html/help-bash/2022-02/msg00031.html

    d70b5339 で追加されている。つまり help-bash で発言した次の日には修正が入っ
    ていたのだった。

2022-03-19

  * 編集文字列に含まれる制御文字の反転表示の可能性

    現在は見た目には区別がつかない。プロンプトシーケンス \w, \W, etc に含まれる
    制御文字については反転の toggle で対処している。

    一方で、現在の実装だと単純に編集文字列に含まれる制御文字の反転状態を変更す
    る事はできない。着色に関係なく制御文字の表現を決めている、つまり地の反転状
    態に関係ない escape sequence を決める必要があるが、地の反転状態が分からなけ
    れば制御文字が終わった位置で正しく反転状態を復元することができなくなる。

    これについてはまた今後必要性を感じた時に実装すれば良い気がする。

2022-03-03

  * 起動時の fork について

    * ble/base/adjust-builtin-wrappers/.assign (2 fork) ... 此処で builtin,
      alias を保存する為に2回に分けて defs=$(...) を実行している。この時点では
      初期化が終わっていないので ble/util/assign は使えない。

      これはそもそも勝手に上書きした builtin や alias を保持する必要があるのか
      という事を考えるとスキップしても良い様な気がする。起動の高速化の為にこう
      いった物を省略するオプションを用意して良い様な気はする。

    * ble/util/msleep/.check-builtin-sleep ... これはロードに失敗した時の事を考
      えて subshell 内部で実行している。

      これも sleep の方法を予め引数等で指定する仕組みを用意しておけばスキップす
      る事は可能である。また builtin sleep に頼り切るのも問題の気がする。という
      か builtin sleep だと C-c が効かない等の問題がある。

      改めて plain Bash に builtin sleep を読み込んで動作を調べてみる。と思った
      が再現しない。というよりそもそも ble.sh をロードしていても bash-5.0 でし
      か再現しない。つまり bash-5.0 & ble.sh の時にだけ bultin sleep 3 で C-c
      に対して即座に実行が中止されない。ble-detach していてもこの問題は発生する。
      plain Bash で直接 enable -f /path/to/sleep sleep して sleep 3 に対して
      C-c した時にはちゃんとすぐに終了する。

    * ble/builtin/bind/read-user-settings/.reconstruct ... これは記録されている
      default bash の binding と、現在の binding を比較してユーザーが設定した
      keybinding を抽出する為に awk を呼び出している。

      これは既存の readline 設定を読み取らない事にすればスキップはできる。実際、
      ble.sh の読み込み時に --noinputrc を指定すればこれは実行されない。

    以上の物は何れもユーザーオプションで省略できる様な機能ではある。然し一方で
    ロードのボトルネックは実は fork ではない。少なくとも Linux では。但し、
    Cygwin では 50ms/fork かかるので 4 fork 省略できるだけで 200ms も時間を短縮
    できるので大きい。

2022-02-20

  * より一般の補完 framework に向けたインターフェイスについて
    https://github.com/rsteube/carapace/issues/431

  * compopt 実装: 現在の実装では "name" や -DEI が与えられた場合には何もせずに
    戻る様になっているが、本来現在の設定を変更するべきなのではないか。また、丁
    度変更対象の補完が現在の補完と一致している時には現在の補完の振る舞いに影響
    を与えるべきなのではないか。これについては実際の Bash の振る舞いを確認する
    必要がある。

  * rsteube の記事
    https://dev.to/rsteube/a-pragmatic-approach-to-shell-completion-4gp0

    filtering を description に対しても適用するという事が書かれている。それは確
    かに便利そうである。現状の実装では対応が難しい様には思われるが。これは fzf
    の様に一旦絞り込み専用の入力欄に移動するなどの事がないと使いにくいだろう。

  * trap (lastarg): 一応 heredoc 等を使えば eval の中から複数行の lastarg を設
    定する事ができるのではないか。他に複数行で、eval されても余分な実行が起こら
    ない様な方法はあるだろうか。不完全な引用符の場合には結局エラーが出力されて
    しまう。

    Ref #D1853

  * [保留] exec: builtin sleep に対して C-c が効かない

    % 現在の実装だと bash-5.0 以下で C-c でループ中に走っている外部コマンドを止
    % めた時に応答がなくなってしまう。bash-5.1 以上では一旦実行が停止するものの
    % 一応応答はする。

    と思ったらこの問題は外部コマンドではなくて builtin sleep を呼び出している時
    特有の問題だった。trap INT を設定しているのは問題なのだろうか。

  * edit: 現在の TRAPDEBUG の枠組みを拡張して try/catch/finally を実装できるのでは
    Ref #D1783

    もしその枠組がちゃんとできるのであれば edit.sh から util.sh に移動する。

2022-02-14

  * 全ての ble.sh session にコマンドを送る機能があれば screen に再 attach した
    時の再調整等に役立つのでは。

    _ble_term_TERM の最初期かもできるし、或いは DISPLAY 環境変数の再設定もでき
    る。チェックの頻度は history-share と同様で良い気がする。

  * ble/builtin/trap DEBUG は関数の入れ子や trace 属性などは考慮していない。こ
    の事によって問題が起こる可能性もある。

2022-02-12

  * highlight: ls -l ~/.c{onfig,a/b}
    ブレース展開の中に / が含まれているとディレクトリパス着色が動かない。

    うーん。そもそも highlight の仕組み的に / が含まれているとどうしたら着色で
    きるか謎という可能性がある? と思ったが恐らくそういう事ではない。何れにして
    も全体を一番最初に一致した PATH に対する色で同じ色で着色する様になっている
    筈。但し、その着色を実行する上で / で分割してから各 segment に対して着色す
    る様になっている為に、brace 展開中に / があると / で分断されてしまって正し
    く着色できないという事になるのだろう。

    ちゃんと対応する為には、"ブレース展開に対して最初の要素で着色をする" のでは
    なくて、ちゃんと各要素に対して着色をするという方向に改める必要があるのかも
    しれない。然し、それは実際の所面倒だし、そこまでする必要があるのかというの
    も謎である。これは優先度は低いがもし実装できたら面白いだろうという事である。

2022-02-08

  * [保留] compat: bind -x 実行後の再描画はプロンプト最後の行以降
    https://lists.gnu.org/archive/html/help-bash/2022-02/msg00023.html
    https://lists.gnu.org/archive/html/help-bash/2022-02/msg00031.html

    どうも bash で試して見た所 に於いてはプロンプトの一番最後の行以降だけが再描
    画の対象らしい。現在の ble.sh の実装だと全体を再描画している。これだと
    help-bash に投稿した様な hack が使えなくなる。

    a Bash と同様に途中から出力する様に調整すれば良い。と思ったが、よく考えたら
      現在の実装では prompt は一気に出力する事になっているので一番最後の行だけ
      出力するという話はない。

    b うーん。その場で clip すれば良いのかもしれない。然しそれは処理として重く
      なる。また、clip した場合には結局描画する時にはカーソルを相対移動させる事
      によってカーソルが本来の位置に戻ってしまう。つまり、hack は結局使えない。

    そもそも hack を使える様にするという発想がおかしいのだとも言える。特に件の
    hack に関しては ps1_final で代用できる。それ以外の目的で描画を乱すとしたら
    それはやはり対応外であるし、もしそういった描画に対する介入を想定しないので
    あれば、結局全体を描画するという現在の振る舞いで特に問題は生じない筈である。

2022-02-05

  * syntax: a=(%{1..10}) の % を '\x' に書き換える時文法構造が破壊 (?)

    $ bash
    $ rep=(%{25,08,0A,2{0..2},24,2{6..9},3B,3C,3E,5C,5E,60,7C})

    として起動した直後に上記の文字列を貼り付けて、それから先頭の % を削除して
    '\x' と入力したら文法構造が壊れてしまった。然し二度と再現しない。問題は '\x
    迄入力した時点で発生していた。もしかすると ' か \ を入力した時点で既におか
    しくなっていたのかもしれない。

2022-02-03

  * キャッシュの判定でファイルを使って判定しているが、よく考えたら現在ロードさ
    れているコードとファイルに含まれているコードが同じとは限らないのではないか。
    もし、現在のシェルの起動時刻よりも比較に使っているファイルのほうが新しい時
    は、ble.sh 自体を reload した方が良いのではないか。と思ったがそれによって失
    われる設定も考えられる。という事から勝手に reload する訳にも行かない。

    起動時刻(というよりble.shロード時刻)を示す一時ファイルを使うという手も考え
    られるが、それだと後になってロードした module の場合には不正確になる。と思っ
    たが、古いコードを使って更新を実行してしまうよりは、新しいコードなのに古い
    情報を更新せずに利用するという位の方が未だましである。

    実はロード時刻は $_ble_base_run/$$.load に既に存在しているのでそれを使えば
    良い。

    検索してみると結構影響のありそうな箇所は沢山ある。一方で具体的にどの様に直
    すのか。load time だけで判定すると毎回キャッシュを更新する事になってしまっ
    て意味がない。(キャッシュが最新でない) & (load time よりも前に元のファイル
    が更新されている) という条件で判定するのが良い気がする。

    * キャッシュが最新でないというのは必須の条件である。そうでなければそもそも
      更新を実行する意味がない。load time が元ファイルより最近の場合にも何も問
      題は生じないので今迄通りに何も気にせずに更新すれば良い。

    * 従って、特に判断が難しいのは (キャッシュ),(LoadTime) > (元ファイル) の場
      合である。更に元ファイルを source した時刻は実は元ファイルよりも後の可能
      性もある。その時にはメモリ上には最新版があるのでそれに従ってキャッシュを
      更新しても問題ない。

    * よく考えたらここで対策をしても問題は生じるのではないか。元々キャッシュファ
      イルが存在しなくて、メモリ上に古い version の関数があって、それに基づいて
      新しくキャッシュを作成した場合、古い version のキャッシュがずっと残ってし
      まう。

      うーん。load time で time stamp を書き換える様にすれば良いのだろうか。

2022-01-23

  * "for ((i=0;i<10;i++)); do sleep 1; done" で C-c すると ble.sh 全体がその場で停止する

    これは外部コマンドを実行中にそのコマンドが SIGINT で終了した場合、trap INT
    に登録されたハンドラーを介さずに即座に実行全体が終了してしまうのが原因であ
    る。

    もしそれがトップレベルのコマンドであれば ERR を用いて捕まえる事はできる。但
    し、それが SIGINT によって引き起こされたものなのか、普通のエラーとして返さ
    れたのかを判定する方法はない。

    更に関数内で実行された場合には ERR でも INT でも捉えられない。RETURN を使っ
    ても捕まえられない。これを解決する方法はない気がする。

2022-01-08

  * mandb: echo のオプションの抽出 (help echo) がおかしい at fc35 vm
    chatoyancy では問題は発生していない

2021-12-22

  * ディレクトリ固有の local commands & aliases を可能にする?

    一方で、勝手に設定をロードする様にしてしまうと怪しいディレクトリに入っただ
    けでそれが有効になってしまうという事が発生する。なので、一旦は enable する
    操作を求めるべきだし、また内容が変更されたらその都度承認を求めるべきである
    (過去に承認したものは hash か或いは実体を記録しておいて再度尋ねはしない様に
    できる)。

    →direnv が丁度同じ事を目的としたプロジェクトの様である。

    2023-01-30 direnv が一体どういう事をしているのかについて調べる → #M0023 に
    纏める事にした。

2021-12-20

  * git-prompt, git-status 等の機能の模倣?

2021-12-18

  * contrib/git: dirty で rps1 が更新された瞬間にカーソル位置がずれた。これは後
    で調べる必要がある。

  * deprecated functions の枠組みを整える。

    散発的に deprecate して行くと毎回設定を変更しなければならず面倒なので、
    version を指定して特定の version 以降になった時に限り初回だけ警告を表示する
    様にするのが良い。

    ((_ble_version>=500)) && ..... と言った具合。

    ? reject: deprecation は version ではなくて独立な番号付を使う可能性?

      →omb において考えていたが、これは特定のバージョンを予め指定するよりは
      deprecation level の様な 1 個ずつ増える整数にするのが良い。というのも、そ
      もそもどの version で完全廃止するのかというのは廃止を決定した瞬間には分か
      らないという事。そして、実際に廃止する瞬間には基本的には全て一度に廃止す
      るのであって、機能によって廃止したり廃止しなかったりという事はない。なの
      で基本的には、新しく廃止をマークする時には次の deprecation level を指定し
      ておいて、deprecation level が上がる時に一斉に廃止するのが良いと思われる。

      一方で、もしかすると緊急で廃止したいという状況が現れるかもしれないので、
      deprecation level は基本的には 100 の倍数にして置いて、細かい廃止を実行し
      たい時に限って 1 ずつ上げる様にするというのも手である。と思ったがその様に
      考えると結局それは _ble_version と同じになるのではないかという気もする。
      但し、基本的に廃止等は master でしか起こらない気がするので patch level と
      deprecation level に関してはずれが生じるだろう。

      また minor version とは無関係に廃止するという事があるのかも分からない。と
      いう事を考えるとやはりその意味に於いても ble.sh に於いては deprecation
      level と version は一致させて良いのではないか。という気がしてきた。

  * complete: FIGNORE と -o filenames

    どうやら元の bash では -o filenames が指定された時にのみ FIGNORE が使われる
    様である。一方で、現在の ble.sh では FIGNORE が設定されている時には強制的に
    fignore が実行される様になっている気がする。と思ったらこれは shopt -s
    force_fignore の設定を参照しての事だった。よく分からないのは bash は
    force_fignore が設定されていても、-o filenames が指定されていなければ
    FIGNORE が有効にならない様だという事。

    * FIGNORE で全て候補が消えた場合には FIGNORE を無効化して全て採択するべきで
      は? と思ったが元の bash ではその様な取り扱いはしていない。

    * Note: bash FIGNORE は glob は解釈しない。bash FIGNORE はそれが実際には存
      在しないファイル名だったとしても、FIGNORE に一致すれば候補削除する。bash
      FIGNORE は候補が FIGNORE で全滅してもそのまま。bash FIGNORE は単一候補だっ
      た時にも FIGNORE を適用して候補を消す。

2021-12-14

  * compat: RLogin で ble-detach した後に modifyOtherKeys の状態がおかしい。
    bash --norc してもおかしい。RLogin である事は検出できている。

  * compat: terminator で status_line で表示が崩れる
    →これは今確認した所再現しない。terminator ではなく terminology の可能性?
    或いは古い vte の問題だった可能性もあるかもしれない。

  * compat: mlterm 起動時に表示が乱れる with statusline

    →これは単純に初期の char_width_mode,char_width_version が一致していない事
    による問題だった。始めから east にしておけば乱れは生じないという事は確かめ
    た。然し、auto で幅を判定する迄の表示の乱れは一般の問題ではないだろうか。

    乱れを最小限にするには文字幅を大きめに取るという意味で east で始めるという
    手もあるかもしれないが、実際には west の端末の方が多いという事を考えると別
    の問題が出てくる可能性がある。また、CPR に応答しない端末の場合ずっと east
    という事になってしまって問題である。起動して暫くは east にしてそれから west
    になるという様な感じの物を auto で判定中の幅にするべきだろうか?

  * C-backspace の問題 (端末自動判定?)
    https://github.com/akinomyoga/ble.sh/issues/94
    https://github.com/akinomyoga/ble.sh/issues/104
    https://github.com/msys2/MSYS2-packages/pull/2490
    https://github.com/microsoft/terminal/issues/755

    以前に色々の端末の動作を調べたと思ったが記録が全く残っていない。辛うじて上
    記の MSYS2 にどのようなパターンがあったかが記されているが、それぞれどの端末
    がどう振る舞っていたかの情報はない。改めて調べる。→ wiki にまとめた。

    うーん。^? と ^H が異なる形に bind されているという事は。。。どうしようもな
    い。既定では両方とも backspace だと思って置くしかない。ユーザーが自分で設定
    をする時にちゃんと判定するのが良い。

    もしくは端末を自動的に判定して C-h, C-_, etc を C-BS に置き換える設定を行う
    という事も考えられる。

2021-12-11

  * declare の引数チェックをもっと真面目に実装する。chroma のインターフェイス
    設計の足がかりにする。

    * wattr=- (未着色) の時にのみ着色しているが、実際には一つでも未着色があった
     らそれ以降の引数に対して与える影響を考慮に入れなければならない。但し、これ
     を実行すると毎回ファイル名着色が全て計算されるなどの様な形になりとても遅く
     なると思われるので、未だ実装しない。

      これは一般の問題なので別項目で議論するべき気がする。mandb_opts 等を用いて
      指定する可能性。

    * declare: -f, -F が含まれる場合には関数名として任意の名前を含む事ができる。
      というかオプション名も含む事ができる? (declare -F -f とした時の解釈はどちら
      になるのだろうか?)

    * 変数代入の形式をしていない引数に関しては中身によってOKかもしれないし駄目
      かもしれない。

  * refactor: highlight-variable というインターフェイスを作る。

    と、思ったが quote 等も考えるとそういった関数を提供する事に意味があるのか
    分からなくなってくる。先に quote 除去した時の対応関係について解決する枠組
    みが必要になるのではないかという気もする。

  * cmdspec: cd 関連の cmdinfo は core-cmdspec ではなくて contrib/cmdspec/* 辺
    りに移動する?

  * PROMPT_COMMAND / trap DEBUG で問題が起こる? (found by rashad-moves)
    https://github.com/rashad-moves/HomeConfigurationFiles/commit/efbac4153fd5021f1bc00d42c618fd9d6f4090b9

    2022-03-03 うーん。どうもこの問題は以下で報告されている物と同じの気がする。
    timer_show が含まれている。
    https://github.com/akinomyoga/ble.sh/issues/176

    実行時間の表示について Q&A にでも書いておくべきだろうか。

  * complete (source:rhs): 変数名依存の補完に対応しても良いのでは。

  * complete: ARGEX (eval 文脈) の補完

    現在は "variable:=, command:D, file" で生成しているが、本来は一番先頭の引数
    を元にして argument (including progcomp, etc.) を呼び出すべきなのではないか。

  * complete: [[ の中の文法も考慮した補完。これは [[ の中の文法にちゃんと対応し
    た後で考える事の気がする。

2021-12-06

  * mandb: コマンドの名称を抽出して保持して置けば binary の呼び出し時に使える。
    dnf や apt 等に問い合わせても良いのかもしれない。或いは、含まれているパッケー
    ジを見るという手もある。

    然し各コマンドについて man 等を呼び出すのは高価である。

    rpm, dnf でファイルの所属する package と含まれるファイルを抽出するには。
    https://linux-audit.com/determine-file-and-related-package/

    $ dnf -C repoquery --installed -f /usr/bin/git-lfs --qf '%{summary}'

    等の様にすれば良い。

    * resolved: しかしこれを呼び出すと package 一覧のダウンロード等を実行し始め
      るので問題がある気がする。或いは、更新を無効化した状態で呼び出す事ができ
      るだろうか →どうやら dnf -C とオプションを指定する事で cache から情報を
      取得できる様だ。

    * background で生成するにしても時間がかかるので、複数の bash session で同時
      に更新が実行されない様に注意が必要である。*.part.$$ に書き込んで、その後
      でそれを mv するという形にすると良い。更に、他の session が既に生成を試み
      ている場合には、background 生成を止める事にする。

    うーん。以下の結果を加工すれば一挙に全てのコマンドについて情報を抜き出せるのでは。
       $ dnf -C repoquery --installed --whatprovides /usr/bin/\* --nvr
       $ LANG=C dnf -C provides -q /usr/bin/\*

    * man -f ...

      というか man -s 1:6:8 -f command... を呼び出せばよいらしい。

      * linux では man -s 1:6:8 -f command 等として結果を得られる。whatis -s
        1:6:8 command としても同じ出力結果である。というか whatis 自体が man に
        よって実装されている疑惑 (-s オプションなどがあるので)。

      * cygwin で実行したら駄目だった。whatis sed awk とした時と全く同じ出力結
        果になったので、whatis を使っているのだろう。

      * solaris では man -f sed は表示されるが、man -f sed awk や man -f sed -f
        awk 等の様にして複数の結果を取得しようとすると何も表示されなくなる。1行
        目は空行で、2行目に man ファイルの情報があって、3行目にようやく説明が表
        示される。

      * minix では man -f sed で whatis を間接的に呼び出そうとしている。そして
        whatis はデータベースがない等の文句を言って動かない。

      * freebsd でも whatis を呼び出している様だ。警告が出ているが、複数指定し
        たら複数の説明をちゃんと出力してくれる。, 区切りで一行に複数の名称を出
        す事もある。例えば man -f awk とすると "awk, nawk (1) - <説明>" という
        具合の行を出力する。

  * complete: 文字列引数の中にファイル名を含めたい事もあるのでは。つまり "add
    a.sh" の様な。特に complete -m '...' の編集で欲しくなる。

  * bash-completion: awk - で long option だけが生成される。調べてみると
    complete -F _longopt が割り当てられているコマンドについては全てこのパターン
    の様である。

  * bash-completion: 空文字列に対して最初からオプションも生成して欲しい。
    そうしないと絞り込みの際に都合が悪い。

    うーん。bash-completion や他の補完の事を考えると一文字目に - が入力された時
    点で候補を再生成するべきの気がする。或いは - から始まる候補も追加する? 追加
    する場合には以前にあった物と重複する候補を削除しなければならない事に注意する。

  * syntax: for $(echo hello) に対しては着色しない。もしくはエラーとする。

    これは heredoc 単語と同様の問題である。因みに heredoc の単語に $() を含めた
    場合には、終端位置判定が正しくできなくなっている。普通に入力すると終端位置
    を逃す。終端を書いてから heredoc の中身を編集すると位置を正しく特定できる。

2021-11-23

  * kitty shell-integration (requested by kovidgoyal)
    https://github.com/akinomyoga/ble.sh/issues/110#issuecomment-976182311
    https://github.com/kovidgoyal/kitty/issues/3948

    | [Check default shell-integration]
    |
    | * ok: 前のコマンドの内容を less で見る: C-S-g
    |
    |   vim-airline を表示している時に問題が生じる。中途半端に切れたりする。
    |
    | * ok: プロンプト移動(scrollback): C-S-{z,x}
    |
    | * マウスによるプロンプト内の移動:
    |
    |   遅い、vi_nmap の中にいると変な事になる。うーん。これはまた後で確認する。
    |
    | * xterm-title で現在ディレクトリを表示する。
    |
    |   これは別に何か新しい機能という訳でもないだろう。敢えて ble.sh で対応する
    |   とするのであれば、bleopt prompt_xterm_title を用いるぐらいの事である。
    |
    | * これも特に変な事はない。但し、ble.sh 側でユーザーが何か設定している場合に
    |   は、kitty integration の設定は off にすれば良い。
    |
    | * ok: winch glitch の解決。これは綺麗に動いている。
    |
    | * Sophisticated completion for the kitty command in the shell. これは
    |   core-complete の領分であるが何か特別な事が起こるとも思われない。
    |
    | 結局 vim-airline を実行した事による問題点は C-S-g で閲覧する内容の切り取り
    | 以外では特に問題になっていない様に見える。以下の三点を報告する。
    |
    | x subshell の中でちゃんと動作していない。従って tmux の内部でも動作しない。
    |
    | x 複数行コマンド編集時に vi_nmap で位置がずれる。他の keymap では問題は生じ
    |   ない。
    |
    | x vim-airline を使っていると時々コマンド内容が切れる

    最初の項目については意図的なのだという返信が来た。だとしても tmux で空にな
    るというのは変である。後で patch を作っても良い。問題にしているのは
    invasive という事だったので SHLVL, SUBSHELL, $- 辺りを参照して本当に kitty
    の中にいる時にだけ有効にするというのが良いのかもしれない。(と思ったが、元々
    の kitty.bash でも kitty かどうかをチェックしているのではないか?)

    2つ目の項目に関しては仕方のない制限だという事。up/down を有効化する
    sequence について提案した所、patch が送られてきたら見るとの事。これは忙しい
    ので今は未だ。

    3つ目は調査中。

2021-11-21

  * complete: インラインでヘルプ・次に期待する引数の種類を表示するという話
    https://www.reddit.com/r/bash/comments/qrm3s2/hints_for_argument_types_in_bash/
    https://github.com/fish-shell/fish-shell/issues/2201

  * やはりメモリを使うという事は明記するべきである。

    bash-3.2 16MB 19MB
    bash-4.3 26MB 31MB
    bash-5.1 33MB 40MB

2021-11-05

  * vim の :term 内部で実行すると振る舞いが変だ

    * 先ず最初のロード時に行が一行ずれる。それ以降は発生しない。modifyOtherKeys
      もしくは文字幅判定の為に出力している何かが問題を起こしているのかもしれな
      い。

      →どうもこのずれは status_line に関係している様だ。

    * うーん vim :term の中だと NUL (C-@, C-SP) を入力することができない。C-wは
      vim の側での操作に使われている様だ。これらは ble.sh の外側でも同様である
      事から、ble.sh の問題ではない。寧ろ vim term の仕様と見るべきである。

  * bash-5.2 で builtin bind -Xs を観察するとところどころ \000 が余分に挿入され
    ている。これは何か。bash-5.1 では問題はない。

2021-10-26

  * winch: Window サイズを変化した時に menu の座標計算がずれる
    (menu_style=dense)そもそも resize した時点で menu の再配置を実行しなければ
    ならない筈である。

    或いはサイズが変わった時には menu-complete はキャンセルするべきなのではない
    か? 特に大量の WINCH を送ってくる端末があって、大量のメニュー項目の後ろの方
    のページを表示しているとすると、ほぼフリーズした様な形になってしまう。

    或いは次に TAB を押して他の項目を移動しようとした時点で改めて配置計算を実行
    する? 例えば、WINCH を受け取った時点では info を単に非表示にしておいて、次
    にメニューに対して表示の変更等を行う必要が生じた時に改めて計算を実行する。

    2022-03-04 そもそも ble/edit/info 自体が WINCH の時に再計算するべきなのでは
    ないか。特に高さだけでなく幅についても考えて再計算しないと内容が乱れてしま
    う。

  * スタートしてから数秒間は user input detection for C-m を off にした方が良い
    のでは。スタートした直後にペーストを実行する事があるとは思われない…。

    と思ったが bash を含む大量のテキストを入力した場合にどうなるのかというのは
    疑問である。とは言いつつも、その場合には親シェルの側でちゃんと paste
    detection ができているべきではないかという気がする。

2021-10-04

  * fzf を直接読み込んだ時に動かない問題について
    https://github.com/akinomyoga/ble.sh/issues/126

    ble-update を実行すると動く様になるが最初から source ble.sh すると動かない。
    ble-import contrib/fzf-key-bindings をすると動く様になる。

    というか改めて説明を読むが一体どういう操作をしようとして問題が生じているの
    か謎である。C-r, C-s をしようとした時に問題が生じているという事だろうか。現
    在の実装では補完については contrib/fzf を自動でロードする様にしている。
    widget に関しては contrib/fzf-key-bindings 経由で呼び出さなければ駄目である。

    うーん。自動的に検出して補正する様にしようと考えたがそんなに単純ではない様
    に見える。

    a 例えば bind する瞬間に fzf 関連であるかどうかを調べて fzf 関連であると分
      かった時点で fzf-key-bindings を呼び出すという方法。

      x ユーザーが実行したい binding が fzf-key-bindings と同じかどうか分からな
        い。ユーザーが自分で調整して binding のキーを変更しているかもしれない。
        この場合には勝手に fzf-key-bindings を読んでしまうとユーザーの予期しな
        い binding が定義される事になり問題である。

        一方で、諸々の関数は fzf/shell/key-bindings.bash に定義されているのだか
        ら、そこに含まれている関数を使おうとしている時点で其処にある binding が
        そのまま使われていると仮定して良いのではないか。もし、ユーザーが
        fzf/shell/key-bindings.bash を自分でコピー・編集して使っているのだとし
        たら、やはり contrib/fzf-key-bindings.bash についても同様に自分の設定に
        合わせて編集するべきなのではないか。

      o bind で -x に fzf 関連を指定した場合に関数の中身を差し替える等の事をし
        ようとしても、例えば inputrc キャッシュで初期化を誘導する等の事までは
        キャッシュできない気がする。

        →これに関しては fzf-key-bindings では関数の中身を差し替えるのではなく
        て、別名の関数を定義してそれに差し替える様にして、更にその別名の関数に
        ついての autoload を def.sh 辺りに記述する事にすれば良い。

        x この方法だと __fzf_cd__ や __fzf_history__ をユーザーが直接自分で
        bind した時に対策できない。

    b 或いは、bind -x を実行する時にコマンド名が __fzf_history__ または
      fzf-file-widget だった場合にこれらの関数を上書きするという手法。

      x この方法だと __fzf_cd__ の検出ができない。__fzf_cd__ は、
        fzf/shell/key-bindings.bash だとマクロ経由で呼び出される様になっている。
        つまり bind -x ではないという事。かと言って accept-line に作用して、コ
        マンド実行前にコマンド内容を調べて関数を上書きするというのも非現実的な
        気がする。

      うーん。やっぱり現状の様に設定するべきなのではないだろうか。

2021-09-28

  * fast-syntax-highlighting

    https://www.reddit.com/r/zsh/comments/oyege0/is_completionaware_syntax_highlighting_possible/
    https://github.com/zdharma/fast-syntax-highlighting/tree/master/%E2%86%92chroma
    https://github.com/Valodim/zsh-capture-completion

    どうやら programmable highlighting に相当する機能は
    fast-syntax-highlighting で既に実装されていて "chroma" と呼ばれているらしい。
    然し実のところそれ程沢山の実装がある訳でもない。

    他に zsh-capture-completion というモジュールに含まれる関数で capture.zsh
    'command' を実行すると 'command[TAB]' とした時の補完結果を取得できるらしい。
    これは ble.sh の上で作成する事も可能である。補完機能のテストで使うのに便利
    な気がする。

    bash-completion のテストをコピーできたら良い気がする…。でも全て python で
    定義されているというのは難点である。うーん。結局、その場で補完を実行する機
    能を実装したとしても使う機会がないからテストされずに残って意味のない機能に
    なりそうな気がする。

  * https://www.reddit.com/r/commandline/comments/pv1fm8/what_are_the_main_advantages_of_the_various_shells/

    fish の便利な機能について紹介している。

    * M-{right,left} でディレクトリ移動。これについては異なる keybinding で提供しても良い気がする。

      iswitchb の如く C-x C-b 等で探索するのもありではないか?
      その際には menu の機能を有効活用できる気がする。

    * fish の Abbreviations の振る舞いが気になる。
      zsh の zsh-abbr も気になる。

    然し、実際に ble.sh をロードさせてテストするというのは有効の気がする。

  * menu: C-x C-d で今迄に訪れたディレクトリの一覧。

    iswitchb と同様に絞り込みをしたいが入力した文字列は何処に表示するのが良いのか。
    panel に表示するのが良いだろうか。或いは、そもそも表示しなくても良いのかもしれない。
    何れにせよ太字で表示されるのであるから。

    太字ではなくてより強調した形にしても良いのかもしれない。これは face 経由で
    設定できる様にするのが良い様な気がする。現在は太字固定になっているが。

  * menu: C-x C-j で job 制御用の TUI メニューを表示しても良いのかもしれないとも思う。

2021-09-26

  * bash-5.2: array が sparse でない ./configure option が追加された。

    もしかすると sparse arrays に declare -gA を指定する必要があるかもしれない。
    sparse かつ ordered な配列については簡単な workaround は存在しない。唯、そ
    の様な配列を実際に使っているかは分からない。なければ気にしなくて良い。

2021-09-22

  * edit: 複数行モードの時は prior/next でページ移動?

  * plug: git clone 用の判定:

    これは

    $ grep -q '^github\.com' ~/.ssh/known_hosts
    $ grep -qEi '[[:space:]]*HostName[[:space:]]+([^[:space:]]+[[:space:]]+)*github\.com' ~/.ssh/config

  * 実は local rex=... [[ a =~ $rex ]] は関数に纏めたら良いのでは。

    速度的にはどうだろうと思って比較してみると4倍位遅くなる。もしくは 0.014ms
    だけ遅くなる。70回の評価で1ms, 1400回の評価で20ms, 7000回の評価で100msの差
    が出る。

    $ ble-measure "local rex=':point=([^:]*):'; [[ alpha:beta:point=end:b = \$rex ]]"
         3.618 usec/eval
    $ function ble/regex#match { [[ $1 =~ $2 ]]; }
    $ ble-measure "ble/regex#match alpha:beta:point=end:b ':point=([^:]*):'"
        17.402 usec/eval

    うーん。一般的には気にする速度低下ではないが、構文解析などの中心部では控え
    た方が良いかもしれないというぐらいである。通常の場所ではどんどん使って問題
    ないのではないか。

    →検索してみたが実は意外とそんなに沢山あるという訳でもない様だ。少しずつ置
    き換えていけば数日で終わるぐらいの箇所しか無い。概算で140箇所程度である。然
    し、そもそも其処までして置き換える必要があるのかという疑問もある。現状で動
    いているのであればそれで良いのではないか。一応他のシェルに移植する時に一括
    で動作を変更するのが楽という可能性はなくはない。

    2021-12-11 ble/string#match という関数名で追加した。

2021-09-15

  * haiku: ble/builtin/bind/.reconstruct-user-settings の gawk が無限ループになっ
    ている? 或いは滅茶苦茶遅くなっている。gawk 4.2 である。bash-4.4.23 から呼び
    出している。変な事が起こる様な余地はない様な気がするが…或いは正規表現エン
    ジンなどが壊れているという事なのかもしれない。

  * solaris: ble-bind を bashrc 内部で呼び出した時点で未だ attach していないの
    に色々と info を表示してしまっている。
    $_ble_base_cache/decode.cmap.gdict.*.dump を削除した時に再現する。

  * grapheme: SpacingMark, Prepend の幅は一体どうなっているのだろうか [#T0008]

    現在の実装では幅を全く考慮に入れていないが、入れるべきの気がする。c2w で
    combining に対して 0 を返す様にしたら Extend や Prepend に対しても c2w で値
    を計算して加算する様にすれば良いだろうか。然し、絵文字の Emoji_Modifier な
    ど組み合わせた時と単体の時で幅の異なる物も存在する。

2021-09-06

  * menu: メニューの詳細表示を toggle できる様にするべきではないか。

    表示するか表示しないか完全に固定するのは微妙な気がする。

    後、desc-raw しか実際には使わない様な気がする。二種類の表示方法を用意したと
    しても、そもそも説明を生成する側で二種類を分けて生成する訳にも行かないので、
    どちらかに統一するべきではないか。速度が気になるというのはあるが、もしテキ
    ストだと解釈するとしても、全角文字などが含まれる場合には結局位置計算は省略
    できない。逆に ascii 文字だけで構成されているのであれば esc を解釈するとし
    てもそんなに速度低下なく処理する事ができる。

    表示の toggle は各メニューが表示される度に行うか或いは一回変更したら暫くそ
    の設定を保持するか。ユーザーの指定した設定を既定値として各 menu が表示され
    る度に toggle を行うという事を考えたがそれは如何にも面倒である。それよりは
    toggle は永続的な変更を引き起こすとした方が分かりやすい様な気がする。その場
    合には、bleopt の設定を永続的に設定してしまっても良いのではないか。

    然し、それだと desc モードになっている時に align 等を設定した時にどの様に振
    る舞えば良いのか分からない。一つの手は一旦完全に toggle 状態を clear して、
    改めて既定の style として align を設定するというのが自然な気がする。

    * toggle するとしたらその表示切り替えのキーボード操作はどうするのか。C-m と
      思ったがそれだと確定と同じ。C-d だと削除みたいな感じがする。insert は確か
      に toggle だがやはり直感的ではない気がする。 ScrLk や CapsLock NumLock 等
      も同様である (というか OS 側のキーボードの状態が変わってしまったりして大
      変である)。

      後、実際に menu-complete に入らなくても切り替えられた方が良い様な気がする。
      その場合には他と被らない様な操作にする必要がある。他で使われていない
      single-key の操作はそうそう残っていない気がするし、残っているとしてもそれ
      をたかが menu toggle に割り当てるべきなのかという問題もある。或いは、2
      keys による操作としても良い様な気はしている。

      例えば C-x | 等。特に C-x は menu-complete やその他の complete に色々割り
      当てているから丁度良い気がする。

      - "C-x d" は emacs では dired,
      - "C-x ?" は emacs では keybinding 一覧,
      - "C-x h" は emacs では全選択に割り当てられている。
      - "C-x |" は emacs では割り当てがない。
      - "C-x C-h" は前の文を削除する。
      - "C-x C-t" は行の入れ替え。

      若干操作しにくい気がするが、うーん。一旦 menu-complete に入ってしまえば
      "|" で入力できるようにすれば良いと思ったが…普通に "|" を入力したいという
      時があるのでそれは駄目だ。やはり C-? の形の方が良い。

  * menu: preview 機能をつけても良い。preview に表示する中身は候補の種類に応じて色々。

    そもそも desc の内容自体その場に表示するのではなくて preview 的な小さな窓の中に
    選択した時にだけ表示するという形式でも良いのではないかという気がする。

2021-09-02

  * 改めて確認した所また Windows Terminal で動かなくなっている

    調べると Cygwin 経由で接続した時だけの問題の様である。
    これは Cygwin の側の conpty の副作用という可能性もある。
    というか最新版の Cygwin で直っている可能性もある。

    ? wt を path に加えて実行もできるのにも関わらず構文着色で赤になっている。不思議だ。
      type wt とするとちゃんと成功する。

    ? Cygwin から起動した時とスタートメニューから起動した時で、Windows
      Terminal の中で Cygwin タブを開いた時のプロンプトに含まれるシー
      ケンスが異なっている気がする。と思ったが、これは Cygwin の
      screen の中から起動すると、Windows Terminal の中の Cygwin も
      screen の中にいると勘違いするからであろう。気にしなくて良い。

      取り敢えず環境変数が継承される事は確認したし、
      CYGWIN=disable_pcon を指定していても指定していなくても Windows
      Termianl - Cygwin では座標計算がずれるという事が確認できた。やは
      り pcon は関係ないのかもしれない。

  * 起動時間を計測しているようだ

    ble.sh でかなり時間がかかっている様だという事。

    * ble.sh は background 処理を行う。特に ble-attach の末尾で行っている気がす
      る。なので、ユーザーが何も入力しない限り background 処理を完全に終えるま
      で ble-attach から抜けないのではないか。逆に、ユーザーが何か入力している
      時にはより早く初期化できるのではないか。と思って試してみたがそうでもない。
      というか殆ど変化がない。どういう事だろうか。

      ユーザー入力の検出ができていない? 或いはそもそも background 処理は最初は
      行っていない? 後者の様な気もするが後で確認する必要がある。

      letsnote でも試してみたがやはりユーザー入力があっても殆ど変化はない。
      GNU/LInux でも Cygwin でも同様にユーザー入力があっても変化はない様だ。

      実装を確認してみると確かに ble-attach の末尾で .tail を呼び出してい
      て、.tail は idle.do を呼び出している。うーん。不思議だ。或いは .tail の
      前後だけに注目すればより短くなっているかもしれない。

    * MSYS2 環境では ble.sh のロード及び attach にはかなり時間がかかる様だ。と
      いうかこれは fork の回数に直結しているという気もする。MSYS2 で調べると
      spawn が 10/s だった。

      一方で Cygwin だと 23/s 程度である。実は Cygwin の方が軽量である。或いは
      最適化が施されていると見るべきか。或いは whitelite に入れていただろうか。

2021-08-31

  * complete: -E (_EmptycmD_) に対応していない

    一方でこれは一体どの様に振る舞うものとして実装すれば良いのか分からない側面
    がある。文字列が本当に空の時にはこれを使って補間するので良い。

    * ; で区切って未だ何も入力していない状況の時にはどう振る舞うべきか。元の
      bash では本当に空文字列の時にだけ呼び出される様である。また -E の用途とし
      て空の時のコマンド候補を生成するという役割もあるかもしれないが、

      というか改めて考えると ; で区切って未だの時には -I が対応する補完になるの
      ではないか。という事を考えると -E はやはり完全に空の時に対応するのではな
      いだろうか。実際に試してみるのが良い気がする。

      complete -F _initial -I, complete -F _empty -E で試してみると ; の次で呼
      び出した補完の場合には _initial が呼び出される。完全に空の時には _empty
      が呼び出されていて一文字でも入力されていれば _initial が呼び出される。入
      力されているのが空文字列であっても同様である。

    実装するとしたらどの様に実装するべきだろうか。単に空の時には新しく -E で呼
    び出す仕組みを作れば良いのだろうか。

  * msys2 での ble-update で変な動きをした。。

2021-08-30

  * complete: overridden builtin 及び他の framework

    | * https://github.com/csdvrx/bash-timestamping-sqlite
    |
    |   この実装では history コマンドを上書きしている様な気がする。然し同時に
    |   ble.sh との併用を推奨している。うーん。この時 ble.sh が history を上書きす
    |   る、もしくはble.sh の history がこの枠組に上書きされるという事があったら何
    |   が起こるのだろうか。何か悪い事が起きる気がする。
    |   ble/function#push とかを使って何とかすれば良いのだろうか。
    |   その場合にはこの interface を固定する必要がある。
    |
    |   と思って実際にコードを確認したが history を上書きしている訳でもない様だ。

    何れにしてもこれは注意点として README に記述しておくべきなのではないか。

  * complete: そもそも遡って書き換える補完候補と純粋な意味での補完候補は区別す
    るべきなのかもしれない。TAB 補完では後者に基づいて補完を実行するが、メニュー
    の表示には両方を表示するという手がある。その場合にはメニューの内部で
    section を分けると良いだろうか。ページング等をちゃんと考慮に入れる必要があ
    る。

2021-08-29

  * bashrc に直接設定を書く方法についても説明する。

    但しこの場合には ble-reload をした時に設定が消えるという事に注意する。→うー
    ん。この様な面倒な事が起こるのであればやはり記述しないほうが良いのではない
    か。

    よく考えてみたら source ble.sh と ble-attach の間に書いた bind にも同様の問
    題があるのではないか? と思ったが、ble-attach よりも前に書いているのであれば
    ちゃんと readline の側にも反映されている筈で問題はない筈。

    ユーザーがコマンドラインから設定した設定は消えてなくなってしまうという事に
    注意する。これらを記録して後で拾える様にするという手もあるかもしれないとは
    思う。

2021-08-26

  * CPU 100% in macOS (reported by killermoehre)
    https://github.com/akinomyoga/ble.sh/issues/131

    CPU 100% になっている時に同時に gawk が待機している様である。
    100% になっている時の gawk の引数について尋ねたら返答が来た。

    二つの bash について異なる gawk が呼び出されている。前者は
    ble/history:bash/resolve-multiline/.awk で、後者は
    ble/history:bash/load/.background-initialize である。両方とも
    history に関係している。

    Q というかどちらの bash が CPU 100% になっているのだろうか。或いは両方?

    Q bash が起動した時に暫く 100% になるのか起動した後もずっと 100% のままなの
      か。もし暫くしたら収まるのだとしたらどれぐらいの間 100% でいるのだろうか。
      これがそんなに長くなければ少なくとも見た目の動作に影響がない限りはそのま
      まにしておいても良い様な気がする。

    Q CPU 100% になっている間 bash は応答するだろうか。応答するとしたら

    Q いつでも現象は再現するだろうか。或いは確率的に発生するだろうか。

    ----

    取り敢えずやはり巨大な history が問題であるという事までは分かった。
    自分の手許の linux では同じぐらいの巨大な history を用意したとしても
    そんなに遅くはない。

    ? 一方で向こうの報告によると builtin history を実行しているプロセスが重いと
      いうことの様である。自分の手許で確認しようとしているがすぐに処理が終わっ
      てしまうので確認できない。

    * 終了時にもかなり待たされる。

      終了時の nawk が滅茶苦茶遅くなる。gawk だと遅くないとかあるのだろうか。と
      思って改めて観察してみると最初に bash が 100% になって、その次に nawk が
      100% になるという具合に処理が進行している。

      ble/builtin/history/.write で時間を消費している。

      A:1630043056.816931
      B:1630043056.936962 0.12s ... history/.get-min
      C:1630043056.942516 0.06s ... history/.get-max
      D:1630043079.487224 13s ... builtin history >> file
      E:1630043092.465937 13s ... nawk の処理

    Q hang と slow は区別しているのだろうか。自分的には hang というのは待っても
      絶対に終わらないという意味である。然し、向こうは有限時間で終わるという事
      を確認しているのにも関わらず hang と言っている可能性がある。よく分からな
      い。

2021-08-23

  * bash-4.2 では [[ ${arr[*]} == *" 2 "* ]] (where arr=(1 2 '')) が駄目

    一応該当しそうな物を検索すると以下の様な物がある。
    何れも空白には関係なさそうなので問題は起こらなそうな気がする。

    $ grc '\[\[ \$\{.*\[[*@]\].*\} [!=]= .* \]\]'
    ./ble.pp:145:    { ((${#BASH_SOURCE[@]})) && [[ ${BASH_SOURCE[${#BASH_SOURCE[@]}-1]} == *bashrc ]]; } ||
    ./src/decode.sh:3632:    [[ ${keys[*]} != "$bind_keys" ]] &&

2021-07-14

  * bash-it によるプロンプト設定が prompt attach で反映されない。

    PROMPT_COMMAND 経由で PS1 を設定していると反映されないのだろうかと思ったが
    そういう訳でもない様だ。

    powerline-multiline で発生するとの事だが再現しない。
    というか powerline-multiline で発生する固有の問題なのか、
    それとも他の theme でも動作するのかの情報についても書いていない。

2021-07-13

  * auto-menu: 一旦 (no items) が表示されるとそれ以降 auto-menu が動作しない

    auto-menu が有効になっている時に一旦 (no items) が表示されるとそれがそのま
    まになって二度と auto-menu が起動しなくなる。

    またこの時に C-l で再描画すると info に何も表示されなくなる。実はこれは
    menu が表示されている時には常に再現する問題である。

2021-06-21

  * auto-menu が有効になっている時に複数行編集で座標が変になる

    2021-07-13 今試しても問題は再現しない。

    2021-07-18 再現した。履歴に複数行の項目が含まれている時に、その履歴が呼び出
    されると問題が発生する。ble-bind ... と入力した時に発生した。というかこれは
    本当に auto-menu の問題なのかどうか分からない。取り敢えず、textmap を再確認
    する必要がある気がする。ずれの量的にも前回の textmap の時と似たような振る舞
    いの様に見える。

    2021-07-19 chatoyancy の上では再現しない? vaiio2016 の上でも再現しない。

2021-06-18

  * grapheme: ble/canvas/trace の lc lg の grapheme cluster 対応について
    Ref #D1619

    基底文字だけを指定しても、最後の Extend を指定しても端末によって左の書記素
    クラスターが破壊される可能性がある。書記素クラスター全体で出力する必要があ
    る。lc lg の組ではなくて lcs lw lg の組で結果を返さなければならない。lc lg
    はデバグ用なので其処まで配慮する意義は薄い。

    そもそも lc lg の枠組みはそろそろ削除しても良いのではないかという気すらする。

  * grapheme: 私用文字で置き換える事により書記素クラスター単位での編集を可能にする可能性
    Ref #D1619

    現在の所その必要性は限りなく低いと考えられる。

  * grapheme: Unicode version 毎の振る舞いの違い?
    Ref #D1619

    emoji_version と同様に grapheme_cluster についても version 毎の違いを考えて
    も良いのかもしれない。

  * emoji: Emoji 対応状況自動判定
    Ref #D1619

    | これも自動検出の対象にしても良いのでは。という気がする。というかそうする
    | べきである。所で Zle は実は内部的にそういう事をしている可能性がある。
    |
    | と思ったが端末によって unqualified の取り扱いもばらばらだろうし ZWJ に対
    | 応しているのかどうかも不明だし、という事を考えていくと単に
    | legacy/extended を区別すれば良いという訳ではない。場合によっては ZWJ シー
    | ケンスに対応しているかどうかと言ったフラグまで管理しなければならないかも
    | しれない。とは言いつつ実際にそのように振る舞う端末が存在するのかどうかも
    | 不明である。なので、これは実際の端末の振る舞いを整理しながら考える必要が
    | ある。
    |
    | 端末ごとの絵文字の振る舞いについて調べる必要がある気がする。kitty/vte は
    | unqualified はテキスト表示で EPVS によって絵文字になる。RLogin は
    | unqualified は半角で表示される? 幅は VS で変化しないように見える。mintty
    | は試した限りでは Emoji に対応していない。既定で off になっているという事
    | だろうか。
    |
    | 以下の振る舞いも端末の対応状況に応じて実装する。
    |
    | * EPVS の時には emoji_width または 2 になる様にしている。然し、絵文字の表示
    |   ができない端末では 2 にせずに普通の文字として求めた方が良い可能性もある。

    * legacy vs extended
    * unqualified をどう取り扱うか。EPVS 及び TPVS がどう作用するか
    * ZWJ sequence に対応しているかどうか

    現実の端末に於いてそれぞれどう対応されているか、そして三つの対応状況の組み
    合わせはどうなっているかについても調べる必要がある。

  * test: ログを何処かに保存する機能? その場合には着色等は除外する

  * syntax_debug の時にコマンド実行すると実行位置が変だ

    うーん。info　を削除する時のシーケンスが間違っている? menu の表示時には何も
    問題がない。menu に関しては消去してから実行するからだろうか。或いは、変なタ
    イミングで info が更新されて info が表示されてはいけないタイミングで表示さ
    れているという事だろうか。

  * progcomp の出力に関する議論 (reported by oc1024)
    https://github.com/akinomyoga/ble.sh/issues/121

    うーん。どうするのが良いのか微妙。Bash と同じ様に動作するべきなのか、或いは
    出力を抑制するべきなのか。関連する議論が幾つかあった様な気がする。というか
    最近抑制する様に変更した様な気がするが何故再発しているのだろう。実際に確認
    してみた所、歴史的には常に出力を許している様にも見える。不思議だ。

    うーん。実は progcomp-helper-func ではなくて、compgen の時点で出力を抑制し
    ていたのだったろうか。

    * 98835b5 2021-05-17 これは _ble_util_fd_stderr 等に保存した fd を使う様に
      する変更。本質的には tty を使う様になっている。元から helper-func で tty
      にリダイレクトしていた。

    * 9d4ad56 2021-05-06 うーん。以前の報告が見つかった。よく見たらこれも
      oc1024 による報告である。この commit では stderr に関連する変更はない。

      https://github.com/akinomyoga/ble.sh/issues/97

      どうもこの時は個別にバグのある関数を置き換えたのだった。修正は 9d4ad56 で
      ある。stderr/stdout に対しては全く変更していないし細かい議論もしていない。

    * 4fc51ae 2021-03-10 fzf に対する対策。これについては明示的に tty にリダイ
      レクトしている。これより前は compgen 呼び出しの stderr への redirect の為
      に stderr は抑制されていた。

    * 68f8077a 2020-04-06 これは compgen 呼び出しに builtin を付加しただけ。

    * 1ca53868 2019-01-01 これは complete -p の解析に機能を追加した物。この時点
      で compgen の stderr は抑制している。

2021-06-13

  * menu-complete: 末尾一致 (skip-completed-text) が考慮に入っていない

    これは最終的な挿入時に処理するべきか、或いはメニュー項目を一時挿入している
    時から処理するべきか。メニュー項目を一時挿入している時から処理しないと振る
    舞いとして不自然になる気がする。

  * 終了ステータスが 2 の時に前回のコマンドを再ロードするというのは面白い試みかもしれない

    最近人気らしい thefuck により修正後のコマンドが取得できればなお良い。

2021-05-29

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

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

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

2021-05-27

  * wiki の更新
    * done: \g{...} について記述する (2021-06-13)
    * wiki: ble-import の -f オプション
    * wiki: bleopt の wildcard, -r, -u
    * wiki: blehook の -a
    * 2021-06-12 wiki: bleopt -I
    * 2021-05-24 airline: 使い方を説明に書く

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

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

2021-05-23

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

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

2021-05-21

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

    ble.sh の関数についても着色及び補完関数を定義して行きたい。

2021-05-19

  * complete: [TAB] 補完の場合には、ユーザー入力があった時に即座にキャンセルす
    るのではなくて timeout があっても良いのかもしれない。

2021-05-17

  * 此処で思ったのだが nawk は Unicode の対象を取り扱えるのだろうか。。。UTF-8
    ならば通常の制御文字はそのままなので問題は生じないのではないかという気もす
    るが。文字数を数えて何かする様な処理では何か変な事が起こるかもしれないが、
    そうでなければ大丈夫の気がする。

    問題が起こるかもしれないのは brace expansion の形式でファイル名一覧を挿入す
    る処理。これに関しては UTF-8 だと例えば平仮名の途中で分断されたりして変な事
    が起こる可能性がある。

  * global: /dev/null を $_ble_util_fd_null に置き換える?

    #D1552 で議論した。毎回 open するよりも dup した方が高速である。一方で
    _ble_util_fd_null が上書きされたりした時は /dev/null の方が頑健である。

  * syntax: redirection が正しく解析できていない気がする
    以下の手順で編集した時に着色が間違っている。

    $ exec {fd}>/dev/null
    $ exec {}>/dev/null
    $ exec {_ble_base_fd_null}>/dev/null

  * 色見本について探した

    多くのサイトは微妙である。そもそも sRGB とかの概念があるのかないのか不明で
    ある。単純に RGB #XXXXXX の値を線形で CMYK に変換していたりしてかなり怪しい。
    色用語の場所にも sRGB やガンマ補正などの単語は見られない。

    https://www.color-sample.com/popular/jiscolor/ja/

    このサイトはちゃんと sRGB/Adobe RGB 等について載っているので少なくともちゃ
    んとその辺りの事を認識した上で作られたサイトであろうと思われる。然し権利関
    係の記述もないし、連絡先もない。メールボタンがあると思って押したら単に "友
    達にこのサイトを紹介する" メールを送る為のボタンだった。© 2021
    Color-Sample.com. All Rights Reserved. という表記の右にあるアイコンがリン
    クになっていたので押して見たが、単純にトップに跳ぶだけだった。Twitter アカ
    ウントは https://twitter.com/color_sample で見に行ったら 2014 で更新が止まっ
    ている。著作権が 2021 になっているのは機械的に置き換えているだけという事だ
    ろうか。何だかよく分からない。というかよく見たらブラウザサポートというアイ
    コンも古いブラウザが並んでいたりして更新が止まっている事を示唆している。

    https://triple-underscore.github.io/css-color-ja.html#rgb-to-lab

    w3 の CSS の仕様の翻訳。ここにちゃんと色々の知識が書かれている。この文書は
    最初から最後まで読むべき。

    http://mezala.la.coocan.jp/pc/jiscolor/jiscolor.html

    このページは複数の情報源からの差異について見せているがそもそも CMYK, RGB の
    変換式として異なるサイトから二種類持ってきていて (どちらかが間違っているの
    に違いない) 更に、Wikipedia からの数値も比較していて、どれだけ見た目が変わっ
    てくるかを見せているが。色には絶対的な基準はないのだとか色々言って納得して
    いるが、これらは単に sRGB と RGB の解釈を間違えて変換しているから起こってい
    る間違いのような気がする。(とはいいつつ画面の輝度やその他の要因もあるだろう
    から一概には言えないのかもしれないが、少なくともどういう条件の元での変換を
    行っているのか明示した上で、その差異について議論していなければ情報としては
    使い物にならない)

    https://www.colordic.org/w

    このサイトは和色大辞典と言って 460 色掲載しているそうで一番大きい気がする。
    然し、その RGB 値が sRGB なのかどうかとかも分からない。Q&A には再利用・再頒
    布可能性などについては述べられていないし、各色の出典についても書かれていな
    い。このサイトの RGB 値が実際に sRGB なのか何なのか確認して、その上で他の色
    についても変換を確認するのが良い気がする。

2021-05-15

  * AUR blesh-git のカスタム update について
    https://aur.archlinux.org/packages/blesh-git/
    https://aur.archlinux.org/cgit/aur.git/tree/blesh-update.sh?h=blesh-git

    * {PRE,POST}_VERSION を local で宣言する
      これはもう既に修正してもらった。

    * _package.sh の属性は 644
      これに関しては結局指摘する機会がなかったからそのままだが、まあ大して問題
      はないだろう。

  * syntax

    1>&$fd- は使えない
    1>&./- もエラーになる

    もっとちゃんと調べる必要がある。

2021-05-09

  * Fedora の package にするには結構面倒な手続きが要りそうな感じである。
    https://blog.jwf.io/2017/11/first-rpm-package-fedora/

    何れにしても ble.sh は頻繁に変更が加わっているし未だ 0.* の version の段階
    なので未だ公式に提出はしない事にする。1.0 を出す時に一緒に提出を考えるのが
    良いだろうと思われる。

  * v1.0 を出す迄に何か目玉の機能を実装したい所であるが、実の所、他のシェルに全
    くない様な機能で便利そうな物は存在しない。

    * syntax-highlighting ... 文法もちゃんと追跡した物

    * error message ... これは他のシェルにはない機能である。fish にあったりする
      かもしれないが。

    * vim mode ... これは highlighting も含めてなかなか気に入っている。

    * complete
      * sabbrev ... 個人的にこれは結構便利だと考えている。
      * auto-complete ... これは別に他のシェルと比べて何か良い訳でもない。
      * auto-menu ... これはちょっと煩い。けれど他のシェルにもあるので。

    * bottom panel ... 一つは bottom panel かもしれないがそんなに便利なのかとい
      うと微妙な所である。tmux の方の設定で似たような物を表示できる筈だし特に便
      利でもない。見た目に派手なので最初は喜んで使う人がいるかもしれないという
      位。

    * enhanced history ... 相対パスでファイル名を参照しているのを記録したい。そ
      れを auto-complete の実装に役立てたい。

    * TUI configuration?

    逆に欠けている物。ex mode の :cmd が全然対応できていない。

2021-05-06

  * progcomp: complete -C completer で改行のエスケープに対応していない

    man bash によると completer の出力した結果は行志向であるが \ によるエスケー
    プで改行を含める事ができるらしい。然し、\ が特別な意味を持つのだとすれば行
    末に \ を置きたい時にはどうすれば良いのか。行内全体に於いてエスケープが意味
    を持つのだろうか。よく分からない事が多い。実際に試してみないと分からない。

    或いは read line で読み込む事ができる形式だろうか。

    →実際に動作を確認したところ、エスケープの除去は行われず \ も含まて補完文字
    列とされる様だ。よく考えてみれば、実際に挿入した時に複数の単語として解釈さ
    れてしまっては困る訳だから、確かにこの動作でなければならない。

    ? 末尾に \\ があったらどうなるだろうか → \\ であってもその後の改行は候補の
      一部と見做される様だ。

    さて、具体的にどの様に実装するのが良いか…という事を考えようと思ったが難し
    い。先ず標準出力を勝手に自分で COMPREPLY に代入するのは違う様に思われる。と
    いうのも、呼び出し元の compgen で -S suffix 等の加工をしてもらわなければな
    らないからである。だとすると、最終的な compgen の出力結果を解釈する時に行末
    の '\' で行を繋げる様に処理しなければならないのだろうか。

    そもそも改行を含むファイル名があった時に compgen はどの様な出力をするのか。
    うーん。普通にエスケープせずに改行を出力した様な気がする→確認した。確かに
    そうなっている。なので '\' が行末にあるからと言って勝手に振る舞いを変更する
    のも憚られる。

    或いは compgen の全ての機能を自前で模倣するという手もなくはない。その場合には区切りは全て制御下にある。

  * progcomp: -F もしくは -C で生成した候補に対しても dir/ 等の suffix を付ける
    必要はあるのか。もし付けたければ completion 側で付けるべきなのではないかと
    いう気がする。

2021-05-04

  * robustness: ble.sh では exit を上書きしているが set -o posix の時にはそれが
    無効になる。

  * util: builtins 復元、function#advice, etc. において functrace 属性は復元し
    なくて良いのだろうか。復元という事を考えるとやはり declare -pf を使う必要が
    あるのかもしれない。

    bash version, posix mode も含めてどういう方法があってそれぞれどの様に振る舞
    うのか調べる必要がある。

    取り敢えず問題が起こらない事を確かめた上で getdef 自体を更新するのが良いの
    ではないか

    →と思ったが実際は複雑である。getdef を使って関数を別名にコピーするのに使っ
    たりしているが、その時に先頭部分だけを置換している。しかし declare -ft の部
    分についても関数名を置換しなければならない。そういう事になるぐらいであれば、
    個別に declare -ft かどうかを判定して、改めて declare -ft で属性を付加し直
    す様にしないと行けない筈である。

2021-05-03

  * rlfunc: fetch-history
    8f485ff8 - new readline "fetch-history" bindable command
  * rlfunc: C-x s, spell-correct-word
    6be3a741
  * rlvar: enable-active-region
    b1965836 new "enable-active-region" readline variable
  * rlbind: prior, next
    65822e50 - alias expansion fix in case statements
  * vi-undo

  * 5.2: LS_COLORS *.readline-colored-completion-prefix (bash e59452c7)

    rlvar colored-completion-prefix が on でかつ LS_COLORS の中に
    *.readline-colored-completion-prefix という項目がある時、共通一致部分の着色
    をそれに書き換える。

    実際に bash の振る舞いを調べてみようとしたがどうも有効にならない。調べてみ
    ると、_rl_color_ext_list が初期化されていない。これを初期化する為には何かす
    る必要があるのだろうか。_rl_parse_colors という関数で初期化しているようだが、
    この関数はどこから呼び出されているのだろうか。

    うーん。分かった。readline.c:1327 で呼び出している。これは初期化部分である。
    つまり、readline を初期化するよりも先に LS_COLORS を設定しておく必要がある。
    更に言うと、bind 'set ... on' も事前にやって置かないと駄目。というか
    colored-stats の時点で同じ問題があったのではないか?

    これは単純に _rl_color_ext_list が空だったらその場で _rl_parse_colors の呼
    び出しを試みるという事と、それから LS_COLORS の値が変更される時に
    _rl_color_ext_list をクリアする。と思ったが、これだと LS_COLORS が空の時に、
    毎回 _rl_parse_colors が試みられて非効率的である。

    * 後、_rl_colored_stats = 0 が _rl_parse_colors の中で設定されている。

2021-04-30

  * ble-reload: blerc 外のユーザー設定の保持

    外部のツールが呼び出した blehook PREEXEC+=... 等は別枠で保存しておくべきで
    はないか。そうしないと ble-reload した時に設定が消えてなくなってしまう。或
    いは、blerc の中から呼び出したか外から呼び出したかで取り扱いを変える。blerc
    の中で呼び出した設定は消えてしまっても仕方がない。一方で、blerc の外側で実
    行した物については保持しておくのが自然なのではないか。

2021-04-29

  * robustness: main/init: readonly POSIXLY_CORRECT されていたらどうするのか。

    少なくともどちらの側の設定であっても ble.sh 的には困る。

    然し、readonly まで気にし始めるとあらゆる変数名で問題が起こるので気にしても仕
    方がないのかも知れない。せめて全て大文字の変数だけが readonly になっていると
    いう事を要請するのが妥当だろうか。ローカル変数で大文字を使っているというと
    KEYS WIDGET ARG FLAG REG 辺りは危ないかもしれない。

    然し、ここまで行くと「ユーザーが自分で変な事をしたのだから責任は持てない」と
    いうレベルの事の様な気がする。

  * robustness: main/init: 最初の bash version 判定も alias 対策可能かもしれない?
    然し、return/exit が上書きされる場合等も考えると難しいかも知れない?

  * robustness: "builtin read -e" 対策?

    これは今迄考えて来なかったが関連する考察 #D1520 があったので記録として残し
    ておく。但し、纏めた物を眺めるに総じて困難である様に思われる。

    a set -o emacs / set -o vi の切り替えを利用して read が使える様にする。つま
      り、ble.sh は裏側の keymap に bind して、ユーザーコマンドを実行する時に反
      転させるという方法。この方法には問題が多い。

      x 全てのユーザー関数 (補完関数、プロンプト、trap、blehook 等) で keymap
        を反転する必要があるのではないか。

      x ユーザーが emacs/vi keymap を切り替える rl bindable function を実行する
        と結局 ble.sh の bind している keymap が表に出てきてその時点で制御不能
        になってしまう。勝手にそういった binding を削除するのも非現実的な気がす
        る。

      x bash の version によっては keymap を切り替えると bind -x が中断した様な
        気もする。

    b trap DEBUG 等を使って builtin read -e が呼び出されるのを検出して、ble.sh
      で wrap した処理を行ってからそのコマンドの実行をスキップする。この方法に
      も色々の問題がつきまとう。ちゃんと透過的に対応できるかというと困難の気が
      する。

      x DEBUG のコストがある。

      x ユーザの設定した DEBUG の管理が面倒。結局 trap DEBUG を透過的に利用でき
        る様にする枠組みは完成していない。(これはその枠組さえ完成すれば余り気に
        しなくても良いのかもしれない)

      x 本当に実行するコマンドを入れ替える事が可能なのだろうか。例えば builtin
        read -e の呼び出し元から見て、本当に関数実行が入れ替わった様に見えるの
        か。exit status はどうなるのか。これは実際に実験してみないと分からない。

      x DEBUG の BASH_COMMAND を用いて元のコマンドを本当に再現できるのか。例え
        ば $1 等が使われていた時にその内容を取得する事は可能なのか (BASH_ARGV
        を有効にしておかなければならないのか? ユーザーが設定を変更してしまった
        らどうなるのか)。また、引数の境界等もちゃんと BASH_COMMAND を見ただけで
        分かる様になっているのか。これも色々実験しないと分からない。

    c builtin read -e に入った後で ble.sh の widget が呼び出されたら良い様に
      状態を adjust して widget の振る舞いを変更できないだろうか。

      x C-c に明示的に対応して、C-c が呼び出された時には設定を restore して抜け
        る様にする。これは面倒なだけで処理としては十分可能である様な気がする。
        但し、外側に SIGINT を伝播する必要はあるのかもしれない。

    d ユーザーがコマンドを実行する度に realine 設定を完全 unbind して、終わったら
      再度 bind し直す。でも、これは文法エラー等によってコマンド実行が中断された
      時に、ble.sh session に復帰せずに通常の readline の状態に落ちてしまう。

2021-04-06

  * logout も exit と同様に置き換えるべきなのではないか。

  * prompt を評価する時に $var が local 変数に被覆されている。

    然し $var だけならば良いが $() で呼び出された関数が更に内部で変数を使用して
    いる可能性等を考えると下手に変な調整はしない方が良いかもしれない。PS1 に直
    接 $var と記述するかしないかで $() の内部でも変数が見えるかどうかが切り替わ
    るというのは不自然すぎる。それならば ble.sh 自体が変数を定義するのでそれに
    よって被覆されてしまうと説明した方が自然である。

    グローバルでない変数を列挙する方法は存在するだろうか。

2021-04-26

  * keymap/vi: vi における既定の keymap を imap ではなく nmap にするオプション

    現在の振る舞いではコマンド実行後に nmap であれば insert-mode に戻すという操
    作をしていた筈である。その箇所を書き換えて、オプションに応じて変更先のモー
    ドを切り替える様にすれば良い。それと ble-attach した時の最初の設定を行った
    直後に、自動的に nmap に移動する様にする処理を加えれば良い。

  * ble-bind: ble-bind -P で、他のオプションで指定したタイプの binding だけを出力する?

    % -T を指定すれば -T の設定を出力する。--cursor を指定すれば --cursor の設
    % 定を出力する。cmap 関連のオプションを指定すればそれに関連する設定を出力す
    % る。と思ったが、-T, --cursor, --csi, -k, etc. はそれぞれオプション引数を
    % 取るので、引数読み取りの段階で -P の後で振る舞いを変更する様にしなければ
    % ならない。これはコマンドライン引数の解釈として不自然である。

    別のオプションを使って dump する内容を選別するのが良い。例えば、
    --filter=timeout:cursor:csi:cmap:etc 等である。

  * decode: [refactor] _ble_decode_KEYMAP_kmap_@ ?

    いきなり KEYMAP ではなくてその前に何か挟みたい。例えば
    _ble_decode_kmap_KEYMAP_@ に変更する等。この場合には KEYMAP の名称として紛
    らわしい物が定義された時に問題になるのではないか。前の実装で KEYMAP の直後
    に固定の文字列を挿入していたのは、末尾から KEYMAP 以外の部分を一意に切り取
    る事ができる様にする為の設計だったのではないか。

    現在の実装は末尾からの一意性が保証される様になっている。_kmap_ が他で使われ
    ていない限りに於いて、ちゃんと一意になっている。然し、名前空間として変であ
    るというのも分かりにくい。なので、 _ble_decode_kmap_KEYMAP_xxxx_yyyy にして、
    xxxx には yyyy に絶対に現れない文字列を指定すれば良い。例えば data 等。

2021-04-04

  * history auto-save

2021-03-21

  * robustness: 様々な基本的な変数が readonly でグローバルに固定されていたらど
    うするのか。ロードした瞬間に様々な良くない事が起こる気がする。然し、それを
    言い出すと、bash-completion や他のフレームワークにも強い影響が出てくるので、
    ble.sh だけが対応しても仕方がないという考え方もできる。

2021-03-07

  * edit: キーボードマクロで "M-d" が "M-d d" と記録されてしまっている
    vi でも emacs でも同様に記録されてしまう。

2021-02-28

  * canvas/trace: wordwrap に対応する。つまり、単語の途中で改行しない様にする。

    これは今の所具体的な用途もないので取り敢えずこの儘にしておく。

  * canvas/trace: より詳しい justify の仕様について設定できる様にする。

    #D1494 の案では "SEP*WEIGHT FILL SEP" を単位として指定するという話だったが、
    これはやはり不自然な感じで分かりにくいのでもっと分かりやすい指定方法を考え
    るべき。

    例えば、最低幅1重み2 '%1.2S{FILL}' という具合にするなど。こうすると % を
    SEP に指定できないし } を FILL に指定できないが使う機会があるとも思えない
    ので気にしない。或いは '%{1.2SFILL}' とする? うーん余計に分かりづらい。或
    いは printf strftime を真似て '%1.2(FILL)S' という具合にする。

    空白は既定で '%1.0( ) ' に相当する。その他の文字は '%0.0()X' に相当する物
    とする。

    2021-03-08 というより、各 sep の性質として登録するよりも、\q{...}  を通して
    設定できた方が自然なのではないか。

    \q{hfill w=2 fill=...}... という具合に。その場合には \1\2 と同様に特別なシー
    ケンスで fill を表現する必要はある。OSC か其処らを使えば良い気がする。或い
    は ANSI seq に何かあった気がしないでもない。

2021-02-27

  * /dev/tcp/... についても特別に着色を行いたい。

    例えば < /dev/tcp/.../.. において正しいパスであるのにも拘らず、存在しないファ
    イルとしてエラーが検出される。

2021-02-24

  * canvas/trace: trace の g0 は後で合成するのではなくて \e[m の段階で設定する
    べきなのではないか。

    後、g0 という名前も余りよくない気がする。他の x0 y0 からの連想で初期の g の
    値という雰囲気が出てしまう。然し一方で sgr0 からの連想で背景色という雰囲気
    もある。実際に別の場所では sgr0 を指定する事によって背景色を設定できる様に
    なっている。

    名前はさておきどの様に振る舞うのが良いのか。例えば \e[39m で既定色に戻すと
    いう操作の場合は本当に端末既定色に戻すべきなのか、或いは g0 で指定した色に
    するべきなのかというのは微妙な所である。g0 で指定した色にするべきの気がする。

    一方で、下線などの属性に関しては g0 で指定したものから解除できる様にするの
    が自然な気もするし、或いは g0 で指定した物は常に設定されているのが自然の様
    な気もする。どちらが良いのかは分からない。やはり現状の実装で良い様な気もす
    る。

    うーん。単に設定のあるなしという捉え方ではなくて下線ありと下線なしという独
    立したスタイルがそれぞれあるのだと思えば、やはり g0 を毎回上書きするのでは
    なくて、\e[m 等に対応する操作の時にだけ g0 の値に設定するというのが正解の気
    がする。

2021-02-23

  * util: カーソルが bottom-dock にいる時の vbell の座標計算
    Ref #D1495 ... 取り敢えずの対策

    現在の実装は vbell が sc..rc を自由に使える前提になっている。しかしカーソル
    が bottom-dock に停泊している時に vbell が来るとvbell によって floating
    panels の位置が分からなくなってしまい、表示がずれてしまう事になる。

    同じプロセス (親シェル) の中で vbell を処理している場合には、一旦 floating
    panel の位置に戻ってから sc..rc をしてそれから再び bottom-dock に戻るという
    手順を踏む事によって問題を回避できる。然し、サブシェルの中にいる場合には現
    在の最新の配置情報にアクセスできないのでこの方法は取れない。

    現在は取り敢えずカーソルが bottom-dock に停泊している事はないとの想定で
    sc..rc を実行しているが、例えば info_display=bottom にして vi_cmap を使って
    いる時などにこの前提が破れてしまう。

    [解決方法]

    ちゃんと実装する為には、親シェルで全ての描画を行う様にする必要がある。その
    時に問題になるのがどうやって visible-bell の消去のタイミングを親側で決める
    かという事。idle を使う方法は bash-4 以降でしか使えない。シグナルを使う方法
    には余り頼りたくないが、現実的にはそうするしかないのだろうか。bash-3 と
    bash-4 で実装を切り替えても良い。何れにしてもサブシェルと通信を行う枠組みを
    整える必要がある気がする。

2021-02-22

  * cavnas: 描画の最中で status が高さを取得する時に textarea の内容を削り取る可能性がある

    現在の render 中に配置を決定する仕組みは問題があるので再考する必要がある。

  * cygwin: 下部での IL が動かない旨を報告する?

    後 DA2 応答をしてくれないか頼みたい。

    $ printf 'Line %s\n' {0..100}; /bin/sleep 1; printf '\e[L'; /bin/sleep 1

    最下部で DL を実行した時にも何か変な事が起こる。

    $ printf 'Line %s\n' {0..100}; /bin/sleep 1; printf '\e[M'; /bin/sleep 1

2021-02-13

  * edit: C-x e に続いて e を連続して押した時にマクロ実行を繰り返す様にしたい

  * 実は bash の read -e は C-r でコマンド履歴を参照できる。ble.sh では read 専
    用の履歴を独立に管理しているが、コマンド履歴にもアクセスできる様にするべき
    なのでは。と思ったがやはり何だか微妙な気がする。

    read 専用の履歴を別に管理するというのもありなのではないかという気がする。
    その場合には保存場所は何処にするべきだろうか。
    ~/.local/share/blesh
    ~/.config/blesh
    ~/.cache/blesh

    https://github.com/fish-shell/fish-shell/issues/744

    fish は過去に config に置いていてユーザの文句によって local/share に移動し
    た様だ。然し、local/share はそれはそれで何だか変な気もする。

  * gnuplot など他のコマンドに対して ble.sh によって編集機能を提供する事は可能
    だろうか。少なくとも pty を自分で開いてその中で gnuplot を起動する必要があ
    る? 或いは、gnuplot のリンク先の readline library を勝手に書き換えて bash
    を起動させて、更にその中で ble.sh を使って readline 関数の振る舞いを模倣す
    る?

    rlwrap 等を使うという手もある? rlwrap のじっそうはやはり pty を開くという物
    のようである。rlfe という物もあるようである。

    どうも gnuplot の場合には普通に gnuplot & で起動しても操作できる様
    な気がする。ble.sh で _ble_syntax_lang=gnuplot として更に
    exec:gnuplot を提供したらそれだけで普通に動く様な気がする。

    - ble-edit/is-single-complete-line で syntax:bash を呼び出している
      のをsyntax:$_ble_syntax_lang として呼び出す様に変更する必要があ
      る。他にも accept-line が is-complete を呼び出している。

    * shell-expand 系統の widget は gnuplot モードでは無効にしたい。
    * command-help 系統の widget も gnuplot モードでは別の実装にする。

2021-02-10

  * main: 関数内で引数なしで source すると関数の引数がそのまま source の中から
    見える。これらを区別する方法はあるだろうか。

    うーん。shopt -u extdebug であれば BASH_ARGC の数が二種類の source の仕方で
    異なるようである (但しその具体的な数は bash-5 から変わっている。更に入れ子
    source や関数呼び出しなどが絡んできた時にどうなるかは不明である)。然し、
    shopt -s extdebug の時には両者は同じになる。

2021-02-06

  * tui: TreeView

    以下の様な物があるのを見つけた。
    https://gitlab.com/TheDalaiAlpaca/saturnon/-/blob/master/saturnon

    実際どんな物かは確かめていないが、TUI 要素としてファイルピッカーは定番である。

    その基礎として先ず TreeView を実装するというのは一つの方向性。TreeView は
    List の拡張として作成するのが自然であろう。List の各要素の高さを変えられる
    様にして、更に中にそれぞれリストを保持するようにしたものと解釈できる。問題
    になるのはリスト項目が増えてきた時に高さの累積計算が重くなるという事。シェ
    ルで実装すると成ると重み付きB木の様な複雑なデータ構造にもしにくい。或いは、
    本気で重み付きB木をBash上で実装するという方向性もあるのかもしれない。

    Midnight Commander と同等の機能を ble.sh の内部で実装するというのも
    demonstration として良いのではないかという気がする。

2021-02-05

  * 他の bash プログラム

    * https://stackoverflow.com/q/41043916/4908404
      history 候補を自動的に表示する可能性について議論している

      上記 StackOverflow の質問で提案されている。Google Chrome の search bar の様に、
      幾つか文字を入力した時点でもう履歴から項目を拾って幾つか表示し始めるという可能性。
      これは fzf の領分である様な気もするが shell integration を考えるとなかなか非自明である。

      というか普通の検索でも複数の候補を表示した方が分かりやすいのではないかという気がする。
      例えば或る一定以上の時間が経ったら一致する候補を列挙するなど。
      更に待っていると曖昧一致も列挙してくれる、という具合にする。

      2021-02-09 hstr が同様の機能を提供している。hstr の動作も参考にした方が良いのではないか。

    * https://github.com/dylanaraps/shfm/blob/master/shfm (file manager in POSIX shell)
      これは dylanaraps の fff の再実装

    * これは README に乗せるバッジの話
      https://img.shields.io/github/downloads/akinomyoga/ble.sh/total
      ダウンロード数の画像を生成できる様だ

    * Incremental parsing:

      ble.sh で行っている構文解析は特殊な物であるが如何にも既存の例がありそうである。

      検索したら以下の様な物があった。

      [Tree-sitter｜Introduction](https://tree-sitter.github.io/tree-sitter/)

      参考にしている論文を見てみると state matching で skip と書いているので、
      やはり単に途中から始めるというだけでなく途中で解析を中断するという考えも
      ある。寧ろ、完全に一致していなくても局所的な一致であれば解析を跳ばすとい
      う事を実行していると思われ、より積極的な最適化である。

      恐らく先にこれを見つけていたら ble.sh の構文解析の実装ももっと複雑になっ
      て、更になかなか完成しない日々が続いたのではないかという気がする。何事に
      も一長一短があるのであって既存の研究だって参考にできる部分と捨て置いて良
      い部分がある筈だが調べてしまうと完全に対応したく成るのが問題である。なの
      で、取り敢えず持てる範囲の知識で何かやってみるというのは大切な事なのであ
      る。

      oil 等は沢山調べすぎて行き詰まっているのではないかという気もする。或いは
      逆に何だか Python -> C++ translator を開発するなど変な方向に走っていて、
      それで余計に時間を取られているのではないか等等。やはりメンテナンス等を考
      えると、Python は prototype として捨て置いて、C++ で完全に書き直した方が
      得策なのではないか。Python -> C++ をずっと使う事にしていると、少しの機能
      追加で毎回 translator にも大幅に手をいれなければならず、結局メンテナンス
      が困難になる。特に第三者がコードに手を入れるのが極度に難しい。この構造を
      保持したまま続けるには最初に完全なる translator を作って、その後は
      translator の改良を行わないという決断が必要である (状況に応じて最適な翻訳
      が異なりうる事まで考えていたら完成した translator があってもきりがない)。

2021-02-05

  * evaluate-path-spec (by 3ximus)

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

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

    2021-12-31 詳細は以下にある。
    https://github.com/akinomyoga/ble.sh/issues/82#issuecomment-773487368

    83.sh に実装を入れて試してみる事にする。

    と思ったが具体的にどの様に実装すれば良いのだろうか。先ず初めに短い物から長
    い物まで順番にパスを構築する。その後に一番長い物から順番に一致を試みる。一
    番長い物が一致すれば、後はその得られたパスを既存のパターンに当て嵌めれば良
    い。と思ったのだが、どうやって当て嵌めるのだろうか。

    * extglob まで絡んで来ると余計に分からなくなる。と思ったが extglob は
      simple-word の要件を外れるのでここでは考えなくて良い。

    うーん。glob を解釈して正規表現に変換すれば行けるかもしれない。或いは、
    ${path#$pattern} または ${path%$pattern} 等として削って行けば良いのでは? と
    思ったが、$pattern の場合には * も一致してしまうのではないか。。

2021-02-03

  * edit: 例えばファイル一覧を表示する機能を付けても良いのではないだろうか。

2021-02-01

  * complete: complete_timeout_compvar でタイムアウトした単語の glob 文字を quote しない?
    Ref #D1457

    現在はグロブ文字も quote して COMP_WORDS と COMP_LINE を構築している。例え
    ば **/*.txt に時間がかかった時に COMP_WORDS には "'**/*.txt'" という文字列
    が格納されるが、これは本来 "**'/'*'.txt'" であるべきなのではないかという事。

    * 一方で、補完関数の方が複雑な quote に対応しているかという問題もある。

    * また、ここで quote しないと結局補完関数の方でも時間がかかってしまうのでは
      ないかという恐れがある。

    という事など考えると、取り敢えずは完全に quote する実装にしておく。後で気が
    向いたらまた考える。

  * highlight: failglob の時の a/b*/c/d.txt の着色が最後のファイル名になっている。
    本来はどの時点で failglob になるか判定して着色するべきなのではないだろうか。

2021-01-28

  * progcolor: ble/syntax/progcolor/eval-word を着色を跨いでキャッシュできないか

    特に展開結果を何処かに保存しておきたい。新しい配列を用意するか、或いは hash
    にして記録するか。

    a hash にして記録すると一度評価した単語を再評価する機会が失われる。ファイル
      が追加・削除された時に更新されなくなってしまう。

      やはり、単語単位でやはりキャッシュしたい。そうすると shift にも耐えうる仕
      組みにしたい、という事で新しい配列を用意するか、或いは既存の配列に格納す
      るという方法になる。

    b 新しい配列を追加する

      また shift 等の操作が増える。面倒である。

    c 既存の配列に要素を追加する

      既存の配列に格納する場合には任意の文字列を含める事ができないので、補助配
      列にデータを格納する事にしてその添字を既存の配列に入れるという手がある。
      特に単語に id を振っておけば今後の word に関するデータ拡張にも使う事がで
      きる。

    →これに関しては ble/syntax:bash/simple-word/eval の側でキャッシュする様に
    したので、今の所はここでは対応しなくて良い気がする。当初は simple-word/eval
    では非常に短期のキャッシュしかしない方向を考えていたが、ファイルシステムが
    そう頻繁に変わる訳でもないので、取り敢えずは行毎にキャッシュを保持する事に
    した。なので、simple-word/eval のキャッシュは単語よりも寿命が長いので単語毎
    のキャッシュは今の所は考えない事にする。

    * 但し、やはりファイルシステムの変化に追随したいという事であれば、適当にキャッ
      シュを更新する必要がある気がする。或いは、globpat を含む様な場合にのみキャッ
      シュを行うというのでも良い様な気がしている。

    * また、ここでの実装手法は例えばエラーメッセージの記録等の場合にも使えるの
      ではないだろうか。という気がする。

2021-01-22

  * highlight: 引数が沢山あると cygwin で滅茶苦茶遅い

    これは様々な種類のパス名展開を試そうとするのが原因だろうか。
    command 名と同様にキャッシュする様にしても良いのではないだろうか。
    でも少しずつ微妙に異なる引数が沢山ある場合には結局遅い。
    それよりは着色自体の高速化について考えた方が良いのではないか。

    * chat でも遅くなるかどうかについて確認する。
      やはり微妙に遅い様な気がする。

    何が遅くなっている原因化について確認する必要がある。
    例えば fork している可能性はあるだろうか。

2021-01-08

  * syntax: 算術式の quote が変である

    x echo $((a['$hello'])) の $hello は展開対象なのに着色されない。
      →然しこれは文法上の問題なので寧ろ着色しない方が自然である様に思われる。
      (これは eval の引数を着色するのかという問題にも通じる)

    x ((a["$index"])) がエラー着色になっている
      →どうもこれは bash-5.0 から振る舞いが変わったという事の様である。

    x bash-5.1 からは (()) でも ' は quote ではない。

    x 更に言うと a['...'] の ' は a が連想配列の時には必ずしもエラーではない。
      現在はエラー着色になっているがこれは修正するべきの気がする。

2020-12-19

  * Note (#D1435): blehook WINCH を処理している最中に終了したユーザのジョブがあ
    るとその通知が画面に表示されない可能性がある。これは実際に起こりうるのかど
    うか確認していない。

2020-12-14

  * progcomp: progcomp で生成された補完候補を現在 quote している。

    * 生成された候補が既に quote されている場合や展開を含む場合に、
      意図したのと異なる結果になってしまう問題がある。
    * 更に既に入力済みの部分に一致しなくなるので遡って書き換わる可能性もある。
    * 生成された候補が複数の単語に分かれる場合に、
      それが blesh の quote によって一つに結合されてしまう問題もある。

    理想的には生成された候補を改めて simple-word/eval して、
    その結果に基づいて単語を再度挿入し直すという事が考えられるが、
    x 全ての候補に対してこれを実行する事を考えると処理が重くなってしまう。
    x また、\**\* 等を展開すると *** になってしまうので
      その quote を復元する方法についてもちゃんと考えなければならない。

    或いは simple-word element を一つずつ抽出して処理すれば良いのかもしれない。

2020-11-30

  * tui: face editor の TUI の様な物を作っても良いのかもしれない [#T0007]
    というより fish の Web interface の様な物を TUI で提供しても良いのでは。

    2021-04-25 @Alyetama から似たような提案を受けた。
    https://github.com/akinomyoga/ble.sh/issues/80#issuecomment-826194833これは
    初期設定 wizard の様な物を想定している様だが、TUI config ではもっと自由にい
    つでもどの設定でも選んで設定できるのでより自由度は高い。そう言った物でも良
    いかという事を一応確認はしてみる。

    作るとしたら先ずは Color Picker?
    その前に layout engine? 或いは画面の切り替え?

    Window system がどうのこうのという計画があったような。window system に関し
    ては内部バッファだとかスクロールだとか textarea だとか様々の物を内包する物
    であった筈で、此処で必要になる物は其処まで複雑な物ではない。でも一緒に実装
    してしまっても良い様な気もする。

    - Windows system に必要な物。control, window, layout-engine,
      background-buffer, redraw, resize, etc.

      既にある panel, textarea 等を拡張する感じに考えても良いのかもしれない。但
      し、これ以上の ble.sh の肥大化を避ける為に canvas ではなくて新しく
      lib/core-forms.sh 的な物を追加して其処で実装するのが良いのではないか。
      textarea に関しては、forms が或る程度形になってから対応するという形で良い
      気がする。

      control に属する変数の記録方法? これは textarea と同様にしたいが、
      textarea の方も forms に対応しようとすると調整が必要になると考えられるの
      で、最初は既存の枠組みに捕われずに実装するので良い気がする。

    - window: overlay を実現する方法として二つの可能性が考えられる。

      a redraw 関数の方で clip 等を処理する方法。

        これは各 control の実装が複雑になってしまう。というより任意の clip
        region の形状に対応しようとしたら非現実的な実装になってしまう。

      b もう一つは Window の側で buffer を内部に保持し、最終的な描画の際にそれ
        を適当に clip して出力する方法。

        これに関しては内部 buffer の表現方法に工夫が必要になる。

    取り敢えず何も考えず少し実装してみた。clip に関しては redraw の側で適当に処
    理する事にした。また、trace に於いても clip 機能を実装した (#D1493)

    invalidate 範囲を記録できる様にしたい。

    更に、要素のサイズが変更された時、移動した時には親の該当範囲も一緒に
    invalidate する必要がある。


    自身の内容が変化した時、自身に被っている別の要素も一緒に更新する必要が出て
    くる事に注意する。

    a 上に物が被っていない時には clip 領域を勝手に広げて描画しても良いのではな
      いか。描画範囲を広げても良いかどうかについては render.draw の呼び出し元か
      ら指定できる様にすると良いのかもしれない。

    c 或いは、そもそも被らない様にするか、被っている時には更新しない様にすると
      いう手もある。

    d 或いは、render.draw の呼び出し元で一旦シーケンスを取り出して、その上でそ
      れを再度 trace によって clip するという手もあるかもしれない。然し、これは
      描画内容が大量にある場合にとても遅いので実は避けたい。

2020-11-20

  * bash: declare -c や ${var~} 等は 5.2 で削除するとしているが本当だろうか

2020-11-13

  * complete: bash progcomp と ble.sh progcomp の競合問題

    現在は complete:* の方が builtin complete の設定よりも優先される様になって
    いる。これは ble.sh がロードされていない時はbash-completion を使い、ロード
    されている時は ble.sh 様に特化した補完設定を使うという状況を考えると自然で
    ある。

    然し一方でユーザーが自分の好きな設定を builtin complete で設定してもそれが
    反映されないという問題が生じる。やはり builtin complete の方を優先させるべ
    きだろうか。或いは、complete:cd は既定ではロードしない様にして、contrib か
    何かに入れてユーザにロードさせる様にするのが良いのではないかという気もする。
    然し、ユーザにロードさせるとしてもコマンドを一つ一つロードするのではなくて、
    まとめてロードするという状況も考えられる。その場合には、やはり builtin
    complete と complete:* の競合が起こってしまいどちらを優先させたら良いのか分
    からなくなる。

    或いは ble.sh に特化した設定も builtin complete 経由で呼び出す様にする?
    しかしそうすると ble.sh から ble-detach した時に動作しなくなってしまう。

    attach/detach の際に設定を保存・復元するという方向性も考えられる。

    complete を上書きして両方の設定を行える様にするという手もある。この場合には
    attach/detach する時に既に設定した内容を読み取る等の工夫が必要になる?

2020-11-11

  * syntax: $HOME 等の変数展開があるパスに対して simple-word/eval が重い問題

    中でグローバル変数の復元等の複雑な処理をしている。一回呼び出すだけならば良い
    が $HOME/.mwg/src/ble.sh/archive/layers ... 等の様なパスの着色で各ディレクト
    リの階層で展開を試みている場合に、何度も呼び出す事になると遅さがかなり目立つ
    ようになる。

    単語着色では determine-separated-path -> locate-filename ->
    highlight-pathspec という具合に三段で処理していて各段で毎回 eval しているの
    で特に重い。これは処理を統合して高速化する余地もある。コードが汚くなるという
    問題はある。よく考えたら現在の実装では locate-filename は特に eval は実施し
    ていない。単に : で区切っているだけである。なので locate-filename に関しては
    気にしなくても良い。

    或いは複数のパスを一度に eval する機能があっても良いのかもしれない。その場合
    に結果をどの様に返すのかは難しい。複数単語に展開される事を考えて既に一つの
    eval の時点で ret が配列だからである。各パスの最初の単語だけを返す事にするか、
    或いは全ての単語を全部混ぜて一つの配列に返すか。一つの配列に格納する場合には
    各パスに対応する index の範囲を返す事ができるがインターフェイスとしては分か
    りにくい。

  * bashbug: builtin で while という名前の builtin を load すると他の builtin が
    使えなくなる。

    ? 使えなくなるのは、同じ dll の中の物のみなのか或いは全ての dll の loadable
      builtin が使えなくなるのか。

    ? while 以外にも問題を起こす名前は存在するか。

    ? 影響を受ける builtin はキーワードと一致する名前の物のみか或いは全てか。

2020-11-07

  * complete: PATH=path1:path2:path3 の補完

    PATH=path1:path2:path3 の時に着色が最後の要素にしか適用されないし、また補完
    は全然働かない。全く動かないのならばまだしも中途半端に動くのは変なのでちゃん
    と対応したい。

    →着色に関しては #D1409 で議論する。

    complete に関しては元の bash ではちゃんと動いているので尚の事問題である。

  * highlight: 条件コマンドの中での着色が効かない。着色しても良いのではないだろうか。
    今まで実装していなかったのは正しい文法解析や入れ子などの処理が面倒だったから。

    今確認してみると 条件コマンドの中でも ( && || ) などは特別な意味を持つ様であ
    る。更に & や | を使うとエラーになる。<< 等のリダイレクトもエラーである。必
    ずしも空白で単語が区切られる訳ではない様なので、これに関しては文法解釈のレベ
    ルで修正が必要になる。

    今試すと ; も途中に現れると区切りとして取り扱われてエラーになる。

    * |&;<>() は特別に取り扱う必要があるという事。単体の < と > に関しても正し
      い演算子の文脈に現れれば大丈夫だが、二項演算子の現れない場所で使うと構文
      エラーになる。この様な構文エラーまでチェックする必要があるだろうか。或い
      は演算子の結合まではチェックしない事にするか。

    * 括弧の途中で ]] が現れた場合にもエラーになる。

2020-11-06

  * complete/mandb: progcomp で生成したオプションに関してもできれば desc を表示する様にしたい。
    progcomp に候補を生成させてもしオプションが含まれていて、
    かつそれが mandb の中に含まれているという事が分かった時に desc-raw を表示する。

    * git 等の場合には man git で得られるオプションと
      サブコマンドで得られるオプションは異なるので注意する。

  * complete/mandb: bash の場合にはビルトインコマンドのオプションまで混ざって列
    挙されてしまって駄目。bash 固有のオプションについてまとめたファイルを用意し
    ておくべきである。

    bash builtins のオプションに関しては builtin ... --help を使用すれば取得でき
    る。これはこれでまた解析の為のコードを書かなければならないが、bash の
    builtin に限れば形式が定まっているので解析のコードを書くのは難しくはない。

  * complete/mandb: 何と man git は .PP ... .RE 4 ... .RS でオプションを説明している。
    この様に .TP を用いない様な場合にも対応するべきなのだろうか。

  * complete/mandb: 同じ意味を持つオプションについて。
    同じ意味を持つ複数のオプションを分ける時に、
    分けてから sort するのではなくて sort してから分けるべきではないか。
    同じ意味を持つオプションは連続されて表示されて欲しい。

2020-09-07

  * complete: メニュー絞り込みが働いている状態で単一確定ができない場合がある

2020-09-03

  * main: attach 戦略再考 [#T0004]

    attach の戦略に関する議論は以下にある。
      #D1382, #D1124, #D0940, #D0737

    | a 即attach。PS1 表示
    |   x PS1 が後で変更された時に問題。
    |   x 後の設定の出力が消滅する
    |
    | b 即attach。PS1表示はする。出力抑制はしない
    |   x PS1 が後で変更された時に問題。
    |   x 後の設定の出力と混ざる
    |
    | c 即attach。PS1表示はpromptまで遅延
    |   x keymap初期化に時間がかかる
    |
    | d 即attach。PS1表示する。出力は記録して後でdump
    |   x 後の設定が対話的なインターフェイスを起動した時に問題
    |   x 後の設定が /dev/tty に対して出力したら防げない
    |   x 後の設定が初期化進捗などを出力するとそれが実時間で反映されない
    |
    | e PROMPT_COMMAND。trap DEBUG/RETURN を用いて変更検知
    |   関連: #D1124, #D0737
    |   x DEBUG はコマンド直前の実行なので最終行での書き換えは防げない
    |   x RETURN は rcfile 末尾では発生しない
    |
    | f PROMPT_COMMAND の読み書きを hook する(非ネイティブな)手法はあるか?
    |   x ない
    |
    | g 他の hook/trap を用いて適切なタイミングを検出?
    |
    |   a EXIT はシェルが終了する時なので使えない
    |   b command_not_found も使えない
    |   c kill -USR2 $$ によるハンドラは?
    |     x 試すと rcfile 終了を待たずに次のコマンドですぐに実行される
    |     x kill ... & として別プロセスから投稿しても同様
    |   d bash (execute_prompt_command) を確認したが介入点は他になさそう
    |   e PS1 に kill 等を埋め込んで通知させる
    |     x これは PROMPT_COMMAND よりも信頼できない
    |
    | h PROMPT_COMMAND の中の最初のコマンドを DEBUG で検出?

    可能性があるとすれば h の手法である

    * trap DEBUG/RETURN の性質を熟知していないとユーザの設定した
      DEBUG/RETURN と干渉しない様にするのは難しいと考えられる。
      これは DEBUG/RETURN の枠組みを整えてからにする必要がある。

    rcfile で ble.sh をロードした時には rcfile を抜けた後の
    PROMPT_COMMAND 直前でアタッチを行う。

    * "PROMPT_COMMAND の最初のコマンド" は恐らく判定可能である。

      rcfile 及び最初の PROMPT_COMMAND 内にいる時は BASH_LINENO の最後の
      要素は0 になっている。rcfile 内にいる時は FUNCNAME の最後の要素は
      "source" になっている。更に bash-4.4 以降では rcfile から
      PROMPT_COMMAND に移る時に $- に s が追加される。

      PROMPT_COMMAND で何か実行するならば、最初のコマンドは必ず
      FUNCNAME[-1] != source になっている筈である。

    対話シェルで ble.sh をロードした時は "bashrc を抜けた直後" という戦
    略は使えないが、HISTCMD, ${_histcmd@P} を用いてユーザコマンドか
    PROMPT_COMMAND かの判定が可能である。

    * HISTCMD は ユーザコマンドを実行している時には $(history 1) の最初
      の要素に一致する。PROMPT_COMMAND を実行している時には常に 1 になる。

    * HISTCMD が unset されている場合には代わりに _histcmd='\!';
      "${_histcmd@P}" が使える (bash 4.4)。HISTCMD が unset されているか
      どうかは HISTCMD=A して値が変化するかどうかで判定できる。

2020-08-27

  * 真面目に宣伝など考えるべきなのかもしれない。

2020-08-03

  * README: bashrc 設定方法の更新
    関連: #D1382, #T0004

    最終的には bashrc の何処に ble.sh を記述しても動くようにしたい。取
    り敢えず、比較的信頼できる手法が確立するまでは README の load 方法
    はそのままにしておく。

  * macOS で遅いという話 (reported by tigger04)
    https://github.com/akinomyoga/ble.sh/issues/58

    チェック項目は…

    * complete -r の代わりに
      shopt -u progcomp を指定したら改善するか?

    問題になっている可能性がある処理は
    ble/complete/progcomp/.compgen の builtin compgen 経由で呼び出される。
    特にユーザの定義した関数・コマンドは以下の関数経由で呼び出される。
    - ble/complete/progcomp/.compgen-helper-func
    - ble/complete/progcomp/.compgen-helper-prog

    上記の関数に benchmark を設定して stackdump なり何なりを計測する?

    ble/function#advice \
      around ble/complete/progcomp/.compgen-helper-prog \
      ''

    * 対策としては auto_complete の時には progcomp を実行しない
      というオプションを追加するというのが一つの可能性。
      bleopt complete_auto_progcomp=1 という事にするのが良い。

      実現可能性について。
      現在の呼び出し文脈が auto_complete かどうかを判定する必要がある。
      確認してみると comp_type に auto を含めている様である。
      実際にそうなっているのか確認する。

    情報をメールで貰った。
    メールではどの期間だけ complete -r を除いていたか分からないとしているが。

    2020-08-05 05:12:50 IST
    2020-08-05 05:13:27 IST
    2020-08-05 08:43:54 IST
    2020-08-05 08:43:57 IST
    2020-08-05 11:02:53 IST

    まあ、どの期間だけ有効になっていたのかという情報は実はそんなに重要ではない。

    眺めていて気づいた事。

    最後にユーザが入力を行ってから auto-complete が起動するまでに一定の時間がかかっている。
    大体 200ms の様な気がするが、しかし時間帯によって変わっている気もする。
    TAB 補完の場合にはこの delay が存在していない (0.06s) 事を考えると、
    これは history 補完にかかる時間という事だろうか。
    history 補完を無効にしたらこの delay は少なくなると判断して良いだろうか。

    補完が走らずに入力できている部分は history に match している入力であろう。

    どうも後半で時間がかかっているのは history の様に思われる。
    TAB 補完の時には 150ms 程度の遅延だが自動補完の時には 600ms に増えている。
    然し、その後で 200ms 程度に減少したりもしている。
    うーん。或いは単語の展開に時間がかかっているのかもしれない。

    * reject: 取り敢えず history 展開について高速化できないか確認する。

      | search-history-heavy について改善できないか考える。
      |
      | a 特に bash-5.0 以降では history -d range を用いて削除した上で
      |   history -p を実行すれば高速に過去の履歴を読み出す事ができるのではないか。
      |   →と思ったがよく考えたらどの範囲を削除したら良いのか不明である。
      |
      |   !string で一致させてその後その候補が当て嵌まらないと分かったとする。
      |   この時その候補以降の履歴項目を全て削除してから再度 !string で
      |   一致させれば良い様に思うが、最初に一致した候補が何番目の履歴項目か
      |   という情報がないのでどの範囲を削除したら良いのかが分からない。
      |
      |   a 例えば二分法で探索する? と思ったがこれだと二分の一の確率で
      |     サブシェルを生成しなければならない。明らかに非効率的である。
      |     或いは履歴展開に履歴番号も一緒に展開させる方法があったろうか。
      |     ない気がする。
      |   b やはり履歴番号を抽出できないかと思ったが、その様な履歴展開はやはりない。
      |     !string で一致させて単語指示子で履歴番号に置換できれば良かったが
      |     その様な単語指示子は存在しない。
      |   c 或いは、番号を指定しなくても一致した項目以降を削除する方法があれば良い?
      |     然し、history -d の引数はやはり数値であって履歴展開ではない。
      |
      |   この方針は難しいのではないかと思われる。
      |
      | b 或いは、history | grep を用いて最後に一致した項目を取り出す事ができるのではないか。
      |   但し、grep の時の問題は行区切りをどうするのかという事。
      |
      |   grep -z を用いれば NUL 区切りで判定する事が可能。
      |   然し、これは GNU extension である。安易には使えない。

      →うーん。調べてみたがちゃんと history search を呼び出す時に
      stop_check を指定しているのでユーザの入力があった瞬間に復帰する筈である。
      つまりこれ自体に時間がかかっていたとしても動きが遅くなる事はない筈?

      そもそも complete -r で解決したという事を考えると明らかに history は関係ない。

      然し、実際に timing log を見るとユーザの入力が待機されている…という事はない様な気がする。
      やはり現在の情報では history からの自動補完が問題になっていると考える根拠がない。
      従って、(不自然な方法を取ってでも) history 展開の高速化方法について考えるのは不毛である。

    * 再び報告があった。コンピュータ自体の処理が重くなっている時に動かなくなるという事らしい。
      普通に bash を動かしている時には問題ないという事を考えるとファイルアクセスが怪しい。
      ファイルアクセスしている箇所は沢山ある。特に着色のためのパス名展開である。

2020-06-04

  * 行数が極端に少ない時の動作 (横スクロール)
    bash-5.1 では横スクロールモードに移行するそうだ。

    そもそも現状で一行しか使える行がない時に何が起こるか。
    実際に試してみると (line 1) という表示だけになって
    更にその上に何か表示しようとするのでまともに表示できない。
    2行の場合にもまともに動かない。vi-mode の mode name で 1 行消費している為である。
    3行の場合にようやくまともに動く様になるが、それでも vbell が上に被ってしまう。

    横スクロールまで実装しないとしてもまともに動作する様にはしたい。
    そもそも (line N) という表示を省略する様にする?
    現状の実装ではプロンプトは必ず表示する様になっている。
    然し、プロンプトを表示するからこそ変な事になっているのである。

    a 行数が 1 になった時にはそもそもプロンプトを表示しない?
      然し、それだとプロンプトが何も表示されなくなってしまってそれはそれで変だ。

    b プロンプトは固定で残りの部分で文字列を編集する?
      これだとプロンプトが画面よりも長い時に何もできなくなる。

    c プロンプトも一緒に横スクロールする?

      | これに対応する為にはプロンプトの内部の各文字の配置を追跡する必要
      | が出てくる。
      |
      | Bash native でも \[...\] を使っている場合にどうやって数えるのだ
      | ろう? という疑問が残る。
      | →bash の動作を見たところ、prompt も一緒にスクロールする。しかし
      | prompt の途中位置でスクロールが止まる事はない。つまり、prompt は
      | 全体が表示されるか全く表示されないかのどちらかである。
      | →prompt 自体の長さが画面の横幅よりも大きい時には、常に横スクロー
      | ルした状態になってしまい、コマンドの1文字目は常に '<' に隠れて表
      | 示されない状態になる。また表示の乱れも発生する。

      Bash は横スクロールによってプロンプトが表示されるか、全く表示さ
      れないかのどちらかの状態になる。中途半端にプロンプトが表示されて
      いる状態はない。プロンプトの長さが画面の長さよりも大きい場合は対
      応しきれていない。

    * プロンプトが範囲内に収まらない場合には何が起こるのか?
      プロンプトの trace の時に高さを制限していただろうか。
      →駄目。制限はしていない。そもそも制限する事自体が自然な動作なのかも分からない。
      リサイズした時に上に流れた情報を参照したいという場合を考えれば、
      プロンプトは制限せずに上に流れてしまうという振る舞いが自然の気がする。

    現在のスクロールの実装はプロンプト行の次以降で実施する前提になっている。
    つまり画面の高さが1行しかない場合には色々弄らなければならない。
    プロンプトが複数行ある場合にはそれだけ多く画面の高さが必要になる。

    * プロンプトの出力は気にせずに実施する。画面がスクロールしても気にしない。
      →これを実行するとその他の panel の描画位置もずれてしまう事になる。
      他のpanelの内容を上書きしないように事前に空行を挿入しようにも、
      空行を挿入した時点で他の panel の内容が反対側の端から流れてしまう。
      という事を考えると、行数が厳しい時には他の panel は全て潰すのが現実的。

      潰す条件がプロンプトの高さが一行に収まりきらない場合、というのは
      プロンプトとして変な物を指定する場合を考えると制限が強い気もするが、
      その様な場合は余りないと考えればそれでも良い気もする。

      因みにプロンプトの高さが1行に収まらない状況としては、
      プロンプト自体に改行が含まれている場合以外にも、
      プロンプト内に長い文字列が含まれていて何度も折り返す場合を含む。

  * util: ble/dict#* を用意する可能性?

    設定ファイルの自動アップデートの実装に関連して
    ble/dict#* という物を作成しても良いのかもしれないとも思う。
    既に辞書的な構造は ble.sh の各所で個別に実装して使用している。

    辞書の bash-4.0 未満における最適の実装は何だろうか。
    任意の key を取り扱える様にする必要性を考えると、
    : 等を区切りにして scalar に key を格納する訳には行かない。
    そうすると配列に key を格納する必要が出てくる。
    配列が巨大になってくると重くなってくる。

    a 簡単な hash を作るという手もあるだろうか?
      例えば配列サイズが小さい時には最初のバイトだけを使って、
      要素が増えてきたら n 番目のバイトまで使って hash を生成する。
      と思ったがそれだと共通の接頭辞を持つ key が沢山ある時に hash が衝突する。
      例えば /home/murase/... という物が沢山ある場合。

    b 或いは全ての文字を用いて hash を計算する?
      という事にすると今度は長い文字列に対して各文字について文字コードを取得する手間がかかる。
      特に bash-4.0 未満では色々面倒な事をする。何れにしても ble/util/assign を使うので遅い。
      (実際にこれでキャッシュをしていないのは下手にキャッシュするよりも ble/util/assign
      を実行した方が高速であるという事からであろうという気がする。)

    c key の sorted list を管理する。
      文字列で辞書順でどちらが速いかについては [[ str < str ]] で判定できる。
      後はアクセスの度に二分探索を実施すれば良いのである。
      挿入には結構時間がかかりそうな気もするが、まあ、大丈夫。
      然し、よく考えたら bash-4.0 未満の配列はアクセスが線形時間だった気がする。
      という事を考えると二分探索よりも線形探索の方が実は良いのかもしれない。

    使用ケースによって色々なので汎用的な実装はやはり難しい気がする。

    * key が整数の場合には普通に配列を使えば良い。

    * key が有限の単語 (識別子) の集合であれば、
      local apple=1 banana=2 pineapple=3 orange=4 等の様にして、
      普通に arr[apple]=red 等とという風にすれば良い。

      或いは普通に変数に保存すれば良い。
      eval "arr_$key=red" という具合である。
      この場合大量の変数が散らかってしまうが、
      それが気にならなければ最良の気がする。

    * key に ":" が含まれない場合には
      keys にコロン区切りの key の集合を保存しておいて、
      head=${keys%%:$key:*} head=${head//[!:]} 等とすれば
      key が何番目の要素であるかというのを取得する事ができる。

    * key が文字である場合も同様にして
      head=${keys##"$key"*} 等としてから ${#head} で文字数を見れば
      それが何番目の要素であるかというのを判定する事ができる。

    * 辞書をメモ化に用いている場合には実は関数自体の計算時間が
      bash による辞書の模倣よりも速い可能性を考えるべき。
      例えば ble/util/s2c については ble/util/assign printf %d '$c の方が
      下手な辞書よりも高速なのである。

    * key の種類がそんなに沢山でない場合には、
      key を配列に格納して線形探索するというので良い。
      これが最も単純で自然な実装になる。

      key を sorted list に入れて二分探索するという可能性もあるが、
      Bash-4.0 未満の配列のランダムアクセスは線形なので、
      それよりは普通に線形探索で舐めた方が良い気がする (実測すると違うかもしれない)。

    結局使用ケースによって最適な実装方法が異なるという事から統合は難しい。
    ble.sh の内部で使わない以上は用意しても仕方がない様に思われる。
    そもそも ble/dict#... の形式による配列アクセスは文法的にそんなに綺麗でもない。
    等の事を色々考えると、ユーザの為に用意する程でもない。

2020-05-20

  * 破壊的変更と後方互換性

    * done: keymap_vi_nmap_name は keymap_vi_mode_nmap_string 等に改名するかもしれない。
      或いはもっと別の名前? やはり keymap_vi_mode_normal で良いだろうか。
      改名するとしたら complete_stdin_frequency と同様に別名に書き換える様にする。
      実はオプションの改名について枠組みにしてしまっても良いのかもしれないという気がする。

    * 勝手に古い設定を書き換える機能を作っても良いかもしれない。
      毎回一行ずつ書き換えを実行するのではなくて、
      書き換えを実行する sed スクリプトを貯めておいて、一括で書き換えを実行する。
      cp a a.bk && sed "$script" a.bk > a 等の様に実行する。

      sed スクリプトは何処に貯めて於けば良いのだろうか。
      書き換え対象のファイル名と一対一に対応するファイル名にする必要がある。

      a 辞書にファイル名を記録するか或いは hash を用意するか。
        hash は計算に時間がかかるので辞書にファイル名を記録するのが良い気がする。
        然し、bash-4.0 未満ではどの様にするのが良いのか微妙である。

      b 或いは、別に辞書など作らなくても直接ファイルシステム上に書き出しても良い気がする。
        つまり、 "$file.sed" に書き出して置いて、それを適用して削除する。という具合にする。
        問題はファイル名が被らない様にするという事。乱数で決定する事にすると駄目。
        "$file.__BLE_REWRITE__.sed" 的なファイル名にするのが良いのではないか。

    * ble{-edit => }/prompt/{print,process-prompt-string,backslash} についても
      警告を表示する様にする仕組みが必要になる気がする。

2020-05-16

  * TERM=alacritty で何か変な事が起きるらしい。
    https://github.com/rux616/init/commit/b03e7ef3dab5171d1f60aa61323ef823401217d5#diff-0af95dc8119f1c458b7a0fd76dfe8042R37-R39

    調べてみると alacritty:extra/alacritty.info が terminfo らしい。tic -x extra/alacritty.info で入れる。
    然し、何も問題は起きていない様に見える。256color もちゃんと動いている。ずっと使っていると発生する問題だろうか。
    これは時間があれば rux616 に何が起こるのか尋ねても良い。
    所で、いつの間にかに alacritty は jwilm/alacritty から alacritty/alacritty に移動したらしい。

    →cache/alacritty.term を確認した所 ich, ech, dch が空になっている。
    然し、ble.sh は ich, dch は使っていない。ech を使う場合でも、
    [[ $_ble_term_ech ]] の時にのみ有効になる様になっている。

    他に気付いたのは 8-15 の着色が 0-7 と同じになっているという事。
    然し実際に tput で tput setaf 15 とすると CSI 9 7 m になる。
    何かが間違っている。再度実行してみた所、問題なく初期化された。
    と思ったら alacritty.term と xterm-256color.term の内容が同一になった変だ。

    続けて何度試しても問題は発生しない。何が起こったかは謎である。

2020-04-25

  * trap: DEBUG trap を用いて DEBUG trap を再現できるか? [#T0003]
    参考: #M0016

    つまり関数呼び出し毎に DEBUG trap が設定されるというのを実装する必要がある。
    ble.sh が使っていなければ特に問題は発生しないが、
    INT を受信した時に ble.sh が DEBUG trap を設置する事になっている。
    従って、実装できれば実装するのが良いという様に考える。

    要件は以下の通り

    * 何も DEBUG trap が設定されていない時には overhead 0 にする。
      つまり builtin trap で何も設定されていない状態にする。
      ユーザか ble.sh のどちらかが何か設定している時に有効にする。

      実のところ、ble.sh の使い方は一時的な物なのでユーザの trap と
      同レベルの取り扱いで良いという気がする。唯単に trap で列挙されない、
      ユーザの設定した trap も保持する、という事が異なるだけ。

    * 関数呼び出しでの継承・非継承を再現する。
      実はこれはそのまま bash の継承・非継承に従うだけで良い気がする。

    * 呼び出し元への影響についても再現する。
      これは新しく trap DEBUG が呼び出される時に、
      builtin trap DEBUG もやり直せば良い?
      と思ったがそもそもそんな事をする必要もない気がする。
      現在のフレームに既に何か設定してあるという事は
      呼び出し元ではそれが必ず有効という事だから。

      bash-4.3 以下では何れにしても呼び出し元に影響を与える事はできない。
      うーん。bash-4.3 以下では trap DEBUG で保存した trap handler を
      関数が抜ける時に削除する必要があるという気もする。
      これについては実装時に注意深く実装すれば良いだけ。

    * DEBUG trap の中で DEBUG trap は設定できるが発火しない。
      BASH_COMMAND は書き換わらない。

    実の所、DEBUG は C-c の時にしか設定していないので、
    取り敢えず気にしない事にする。

    先ず試験的な実装を作成して見るのが良い気がする。

  * trap: INT
    現在の実装ではユーザの設定した INT で握りつぶしても、
    ble.sh の設定したハンドラによって実行が中断される。
    ユーザが INT を設定している時には握りつぶさない様にするという手もある。

  * [保留] bash-4.4 trap 内無引数 return の修正

    ref #D1350

    bash-4.4 以降では trap 内の無引数 return は trap handler が開始する直前の $? を返す。
    強制的に trap handler の内部での直前の $? を返す様にする方法はあるだろうか。

    * return() { builtin return $?; } とする案
      x 本来の return を実行する方法がない。
        RETURN trap を使って return 関数呼び出し後に builtin return できないか?
        x RETURN trap は抑も終了しようとしている関数内の文脈で実行される。
        x RETURN trap 内部では RETURN は発火しない。
    * alias return で何とか無引数の場合を $? に置き換える事は可能か。
      x 引数がある場合とない場合の両方に alias で対応するのは難しそう。

2020-04-19

  * history: 履歴の管理の枠組みで欲しい物

    1 実行したコマンドを追記で記録する仕組み (勝手に編集したりしない)
      他のシェルと同様に追加の情報も記録する?

      * 実行したディレクトリ。実行した時刻。$$.$LINENO

      * コマンドラインに含まれる有効なファイルパスの集合

        | fish はこの情報を用いて history autosuggestions の時に
        | コマンド履歴のフィルタリングを実行する様だ。
        | 然し疑問なのは echo > a.txt で a.txt など出力ファイルが元から存在していた時には、
        | 新しくファイルを作成したいという時にその履歴が候補に出てこない、
        | という事態になってしまうのではないかという事。
        |
        | その様に考えるとやはり実は個別のコマンド毎に判定した方が良いのではないか。
        | 例えば cd の場合には使い方が決まっているので、
        | 実際にそのコマンドラインを実行した時に成功するか失敗するかはすぐに判定できる。

        自動補完のフィルタリングに関しては完全な判定はできないので
        取り敢えず core でサポートしなくても良い。

      * zsh は実行にかかった時間も記録する様である。

        | 然し、これは微妙。何故ならば bash ではコマンドの実行開始前に履歴を追加するから。
        | 実行後に書き換える仕組みが必要になる。或いは開始の記録と終了の記録を別々にする?
        | そうすると複数のセッションで実行している時に互い違いになってしまう。
        | なので実行するコマンド毎に ID を設定する必要がある気がする。
        | と思ったが ID は $$.$LINENO 等で良い気がする?
        | x と思ったが同じ PID でシェルが起動する事もあるのでは?
        |   o と思ったが同じ PID で複数のコマンドを同時に走らせるという事はないので問題ない。

        開始と終了をそれぞれ記録する。$$.$LINNO でコマンド毎に ID を設定して対応を取る。

    2 記録されたコマンドとは別に bash の履歴で遡れるコマンドのリストを管理する仕組み。
      こちらは長いコマンドを自由に削除したりできる様にする。
      倍加したりすると嫌なので枠組み 1 で得た差分に基づいて更新する?
      差分を取る方法を気をつけないと結局倍加するので、
      ちゃんと同期して差分を取れる様な枠組みを整理する。

2020-04-09

  * 別の bash の枠組みについて
    https://github.com/sio/bash-complete-partial-path
    https://github.com/mgalgs/fuzzy_bash_completion
    https://github.com/brujoand/sbp

2020-04-02

  * test: テストフレームワークの追加機能

    * 単体テストの機能
      * テストを直接本体の関数の近くに書き込める様にする?
        これは mwg_pp.awk の枠組みを用いた対応が必要である。というか出力
        先が ble.osh と分かれている場合を考えると、#%$> の右辺に変数を指
        定するべき? と思ったが #%$> を含む行自体をマクロに入れれば良い。

    * テスト集合の管理
      * 集計・サブシェルで実行した結果も扱える様に。
      * テスト結果のキャッシュ
      * 並列テスト
      * 様々な bash の version の結果を集計

    * 他のフレームワークの機能を確認
      * bats
      * oil/test
      * shellspec
        kcov を用いて coverage が計測できる
        skip を設定できる。前回成功したものをスキップできる。

    * GitHub 用に Travis を設定する。

2020-03-22

  * read -t や read line の戻り値が変だ
    →今試してみると別に変な事はない。-e が入っていても入っていなくても。

    一応 C-c で read -e を止めた時の終了ステータスは 130 の所が
    ble.sh の実装では単に 1 になっているという違いはある。

  * bash-3.0 が malloc array.c botched というエラーが出てクラッシュした。
    これは bash のバグである。そして古いバグなので治りそうにない。
    更に言うと再現性もあるのかどうか微妙である。

  * oilshell で色々説明を行った。
    それらの説明へのリンクを作成して後で纏めるのが良い気がする。
    これは後で実行する。

  * decode: 大量の貼り付けの高速化4 (report by dylankb)

    現状の ble.sh の枠組みの中では大幅に改善した。
    然し、やはり decode を自前でやっている。
    そもそも decode の結果を整数の列にする時点で遅い。

    bracketed paste だと分かった時点で、
    stdin から文字列として読み取って、
    文字列としてそのまま挿入する等の事が可能な筈なのではないか。
    そうすれば無駄な処理をする事なく即座にエディタを起動できる。

    現在の nonblocking-read の実装に
    bracketed paste を検出する機能をつけて
    bracketed paste の処理中にはそれを使って
    良い感じに実行すれば良いのだろうか。

2020-03-11

  * __line_limit__ の実装の制限

    1 replace-limited を直接呼び出している箇所については確認したが、
      replace-limited が .replace-range を通して呼び出している時、
      外側で ind, mark を設定していると計算がずれて範囲外になる可能性がある。
      特に vi で .replace-range を多用しているが面倒なので細かくチェックしていない。

    2 容量超過でもコマンドラインが短縮されていない場合
      (これは isearch の途中などで起こりうる)
      複数のキーから為るキーシーケンスが間に入る __line_limit__
      によって無効化される。

      これの対処方法として mouse_move と同様に特別に
      __line_limit__ を keyseq に属さないキーとして取り扱う方法がある。
      然し、現在ではチェックが非効率になるので対応していない。
      或いは keyseq に属さない keycode の範囲を定義して、
      その範囲で判定できる様にするのが良い気がする。
      (その様なキーは実は沢山ある)

  * history: fish の autosuggestions はファイルが存在しない履歴項目はスキップする (suggested by cole-h)
    https://oilshell.zulipchat.com/#narrow/stream/121540-oil-discuss/topic/autosuggestions

    うーん。どうやら fish は履歴を保存する時にその時に使った有効なパスも一緒に記録する様だ。
    Bash はそれを記録しない。という事は ble.sh が代わりに記録する等の工夫をする必要がある。
    然し、ble.sh が代わりに記録するという事になると履歴の一貫性を保つ為に工夫が必要になる。
    或いは、ble.sh の履歴を本体として bash の history は全部それを元に再構築する?
    その様にするしかない気がする。

    或いは cmdinfo:color の実装が完全であれば、わざわざ履歴を見て
    ファイルパスかどうかを判定しなくても、それが有効な履歴かどうかを判定する事が
    可能になる。特に cd に関しては簡単に判定する事ができる筈である。
    という事を考えるとわざわざ実装する必要はないのかもしれないとも思う。

2020-02-02

  * vi mode の時は read も vi mode になっているべきではないのか?
    と思ったが vi mode にはコマンド実行等の色々と
    危ない機能も沢山ついているので、寧ろ cmap を使うべきで、
    然し、cmap を使うのだとしたらそれは殆ど現状の read の様な物だ。

    これはその内に request があるかもしれない。その時に対応する。

    と思ったが既定の readline では vi-map が使える様になっている。
    コマンド実行等はどの keymap に定義されているだろうか。
    或いは accept-line や edit-and-execute-command の意味を差し替えられる様にするか。
    そちらの方が現実的である様な気がする。

2020-01-26

  * progcolor: 非同期で実行できる様にする可能性?
    場合によっては重い計算が必要になるかもしれないし、
    実は非同期で実行しても良いのではないかという事。

  * progcolor: redirect の場合にも対応したい
    実は補完の時にも redirect をプログラム補完しても良いのでは。
    但し、補完と着色で違うのは補完は一つの単語について呼び出されるのに対して、
    着色は一度に複数の単語を着色する事があるという事。
    補完に関しては引数とリダイレクトを別々に処理すれば良いが、
    着色の場合には一度に処理できる様にしたい。

  * progcolor: here document にも対応したい。
    here document に対応するコマンドを抽出する事は可能か?
    →here document は開始部分に対する参照を確か持っていたのでできる筈。

    実際にユーザは何を提供すれば良いのか。
    ble/cmdinfo/color:XXX を呼び出す様にするのか。
    然し、それだとそのコマンドの引数が変更される度に、
    対応する heredoc を抽出する必要が出てくる。それは面倒だ。
    或いは、heredoc に変更があった時に着色するだけで良いのでは。

    というか heredoc は単語ではない。でも一つの nest ではある。
    うーん。然し wrange に登録しているかは謎。
    その辺りも整理しつつ実装すると良い。

  * progcolor: コマンド自身が書き換えられた時には
    全ての引数について再度着色の確認が必要になるのではないか。

2020-01-23

  * 前々から発生していたが曖昧補完などを実行すると時々ごみが残る。
    これは何故だろうか。そもそもカーソルよりも右に何か文字列が入るはずがないのに?

    再現させようとしても再現できない。
    これは実際に起った時に再度確かめる必要があるのである。

2020-01-21

  * lmorg/murex という新しいシェルの対話環境

    https://github.com/lmorg/murex

    このシェルは POSIX 互換でないので微妙。
    パス名展開をするのに面倒な指定をしなければならない。
    既存の様々なツールと相性が良いかというと微妙な気がする。
    しかし fish や PowerShell よりは unix shell よりである。

    一方で対話インターフェイスに関しては色々工夫している。
    入力していくと一行下に現在入力しているコマンドの説明が表示される。
    何も入力していない場合は git リポジトリの情報を表示している。
    (然し、なにか入力するとすぐに消えてしまうので何処まで使いやすいかは分からない)
    kill まで入力すると補完候補としてプロセス ID を表示してくれる。
    プロセス ID に対してコマンドラインを説明として表示している。

    * 所で ble.sh ではメニューの形式は事前にユーザの側で指定する事になっている。
      然し、これは微妙な気がしてきた。というのも説明文があるかどうかの情報は
      補完生成側が知っている事である。なので、補完候補生成器の側で、
      メニューの表示形式を上書きできる様にするべきなのではないかという気がする。

2020-01-17

  * Minix で無限ループになっている?

    echo と入力しようとすると確率的に無限ループになる。
    (それでも可也高い確率で無限ループになる。)
    auto-complete を off にしても発生する。
    menu-filter を off にしても発生する。
    という事は着色か或いは。。

    調べてみると暴走しているプロセスは別の Bash だという事が分かった。
    恐らく子プロセスで暴走している。何が悪いのだろうか。履歴?
    →履歴はちゃんとロードできている。その後で暴走する。
    →再度確かめたらやはり子プロセスの暴走としか思えない。
      と思ったがよく見ると親プロセスの暴走だった。両方で起こる?

    2020-02-03 新しい ble.sh を実行しているが固まるという現象が再現しない。
    これは新しい ble.sh のお陰だろうか、それとも偶だろうか。
    →暫く使っていたが全く再現しないので以前の ble.sh の問題と思って良いだろう。

    と思っていたら実は裏でちゃんと無限ループになっていた。
    どうも ssh が予期せず切断すると無限ループになる?

    気になるのは暴走していたプロセスは stderr にリアルタイムで
    データを出力し続けていたという事。

    | -rw-r--r--  1 murase  users  14174140 Feb  3 21:58 5726.stderr
    | -rw-r--r--  1 murase  users  14324924 Feb  3 21:59 5726.stderr
    | -rw-r--r--  1 murase  users  14504088 Feb  3 22:01 5726.stderr
    |
    | 出力内容は以下の通り 0d 1b 5b 4b の 4B を繰り返し出力している。
    |   $ < $_ble_base_run/5726.stderr od -t x1
    |   0000000   0d  1b  5b  4b  0d  1b  5b  4b  0d  1b  5b  4b  0d  1b  5b  4b
    |   *
    |   67250220   0d  1b  5b  4b  0d  1b  5b  4b
    |   67250230
    |
    | 0d 1b 5b 4b とは何か? \r\e[K である。CR EL である。うーん。
    | ble.sh の該当しそうな部分を調べてみる。
    |
    | * canvas:344 (negative cup:el)
    |   ble/canvas/put-cup.draw 1 $((x0+1))
    |   ble/canvas/put.draw "$_ble_term_el"
    | * canvas:1928 (negative sgr0:cr:el)
    |   ble/canvas/panel#goto.draw "$index" "$x" "$y"
    |   ble/canvas/put.draw "$_ble_term_el"
    | * edit:1520 (negative sgr0:cr:el)
    |   ble/canvas/panel#goto.draw "$_ble_textarea_panel" "$fminx" $((fminy-new_scroll))
    |   ((new_scroll==0)) &&
    |     x=$fminx ble/textarea#render/.erase-forward-line.draw # ... を消す
    | * edit:1680 (negative sgr0:cr:el)
    |   ble/canvas/panel#goto.draw "$_ble_textarea_panel" $((cols+1)) "$y"
    |   ble/canvas/put.draw "$_ble_term_el"
    | * edit:1696 (negative sgr0:cr:el)
    |   ble/canvas/panel#goto.draw "$_ble_textarea_panel" "${pos[0]}" "${pos[1]}"
    |   ble/canvas/put.draw "$_ble_term_el"
    | * edit:3869 (negative cuf:sp:sp:el)
    |   ble/canvas/put-cuf.draw "$advance"
    |   ble/canvas/put.draw "  $_ble_term_cr$_ble_term_el"
    | * edit:7322 (negative cr:el:sgr)
    |   ble/canvas/put.draw "$_ble_term_cr$_ble_term_el${_ble_term_setaf[9]}"
    |
    | うーん。何れも関係なさそうな気がする。
    | もしかして _ble_term_el2 に CR EL が入っている?→確認したがそうでもない。
    | 上の中で一番怪しいのは panel#goto.draw だと思ったが、
    | sgr0 が消滅している理由が分からないし、
    | 一度 CR を出したら _ble_canvas_x=0 になるのだから、
    | 何度も CR を出力し続けるのは変だ。

    暴走した bash は何れも console ではなくて pty だった。
    接続が途中で落ちると無限ループになるのだろうか。
    hp2019 側及び vmminix 側で nc/sshd を kill -9 しても再現しない。

  * 英語圏のニュースサイトに投稿する可能性 (suggestion by dylankb)
    Hacker News を紹介されたがここが適切なんだろうか?

    reddit に投稿した話がある。
    https://rcmdnk.com/blog/2014/02/23/computer-bash-zsh/

    単にリンクを貼るというのでも良いけれども。
    やはり様々な機能を惜しげもなく紹介する
    長い記事を書くのが良い気がする。

    →返信で自分の作品を投稿する時のルールの頁があった。
      なるほど。やはりルールがあったのである。危ない所である。
      https://news.ycombinator.com/showhn.html

      これによると作品の紹介は一度きりしかできないとの事。
      > The community is comfortable with work that's at an early stage.
      と書かれているがまさかこれは初期の作品でなければならないという訳でもあるまい。
      > Blog posts, sign-up pages, and other reading material can't be tried out
      と書かれているが…。使い方の説明記事の様でも駄目なのだろうか。
      Blog posts でなければ良い? 或いは README を派手に改造してしまうという手もある。

    https://news.ycombinator.com/shownew
    ここを観察していると "Show HN: 作品名 ― 説明" という名前の物が多いが、
    実は "Show HN: 今〇〇なのを作っているんだけど" というタイトルの物の方が upvote が多い。
    "作品名 - 説明" だといかにも宣伝という感じで入る余地がない気がする。
    一方で "〇〇なんだけど" みたいに書くと "自分も何か貢献できるんではないか" と錯覚して人がたくさん来る。
    そういう仕組になっているんだろうという気がする。

    * reject: "Show HN: Bash Line Editor -- syntax highlighting, autosuggestions, etc. in Bash"
      これは普通。つまらない

    * "Show HN: I am developing a line editor in pure Bash script. I'd like to hear your comments!"
      これだと面白そうとは思ってくれるかもしれないけれど使ってくれる人は少なそう。
      後 explicit にコメントが欲しい! という事をタイトルに書いても良いのだろうか?
      眺めてみるとそういう投稿はない。やはり雰囲気が分からないのである。

    * reject: "Show HN: I made syntax highlighting, autosuggestions, etc. in Bash"
      これも普通。つまらない

    * "Show HN: "Bash Line Editor" with syntax highlighting, autosuggestions, ... written in pure Bash!"
      やはり宣伝っぽい。

    * "Show HN: Bash Line Editor -- syntax-highlighting, autosuggestions and vim emulation written in pure Bash"
      vim と書くと他のエディタを使っている人やシェルでは別に vim は使わないという人が敬遠してしまわないか?
      然し話題に乗るという事だけであればその辺りを無視して投稿しても良い気がする。

    * reject: "Show HN: I wrote a line editor (syntax highlighting, autosuggestions, vim amulation, etc.) in pure Bash script"
    * reject: "Show HN: I wrote a line editor in pure Bash script which provides syntax highlighting, autosuggestions, vim emulation, etc. to Bash"
    * reject: "Show HN: Bash Line Editor written in pure Bash script for syntax highlighting, autosuggestions, vim emulation..."
      長い
    * "Show HN: Bash Line Editor totally written in pure Bash script"
      案外これぐらいの方が気を引けるのかもしれないと思う。
    * "Show HN: Bash Line Editor -- a next-generation Bash configuration"
      或いはこんな感じに煽った感じのタイトルにしても良い。zplug の真似
      でも技術的に面白いのは pure Bash script であるという事。

      "with syntax highlighting, autosuggestions, vim emulation" 等は書かなくてよい。
      書かない方が煽りになるのである。本当か? と思ってみんなリンクを開く。
      そしてどんな機能があるのかとみんな確認する。
      少なくともこれだけの物があるのだからがっかりする事はないだろう。

      でも落ち着かなければならない。Bash configuration と書くと、
      従来の PS1 や aliases や functions を包含する物と考えられてしまう。
      その様に考えると、Bash plugin と書いた方が良いか?
      或いは、plugin manager として突貫で他の物を取り込める様にするか、
      或いは README に強調しておくことにするか。

      というか Bash configuration というのが良くない。違う。
      もっと土台になるものなのである。
      実のところ "a next-generation Bash Line Editor" なのだ。
      然し line editor という意味では全然 next-generation ではない。普通だ。
      つまり Bash の設定にしては next-generation なのであって、
      line editor として next-generation な訳ではない。

      a next-generation Bash interface/infrastructure/extension/framework

      Framework としての側面も強調してよいのかもしれない。
      (或いは真面目にライブラリとして独立させても良い。
      decode 部分に関しては大幅に手を入れる必要があるかもしれない?)

    * "Show HN: I wrote a featureful line editor in pure Bash scripts"
      みたいな単純な物の方が気を引けるのではないかという気がする。

    調べるとスタートアップという文字が頻りに見える。
    投稿してみた感想を観察してみるとやはり何かのお誘いがある様である。
    タイトルに文字数制限は在るのだろうか。

    何れにしても今は忙しいので沢山の要望などが来てしまっては困る。
    従って暫くはこのまま放置するというので良い気がする。

2020-01-05

  * Homebrew の設定を作成する?

    先ず Linuxbrew (Homebrew for Linux) を ~/opt/linuxbrew に入れた。
    普通と違う場所に入れようとしたので色々問題が起こって時間を食ってしまった。

    * brew tap について調べてみる事にする。

      % brew tap akinomyoga/ble.sh を実行すると https でダウンロードしようとする。
      % brew tap akinomyoga/ble.sh git@github.com:akinomyoga/ble.sh.git とすれば良い様だ。
      % それから brew install を試そうとするがどうやっても動かない。
      % どれをやってもそんな formula は見つかりませんのエラーになってしまう。
      % もしくは tap を確認すらしない場合もある。不思議だ。
      % $ brew install akinomyoga/ble.sh
      % $ brew install akinomyogable.sh
      % $ brew install akinomyoga/homebrew-ble.sh
      % $ brew install homebrew-ble.sh
      % $ brew install brew-ble.sh
      %
      % $ brew tap
      % を実行してみると。自分が登録した物の他に homebrew/core がある。
      % homebrew/core は中に formula を沢山入れた repo の筈である。
      % もしやと思って調べてみる。
      %
      % https://qiita.com/wkentaro/items/d4981582e08b134f1e1d

      どうも user/name に対応して github.com:user/homebrew-name を作成して、
      その中に formula.rb を入れて置くという事になっている様だ。
      面倒なのでそれよりは直接 core に取り入れてもらった方が楽だ。

    * 自分で formula を作ってみるのを試す

      仕方がないので自分で formula を作ってみるのを試す事にした。
      $ brew create --set-name blesh

      全て自分で記入しなければならない様だ。適当に formula を作成してみる。
      sha256 は何の sha256 を記入すれば良いのか分からないのでコメントアウトする。
      結局分からないので以下を参考にして埋めてみる事にする。
      https://github.com/10sr/homebrew-pkg/blob/813de30c121e8dea970f11e7c1e63e57d3a6a0ed/Formula/ble-sh.rb_
      * ビルドは gawk に依存しているので gawk に依存させてみる。
      * gmake については調べてみた所 macOS ではデフォルトで GNU make だそうなので不要?
        然し、mac ではデフォルトで make が入っているのだろうか。
        或いは自分で追加で入れる必要があったりするのだろうか。よく分からない。

      と思ったが何処にも *.rb が作られていない。
      $ find ~/opt/linuxbrew/ | grep blesh
      で調べてみたら ~/opt/linuxbrew/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/blesh.rb
      に新しく blesh.rb が作成されていた。これを使う事にする。
      試しに $ brew install blesh としてみたら動き出した。
      gawk を入れるためにその依存関係まで全てダウンロードしてインストールしようとしている。

    ? brew では自分で何処かで入手した formula を使うにはどうすればよいのか?

    * homebrew-core に登録する為には test を用意しなければならないようだ。

2019-12-31

  * progcolor: 引数の中の着色 (zsh -c '...' の ... の部分)。

    いつか実装しようと思っていたら fast-syntax-highlighting が既に実装している。

    | fast-syntax-highlighting
    | →引数の中も着色すると思ったら '$(...)' の中も着色を行っている。
    | 然し、zsh -c '...' に関してはちゃんと zsh や -c を認識して着色している様だ。
    | 調べてみると awk もちゃんと文法的なチェックを行っている。
    | (→ うーん gawk --source '...' で文法チェックをできる様だ。)
    | sed に関しては行っていない。何れにしてもコマンド毎の着色を実現している。

    * コマンド毎の着色設定を指定できる様にした #D1245

    | 次に例えば awk に対応する事を考える?
    | 或いはそれよりは sh もしくは bash に対応する方が楽?
    | 色々考えてみたがちゃんと対応するのは可也大変である。
    | 先ず単語が単純単語でない場合にどの様に実装するか。
    | 等、色々難しい。既にある文法構造を利用して何とかできる可能性はある。
    |
    | awk に対応するとしても awk の様々な実装によってオプションなど異なる。
    | このオプションが異なっていると異なった着色になって、
    | ユーザに混乱を齎す。従って対応するとしたら完全に対応している時にだけ有効にする。
    | 何れにしても面倒である。awk よりは先に bash で対応した方が懸命ではないか。
    | awk の対応に関しては自分の blerc の中だけに留めておく。
    | その自分の blerc の中での awk の着色の設定で必要になると
    | 思われる補助機能をble.sh の方で実装する。

    * awk の着色対応を通じて ble.sh 側で支援の必要な機能を実装する。

    * 単純単語に関して。評価値を求める方法。
      評価値の各文字が元の単純単語のどの位置に対応するか。
      或いはその逆? どちらの方が適切だろうか。

      例えば引用符等に関しては対応する文字はないのでそのままの色が良い。
      従って評価後の文字に対応する評価前の範囲を取得すると良い気がする。
      然し、逆に評価前の $a が評価後に沢山の文字列になる事もある。
      その場合には評価後の各文字の色を評価前に割り当てるのは難しい気がする。

    * 対応する物がない文字をそのままの (下の層の) 色にする事は可能だろうか。
      恐らく getg 等で取得しなければならない。面倒である。
      或いは ble/highlight/layer:syntax では少し違う様に処理していた気もする。

    * 複雑な単語に関しては文法構造を利用する事も考える。

    * 現在の layer:syntax の枠組みでは一旦着色情報を wattr に格納してから、
      それを word table に対して適用するという仕組みにしている。
      この様にする事に何の意味があったのだったか?

      直接 word table に適用した方が早いのではないか?
      →これは何度も単語着色を求め直すのを省略する為である。
      つまり、単語着色を決定する部分と実際に適用する部分を分けて、
      前者をできるだけ省略する様にしている。

      実際に適用する必要がある場合でも前回求めた値を
      そのまま使えば良い場合があるという事なのである。

  * fast-syntax-highlighting の機能を確認する
    https://github.com/zdharma/fast-syntax-highlighting

    * コマンド毎の着色。オプションや引数が正しいかのチェックも行う。
      これは丁度 ble.sh で将来的に対応したいと思っている機能である。
    * 括弧の対応に応じた着色
    * gawk --source による文法チェック?

  * theme: 流石に theme を作った方が良い気がしてきた。
    少なくとも枠組みだけでも作って置くと良い気がする。
    と思ったが実際に例がないと枠組みの良い設計も分からない。
    zsh-syntax-highlighting はどうしているのだろうか。
    zsh-syntax-highlighting theme で検索してみる。

    どうも zsh-syntax-highlighting は theme を提供していない様だ。
    https://highlightjs.org/static/demo/
    ここは dark/light の両方を提供している theme があって参考になる。
    但し、ファイル名着色に使う色は色々調整しなければならないが。。

    fish の theme はあるだろうかと思って探すと。
    https://github.com/oh-my-fish/oh-my-fish/blob/master/docs/Themes.md
    どうもシェル業界では theme というのはプロンプトの事を指す様で。
    然し、fish のブラウザ設定画面ではタブは colors となっている物の、
    色々な設定の部分には theme という文字も見える。
    何れにしても theme というのは紛らわしいかもしれない。
    注意書きを書いておく必要があるかもしれない。

  * tui: TUI 設定画面?
    fish はユーザフレンドリーを謳っている。
    ブラウザで設定できるなど (リモートの場合には使えない気がするが)。
    ble.sh ではブラウザでなくても TUI で設定画面を用意しても良いのかもしれない。
    マウスサポートまですればブラウザでなくてもOKなのである。

    →fish の web 設定画面を確認してみた。
      実は theme と prompt が選べるだけだった。
      他は関数・変数・履歴・束縛・略語展開の一覧が見えるだけで、
      何も設定することはできないのだった。
      但し履歴項目の削除はする事ができる。
      略語展開も実は編集することができた。
    →theme に関しては配色が選べるだけで、
      具体的にどの色がどの意味というのは余り考えられていない気がする。
      適当に順番に割り当てただけなのではなかろうか?

    その様に考えると履歴の着色でも良いのかもしれない等と。

  * complete: 重い補完関数に対する対策

    * 曖昧補完の為に何度も progcomp を呼び出していて非効率的
      →無駄があると思ったが実際にどういう補完を行っているか調べると
      様々な補完点を試しているのだった。うーん。
      自動補完の補完候補がすぐに見つかる場合にはそんなにたくさん呼び出されない。
      補完交互が見つからない時には自動補完によって何度も補完が実行されて遅くなる。

      もしかすると自動補完を off にしたいという人は時間のかかる
      補完関数を使っているという事なのかもしれない。
      よく考えたら peco の類を設定している場合大変に面倒な事になるのでは?
      自動補完が実行される度に選択メニューが表示されてしまう。
      そもそも補完に peco を設定している時点で変ではあるが。

      色々な補完点で試すとしても現在の単語を 0 文字または 1 文字しか
      入力していない場合には、同じ状態で呼び出す事もあるだろうという気がする。
      その場合の為に compgen の呼び出し結果をキャッシュする利点はあるだろうか。
      つまり、同じ補完状態で再度呼び出される事を見込めるかどうかが問題になる。

    * 或いは、処理を非同期で呼び出すというのが良いのかもしれない。
      その場合には計算結果を何処かファイルに書き出す様にしなければならない。

      非同期で呼び出すのは -CF が設定されているときだけで良い。
      と思ったが -F の中で環境を変更したいという場合にはどうするのだろう。
      非同期で呼び出すという事にすると環境に対する変更が適用されない。
      これは bleopt で変更できる様にしても良いのではないだろうか。

  * complete: menu-complete 中の通常文字挿入は
    絞り込みに戻すのが良いのではないか。
    というか普通にキャンセルして挿入すれば絞り込みになるのでは?
    と思ったが menu-complete 状態からは抜ける事になる。

    後、suffix を挿入せずに確定する方法がなくなる。
    これについては別の操作方法について考えると良さそう。
    例えばスペースを押すと suffix 挿入を抑制して確定する等。

    →やはりこれは分かりにくいのではないか。
      fish, zsh の動作を確認してみたが menu-complete 中に
      新しい文字を入力すると何れも現在の選択肢を確定させた後に
      続きの文字が入力される様になっている。
      これらのシェルと異なる振る舞いをするのは良くない。

      だとすると絞り込みをする為には明示的に
      絞り込みのモードに入るキーを設定するべきなのでは。
      例えば M-e 等?

      因みに emacs で試してみると M-e, M-a は end/beginning of
      sentence 的な動作をしている様に見える。
      なので上書きしてしまっても良い様な気がする。
      うーん。でも end of line の代わりに使っている人がいるだろうか?

      因みに現在の ble.sh では M-e は何にも紐付いていない。
      うーん。M-e を勝手に補完の絞り込みモードに割り当てる事にする。
      絞り込みモードにいる時にはカーソルの動く範囲と編集範囲を制限する。
      と思ったが vi の様な複雑なモードの場合にそれを実現することは可能か?
      移動だけならば __after_widget__ で範囲外に出た時に
      強制的に範囲内に移動させる事が可能であるが、編集まで入ると困難である。
      編集を禁止しなければならないがそれは難しい。

      だとすると新しいプロンプトで編集させるというのが現実的だろうか。

2019-12-29

  * color: term_true_colors=auto

    自動判定は難しい。screen-4.99.0 が truecolor on/off
    のオプションを持っているので実際にユーザが有効にしているかどうかは
    TERM や DA2 を使っても分からない。結局試しに色を設定して、
    その色を読み出すという事をしなければ判定できないのだろうか。
    然し、これも端末によって問い合わせができたりできなかったり
    (セキュリティ上の都合から)無効になっていたりする気がする。

    以下の優先順位で試すというのが妥当な実装方法の気がする。
    然し 1 の判定を非同期に行わなければならないので面倒である。

    1. 色を設定して問い合わせる

      http://nanno.dip.jp/softlib/man/rlogin/ctrlcode.html
      https://qiita.com/kefir_/items/c2bd46728364bdc7470b
      OSC 10 ; ? ST で前景色RGB問い合わせ、
      OSC 11 ; ? ST で背景色RGB問い合わせの様である。
      応答は OSC 10 ; "rgb:rrrr/gggg/bbbb" ST の形式?

      よく考えたら現在の実装では ESC-[ (CSI) しか特別扱いしていない。
      これに対応する為には "ESC ]" (OSC) についても処理する必要がある。
      これは ble-decode-char/csi/consume の辺りを拡張する必要がある。
      特に BEL または ST (ESC \) で終端する様に処理を書く事に注意する。

    2. DA2 を元に判断する
      然し https://gist.github.com/XVilka/8346728 のページには
      各ターミナルの対応 version が書かれていないので使えない。
      自分で調べ上げるしかないのだろうか。

    3. TERM を元に判断する (*-24bit *-24bits *-truecolor)
    4. terminfo を元に判断する (setf24, setb24, tc, RGB)

2019-10-21

  * ずっと起動していると段々と遅くなっていくのは何故か。

    Ubuntu bash-4.3 (song437) で動かしていて気づいた。
    bash として新しく起動すると速い。
    ble-update や ble-reload をしたり、
    ble-detach / ble-attach しても直らない。

    カーソル移動だけでも遅くなって行くので描画が関係しているとは思われない。
    また、reload しても直らないという事から考えられる事は何か。
    履歴がどんどん溜まって重くなるという事でもない様な気がする。

    或いは変数のアクセスが遅くなって行くという事なのだろうか。
    変数に代入するスクリプトを回してみたが特に遅いという事はない様だ。
    (それにそもそも使用している時間に比例して変数が増えていくという物でもない)

2019-09-24

  * ble.sh で export PATH=aaa:bbb:ccc で最後の部分しか着色されない。
    それぞれ着色するべきなのではないか。

2019-09-22

  * complete: = を含むファイル名を補完すると = 以前の部分が重複して挿入されてしまう。

    →今確かめてみると再現しない。\= としていても = としていても同じ。

    2019-12-31 ./configure の引数で --prefix= を補完している時に
    = が \= になったり --prefix= も丸ごと置換されたりなど変な動作をする。
    一方で、complete -r で progcomp を消してやると変な事は起こらない。
    これは要するに progcomp の仕様の微妙な違いに起因して変な事が起こっている。

2019-07-16

  * complete: パス名展開で複数語に展開される場合の補完に関して
    現在の実装ではパス名展開が起こったとしても展開された最初のファイル名を使って補完を実行する。
    然し、実際には展開された各パス名について補完を実施しても良いのではないだろうか。うーん。

    更に failglob の場合には続きを入力したら一致したかもしれなくても常に展開に失敗してしまう。
    というか現状でそもそも failglob だった時にそれを検出しているのかどうかすら怪しい。
    確認する必要があるのである。

    既に COMPV には複数の値が入る仕組みになっていた。
    それならばと COMPV に入っている値の数だけ source を呼び出せば良いのかと考えたが、
    実際に試してみると全く同じ候補が何度も生成されるだけに終わってしまった。
    よく考えたら progcomp では独自に展開を行っていたのではあるまいか。
    調べてみたらやはりそうである…。これに対応するのは面倒である。

    或いは複数語に展開される場合には先ず始めにその内のどれか一つに絞らせるという可能性もある?
    然しそれはそれで不便な気もする。

2019-07-09

  * history.mlfix: bash-3.0 で実現する方法?
    history -s が使えないので複数行の履歴を登録する事が不可能である。

2019-07-02

  * menu: 複数選択を可能にしても良いのではないか
    C-@ で toggle をする等。抜ける時に全てを挿入する?
    然し使いみちがよく分からない。使いたくなったら追加するというので良い気がする。

2019-06-18

  * history: interactive な history 編集に対応できたらする
    つまりメニューを表示して其処で選択したり削除したりする。
    検索などもできる様にする。遅延で着色をする。

    core-complete に実装されている既存のメニューの枠組みは、
    menu item を配列に格納する。従って容量を食う。
    更に重そうである。これは独自に新しく実装した方が良いだろうか。

2019-05-27

  * 次に機能を追加するとしたらマウスなのだろうという気がする。
    fish は未だマウスに対応していない。
    zsh はそういう拡張があるらしいがちゃんと動くのかは知らない。

    zsh extension: https://unix.stackexchange.com/questions/444601/any-terminal-shell-with-mouse-support
    fish suggestion: https://github.com/fish-shell/fish-shell/issues/4918
    question: https://superuser.com/questions/322367/are-there-any-unix-shells-that-support-mouse-reporting

    マウス対応の問題点はマウスが有効になっていると、
    従来の端末に対するマウス操作(端末に表示されている内容のコピー・ペーストなど)が使えなくなる事である。
    端末に表示されている内容まで全て ble.sh の管理下であればそういう事もできたかもしれない。

    部分的なサポートとして何らかのモードに入っている時だけマウスを有効にするというのはあるかもしれない。
    例えば補完のメニューを出している間だけ、など。然し、それもなかなか分かりにくい気はする。
    或る特定の範囲だけでマウスを有効にするという制御機能があった様な気がする。
    それが使えればそれを使ってマウスを有効にするというのが可能になる気がする。
    何れにしてもこれは考察が必要になるのである。

    2019-07-22 どうも既存の端末では Shift を押しながら操作すると
    Mouse report ではなくてローカルでの端末上でのマウス操作になる、
    というのを採用している物が多い、という話を何処かで見かけた。
    何処で見掛けたかは忘れたし実際にそうなのかの確認はしていないが。

2019-04-21

  * 実は背景色を判定する方法はなくはない様だ。
    https://qiita.com/kefir_/items/c2bd46728364bdc7470b
    しかしそうだからと言って暗い背景用に配色を調整する必要があるので、
    それを実行するまでは対応しても仕方がないかもしれない。

    % というか、調べていたら DECSCNM (SM/RM(?5)) が背景が暗いか明るいかの設定の様だ。
    % という事は DECRQM して DECRPM を受け取れば普通に背景が明るいか暗いか分かるのでは。
    % そして Poderosa や screen の側でもそれを設定すれば良かったのではないか…。
    % と思ったが xterm は明るいか暗いかが反転している。
    % つまり、DECSCNM は飽くまでその端末の既定の背景と比べて反転しているかどうかしか分からない。
    % 既定の背景色が明るいか暗いのかの情報は取る事ができない。

    一方で、背景色の問い合わせで返ってくる色が DECSCNM の影響を受けるのか
    は気にして置かなければならない。

2019-03-23

  * menu: alias select='while myselect $# "$@"' 等として select を上書きできるのでは

    というか現在の ble.sh で select を実行すると悲惨な事になる気がする…。
    と思ったが select は別に readline は使っていない様子だ。
    元の bash でも全然行編集できない感じの入力になっている。
    なので現状で問題が発生しているという訳でもない。

    もし置き換える事ができるのであれば便利かもしれないという程度である。

  * menu: 今後の拡張性

    * 因みにフィルタリング機能は menu-filter を統合・整理する形で実装したい。
      フィルタリング文字列の入力に関しては isearch や iswitchb の様な、
      単に文字を入力するか BS で戻るかだけしかできない様なものでも良い事にする。

      フィルタリングに関してはフィルタリングを実行する関数と、
      フィルタリングを誘発する為の機能を分離して実装する事にする。
      既存の menu-filter の機能は自動的にフィルタリングを呼び出す。
      明示的なフィルタリングの場合には keymap にフィルタリングを紐付ける。

    * cdhist では更にリスト編集機能までついている。
      つまり項目を並び替えたり削除したりと言った事ができる。

      うーん。これをどの様に返すかは微妙かもしれないが、
      _ble_complete_menu_items にある物を呼び出し元で参照してもらうというので良い気がする。
      或いは callback でどの様に並び替えたかを返すという手もあるが分かりにくいだろうか。
      両方という事で良い気がする。使う側で便利そうな方を選んでもらう。
      どの様に並び替えたかの操作が欲しければ callback を使うし、
      最終的な結果だけ欲しければ _ble_complete_menu_items を参照してもらう事にする。

    * callback という事で思ったが、実は accept だとか cancel だとかも
      全て menu_class 経由で定義した方が良いのではないだろうか。
      一つずつ全て callback を変数に設定していくのは面倒である。
      更に、並び替えの callback だとかどんどん増やしていくと際限がない。

2019-03-22

  * menu-filter の使い心地が微妙なのはもしかして
    menu-complete を実行中に絞り込みができないからなのではないか。
    現在は menu-complete を実行している途中に入力をするとその場で確定してしまう。

    では bash の振る舞いはどうなっているだろうか。
    確認してみた所、bash の menu-complete はもうその場所に挿入してしまう。
    そして文字を入力すれば続きに挿入される事になる。

    現在の ble.sh の振る舞いはどうだろうか。
    その場で入力すると addtail 等の処理をせずにいきなり続きから入力されてしまう。
    少なくとも addtail ぐらいはするべきなのではないか。
    また、絞り込みを実行しても良いのではないかという気もする。
    然し、それでも何か違う様な気がする。

    絞り込みの入力欄と現在選択されている内容というのは別に一致している必要はない。

2019-03-19

  * complete: 実装されていない補完関連の rlvar は以下の通りである。
    実際に対応するかどうかも含めて考察する必要がある。

    - set completion-map-case off
    - set disable-completion off
    - set expand-tilde off
    - set horizontal-scroll-mode off
    - set page-completions on
    - set completion-display-width -1
    - set completion-prefix-display-length 0
    - set completion-query-items 100

    うーん。これらの設定は bash の既定値では余り便利ではなかったりする。
    ble.sh で折角実装してもユーザに使ってもらえないのでは仕方がない。
    それならば最初から ble.sh の bleopt として提供してしまった方が良いのでは。
    元々 bash を普通に使っていて設定している人の為に、
    bash の規定値と異なる値を敢えて選択している時に限り
    ble.sh でその効果を再現する様にすれば良い。

2019-02-09

  * main: --attach=prompt の問題は何だったか
    ref #D0940

    何か問題があって現在はこれを使っていないが、それは何だったろうか。
    何処かに記録されていて良い筈なのに何処にも記述がない。
    対応した時の記録は #D0737 にある。
    動かしてみた所、ちゃんと動いている様に見える。

    →恐らく、先ず古い ble.sh の version では使えないという事。
      それから PROMPT_COMMAND を上書きすると使えなくなってしまうからという事。
      ユーザに PROMPT_COMMAND を設定しないように要求するのは面倒である。

2018-09-21

  * [保留] 2018-09-15 complete: 文脈の変更範囲で end0 だけ負になるバグ (ref `#D0818`)
  * [保留] 2018-09-11 complete: 端末が操作を受け付けなくなるバグ (ref `#D0817`)

2018-08-16

  * complete: オーバーレイによる実装?

    現在の実装では仮挿入しているが、
    これによって現在の入力内容でエラー着色するべき所が、
    補完が実行された後の着色になってしまっていて、
    補完前の現状でエラーなのかどうなのかが判別できなくなっている。

    やはり仮挿入ではなくて overlay で実装するべきなのではないか。
    しかし overlay の仕組みを実装するのは面倒である。
    どの様な仕様にするのが良いのかの吟味から実装まで。
    しかし、これについては後回しで良いだろう。

    以下に仮入力の4種類の方法について言及がある。
    https://mattn.kaoriya.net/software/vim/20170905113330.htm

    リンク先は消えている。web archive のリンクを追記 (2018-09-23)。
    https://web.archive.org/web/20110630165743/https://www.mozilla-japan.org/projects/intl/input-method-spec.html

    * 2018-09-23 自動補完時の着色について
      cmplstofB さんからも指摘があった。
      https://github.com/akinomyoga/ble.sh/issues/5

      自動補完の候補文字列は実際に挿入しているので構文着色に影響を与える。
      "現在の内容" で着色するべきなのではないか、ということ。
      そうしないと例えば今入力したコマンドが実際に存在するコマンドなのかどうかが分からない。

2018-08-05

  * edit: set blink-matching-paren on に相当する機能
    対応するならカーソル移動ではなくて着色でやった方が良い。

    | 括弧の対応と region が両方走っていると分かりにくい。
    | 既に region には複数箇所を highlight する機能がある。
    | そういう意味で region を使うという手もある。
    | と思ったが、分かりにくい問題に関しては region の方を上に配置すれば良い。
    | 複数箇所を highlight する機能は実装を参考にするだけで良い。
    | 論理的には全く異なる (region は _ble_edit_mark を参照する) し、
    | それぞれ独立に on/off する事を考えれば別の highlighter にするべき。

    region の複数箇所着色の実装を参考にする可能性も考えつつ、
    region とは独立な highlighter にしたい。
    その時は region の一つ下の層に挿入したい。

    また対応する括弧はどの様に検出するのが良いだろうか。
    やはり文法構造を参照する実装にするしかない様に思われる。
    しかし、括弧の対応には色々ある。引用符の対応、
    括弧の対応、if then else などのキーワードの対応、
    ヒアドキュメントの始まりと終わりの対応である。
    それらは必ずしも記録されていないし、また、記録されているとしても
    様々な形式で記録されている。取り敢えず一番簡単な対応として
    nest に記録されている物を着色するというのが良さそうである。

    2023-03-26 https://github.com/akinomyoga/ble.sh/discussions/308

    対応する request が来た。うーん。もっと最近にも関連した考察をした気がするが、
    メモに記録があるかどうかは覚えていない。

2018-07-29

  * complete: メモ

    - 生成候補のキャッシュを行うとすれば source 内で実装するべきである #D0705

2018-07-19

  * ble-decode: 'set convert-meta on' 的な操作

    ref #D0699 (LANG=C bash で ble.sh をロードすると全く操作できない)

    ble.sh の内部環境では set convert-meta off にしているが
    (そうしてないと特殊文字の受信時に無限ループになる)、
    外部環境で set convert-meta on だった時に、
    それをエミュレートする様な動作を行っても良い。

    外部環境における set convert-meta の状態は
    変数 _ble_term_rl_convert_meta_external に記録してある。

  * 現在の `LC_CTYPE` で表現できない文字を入力した時の `self-insert` の振る舞い

    ref #D0699

    self-insert で入力するのは逆符号化したバイト列であるべきでは?

    というのも LC_CTYPE が正しくない場合でもファイルシステムのファイル名などは
    そのまま謎の文字列として取り扱われるからである。
    然し逆符号化したバイト列は文字列として正しくないかもしれない。
    逆符号化したバイト列を更に一バイトずつ現在の LC_CTYPE に変換すると意味がない。

    これは文字列を編集などしようとすると分からない事になりそうなので、
    取り敢えず現段階では \u???? を出力するという現状の振る舞いを維持する。
    後で落ち着いてから再考する事にする。

    以下の c2s 使用箇所は一貫している必要がある。

    ble/widget/self-insert 編集文字列の入力
    ble/widget/vi-command/search-char.impl/core 検索文字列の入力
    ble/widget/vi_xmap/visual-replace-char.hook 置換に使う文字の入力
    ble/lib/vim-surround.sh/get-char-from-key 囲み文字の入力 (あらゆる遅延入力)

2018-02-21

  * vi-mode: nmap (, ), {, }

    カーソルを N 文元に戻す or 先に進める。N 段落元に戻す or 先に進める。

    これは operator:d,c で "- ではなく "1 に記録するという例外の対象であるので、
    対応したらその例外のリストに登録する必要がある。

    2020-08-27
    https://www.youtube.com/watch?v=hIJh-KlQ7io
    この動画で zsh/bash の vi mode に (){} がない事を嘆いている。
    然し、"文" をどの様に定義するのか。文法的なコマンドで定義するのか、
    或いは、元の vim と同様に . の位置で判断するのか。
    シェルの機能としては . の位置で判断するのは使いようがない。
    一方で、シェル文法の . で移動する様にすると
    vim に使い慣れた人に取っては混乱の元である。

2018-02-12

  * [保留] vi-mode: operators 保留項目 [#tmp0002]

    * 領域折り畳み zf には対応しない。

    * gq の formatexpr, formatprg には未対応である。

2018-02-11

  * [保留] keymap/emacs: 連続する delete-backward-char の場合 undo の記録をまとめる可能性?

    現状では一文字ずつ記録しているので一文字ずつ undo される。
    現在の振る舞いの方が良いのか emacs と同様にまとめた方が良いかは微妙な所である。

2017-11-21

  * syntax: for^J で改行にエラーが設置されるが見えない [#T0005]

    改行のエラーは何らかの方法で見える様にするか、
    或いは、改行位置にエラーがある様な時は、
    その前の文字でエラーが発生する様にチェックを行うべき。

    Note: これは端末によっては表示されたりする。端末による。
    エラー着色はどの様に行われているのか。for の後には FARGX1 に入る。

    これは ble-syntax:bash/ctx-command/.check-delimiter-or-redirect の冒頭部分が怪しい。
    と思ったが FARGX1 に関してはチェックが入っていないのでやはり関係ないだろうか。
    うーん。調べるとやはり文法レベルでの着色になっている。

    2019-03-11

    | rps1 で表示している時に EL を空白で代替していると、
    | 改行の着色が空白に反映される。これでも良いような気がしてきた。
    | 然し、右側が全て着色されるというのもうるさい。
    | 最初の1文字だけ着色して SGR(0) するかと思ったが、
    | そうするとその次にある文字の着色も消えてしまう。
    |
    | それの対策のために _ble_textmap_ichg があるのでは。
    | と思ったが、実装を見てみると違っている様に見える。
    | _ble_textmap_ichg は着色の調整に使っている事は確かだが、
    | _ble_textmap_ichg に登録されている文字の着色を計算しているのであって、
    | _ble_textmap_ichg に登録されている文字の次の文字の着色は計算していない様に見える。
    | うーん。_ble_textmap_ichg は他の箇所では全く使っていない。
    |
    | そうだ。思い出した…。_ble_textmap_ichg に登録されている文字は、
    | 配置の場所によって中身が変わるので、shift が使えないという事だった。
    | 特に、中身が変化している場合には文字を取り出して変更を行うのだった。
    | では以前 ichg に登録されていて、現在位置では ichg に登録されていない文字はどうなるのか。
    | と思ったら既定の文字形は別の所で決定されている様だ。
    | ble/highlight/layer:plain/update/.getch である。

    a 右側の1文字だけ着色される様にする?

      x 問題点はコピーペーストした時に必ず余分な空白が入る事である。
        これは右側の全てを着色させる場合にも同様の問題が生じる。

        また、エラーが有る時にだけ (着色の必要がある時にだけ)
        右側に空白を入れるという方法もある。
        しかし、その為にはその位置にエラーが有るのかないのかを
        外部から取得しなければならない。

        ble/textmap#update は edit.sh だとかの仕組みに依存しない、
        独立した枠組みにしたいので余り変な機能は取り付けたくない。

      x また実装上の問題点として、rps1 が表示されている時に、
        _ble_term_ech を使わない場合、2文字目以降の空白文字を SGR(0)
        でクリアしなければならない事である。この場合、
        改行の次の文字の SGR を復元する為には…

        _ble_textmap_ichg に次の文字の番号も追加するか、
        或いは現在の改行文字の SGR 状態を復元する必要がある。
        しかし textmap の処理をしている間は、
        未だ着色が完了していないので SGR 状態を取得できない。

        或いは着色部分だけ textmap#update よりも前に持ってきても良いのだが、
        その様にしたとしても色情報を textmap#update に伝達する手法が必要である。
        例えば getg なる関数を textmap#update から呼び出してもらう事にするのか。
        或いは呼び出す関数名も外から指定できる様にするのか。

    b やはり改行の前の1文字を描画時に強制的に着色するという手もあるのではないか。
      と思ったが…エラー着色だけ特別扱いするというのも変な話である。

    c その様に考えると初めから改行にはエラー着色はしないというのが正しい気がする。

      改めて調べると ble/syntax:bash/ctx-command-compound-expect がエラーを設置している。
      うーん。for だけの問題では無い様である。他に select, case の時にも同様である。

      ('for'|'select'|'case')
        [[ ${text:i:1} == $'\n' ]] &&
          ((_ble_syntax_attr[i-1]=ATTR_ERR))
        case $word_expanded in
        ('for')    ((ctx=CTX_FARGX1)) ;;
        ('select') ((ctx=CTX_SARGX1)) ;;
        ('case')   ((ctx=CTX_CARGX1)) ;;
        esac
        processed=begin ;;

      実際に上記の様にして見たら見える様になった。
      しかし rps1 が有効になっている時はやはりうるさく感じられる。
      また端末に依っては rps1 が無効になっていても行全体が赤く着色される。
      そういう端末 (mintty など) どういう発想なのかはよく分からないが…。

      更に here documents も行末にエラーを設置する。
      これについても対策したいが、here documents に関しては、
      nest の終端がない事によるエラー着色である。
      これは nest の範囲を変更しないと着色を変更できない。

      何だか中途半端な実装の気がしてきたので取り敢えずこの変更はなかった事にする。

    d うーん。右側の内容の消去は実は改行文字を使って行うのではなくて、
      描画した後に消去するという方法にした方が良いのだろうか。
      しかし、その様にすると、今度は urange の中にある行末というのを列挙して、
      それから各行末について位置を計算して実行するという事をしなければならない。
      textmap さえあれば指定範囲内の行末は二分法によって特定する事が可能である。
      しかし面倒である事に変わりはない。もっとまともな方法はないのだろうか。

    結局実装の面倒さを考えなければ三種類の仕様が考えられる。

    a 右側に1文字赤く表示する
    b 行末まで赤く表示する
    c 行の最後の文字を赤くする
    d 表示されなくても気にしない

2017-11-09

  * complete: 候補の優先順位? 例えば拡張子でフィルタすると絞りすぎることがある。
    拡張子の要件を満たすものを先に表示して、満たさないものを後に表示する。
    満たさないものに関してはサブ候補として、TAB による接頭辞挿入には寄与しない。

    2018-07-28 候補間の優先順位をつける可能性。
    weak な優先順位は、候補を表示する時の順序。
    strong な優先順位は、候補絞り込みの際に一番優先順位の高いものが一つしかない場合にはそれに確定する。

2017-11-05

  * vi-mode

    :help 関連の気になること:

    - v_p v_P: Implementation details に書かれている処理の順序は実際は逆
    - exclusive-linewise: ここの inclusive/linewise になる条件の記述は曖昧だし全く合っていない
    - star: vim-jp の文書だと WORD と書いてあるが、振る舞いは word (しかも \<\> で囲まれる) に近い

    振る舞いで気になること

    - i<C-o><C-c> とすると普通のノーマルモードに移行したように見えるのに、
      モード表示は -- (挿入) -- のままである。これは何故だろう。
      ble.sh ではノーマルモードに完全に移行する。

    - qa<C-c>q とすると ^C が二重に記録される。これは何か?
      ble.sh では単に ^C は入力された通りに一個だけ記録する。

    - C-v <bracketed paste> では矩形挿入にするべきなのではないか。
      ble.sh では矩形挿入を行う。


2017-11-03

  * vi-mode (registers): 各種特殊レジスタの対応

    http://vim-jp.org/vimdoc-ja/change.html#registers

    - done: "% は現在のファイル名を保持するが、これは $HISTFILE の内容を返す事にした。

    - done: ": は一番最後のコマンドラインの内容である。
    コマンドラインを入力し途中でキャンセルした場合などには記録されない。
    空のコマンドラインで確定した時にも記録されない。
    コマンドが入力された場合は、それが存在しないコマンドであっても記録される。
    コマンドが実行されている途中では未だ設定されていない。
    つまり、そのコマンドが実行された後で値が設定される。

    - ". は挿入モードで挿入された文字列を保持する。挿入モードから抜ける時に記録すればよいだろうか。
    と思ったが説明をよく読んでみるとそういう振る舞いという訳でもなさそうだ。
    よく分からないので実際に動かして試してみる必要がある。

    - "# は代替ファイル (副ファイル) の名前だそうだが何か良くわからない。
    C-^ の動作と関係しているそうだ。これは未だ実装しない。

    - "= これは複雑だ
    - "* "+ "~ これは GUI で選択した範囲を表すものだそうだ。

2017-10-31

  * [保留] vi-mode (_ble_keymap_vi_REX_WORD): Unicode categories?

    Bash の正規表現 (<regex.h> ERE) で対応するのは難しい。
    また必ずしも Unicode (UTF-8) で実行されるとは限らない。
    現在は UTF-8 しか対応していないが枠組みとしては
    別の文字コードにも対応できる余地は残して置きたい。

2017-10-12

  * vi-mode まだ対応していない・考えていないコマンドを列挙する

    意外とそんなに残っていないようなので。

    * nmap: C-^ '括弧 `括弧
      C-t C-] M Q ZZ ZQ do dp { }
      [{char} ]{char} z{char} C-w{char}
      g<C-a> g<C-g> g<C-h> g<C-]> g# g* g$ g&
      g` g' g+ g, g- g8 g; g< gD gH gN gP gQ gT gV
      g] ga gd gf gF gh gn gp gq gs gt gw gx g@

  * [保留] vi-mode: xmap <C-]>

    % <C-]> なる物は今見ても存在しない。vivis https://qiita.com/b4b4r07/items/8db0257d2e6f6b19ecb9
    % 辺りに在ったものかとも思ったが、ない。zsh-vimode-visual を見てもない。
    % vim で C-] としてもベルが鳴る。何かの間違いで C-[ を C-] と書いてしまっただけなのかもしれない。
    % と思って改めて vimindex を見ていたら実はあった。

    C-] で "選択した文字のタグ" へジャンプと書かれている。
    タグとは何だろうと思ったら http://vim-jp.org/vimdoc-ja/tagsrch.html に説明がある。
    ctags のタグと同じものと思って良さそうだ。因みに :help ... で表示されるのもタグの様だ。
    またノーマルモードの C-] はカーソル位置の単語を ":ta" で検索と書かれているが、
    実質 xmap の時と同じことのようだ。

    % これについてはシェルの操作としてどの様な意味を持たせるのかというのは微妙な所である。
    % 履歴項目のブックマーク的なものとして利用することはできるかもしれない。
    % しかし、既にコマンドラインに入力されている文字列を元にジャンプをするとなると矢張り微妙だ。
    % 唯一意味がありそうなのは、指定した単語がコマンドライン上で定義された
    % シェル関数だった時にそこにジャンプするという物だが…本当に需要があるのかは微妙である。
    % しかし、シェル関数の定義を確認したいのであれば寧ろ command-help を呼び出せば良い。
    % シェル関数を修正するという目的ならば使えるかもしれない。
    % 然し、必ずしもシェル関数をコマンドラインで定義したとは限らないし、
    % 該当するファイルがあったとしてもそれをコマンドラインで表示する訳にも行かない。

    既に入力した文字列に対応して適切な履歴項目またはコマンドライン中の文字があればそこにジャンプする。
    例えばシェル関数を定義した履歴項目に跳んだり、変数名から declare に移動するなど。
    そういう機能でまともそうなのが定義できればそれを実装する。

2017-09-18

  * vi-mode: operator = [#tmp0001]

    :help = を見ると (設定 equalprog || 内部関数 C-indenting, lisp || 外部コマンド indent) が使われるそうだ。
    但し、indentexpr が非空白の時、indentexpr が使われる (参照: indent-expression)。

    インデントの規則について調べる。
    先ず初めに空行 (空白だけの行) を隔てて前の行に括弧がある場合には、
    それを考慮に入れて初めのインデントが決定される。
    空行を隔てて前の行がインデントされていればそれを継承する。

    結局空行を隔てた前の行のインデントまたは最後の括弧の位置を継承するということ?

    また括弧の種類は () しか見ていない {} や [] は見ていないようだ。
    デフォルトが lisp だからだと思われる。
    これは実のところシェルに適したインデントを実行するようにするべきなのだと思われる。
    しかしながらシェルのインデントはかなり面倒くさい。
    特に if, then, else, while, do, done 等については現在の解析では状態を記録していない。

    関連してコマンドが閉じていない時 RET を押すと改行挿入にするという物がある。
    この機能を実装する為にも現在の入れ子の状態を調べる仕組みが必要になる。
    RET で改行挿入にする機能のほうが幾らか単純なので、
    それを先に実装してからこれを実装する方が良い気がする。

  * vi-mode: 関連して [/ 等の実装についても調べたい。

    既に vim-surround.sh で類似の機能について実装したが、
    [/ についても個別に実装したい所である。

    他にテキストオブジェクトで [{ [} [( [) などと同等の機能も実装している。

    [# [' [( [* [/ [` [D [I [P [p [[ [] [c [d [f [i [m [s [z [{ [<mouse2>
    ]# ]' ]) ]* ]/ ]` ]D ]I ]P ]p ][ ]] ]c ]d ]f ]i ]m ]s ]z ]} ]<mouse2>

  * vim-surround: ds cs インデント

    surround.vim では改行が絡むとき = によるインデントを実行している。
    現在 vim-surround.sh ではインデントを実行していない。

    2017-10-09 追記

    yS ySS でもインデントは起こる様である。
    更に、xmap S でもインデントを行う (xmap gS はインデントは行わない)。

2017-09-17

  * cmplstofB: ビジュアルモード・選択モード?

    関連 #D0672 選択モード対応

    * テキストオブジェクトで範囲を選択し、また範囲を拡大する。

      どうやらテキストオブジェクトの拡大では左右の両端からの拡大を試みるような気がする。
      決して右端からテキストオブジェクトを拡大するというわけではないようだ。

      というのも変なところから初めて (...) の中に右端を移動して、
      その上で ib としてもエラーになるからである。或いは短くなる。
      どうも ib の動作としては左端から外側の ( を見つけて、
      それに対応する ) を右端に直すようである。

      うーん。これはテキストオブジェクトによって動作が異なるのかもしれない。
      aw などは明らかに右に向かって拡大を行っている。
      因みに矩形選択かどうかは気にしないようだ。
      同じ動作をする。行の右端に行くと次に次の行に普通に移動する。

    2018-02-22 現状の xmap におけるテキストオブジェクトの状況について整理する。
    - ble/keymap:vi/text-object/word.impl に於いては既に xmap での振る舞いに対応している様子である。
    - ble/keymap:vi/text-object/quote.impl は明らかに対応していない→対応した #D0670
    - ble/keymap:vi/text-object/block.impl も対応していない→対応した #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 (実装ログ)
-------------------------------------------------------------------------------

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 ... を実行する事はできる。

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/util/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 を一つ作る事にする。