note.txt

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

拡張

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

制限

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

  * bash-3 C-d について

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

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

  * 文字コードについて

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

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

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

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

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

    - ble/encoding:$bleopt_input_encoding/generate-binder

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

    - bash echo {@(,)}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    - echo [a[!b

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  [complete 仕様について]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  * bash-4.4 -- 4.3 バグ

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

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

  * bash-4.4 -- 3.2, etc

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

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

  * bash-4.2

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

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

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

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

  * bash-4.0 segfault

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

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

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

  * bash-4.0 -- 3.0

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

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

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

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

  * bash-3.2 -- 3.1

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

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

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

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

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

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

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

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

  * bash-3.1

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

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

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

  * bash-3.0

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

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

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

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

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

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

  * bash-3.0 - 4.4.7 算術式:

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

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

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

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

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

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

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

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

  * bash-4.2 算術式 seg fault

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

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

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

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

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

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

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


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

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

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

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

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

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

  * bash-3.1, 3.0

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

bash 配列の宣言に関する仕様・バグと注意点

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

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

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

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

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

  * BUG bash-4.0, 4.1 (local), bash-3.0 ～ 3.2 (declare)

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

    [問題]

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

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

    [解決]

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

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

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

  * 配列要素を連結する時

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

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

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

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

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

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

bash_features

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

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

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

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

  * read -t timeout

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

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

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

    2021-02-10 #D1470 どうも bash-4.2 の declare -g にはバグがある。declare -gA
    とすると属性は global まで適用されるが、代入された値は関数を抜けると共に消
    滅する。

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

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

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

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

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

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

  * printf -v var %s value

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

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

bash_tips

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  * rcfile を処理している間は

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

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

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

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

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

2021-05-03

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

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

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

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

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

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

2021-05-01

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

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

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

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

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

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

    3 expand_aliases
    4 FUNCNEST
    5 set +o posix

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

    6 reset-builtins

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

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

2020-05-11

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

    ref #D1351

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

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

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

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

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

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

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

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

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

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

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

2020-05-06

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

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

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

    RETURN:

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

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

2020-04-14

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

    Bash のパラメータ展開 #D1330

    <param>

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

    <modifier>

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

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

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

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

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

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

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

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

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

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

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

2020-04-07

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

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

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

2019-06-10

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

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

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

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

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

2019-02-13

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

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

2019-01-01

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

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

2018-08-31

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

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

    * modifyOtherKeys(2)

2018-08-05

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

    参考: #D0714

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

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

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

    ※2 バグと思われる。

2017-10-31

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

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

    126 widget を呼び出すことができなかった
      未使用

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

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

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

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

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

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

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

2017-10-18

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

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

2017-09-24

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

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

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

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

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

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

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

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

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

2017-09-08

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

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

2015-11-28

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

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

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

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

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

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

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

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

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

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


2015-08-14

  * [memo] builtin check [#M0003]

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

  * [memo] leak variables check [#M0002]

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

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

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

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

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

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

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

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

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

2021-05-06

  * bash-completion
    https://github.com/akinomyoga/ble.sh/issues/97
    Ref #D1533

    python のテストを自分で実装したりしなければならず面倒である。

  * 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-05-04

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

  * 2021-03-21 gitstatus.plugin.sh の alias builtin で builtin eval 他が破壊されている
    https://github.com/akinomyoga/ble.sh/issues/93

    * 取り敢えず暫定的な対策として source ble.sh の時に unalias builtin 等を実
      行する事にした。

    * 他に source ble.sh した後に gitstatus.plugin.sh が実行されて、更にその後
      になって ble-attach した時の事も考える必要がある。

    gitstatus.plugin.sh の側で対策できないのか。
    34e21707

    https://github.com/romkatv/gitstatus/issues/154
    ここで本人が builtin を置き換えるのは良くない事だという事を述べている。

    > It's generally not a good idea to redefine builtins. If you also redefine
    > things like true, local, unset, etc., gitstatus won't work. Please don't
    > file a bug in this case but rather fix your config.

    eval ... pos parameters
    source ... pos parameters
    source ... function scope or not (declare var の振る舞い)
    unset ... previous-scope dynamic-unset or value-unset
    exec ... persistent redirections
      これは実際に問題になるという事を確認した。


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

0.6 ErrorMsg
0.5 ControlPanel/TUI Framework
0.4 progcolor

2021-05-05

  * MSYS2 で Backspace で行全体が削除されるという話
    https://github.com/akinomyoga/ble.sh/issues/104

    取り敢えず MSYS2 の .inputrc が怪しいという事で msys2-users に報告した。
    それとは別に ble.sh の側でも対策する事は可能だろうか。

2021-05-04

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

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

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

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

2021-05-03

  * rlfunc: C-x s spell-correct-word
  * rlvar: enable-active-region
  * rlbind: prior, next
  * vi-undo

2021-04-29

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

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

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

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

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

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

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

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

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

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

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

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

      x DEBUG のコストがある。

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

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

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

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

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

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

2021-04-06

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

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

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

2021-04-26

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

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

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

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

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

  * decode: [refactor] _ble_decode_KEYMAP_kmap_@ ?

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

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

2021-04-04

  * history auto-save

2021-03-21

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

2021-03-07

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

2021-02-28

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

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

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

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

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

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

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

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

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

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

2021-02-27

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

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

2021-02-24

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

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

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

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

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

2021-02-23

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

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

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

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

    [解決方法]

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

2021-02-22

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

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

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

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

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

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

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

2021-02-13

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

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

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

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

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

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

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

2021-02-10

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

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

2021-02-06

  * tui: TreeView

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

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

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

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

2021-02-05

  * 他の bash プログラム

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

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

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

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

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

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

    * Incremental parsing:

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

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

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

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

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

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

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

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

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

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

2021-02-05

  * evaluate-path-spec (by 3ximus)

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

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

2021-02-03

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

2021-02-01

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

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

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

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

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

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

2021-01-28

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

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

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

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

    b 新しい配列を追加する

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

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

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

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

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

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

2021-01-22

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

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

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

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

2021-01-08

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

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

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

2020-12-19

  * bug-bash: jobs in trap handlers

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

      trap '(true); jobs' WINCH

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

      trap '(true); jobs' INT

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

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

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

2020-12-14

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

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

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

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

2020-11-30

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

2020-11-20

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

2020-11-13

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

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

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

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

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

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

2020-11-11

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

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

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

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

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

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

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

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

2020-11-07

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

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

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

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

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

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

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

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

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

2020-11-06

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

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

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

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

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

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

2020-09-07

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

  * complete: メニュー絞り込みの着色が残ったままになってしまう事がある

2020-09-03

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

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

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

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

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

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

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

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

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

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

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

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

2020-09-01

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

2020-08-27

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

2020-08-03

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

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

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

    チェック項目は…

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

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

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

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

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

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

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

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

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

    眺めていて気づいた事。

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

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

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

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

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

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

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

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

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

2020-06-04

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2020-05-20

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

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

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

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

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

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

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

2020-05-16

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

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

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

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

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

2020-04-25

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

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

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

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

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

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

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

    要件は以下の通り

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

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

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

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

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

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

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

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

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

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

    ref #D1350

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

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

2020-04-19

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

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

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

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

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

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

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

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

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

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

2020-04-09

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

2020-04-02

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

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

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

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

    * GitHub 用に Travis を設定する。

2020-03-22

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

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

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

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

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

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

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

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

2020-03-11

  * __line_limit__ の実装の制限

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

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

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

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

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

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

2020-02-02

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

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

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

2020-01-26

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

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

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

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

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

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

2020-01-23

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

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

2020-01-21

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

    https://github.com/lmorg/murex

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

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

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

2020-01-17

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2020-01-05

  * Homebrew の設定を作成する?

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

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

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

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

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

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

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

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

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

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

2019-12-31

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2019-12-29

  * color: term_true_colors=auto

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

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

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

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

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

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

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

2019-10-21

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

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

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

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

2019-09-24

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

2019-09-22

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

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

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

2019-07-16

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

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

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

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

2019-07-09

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

2019-07-02

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

2019-06-18

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

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

2019-05-27

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

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

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

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

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

2019-04-21

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

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

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

2019-03-23

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

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

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

  * menu: 今後の拡張性

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

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

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

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

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

2019-03-22

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

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

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

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

2019-03-19

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

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

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

2019-02-09

  * うーん。git や bash-it の様に ble.sh でも ble コマンドの様な物を提供するべき?

    と思ったが既に何処かには ble という名前のコマンドが存在していて、
    これらは Bluetooth のサービスの開始・終了などを実行するのに使われている様子である。
    もしこれらが広範に用いられている物なのだとしたら使いにくい。

    また、ble の名前の由来である zle コマンドの事を考えると、
    ble widget の様な使い方を想像してしまうのではないかとの問題もある。

    混乱を防ぐためには ble ではなくて ble.sh または blesh の様な名前が良いだろう。
    しかしそうすると現状の ble-import だとかの機能を呼び出すのに余り適していない気がする。
    つまり、blesh import ... で ble-import が呼び出されるというのは分かりにくい。
    或いは現状の ble-import を blesh-import に改名するという手もあるかもしれないが、
    そういう事を考え始めると全ての関数を ble から blesh に改名したくなる。
    それは面倒だし、元の zle という名前から離れていくので余りやりたくない。

    実のところ、現状のまま ble-* の方が自動的に補完が効くので嬉しい。

    bash.env は bash.env という名前のコマンドを提供する様である。
    https://github.com/midwire/bash.env
    そういう事であれば ble.sh でも ble.sh という名前の関数を提供すれば良い気がする。
    しかし ble.sh が入力しやすいのかというと微妙ではある。

    bash-it の場合には bash-it-update だとか bash-it::update だとかだと
    格好が悪いので bash-it update という形の関数名になるというのは分かる。

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

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

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

2018-09-21

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

2018-08-16

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

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

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

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

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

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

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

2018-08-05

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

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

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

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

2018-07-29

  * complete: メモ

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

2018-07-19

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

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

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

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

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

    ref #D0699

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

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

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

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

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

2018-03-14

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

2018-02-21

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

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

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

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

2018-02-12

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

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

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

2018-02-11

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

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

2017-11-21

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

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

    Note: これは端末によっては表示されたりする。端末による。
    エラー着色はどの様に行われているのか。for の後には FARGX1 に入る。

    これは ble-syntax:bash/ctx-command/.check-delimiter-or-redirect の冒頭部分が怪しい。
    と思ったが FARGX1 に関してはチェックが入っていないのでやはり関係ないだろうか。
    うーん。調べるとやはり文法レベルでの着色になっている。

    2019-03-11

    | rps1 で表示している時に EL を空白で代替していると、
    | 改行の着色が空白に反映される。これでも良いような気がしてきた。
    | 然し、右側が全て着色されるというのもうるさい。
    | 最初の1文字だけ着色して SGR(0) するかと思ったが、
    | そうするとその次にある文字の着色も消えてしまう。
    |
    | それの対策のために _ble_textmap_ichg があるのでは。
    | と思ったが、実装を見てみると違っている様に見える。
    | _ble_textmap_ichg は着色の調整に使っている事は確かだが、
    | _ble_textmap_ichg に登録されている文字の着色を計算しているのであって、
    | _ble_textmap_ichg に登録されている文字の次の文字の着色は計算していない様に見える。
    | うーん。_ble_textmap_ichg は他の箇所では全く使っていない。
    |
    | そうだ。思い出した…。_ble_textmap_ichg に登録されている文字は、
    | 配置の場所によって中身が変わるので、shift が使えないという事だった。
    | 特に、中身が変化している場合には文字を取り出して変更を行うのだった。
    | では以前 ichg に登録されていて、現在位置では ichg に登録されていない文字はどうなるのか。
    | と思ったら既定の文字形は別の所で決定されている様だ。
    | ble/highlight/layer:plain/update/.getch である。

    a 右側の1文字だけ着色される様にする?

      x 問題点はコピーペーストした時に必ず余分な空白が入る事である。
        これは右側の全てを着色させる場合にも同様の問題が生じる。

        また、エラーが有る時にだけ (着色の必要がある時にだけ)
        右側に空白を入れるという方法もある。
        しかし、その為にはその位置にエラーが有るのかないのかを
        外部から取得しなければならない。

        ble/textmap#update は edit.sh だとかの仕組みに依存しない、
        独立した枠組みにしたいので余り変な機能は取り付けたくない。

      x また実装上の問題点として、rps1 が表示されている時に、
        _ble_term_ech を使わない場合、2文字目以降の空白文字を SGR(0)
        でクリアしなければならない事である。この場合、
        改行の次の文字の SGR を復元する為には…

        _ble_textmap_ichg に次の文字の番号も追加するか、
        或いは現在の改行文字の SGR 状態を復元する必要がある。
        しかし textmap の処理をしている間は、
        未だ着色が完了していないので SGR 状態を取得できない。

        或いは着色部分だけ textmap#update よりも前に持ってきても良いのだが、
        その様にしたとしても色情報を textmap#update に伝達する手法が必要である。
        例えば getg なる関数を textmap#update から呼び出してもらう事にするのか。
        或いは呼び出す関数名も外から指定できる様にするのか。

    b やはり改行の前の1文字を描画時に強制的に着色するという手もあるのではないか。
      と思ったが…エラー着色だけ特別扱いするというのも変な話である。

    c その様に考えると初めから改行にはエラー着色はしないというのが正しい気がする。

      改めて調べると ble/syntax:bash/ctx-command-compound-expect がエラーを設置している。
      うーん。for だけの問題では無い様である。他に select, case の時にも同様である。

      ('for'|'select'|'case')
        [[ ${text:i:1} == $'\n' ]] &&
          ((_ble_syntax_attr[i-1]=ATTR_ERR))
        case $word_expanded in
        ('for')    ((ctx=CTX_FARGX1)) ;;
        ('select') ((ctx=CTX_SARGX1)) ;;
        ('case')   ((ctx=CTX_CARGX1)) ;;
        esac
        processed=begin ;;

      実際に上記の様にして見たら見える様になった。
      しかし rps1 が有効になっている時はやはりうるさく感じられる。
      また端末に依っては rps1 が無効になっていても行全体が赤く着色される。
      そういう端末 (mintty など) どういう発想なのかはよく分からないが…。

      更に here documents も行末にエラーを設置する。
      これについても対策したいが、here documents に関しては、
      nest の終端がない事によるエラー着色である。
      これは nest の範囲を変更しないと着色を変更できない。

      何だか中途半端な実装の気がしてきたので取り敢えずこの変更はなかった事にする。

    d うーん。右側の内容の消去は実は改行文字を使って行うのではなくて、
      描画した後に消去するという方法にした方が良いのだろうか。
      しかし、その様にすると、今度は urange の中にある行末というのを列挙して、
      それから各行末について位置を計算して実行するという事をしなければならない。
      textmap さえあれば指定範囲内の行末は二分法によって特定する事が可能である。
      しかし面倒である事に変わりはない。もっとまともな方法はないのだろうか。

    結局実装の面倒さを考えなければ三種類の仕様が考えられる。

    a 右側に1文字赤く表示する
    b 行末まで赤く表示する
    c 行の最後の文字を赤くする
    d 表示されなくても気にしない

2017-11-09

  * complete: 候補の優先順位? 例えば拡張子でフィルタすると絞りすぎることがある。
    拡張子の要件を満たすものを先に表示して、満たさないものを後に表示する。
    満たさないものに関してはサブ候補として、TAB による接頭辞挿入には寄与しない。

    2018-07-28 候補間の優先順位をつける可能性。
    weak な優先順位は、候補を表示する時の順序。
    strong な優先順位は、候補絞り込みの際に一番優先順位の高いものが一つしかない場合にはそれに確定する。

2017-11-05

  * vi-mode

    :help 関連の気になること:

    - v_p v_P: Implementation details に書かれている処理の順序は実際は逆
    - exclusive-linewise: ここの inclusive/linewise になる条件の記述は曖昧だし全く合っていない
    - star: vim-jp の文書だと WORD と書いてあるが、振る舞いは word (しかも \<\> で囲まれる) に近い

    振る舞いで気になること

    - i<C-o><C-c> とすると普通のノーマルモードに移行したように見えるのに、
      モード表示は -- (挿入) -- のままである。これは何故だろう。
      ble.sh ではノーマルモードに完全に移行する。

    - qa<C-c>q とすると ^C が二重に記録される。これは何か?
      ble.sh では単に ^C は入力された通りに一個だけ記録する。

    - C-v <bracketed paste> では矩形挿入にするべきなのではないか。
      ble.sh では矩形挿入を行う。


2017-11-03

  * vi-mode (registers): 各種特殊レジスタの対応

    http://vim-jp.org/vimdoc-ja/change.html#registers

    - done: "% は現在のファイル名を保持するが、これは $HISTFILE の内容を返す事にした。

    - done: ": は一番最後のコマンドラインの内容である。
    コマンドラインを入力し途中でキャンセルした場合などには記録されない。
    空のコマンドラインで確定した時にも記録されない。
    コマンドが入力された場合は、それが存在しないコマンドであっても記録される。
    コマンドが実行されている途中では未だ設定されていない。
    つまり、そのコマンドが実行された後で値が設定される。

    - ". は挿入モードで挿入された文字列を保持する。挿入モードから抜ける時に記録すればよいだろうか。
    と思ったが説明をよく読んでみるとそういう振る舞いという訳でもなさそうだ。
    よく分からないので実際に動かして試してみる必要がある。

    - "# は代替ファイル (副ファイル) の名前だそうだが何か良くわからない。
    C-^ の動作と関係しているそうだ。これは未だ実装しない。

    - "= これは複雑だ
    - "* "+ "~ これは GUI で選択した範囲を表すものだそうだ。

2017-10-31

  * [保留] vi-mode (_ble_keymap_vi_REX_WORD): Unicode categories?

    Bash の正規表現 (<regex.h> ERE) で対応するのは難しい。
    また必ずしも Unicode (UTF-8) で実行されるとは限らない。
    現在は UTF-8 しか対応していないが枠組みとしては
    別の文字コードにも対応できる余地は残して置きたい。

2017-10-12

  * vi-mode まだ対応していない・考えていないコマンドを列挙する

    意外とそんなに残っていないようなので。

    * nmap: C-^ '括弧 `括弧
      C-t C-] M Q ZZ ZQ do dp { }
      [{char} ]{char} z{char} C-w{char}
      g<C-a> g<C-g> g<C-h> g<C-]> g# g* g$ g&
      g` g' g+ g, g- g8 g; g< gD gH gN gP gQ gT gV
      g] ga gd gf gF gh gn gp gq gs gt gw gx g@

  * [保留] vi-mode: xmap <C-]>

    % <C-]> なる物は今見ても存在しない。vivis https://qiita.com/b4b4r07/items/8db0257d2e6f6b19ecb9
    % 辺りに在ったものかとも思ったが、ない。zsh-vimode-visual を見てもない。
    % vim で C-] としてもベルが鳴る。何かの間違いで C-[ を C-] と書いてしまっただけなのかもしれない。
    % と思って改めて vimindex を見ていたら実はあった。

    C-] で "選択した文字のタグ" へジャンプと書かれている。
    タグとは何だろうと思ったら http://vim-jp.org/vimdoc-ja/tagsrch.html に説明がある。
    ctags のタグと同じものと思って良さそうだ。因みに :help ... で表示されるのもタグの様だ。
    またノーマルモードの C-] はカーソル位置の単語を ":ta" で検索と書かれているが、
    実質 xmap の時と同じことのようだ。

    % これについてはシェルの操作としてどの様な意味を持たせるのかというのは微妙な所である。
    % 履歴項目のブックマーク的なものとして利用することはできるかもしれない。
    % しかし、既にコマンドラインに入力されている文字列を元にジャンプをするとなると矢張り微妙だ。
    % 唯一意味がありそうなのは、指定した単語がコマンドライン上で定義された
    % シェル関数だった時にそこにジャンプするという物だが…本当に需要があるのかは微妙である。
    % しかし、シェル関数の定義を確認したいのであれば寧ろ command-help を呼び出せば良い。
    % シェル関数を修正するという目的ならば使えるかもしれない。
    % 然し、必ずしもシェル関数をコマンドラインで定義したとは限らないし、
    % 該当するファイルがあったとしてもそれをコマンドラインで表示する訳にも行かない。

    既に入力した文字列に対応して適切な履歴項目またはコマンドライン中の文字があればそこにジャンプする。
    例えばシェル関数を定義した履歴項目に跳んだり、変数名から declare に移動するなど。
    そういう機能でまともそうなのが定義できればそれを実装する。

2017-09-18

  * vi-mode: operator = [#tmp0001]

    :help = を見ると (設定 equalprog || 内部関数 C-indenting, lisp || 外部コマンド indent) が使われるそうだ。
    但し、indentexpr が非空白の時、indentexpr が使われる (参照: indent-expression)。

    インデントの規則について調べる。
    先ず初めに空行 (空白だけの行) を隔てて前の行に括弧がある場合には、
    それを考慮に入れて初めのインデントが決定される。
    空行を隔てて前の行がインデントされていればそれを継承する。

    結局空行を隔てた前の行のインデントまたは最後の括弧の位置を継承するということ?

    また括弧の種類は () しか見ていない {} や [] は見ていないようだ。
    デフォルトが lisp だからだと思われる。
    これは実のところシェルに適したインデントを実行するようにするべきなのだと思われる。
    しかしながらシェルのインデントはかなり面倒くさい。
    特に if, then, else, while, do, done 等については現在の解析では状態を記録していない。

    関連してコマンドが閉じていない時 RET を押すと改行挿入にするという物がある。
    この機能を実装する為にも現在の入れ子の状態を調べる仕組みが必要になる。
    RET で改行挿入にする機能のほうが幾らか単純なので、
    それを先に実装してからこれを実装する方が良い気がする。

  * vi-mode: 関連して [/ 等の実装についても調べたい。

    既に vim-surround.sh で類似の機能について実装したが、
    [/ についても個別に実装したい所である。

    他にテキストオブジェクトで [{ [} [( [) などと同等の機能も実装している。

    [# [' [( [* [/ [` [D [I [P [p [[ [] [c [d [f [i [m [s [z [{ [<mouse2>
    ]# ]' ]) ]* ]/ ]` ]D ]I ]P ]p ][ ]] ]c ]d ]f ]i ]m ]s ]z ]} ]<mouse2>

  * vim-surround: ds cs インデント

    surround.vim では改行が絡むとき = によるインデントを実行している。
    現在 vim-surround.sh ではインデントを実行していない。

    2017-10-09 追記

    yS ySS でもインデントは起こる様である。
    更に、xmap S でもインデントを行う (xmap gS はインデントは行わない)。

2017-09-17

  * cmplstofB: ビジュアルモード・選択モード?

    関連 #D0672 選択モード対応

    * テキストオブジェクトで範囲を選択し、また範囲を拡大する。

      どうやらテキストオブジェクトの拡大では左右の両端からの拡大を試みるような気がする。
      決して右端からテキストオブジェクトを拡大するというわけではないようだ。

      というのも変なところから初めて (...) の中に右端を移動して、
      その上で ib としてもエラーになるからである。或いは短くなる。
      どうも ib の動作としては左端から外側の ( を見つけて、
      それに対応する ) を右端に直すようである。

      うーん。これはテキストオブジェクトによって動作が異なるのかもしれない。
      aw などは明らかに右に向かって拡大を行っている。
      因みに矩形選択かどうかは気にしないようだ。
      同じ動作をする。行の右端に行くと次に次の行に普通に移動する。

    2018-02-22 現状の xmap におけるテキストオブジェクトの状況について整理する。
    - ble/keymap:vi/text-object/word.impl に於いては既に xmap での振る舞いに対応している様子である。
    - ble/keymap:vi/text-object/quote.impl は明らかに対応していない→対応した #D0670
    - ble/keymap:vi/text-object/block.impl も対応していない
    - ble/keymap:vi/text-object/tag.impl も対応していない
    - ble/keymap:vi/text-object/sentence.impl も対応していない
    - ble/keymap:vi/text-object/paragraph.impl も対応していない

2017-09-16

  * cmplstofB: vim-surround.sh: ds cs cS yS ySsd ySSd S gS 'C-s' 'C-g s' 'C-g S'

    現在のところ特に要望は出ていないが ds cs あたりは使いたくなるのではないかと思われる。
    → ds cs に関しては要望が出たので対応した。
    → cS yS ySs ySS vS vgS にも対応した。

    残っているのは imap <C-s> <C-g>s <C-g>S のみである。

2017-09-15

  * cmplstofB: here string 候補について

    here string 候補にファイル名以外のものがあれば対応する。返信待ち → やはり候補は難しい。

    コマンド名に応じた補完関数の設定を可能にする?
    例えば python3 に対する here document の場合には、import を補完候補に出すなど。

    2018-10-02 C++ の場合にはこんな感じに clang を呼び出せば良い様だ。
    clang -cc1 -fsyntax-only -code-completion-at=test2.cpp:7:7 test2.cpp
    http://d.hatena.ne.jp/ohtorii/20110319/1300514225

    Here document で補完候補を出す為には、
    Here document の内容 (先頭から現在位置まで) が
    単純内容 (単純単語に近いがシェルの特殊文字を使える) でなければならない。
    その為の関数を追加する必要がある。simple-word の実装を真似れば良い。

2017-08-19

  * [保留] cmap/default.sh: "CAN @ ?" 代替?

    "CAN @ ?" は "C-x C-x" と較べて曖昧ということで現在無効にしている。
    これの代替キーシーケンスを定義しても良いかもしれない。
    といいつつ現実の端末に存在するものを登録しなければ意味がない。
    (そういう意味では "CAN @ ?" もこれに対応する現代的な端末が実在するのか怪しいのであるが。)

    思うに s-x だとか H-x だとか A-x を送りたければ CSI 2 7 ; ... ; ... ~ を使えば良い。
    何故 Emacs が "CAN @ ?" に対応しているのかは謎である。

    →実はこれは isolated esc と同じ方法を用いて区別して受信可能かもしれない。
    しかし、何れにしても "CAN @ ?" に対応している端末は殆どないので、対応する理由がない。
    https://superuser.com/questions/407391/super-key-over-ssh によると Konsole がこの形式を使うそうだ。

2017-03-04

  * syntax: bug ヒアドキュメントによる nparam の更新が追いついていない。

    これは何でかというと nparam の計算に stat 保存点を超えた過去の情報を用いているからである。
    部分更新をしている為に過去の情報が書き換わったとしても
    stat 保存点で解析状態が一致したと見なされてしまい、
    其処で解析が中断してしまうのがいけない。

    これを解決する為にはヒアドキュメントの word に相当する部分は
    一気に解析する様に修正しなければならない。
    結局 word 部分は最終的には独自の方法で読み取るのが良い様な気がする。

    或いは暫定的に範囲を指定して stat を消去する様な機能があったような…?
    →昔その様な処理の仕方をしていたような気がするが、いま確認してみるとない。
    恐らく何か問題が色々生じて結局その方法は使わないという事になった様な気がする。
    記憶が正しければそれは time ... や function func () だとか func () を解析する時の話だった。
    結局何れの場合でも一回の解析で行けるところまで解析するという事になった。
    ヒアドキュメントでもその様に実装するのが一貫している。

  * syntax: ヒアドキュメント 終端 word 着色

    todo: 取り敢えず RDRS 等と同様に完全に入れ子を追跡する様に実装する。

    $() ${} の入れ子も含めた実装が必要になる。

    実は、通常通りに解析してしまって、
    後の着色で一様な色に塗り潰してしまうという方策で良いのではないか。
    しかしそれだと tree-enumerate の際に $() の内部で着色が起こる気がする…。
    % 特に部分更新などをすると確実に内部での着色が発生するのでは…??
    % →部分更新の時は一番外側の単語についても着色が判定されるから特に
    % 部分更新仮想で内科に依る違いは発生しないと思われる。

    取り敢えずの実装として通常通りに解析する様に変更した。
    単に ble-syntax:bash/ctx-heredoc-word から
    ble-syntax:bash/ctx-redirect に処理を委譲するだけで良かった。
    ヒアドキュメント特有の処理は ble-syntax:bash/ctx-heredoc-word/check-word-end
    の方にしかなかったからである。
    また、同時に CTX_RDRI, CTX_RDRH の単語を上から塗りつぶす様にした。
    しかし、やはり予想通り $() の内部などの単語の着色は発生してしまっている。

2017-03-02

  * syntax: パラメータ展開・算術式評価内部の quote 除去が為されない状況での _ble_syntax_attr

    以下の項目で対応しきれなかった (対応しないことにした) ものをここにまとめる。
    cf. #D0375 "2017-03-02 [2016-08-06] syntax: extquote と "${}" の入れ子に関して"

    > - $(()) の中の () のネストに関しては対応していない。
    >   つまり () が一つでも挟まれば quote 除去が有効であるかのように着色される。
    >   →これは対応した。

    - $((a['1+1'])) などの添字の quote 除去は有効であるが、現実装では quote の着色はしていない。
      つまり $(('1+1')) などと同様に quote 除去が為されない物として着色を行っている。

      これに対応する為には $(()) の中でも [] に対応するネストを判定する様にしなければならない。
      ※一方で [] の中では () に対応するネストの判定はしなくても良い。

    - $(("${hello}")) などの構造では CTX_QUOTE の中で自身が有効かどうかを判定して
      自身の着色を変更したりするのは面倒なので、普通に (有効であるかの様に) 着色している。

      算術式の場合には quote 除去されないと分かっている時点で文法エラーになるので
      1文字目をエラーの色にするというので良い気がする。
      パラメータ展開の内部の場合には quote 除去されないからと言ってエラーにはならない。

    - bash では "${var# ... }" の中の '' は quote 除去される一方で、
      "${var:- ... }" の中の '' は quote 除去されない。
      この実装では取り敢えず quote は除去されるという取り扱いである。

      これらについては包括的に振る舞いを調査する必要があるだろう。
      他にも様々な種類のパラメータ展開があるし、
      また将来的に各種類のパラメータ展開についての詳細な構文解析にも対応する可能性がある。
      (特に ${var//a/b} の quote (\?) の取り扱いがややこしいのでこれは視覚的に分かる様にしたほうが良い。)

    - 現状では $(("a")) はエラー着色になっているが実は文法的に有効である。
      同じクォートでも $(('a')) や $((\a)) は文法的に駄目。

    - Bash 5.1 以降では (('a')) がエラーになる様に文法が変わった。

2016-07-15

  * isearch: 現在の履歴内の位置を % で表示しているが、
    これは検索の進捗状況の表示の方が分かりやすいのではないか。

  * complete: declare の引数を特別扱いしているがこれも compgen があればそれに従うべきでは。
    もしくは、何か特別な処理をするとしても compgen を介して特別な処理をするべきではないのか。

    現状の実装だと、declare などの変数を宣言する組み込みコマンドについて、
    ユーザが complete によって補完の制御を行う事ができない。

2016-07-08

  * prompt: 最終行・先頭行に何か表示する機能があっても良い。

2016-07-07

  * isearch: 正規表現検索?

    →取り敢えず vi-mode で実装した #D0513。incremental ではない。

    正規表現で incremental にすると一度通り越したものに一致する可能性があるので直観的でない。
    もし incremental にする需要がある場合には再度考える必要がある。
    因みに、emacs は (分かりにくい動作だが) 現在の位置から続きの検索をする。

  * edit: 置換モード (正規表現・固定文字列・globパターン)?

    その為には置換前・置換後を入力する欄を別に表示する必要がある。
    入力欄でも様々な binding が使えた方が嬉しい。

2016-06-22

  * tui: prompt-toolkit という物がある様だ。ちょっと観察してみるのも良い。

    基本的には補完候補を勝手に出すという事と、
    表示の仕方が emacs auto-complete と同様に
    overlay によって実現されているという事。

    所で overlay で実現するためには複数行で編集を行っている時に、
    下の行にある内容を記憶しておく必要性が生じる。
    Emacs の場合には表示している内容を完全に内部に保持しているので問題にならなかった。
    (a) 現在の実装で実現するためには内容を完全に記憶するか、そうでなければ
    (b) 複数行で編集を行っている場合には枠の位置・大きさを変更する際に
    毎回下の方にある行を再描画するかといった事が必要になるだろう。

    Bash では 2 次元配列を実現するのは辛いので
    結局内容を完全に記憶するというのは余り嬉しくない事だろうか。
    と思ったが、表示領域の幅 (COLUMNS) さえ把握しているのであれば、
    実は 1 次元配列の上に terminal の内容を保持してしまっても問題ない気がする。
    というか枠の大きささえ決まっていれば普通に sub window の様な物も
    bash で実現する事ができる。今まで余り考えたくないとして避けていたことだが、
    この方法ならば楽である。

  * tui: GUI Window System を整える? Window を出したり消したりだとかそういう事。

2016-04-05

  * tree-enumerate による skip の実装と解析一時中断の不整合に関して。

    ble-syntax.sh: ble-syntax/parse/shift.impl2 の問題点である。

    現状の方法では、解析一時中断を行った時に shift 対象の高速な列挙が出来なくなる。
    唯一の現実的な高速化手法は "直前非空白要素の位置" を管理するように変更する事である。
    これは解析自体の動作とは全く関係なく、_ble_syntax_tree/stat/nest の配列としてのデータ構造を拡張するという事である。
    解析自体の実装とは直交して実装する事が可能と思われるが、新規情報の管理コストが増えるという問題点が残る。

    →一方で tree-enumerate を使った場合には閉じている単語内部の shift を省略できるなどの利点がある。
      最終的にはこれらを組み合わせたような shift が必要になるだろうと考えられる。
      もう少し詳しく考察を行う必要性がある。

2015-12-20

  * complete: 履歴を用いた候補生成? 特に単語について。

    2018-09-23 これは動的略語展開によって部分的には対応された。
    しかし処理の重さから一度に全ての候補は計算しないし、
    また文法的な単語ではなくて COMP_WORDBREAKS によって分割された単語である。
    これを本当に対応しようと思ったら background でプログラムを
    走らせるなどの事が必要になる気がする。

2015-11-21

  * 公開までに追加であった方が良いかも知れない物

    + 拡張性の提供 (拡張の仕方の説明)
      + theme の枠組を整える事 (setting files の置き場?)
        ble-color-list
      + 文字コード拡張 (Unicode との mapping)
      + 端末制御コード拡張
        tput からもっと積極的に読み込むべきなのでは?
        cmap/default.sh に加えて cmap/tput.sh 的な物も?
        > minimal.sh, xterm.sh, rosaterm.sh の整理。

    + 簡単なキーボードハンドラのサンプル (テトリスとか? 或いは sentaku 再実装とか)

      サンプルとしては、端末の出力画面に現れる物よりは、
      画面を altscreen で完全に切り替える物の方が実装しやすいと思われる。
      それでいて、read -t 0 などを有効に使えるとなるとテトリスなどになるだろうか。

    + マウス対応

    + キーボード入力内容を全部 vbell で表示する方法?

2015-11-06

  * まったく同じ nest 状態になると思われるのに解析中断が起こらない

    ☆これは表面上は何の問題も起きない。多少無駄な処理をするだけである。
      従ってそんなに対処に緊急を要しない。

      | function ble-syntax/parse/nest-equals {
      |   local parent_inest="$1"
      |   while :; do
      |     ((parent_inest<i1)) && return 0 # 変更していない範囲 または -1
    -->     ((parent_inest<i2)) && return 1 # 変更によって消えた範囲
      |
      | local _onest="${_tail_syntax_nest[parent_inest-i2]}"
      | local _nnest="${_ble_syntax_nest[parent_inest]}"
      | [[ $_onest != $_nnest ]] && return 1
    変更によって消えた領域を指している場合は、
    既に消えた領域のデータを捨てているので nest の判定を行う事ができない。
    そんな訳で解析中断はできないと判定されてしまうのである。

    ここで解析中断を出来るようにする為には消えた領域のデータも取って置いて、
    その上で全く同じ解析結果になったら解析中断を行う、という事になろう。
    以降の解析の動作に違いがなければ良いのだから
    過去の nest の状態だけが一致していれば解析中断には充分である。
    これは別項目として独立させて残す事にする。

    ※問題は解析領域拡大によって i1 が後退する事によって
      変化の無かった部分についても解析結果が消去されてしまう事にある。

2015-08-20

  * エラー検出・表示の管理について

    現状

    現在エラーは様々な方法で使用者に対して提示している。
    解析の途中状態で既にエラーと分かる物については
    _ble_syntax_attr に ATTR_ERR を設定している。
    これは _ble_highlight_layer_syntax1_table を経由して表示の着色に反映される。
    もう一つのエラーの種類は入力したコマンドラインの末端で入れ子が閉じていない物である。
    これは一番最後の文字と対応する入れ子の開始点の色を変更する事によって提示する。
    この着色は解析点より前に対して行われるので部分更新の対象とする事は難しい。
    従って _ble_highlight_layer_syntax3_table を介して、毎回全消去・再計算を実行している。

    以下に改善したい箇所について列挙する。

    - この様に複数の方法を用いてエラーを提示しているのは少し醜い。
      もう少し統一した枠組を作っても良いのではないかという気がする。

    - ATTR_ERR を用いて設定したエラーは、
      後の処理で追加される単語毎の着色によって上書きされてしまう。
      つまり、折角エラー通知の為に着色を設定していても使用者に見えない事がある。
      別の場所にエラーを登録しても良いのではないかという気がする。

    - 各エラー項目に対して何が問題なのか・何のエラーなのかのメッセージを設定したい。
      これらのメッセージも枠組の中で管理して、カーソルの位置に応じて表示できる様にしたい。

    もう少し現状について調べて実装の方法について考える。
    先ずエラー情報を記録する為の配列の形式について。
    既存のエラー着色に使っている配列 _ble_highlight_layer_syntax3_table が気になる。
    これを拡張する形で実装する事はできないだろうか。。
    →この配列は部分更新できないような情報を保持するのに使っている。
      部分更新できない様な着色であっても今回の実装によって
      よりましな方法に変更できるのではないか、という気もするが、
      それは今回の実装が終わってから考えれば良い事である。
      (初めからその様な物にも対応できる様に今回の実装を設計するという事も出来るが
      複雑になるので、取り敢えずは何も考えずに実装する事を目指す。)

    つまり、_ble_highlight_layer_syntax3_table は non local な着色の為に使うとして残し、
    それとは別にエラーを管理する為の配列を作成する。

    部分更新の際の効率を考えると _ble_syntax_attr と同様に、
    編集文字列中の位置を配列のインデックスとする方法が良さそうに思われる。
    然し一方で、エラーの数はそんなに沢山になるとは考えがたい (sparse) なので、
    リストにして管理するという方針も考えられる。どちらの方が良いだろうか。
    リストにしている場合、"エラー設置点 エラー開始点 エラー終了点 メッセージ" というデータ形式になるだろうか。
    shift や解析中断後の再開に際してはエラー設置点を用いた filtering を行う。
    % このエラー情報の内容は解析の動作に全く影響を与えないし、
    % 解析が同じように進めば全く同じエラー情報を生成すると期待できるので、
    % 解析中断の判断基準に含める必要はないと考えられる。
    →本当だろうか。エラー開始点・終了点などの情報は解析状態が同じになっても異なる値になりうるのでは?
      特に、現在 _ble_highlight_layer_syntax3_table で管理している物はその最たる例である。
      ここで、エラー開始点・終了点が正しく設定される為には次の条件が必要である。

      エラー設置点を p1 とする。ble-syntax/parse の 1 step で i=i1 から
      i=i2 まで進む (但し i1 <= p1 < i2) 時、エラー開始点 p2, 終了点 p3 は、
      i1 <= p2 < p3 < i2 を満たす。

      この条件が揃っている時のみに現状の解析中断条件で部分更新安全である。
      因みに p2, p3 を設置点からの相対位置で記録しておけば shift の操作が必要なくなるのでその様にするべきである。

2015-08-16

  * 入れ子構造を考慮に入れた効率的な単語着色

    現状: 新規生成単語及び消滅単語の範囲 (range1) に関して再度単語の着色を実行する。

    x 但し、着色は "消滅単語の存在していた範囲" 及び "新規生成単語登録位置の範囲"
      に登録されている単語及びその子孫だけになっている。
      本来は、range1 に被さっている全ての単語について処理を実行するべきである。

    - 考慮に入れるべき事として、将来的に解析を途中で停止した場合でもそれなりに動くような方法がよい。
      しかしながら未だ解析を終えていない部分については結局どうしようもないから、
      解析が完了している部分文字列について木構造を作成して処理する事になるだろう。
      結局、現在 shift を実行するのに用いているのと同じ事をする事になる。
      (そしてそれは tree-enumerate/.initialize で実装されているので余り気にする事はない。)

    方法

    a 一つの方法は tree-enumerate を使用して末端から順に単語の範囲をチェックしていく方法である。
      つまり、現状の shift の実装と同じになっている。

    b もう一つの方法は、先に単語の木構造の情報だけ構築してから、
      range1 に対応するノードを列挙して構築する方法である。
      木構造として親ノードの位置・子ノードの配列を保持していれば、
      指定した範囲に対応するノードの範囲を効率的に計算する事が出来る。

      ただし、木構造の情報の構築自体にどれだけのコストがかかるかについて考える必要がある。
      木構造は後ろから掘り出すようにして実行する為、
      更新範囲の beg から文字列の末端 iN 迄を完全に構築し直す必要がある。
      部分更新するというのが難しいと思われる。

      しかし、部分更新は全くできないのでは等と考えていたが、
      考えてみると意外と部分更新も出来るのではないかという気になってくる。
      更新範囲に含まれていないノードの内部構造に関しては実は更新の対象ではない。
      また、更新範囲より前にあるノードの内部構造についても同様である。
      但し、親ノードの位置は、更新範囲より前にあるノードであっても更新する必要がある。

    c 或いは、parse の過程でより分かり易い木構造データも同時に構築してしまうという手もある。

      x parse の内部状態を増やせば増やす程、解析中断が難しくなるが
        最終的に構造を再構築するのであれば結局中断してもしなくても同じかも知れない…?
        しかしながら木構造を考えずに parse した後、木構造に対する更新を行った方が処理量は少なくなるはずである。
        というのも木構造を考えながら parse する事にすると、
        更新の必要のない文法的処理も木構造の構築と同時に実行してしまうからである。
        それよりは、文法的処理で必要最低限の所を parse で処理して、
        木構造の構築について必要最低限の所を後の処理で実行する、という形の方が良さそうである。

      o ただ、parse の過程で木構造も一緒に構築するようにした方が、
        データ同士の依存関係が整理されて良いという側面もある。
        parse の後で木構造としてどの範囲を更新するべきかを決定するのは面倒でありバグを生む原因にも成る。
        →parse の後で処理をする際にも何らかの "原則" を決めてその下で実装するなどした方が良いと思う。
        (逆に言えば上手に原則を決める事さえ出来れば、parse で木構造を構築する事の利点はなくなる。)


    入れ子構造の実装後に改善できる箇所
    - tree-enumerate-in-range 及びその呼出元
      現在は愚直に範囲内に設置されている単語識別子を

2015-08-15

  * syntax: `function ...' において関数名の部分に使用した履歴展開を解釈する?
    履歴展開だけを解釈する新しい文脈が必要になると思われる。

    然し乍ら、履歴展開の結果として複数の単語になる場合などを考えると、
    そもそも一つの単語として読み取って良いのかなど疑問点が残る。

    % 或いは、その場で履歴展開としての妥当性を検証して色をつけてしまうという手もある?
    % →これだと正しく解釈されない。例えば履歴展開には $ が含まれて良いが関数名には $ が含まれないので、
    %   先に関数名としての切り出しを実行すると $ の直前で不正に関数名が中断する事になる。

2015-08-14

  * 高速化: ble-syntax/parse: より厳密な shift 範囲の特定・省略?

2015-08-11

  * 今後必要になる大きな書換・再実装は2つある:
    1 コマンドライン着色の効率的方法の模索
    > 2 shift の高速化の為の _ble_syntax_word, etc. のデータ構造の変更

2015-02-24

  * layer の仕組みに対する問題提起

    | 現在の実装では各レイヤーは下のレイヤーが提供した文字配列を弄る事によって動作している。
    | しかし、実の所受け継ぐのは文字配列ではなくて描画属性の配列の方が良いのではないだろうか。
    |
    | o 先ず第一に実装の簡便さがある。
    |
    | o 次に、更新範囲というのは複数のレイヤーで似たような箇所になりがちなのではないかと思う。
    |   属性の配列で渡して置いてから一番最後の所で更新範囲に対して切り貼りをして文字配列を構築した方が良いかも知れない。
    |
    | x ただ、文字配列にするという事の利点も存在する。
    |   region 等の様に大域的に色を一時的に変更する様な物の場合、
    |   文字配列として region の下層にあるレイヤーについて記録を行っておく事は有意である。
    |   選択が解除された時に再び構築し直すというのは時間が掛かる。
    |
    |   但し、その様な動作をする物は限られている様にも思われる。
    |   殆どの場合には纏まった箇所でコンパクトに更新が行われる。
    |
    | x 括弧の対応などの場合、まとめて描画属性から文字列を構築する場合に細かい最適化が出来ない。
    |
    |   複数のレイヤーの描画属性の配列からまとめて文字列を生成する場合、
    |   複数のレイヤーが報告した更新範囲を総合してその範囲で文字列を再生成する事になる。
    |   しかし、括弧の対応など、実際の変更が小規模に渡るにも拘わらず、
    |   離れた二点で実施される色付けの場合には、変更の実体に反して範囲が拡大する。
    |
    |   今迄の様に文字列を各層で構築する方式の場合には、
    |   更新を各層の関数の中で自由に行う事ができるので、
    |   自身の変更の update に関しては最適な方法で更新する事ができる。
    |
    |   とはいいつつも更に上のレイヤーに渡す更新範囲はやはり巨大な物になる為、
    |   上のレイヤーでの合成作業が大域に渡る事は考えておかなければならない。
    |   実のところ合成作業についてはちゃんと実装していない。
    |   region に関しては可能な限り最適な方法になる様に実装したが滅茶苦茶複雑になった。
    |   実際の実装では被覆によって隠される更新などについては考慮に入れなくても良いが、
    |   複雑になりそうだという事に代わりはない。
    |   結局、内部的に描画属性の配列を持って更新に望まなければならないという事態になりそうだ。
    |
    | 何れにしても現在の実装は、今後拡張していく上で非現実的な感じがする。
    | ベースを (下層の情報を含まない) 描画属性の配列を上流に渡す方法に変更した方が良いのではと思う。
    | region 等の実装の際には cache を行う様にする等の工夫をその上で実装する様にしてみたい。
    |
    | また、実装が複雑になるが仕様がない。
    | 取り敢えず現在の所まともに着色を行っている所が syntax だけなので、
    | これを ble-highlight-layer:syntax に対応する上で考えてみる。
    |
    | ble-highlight-layer:syntax の内部で三つの描画属性の配列を用意し、
    | これらの三つの描画属性の配列を総合する事で文字列を構築する様にしてみた。
    | 可もなく不可もない感じの実装である。
    | 少なくとも各層で文字列を構築する様な実装はしたくない。
    | これぐらいが丁度良い実装の複雑さである様に思う。

    将来的には描画属性の配列で対応できる様にする。

2015-02-23

  * bleopt_suppress_bash_output 制限

    - SIGWINCH (ウィンドウサイズ変更) の時に bash の表示する物になってしまう

  * 描画ちらつき: DCH や ICH 等を用いた効率化?

2015-02-18

  * エラーメッセージの設定を可能にする

2015-02-16

  * syntax: ToDo

    - [[ 条件式の文法。より正確に。特に括弧の入れ子。

      →括弧の入れ子というのはどういう意味であったか?
      今試してみた所括弧の入れ子などは関係なく ]] が来れば条件コマンドは終了とみなされる様である。
      例えば $ [[ ( [[ == ]] ) ]] は構文エラーになる。初めの ]] で条件コマンドが終了と解釈される為である。

2013-06-10

  * sword で quote を正しく処理する?
    これは少なくとも解析器が出来た後に考える。

2013-06-01以前

  * ble-decode
    + [kbd] terminfo からの読み取り (entry 名は tmux が参考になる)
    * ble-bind: -s オプションで文字入力の羅列を指定できる様にする (2019-02-10 #D0915 で実装)

  * 説明書
    + 文字コード decoder の追加方法
    + keysequence を指定する文字列の文法 (2018-09-23 done)
    + スタイルを指定する文字列の文法 (2018-09-23 done)

    取り敢えず GitHub の Wiki 上に作る事にした。


*******************************************************************************
    Done (実装ログ)
-------------------------------------------------------------------------------

2021-05-06

  * complete: bash-completion bug workarounds (reported by oc1024) [#D1533]
    https://github.com/akinomyoga/ble.sh/issues/97

    自分の手許でも色々エラーメッセージが出てうるさい。

    bash-completion で修正を掛けるのは面倒だし時間がかかりそう。更に、各種
    distribution に波及する迄に更に時間もかかりそうなので取り敢えず暫定的に、
    ble.sh の側で bash-completion の実装を上書きする事にしてしまう。

  * 2021-04-06 localvar_inherit で動かなくなっている  [#D1532]

    或いは元から動いた事はなかった可能性も?

    * localvar_inherit をしていると local -r a した変数に対して、
      内側の関数で同名の変数を定義できなくなってしまう。

    うーん。それでも未だ色々動かない。というか、バグというかちゃんと書
    かれていないコードを洗い出すのに使えるかもしれないとは思う。

    * どうやら localvar_inherit になっていると local BASH_COMMAND としても
      BASH_COMMAND の値が変化する性質は受け継がれてしまう様である。

      | RANDOM でも同様の現象が発生している。
      |
      | $ f1() { local RANDOM=hello; echo $RANDOM; RANDOM=world; echo $RANDOM; }
      | $ shopt -u localvar_inherit; f1
      | hello
      | world
      | $ shopt -s localvar_inherit; f1
      | 20034
      | 20034
      |
      | 何が起こっているのだろう。元の変数がそのまま見えているという事だろうか。
      | と思ったがそうでもない。unset RANDOM して見たが元の変数が消えるという事は
      | なかった。恐らく localvar_inherit の時には値が受け継がれるのではなくて、
      | setter/getter が引き継がれてしまっているのが原因なのだろうと思われる。
      |
      | bash を確認すると subst.c (expand_declaration_argument) では
      | localvar_inherit が設定されている時には declare は declare -I と同様の振
      | る舞いになる。 declare -I の説明を declare --help で確認すると値と属性を
      | 継承すると書かれている。
      |
      |   if creating a local variable, inherit the attributes and value of a
      |   variable with the same name at a previous scope
      |
      | と思ったが実装をよく見ても inheriting の値が一切使われていない気がする。
      | 不思議である。未実装なのだろうか。或いは何かを見落としている? どうもこの
      | 関数は arr=() の形式の引数を処理する時にだけ使われているという事だろうか。
      |
      | 実際に localvar_inherit の処理を具体的に処理しているのは variables.c の方
      | である様に思われる。特に以下の部分 (variables.c:2738) が setter/getter を
      | 継承するコードである。
      |
      |   if (localvar_inherit || (flags & MKLOC_INHERIT))
      |     {
      |       /* It doesn't make sense to inherit the nameref attribute */
      |       new_var->attributes = old_var->attributes & ~att_nameref;
      |       new_var->dynamic_value = old_var->dynamic_value;
      |       new_var->assign_func = old_var->assign_func;
      |     }
      |
      | 明示的にコピーしているという事を考えるとこれを覆すのは難しいかも知れない。
      | 具体的に変な振る舞いをする例を作ってそれを呈示すれば何か考えて貰えるかも
      | しれない。getter/setter が関わっている関数は他にあるだろうか。
      |
      | INIT_DYNAMIC_VAR で検索するとそういった関数の一覧が得られる。
      |
      | - "SECONDS", (v ? value_cell (v) : (char *)NULL), get_seconds, assign_seconds
      | - "FUNCNAME", (char *)NULL, get_funcname, null_assign
      | - "BASH_ARGV0", (char *)NULL, get_bash_argv0, assign_bash_argv0
      | - "BASH_COMMAND", (char *)NULL, get_bash_command, (sh_var_assign_func_t *)NULL
      | - "BASH_SUBSHELL", (char *)NULL, get_subshell, assign_subshell
      | - "RANDOM", (char *)NULL, get_random, assign_random
      | - "SRANDOM", (char *)NULL, get_urandom, (sh_var_assign_func_t *)NULL
      | - "LINENO", (char *)NULL, get_lineno, assign_lineno
      | - "BASHPID", (char *)NULL, get_bashpid, null_assign
      | - "EPOCHSECONDS", (char *)NULL, get_epochseconds, null_assign
      | - "EPOCHREALTIME", (char *)NULL, get_epochrealtime, null_assign
      | - "HISTCMD", (char *)NULL, get_histcmd, (sh_var_assign_func_t *)NULL
      | - "COMP_WORDBREAKS", (char *)NULL, get_comp_wordbreaks, assign_comp_wordbreaks
      |
      | TERM の場合はどうなっているのだろうか。これは special_vars という事になっ
      | ていて、値が変更した時に特別の関数が呼び出される様になっている。他に
      | TERM* や LANG, LC_* 等様々な変数がこれに相当する。これらは local に関係なく
      | 常に値が変更したら何か処理する事になっているので今回の振る舞いには関係ない。
      |
      | やはり勝手に上書きするのが悪いという結論になりそうな変数しか存在しない。
      | 敢えて言うならば RANDOM か LINENO ばかりだろうか。LINENO の方も確認したが、
      | やはり LINENO に対する代入は無視されて現在の行数が常に表示される様になっ
      | ている。因みに LINENO=1234 eval 'echo $LINENO' に関しては
      | localvar_inherit を設定しても特に変わりなく同名の tempvar が作成される。

      bash のバグか或いは confusing behavior かどうかは別として、古い version
      に対しては取り敢えず修正しなければならないので、対策は行う事にする。時間
      があれば bash に報告・相談もする事にする。

    * もう一つの問題は local -a buff とした後に ble/array#push としていると、前
      の配列の内容が既にあった場合にそれの続きとして値を push してしまうという
      事。こう言った使い方をしている箇所はないと思っていたが、確かめてみると古
      いコードを中心にして沢山あった。と思ったがそんなには無かった。合計で4箇所
      だけだった。

    上記の事を直したら取り敢えず動いている様に見える。残りは具体的に問題が生じ
    てから対処する事にする。

  * 2021-04-28 keymap 初期化に失敗した時にそれを検出しているのにも拘らず操作不能になる [#D1531]

    $_ble_base_cache/keymap.emacs が空の時、The keymap 'emacs' is empty 等の様
    にメッセージが表示されて空かどうかのチェックが為されている筈なのに、その後
    に何も操作できなくなる。

    ble/decode/attach の中でチェックが起こっている気がするが、その場合には
    attach せずに終わって操作不能にはならない筈なので関係ないかもしれない。

    今試しに keymap.emacs を空にして bash --norc から ble.sh をロードしてみたが、
    stty の状態が変になる物の操作不能になる訳ではない。set -o vi でスタートさせ
    てset -o emacs で切り替えようとすると問題が再現する。つまり、detach して
    attach した時の問題である。

    調べてみるとどうもコマンドは実行されている様である。stdout.off の状態になっ
    ている事によって操作できなくなってしまっているという事の様である。そしてそ
    れは、ble/decode/attach の呼び出し元の .check-detach の更に呼び出し元におい
    て、bind/.tail 経由で改めて stdout.off が実行されているという事になる。これ
    を抑制する為に、.check-detach の中で rebind に失敗した時には改めて
    .check-detach を呼び出して抜ける処理を実行する事にした。

    →然しそれでもやはり stdout.off が呼び出されてしまう。と思ったが、どうも
    .check-detach の戻り値を使って実際に detach が起こったかどうかを伝達してい
    る様である。ちゃんと再帰的に呼び出した .check-detach の終了ステータスを外に
    伝播させる。これで問題なく抜ける様になった。

  * 2021-04-06 main (--rcfile): 通常ファイルしか許可していないが [#D1530]

    <() や /dev/null を食わせたい事もあるだろう。後、ファイルが見つからなかった
    時に結局 ~/.blerc を読み取ってしまうのは不便。ファイルが見つからなかった場
    合には何も読み込むべきではない。

    --norc オプションにも対応した。

  * syntax: eval() { echo yes; } が構文エラーになっている [#D1529]
    local, declare も同じ。

    これは意外と簡単だった。処理順序を変えるだけで良かった。builtin の処理と
    keyword の処理が結合しているから切り離すのに時間がかかるのではないかと思っ
    たが、実際には builtin の処理は独立にしても問題ない様な実装になっていた。

  * main: freeze-utility-path が一時実装を置き換えなくなっている [#D1528]

    ble/bin/sleep を初期化する前に sleep の機能についてテストしている気がする?
    と思ったが最初に ble/bin/sleep を絶対パスではなくて command sleep で定義し
    ているので問題は起こらないのだった。というより、最近 freeze-utility-path で
    既存の関数がある時には上書きをしない様に変更したが、これは駄目だ。元々上書
    きする様になっていたのはこの一時的な実装を置き換える為であったのである。

    然し、上書きする様に変更してしまうと freeze-utility が ble/bin/awk を上書きしてしまう。

    a そうすると一時的な実装とそうでない実装を区別できる様に、関数か変数をマー
      カーに使う?

    b 或いは初めからもう定義してしまって呼び出した時点でパスを決定する事にする。
      初期化の順序によっては fork コストがかかる可能性もあるが、
      それも少しだけなので余り気にしなくても良いかもしれない。

      問題は ble/util/assign がちゃんと動作する迄に時間がかかるという事だから、
      ble/util/assign が準備できたかどうかを変数に記録しておけば良いのでは。

    c 或いは ble/util/assign が準備できた時点で .freze-utility を改めて呼び出す
      事にする。直接呼び出しても良いし、それだと密結合になるというのであれば、
      hook か何かを準備しても良い。

    d 或いは今まで通り freeze-utility は上書きをしてしまう様にする。awk に関し
      ては上書きしない様にリストから削除しておくか (然し削除の為にまたコードを
      書かなければならない。初期化時点では ble/array#remove もない)、或いは
      ble/bin/awk.protected か何かの様にして上書きをしない様に関数を定義する。

    うーん。大きく変更するのも面倒なので ble/bin/awk.protected を定義するという
    方針にする。と思ったが関数が存在するかどうかのテストはやはり util.sh を待た
    なければならない。

    ? ok: alias が定義されている時に freeze-utility は正しく動作するだろうか?
      →これは大丈夫。type -P としているから。

2021-05-04

  * util: bleopt/check-all で obsolete な設定も読み取ろうとしてエラーになっている [#D1527]
    obsolete なオプションに対しては初期設定のチェックは行わなくて良い。

  * syntax: 着色決定時に expand_aliases 設定が退避されている (reported by 3ximus) [#D1526]
    https://github.com/akinomyoga/ble.sh/issues/103

    0860be0 に於いて内部では alias が展開されない様に shopt -u expand_aliases
    を設定していた。然し、よく考えてみたら構文着色等に於いて expand_aliases が
    有効かどうかによって処理を変えていた。つまり expand alias の処理の際にちゃ
    んと退避した設定を確認する必要がある。

    実際に修正しようとしたら話はそう単純ではない様である。そもそも自分で shopt
    -s/-u expand_aliases を変更しようとしても完全に無視されてしまう。次のユーザー
    状態になる頃には勝手に元の値に戻ってしまっている。何故? 例えば
    POSIXLY_CORRECT を手で弄っている所為だろうか。或いは expand_aliases の保存
    復元の呼び出しタイミングが混ざっているからだろうか。それとも bind -x の中で
    変更した expand_aliases の状態は抜けると消えてしまうという事なのだろうか。

    やはり自分では何も操作していないのに expand_aliases の設定が変わってしまっ
    ている。うーん。という事は…どうすれば良いのか?

    * 内部で shopt -u expand_aliases にしたいというのは…。毎回 bind head で設
      定し直すぐらいしかできない→ bind/.head で再設定する様にした。

    * ユーザーが設定した設定が保持されないという事に関しては。これは明示的に自
      分で保存復元する必要がある。特に restore する時には shopt -u
      expand_aliases も明示的に実行する。→これは bind/.head で設定する様にした
      ので、わざわざ自分で実行しなくても良い。

    * エイリアスを展開する時に一時的に shopt -s expand_aliases 状態を復元する。
      と思ったが、それでは駄目だった。様々な所で ble/util/type を呼び出していて、
      その結果が alias にならないとそもそも expand-alias 関数自体が呼び出されな
      い。修正するべきは expand-alias ではなくて ble/util/type の方である。こち
      らを修正したら動く様になった。

  * util: test-canvas.sh ext/contra 依存性の解消 [#D1525]

    test-canvas.sh がエラーを出す様になっている。試すとテストを取り入れた時から
    既にエラーになっている。どういう事だろうか。と思ったが、テスト自体が
    ext/contra もしくは contra を前提としていた為に起こっていたエラーだった。存
    在しない時には通る様に書いたつもりだったがそうなっていなかった。

  * awk で {m,n} は使えないという事 [#D1524]
    https://unix.stackexchange.com/questions/354553/awk-repetition-n-is-not-working
    Ref #D1522

    更に nawk, mawk では十六進表記 0xHHHH も使えない。規格的には optional に対
    応しても良いという事になっている様だ。

    更に mawk は match("AAA", /AA?A?/) としても2文字しか一致しない。/A(AA?)?/
    という具合にしなければならない。

    過去の互換性の為であると言っている割に POSIXLY_CORRECT=always を指定しても
    対応するという気配はない。

    →特にこれらに引っかかりそうな箇所は今の所は見つからなかった。然し、
    今後の為にちゃんと記録しておく必要がある→ #M0019 に残す事にした。

  * nawk の方が軽いので既定で nawk を使う様に変えてみる [#D1523]
    Ref #D1522

    gawk 特有の振る舞いに依存している部分を洗い出す為にもこの変更は有用だろう。

    x nawk を使う様にして試してみた所、初期化時に "function" というメッセージが
      沢山表示される → これは nawk とは関係なくて freeze-utility で追加したコー
      ドで既存の ble/bin/??? が定義されているかどうか確かめる type の出力を
      /dev/null に繋いでいなかったのが問題であった。

    x また、use-solaris-xpg4 が他から参照されている。mshex にも
      akinomyoga.dotfiles にも use-solaris-xpg4 はない気がする。何処由来だろう
      か? →これは単に ble.pp に古いコードが残っていただけだった。

    他にも様々な問題が発生した様に思われたが全て最近行われた別の変更によるバグ
    だった。一通り修正できたので改めてテストを行う。取り敢えず動いている様な気
    はする。

  * 2021-03-15 巨大なディレクトリで TAB 補完が遅い (2) (reported by timjrd) [#D1522]
    https://github.com/akinomyoga/ble.sh/pull/65#issuecomment-798551355
    Ref #D1512

    修正したと思ったが依然として時間がかかっている。

    (1) 調べてみると、どうもconditional-sync が終わった後の
      builtin eval -- "$def"
      を実行する時に時間がかかっているという事。

      これを高速化する方法はあるだろうか。というか assign-array では駄目なのだ
      ろうか。と思ったが、ファイル名に改行が含まれている可能性などを考えると駄
      目という事?

    後気付いたのだが、ファイル名に改行が含まれている場合には何が起こるのだろう
    か。source:file はファイル名のチェックをしない様に今回書き換えたが実はこれ
    によって改行が含まれているファイル名の断片も生成される様になってはいないか。
    然し、eval-pathname-expansion で変な分割のされ方をしない限りは問題は起こら
    ないはずである。また、eval を経由して親に結果を渡す事によって、改行を含むファ
    イル名でも対応できる様になっている。

    うーん。eval の中でも時間がかかっている様に思われたが、これも eval するため
    の文字列を構築するのに時間がかかっているという事なのだろう。

    $ files=(*)
    $ time eval ': "${files[@]@Q}"'
    280ms
    $ time eval ': "${files[@]}"'
    216ms
    $ time for a in "${files[@]}"; do break; done
    235ms
    $ time echo ${#files[@]}
    0ms

    これらの結果を見るに、インデックスでアクセスする様にするべきという事か。

    $ time data=("${files[@]}")
    300ms

    a ${files[@]:offset:length} を使って切り分ける?
      →これは遅い。

      $ time : "${files[@]:0:100}"
      72ms
      $ time : "${files[@]:0:1000}"
      77ms
      $ time : "${files[@]:0:10000}"
      89ms

      うーん。これ自体にも時間がかかっている。然し、1000 単位で分割しようとする
      と 200k の場合には全て処理するのに 20s かかる。10000 単位ならば 200k ファ
      イルに対して 2s 以下で処理できるが、元から 200ms かかっていたのが 2s に増
      えるのは微妙な気がする。等の事を考えると、これにかかる時間は仕方がないと
      諦めるべきか。

      →単に ${arr[@]:xx:yy} が遅いというだけの様だ。

    b 直接要素にアクセスする。

      以下の様に直接アクセスすれば、全体を一気に置換した時と比べて遜色のない速
      度が出る。約2倍程度の速度低下で済んでいる。

      $ time for ((i=0;i<200000;i++)); do v=${files[i]}; done
      500ms
      $ time for ((i=0;i<10000;i++)); do v=${files[i]}; done
      29ms


    ? 高速な配列の初期化と言えば history.sh である。結局どの様な方法を用いてい
      たのだったか。やはり eval だったような気もする。確認する。

      うーん cygwin かそうでないかで場合分けしている。Cygwin 以外では mapfile
      を使って読み出している。改行を含む要素に関しては後で補正処理を行うという
      方法を用いている。Cygwin に於いては source している。中では恐らく直接巨大
      な配列のリテラルを指定している。

    $ time x=$(declare -p files)
    72ms

    実は declare -p 自体はそんなに低速ではない。
    現在の実装では quote を ${file[x]@Q} を用いて処理しているが、
    declare -p を用いれば多少の改善はできるかもしれない。

    $ time eval "$(time ret=(*); time declare -p ret)"
    real    0m0.326s
    real    0m0.071s
    real    0m1.345s

    $ cd /path/to/big-directory
    $ time files=(*)
    $ time def=$(declare -p files)
    $ time def=ret=${def#*=}
    $ time eval "$ret"

    具体的に timjrd に計測してもらったがやはり eval "$def" で結構な時間がかかっ
    ている様子である。特に 33k の項目に対して 0.87s かかっている。手元では 200k
    項目に対して 0.40s かかっている。(線形時間を仮定すれば自分の手元では 33k に
    対しては 0.066 で処理できるので余り気にならなかったのだろう。)

    因みに手元では配列のコピーも 0.27s かかっている。これはそんなに長くはないが、
    向こうでは 0.6s ぐらいかかるのだという事を示唆している。つまり、配列コピー
    も気安く行う事はできないのである。

    手元でより高速な方法を模索してみる事にする。

    a eval "$def" の処理時間は 200k 項目に対して 0.40s である。展開と読み取りに
      は 0.67s かかっている。total では 1.07s である。

    b printf '%s\0' "${ret[@]}" で出力した結果を mapfile -d '' で読み取る方法を
      試してみた。結果、読み取りに 0.74s かかっている。実は eval による手法より
      も時間がかかっているという事になる。展開も含めた total の時間は 1.17s で
      ある。total で考えれば手法 a とそんなに変わらないが、中断できないという事
      が問題である。

      更に mapfile -d "" は 4.4 以降でしか使えないので、4.3 以下でも使える様な
      read -d '' による方法の速度を計測してみた所、75s かかった。

      | if ((_ble_bash>=40300)); then
      |   printf '%s\0' "${ret[@]}"
      | else
      | fi
      | if ((_ble_bash>=40400)); then
      |   time ble/util/assign-array0 ret 'ble/util/conditional-sync "$sync_command" "" "" "$sync_opts"' &>/dev/null; local ext=$?
      | else
      | fi 2>/dev/tty

    c source にしたら total 時間を減少させる事ができるだろうか。

    2021-05-01 時間が空いてしまったので改めて現状を整理する。問題は subshell で
    得たファイルリストをどうやって親シェルに伝達するのかという事。500k の文字列
    配列を現実的な時間内に親シェルに伝達し、更に中断も可能である必要がある。

    例を交えて説明するとしたい事は以下の事である。現状で、eval "$(< a.tmp)" が
    遅いというのが問題である。合計時間が長いというのは未だ良いのだが問題はユー
    ザーからの interrupt があった時に中断できないという事にある。

    (
      a=({000000..500000})
      declare -p a > a.tmp
    ) &
    wait $!
    eval "$(< a.tmp)"

    declare -p a の実行自体はそんなに時間はかからない。また mapfile も比較的高
    速である。問題は declare -p a だと eval (遅い) で読み出す必要があって、
    mapfile にする為には要素を printf で出力する必要があるという事。

    a printf '%s\0' / mapfile -d '' (2.5 + 1.6)

      そうだとしても printf '%s\0' で出力して mapfile -t -d '' で読み出すのが一
      番高速でかつ中断可能の気がする。と思って試してみた所、mapfile は -d '' を
      指定した瞬間に遅くなってしまった。どういう事だろうか。最新版 bash でも同
      様である。

    b echo / mapfile -t (3.2 + 0.1)

      この方法は高速であるが代わりに改行を含む様な要素について特別な対処が必要
      である。また時間のかかっている部分での中断も容易である。

      特別な対処を実装したら合計で 3.2+0.1 になった。それでも他の方法よりは高速
      である。これが現実的な解であるような気がする。合計の処理時間は2倍以上になっ
      てしまうが。

    c declare -p a | awk ???

      declare -p を awk で処理する事を考えたが awk には行に含まれる文字数の上限
      があるのではなかったか。本当にそれを正しく処理できるのだろうかという懸念
      は残る。もしそうだとしても物凄く長い行を処理しても処理能力の低下は起こら
      ないのだろうか→文字数の制限が厳しいのは sed 実装だった気がする。POSIX 的
      には awk も制限があったけれども実際の実装ではそんなに問題にならなかったの
      だという気がする。

      読み取りの速度を考えると mapfile-nfix で読み取れる形式に変換するのが良い。
      つまり、declare の parse を awk で行うという事である。declare の形式は
      version によって異なっていたりバグがあったりするが…。

    やはり速度という観点で一番良いのは declare -p a | awk して mapfile-nfix で
    読み取るという物の様に思われる。それとは別に何故 mapfile -d '' が遅いのかと
    いうのは気になる所ではある。

    ? 何故 mapfile -d '' は遅いのだろうか。

      | 確認してみると delim が \n 以外の場合には unbuffered read に切り替える様
      | になっている。何故だろうか。zgetline の実装を見ると delim を引数に受け取
      | る様になっている。更に、zgetline は zread もしくは zreadc を呼び出してい
      | る。最終的に buffered の場合には read(fileno, buf, bufsz) を呼び出して、
      | unbuffered の場合には read(fileno, buf, 1) を繰り返し読む様になっている。
      | 実装を読む限り \n かそうでないかで振る舞いを変更する理由もない様な気がす
      | る。不思議である。理由について尋ねても良いだろうか。
      |
      | Greg に最終的な目標は何なのか。不適切な事を Bash で実行しようとしているの
      | ではないか、という様に文句を言われるかもしれない。その時の為に説明を書く
      | のが良い気がする。
      |
      | get_file_list() {
      |   (files=(*); declare -p files > tmpfile) & bgpid=$!
      |   while :; do
      |     if has_background_completed "$bgpid"; then
      |       eval -- "$(< "$tmpfile")"
      |       return 0
      |     elif has_user_interrupted; then
      |       cancel_everything "$bgpid"
      |       return 1
      |     else
      |       my_sleep 0.1
      |     fi
      |   done
      | }
      |
      | $ a=({000000..500000})
      | $ printf '%s\n' "${a[@]}" > tmp
      | $ mapfile -t a < tmp
      |
      | $ printf '%s\0' "${a[@]}" > tmp
      | $ mapfile -d '' a < tmp
      |
      | builtins/mapfile.def L187..L194
      | > #ifndef __CYGWIN__
      | >   unbuffered_read = (lseek (fd, 0L, SEEK_CUR) < 0) && (errno == ESPIPE);
      | > #else
      | >   unbuffered_read = 1;
      | > #endif
      | >
      | >   if (delim != '\n')
      | >     unbuffered_read = 1;

      これは報告した。

    さて declare -p | awk を実装してみたが遅い。実装している内に気づいたが、awk
    では文字列の途中から一致させる事ができないので、一致範囲を毎回切り出す必要
    があって、これを巨大な文字列に適用すると大変な事になる。今迄の実装で
    declare -p | awk が使えていたのは正規表現で一気に全体を置換するという様な簡
    単な処理しかして来なかった為である。

    →これについては split(s, a, / /) で分割して各要素について処理する様にした
    ら改善した。

    然しそれでも unescape の処理によって格段に時間がかかっている事は確かである
    様な気がする。もっと手っ取り早く変換する事はできないだろうか。例えば "..."
    と $'...' の何れかしか使われないという仮定で単純化できないか等。しかし、例
    えば空白一文字取って見ても " " の内部と、要素と要素の間の " [...]=" を明確
    に区別できる様な正規表現はない様に思われる。或いは "..." 全体に一致する様な
    正規表現を書ければ、特定の文字列を []="..." の直後に挿入して、更にその後に
    その特定の文字列を使って分割する事が可能だろうか。然し、その為には & または
    \1 等による後方参照で元々の文字列を置換後に参照する必要がある。gawk の
    gensub を使えば可能かもしれないが、その儘の awk では難しいのではないだろう
    か→改めて確認した所、

    ? 今試している awk 実装では問題になっていないが、この様な巨大な処理をすると
      なると awk 実装によってはとても遅くなる可能性があるのではないだろうか。

      | →試してみたらそもそも動作していなかった。動かないと思ったらそもそも nawk
      | は {m,n} に対応していない?
      |
      | $ echo '000' | nawk '/[0-9]{3}/'
      | $ echo '000' | mawk '/[0-9]{3}/'
      | $ echo '000' | gawk '/[0-9]{3}/'
      | 000
      |
      | この様な事態になっている。これは大変な事である。つまり、ERE は使えると思っ
      | て書いていると痛い目を見るという事である。更に調べると gawk-3.0 でも
      | --posix または --re-interval オプションを指定する必要があった様だ。
      |
      | https://unix.stackexchange.com/questions/354553/awk-repetition-n-is-not-working
      |
      | gawk であれば --posix または POSIXLY_CORRECT=always を指定すれば良いそう
      | だが、どの道他の実装では使う事ができない。という事を考えると一概に使えな
      | いと思っておくべきである。
      |
      | * 更に 0xHHHH もエラーメッセージなく勝手に 0 と解釈されていた。
      |
      | * また printf("%s\0",line) は普通に \0 が null-terminated と見做されて 0
      |   は出力されない。これは gawk の振る舞いの方が特殊である様に思われる。
      |   printf("%s%c", line, 0) で出力する事にする。
      |
      | * mawk は /[0-9][0-9]?[0-9]?/ としても /[0-9][0-9]?/ になってしまう。

      色々互換性の問題を修正した。見た感じだと nawk も mawk も gawk よりは高速
      である。余り気にしなくても良さそうである。

    ? 更に変な内容がなければもっと高速化できるのではないだろうか。

      例えば全て []="..." の形式だったならば、最初に " []=" を全て他と当たらな
      い様な物 (例えば ^A) に変換して、その後で "" の中身の unescape 処理をして
      から分割すれば良いのではないか。unescape は \\ -> ^B, \" -> ", \$ -> $,
      \` -> `, ^B -> \ とすれば良い。

    取り敢えず新しく実装した ble/util/{read,write}array を使う様に変更してみた。

  * main: ble-reload するとプロンプトの計算の箇所で問題が生じる [#D1521]

    これは当初 nawk のテスト時に気がついた問題なので nawk に関連して生じている
    のかと考えたが、gawk で試しても同様の問題が生じた。

    遡って調べてみると実は 82c5ece で発生する様になった問題の様である。
    取り敢えず bleopt/check-all でエラーが発生しているのかもしれない。
    →これが原因だった。これは独立な問題として commit する事にする。

  * set -o posix の時、ユーザーが read -e を呼び出すと [#D1520]
    何にも動かなくなるのではないか。

    a 然し、read -e 自体が posix の範囲外なので仕方がないという見方もできる。

    b 或いは、set -o posix の時には set -o emacs / set -o vi の切り替えを利用して
      read が使える様に調整するという事も原理的には可能である。その場合には実際に
      bind する対象の keymap が反転するので大幅な改修が必要かもしれない。

      x 然し、vi mode 及び emacs mode に切り替える機能も存在した筈である。これを
        呼び出されると結局 ble.sh の管理下の keymap が前に出てきて問題になる。
        read の中から呼び出された事を検出してどうにかその場で取り繕う事は可能だろ
        うか。

    c 別の方法で read が呼び出される瞬間を検出できないだろうか。或いは read -e に
      よって最初に widget が呼び出された瞬間に POSIX を始めとする様々の設定を回復
      する? その場合には C-c で read をキャンセルした場合にまた元に戻す事を忘れて
      はならない。

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

    →どうやら set -o posix でも本来の意味を取り戻す builtin とそうでない
    builtin が存在する様で、read の場合には set -o poix であっても関数が定義さ
    れていればそちらが呼び出される様である。なので気にしなくて良い。本当に問題
    が起こるのは builtin read -e が実行された時になるが、これは元から動いていな
    かった。

    実の所、builtin read -e に対しても制御を全く失う様な事態にならない様にした
    いが、それはまた別に考えた方が良いのでは? と思ったが、此処での考察はその場
    合にも同様に適用できる→別項目に残す事にした。

2021-04-30

  * 2021-03-21 set -o posix してから source ble.sh すると失敗する [#D1519]

    先に source ble.sh してから set -o posix する分には即座に問題は起こらない。
    然し ble-attach に失敗するという可能性は存在する。うーん。
    関数を新しく定義するという事をしなければ特に問題は発生しない?

    POSIX モードに対する処理は関数の外で実行する事にした。同時に順序を変えて一
    番最初に POSIX モードを ble.sh 内部状態として調整する事にする。

    ? done: 実のところ、enter/leave でユーザーの設定した同名の alias/function
      を保存し、それからまた後で復元するという事も原理的には可能なのではないか

      …と思ったが、果たして其処までの事をする必要はあるだろうか。保存の為にま
      た色々コマンドを走らせなければならなくなるが重くはならないだろうか。と思っ
      たが、alias ... declare -pf ... を呼び出すだけなので実はそんなに処理とし
      て重い訳ではない。問題は alias や declare が勝手に置き換えられていた時に
      ちゃんと動作するのかという話である。

      結局実装する事にした。

    ? done: 現在二段階に分けて unset -f しているが POSIXLY_CORRECT しているのだ
      から、builtin も unset も本来の意味を取り戻している筈で、それならば一回の
      unset -f で十分なのではないか。

    x fixed: 現在 set -o posix, +o posix を使ってモードを切り替えているが、これ
      は setを上書きされていた場合に使えない。直接変数に代入するべきである。更
      に言うと、local ... も使えるとは限らない。local が上書きされているかもし
      れないから。という事を考えると、これも直接グローバル変数の値を変数代入で
      変更するべきである。

      →これは確認した所、元から殆どその様になっていた。新しく追加したコードだ
      けで set を使っていたので、これを全て POSIXLY_CORRECT=y 及び \builtin
      unset -v POSIXLY_CORRECT に書き換えた。また、unset は -o posix の時にだけ
      実行する様に変更した。-o posix の時には \builtin unset は本来の意味で解釈
      される事が保証されているからである。

      ? と思ったが、unset を使って解除する場合には見えている一番上の
        POSIXLY_CORRECT が解除されるだけで、更に呼び出し元のスコープで定義され
        ている POSIXLY_CORRECT が存在した場合には依然として set -o posix のまま
        になるのではないか。

        $ f1() { local POSIXLY_CORRECT=y; f2; echo f1:$SHELLOPTS; }
        $ f2() { local POSIXLY_CORRECT=y; f3; echo f2:$SHELLOPTS; }
        $ f3() { set +o posix; }
        $ f1
        $ f2

        試して見た所、unset POSIXLY_CORRECT だとやはり、更にその上の階層の状態
        が見える様になるだけである。そして、set +o posix も全く同じに作用すると
        いう事が分かった。

        但し考えて見るに ble.sh はトップレベルで動いていてその途中で
        POSIXLY_CORRECT を設定して動作するという事もないので、unset が途中の関
        数スコープの POSIXLY_CORRECT に当たるという事もない。従って、普通に
        unset -v POSIXLY_CORRECT を一回実行するだけで問題ない。

        何か問題が起こるとすれば、ble-attach もしくは source ble.sh を実行した
        時に複数の local POSIXLY_CORRECT=y の中で実行された時である。然し、この
        場合にはどうにも対策の仕様がない。unset -v を繰り返し呼び出す事によって
        POSIXLY_CORRECT を解除する事はできるが、然しこれを実行すると呼び出し元
        で実行した local POSIXLY_CORRECT の意図を壊してしまい呼び出し元で問題が
        生じる可能性がある。

        実はこの事まで考えると set +o posix や set -o posix で POSIX 状態を操作
        するのは不味いのではないかという気がする。呼び出し元で設定した
        POSIXLY_CORRECT の動作を破壊してしまう。

    x posix にしていても eval の中の alias 置換を防ぐ事はできないのでは。
      alias 展開をオプションで無効にする必要があるのではないか。
      そして alias は割とあらゆる箇所で影響が出る。
      これは大丈夫だろうと思っている if や [[ 等も対象である。

      | a builtin に関しては危ない所を全て \builtin 等に書き換えてしまえば問題ない。
      |
      |   grc '(^|[[:space:];|&('\''"])builtin\b' --exclude={wiki,ext,memo}
      |
      | b 或いは shopt expand_aliases を off にして処理を行う? うーん。ble.sh の内
      |   部では expand_aliases を off にするのが良い気がしてきた。
      |
      | c と思ったが ble.sh に影響を与える様な alias だけを off にすれば良いので
      |   あって全ての alias を off にする必要性もない。そして ble.sh に影響を与
      |   える様な物に関しては、ble.sh の処理中には unalias してしまっている筈な
      |   ので殆どの場合は大丈夫な筈なのである。
      |
      |   ユーザー実行環境で ble.sh 関数が呼び出されて、その ble.sh の中で eval
      |   をした時に alias 置換が発生するという状況は考えられるが、まあ、その様な
      |   場合にまで気を配る必要は今の所ないと考えている。
      |
      |   取り敢えず、adjust-builtin-wrappers が呼び出される所までは \builtin の
      |   様にして escape する必要がある。後、adjust-builtin-wrappers 自体の処理
      |   でも対策が必要になる。
      |
      |   * 特に、adjust-builtin-wrappers の中で eval を実行しているが、其処で
      |     alias 展開が起こると問題である。特に ble/util/assign によって実行され
      |     る eval が問題になるのではないか。
      |
      |   後、ble/util/assign の中でも

      結局 expand_aliases を off にする事にした。ble.sh を読み込んで
      expand_aliases を無効にする迄の部分を \builtin の様に quote すれば良い。
      一旦関数を定義してしまえば実行時に書き換わる事はないので、気にしなくて良
      い。気にするべきは eval で実行される文字列 (新しく解析される文字列) であ
      る。

    * resolved: 保存・復元の時に sed を使っているがこれを置き換えられないか。

      | これは ble.sh 読み込み時の最初の最初の部分なので sed が PATH に含まれてい
      | ない可能性も考える必要がある。sed の代わりに使える物はないだろうか。
      |
      | a 例えば extglob を有効にしてパラメータ展開で置換を実行するというのは一つ
      |   の手である。
      |
      |   この方法だと一回 type の出力を変数に格納する必要がある。従って、余分に
      |   $(subshell) を実行する事になってしまって非効率的である。と思ったが、パ
      |   イプにする事によっても subshell が 2 つ余分に生成されるのだから、$() に
      |   しても特に overhead にはならない気がする。
      |
      |   然し extglob を on/off するのはそれはそれでまた面倒である。
      |
      | b どうにかして sed の binary を見つけてそれを先に ble/bin/sed に登録して
      |   しまう? 然し、その為に色々の処理が必要で、その処理を不明な環境で安全に
      |   実行するのもまた面倒である。
      |
      | 後、最初の実行時には注意深い実装が必要かもしれないが、一旦初期化が終わっ
      | てしまえば、ble/bin/sed を使っても良いし、ble/util/assign も軽い実装を利
      | 用する事ができる。いっその事、初めから初期化前用の実装と、初期化後用の実
      | 装に分けても良い気がする。

      汚いが extglob で処理する事にした。

      実際に動かしてみると bash-3.0 で滅茶苦茶遅い。何故だろうか。bash-3.1 では
      特に問題は起きていない。調べてみた所、+([[:lower:]]) とすると遅い。
      +([a-z]) は遅くない。直接書く様に修正した。

    * 現在の待避コードの順序について考える。

      posix だとそもそも ble/* という関数自体定義する事ができない。一旦関数さえ
      定義できてしまえば関数呼び出し自体はできる。

      FUNCNEST の設定。関数定義はできるが関数呼び出しができないという状態だと駄
      目なので。

    * 一応各 builtin について動作確認をしておく。

      builtin, unset, eval はOK
      return, break, continue, local もOK

      % declare は駄目だった。というのも関数定義を抽出するのに使っているから。set
      % -o posix していても declare は回復できないのだという事。うーん。つまり
      % builtin か declare のどちらかは必ず先に unset しないと動かないという事。
      %
      % local の方を諦める事にした。local を上書きしてもローカルに変数が作られる
      % 事になる為、期待した効果を再現する事は不可能になる。なので敢えて上書きし
      % ようという人はいないだろう。declare だと機能を勘違いしている人が上書きし
      % ている可能性がある。また最初の local POSIXLY_CORRECT が効果を失うのも避け
      % たい。

      やはり他にも色々動かない物があるので local を諦めるだけでは済まない。やは
      り builtin の復元を諦める事にする。そもそも builtin を置き換えようとする
      事自体が異常である。何か一つ置き換えを禁止するのだとしたら builtin にする
      のが自然ではある。

      x fixed: : は保存できていない。もしかすると set -o posix の時には declare
        -pf で定義を出力できないという事? 確かめてみたが別にそういう事はない様
        である。という事は逆に定義する時に失敗しているという可能性?

    x fixed: ble-reload 後に ble-detach を実行すると以下のメッセージが出る。

      | bash: builtin: is: シェルのビルトイン関数ではありません
      | bash: enable: is: シェルのビルトイン関数ではありません
      | bash: enable: a: シェルのビルトイン関数ではありません
      | bash: enable: shell: シェルのビルトイン関数ではありません
      | bash: unalias: is: 見つかりません
      | bash: unalias: a: 見つかりません
      | bash: unalias: shell: 見つかりません
      | bash: unalias: builtin: 見つかりません
      | bash: return: is: 数字の引数が必要です

      これを見るに何らかのエラーメッセージがコマンドとして実行されている?

      然し、ble-reload の後に履歴が可笑しくなっているのも、ble-detach の後に変
      な状態になっているのも治っていない。これらはまた別の問題という事か。

      どうも _ble_bash が変な値になっていて、それによって別のコードが呼び出され
      ていたという事。そしてそのコードはちゃんとテストされていなかったので元々
      バグを持っていて、それが発現していたという事の様である。そもそもそのコー
      ドは set -o posix でも動く関数定義取得の為に declare -pf と type を切り替
      えて使っていた物だったが、そもそも関数名が通常の識別子である限りは
      declare -f を常に使っていれば特に問題はない。基本的には declare -f を使っ
      て、: だけは bash の version で切り替える事にした。

      以前使っていた declare -pf / type の切り替えによるコードは以下に残して置
      く。

      | if ((_ble_bash>=40300)); then
      |   builtin local defs
      |   ble/base/adjust-builtin-wrappers/.assign '
      |     \builtin declare -pf "${builtins1[@]}" :
      |     \builtin alias "${builtins1[@]}" "${keywords1[@]}" :'
      | else
      |   builtin local fname
      |   ble/base/adjust-builtin-wrappers/.assign '
      |     \builtin declare -pf "${builtins1[@]}"
      |     \builtin alias "${builtins1[@]}" "${keywords1[@]}" :'
      |   defs=$'\n'$defs
      |
      |   # Note: bash-3.0 だと何故か extglob +([]) の中で [:alnum:] や [:lower:]
      |   #   を使うと滅茶苦茶遅い。何れにしても locale 依存になるのは避けたいので、
      |   #   直接 a-z と書くのが良い。
      |   builtin local pattern=$'\n+([][{}:a-z]) is a function\n'
      |   if builtin shopt -q extglob; then
      |     defs=${defs//$pattern/$'\n'}
      |   else
      |     builtin shopt -s extglob
      |     defs=${defs//$pattern/$'\n'}
      |     builtin shopt -u extglob
      |   fi
      | fi

      さて、これで問題は "何故 _ble_bash が消えて無くなるのか" という事に集約さ
      れる。(履歴の振る舞いが変になるのも古い bash の history -s の振る舞いが変
      だという事と関係しているのだろう。また、C-d の反応が悪いのも関係している
      だろう。)

      実際に _ble_bash が空になっているという事が確認できた。

      そしてそれは何故かというと ble/base/unload-for-reload で _ble_bash を
      unset しているのが原因だった。つまり、unload-for-reload を呼び出す迄は
      _ble_bash 等の初期化は遅延した方が良いという事なのだろう。builtin に対す
      る対策は _ble_bash には頼らずに version 判定するべきなのである。→結局ど
      の bash version でも動作する様に常に type を使って関数定義を得る事にした。

    x fixed: ble-reload すると何故か履歴項目が最後の項目に対する追記の様になっ
      てしまっている。ble-reload ではなくて source ble.sh しても同様の問題が発
      生する。bash --rcfile out/ble.sh としても発生している事を考えると mshex
      等の他の設定との組み合わせで起こっている問題ではなくてそれ自体として発生
      している問題である。

      遡って見ると #D1519 の問題であるという事が判明した。これは #D1519 の下で
      議論するべきであろう。然し、そうだとしても何が原因になっているのかは謎で
      ある。構文着色も動いている様に見えて何だか不思議な動作をしている。原因を
      特定する為に幾つか振る舞いを変えて試してみる必要がある。

      * 保存していた builtins を復元しない様に変更したが特に変化はない。依然と
        して変な振る舞いを続けている。

      * adjust/restore-builtin-wrappers を使わない様にしても変な振る舞いを続け
        ている。

      うーん。コードを見ても怪しい所は見つからない。明らかに機能不全を起こして
      いる箇所があるのだから其処を手掛かりに原因を探る方が懸命である様に思われ
      る。

      ble-detach で発生するエラーについて調べようとしたが原因の設定では再現しな
      い様である。再現する為の条件があるという事か? 或いは ble-detach で発生す
      るエラーに関しては実は adjust/restore-builtin-wrappers が関係しているとい
      う事だろうか。

      これの原因は前の項目で判明した _ble_bash の消滅だという事が分かった。一緒
      に治った。

2021-04-28

  * blerc にユーザーが使いそうな ble-bind を載せても良いのではないか (motivated by Alyetama) [#D1518]

    ble-bind -f up 'history-search-backward immediate-accept'
    ble-bind -f down 'history-search-forward immediate-accept'

    やその他の Vim の説明に書いた ble-bind など。
    magic-space の効果をなくす為の ble-bind も。

  * nsearch の再設計について (motivated by Alyetama, rashil2000, carv-silva) [#D1517]
    https://github.com/akinomyoga/ble.sh/issues/101
    https://github.com/akinomyoga/ble.sh/issues/80

    一旦は bleopt オプションを追加すると書いたが、ここは widget の引数として
    opts を受け取る様にして、readline settings を読み取る時の振る舞いは適当に
    Bash に合わせる様にする方が良いのではないかという気がする。或いは、多少はユー
    ザーが期待する様な振る舞いに調整しても良い。

    * 実際に history 内部を移動するかどうか。現在の振る舞いは history の中から
      "load" するという振る舞いになっているが、本当は isearch と同様に history
      の内部を "移動" するという振る舞いの方が分かりやすい。

      action=load
      action=move

    * 空文字列の時に唯の行移動に fallback するかどうか。
    * 空文字列の時に前回と同じ文字列で検索するという手もある。

      empty=line-move
      empty=graphical-line-move
      empty=logical-line-move
      empty=history-move
      empty=previous-search

      空文字で検索する事はない様に変更する。

    * カーソル位置を何処に置くか。
      point=end
      point=begin
      point=preserve

    * nsearch status を表示するかどうか。
      hide-status
      % hide-status-on-empty

    * 下を押し続けた時にまた元の状態に戻る様にする。
      これはオプションにしなくて良い。

    C-x p 等の時には以下の設定で実行する。

      action=move:point=preserve:empty=line-move

    readline function 経由での呼び出しではできるだけ Bash の振る舞いを再現する?

      action=load:point=preserve:empty=line-move

      % うーん。実は Bash も空文字列の検索に対しては特別の挙動をしている様だ。
      % つまり、今まで議論で一貫性のある振る舞いについて考えていたが、これは既
      % に Bash が自然な形で破っているので Bash に従うべきなのである。

      →改めて Bash を試してみた所、やはり単純に行を移動しているだけではない様
      に見える。カーソルを行末に移動しているが、それによって次の検索内容が変化
      するという訳でもない。実際、ble.sh の実装に於いて、空文字列に対して単に行
      移動の widget に委譲してしまうと、次の up の呼び出しの時に新しくロードし
      た文字列全体に対して再度検索が走ってしまう。

    point=end をリクエストされたが正直これはデフォルトにしなくて良い。
    変更したければ自分で nsearch に point=end を指定して ble-bind して貰う。

    色々考えると実は hide-status-on-empty は実装しなくても良いのではないかとい
    う気がしてきた。理由付けとしては空文字列検索を行うオプションはそもそも存在
    しないから。というか、hide-status 自体表示する必要がないのかもしれないとも
    思った。然し、一応実装しても良い気がする。


    [疑問]

    * ok: isearch に対する疑問。現在履歴位置の古い内容に一致しないのか。

      % よく分からないのは現在履歴項目を遡った状態であった時に、現在の履歴の内容
      % に一致したらどうするのかということである。うーん。isearch はちゃんと遡っ
      % ている時にはその内容に一致している気がする。が、それは何でかというと他の
      % 場所に周遊している時にはその時の編集している内容は履歴に反映させている為
      % である。此処での疑問は、cyclic で検索している時に、現在の編集内容では消え
      % ているが、現在位置の履歴に残っている文字列に一致する場合に何が起こるのか
      % という事
      %
      % →うーん。試そうとしたが isearch で入力している内に最初の方に入力した文字
      %   に一致する項目にジャンプするので実の所、この様な状況が発生する事は滅多
      %   にない。
      %
      % しかし原理的には現在位置の古い内容に一致してしまう事がある気がする。これ
      % を回避するには検索を開始する前に現在の編集内容を履歴に反映させておくか、
      % 或いは、cyclic で検索するにしても現在位置には一致しないようにしておくか。
      % 現在の実装ではどちらかになっているのだろうか。
      %
      % コードを確認した所、気になる部分を見つけた。#D1025 で同様の問題があって部
      % 分的な修正が行われた様に見える。何れにしても基本的には isearch は非
      % cyclic な検索になっているので、そもそも巡回して現在の位置が検索対象になる
      % 事がないので気にしなくて良かった。

      →isearch は現在履歴位置については自分でテストして、それ以外については非
      cyclic な検索で次の項目から検索する様にしているので、現在履歴位置の古い内
      容に一致する事はない。

    [実装]

    * ok: 先ず初めに down を続けた後に元のコマンドライン文字列を回復する機能に
      ついて考える。

      ? そもそも既に history の途中に移動している状態で nsearch を始めた時はど
        うなるのか? →変な振る舞いになっている。#1 から更に down を押したら元に
        戻るべきなのに、改めて上方向に検索して #2 という状態になっている。更に
        付け加えるならば "echo" という文字列には一致しない。

      うーん。元のコマンドライン文字列に戻った時に、nsearch 状態が継続している
      とするか、或いは、nsearch 状態から抜けるか。again または input の時には、
      元のコマンドライン文字列に戻ってしまうのは変である。元のコマンドライン文
      字列に必ずしも一致するとは限らないので。(然し、逆に言えば元のコマンドライ
      ン文字列に一致する場合にはどの様に動作するのが自然だろうか?)

      | ? 現在のコマンド文字列から検索対象を拾った場合には、元の位置まで戻って来
      |   たら nsearch 状態を抜けるのは自然である。と思ったが、それはそれで変であ
      |   る。例えば C-x up で検索を初めて、その後は up/down で移動していた時に突
      |   如として nsearch から抜けてしまうと不便である。という事を考えると
      |   nsearch 状態から抜けるというのは変な話である。
      |
      |   そういう観点から考えると、やはり勝手に nsearch 状態から抜けるのではなく
      |   て、現在文字列に一致している状態にするのが自然である。一方で、stack の
      |   先頭に記録しているのは、現在の一致状態ではなくて、nsearch 開始前の状態
      |   である。
      |
      |   例えば、現在のコマンドラインから検索対象を拾った場合に
      |   は、_ble_edit_nsearch_stack に初めから余分に record を追加しておくのが
      |   良いのではないだろうか。つまり、検索開始時に最初に
      |   _ble_edit_nsearch_stack に検索開始前の状態を保存すると共に、カーソル位
      |   置を point=* で指定したのに対応する位置に初期化してしまう。
      |
      |   と思ったが空文字列で empty=previous-search によって検索開始した時には現
      |   在のコマンドラインに一致しているとは限らない。など考えると明示的に現在
      |   のコマンドラインに一致するかどうかはチェックするべきである。
      |
      | ? input/again の時に元のコマンドライン文字列に一致する場合にどの様に取り
      |   扱うか。これは action=load にしているか action=goto にしているかでも振
      |   る舞いを変えるべきかもしれない。
      |
      |   →input/again でなくても現在のコマンドラインに一致しない可能性があるの
      |   で、これは input/again かどうかの問題としてではなくて、検索が初期コマン
      |   ドライン文字列に一致するかどうかの問題として捕らえるべきである。


      検索開始時点で現在の状態は _ble_edit_nsearch_stack に記録しておく。次に現
      在の行に対して一致するかどうかをチェックして、一致していたらそれも記録に
      残す。そしてその次の一致を調べる。

      うーん。何だか分からなくなってきた。もし現在のコマンドラインだけに一致す
      る時に nsearch をそもそも開始するべきかどうか? という話にもなる。現在の実
      装を確認してみた所、一応 nsearch は開始する様だ。然し、highlight も何も起
      こらない。うーん。これは実は highlight しても良いのではないだろうかという
      気がする。

      じゃあ、input 等で指定された検索対象が現在の内容にも履歴にも見つからない
      場合にはどの様に振る舞うべきなのだろうか。この場合には、選択範囲も何もな
      い状態で nsearch に入るという事の気がする。

      振る舞いとしては (1) 何処にも一致しない場合には現在の内容から少しも動かな
      いが、それでも nsearch 状態には入る。(2) 現在位置に一致して他に一致しない
      場合は、現在位置に一致した状態で固定。 (3) 現在位置にも他の位置にも一致す
      る場合には、他の最初に見つかった位置に移動するが down 等で現在位置に戻っ
      てくる事ができる。(4) 現在位置に一致せず他の位置に一致する場合には、他の
      最初の位置に移動するが down 等で現在位置に戻ってくる事はできない。という
      ので良い気がする。

      この振る舞いにするのであれば別に難しい事はない気がする。単に最初に現在位
      置に一致するかどうかをテストして、一致していたら stack に記録して状態を書
      き換えれば良いのである。

      実装を確認した感じでは現在のコマンドラインの内容は検索で参照しないし、中
      で実際に呼び出している検索処理である isearch も履歴の内容しか参照していな
      い。つまり、現在のコマンドラインの内容に対する一致は呼び出し元でちゃんと
      処理するという前提になっている。という事を考えると、この実装でも現在の内
      容に対する一致は呼び出し元でチェックすれば良い。というより古い内容に一致
      しない様に現在位置の一致は自前でする必要がある。

    * ok: 実装を確認した所、既に opts は受け取る様になっていた。これに色々とオ
      プションを追加すれば良い。

    * done: 空文字列の振る舞いとして単に行移動するだけの実装だと再検索で問題が
      起こるという事が判明した。これの対処方法は二種類ある。

      a 一つは行移動した時に必ず行頭に移動するという事。但し、その場合には検索
        文字列は改行を含まない物として、行頭から抽出するという様に振る舞いを変
        えなければならない。

        問題が起こるのはカーソル位置から検索文字列を取り出す時だけである。でも
        一貫性を考えれば、別に常に先頭に移動するという実装で問題ない気がする。

      b もうひとつの方法はやはり hide-status-on-empty で対処するという事。或い
        は empty=hide-status で良いのかもしれない。

      取り敢えず二種類をオプションで指定できる様にした。

    * done: opts hide-status

    * resolved: 検索対象の文字列を行頭迄にして見たが、実際の検索にはコマンドラ
      インの一番最初からの一致しか考えていないので、自分自身に一致することがな
      い。これは何だか変な気がする。或いは、現在行だけ置換するという手も考えら
      れなくもないが、それはそれで機能として複雑すぎる気がする。やはり、検索対
      象はコマンドライン先頭から抽出する事にして、更に、空文字列 up down の移動
      後もコマンドライン先頭に移動するべきである。という事を考えると、line-move
      というのは変である。history-move しか nsearch とは相容れない気がする。

      →line-move は機能として削除する事にする。

    x fixed: 今気づいたのだが read -e が動かなくなっている。どうも 856cec2 がい
      けない気がする。と思って確認したが別に read -e が動かなくなる様な要因はな
      い気がする。或いはもっと最近の修正が原因だろうか。どうも調べてみた所、最
      新の ble-bind --cursor の commit によって動かなくなっている様である。何故
      だろうか。refactoring で変更漏れがあっただろうか。

      refactoring 関連を確認してみたがぱっと見た感じでは変更漏れはない気がする。
      だとすると何が変わったのだろうか。何処で失敗しているのか read の中に入っ
      て行くべきだろうか。

      →分かった。これは ble/decode/keymap/push が 1 を返す様になってしまってい
      たのが原因だった。push の一番最後の行に [[ $cursor ]] && do something を
      入れた所為で、カーソルが設定されていない keymap/push が失敗する様になって
      しまっていた。カーソルの設定に関係なく 0 を返す様に修正した。

    x fixed: C-x up/down で移動する内に履歴が書き換わっている気がする。これは
      goto と load が入り混じっているからの気がする。ちゃんとその辺りを修正して
      からテストするべきである。

    x 下方向に検索できない状態になっている。というか goto-match で常に backward
      になっているのは変である。

      そもそも検索開始位置は現在の履歴位置とするか或いは末端とするのかという問
      題がある→確認してみた所、一応検索開始位置は現在の履歴位置になっている様
      である。

      ? 検索方向を反転する時に古い履歴内容に一致してしまうのではないか。

        検索開始位置の履歴項目には含まれていた単語を、編集でそれを消した後に検
        索すると、最初の一致が当初の検索方向に離れた箇所で起こる。その時に検索
        方向を反転させようとすると、過去の履歴に一致してしまう可能性がある。

        この時にはどの様に対処すれば良いか。先ず、検索方向の反転は stack の内容
        が1個しか残っていない時に起こる筈である。この時には、検索再開位置は現在
        項目か或いは検索開始項目でより検索再開方向に進んだ物を採用する必要がある。

    * 既定の動作をどの様にするのが良いのかよく分からなくなってきた。そもそも何
      故 nsearch という表示を隠す必要があるのかという事。

      特にカーソル位置を末尾に移動するという設定と組み合わせると、連続して同じ
      コマンドを実行した時には "カーソル前の文字列を検索する" という動作は最初
      の一回だけであり、それ以降には最初の一回で使った検索文字列を繰り返し使う
      という動作になっている。つまり、連続で実行している時には通常と異なる状態
      になっているというのは明らかである。という事を考えるとその事が分かる様な
      表示が必要になる筈である。単に上下で履歴内部を移動するのとは訳が違うので
      ある。

      zsh の振る舞いを調べてみた所、別にカーソル位置を変な所に移動するという事
      はしていない。と思ったが、どうやら history-search-end というモジュールが
      あって、それに history-beginning-search-backward-end 等の様な、末尾にカー
      ソルを移動する様な同じ機能の物が存在する様である。
      https://unix.stackexchange.com/a/97844/121088

      取り敢えず C-x up 等によって使える物については自分の思う様に実装する事に
      する。先ず action=load ではなくて移動。nsearch status は表示する。point
      は現在位置。explicit に呼び出しているのだから空文字列でも普通に nsearch
      に入る。

      readline 経由で up に割り当てている時には。

      a やはり2回 RET して実行されるというのは、保持する。そうすると nsearch
        status も表示して置くのが良い。Bash の元々の動作と思うと action=load は
        保持した方が良い様な気もする。空文字列の時に空文字列で検索するか、とい
        うと微妙。うーん。空文字列の時は history-move が良い気がする。うーん。

      b 或いは bash と完全に同一の動作を目指すのであれば、
        action=load:hide-status:immediate-accept 等と指定すれば良い。が、それは
        それでユーザーが便利にならない。ble.sh の便利さを押し出していきたいので
        あればやはり便利な動作を既定の動作とするのが良い気がする

        hide-status:immediate-accept:action=load:empty=empty-search:point=end

    [Note]

    * 空文字列移動: 行指向の通常移動に fallback する選択肢を考えたが、コマンド
      ラインの途中に移動すると、カーソル前の文字列が非空になるので、続けて移動
      しようとすると予期しない nsearch が始まってしまう。代わりに常に行頭に移動
      して検索文字列を行頭から抽出する様にすると、今度は自分自身に一致しなくな
      るので動作として分かりにくい。

    * C-x up で始めた時は empty=previous-search で良い気がする。うーん。ユーザー
      に入力させた時には空文字列を指定したのに前の文字列で検索が始まったら変で
      ある。なので既定の動作を previous-search にするのは変である。然し、コマン
      ドラインから検索文字列を抽出した時にだけ empty=previous-search にするのも
      分かりにくい気がする。

    [修正]

    x fixed: 描画で一番最後の文字が欠けてしまう。何らかの座標計算が間違っている
      という事だろうか。

      どうも point=end を指定すると振る舞いがおかしくなる。然し、可笑しな事が起
      こる余地などない様な気がする。或いは、_ble_edit_ind の値を勝手に此処では
      変えてはいけないという事なのか、或いは、${#_ble_edit_str} の値がここでは
      大きな値になっているか。

      どうも get-selection によって発生している様な気もする。もしかして空の
      selection range を指定すると発生する現象なのだろうか。試してみると、空の
      range の数だけカーソル位置がずれるという事が分かった。

      分かった。buffer を構築する時に空 range があると "SGR${buff[@]::0}" になっ
      て、これが 0 要素に展開されれば良いが、SGR がある為に 1 要素に展開されて
      しまって、結果として buffer の要素数が増えてしまっているというのが原因で
      あった。そもそも空 range については要素の追加自体を実行しないという形で対
      処する事にした。

      それとは別に空文字列で検索している時には _ble_edit_mark_active を設定する
      必要もない。判定条件を見たら、_ble_edit_ind==end だった時の条件がそのまま
      になっていたのが悪かった。これも修正した。

    x fixed: 最新行が空文字列の時、最新行に空文字列検索で移動できない。これは
      isearch の実装の問題だろうか。或いは最新行が空文字列の時は移動しても登録
      されないという事なのか。或いは isearch の検索範囲の判定で有限文字列化空文
      字列かで振る舞いが変わるという事か。

      →分かった。最新行が空文字列の時に移動しても登録されない事態になっていた。
      dirty かどうかの判定で文字列比較を行って同じであれば処理をスキップしてい
      たが、そもそも登録されていない時にも "空文字列" になってしまうので、"空文
      字列" を登録しようとしても登録されずに終わってしまうというバグであった。
      これは修正した。

    * done: wiki: widget についての説明を書く。これは rasheil2000 への説明を調整して
      乗せれば良い→書いた。

    * done: wiki: Q&A から説明へのリンクを書く→書いた。

    * done: wiki/Q&A: リンクが間違っている物があった→修正した。

    * done: wiki: key bindings について RET, TAB, ESC 等についての説明をちゃん
      と書く。
      https://github.com/akinomyoga/ble.sh/issues/101#issuecomment-828340592

    * done: blerc に何か書いても良いのかもしれない? 或いは Alyetama の言う様に
      wizardを作って其処から設定を選択できる様にする。取り敢えず今は blerc には
      書かない事にする→やはり書いた。

2021-04-26

  * util: 既定の cursor-shape の時には DECSCUSR は出力しない (motivated by jmederosalvarado) [#D1516]
    https://github.com/akinomyoga/ble.sh/issues/95

    % cursor shape を変更しない場合には external/internal の切り替えでも
    % DECSCUSR は出力しない様にするオプション?
    →オプションではなく固定でその様な動作に変更した。

    そもそもその様な実装になっていると思っていたが…。恐らく一番最初の状態が
    unknown になっているのが原因? もし最初の状態が 0 になっていたとして emacs
    mode の場合にはそのまま DECSCUSR が全く呼び出されずに済んだ可能性はあったろ
    うか。

    →実際に試しに最初の状態を unknown から 0 に変更した所、ちゃんと最初のカー
    ソル状態が保持される様になった。

    ? no: 然し、コマンドを実行した後にカーソル形状を元に戻すという操作が強制で
      入っている可能性はあるだろうか?

      →確認してみたが、特に external/internal は意識していなくて、また外部コマ
      ンドがカーソル形状を変化させてしまうという可能性は考えていない。外部コマ
      ンドが停止する時にカーソル形状を戻しておくべきであるという前提に基づいて
      いるのであろう。

      取り敢えずその前提は仮定する事にする。

    条件判定を変更したが、実は初めから値を 0 に設定しておけば同じ動作になるので
    はないだろうか…。此処で実装するべきは空文字列だった時と 0 の区別ではないか。
    と思ったが、0 を意図してブロックとして指定するユーザーがいるかも怪しい。ブ
    ロックであれば 1 を指定すれば良いからである。

    諸々考えると単に初期値を unknown から 0 にすれば良いという気がする。

  * term/edit: keymap 毎のカーソル形状 (motivated by jmederosalvarado) [#D1515]
    https://github.com/akinomyoga/ble.sh/issues/95

    現在の実装では auto-complete, menu 等の mini mode 等でカーソル形状は変わら
    ないと仮定して、emacs, vi_?map の間の変更だけでカーソル形状の再設定を行って
    いる。然し、今後 mini mode におけるカーソル形状の変更も考えると、もっと統一
    的にカーソル形状を管理する必要がある気がする。

    例えば keymap 毎にカーソル形状を設定できる様にして、keymap の切替時に設定さ
    れたカーソル形状に変更する様にする。指定した keymap にカーソル形状が設定さ
    れていない場合は、keymap stack 内の前の keymap を参照する。

    * この時、既存のカーソル形状の設定はどうするのか。

      現在の vi におけるカーソル形状の設定: imap,nmap,omap,xmap,smap,cmap
      ... これらの設定に応じてカーソル形状を変化させる様になっている。然し、実
      際の実装ではこれらの map は参照せずに設定している気がする… と思ったが確
      認したらちゃんと keymap を参照してカーソルを切り替えていた。

      設定の方法は bleopt keymap_vi_?map_cursor を介して行っているが、もし
      keymap 毎にカーソル形状を管理する様にするという事だと、(1) 既存の設定は翻
      訳しなければならない (2) 新しい方法に移行する様に情報を提示する必要がある。

      或いは、bleopt keymap_KEYMAP_cursor を一般に使える様にするという手もある
      が、これはこれで bleopt 内に名称の構造を作成する事になるので避けたい。

    * emacs に対応する。

    ? ok: cursor-state を decode.sh から参照しても依存関係的に問題ない
      か。cursor-state は何処で実装されているか? → util.sh で定義され
      ている様なので大丈夫。

    [変更]

    * done: 設定の変数名を決める ... _ble_decode_KEYMAP_kmap_cursor

      取り敢えずは bleopt_keymap_KEYMAP_cursor を参照して実装する? と思ったが後
      の調整が色々面倒になりそうなので、もうこの時点で変数名も決めてしまう事に
      する。

      元々の keymap の設定は _ble_decode_KEYMAP_kmap_@ に保持している。同様に
      _ble_decode_KEYMAP_kmap_cursor を使おうと考えたが、これだと dump/save で
      記録されてしまうので微妙である。また、どういう設定コマンドで設定するべき
      かという問題もある。

      a ble-bind を使って設定を行う? と思っても直感的に変である。例えば
        ble-bind -m KEYMAP --cursor 5 とか設定する事になる。うーん。そんなに変
        ではないかもしれない?

        後、これの呼び出しも遅延する事にすれば実は dump で記録されてしまう問題
        も気にしなくて良い気がする。KEYMAP に紐付いているという事を考えても、直
        観的に特に問題はない様な気もしてきた。

        この場合には ble-bind -P で出力する時にカーソル設定も出力する様にする必
        要がある。

      a 新しくカーソル設定だけの為のコマンドを用意する? というのもユーザーが覚
        える事が増えるだけで余り良くない。

      c 或いはやはり bleopt keymap_cursor_KEYMAP という感じにして、多少構造化さ
        れた名前の bleopt に変更するに留めるか。

      今は取り敢えず a の方針で考える事にする。

    * done: ble-bind にオプションを追加する。
    * done: ble-bind に於ける遅延初期化について確認する。
    * done: refactor: ble-decode-key/dump 其他。

    * done: 実装する。keymap/push, pop の際に cursor shape を再設定すれば良い。

      % 遡ってもカーソル形状が指定されていない場合には何もしない? 今までに何も
      % 設定されていなければ何もしない。今までに何か特別な物が設定されていた場
      % 合には 0 または空の文字列で DECSCUSR を呼び出してカーソル形状の設定をク
      % リアする。これは実は cursor-shape の側で設定を行っている筈なので気にし
      % なくて良い。

      遡ってもカーソル形状が指定されていない場合はカーソル形状をクリアする。

    * done: keymap_vi_?map_cursor の設定を翻訳する。

      書き換えの指示を表示する事にした。然し、遅延ロードで設定が読み込まれる為
      に表示が乱れてしまう。これに対応する為にはメッセージを受け取った時に表示
      する様にしなければならない。どの様にするのが良いか。或いは invalidate す
      る? と思ったが座標計算のずれまでは解決しない。

    * reject: term_vi_?map についても keymap 側に設定を移行するべきなのではないか。

      然しこれに関しては大して系統的に管理しようとはしていないし、もし何かしよ
      うと思う場合でも __attach__ で実行すれば良いのではないか。ただ
      し、__attach__ はその keymap を push した時にしか実行されない。一方で、
      term は pop して表に出てきた時にも実行する必要があるという点が異なる。そ
      ういう意味で ble-bind --cursor と同様に取り扱っても良いのではないか。とい
      うより、ble-bind --cursor を止めてもっと汎用的な hook を用意する可能性?
      と思ったが、やはり cursor は cursor で管理するのが良い気がする。

      term_vi_?map についてはユーザが設定したい時に利用する物なので、現状の儘
      naive な実装をするままで良い。複雑な仕様にするとユーザーが混乱する。

    * done: vi における動作テストを行う。

    * done: wiki: ble-bind に追記
    * done: wiki: 既存の keymap_vi_?map_cursor を廃止。
    * done: update blerc

  * 2021-04-04 keymap/emacs: emacs mode でも cursor shape を設定できる様にする [#D1514]
    https://github.com/akinomyoga/ble.sh/issues/95

    % keymap/vi と同様に実装した。本来は auto-complete や menu 等の mini mode の
    % 中でカーソルの形が変化することも考慮に入れて、もっと統一的な枠組みでカーソ
    % ルの形状を管理するべきな気もするが、現在は external/internal 及び major
    % mode の切り替えのみでカーソル形状を変更する取り決めにして、直接カーソル形状
    % の設定を各 major mode の切り替えで記述している。
    %
    % 2021-04-26 設定を変更した時に直ぐに反映する様にするには? →取り敢えず
    % keymap/vi と同様にカーソルの形状はトップレベルで決まっていると考えて、基底
    % keymap　が emacs かどうかだけで変更を適用する様にした。然し、既に上の段落で
    % 記述した様に、mini mode 毎にカーソル形状を変更する為にはちゃんと構造化して
    % カーソルを変更する仕組みを整備しなければならない。
    %
    % * 今の暫定実装だと、emacs モード内で vi に移行している時に意図しない動作に
    %   なる。vi は毎回自分の状態に応じてカーソルを設定しようとするとので、emacs
    %   の中で vi に移行していたとしても関係なくカーソル形状を変更してくる。なの
    %   で、emacs 内の vi でも vi のカーソル形状の設定は有効であると考えるべきで
    %   ある。
    %
    %   暫定実装では基底が emacs かどうかで判定しているが、そうではなくて、keymap
    %   stack の内部でカーソルが設定されている一番上の keymap を使って判定するべ
    %   きなのではないだろうか。
    %
    %   これも keymap ベースの判定方法なので、やはり keymap を基準にした実装に切
    %   り替えるべきの気がしてきた。

    この変更は結局 #D1515 の実装に伴ってキャンセルした。一応変更は
    memo/D1503.stub.patch に残しておく。

2021-03-15

  * 2021-03-03 syntax: 実は "${v#...}" の中身も tilde 展開の対象の様である [#D1513]
    https://lists.gnu.org/archive/html/help-bash/2021-03/msg00003.html

    bash-1.14 から bash-dev まで一貫して再現する。
    bash -c 'v=/home/murase/test; echo "${v##~/}"'

    : の後は特に展開対象という訳ではない様だ。変数代入形式の単語でも特に展開は
    しない。つまり本当に先頭に ~ がある時にのみ展開が発生する。

    $ bash -c 'v=x:/home/murase/test; echo "${v##x:~/}"'
    $ bash -c 'v=a=/home/murase/test; echo "${v##a=~/}"'
    $ bash -c 'v=a=x:/home/murase/test; echo "${v##x:a=~/}"'

    序でに、この振る舞いについては実はマニュアルにちゃんと記載されている。

    > In each of the cases below, word is subject to tilde expansion,
    > parameter expansion, command substitution, and arithmetic
    > expansion.

    対象は ${v-w} ${v+w} ${v?w} ${v=w} ${v#w} ${v%w} である。他は関係ない。

    * 他に posix モードに於いては変数代入形式の単語についてチルダ展開は起こさな
      い→これの対策も実装した。OK

  * 巨大なディレクトリで TAB 補完が遅くなる (reported by timjrd) [#D1512]
    https://github.com/akinomyoga/ble.sh/pull/65#issuecomment-798551355

    再現する事ができたので対応する事にする。200k のファイルまたはディレクトリが
    存在する所で TAB を押して少ししてから別のユーザー入力を押した時に直ぐにキャ
    ンセルされない。時には数秒待たされる事もある。現在の実装では補完時に別のプ
    ロセスを使っているので展開自体に時間がかかっているとしてもすぐにキャンセル
    される筈?

    ? 然し、本当にユーザー入力に対して即座にキャンセルするという事にして良いの
      だろうか。ある程度の interval は置くべきなのではないだろうか。と思ったが、
      実際の所、現在の実装で既にユーザー入力がある時にはすぐにキャンセルする動
      作になっていて、単にキャンセルが成る迄に待たされてしまうという動作になっ
      ているという事を考えるとこれは気にしなくて良い。

      →元から即座にキャンセルになる。ただ現状の実装ではキャンセルに時間がかかっ
      ているだけ。

    どうも TAB 補完の時には conditional-sync による実行がされていないのではない
    かという気がする。取り敢えず何処で時間がかかっているかを確認する。

    →絞り込みをかけていった所、ble/complete/source:file に於いて、生成したファ
    イルの存在確認とディレクトリかどうかの確認に時間がかかっていた。

    ? 然しそもそもこの確認は必要なのだろうか。現在の実装では nullglob を設定す
      る様にしているので存在しないファイル名が生成される事はないのではないか。
      やはり確認してみると nullglob を設定しているので改めてファイルの存在確認
      を行う必要はない筈。-e または -h で確認を行っているがこれは全ての生成され
      たファイル名に対して真であると考えられる。従ってこの処理は不要である。

      →特にファイル名の生成の時にはチェックはしない様に変更する事にした。ディ
      レクトリの場合にも予めパターンに / を含めているので、ディレクトリ以外が混
      入するとも考えられない。従って、全て使う事にする。但し、末尾の / は除去す
      る。

    然し、これまでの処理ではファイルの存在確認を全てのファイルに対して再実行し
    ていた。つまり、-d -e -h を実行していた。stat を何度も繰り返す事になるし、
    そもそもループで 200k ものファイルを回していたという事になる。なのに、手元
    の計算機ではかなり短い時間で処理できていた。bash は意外と遅くないという事な
    のだろうか。何れにしても環境によってはこれらのファイルアクセスに時間がかか
    るというのは理解できる。

    実のところこれが本当に報告された問題に関係しているのかは分からないが、少な
    くとも性能の改善はあるだろう。他にも bottleneck があるかもしれないがこれで
    良い事にした。

  * 2021-03-07 bleopt 初期化時に最初から存在する設定をチェックする? [#D1511]

    というのも ble-update や version up に従って設定名が変わるかもしれないから。
    ただ、今までに設定を破壊的に変更した事はないので余り気にしなくても良いのか
    もしれない。

    % その場でチェックをする為にはチェック用の関数が bleopt/declare の時点で存在
    % している必要がある。check 関数が定義されている時にはそれが bleopt/declare
    % よりも前になる様に書き換えていく。
    %
    % x 以下の関数は定義時にちゃんと関数群が存在しているか確かめているが、その関
    %   数群は未だ定義されていなかったりする。これらの初期化順序についてちゃんと
    %     再考する必要があるのではないか。
    %
    %   - canvas: bleopt/check:char_width_mode
    %   - util: bleopt/check:input_encoding
    %
    % 或いは値の設定に関しては ble.sh の基本的な初期化が終わった後に一括してチェッ
    % クを行う様にする? そうすると既定値を何処かに記録しておく必要があるのでは
    % ないか。

    その場でチェックする様にすると dependency injection 的に用意される設定値の
    場合に (オプションを宣言した時点では設定値が登録されておらず、後で各設定値
    が補助関数の定義などを通して登録される場合) 問題が起こる。

    結局、様々のモジュールを読み込んだ後で最後に一括してユーザによって指定され
    た値のチェックを行う事にした。既存の設定に関してチェック用関数の順序を変更する必要はない。

2021-03-09

  * README: uninstall に .cache の事が書かれていない [#D1510]
    書いた。

  * README: 0.3 に関しては release note の側に書いておくべきなのでは [#D1509]
    記入した。0.1..0.3 の情報を書いた。各 Release ページに使い方を記入した。

  * COMPAT complete vs fzf: システムによってロードされた fzf で固まる [#D1508]

    これは . /etc/bashrc を読み込むと強制的に読み込まれている設定である。ユーザー
    が自分で入れた fzf に関しては contrib/fzf-completion を ble-import して貰う
    事によって問題が起こらない様にしているが、システムによってロードされる fzf
    に関しては内容を上書きする隙がない。仕方がないので、core-complete.sh で
    _fzf_* が呼び出された時に contrib/fzf-completion を自動的にロードする様にす
    る事にした。元より bash-completion を勝手に呼び出したりする様にしているので
    他の framework ありきのコードがあっても気にしない。

    これは正直 fzf が tty ではなくて stderr になにか出力しようとするのが行けな
    い。/dev/tty に出力する様にして欲しい物である。

    うーん。 fzf のページを見てもそれらしい物は存在しない。環境変数などで指定で
    きれば良いのだが。man fzf を見てもそれらしい物は存在しない。そういう機能を
    request して見ようと思ったが、考えてみれば自分で fzf を呼び出す時には
    2>/dev/tty をつければ良いだけなので新しい機能として実装する意味がない。ユー
    ザー経由で呼び出しているのであればユーザーにその様に指定する様にお願いする
    べきなのである。

    然し、ble.sh がやっているのは bash progcomp の模倣である。bash の方で問題が
    ないのであれば、ble.sh の方で問題が起こるのは余り良くない。うーん。fzf につ
    いて関数などで上書きして振る舞いを変える? うーん。それだと fzf-xxx の様な派
    生コマンドを使われた時に対処できない。結局 bash progcomp を真似て 2 は tty
    に繋いだ儘にしておくべきなのだろうか。うーん。

    というかそもそも fzf が tty に出力する様にしたとして auto-complete に際して
    期待通りに動くかどうかというのは非自明である。取り敢えず試してみる。
    →試してみた所期待通りに動作しない。やはり fzf の設定をそのまま使うのは駄目。

    ? うーん。実行しても結果が反映されない。COMPREPLY をちゃんと設定しているか?

    ? redraw-line が正しく呼び出されていない。

      % これは恐らく ESC [ が M-[ になって bind されているのが原因。CSI の構築に
      % 失敗した時に M-[ と解釈するべきか或いは ESC [ と解釈するべきかは微妙な所
      % である。然し、CSI を構築する ESC は isolated ESC ではなくて他の文字と一緒
      % に受信した ESC であるべきと考えれば、やはり M-[ と解釈するべきだろうか。
      % そうすると、CSI に失敗した時に 1 byte だけ切り取って ESC を key として生
      % 成しているのを修正するべきである。

      改めて確認した所、そもそも CSI 0 n は認識できないシーケンスとして捨てられ
      ているという事が判明した。

    ? その他の問題として fzf を実行している間は modifyOtherKeys の設定によって
      fzf の操作ができなくなっているという事がある。うーん。実際に端末に作用す
      るかどうか分からないのに補完関数を呼び出す度に端末の状態を変更するという
      のも変な感じがする。

    面倒なので fzf が補完関数の名前に入っている時に限り特別の動作をする様にする?
    取り敢えず、固まったりしない様に調整した。

    % x fixed: CSI 5 n が候補の文字列に結合してしまっている。これは何故だろうか。
    %   COMPREPLY にはちゃんとした候補が入っている…気がする。
    %
    %   →これは compgen の標準出力を読み取って候補としているのが原因。元の
    %   progcomp の -F の場合には標準出力はそのまま端末に繋がっている。それに倣う
    %   様に修正した。
    %
    % x fixed: 候補が生成されない…と思ったら実は CSI 5 n に対する返答 CSI 0 n に
    %   よってユーザー入力に依る中断が入って処理がキャンセルされている。fzf の時
    %   にはどうにかしてこれに対する対策を行う必要がある。
    %
    %   a CSI 0 n を受信しても処理を続行するというのは難しい。何故ならば受信した
    %     段階ではそれがユーザー入力なのか応答なのか判定する方法がないので。受信
    %     して読み取ってから違ったら書き戻すというのも処理としては汚い。
    %
    %   b それなら CSI 5 n がそもそも伝播しない様に抑える必要がある。うーん。幸い
    %     にして CSI 5 n は標準出力に、それ以外のメニューの描画は標準エラーに出力
    %     されている。従って、_fzf* に対しては標準出力を潰す様にするのが良い気が
    %     する。

    色々対策してみたが実はこれらの対策は contrib/fzf-completion.bash と本質的に
    同じであった。fzf-completion.bash を自動で load する方が良いのではないか。

    x fixed: progcomp で単一候補を生成したとしても progcomp 以外に sabbrev も表
      示されてしまって単一確定にならない。うーん。これは _fzf_* で成功して単一
      確定の場合には既に生成した候補は全て削除するという事にすれば良いのでは。
      →既存の候補は消去する様に実装した。

    x そもそも既に入力済みの内容を無視している。normal bash で試してみると、既
      に何か入力済みの物がある場合には fzf による completion は起動しない。空の
      文字列の時にだけ fzf による選択が開始される。

      →これは曖昧補完の為に空文字列で補完候補生成を要求するのが原因であった。
      曖昧補完の時にはそもそも fzf を呼び出さない様に修正した。

  * BUG progcomp: 現在 read に介入して中断する様にしているが [#D1507]

    現在の実装だと

    while read || [[ $REPLY ]]; do ... done

    の様になっていると、無限ループになってしまう。
    中断する時にも引数に指定した変数は全て空にしておく必要がある。

    というより、現在の read の実装は普通に呼び出した時であってもちゃんと変数を
    空にしてくれるのか?

    % そもそも元の read の振る舞いが良く分からない。read line とした時にもう読み
    % 取る内容がなかったとして line が空になるのかと思いきやそうでもない? と思っ
    % たがこれは勘違いだった。試す時に : | read ... とすると subshell の中で値を
    % 設定するので、外側の変数には影響が出なかっただけ。

    うーん。取り敢えず中断の時には内部で </dev/null を builtin read に食わせて
    処理する事にした。option -e が指定されていても /dev/null に繋がっている時に
    は特に readline も起動せずに期待通りに動作する筈。

  * [OK] edit: read -a ARRAY に対応していない? [#D1506]

    と思ったが実はちゃんと対応していた。抑 -a ARRAY は bash-4.0 の時点でちゃん
    と存在している。調べたら bash-2.0 で配列に対応した当初から存在している様で
    ある。

    対応していない様に見えたが実のところ read -e で読み取った結果を改めて
    builtin read で解釈されているので特別に実装しなくてもちゃんと振る舞いを再現
    できているのである。

  * wiki: bleopt openat_base [#D1505]

    現在は実は積極的には使われていないという事。
    また、既に重複して開かない様に対策が為されているという事。

    →どの時点で対策が導入されたか確認しようとしたら実は ble-0.1 の時からちゃん
    と或る程度の衝突回避はある様だった。問題が発生するのは ble.sh が fd を使い
    始めた後でユーザーがそれを上書きしてしまった場合である。この問題は今も依然
    としてある。従って、現在の文章はそのままにする。但し、Bash 4.0 以下でしか使
    われないという事は書いておいて良いだろう。

    wiki を編集した。

2021-03-07

  * progcomp: やはりファイルが大量にあるシステムで遅い (reported by timjrd) [#D1504]
    https://github.com/akinomyoga/ble.sh/pull/65#issuecomment-791932281

    試しに complete -r して見ると発生しなくなる。

    という事は bash_completion が悪さをしているのだろうか。

    * fzf completion も勝手にロードされている。fzf completion の実装が悪いのか
      と思って fzf の completion をロードしない様にしたがそれでも問題は発生する。

    * highlight_filenme= としても特に問題は改善しない。逆に
      complete_auto_complete= として highlight_filename=1 のままの場合には特に
      問題も生じない。着色もそんなに時間をかけずに実行できている。という事を考
      えるとやはり progcomp 特有の問題である様に思われる。

    * bash の progcomp の場合には特に問題は生じていない。という事は -F で呼び出
      した関数を強制的に中断する機能があるのか、或いは -F の関数の呼び出し自体
      にはそんなに処理時間がかかっていなくて後の処理で時間がかかっているという
      事なのか。何れにしても計測が必要になる。

    実際に処理をブロックしているのは以下の関数の呼び出しの様だ。

    $ _minimal 'echo' '' 'echo'

    然し普通に呼び出してもそんなに時間がかかる事はない。

    ----

    _minimal の呼び出しに時間計測をかける。結局 _filedir の中にあるループがいけ
    ないのだという事。うーん。ble.sh の中で実行すると 20 秒も待たされるが、bash
    progcomp から呼び出すと 1.2 秒で終了する。何故だろう。

    実際に候補を bash progcomp 内で生成しているのか確認してみるとちゃんと候補は
    生成されている。

    もしかして read で変な処理をしているのが行けないという事だろうか。でもそん
    なに重い処理はしていない。うーん。オプションの処理をしているが、bash
    progcomp の時にも現在 attach しているかどうかのチェックは行っている。そんな
    に差が開く物なのか。

    実際に unset -f と read() { ble/builtin/read "$@"; } で囲んでみたら 0.6s に
    縮まった。1/60 の時間になった。

    ----

    これに対する対策はどのようにするのが良いか。

    a progcomp で compgen する時だけは unset -f read する? と思ったが、この状態
      で read -e を内部で呼び出されるなどすると変な事になってしまう。

    b decode-detach/attach するのは処理量的に好ましくない気がする。特に
      auto-complete で何度も呼び出されるのに、実際に時間がかかるかどうか分から
      ない処理のために毎回 detach/attach するのは大変。

    c 或いは _filedir 等の各関数に対して .advice around で unset -f read を行う?

    d 或いは read の中に complete_polling_cycle を仕込む。うーん。これが一番
      smart な気がしてきた…。

  * canvas: Kitty が CSI ; r に対して何もしない (reported by timjrd) [#D1503]
    https://github.com/akinomyoga/ble.sh/pull/65#issuecomment-791932281

    抑 CSI ; r にしていたのは DECSLRM CSI ; s に合わせる為であり、DECSLRM を
    CSI ; s にしていたのは、SCOSC と区別する為に引数の数に基づく heuristics を
    用いている為である。CSI r 自体については SUNSCRL と conflict が存在している
    が、SUNSCRL を実装している端末は Solaris console ぐらいしかないだろう。なの
    で、CSI r をそのまま出力しても問題ないと判断する。

    然し、引数の省略をすると動作しないというのは Kitty のバグなのではないのか。
    まあ Kitty の全体的なデザイン等について知らないので、もしかすると Kitty は
    全体的にそういう感じなのかもしれない。何れにしても Kitty の端末エミュレーショ
    ンは元より滅茶苦茶なので気にしても仕方がない。

2021-03-03

  * 2021-02-28 canvas/trace: align=right,center に対応する [#D1502]

    高さについても同様に対応しても良いのかもしれないがそれは必要になってからで
    良い。

    rps1 の各行右揃えに対応しようと思ったが問題がある。範囲計算がちゃんとできな
    いという事。rps1 が横幅一杯に広がれる様にする為には trace の計測開始点は
    x=0 でなければならない。然しこれで measure-bbox すると範囲が x=0..COLUMNS
    になって横幅一杯になってしまう。一方で、rps1 を表示する時には実際に文字が出
    力される範囲を取得したい。これはどの様にするのが良いか。

    a 描画開始点を実際に文字が出力される範囲の bbox の左上になる様にする? 然し
      それは最後まで範囲計算をしないと求められない。一番最後に、出力シーケンス
      の先頭に移動シーケンスをつけ加えれば実装できるが実装が汚くなる。特に右寄
      せしていない場合でも同様の機能を提供する等の事を考えると変である。

      更に、bbox の左上の位置というのが分かりやすいのかも不明である。何故なら呼
      び出し元は配置の結果として何処が bbox の左上になるのかという事を知らない
      からである。これは、呼び出し元で bbox の中身の配置について全く関知せずに、
      一つの blackbox として取り扱うという場合にのみ妥当である様に思われる。

    b 或いは描画開始点を右上にするという手も考えられる。右寄せの場合にはその方
      が自然に思われる。

      b1 計測の時には取り敢えず x=0 にして計測を行って、その後でユーザーが指定
        した (x,y) を起点とした描画シーケンスを構築するのである。然し、その時に
        は左に向かうシーケンス等が何処で壁に当たって止まるのかという振る舞いが
        変わってしまう。

      b2 代わりに unbounded な空間で計測をしてから再配置をするという事を考える
        と、今度は折角計測した内容が実は一行の中に収まらなかったという様な自体
        が生じる可能性もある。然し、これに関しては現在の実装でも似たような物で
        ある。しかし、少なくとも一つのフィールドの幅が行内に収まっていればOK。
        一つ一つのフィールドについて絶対範囲ではなくて幅や高さで制限をかける事
        になるが、それはまた実装が無駄に複雑になってしまう。

    c 或いは measure-bbox で文字列の範囲とカーソル移動の範囲の二種類のどちらを
      計測するか指定する事ができるようにする?

      両方の情報が欲しい場合も考えられるので、x1 x2 y1 y2 に加えて、x1c x2c y1c
      y2c 等を用意する? 少なくともカーソル移動は文字列を包摂するべきである。変
      数が増えるのも面倒なので x1[1] x2[1] y1[1] y2[1] 等の様に配列にしてその第
      二要素以降に値を格納するという考え方もある。然し、これはインターフェイス
      として分かりにくい。

      measure-bbox の振る舞いを切り替えられる様にするというのはやはり問題がある
      気がする。何れにしても両方の情報が必要になるからである。justify で配置を
      する時に出力された文字列の範囲を元にして配置を行うと、端にぶつかった時に
      座標計算がずれてしまう可能性がある。一方で、right align の大きさを調べる
      為には right を表示する必要がある。

    d 行毎に ret x1 x2 y1 y2 x y を算出する。これらの変数を全て配列にする。各行
      の bbox の左上 (x1,y1) を ret の出力開始点とする? (x1,y1) への移動に関し
      ては自前で実行する。その他の align も全て自分で処理する。

      これは微妙。これならそもそも trace に実装する必要もない様な気がする。
      (一応 sc/rc で囲んでいる部分やシーケンスを跳ばすという処理が非自明だが)
      そもそも trace に渡す前に分割して指定していれば良かったのである。

    % 調べて見た所、実は現在の実装は既に文字を出力した範囲の bbox を使う様になっ
    % ていた。という事は…。現在の実装で既に right を指定した時の範囲も表示して
    % いる物の範囲になっているという事?
    % →勘違いだった。ループの最後で記録しているが、これは制御機能によって移動
    % した後でも通過する場所に書かれている。

    表示が乱れる場合の事を考えると right の時には一旦右端に移動してから其処から
    の相対移動で描画するのが良い気がする。これは right の時の特別な取り扱い。

    * 現在の範囲追跡のコードを整理するという可能性。現在は移動を伴わないエスケー
      プシーケンスであっても記録を行う様になっている。これは無駄な気がする。

      また、全てに対して一律に範囲追跡を行っているので、文字列出力のみに対して
      計算する等の事ができない。と思ったが、結局最終的に文字列範囲とカーソル移
      動範囲の両方の情報が必要になるのであれば、文字列出力範囲に関しては独立し
      たコードで実装を行う筈で、これは気にしなくて良い。

    opts measure-gbox として出力した文字列の範囲を計算する事にした。

    * justify の時に最後に jg[xy][12] から g[xy][12] に転写する

    * main-loop の下部の ((w>0)) の処理について

      * 何故折返し処理を此処でしているのだろうか? w として有限の幅を設定する制
        御機能は限られている。調べた所、print+ と単一文字の時の二通りしか無い。
        単一文字に関しては行に収まらない場合には事前に改行を実施している。行に
        ぎりぎり収まる時の振る舞いはどうなっているか。うーん。

      * gbox は此処で処理するべきの気がする。有限幅の文字列がある時には此処に来
        るのだから。というよりこの処理自体を関数にしても良いのではないかという
        気もする。

      * そもそも此処で行っている処理は put-ascii や put-atomic で行うべきなので
        はないだろうか。

      →全て各制御機能及び print の内部で measure-bbox, gbox の処理を行う様に変
      更した。

    取り敢えず rps1 の複数行も実装して動作確認した。OKだと思う。

2021-02-28

  * 2021-02-06 render-defer.idle の優先順位を下げたい [#D1501]

    現在の実装では ble/textarea#render-defer.idle が menu-filter, auto-menu,
    auto-complete よりも先に来ているが、これは後に来るべき。特に menu-filter よ
    りも先に来ないと絞り込み状態の着色がずっと残ってしまう。

    menu-filter を render-defer.idle よりも前に挿入するべきである。どの様にすれ
    ば良いか。

    a 特定の要素の前に挿入するという操作を実装しても良いと思ったが、その為だけ
      に関数を用意するのも変である。それよりはオプションで指定できる様にする方
      が実装としては自然である。その時に挿入点よりも後に詰まって存在している要
      素はシフトする。

    b 或いは初めから各 background の優先順位を指定して登録してしまうという手も
      ある。というよりその方が自然である。どうせ決め打ちになるのでその方が柔軟
      に対応できる。

      現在 background idle (10000+) に登録される処理は以下の通り
      - ble/util/msleep/calibrate
      - ble/textarea#render-defer.idle
      - ble/complete/menu-filter.idle
      - push-background ble/complete/auto-complete.idle
      - push-background ble/complete/auto-menu.idle

    うーん。単に menu-filter を 9999 に登録すれば良い? これが単純で分かりやすい
    対応であろう。

  * 2021-01-31 complete: change bleopt complete_limit default [#D1500]

    実は今回の subshell による実行でしなくても良くなったのではないか。と思った
    が、元の報告だと別にグロブパターンと関係なく遅いという話だった気がする。と、
    思ったが補完の話だったのでやはりグロブパターンというかファイル名補完に関係
    がある。

    うーん。やはり 500 というのは上限としては小さすぎる様な気がする。
    auto-complete の 200 というのも小さすぎる様な気がする。もっと増やしても良い
    のではないかという気がする。5000 vs 2000 ぐらい。というか tab 補完に対して
    制限する必要があるのだろうか。

    ? globpat を含んでいるかのどうかの判定は実は failglob を使った方が早いかも
      しれない。現在の正規表現に基づく実装と速度を比較する価値はあるかもしれな
      い。しかし、../../.. みたいなパスが含まれている可能性等も考えると下手な事
      はできない。

  * [自然解消?] 2021-02-01 complete: slow tab completion after globstar words (reported by 3ximus) [#D1499]
    https://github.com/akinomyoga/ble.sh/issues/82#issuecomment-770390986

    パス名展開を compvar 構築時に全ての単語に対して実行しているのが原因かと思っ
    て#D1457 で compvar 用の timeout を導入してみたがどうも関係なかった様だ。報
    告に依ると globstar の着色が終わった後でも遅いという話だ。これはこちらの手
    元では再現しないという事が分かった。恐らく cache が働いているのだろうと思う。

    2021-02-04 新しい commit で改善したそうであるが、それでもパターンがない時よ
    りも遅いそうである。

2021-02-27

  * canvas/panel: set-height で高さ拡張時にその時の sgr0 が bce で適用されてしまう [#D1498]

    < /dev/tcp/..../80 で赤色になっている時に実行すると赤い行ができてしまう。
    これは sgr0 をせずに set-height を実行する事によって発生している事態である。
    そもそも赤い状態をそのままにして放置している事自体が変なのかもしれないが、
    取り敢えず set-height をする前に sgr0 をする必要はある気がする。

    $_ble_term_sgr0 を出力する様にしてみた。

    しかし、どうも ble/canvas/goto.draw する時にまた $_ble_term_sgr0 を出力する
    様なので、重複してしまう。問題が発生するのは、ble/canvas/goto.draw の時に既
    に目的地にいる場合で、その時は既定では sgr0 の出力も省略されてしまう。
    goto.draw の opts=sgr0 は、例え移動が起こらなくても sgr0 の出力を行うという
    物であった。→方針を変更して goto.draw に sgr0 を指定して其処で強制的に
    sgr0 を出力するという事にした。

  * エラーメッセージ "bash: ((: '0': syntax error:" (reported by rux616) [#D1497]
    https://github.com/akinomyoga/ble.sh/issues/92

    [状況]

    bash: ((: '0': syntax error: operand expected (error token is "'0'")

    * 最近発生する様になったという事。

    * 一度発生し始めると色々なキーを入力する度にメッセージが出るという事。

    * RET TAB BS 及び function keys が全滅。0-9 や numpad key も駄目。
      何故か # や & 等の記号は OK

    これは decoder が関係している気がする→2021-02の変更点を探してみたが特に怪
    しい所はない。

    * 連想配列が配列に化けてしまって発生しているという可能性もある。
      然し、連想配列の添字に quote 付きの文字列を指定する事があるだろうか。
      そもそも連想配列の添字に指定した '' が除去の対象だったかどうか怪しい。
      →試してみた所、どうやら展開の対象の様である。

    最初は発生していなくて途中から発生する様になるというのも不思議な事である。

    再現できた。というか空の blerc でも再現できた。どうも set -o vi だと発生し
    なくて set -o emacs だと発生する様だ。

    bleopt default_keymap=vi でも起きなくなる。
    bleopt default_keymap=emacs; set -o vi だと起きる。
    bleopt default_keymap=safe でも起こらない。

    うーん。emacs.sh の問題かとも思ったが最近変更した内容に関係のありそうな箇所
    は存在しない。だとすると別の場所で発生した問題が emacs.sh の中でたまたま見
    える様になっただけと考えるのが自然だろうか。

    取り敢えずなにかエラーメッセージが出ているという事はその場所を特定するとい
    うのは簡単の筈である。

    | 取り敢えず PROLOGUE と EPILOGUE の間だという事は分かった。decode byte 関
    | 連ではない。home を押しても一組しかエラーメッセージが出てきていないという
    | 事と、keymap safe, vi では発生していないという事から考えるに。だとすると
    | 残っているのは widget 実行辺りなのだが、様々な widget で発生している事か
    | ら __before_widget__ が怪しい。
    |
    | →確かに __before_widget__ だった。特に ble-edit/undo/add の中でエラーが
    | 発生している。
    |
    | % 更に ble-edit/undo/.get-current-state の内部で実行が途絶えている。と思っ
    | % たがそうでもなかった。その次の行の辺りだった。
    | %
    | % _ble_edit_undo_index に整数が入っている筈なのに history という文字列が入っ
    | % ている。と思ったら勘違いだった。_ble_edit_sttr に history という文字列が
    | % 入っているだけだった。
    |
    | やはり .get-current-state だった。調べると _ble_edit_undo_index の中に
    | '0' という文字列が設定されている。これは何処から来るのか調べる必要がある。

    分かった。配列を保存・復元する時に quote-words 的な処理で囲んだ要素を eval
    で評価するべき所が単に split-words で評価していたのが原因。最初は
    quote-words 的な処理にに書き換えたのが原因かと思ったが、逆で eval していた
    所を split-words に書き換えてしまったのが原因だった。つまり、犯人は 5f9adfe
    だった。IFS の調整として分割を全て split-words に置き換えた時に余分に書き換
    えてしまったのが原因。

    修正した。

    * ok: 他に似たような書き換えミスがなかったかどうか確認してみたが大丈夫の様
      である。

    後で改めて見てみたら修正によって破壊している。最近どうも全然駄目だ。毎回修
    正する時に新しいミスを導入にしている。改めて修正した。

2021-02-24

  * Makefile: keymap/*.txt に対する規則を削除してはいけなかった (reported by nihilismus) [#D1496]
    https://github.com/akinomyoga/ble.sh/issues/91

    f25a6e8 が悪い。22日15時過ぎに push したと思うから大体1.5日の間壊れていた事
    になる。これは良くない。修正した。動作確認もする必要がある。

2021-02-23

  * util: vbell で座標計算がずれる [#D1495]

    [状況]

    | 座標計算がずれる様になっている。ble.sh のディレクトリで空コマンドラインで
    | TAB 補完を実行しようとすると、complete_limit に達すると同時に sabbrev 候補
    | の \ が一次挿入される。この時に座標が一つ左にずれる。
    |
    | 8856a04 では問題は起こっていない。3cadd54 では問題が発生している。37363be
    | でも発生している。3cadd54 は ecb8888 に対応する。
    | 取り敢えず問題の commit は 69228fa にあると分かった。
    |
    | * bleopt edit_vbell= にすると問題は発生しなくなる。
    | * visible-bell の先頭で return して実際の処理を行わない様にすると発生しなく
    |   なる。
    |
    | 問題の commit では vbell に対する修正も色々入っている。やはりこの辺りが怪し
    | い。
    |
    | これは sc/rc による問題だろうか。然し、_ble_term_sc= _ble_term_rc= としても
    | 問題は再現している。fork の直前で return 0 すれば問題は生じない。つまり
    | .show 自体の問題というよりは出力が混ざる事による問題の様な気がする。
    | 然し buffer.flush を fork 直前に挿入しても何も効果はない。
    |
    | うーん。タイミングが丁度悪いという事なのだろう。

    あー。分かった。save-position/restore-position しているが、この時に
    _ble_canvas_{x,y} を参照している。然し、これらの値は subshell の中では更新
    されない。これが理由で座標計算がずれてしまうのである。

    [解決法]

    どの様に対策すれば良か。何が問題かと言うと…bottom-dock に対応する為に
    SC/RC を使っていて、それが visible-bell の使っている SC/RC と衝突していると
    いう事。コマンドライン上に居る時には visible-bell の為に SC/RC しても良いが、
    bottom-dock にいる時には visible-bell が SC/RC すると本来のコマンドライン上
    の位置が失われてしまって問題になる。これを防ぐ為に visible-bell では一旦コ
    マンドライン上に復帰してから visible-bell を表示する事にしている。

    どの様に解決するべきか。

    a IPCか何かを使って vbell の状態変化を親シェルに伝達して描画は親シェルで行
      う様にする? 然しどの様に伝達するのが良いだろうか。

      - シグナルは bind -x の内部ではチェックされない (もしくは bash の内部的に
        はチェックされているのかもしれないが対応する trap handler の呼び出しが
        遅延される)。然し、或いはそれでも良いのかもしれない。例えば現在
        bash-3.0 における C-d の読み取りは外部プロセスに行わせていて、C-d を検
        出したらファイルに書き込んでシグナルを送信する仕組みになっている。

      - tty に文字を挿入する事ができれば decode の枠組みに自然にイベントを組み
        入れる事ができるが、実際の所 tty に文字を外部から挿入する事はできない。
        シグナルを

      - FIFO か何かを使って通信するというのはよくある方法だが、現在の実装では
        visible-bell を実行する度に新しくプロセスを立ち上げているので、pipe を
        沢山管理しなければならないので非効率的である。

      - ファイルを使って処理をするという手が考えられる。bash-3.0 C-d でやってい
        る様にファイルに書き込んでからシグナルで通知する。然し、複数のプロセス
        が走っている場合には出力が混ざりあった時に問題が発生する。mkdir 等を使っ
        て同期するという手も考えられなくはないが益々処理が重くなってしまう。

        プロセスごとにファイルを作って処理するという手も考えられる。そして、読
        み取り用のプロセスは一つに絞る事にする。というか実は親プロセスで読み取
        りを実行すれば良いだけの気もする。ファイル書き込み中の同期に関しては、
        現在既に visible-bell でやっている様に複数の状態通知様ファイルを作って
        ファイルが空かどうかで判定する様にすれば良い。

    b そもそも別のプロセスを作る必要があるだろうか。全て親シェルで実行すれば良
      いのではないだろうか。折に触れて状態をチェックしつつ sleep して時間が来た
      ら親シェルが書き換え・消去を行う。

      然し、この方法の問題点は Bash 3.0 である。read -t 0 がないので、ユーザー
      入力が来た事の判定ができない。ユーザー入力があると想定してすぐ抜ける様に
      していると、実際にユーザー入力がなかった時に bind -x による制御が戻ってこ
      ないので、次にユーザー入力があるまで vbell の処理をする事ができなくなって
      しまう。ユーザー入力がないと想定して処理を続けると、vbell が表示されてい
      る間ユーザー入力が処理できなくなって固まった様になってしまう。

      そうするとやはり別プロセスに任せてそれをシグナルで処理するという事になる
      のだろうか。実際の所、シグナルハンドラーの中での処理は色々と怪しい事が起
      こるのでやりたくない。

      複数のサブシェルとメッセージをやり取りする様な一般的な枠組みを整えるのも
      手なのかもしれないと思う。

    c 取り敢えず今まで通り sc..rc が自由に使える前提で処理する

      今まで問題が起こっていなかったのは SC したまま放置される様な状況がなかっ
      たからである。その為いつでも SC...RC を気兼ねなく用いる事ができて親シェル
      の _ble_canvas_{x,y} の状態に依存せずに実装する事ができていた。本当の所、
      タイミングが悪ければ SC...RC が overlap して描画が乱れる可能性は 0 ではな
      いが確率的にはとても小さい筈。というのもシーケンスの書き出しは buffer に
      貯めてできるだけ atomic に行っているので。

      実は現在の所は SC/RC によって bottom-dock を実現しているとは言え、カーソ
      ルを bottom-dock に放置する様な事はしていない。なので、visible-bell の書
      き換えを行う時には常に SC..RC は閉じていると想定して良いのではないか。

    取り敢えず現在は c の方針で回避する事にする。

  * tui: trace に align/justify 機能を実装する [#D1494]

    prompt_status_line に右寄せの内容と左寄せの内容を表示するという需要はある。
    原理的にはユーザーの側で自前で実装してもらう事は可能である。然し、文字幅を
    考慮に入れる等すると実は非自明である。

    * prompt_status_line の中で適当に文字列を分割・計測したりして処理する方法も
      考えたが非効率な気がするし、エスケープシーケンスの中に justify の文字が含
      まれていたり、或いは prompt 展開の結果として justify の文字が現れる場合な
      どにも対応したいと思うとより下流で処理するべきである。

    * また、prompt_rps1 に於いても現在の実装では描画内容全体を一塊として右寄せ
      しているが、各行について右寄せをする様にしたい。

    その様に考えると trace の中で一括して実装した方が理に適っている気がする。

    * justify のデザイン

      | justify 用の文字の幅を保持するかしないかという問題が存在する。空白で
      | justify する場合にはどんなに狭くても空白一個分は開けなければならない。そ
      | うでないと英単語が互いにくっついてしまう事になる。他の制御文字等でフィー
      | ルドを区切る場合にはどうするか。うーん。その場合でも空白一個分は開けて置
      | きたい気がするが、しかし一方で | 等の様な記号を含める場合にはフィールドセ
      | パレータの分の空白があると邪魔なのではないか。
      |
      | 後、間を埋める文字についても指定できて良いのではないかという気がする。つ
      | まり、...... で埋めたり ------ で埋めたりするという事。実際に Emacs は
      | ---- で余分な部分を埋めているし、TeX の目次の様に .... で埋める様な機能が
      | あっても良い様な気がする。
      |
      | 指定方法について考える事にする。例えば、図形文字を sep に指定した場合には
      | 少なくとも 1 文字は其処にあると想定する。間を埋める場合にはその図形文字を
      | 繰り返す。制御文字を sep に指定した場合には幅が狭い時には零幅になる事を許
      | 容する。sep として複数の文字を指定できる様にし、それぞれの sep に応じて振
      | る舞いを変える。
      |
      | この方法の問題点は本文の中に fill 文字と同じ文字がある時に困るという事。
      | そう考えると fill 文字はやはり外部から指定できる様にした方が良いのではな
      | いか。でもそうすると間隔毎に異なる fill を使う事ができない。必ずしも sep
      | と fill を同じにしなくても良い。各 sep 毎に fill を指定できる様にするとい
      | うのも手である。但し、その場合にどうやって引数を指定するのかは謎である。
      |
      | というか空白の時にだけ特別扱いすれば良いだけなのでは。空白で justify する
      | のは英文の場合である。似たような文脈で空白以外で justify するという状況は
      | 考えにくい。

      仕様: 連続する同じ SEP がある時、その数はその SEP によって挿入される間隔
      の weight を表す。同じ SEP が離れて複数ある場合は、その SEP の間の文字列
      をその SEP に対応する FILL と解釈する。例えば SEP SEP -- SEP の場合はこの
      SEP の間隔の weight は 2 で fill は "--" と考える。

      最小間隔は通常 0 であるが SEP が空白の時は特別で 1 である。これは通常の英
      文の様なものを想定した特別規則である。

    実装方法について考える。やはり put-atomic, put-ascii を修正する事になる。
    clip とは相容れない。clip も処理しようと思ったら先に配置を決めておいて、
    その後で再び trace に入れて clip を実行する等という具合にする必要がある。

    clip と同様に出力する文字だけちゃんと配置できれば問題ない。
    その上で気にする必要があるのは "現在の塊" の範囲と、
    span weight である。

    うーん。measure についても justify が設定されている場合には注意が必要である。
    これも clip と同様に最初の実行では justify 用に使用して、後の実行に於いて改
    めて計算し直すのが適切である用に思われる。

    はみ出そうになった場合はどうするべきか。これは confine 等の取り扱いにも依る
    のではないかという気がするが、それらの処理は put-atomic, put-ascii の外側で
    為されている気がするので後で個別に考えれば良い。

    うーん。put-atomic 等の中では実は何も気にしなくて良い気がする。

    * reject: というか sep が図形文字の場合には、最初の各セグメントの幅計測時に
      は取り敢えず sep の幅も考慮に入れても良いのではないだろうか。うーん。やは
      り考慮に入れない方が自然の気がする。

    * done: xI yI を記録する。変数名は jxI jyI 等の方が良いのかもしれない。
      →jx0, jy0 という名前にした。

    * resolved: 現在の実装だとはみ出る場合にどうすれば良いか想定していない。という
      よりはみ出る場合に対して対策する必要はあるのだろうか。そもそも最初の点と
      最後の点だけ記録して、measure-bbox の内容は反映しなくても良いのではないか。
      その方が柔軟に設定できる様な気がする。

      →各フィールドについて初期位置と最終位置だけを元にして配置を決定する様に
      変更する事にした。

      然し、これだと右端を超えて描画されてしまう可能性が排除できない。うーん。
      その場合には適切に shift か clip を行う必要がある気がする。やはり初期位置
      と最終位置ではなくて幾何的に位置を決定する必要があるだろうか。でも、x1:x2
      が初期位置・最終位置の範囲外にはみ出ているという事は元からフィールド間で
      overlap があるという事に他ならないのだから、overlap してしまう事自体は問
      題ないのではないか。

      範囲外に収まらない時にのみ位置を shift するという処置を導入する事にする。
      →その様に修正した。

    * resolved: xenl の問題について。

      一番右端に寄った時に改行してしまう様な端末の場合、下手に一番右まで fill
      してしまうと描画が壊れてしまう。一番最後に出力した文字が右端に接触してい
      る時に改行が起こると想定しても良いかもしれないが、もし描画の途中で複数回
      右端に接触するという様な事があった場合、やはり描画が崩れてしまう。

      xenl のある端末の場合には一番右端まで領域を使ったとしても問題がないのかと
      思いきや、実は相対移動で左に移動しようとした時に結局ずれが生じてしまう。
      基本的に relative で移動している時には右端は使えないと考えるべきなのであ
      る。

      [実装] 然し、status line ではやはり右端まで使いたい。やはり一番右端に接触
      するのは、それぞれの行に於いて唯一回最後だけという想定をして良いだろうか。
      うーん。一応一番最後の位置と x2 が一致しているか確かめて、もしそうであれ
      ば一番右端に一番最後に接触したと想定する事にする。

      →そうするとやはり結局 measure-bbox は有効にする必要がある。

    x ok: ble/canvas/trace/.process-overflow に関しては justify に対して
      opt_relative を入れる事にすれば問題ない筈だが…。うーん。

      これは微妙だ。xenl cap のない端末ではそもそも最後の文字を出力しない様にし
      なければならない。というかそういう観点で言ったら実は、現在の
      opt_nooverflow の実装は駄目なのでは…。xenl のない端末で改行が発生してし
      まう。でも、opt_relative の時には OK である。

      少し xenl の取り扱いについて調整した。

    x ok: 現在の実装では !xenl の時に ble/canvas/trace で無駄な改行が入ってしま
      うのではないか。少し確認が必要である。どの様に検証するか。うーん。

      と思ったが問題の計算をしている所では opt_clip || opt_relative を仮定して
      いたので、そもそも端に接触するという事はないと考えている。なので、勝手に
      新しく改行が挿入されてしまうという心配は要らないという話だった。一方で、
      新しく導入した justify が関係して来る時には何が起こるだろうか。うーん。す
      ぐに .NEL を実行していて、更に .NEL の中では x==cols かどうかについてチェッ
      クしている訳ではないので大丈夫の筈。というか、justify の時には最初に仮想
      的な領域に書き込んでいて、右端で改行してしまう事に関しては後の再配置の時
      に処理する事になっているので気にしなくて良い。そういう意味では、後の xenl
      の処理に関しても同様。

    * done: 他に改行が必要になりそうな箇所を一つずつ探していく事にする。

      * ble/canvas/trace/.put-ascii.draw は justify の時には途中で改行する可能
        性のある動作はしない様にしてある。大丈夫の筈。

      * その他の通常文字(全角)の挿入の場合も範囲に入る時のみに文字列を出力する
        様にしてあるので勝手に改行が発生する事はない筈。

      * done: VT, CR, IND, RI でどの様に処理するのが良いかは微妙。別の行に移っ
        たと見做すのか或いは、また同じ行に戻ってきたら align するのか。というか、
        行った先でまた出力など起こす事を考えると、うーん? でも CR 以外は列番号
        は保持される。という事を考えると水平配置は途切れないと考えるのが自然な
        のではないか。

        VT/IND/RI に関しては何も処置はしない事にする。

        CR に関しては微妙である…。新しいフィールドという事にするか? 然しそれだ
        と指定もしていない sep が有効になっている感じで変である。うーん。jx0 に
        戻るというのが自然な振る舞いの気がする。

      * ok: CUU,CUD,CUF,CUB に関しては相対移動なので同じフィールド内での移動と
        解釈する事にする。

      * ok: HPA,CUP,CHA 等に関しては列番号を直接操作するので水平位置が途切れる
        様な気がする。然し、だからと言って別の行に移る訳でもないし…。これで移
        動しても同じフィールドの中にいるという事にする。

      * done: SC/RC に関してはどの様に取り扱うのが良いか。SC/RC についても
        SC/RC の内部にいる間はsep・改行も含めて特別な処理はしない様にするのが良
        い気がする。

      * done: \1..\2 による保存・復元。これに関しては field を跨いで復元される
        と微妙な感じだが…。うーん。或いは \1..\2 の内部では field の処理は無効
        化する?  それが自然な気がする。これは後で実装する事にする。

    * done: 空白文字の sep については特別扱いする。前の要素に空白文字を含めてし
      まって良い→と思ったがそれだと行折返しが発生した時に行末に余分な単語が含
      まれてしまう。

      ここは単に右に一文字ずらす事で span を最低限保つという方式にした。

      然し、この時の問題点は、他の種類の sep と混合していた時に、必ずしも空白に
      対応する sep に確保した span が割り当てられるとは限らない事。うーん。各
      span に対して "最低限これだけの幅は確保する" という制御は必要になるだろう。
      最初の計測の時点でその情報を参照するのだから、その情報も sep の記録に一緒
      に記録することにするのが良い気がして来た→その様に書き換えた。

    * ok: opt_relative を imply する。opt_measure も imply する。これらは判定を
      flags を用いて行う様にしたい。

      →これらは適当に実装した。

      1 現在の実装では opts=relative -> R, opts=measure-bbox -> M, opts=justify
        -> J を割り当てた。
      2 更に、char flags だと算術式の中で使えないので、別に変数 opt_relative (R),
        opt_measure (M or J) を用意した。
      3 他に、xenl についても opt_relative の時には自動的に imply する様にした。

    * done: $trace_flags == *M* が設定されている時に、範囲を改めて計算する。
      →実装した。

      特に center align している時に範囲を正確に抽出できているか確認する。でき
      ている。OK

    * done: test: フィールドの x1:x2 が範囲外にはみ出る時に正しくシフトできてい
      るか。

      →うーん。右端に一文字余裕を残した実装になっている。これは意図的な物だっ
      たか。確認する。うーん。xlimit が 29 になっている

      % →と思ったらこれは意図的な物だった。範囲を右端にはみ出ているので xenl
      % のない環境では xlimit を一文字減少させている。

      しかしよく考えたら、シフトを実装した今この取り扱いは不要な気がする。つま
      り、xenl のある端末では別に一番右端まで行っても良い。シフトがあるので右端
      を超えてしまう事はない。一方で、xenl のない端末の場合には常に駄目。

    * ok: 行末で begin-line してその後に改行が入るとどうなるのか。
      即座に end-line して空で終われば良し。そうでなければ対策が必要。

      →うーん。その様な状況があるのだろうか。元々何故このような事を考えたのか
      思い出せない。要するに $'\nhello' 等の様になっている時にどうなるかという事?
      この時は空の文字列が作られて終わるだけの気がする気にしなくて良い。

      と思ったが、現在の実装だと空の行に対しても無駄に処理をしている。この辺り
      は最適化の余地がある。取り敢えず justify_fields と DRAW_BUFF の中身を確認
      して空ならそのまま戻る様にした。

    * done: clip している時にも対応する。これの対応はどの様にするべきか。

      a 内部で再帰的に trace を呼び出して二回処理を行う。この時 opts を構築する
        のが面倒そうである。

      b trace の中身の中心部分を別の関数に分けてそれを二回呼び出す様にする。

      思うに殆どの opts は一回描画内容を決定したら継承しなくて良い気がする。
      寧ろ clip 処理は clip だけに徹するべきの気がする。という観点から考えると、
      方針 a に従って後で clip 用に trace を一回実行するのが良い気がする。

    * reject: 改行をしても別のフィールドには移らないオプション? 同じフィールド内で改行
      を行う。その時には xI:y+1 に戻る。

      また、フィールド内での CR はそのフィールドの開始位置に戻るべきでは。と思っ
      たが元からそういう実装になっていた。

      うーん。そういう事をしたければ \r\v 等とすれば良いのではないか。実際それ
      で動く筈。

    x justify:confine が変な動きをしている。一方で justify:truncate は動いている。
      →これは confine の側のバグだった。修正した。

    * done: 空白の時は空白で fill する。

    [追加修正]

    x \r が含まれている時に振る舞いが変である。→これは \r でフィールドの先頭に
      移動した時に追跡座標 x を正しく設定していなかったのが原因だった。修正した。

    o \v の動作については確認した。恐らく大丈夫。IND/RI も試していない
      が大丈夫だろう。

  * 2021-02-06 tui: trace に clip 機能を実装する [#D1493]
    Ref #T0007

    Note: これは元々 tui 計画の一部として実装した物だったが prompt_status_line
    や prompt_rps1 の為の align 実装に使う為に、trace を大幅に拡張したいという
    事で、独立な commit として適用する事にした。

2021-02-22

  * prompt: status line が最初の起動時に表示されていない [#D1492]

    | 何故だろうか。。。うーん。プロンプトが初期化される前だから? でもプロンプト
    | が初期化されたら…うーん?
    |
    | screen の中だと遅れて statusline が表示されるが、contra の中にいると次に何
    | か新しく表示されるまで何も表示されない。そもそもこの違いは何処から来るのだ
    | ろうか。screen の場合には誰かが invalidate しないと再描画がなされない筈なの
    | である。
    |
    | * screen で何故再描画が実施されるのか。調べてみると何らかのデータを受信した
    |   折に screen の中での再描画が走っている。
    |
    |   DA2R を受信した時に再描画が走っているのだろうと思ったがそうでもない様だ。
    |   contra でも DA2R は受信している。また、DA2R を受信してから一拍置いてから
    |   再描画が走っている様に見える。
    |
    |   もう少し詳しく受信しているバイト列を確認する事にする。
    |
    |   % うーん。分かった気がする。screen が CPR に応答した時に char_width_mode
    |   % が変わって invalidate が起こっているのではないかという気がする。contra
    |   % については CPR に応答していないが為に char_width_mode による invalidate
    |   % が起こっていない、という事なのだろう。
    |   %
    |   % →と思ったがやはり CPR ではない様である。先ず contra は一切 CPR に返事を
    |   % しないのは予想通り。一方で、screen はそもそも char_width_mode についての
    |   % CPR 要求はしていない。何故なら char_width_mode に emacs を指定しているか
    |   % ら自動判定にはなっていないのである。代わりに DECSTBM の判定に使っている
    |   % CPR を受信している。然し、その受信した CPR を完全に無視する様に書き換えて
    |   % もやはり再描画は発生しているのである。
    |
    |   再描画が起こっている理由について調べる。$caret_state が変化している事によ
    |   る再描画の様子である。
    |
    |   ? yes: というより本当にこの dirty の判定の所まで到達しているのだろうか。
    |     もっと前の段階て撥ねられていないだろうか。と思ったが、大丈夫の様だ。こ
    |     の判定の部分までは到達している。
    |
    |   caret_state の値について出力して確認してみる。
    |
    |     contra 内部       screen 内部
    |     ----------------  ------------------
    |     old=0:0:0:::      old=0:0:0:::
    |     new=0:0:0:::      new=0:0:0:::
    |     dirty:2           dirty:2
    |     old=0:0:0:::      old=0:0:0:::
    |     new=0:0:0:::      new=0:0:0:::
    |     dirty:clean       dirty:clean
    |     old=0:0:0:::
    |     new=1:0:0:::
    |     dirty:3
    |     chars=(DA2R...)   chars=(DA2R CPR)
    |                       CPR ble/term/t
    |     old=1:0:0:::      old=0:0:0:::
    |     new=1:0:0:::      new=0:0:0:::
    |     dirty:clean       dirty:clean
    |     old=1:0:0:::      old=0:0:0:::
    |     new=1:0:0:::      new=1:0:0:::
    |     dirty:clean       dirty:3
    |
    |   起動の振る舞いを見ると contra の場合には、CPR DA2R の応答を貰うよりも前に
    |   再描画の機会がある様だ。うーん。
    |
    |   ? 不思議な事に keymap_vi_load の実行は比較的最初に済んでいるという事であ
    |     る。もう一つの不思議な事は contra の内部でも dirty:3 が発生しているのに
    |     も拘らず prompt update が実行されていないという点。prompt の update の
    |     条件についても確認するべき気がする。
    |
    |     どうやらプロンプトが更新されたりされなかったりするのは history を読み込
    |     んだり読み込まなかったりする事による物のようである。何故端末が異なると
    |     history の読み込みに影響が出るのかは謎である。しかも、確率的にではなく
    |     て確実にそれぞれの端末で異なる一貫した動作になっているのも不思議な事で
    |     ある。

    [状況]

    最初に描画する瞬間は未だ keymap も読み込んでいない状態なので keymap_vi_load
    を経由して設定される prompt_status_line も表示されない。その後で
    keymap_vi_load が実行され、更にその後で再描画がかかる。

    違いは再描画がかかるタイミングが contra の中と screen の中で何故か異なる事
    によって出てくる様に見える。

    * keymap_vi_load との前後関係は実は関係ない。再描画がかかるのは何れにしても
      既に prompt_status_line が初期化された後の話なので、もしプロンプトの更新
      がかかるのであればどちらの場合でもちゃんとステータスラインが表示される筈
      である。

    * 代わりにコマンド履歴の読み込みのタイミングとの前後関係が問題になっている。
      screen の中では DA2R, CPR を受信した後に再描画が起こるが、この段階でコマ
      ンド履歴が読み込み済み状態になっている。これにより再描画に際してプロンプ
      トの再計算が実施される。一方で contra の場合には DA2R を受信する前に再描
      画がかかって、この時には未だコマンド履歴が読み込まれていない。この為に、
      プロンプトの更新の必要がないと判定されてプロンプトの更新無しで再描画だけ
      が行われている。

    何れにしても設計としてはプロンプトの設定を変更したら ble/prompt/clear を実
    行するべきで、更に、ble/prompt/clear を実行する時には
    ble/textarea#invalidate も実行するべきという事。

  * global: IFS 対策 [#D1491]

    多くの関数は IFS が普通の値になっているという事を前提にして書かれている。
    ble.sh の中では一時的に IFS を設定して動作する様になっているが、
    ユーザーから使用された時に IFS に変な値が設定されている可能性は排除でいない。

    * 引数を $* で渡された時の対策は取り敢えず grc -F で ${* もしくは $* に一致させて確認した。
    * 配列に対する単語分割 =($...) に関してもチェックは行った。

    * 他に配列を結合する処理に関しても注意が必要になる可能性がある。
      つまり、aa="${arr[*]}" の形の処理である。

      grc '\$\{[[:alnum:]_]+\[\*\]' --exclude={test,ext,wiki}

      取り敢えずこれも大体対応した。

    * builtin read も IFS に依存して振る舞いが変わる。

    他にも IFS が影響を与える様な状況はあるだろうか。恐らく他にもあると思うが、
    すぐには思い浮かばないので取り敢えずこれぐらいで良いだろう。

  * global: 現在様々な関数が引数として text... を受け取っているが [#D1490]

    実の所複数の引数を受け取る事に意味は余りない。
    実際に複数の引数をこれらの関数に渡している箇所があるとは思えない。
    現在は毎回 IFS を設定してこれらの引数を結合する様にしているが、
    そもそもその様な処理すら必要ないのではないか。

    * done: (main) ble/util/put
    * done: (main) ble/util/print
    * done: (util) ble/string#escape-*
    * done: (util) ble/string#{toggle-case,toupper,tolower}
    * done: (util) ble/string#[lr]?trim
    * done: (util) ble/string#capitalize
    * done: (util) ble/util/buffer
    * done: (util) ble/string#split-lines
    * done: (util) ble/util/idle.push
    * done: (vi) ble/keymap:vi/string#encode-rot13
    * done: (complete) ble/complete/cand/yield
    * done: (canvas) ble/canvas/put.draw
    * done: (edit) ble-edit/hist_expanded.update
    * done: (edit) ble/widget/(in|ex)ternal-command
    * done: (edit) ble/widget/execute-command

  * global: ロード時にエラーが出る (reported by 0neGal) [#D1489]
    https://github.com/akinomyoga/ble.sh/issues/85

    bash: ((: 4 0: syntax error in expression (error token is "0")

    うーん。 "4 0" という文字列が何処から混入するのかという事。
    "4 0" という文字列があるという事は何処かにそういう変数が存在しているという事?
    と思って declare -p の結果を grep で検索して 4 0 の組み合わせを探そうとしたが見つからない。
    配列に、要素を跨ってその様な値が格納されているのかとも思ったが、そうでもない。

    だとするとグローバル変数ではなくて内部で一時的に生成された文字列に問題が起きているという事?

    ((${#aaa[*]})) となるべき所を ((${aaa[*]})) にしてしまっているというのが怪しい。
    と思ったが m scan で引っ掛からない。
    sub:scan/array-count-in-arithmetic-expression でちゃんとチェックしている。

    3588158 で発生している。前に動いていた時はいつの version かと思ったが、
    どうも 0.3.3 を動かしていた様なので実は 0.4 でも前からずっと問題があった可能性もある。

    うーん。エラーメッセージから察するに "4 0" が完全な算術式として評価されよう
    としているという事。これにより ((...)) の形のコマンドで発生しているとすると
    かなり発生箇所を制限する事ができる。

    | ./lib/core-complete.sh:2847:      ((${simple_ibrace%:*})) && comps_fixed=1
    | ./lib/core-complete.sh:3282:      if ((${simple_ibrace%:*})); then
    | ./lib/core-complete.sh:3293:      if ((${simple_ibrace%:*})); then
    |
    |   simple_ibrance に値を設定している箇所は限られている。そしてその何れの場所
    |   でも確実に 数字:数字 の形になっているので、変な事が起こる余地はない。
    |
    | ./src/canvas.sh:1725:    (($3)) && ((x=0,y++))
    |
    |   ble/textmap#hit/.getxy.cur の第三引数…ではなかった。ここでは textmap 配
    |   列に含まれる単語を分割している。もしかして IFS に変な値を設定されていると
    |   いう事? と思ったがその影響が残っているのだとしたらもっと色々な大変な事が
    |   起こってしまう筈。そして実際に IFS= にして起動してみたが特にエラーメッセー
    |   ジは出ていない。
    |
    |   もう一つここが違いそうな理由は、報告によると起動時のみに問題が起こるとい
    |   う事であった。然し、もしここが本当に問題になるのだとしたらそれ以降もずっ
    |   と危ない感じになる気がする。
    |
    |   何れにしてもこの部分はもっとまともな実装に置き換えて良い気がする。
    |
    | ./src/color.sh:955:    (($name)) && return 0
    |
    |   name=_ble_faces__$1 としているので此処からは '4 0' という値は出てこない。
    |
    | ./src/util.sh:3244:    (($2))
    |
    |   これは ble/util/test-rl-variable の第二引数である。使用箇所を確認したが第
    |   2引数はそもそも指定していないか指定していたとしても 1 か 0 である。なので、
    |   これも違うだろう。

    然し、変数に alpha='4 0' 等の値が入っていてそれを ((alpha)) 等として実行し
    た場合にも同じエラーメッセージが発生するので本当にこの部分で発生しているの
    かというのは分からない。一方で $(()) の中で実行した場合にはエラーメッセージ
    が異なる物になるので、やはり (()) の中で発生しているというのは確定して良い。

    もしかすると bashrc の内部で ble-attach すると問題が発生する可能性?

    できた。再現できた。IFS= を ble-attach の直前に記入すると問題が生じる。

    どうやらコメントに依ると unset IFS にしている様である。という事は…。ble.sh
    をロードした時に unset 状態の IFS を保存して復元する時に空文字列になってし
    まうのが問題の原因になっている。

    * done: IFS の unset 状態も復元する様にする。復元する様にした。

    更にその後で空文字列の IFS が問題を引き起こしている。掘り下げていくと
    textarea#redraw の中で問題が発生している。

    * done: 空の IFS でも単語分割ができる様に個々の関数を書き換える。

      * 結局 ble/textmap#getxy.cur の問題だった。先に上で修正したと思っていたが
        修正漏れがあった。これで動く様になった。

      * 他にも IFS=$' \t\n' でないと動かない様なコードはないだろうかと調べると
        ble/canvas/trace の sc/rc がそれだった。修正した。

      * 他にも ble/textmap#update の中でも単語分割を使っている様子だったが、こ
        れは関数の先頭で IFS を設定しているので問題にならない。
        ble/string#split-words で書き換えようと思ったが performance の問題だろ
        う。そのままにしておく事にした。

      * 他のファイルも探したら沢山あったのでこの際全て修正する事にした。他にも
        IFS の値で振る舞いが変化する物は沢山あるのでこれだけで local IFS=$'
        \t\n' しなくてよくなったりはしないが、念の為変な動作を起こさない様にし
        ておく。

    x fixed: 全部直した筈だと思ったが ble-bind がエラーを出力している。
      →"$*" の類も全て IFS を気にする必要がある。取り敢えず util.sh の関数については
      IFS の値に拘らず動作する様に修正した。

  * keymap/vi: vim mode strings の設定をもっと柔軟にできる様にする (motivated by 0neGal) [#D1488]
    https://github.com/akinomyoga/ble.sh/issues/85

    Note: 0neGuyDev は名前が 0neGal に変化した様だ。

    * done: wiki vim のページ hook の説明で := の : が余分。
    * done: wiki vim の設定のページで全ての項目に注意書きを書く。

    何れにしても Cygwin での IL/DL の問題 (#D1482) に取り敢えずの決着をつけてから。
    →IL/DL の問題を解決したが未だ status line の問題 (#D1487) は残っていた。
    その後 status line の問題も解決した。

    どうやら Vim では mode() を用いて現在のモードを表現する文字列を取得する事が
    できるらしい。然し、mode() だけでは表しきれない情報も存在する様である。取り
    敢えず似た関数を用意さえすれば既存の枠組みを使って mode を status ilne に表
    示する事ができるのではないか。

    | Mode                                                                                          | `mode()` |
    |:----------------------------------------------------------------------------------------------|:---------|
    | INSERT                                                                                        | i        |
    | REPLACE<br/>VREPLACE                                                                          | R        |
    | NORMAL<br/>(insert)<br/>(replace)<br/>(vreplace)                                              | n        |
    | VISUAL<br/>(insert) VISUAL<br/>(replace) VISUAL<br/>(vreplace) VISUAL                         | v        |
    | VISUAL LINE<br/>(insert) VISUAL LINE<br/>(replace) VISUAL LINE<br/>(vreplace) VISUAL LINE     | V        |
    | VISUAL BLOCK<br/>(insert) VISUAL BLOCK<br/>(replace) VISUAL BLOCK<br/>(vreplace) VISUAL BLOCK | ^V       |
    | SELECT<br/>(insert) SELECT<br/>(replace) SELECT<br/>(vreplace) SELECT                         | s        |
    | SELECT LINE<br/>(insert) SELECT LINE<br/>(replace) SELECT LINE<br/>(vreplace) SELECT LINE     | S        |
    | SELECT BLOCK<br/>(insert) SELECT BLOCK<br/>(replace) SELECT BLOCK<br/>(vreplace) SELECT BLOCK | ^S       |

    これらは基本的にはそのモードに入る為に使うコマンドが使われる。
    然し、normal の n や select の s は名前から来ている。

    これに倣えば。拡張するとしたら VREPLACE は gR になるだろうか。
    insert, replace, vreplace は それぞれ i^O R^O gR^O になる。
    でもどうせ組み合わせるのであれば、実の所 ^O は必要ないのではないか。

    つまり、/(i|R|gR)?(n|v|V|^V|s|S|^S)?/ - ε (4x8-1=32-1=31種) という事になる。

    うーん。サンプルを見ると Rv というのが存在しているが実際に試してみると R に
    なっている。何故だろうか。後、やはり gR というのは都合が悪い気がする。
    vreplace の文字はまた別に考えたい。小文字の r を考えたがどうやら既に PROMPT
    というのの為に使われている様だ。だとすると ^R という事になるだろうか。うー
    ん。取り敢えず ^R という事にする。そもそも制御文字を使うとうのが良い事なの
    か微妙だが。RSTUV で何れも近い値というのも比較的良い事の気がする。

    * テストに用いた vimrc を移動する。

  * edit: prompt_status_line の表示が崩れる [#D1487]

    | prompt_status_line を試しに組み合わせて見たら表示がおかしくなっている。うー
    | ん。status の報告する文字列の高さが間違っているのが原因かとも思ったがそうで
    | もない。常に高さ1を強制する様に書き換えてみたがそれでも同じ問題が発生してい
    | る為である。
    |
    | という事はスペースを確保する時のコードが間違っているという事だろうか。これ
    | は丁度 stub branch で議論している物と関係する。というより stub branch の方
    | で何か修正を入れた気がする。その修正を適用してからこの問題が未だ継続してい
    | るか調べてその上で対処するべきだろう。
    |
    | →どうやら問題は継続している様だ。何故だろうか。なぜか知らないが高さを確保
    | できていないのが原因である。

    [再現]

    prompt_status_line を表示してかつ keymap_vi_mode_show= を使って vim mode
    string を表示しない設定にすると、一番下の行でコマンド実行した後に status
    line が消去されずに複製されて残ってしまう。

    振る舞いを調べると高さの確保は一応している様子である。毎回 1->2 に増やして
    いる。コマンドを実行した直後には高さ 1 という事になっている為であろう。然し、
    問題点が幾つかある

    * コマンド実行中にはステータス行は消去する筈なのに消去されていない。うーん。
      実装によるとコマンドを実行する前に ble/prompt/status#collapse を呼び出す
      事になっている。そして其処では set-height を用いてステータス行を消去する
      事になっている。然し消去できていない。

      調べてみるとそもそも status#collapse が呼び出されていない?? いや、これは
      呼び出されている。という事は set-height の途中で消えているという事であり、
      それはつまり元から高さが 0 だったという事。高さが増える事なく status line
      が表示されていたという事である。

    うーん。何かと思ったら reallocate-height.draw が呼び出されていない。現在の
    実装では他のパネルの高さが不整合になっていない限り reallocate-height.draw
    は呼び出されないのである。うーん。取り敢えず status#panel::render の中で
    reallocate-height.draw を試みるべきだろうか。

    status#panel::render の中で現在の高さを確認して足りなければ再配置を要求する
    様に変更した。これで OK の筈。これによって textarea の方に皺寄せが行く可能
    性もあるが、取り敢えずはこれで良い事にする。また後で reallocate-height につ
    いては考え直すのが良い→別項目を立てた。

  * decode: rlfunc.txt ファイルを移動する [#D1486]

    * .srcoption の中身も更新した。
    * GNUmakefile も書き換えた。
    * decode.sh も書き換えた。
    * 他に make_command.sh と vi.sh の中で言及していたファイル名を書き換えた。
    * 序でに散らばっていたテスト用のファイルをリポジトリに追加しておく。

  * term: screen で attach した時に時々 _ble_term_* が壊れる現象 [#D1485]

    screen で attach すると何故か色々壊れる現象があったが、どうも contra からの
    DA2R がそのまま screen の内部の shell に伝播しているという事の気がする。
    DA2R を受信した時に最初に受信した時の値を保持する様にするべきではないか。
    もしくは一旦受信したら blehook で削除しておく。

2021-02-21

  * decode (rlfunc): vi-replace in imap, vi-editing-mode in nmap (reported by onelittlehope) [#D1484]

    それから vi-replace in imap 及び vi-editing-mode in nmap は未実装である。

    * vi-editin-mode in nmap: 先ずは vi-editing-mode を vi-command で使うと何が
      起こるのかについて確認する。→どうやら vi_nmap を抜けて imap に戻る様であ
      る。うーん。これは単に vi_nmap/insert-mode にすれば良い気がする。

    * vi-replace はどうやら replace-mode に入る為のコマンドの様だ。そしてこれは
      insert と同じで良いのではないか?? と思ったがうーん。vi-command では "R"
      に割り当てられている。つまり、文字幅に応じた replace-mode に入るべきであ
      る。

      | vi_imap でも同等の replace-mode に入るための widget を追加するべきだろう
      | か。と思って、vi_imap/normal-mode-without-insert-leave &
      | vi_nmap/replace-mode を組み合わせて新しい widget を作りかけていたら、どう
      | やら既に存在していた様だ。vi_imap/overwrite-mode である。というより、既定
      | の insert がこれになっていた。
      |
      | なので作りかけた以下の関数は廃止。
      |
      | function ble/widget/vi_imap/replace-mode {
      |   ble-edit/content/clear-arg
      |   _ble_edit_mark_active=
      |   _ble_edit_overwrite_mode=R
      |   _ble_keymap_vi_insert_overwrite=R
      |   ble/keymap:vi/update-mode-name
      | }

      所で、既存の vi_imap/overwrite-mode は ble-edit/content/clear-arg がない
      が良いのだろうか。と思ったが、よく考えたら vi_imap では引数を指定する方法
      が存在しない。という事を考えたら別になくても良いという事なのだろうか。ま
      あ、ble-edit/content/clear-arg して困る事はない。もしかすると誰かが
      vi_imap でも arg を設定できる様に binding を追加するかもしれない。

    結局二つとも既存の widget を辞書に登録するだけで済ませる事にした。

  * decode (rlfunc): 既存の束縛の読み取り時にエラー (reported by onelittlehope) [#D1483]
    https://github.com/akinomyoga/ble.sh/issues/89

    二種類の問題がある。

    * 一つは LC_CTYPE であろう。現在のエンコーディングに一致しないバイト列が文
      字列に含まれている場合、bash の正規表現は一致に失敗する。もしくは何か変な
      一致の仕方をする。

      $ alpha=$'"\x9B": self-insert'
      $ rex='^"[^"]*$'
      $ [[ $alpha =~ $rex ]]

      然し実際に試してみたがそんな事は起こっていない。susu-linux の regcmop は
      振る舞いが違うという事なのだろうか。これについては no closing ... という
      メッセージを出している部分をもう少し詳しく見る必要がある。

    * もう一つは vi_imap/vi_nmap で vi-replace/vi-editing-mode に対応していない
      という事。これは単に対応していないというだけの事なのでできるだけ対応する
      様にする。

      然し、以下は期待通りに動いている。

      rex='^"([^\"]|\\.)*$'
      [[ $'"\x9B": self-insert' =~ $rex ]]; echo $?

      できた。再現できた。

      bind '"\x9b1;2H": beginning-of-line'
      source ble.sh

      更に良くメッセージを見ると正規表現でテストを実行する前に既に文字列が削れ
      て '"' だけになっている。

      →これについては修正した。

    https://github.com/akinomyoga/ble.sh/issues/89#issuecomment-782824259
    追記: 簡単なミスをしていた。修正する。

    https://github.com/akinomyoga/ble.sh/issues/89#issuecomment-782827987
    追記: まだ駄目だった。何度でも同じミスをしている…。ちゃんと実際にテストしなければならない。

2021-02-20

  * term: Cygwin console で最終行で IL/DL すると画面消去されるバグ [#D1482]

    Solaris に加えて Cygwin console も何だか変な振る舞いをしている。
    どうも一番下の行で .insert-newline をすると画面の内容が全て消える。
    分かった。どうやら一番下の行で IL すると問答無用で画面クリアされる。
    これは明らかにバグである。Cygwin をアップデートしてみる事にする。

    →cygwin を update して見たが修正されていない。なので、結局 ble.sh の側で対
    策をしなければならない。この様な壊れた IL に対して対策を実行する事は可能な
    のだろうか。

    * 取り敢えず現在位置が分かっていれば対応は可能である様に思われる。一番下の行
      にいる時には IL の代わりに CSI 2K を実行すれば良い。それ以外の行にいる時に
      は特に問題は起こらない様だ。

      うーん。最下部にいるかどうかで振る舞いを変えるのは難しい気がする。取り敢
      えず複数行の IL, DL の時にはちゃんと計算ができていれば最下行になる事はな
      い。問題は単一行の IL 及び DL で以下に最下行での IL/DL を避けるかという事。

      最下行にいない時には以降の内容を下に一行ずらす役割がある。うーん。それよ
      り下に内容があると分かっている場合には IL/DL を実行し、それより下に内容が
      ないという場合には DL を実行するというのが可能な対策方法である。

      うーん。かなり面倒臭い。というより CYGWIN の側で修正してもらえばこの様な
      面倒な事はしなくても良い筈なのである。取り敢えずこの workaround の為に本
      体の描画アルゴリズムを変更する事はしない事にする。

      IL/DL の中だけで対策可能であればそれを実施する。そうでなければ何もしない。

      例えば IND CUU を実行して一番下の行にダミー行を挿入して、その上で DL/IL
      を実行してから、RI かスクロールを実行してまた元に戻すという実装は可能だろ
      うか。→ SD,SU を実行してみたが消えてしまった行は戻ってこない様である。RI
      も同様に一度消えた内容が戻って来る物ではない。うーん。現在最下行にいるか
      どうかを判定して動作を切り替えるしかないのか。

    | a 結局 DSR(6) で現在位置を問い合わせて一番下の行にいる時には CSI 2K で行
    |   消去する事にした。
    |
    | x これで以前よりも全画面消去が起こる場面は減ったが、それでもやはり全画面消
    |   去が依然として発生している。何故だろうか。IL/DL を実行している箇所は既に
    |   全て抑えてある。とすれば IL/DL とは別に未だ全画面消去を引き起こす物が存在
    |   しているという事。
    |
    |   問題が発生している場所での出力内容を確認すると
    |
    |   ^[(B^[[m^[[1B^M^[[2K^[[1M^[(B^[[m^[[1A^[[31C^[(B^[[m
    |
    |   printf '\e(B\e[m\e[1B\r\e[2K\e[1M\e(B\e[m\e[1A\e[31C\e(B\e[m'
    |
    |   うーん。全消去が起きそうな気配は何処にもない気がする。と思ったが、よく見
    |   たら DL(1) が含まれている。これは一体何処から現れたのだろう…。あー。分かっ
    |   た。。DSR(6) で問い合わせする前に flush しないと駄目だ。
    |
    |   そして各スタックにある DRAW_BUFF にアクセスして出力予定の内容を全て集めて
    |   flush しなければならない。然し、DRAW_BUFF の中には取り敢えず内容を構築し
    |   て保存する為の物だったり、後で再解釈する為の物だったりする可能性もあり、
    |   一律に出力して良い内容7日どうかも分からない。という事を考えると put-il,
    |   put-dl の中で現在位置を検出して出力するという対策は全然駄目である。
    |
    |   | if ((_ble_bash>=40000)) && [[ ( $OSTYPE == cygwin || $OSTYPE == msys ) && $TERM == xterm-256color ]]; then
    |   |   # Cygwin console (pcon) では最終行で IL/DL すると画面全体がクリアされる。
    |   |   function ble/canvas/.put-il.workaround {
    |   |     local count=$1
    |   |     ((count==1)) || return 1
    |   |
    |   |     # Cygwin console 以外なら対策不要
    |   |     [[ ! $_ble_term_DA2R ]] || return 1
    |   |
    |   |     # 現在のカーソル位置の取得
    |   |     local reply=
    |   |     printf '\e[6n' >/dev/tty
    |   |     IFS= read -r -d R -t 0.1 reply </dev/tty
    |   |     local rex='([0-9]*);([0-9]*)'
    |   |     [[ $reply =~ $rex ]] || return 1
    |   |     local l=$((10#${BASH_REMATCH[1]}))
    |   |     local c=$((10#${BASH_REMATCH[2]}))
    |   |
    |   |     ((l==LINES)) || return 1
    |   |
    |   |     DRAW_BUFF[${#DRAW_BUFF[*]}]=$_ble_term_el2
    |   |     return 0
    |   |   }
    |   |   function ble/canvas/put-il.draw {
    |   |     local value=${1-1}
    |   |     ((value>0)) || return 0
    |   |     ble/canvas/.put-il.workaround "$value" && return 0
    |   |     DRAW_BUFF[${#DRAW_BUFF[*]}]=${_ble_term_il//'%d'/$value}
    |   |     DRAW_BUFF[${#DRAW_BUFF[*]}]=$_ble_term_el2 # Note #D1214: 最終行対策 cygwin, linux
    |   |   }
    |   |   function ble/canvas/put-dl.draw {
    |   |     local value=${1-1}
    |   |     ((value>0)) || return 0
    |   |     ble/canvas/.put-il.workaround "$value" && return 0
    |   |     DRAW_BUFF[${#DRAW_BUFF[*]}]=$_ble_term_el2 # Note #D1214: 最終行対策 cygwin, linux
    |   |     DRAW_BUFF[${#DRAW_BUFF[*]}]=${_ble_term_dl//'%d'/$value}
    |   |   }
    |   | fi
    |
    | b 別の手段を考える。一番上の行を犠牲にする事になるが SU/SD を組み合わせる。
    |
    |   DRAW_BUFF[${#DRAW_BUFF[*]}]=$'\e[S\e[A\e[M\e[B\e[T'
    |
    |   うーん。一応動いている様な気がするが、この対策法の問題点は DA2 を返さない
    |   端末で SU/SD に対応してない物があると描画がずれてしまうという事である。
    |
    |   あとちらつきが激しく出ているという事。やはり対策を実施するのは最
    |   低限にしたい。
    |
    | c また別の手法。一番下の行は諦めて DL/IL をする前に必ず IND/CUU を実行して
    |   一番下の行は使わない様にするという作戦。これは実際に試してみた所レイアウ
    |   ト崩れるので使えない。

    改めてそれぞれの方法の問題点について整理する

    a DSR(6) で問い合わせて判定する方法。

      o この方法は出力をキャッシュしていなければ確実に最終行を判定できる。

      x 然し実際にはカーソル移動なども含めて出力内容を複雑にキャッシュしている
        ので、その場で現在位置を取得したとしても全く意味がない。キャッシュを
        flush するにしても、それぞれのキャッシュがその場で画面に出力する事を想
        定した物でない場合もあり困難。

    b SU/SD の組み合わせを用いる。

      x 一番上の行の内容が犠牲になる。
      x 画面がちらつく。

        o これについては panel 内部で動作している限りは panel の最終行にいる時
          にだけ対策をする。これでちらつきはある程度抑える事ができる。それでも、
          panel の最終行にいる時にはちらつきが出るが、そもそも本当に最終行にい
          る時のちらつきは抑える事ができないので、我慢する。

      x Cygwin console であると誤判定した時に、その端末が SD/SU に対応していな
        いと悲惨な事になる。

    c 一番下の行は常に空になる様にしておく。

      x 使える領域が一行減ってしまう。
      x 今までの座標計算が狂ってしまうので注意深く全体を書き直す必要がある。

    d panel で一番下の行にいると分かっている時は単に EL(2) で良い。

      panel で一番下の行にいるという事が分かっている場合には、IL を一番下の行
      で実行する代わりに単に端末の最上部で DL をすれば良いのではないだろうか。
      と思ったが全然違う結果になるので駄目だ。

      或いは panel で一番下の行にいるという事が分かっているのであれば何処か別
      の行で IL/DL すれば良いのではないか。と思ったが、それだと端末最終行にい
      なかった時にずれるべき内容がずれずに残るのではないか。と思ったが、そも
      そも panel 外の内容に関しては関知しなくて良い。

      整理すると panel で一番下の行にいる時、panel の最上部で IL/DL を実行す
      る。その上で panel の最下部で EL(2) を実行すれば良い。うーん。実は最下
      部で EL(2) を実行するだけで良い気がしてきた。

    結局 b に d を組み合わせて実装した。どうも既存の IL/DL は全て panel 管理下
    にある様だ。という事なので実は実質的に d だけでうまく行くという事。

    x fixed: と思ったがどうも SU/SD の対策がコマンドを実行する度に発動している
      様子だ。と思ったがこれは単純ミスだった。opts=$2 を忘れて opts を使ってい
      た。

    ? IND を \n にして見たが微妙かもしれない。端末によっては現在の x の位置をずらしてしまうから。
      然し、現在の設計では ind によって位置がずれてしまう事も想定しているのではなかったか。

      と思ったが IND に対応していない物も沢山ある様だ。なのでやはり \n に頼るべきなのだろう。

      IND を使っている箇所について改めて確認する必要がある。ちゃんと x=0 にしているか?

      →どうも _ble_term_ind の使用は canvas.sh の中で閉じている様子である。
      put-ind.draw も内部でしか使われていない。殆どの箇所で既に対策済みか或いは
      元から column 0 にいる状態で使っている。

      問題に成るのは ble/canvas/put-move-y.draw の内部での使用で、mc の中で動作
      している時には CUU の代わりに IND を使っている。put-move.draw が何処で使
      われているか確認すると相対移動・noscrc で使っている。_ble_term_{sc,rc} も
      使えないし、相対移動なので後で絶対位置を指定して補正というのも使えない。
      ここは IND/LF で col が移動しない状況で使われていると期待するしかない。

      →うーん。現在の init-term だと LF が優先されてしまう。IND に端末が対応し
        ている事を期待して $'\eD' を使った方が安全に思われる。

  * term: sum (Solaris console) IND/RI が使えない。他色々動いていない [#D1481]

    * RI が使えない時にどの様にすれば良いか。

      * 使っている箇所の一つは vbell である。

        例えば prompt の上の行に一行 IL するという方針だと…。vbell を表示する度
        にずれてしまう。今ここで欲しいのは "上に一行も余裕がない時限定で一行確保
        する" という機能である。

      * ble/canvas/put-ri.draw

        これは2箇所から使われている。両方とも
        ble/canvas/panel/ensure-tmargin.draw という関数の中から使われていて、この
        関数は vbell から使う為の物である。

      * ble/canvas/panel#clear-after.draw
        これは単に cuu に置き換えれば良い気がする→置き換えた。

      結局 vbell が問題になる。_ble_term_ri が空の時に別の手法で vbell を表示す
      る?

      a 例えば xterm_title を使って表示するか。

        元から設定されている値を保存・復元したりするのが面倒である。push/pop の
        エスケープシーケンスも存在するかもしれないが、それに対応しているかどう
        かの判定も面倒である。というより RI を対応していない端末が xterm title
        等に対応しているとは思えない。この手法は追求しても余り意味がない。

      b 或いは、一番下の行に表示するというのは可能だろうか。

        この方法を取る場合には現在の canvas の tmargin の取り扱いを工夫しなけれ
        ばならない。というか RI が使えない場合には canvas の tmargin も振る舞い
        が微妙な気がする。

      c もしくは _ble_term_ri を使わずに被っても良いので先頭行を使う。

        然し、やはり内容が上書きされてしまうというのは都合が悪い様に思われる。

      d もしくは毎回一番上に行を挿入する。

        この方法だと bell が表示される度に行がどんどん下の方に移動してしまって
        余り嬉しい事にはならない。一応 IND を使って下に行きすぎない様に調整する
        事はできる。top/bottom dock に分かれている場合には制御が面倒である。

        現在の ble/canvas/panel/ensure-tmargin.draw の実装について確認する。
        DECSTBM が存在する場合には、スクロール領域を設定して bottom dock を固定する。
        その上で RI を実行して canvas 原点の上に tmargin 行だけスペースを確保する。

        それ以外の場合には即座に RI で canvas 原点の上にスペースを確保する。
        bottom に関しては破壊されてしまうのは我慢して invalidate する。

        さて、RI が使えない場合にどの様に内容をシフトするのか。場合分けして考え
        る。DECSTBM が使える場合にはやはり bottom dock を固定して於いて、その上
        で、top_height+tmargin だけ IND を実行する。これで少なくとも top dock
        の下に tmargin だけのスペースができる。その後で IL を一番上で実行すれば
        良い。

      うーん。完全ではないが d の方針で何とか誤魔化す事にした。

    * done: modifyOtherkeys がそのまま出力される。

      これは linux や minix と同様に出力しない様に変更。

    * done: home csi 214 z / end csi 210 z

      これは contra の escseq.html にまとめてある物に一致する気がするので確認する。

    * done: OSC がそのまま出力されている

      面倒なので xterm_title の所で直接 term の判定を行って切り替える。
      OSC を無視できるかどうかを各 OS のコンソールで確認する。
      freebsd, linux, haiku ではちゃんと無視できている。
      minix 及び sun は失敗している。

    * prompt_eol_mark 関連のカーソル移動に使われているシーケンスにも問題のある
      物がある。_ble_term_sc, _ble_term_rc の既定値が \e[s, \e[u になっていたが、
      これらは寧ろ少数派なので \e7, \e8 に切り替える事にした。Solaris では
      terminfo に \e7, \e8 は載っていないが実際には使える。

      また _ble_term_xenl に関しても terminfo になかった事から既定で 1 になって
      いたが、Solaris では 0 にする必要がある。修正した。序でに xenl がない時に
      は 0 ではなくて空文字列にする事にする。

    x ok: RI がない時の vbell の振る舞いが駄目。再度実装を確認する。
      うーん。幾らか修正して、更に必要な時にだけ高さを確保する様に変更した。

      そもそも sun console は下から出ていくと上に戻るという変な振る舞いをするの
      でまともに対応するのが難しい。適当な所で良しとするのが良い。

    * done: delete キーで ^? (DEL) が送信される。これについては TERM=sun* の時
      に ^?  を delete に変換して対策する事にした。実は既に infocmp kdch1 が ^?
      の時にはこの対策が実施されていたが、sun* の terminfo に kdch1 が登録され
      ていなかったのが原因だった。

    x 文字 x が入力できない。emacs にするとちゃんと入力できる。.blerc を別名に
      すると入力できる。と思ったがこれは set -o vi が実行されなくなるからだった。
      更に時々 segfault もする。またランダムな文字列を実行しようともする。

      これは恐らく "x?" で bind が形成されてその後でそれが削除される事により、
      x 単体の入力に対して出鱈目な文字列が実行されているという事なのだろう。
      では誰が x に bind しているのだろうか。。不思議である。

      うーん。inputrc は存在していないし、bind は特に直接呼び出されてはいない様
      だし、という事を考えると ble.sh で呼び出している builtin bind が問題を起
      こしているという事なのだろうか。

      generate-source-to-unbind-default の出力を保存してそれを読ませてみたら
      問題が発生するという事が分かった。特に問題のある行もない…と思いきや、

      builtin bind -r 'x1c' (bash-4.1)

      という変な行が混入している。これは一体何処から出てきた物だろうか。普通に
      動いている環境で実行してみると

      builtin bind -r '\x1c' (bash-4.4)

      という結果になっている。つまり、これは bash-4.1 特有の処置ではなくて一般
      に行われている処置である。

      問題の箇所を確認してみると awk で sub(/.../, "\"\\x1c\"") としている。
      つまり Solaris awk はこの \\ を消してしまうという事。と思っていたら、
      既にその問題点についてコメントに書かれていた。'\'' に対しては対策されていたが、
      直接 \ が現れる場合については対策されていなかったのが原因。
      特に \x の組み合わせが x に変換されてしまうという問題の様である。
      \x についても対応すると共にコードの整理を行った。

  * complete/mabdb: man awk の内容を抽出しきれていない [#D1480]

    先ず .PD という行が挿入されている事が原因の様である。
    .PD という行は皆無視しても良い様な気がしたので無視する。
    更に、複数のオプションに対して一つの説明がなされている場合に対応した。

    キャッシュファイルは LANG 毎に別にするべき気がする。特に LC_MESSAGES に従って
    設定するべき。

  * edit: "echo " の状態で \C-x\C-v するとバージョン情報が灰色 [#D1479]

    これは外部コマンドを実行する時に sgr0 をちゃんとしていないのが原因。何処で
    sgr0 をすれば良いのかと悩んだが取り敢えず insert-newline は新しい行に行くと
    いう意味なのだから sgr0 するのが自然である。他に外部コマンドを実行する瞬間
    にも sgr0 を実行する。

  * bash-4.4 で emacs mode で C-x * が効かなくなっている [#D1478]

    vi から emacs モードに切り替えると emacs モードで C-x が効かない。
    keyseq-timeout が長い時には問題は起こらない。

    [状況]

    | これは keyseq-timeout が関係している様だ。更に、一度 emacs モードにしてしま
    | うと、vim モードに戻しても依然として効かない状態が続いている。
    |
    | keyseq-timeout を長く設定してみたところ問題は発生しなくなったので、これはつ
    | まり "C-x ?" の組み合わせで 登録してキーを読み取ろうとしている事自体に何ら
    | かの問題があるという事なのだろう。という気がする。
    |
    | 然し vi に戻しても問題が持続しているのは不思議な事である。詳しく調べてみる
    | と vi に戻すと C-x 一回の入力に付き C-x が2回入力されている様子である。不思
    | 議な事である。
    |
    | * 普通に emacs モードから始めた場合には問題は起こらない。
    | * 同じモードで detach/attach しても問題は起こらない。
    | * 一回のコマンドで ble/decode/detach; ble/detach/attach しても問題は起こらない。
    | * ble-detach して set -o して ble-attach すると再現する。
    |
    | % 問題の一部は分かった。unbind cache に於いて "C-x ?" の組み合わせについて
    | % emacs モードの時にしか unbind していない。然し、これはモードに拘らず
    | % unbind するべきではないのか。つまり、set -o でモードを切り替えた時には元々
    | % と異なる keymap になっている為に [[ -o emacs ]] で判定したのと異なる
    | % keymap に作用する可能性がある? と思ったがそれは変だ。[[ -o emacs ]] になっ
    | % ているのであれば実際にその keymap になっている筈だし、unbind する時には一
    | % 旦元の keymap にしてから戻す様にしていた筈である。実際に
    | % ble/decode/detach においてその様に処理している。
    |
    | * ble-bind -m emacs -P で確認した限りは特に違いは見られない。という事を考え
    |   るとやはり bind の側の問題であろう。何故違いが生じるのだろうか。
    |
    | 全く同じ binder を用いていても問題が生じる物なのだろうか。何より異なる
    | keymap に対して作用しているのに影響が出るのは何故だろうか。うーん。
    |
    | うーん。builtin bind の呼び出しを全て検査すれば大丈夫だろうか。
    | と思って builtin を置換する実験をして見たら滅茶苦茶になる。
    | 何かと思ったら eval を通して $* を参照する場合には、
    | 関数の中から実行すると $* が変わってしまって駄目という事。
    | なので、builtin を置き換えて bind の呼び出しを監視する作戦は使えない。
    |
    | 直接 bash のソースを弄ってデバグする? うーん。
    | そもそも一体どういう状態になっているのかというのが謎である。
    | vi の時には何故二回連続で C-x が受信される事態になっているのか。
    | 本当に C-x が二回連続で受信されているのだろうか。。
    | 或いは C-xC-x の entry が xmap にされていると
    | C-x に対しても勝手に C-x C-x のマッピングが呼びされてしまうという事なのか。
    | もしそうだとしたら再現は簡単で良い。

    というより version 毎にちゃんと動いているか確認する。

    bash-4.4 vi: 動いている
    bash-4.4 vi->emacs: 駄目(何も受信されない) #1
    bash-4.4 vi->emacs->vi: 駄目(C-x が二回受信される) #2
    bash-4.3: 全部OK
    bash-4.2 vi: 動いている
    bash-4.2 vi->emacs: 動いている
    bash-4.2 vi->emacs->vi: 駄目(何も受信されない) #3
    3.0..4.1 は 4.2 と同じ振る舞いである。

    取り敢えず 4.4 の振る舞いだけは修正したい。

    うーん。#2 については何が起こっているか分かった気がする。以下で再現できる。

      $ bash-4.4 --norc -o vi
      $ bind -x '"\C-x":echo X'
      $ bind -x '"\C-x\C-x":echo XX'
      $ bind -r '\C-x\C-x'
      kbd <C-x><500ms> → XX と表示される

    #1 についても何が起こっているか分かった気がする。

      $ bash-4.4 --norc
      $ bind -r '\C-x'
      $ bind -x '"\C-x\C-x":echo XX'
      $ bind 'set keyseq-timeout 1'

    この状態だと C-x を押して timeout すると何も起こらない。
    keyseq-timeout を短く設定してしまうのが問題という事。

    問題 #3 では何が起こっているのだろうか。何も受信できていないというのが気に
    なる。emacs に移動した時に既に \C-x\C-x の bind -x & bind -r は終わっている
    筈である。この時点で cmd_xmap は問題がない筈。

    #3 に関しては以下の様にして再現する事ができる。

    $ bind -x '"\C-x\C-x":echo XX'
    $ bind -r '\C-x\C-x'
    $ set -o vi
    $ bind -x '"\C-x":echo X'
    kbd <C-x>

    [対処]

    | 敢えて \C-x\C-x の場所に何か変な値を設置しておく?
    | というかこれは元々の \C-x を検出する時の問題に関係するのではないか。
    | 実は以下のようにおけば問題ないのでは。
    |
    |   bind -x '"\C-x\C-x":C-x 用の文字列'
    |   bind -r '\C-x\C-x'
    |   bind -x '"\C-x":C-x用の文字列'
    |
    | 少し実験してみる事にする。
    |
    | 取り敢えず問題の再現から。bash-4.2 で以下で落ちる事を確認した。
    | bash-4.1,4.0,3.2 でも同様に落ちる。bash-3.1,3.0 では変な文字列を実行しよう
    | として失敗する。以前の実験で 3.2 だけ無限ループになったのは偶々だったのでは
    | ないかと思われる。
    |
    |   bind -r '\C-x\C-b'
    |   bind -x '"\C-x":echo X'
    |   kbd <C-x><C-b>
    |
    | さて、これの WA として \C-x\C-x を一回 bind してから unbind すると
    | いうのは有効か確認する。うーん。
    |
    | o 一応この対策をして置けば何れの場合にも crash はしなくなる。
    |
    | o bash-4.4 の場合にはこれで完全にOK。- 但し、bash-3.0..4.2 の場合にはこれを
    |   実行すると shadow binding timeout が発生しなくなってしまうので、-o emacs
    |   の時にだけ実行する様にした方が良い。
    |
    | 0 bash-3.0..4.2 の場合には vi->emacs->vi とした時に C-x で何も受け取れなく
    |   成る問題 #3 は持続している。然しそれでも、従来行っていた "C-x ?" に全て
    |   bind する作戦と同等の振る舞いを一つの binding で実現できているので、これ
    |   だけでも新しい手法に移行する価値はある。
    |
    | vi の側でも bind -x & -r を実行すれば検出できる様にはなるが、C-x 単体での検
    | 出ができなくなってしまう。でもそれは emacs keymap を一度でも使うのであれば
    | 避けようがないので、受容するしかない。或いは、emacs でも vi の上で動作する
    | 様にすれば良いのかもしれないが…。
    |
    | 取り敢えずこれがどの bash version でも再現するのかを確かめる。Bash-4.0 以下
    | では C-x を押すと行が新しくロードされる。これが意味する所は、 bind -x によっ
    | て unix_execute_command は呼び出されているが、対応する文字列の探索に失敗し
    | ているという事の気がする。
    |
    | ? 或いは一度は却下した bind -s '"\C-x": "\xC0\x98"' を用いる方法について再
    |   検討しても良いのかもしれない。遅延が生じるという事が述べられているが、ど
    |   の bash の version で起こるのか等について記録が残っていない。
    |
    |   * 先ずは遅延を再現しなければならない。そしてどの様な状況で問題になるのか
    |     を確認しなければならない。
    |
    |     →うーん。bash-4.4 で bind 'set keyseq-timeout 500' にしたら再現できた。
    |     これは何故発生しているかと言うと C-x ? が (過去に) 存在していた時に
    |     '"\C-x":"\xC0\x98"' を実行する為には結局 timeout/mismatch が必要だから
    |     である。
    |
    |     然しこの遅延に関しては "C-x ?" 全バインドの手法を取ったとしても共通であ
    |     る。特に問題になるのは C-x C-x と連続で入力した時に、この C-x C-x の組
    |     で認識されれば即座に反映されないという事である。"C-x ?" なら即座に反映
    |     される。'"\C-x":"\xC0\x98"' だと
    |
    |       C-x C-x
    |       \xC0 \x98 C-x
    |
    |     の様な形になるので余った C-x が残ってしまう。
    |
    |   x 更に、bash-4.2 で '"\C-x":"\xC0\x98"' を適用してみたが、結局遅延が存在
    |     する事には変わりがない様で、意味がない。bash-4.3 以降は現在は問題なく動
    |     作するので、対策は bash-4.2 以下に対してになるが、bash-4.2 以下では
    |     keyseq-timeout を指定する事もできないのでこの遅延をどうにかする事はでき
    |     ない。
    |
    | ? というかこの単一 bind 手法だと結局 C-x C-x とした時に遅延が生じるのではな
    |   いだろうか→確かめた。実際にそうだった。やはり単一 bind は駄目である。
    |   bash-4.4 ならば keyseq-timeout を短くすれば未だ何とかなるが bash-4.2 以下
    |   では次の操作をしない限りは C-x C-x に対して結果を受信する事ができない。

    [対処法比較]

    単一C-x (C-xC-xを一旦設定)

      4.4 ... keyseq-timeout の分だけ遅延が生じる。keyseq-timeout を 0 にすれば
        問題ない。何故 timeout 遅延が生じるのかと言うと、元々 emacs keymap には
        C-x ? の組み合わせが登録されていて、それらが全て削除されていたとしても
        (或いは削除しきれていないのかもしれない)、確定状態にならないからなのだ
        と言う気がする。

        ※C-xC-xを一旦設定する措置をしないとコマンドが登録されていない旨のエラー
        が発生する。

      4.2 ... timeout がないので key 一個分だけ遅延してしまう。keyseq-timeout
        を 0 にする訳にも行かない。

        ※C-xC-xを一旦設定する措置をしないとそもそも、次の key が来ていざ確定し
        た時にクラッシュしたりランダムな文字列を実行したりして問題になる。

    全 "C-x ?" の束縛 (C-x は unbind しておく)

      4.4 ... keyseq-timeout により timeout が発生すると "C-x" 単一で確定が為さ
        れるが、その時に何も実行されない。keyseq-timeout を十分長くすれば気にな
        らなくなる…かもしれないが、それでも振る舞いとしては微妙。

        ※C-x にも bind する様にしておくと今度は C-x に対して C-xC-x に対応する
        コマンドが実行されてしまう。

      4.2 ... key 一個分の遅延はない。emacs では特に何も問題は発生しない。但し、
        一旦 emacs で "C-x ?" の組み合わせに対して全 bind を実行していると、vi
        の側で単一 C-x に対して bind しようとした時に支障が出る。

        これを防ぐ為には "C-x ?" の組み合わせについて直接 -x を設置するのではな
        くて、文字列マクロ経由で読み取る様にするべきではないか。という事。この
        時の問題は…。やはり \C-x が再び現れると key 遅延が発生する事。つまり、
        bind '"\C-x\C-x":"\xC0\x98\x18"' 等とすると、\x18 (\C-x) に対して再び
        key 一個分の遅延が発生する。なので、'"\C-x\C-x":"\xC0\x98\xC0\x98"' と
        する必要がある。

        * 一方で、"\xC0" や "\x98" に関しては複数バイトの束縛は行わないので、
          "\xC0" の timeout/key 遅延について問題が新しく発生する事はない筈。

    Bash 4.4 では単一 C-x を採用する。Bash 4.2 以下では今まで通り "C-x ?" を全
    束縛するが、vi に影響が出ない様にマクロ経由で束縛する事にする。

2021-02-18

  * syntax: !; 及び time; の後の文脈 [#D1477]

    !; 及び time; の後の文脈で } fi done esac を要求しているが実際は任意のコマ
    ンドの筈である。少なくともそうなっている様に見える。問題の部分では #D0592
    を参照しているが、これは大きな書き換えなので特にこの部分で何故この様にした
    のかは謎。コメントには明示的に CTX_CMDXE と書かれている。そんな事はない筈な
    のに不思議である。

    よく #D0592 を見てみたら "time ; echo" でエラーになると書かれている。
    うーん。bash の version かと思って試したらそうだった。bash 4.3 以前は
    "time ; echo" がエラーになるのであった。一方で 4.4 以降は OK

2021-02-15

  * 2017-10-01 syntax: case $x in (a b) : ;; esac のパターン "a b" はエラー [#D1476]
    これも #D1474 で対応した。此処に挙げられているテストケースは有用だった。

    どうやら一個の単語までしか駄目な様子?

    更に case aaa in ((aaa)) echo;; esac 等の様に () の入れ子もエラーになる。
    shopt -s/-u extglob に拘らずエラーになる。
    一方で extglob の @() に関しては中で () の入れ子が可能である。
    つまり、case の中の (...) と extglob @(...) の文脈は異なる。

    他にも違いはある。@(<>) は許されるが、in (<>) は許されない。
    @(&&) は許されるが in (&&) は許されない。
    in (a|a|a) は許されるが in (a||a) や in (||) は許されない。
    in (&), in (|), in (;), in (<), in (>) は何れも駄目。
    in (a&b), in (a;b), in (a<b), in (a>b) も何れも駄目。

    どうも全然違う文脈の様に思われてきた。

    現在の実装では ble-syntax:bash/ctx-case から CTX_PATN に突入している。
    (他に CTX_PATN に入っている箇所を探すと、
    関数の引数の括弧に何か変な物が入っている場合と、
    コマンドの途中で突然括弧が現れた場合である。
    これらはエラーに対する復帰としての CTX_PATN なのでそんなに気にしなくて良い)

    どうも振る舞いを観察すると ctx-conditions と ctx-globpat の中間のように思う。
    単語を設置しなければならないという観点で言うと ctx-conditions に近い。
    一方で対応している構文の集合という観点で言うと ctx-globpat が幾らか近いように思う。

    2017-11-27 追記
    どうやら () の中の単語ではチルダ展開も有効のようだ。以下で hello が出力される。
    case a=~ in (a=/home/murase) echo hello; esac # これは対応済み
    case a=/home/murase in (a=~) echo hello; esac

  * syntax: case x) とした時の ")" の着色が括弧でちゃんと囲んだ時と異なる [#D1475]
    これは #D1474 における再実装で一緒に修正した。

  * syntax: case a in @) で @() と入力すると fatal error [#D1474]

    case a in ) の状態でパターンに @() を入力しようとするとシフトエラーになる

    | もっと具体的に調べてみると case a in @) の状態で @ の直後に ( を挿入する
    | となる。シフトエラーになるという事は case a in @) と入力した時点で壊れて
    | いると考えられる。
    |
    | | 先に ) を入力した時
    | | $ case a in @)
    | | _ble_syntax_attr/tree/nest/stat?
    | | 18 a    000 'c' | stat=(CMDX w=- n=- t=-:-)
    | |  | a    001 'a' |
    | |  | a    002 's' |
    | |  | a    003 'e' + word=CMDI:0-4/(wattr=d)
    | | 39 a    004 ' '   stat=(CARGX1 w=- n=- t=$4:-)
    | | 40 a    005 'a' + word=ARGI:@3>5-6/(wattr=d) stat=(CARGX1 w=- n=- t=$4:-)
    | | 41 a    006 ' '   stat=(CARGX2 w=- n=- t=$6:-)
    | | 42 a    007 'i' | stat=(CARGX2 w=- n=- t=$6:-)
    | |  | a    008 'n' + word=CARGI2:@5>7-9/(wattr=d)
    | | 34*a    009 ' '   stat=(CASE w=- n=- t=$9:-)
    | | 30*a    010 '@' | nest=(CMDX w=- n=- t=$9:-) stat=(CASE w=- n=- t=$9:-)
    | | 30*a  s 011 ')' + word="none":@8>10-12 stat=(PATN w=- n=@10 t=-:$9)
    | |  |    s 012 ^@   stat=(CMDX w=- n=- t=$12:-)
    | |
    | | 先に @ を入力した時
    | | $ case a in @)
    | | _ble_syntax_attr/tree/nest/stat?
    | | 18 a    000 'c' | stat=(CMDX w=- n=- t=-:-)
    | |  | a    001 'a' |
    | |  | a    002 's' |
    | |  | a    003 'e' + word=CMDI:0-4/(wattr=d)
    | | 39 a    004 ' '   stat=(CARGX1 w=- n=- t=$4:-)
    | | 40 a    005 'a' + word=ARGI:@3>5-6/(wattr=d) stat=(CARGX1 w=- n=- t=$4:-)
    | | 41 a    006 ' '   stat=(CARGX2 w=- n=- t=$6:-)
    | | 42 a    007 'i' | stat=(CARGX2 w=- n=- t=$6:-)
    | |  | a    008 'n' + word=CARGI2:@5>7-9/(wattr=d)
    | | 34 a    009 ' '   stat=(CASE w=- n=- t=$9:-)
    | | 30*a    010 '@' | nest=(CMDX w=- n=- t=$9:-) stat=(CASE w=- n=- t=$9:-)
    | | 30*a    011 ')' + word="none":@8>10-12 stat=(PATN w=- n=@10 t=-:$9)
    | |  |    s 012 ^@   stat=(CMDX w=- n=- t=$12:-)
    |
    | これら二つを比較しても違いは 011 の位置の s という記号のみである。この s
    | というのが何であるかは覚えていないが、実のところこの二つの両方で問題が再
    | 現するので @ を先に入力するか ) を先に入力するかは問題には関係ない。
    |
    | @の代わりに X を挿入した場合にどうなるか調べる。X に引き続いて (
    | を挿入しても問題は発生しない。
    |
    | | $ case a in X)
    | | _ble_syntax_attr/tree/nest/stat?
    | | 18 a    000 'c' | stat=(CMDX w=- n=- t=-:-)
    | |  | a    001 'a' |
    | |  | a    002 's' |
    | |  | a    003 'e' + word=CMDI:0-4/(wattr=d)
    | | 39 a    004 ' '   stat=(CARGX1 w=- n=- t=$4:-)
    | | 40 a    005 'a' + word=ARGI:@3>5-6/(wattr=d) stat=(CARGX1 w=- n=- t=$4:-)
    | | 41 a    006 ' '   stat=(CARGX2 w=- n=- t=$6:-)
    | | 42 a    007 'i' | stat=(CARGX2 w=- n=- t=$6:-)
    | |  | a    008 'n' + word=CARGI2:@5>7-9/(wattr=d)
    | | 34 a    009 ' '   stat=(CASE w=- n=- t=$9:-)
    | | 30 a    010 'X' | nest=(CMDX w=- n=- t=$9:-) stat=(CASE w=- n=- t=$9:-)
    | | 30 a    011 ')' + word="none":@8>10-12 stat=(PATN w=- n=@10 t=-:$9)
    | |  |    s 012 ^@   stat=(CMDX w=- n=- t=$12:-)
    |
    | 然し木構造を調べても X の時と @ の時で全く同じ状態になっている。な
    | のにシフトでエラーが発生するというのは不思議である。
    | →改めて確認した所、一番最初に発生するエラーはシフトエラーではなかった。
    |
    | | ble/syntax/tree-enumerate/.initialize/FATAL2
    | |   @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:4 (ble/syntax/tree-enumerate)
    | |   @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:6 (ble/syntax/print-status/.dump-tree)
    | |   @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:8 (ble/syntax/print-status)
    | |   @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:74 (ble/highlight/layer:syntax/update)
    | |   @ /home/murase/.mwg/src/ble.sh/out/ble.sh:13 (ble/highlight/layer/update)
    | |   @ /home/murase/.mwg/src/ble.sh/out/ble.sh:10 (ble/textarea#update-text-buffer)
    | |   @ /home/murase/.mwg/src/ble.sh/out/ble.sh:76 (ble/textarea#render)
    | |   @ /home/murase/.mwg/src/ble.sh/out/ble.sh:3 (ble-edit/bind/.tail)
    | |   @ /home/murase/.mwg/src/ble.sh/out/ble.sh:18 (ble-decode/EPILOGUE)
    | |   @ /home/murase/.mwg/src/ble.sh/out/ble.sh:79 (ble-decode/.hook)
    |
    | print-status の段階でエラーが発生している。つまり、直前の状態が問
    | 題なのではなくて ( を入力した直後の状態が壊れているのである。
    |
    | | _ble_syntax_attr/tree/nest/stat?
    | | 18 a e  000 'c' | stat=(CMDX w=- n=- t=-:-)
    | |  | a e  001 'a' |
    | |  | a e  002 's' |
    | |  | a e  003 'e' + word=CMDI:0-4/(wattr=d)
    | | 39 a e  004 ' '   stat=(CARGX1 w=- n=- t=$4:-)
    | | 40 a e  005 'a' + word=ARGI:@3>5-6/(wattr=d) stat=(CARGX1 w=- n=- t=$4:-)
    | | 41 a e  006 ' '   stat=(CARGX2 w=- n=- t=$6:-)
    | | 42 a e  007 'i' | stat=(CARGX2 w=- n=- t=$6:-)
    | |  | a e  008 'n' + word=CARGI2:@5>7-9/(wattr=d)
    | | 34 a e  009 ' '   stat=(CASE w=- n=- t=$9:-)
    | | 31*a e  010 '@' | nest=(PATN w=- n='none':10- t=-:$9) stat=(CASE w=- n=- t=$9:-)
    | |  |*a e  011 '(' |
    | |  6*a es 012 ')' + word="none":10-13 stat=(PATN w=- n=@10 t=-:-)
    | |  |    s 013 ^@   stat=(PATN w=- n=@10 t=$13:$9)
    |
    | というか、")" が存在しなくても普通に @( と入力しただけでエラーになってい
    | る。a@( としている時には大丈夫である。これはつまり単語と nest が同じ場所
    | で始まる事によってエラーになっているという事だろうか。うーん。確かに a@(
    | とすると a の位置と @ の位置の両方に nest が設定されている。という事は、
    | @( を入力した時に同時に二箇所に nest を設定しようとして状態が破壊されてい
    | るのである。だとすると $( でも問題が発生する筈→発生した。" でも問題が発
    | 生した。うーん。根本的に nest を再考する必要があるのかもしれない。

    [状況]

    以下の何れでも問題が発生する。原因は同じ位置に2つの nest を設置しようとして
    いる事にある。

    - case a in @(
    - case a in $(
    - case a in "
    - case a in (x);;"

    nest の位置をずらそうとしても " の場合には一文字しか無いのでずらす事ができ
    ない。逆にパターンの側の nest の位置を一文字前にずらすという事も考えたが、
    必ずしもパターンの前が空白とは限らない。例えば ;; など。この場合には結局同
    じ位置に nest を設置するしかない。或いは ;; の位置に nest を設置してしまう
    という手もあるのかもしれないが、それは不自然だし色々とまた変な問題が発生し
    そうである。

    [修正]

    やはり解決策としては同じ位置に nest を設置できる様にするという事。然し、現
    状のコードで nest が同じ位置に設置されないという前提は何処で使っていただろ
    うか。場合によって単に対応するだけでは済まないかもしれない。

    或いはもう一つの方法として、そもそも case パターンを nest にする必要があっ
    たのかという事。この方法の方が確実に簡単に修正できる気がする。然し、nest に
    した理由は何だろうか。単に既存の CTX_PATN を使いたかったからというのであれ
    ば簡単である。

    コードを確認してみたがやはり nest を使わないとすると新しい文脈値が必要にな
    りそうである。更に、元から case pattern の中は単語が一個だけになる様に制限
    を加える予定だった。これに対応する為には結局新しい文脈値が必要だったのだ。
    case pattern の単語数も一緒に対応してしまうのが良いだろう。

    うーん。実はコマンド文脈で読み取った方が良い? とも思ったがそうでも
    ない気もする。例えば | の取り扱いが異なる。& や ; 等他の delim の
    場合にはエラーにする必要がある。|| は一まとまりではなく一文字ずつ取る。
    | の直後は再び単語を受け付けて OK。など。

    - done: ble/syntax:bash/ctx-command-case-pattern

    実装したが無限ループになってしまう。調べると parse の中で同じ位置に対してずっ
    と計算している。

    parse (i=19): ctx=78 ble/syntax:bash/ctx-command-case-pattern-expect

    $ case x in @() echo ;; esac

    問題は ;; の直前で起きている様だ。これは BASH_REMATCH が途中で書き換わって
    いたのが見落としだった。修正した。OK 動いている。

    ----------------------------------------------------------------------

    2021-02-19 assertion failure が出た。

    assertion failure: ((_ble_syntax_bash_command_isARGI[ctx]))
    invalid ctx=79 in words
      @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:15 (ble/syntax:bash/ctx-command)
      @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:86 (ble/syntax/parse)
      @ /home/murase/.mwg/src/ble.sh/out/ble.sh:7 (ble-edit/content/update-syntax)
      @ /home/murase/.mwg/src/ble.sh/out/ble.sh:75 (ble/textarea#render)
      @ /home/murase/.mwg/src/ble.sh/out/ble.sh:3 (ble/textarea#panel::render)
      @ /home/murase/.mwg/src/ble.sh/out/ble.sh:5 (ble/function#try)
      @ /home/murase/.mwg/src/ble.sh/out/ble.sh:8 (ble/canvas/panel/render)
      @ /home/murase/.mwg/src/ble.sh/out/ble.sh:3 (ble-edit/bind/.tail)
      @ /home/murase/.mwg/src/ble.sh/out/ble.sh:18 (ble-decode/EPILOGUE)

    [再現]

    | 以下のコマンドラインに於いて "'; の ; の前にカーソルを置いて、其処から BS
    | の autorepeat で削除を行うと確率的に上記のエラーが発生する。不思議なのは
    | ctx=79 は最近追加した CTX_CPATQ であり、これは case の時にしか発生しない筈
    | の物であるという事。現状では何処にも case はないので ctx が 79 になる事はな
    | い様に思われる。core-syntax.sh の中を再度確認してみたが混入する事はない気が
    | する。
    |
    | $ debug/builtin() { unset -f builtin; IFS=" " eval 'echo "[$*]"'; builtin "$@"; local _ext=$?; echo "[$* ($_ext)]";
    |   builtin() { debug/builtin "$@"; }; return "$_ext"; }
    |
    | $ d() { unset -f builtin; A=" " : ': "[$*]"'; : "$@"; : a=$?; : "[$* ($a)]"; }
    |
    | $ : helloworldhelloworld; A=" " :; : a=$?; : "[$* ($a)]"
    |
    | あー。成程。79 が現れたのは BS で消す途中に ;; が現れる為である。確率的に発
    | 生していたのは、丁度 ";;" の時に文法の再解析が起こるか起こらないかである。
    | 一つずつ BS を押していれば必ず発生する。
    |
    | $ :; :;: a=$?;:
    |
    | OK. 以下が最小再現コードである。以下の状態から間の空白を削除するとエラーになる。
    |
    | $ ; ;a=1
    |
    | というより変な事をしなくても普通に以下で問題が発生する。
    |
    | $ case x in a=1

    取り敢えず 79 が出るのは別にバグではないという事は確認できた。
    そして修正は簡単だった。これは fixup にする。

2021-02-10

  * ble/builtin/read: 空文字列の時 C-d でキャンセルしない [#D1473]

    使い心地が変だと思って plain Bash で試してみたら C-d でちゃんとキャンセルに
    なる。ble/builtin/read もこれと同様に振る舞うべきである。

    →これも実装した。これは簡単な修正。

  * ble/builtin/read: 全く描画されなくなっている [#D1472]

    これは ble/canvas/panel/render において描画するかどうかを各パネルの高さで決
    定しているが、textarea は textarea#render の中で高さを決定する事にしている。
    なので高さがいつまでも 0 の儘になってしまって結局全く描画されないという事態
    になっている。

    | 本来は描画を実行する前に高さを決定するべきなのである。然し、現在の実装では
    | 中身の計算が重いために必要になるまで計算しない事にしている。うーん。
    | getHeight を受け取った時点で中身の計算を終わらせるべきだろうか。然し、希望
    | の高さを伝えたからと言って必ずしもその高さが通るとも限らないし、結局結果に
    | よっては再計算する必要が出てくる可能性は変わらない。
    |
    | その様に考えると結局現在の様な実装でも変わらないのではないかという気はする。
    | 或いは 0 という高さは特別な高さという事にして中身がある場合には必ず有限の高
    | さを指定する事にする?
    |
    | 然し、0を特別扱いする事にすると一時的に高さを 0 にして再び後で高さが有限に
    | なる可能性がある時、そしてその高さが有限になる機会が render の中で得られる
    | 場合に困る。なので、0 であってもやはり render は呼び出すべきなのではないだ
    | ろうか。
    |
    | うーん。然しそうすると… textarea を隠したい時にも必ず textarea が表示され
    | てしまうという事になってしまう。或いは、textarea を隠したい時には
    | _ble_textarea_panel には -1 などの値を代入しておくというルールにする? とい
    | うよりそもそも表示・非表示という状態は height とは別に持っておくべきなので
    | ある。

    * 表示・非表示の状態は height とは別に持っておくべき。現在の実装では取り敢
      えず各実装に任せる事にする。

    * render では取り敢えず高さ 0 であっても全ての panel について
      $class#panel::render を呼び出す事にする。これは render の中でレイアウトを
      計算する時に高さを変更したくなるかもしれないからである。

    * reject: 将来的には textarea#render を textarea#layout と textarea#render
      に分ける事も考えるべきかもしれない。

    | 少し textarea#layout と textarea#render に分ける事も考えたが、これをして
    | も結局何も変わらない。というのも、textarea#layout で高さを計算する時に自
    | 身の高さを変更すると結局、他のパネルの高さも全て再計算になる。なので、再
    | 帰的な高さ変更の可能性は、高さ計算を textarea#layout に分離したとしても本
    | 質的には解決していない。何か利があるとすれば最後の描画処理が省略できるだ
    | けである。そして最後の描画処理は ble.sh ではそんなに重い処理ではないので
    | 意味がない。
    |
    | また、今まで問題が起こらなかった理由でもあるが textarea は高さを要求する
    | が、info は高さが足りなければ他から奪おうという事はしないので、高さの更新
    | が再帰的になる事はない。特に textarea よりも info の方が後に render を行
    | うという事もあるので特に問題になっていない。(実は今までは info が描画した
    | 内容を textarea が truncate するという事になっていたのではないかという気
    | がするので、現在の実装のほうがよりまともなのであろう)

    * 結局 height 更新の無限ループは可能性として排除できない。それは render の
      中で height 設定をしても、layout の中で height 設定をしても同じことである。
      最終的には誰かが皺寄せを食うという事にしておけば何れにしても問題にならな
      いし、そうでなければそもそも解が存在しない。現在の実装では info が皺寄せ
      を食う事になっている。

  * global: 今度はまた別の連想配列のエラーが出ている (reported by 0xC0ncord) [#D1471]
    https://github.com/akinomyoga/ble.sh/issues/86#issuecomment-776165286

    新しいシェルを開いてもエラーが出ていると書いているが本当だろうか?
    もしこれが同じシェルだとしたら ble-update で駄目な事になるというのは理解できる。
    取り敢えずその為の修正だけは入れる事にした。

  * global: 連想配列の中身が bash-4.2 関数内ble.shソースで消滅する (reported by 0xC0ncord) [#D1470]
    https://github.com/akinomyoga/ble.sh/issues/86

    4.2 で動かないという話。調べると問題の _ble_builtin_trap_n2i は連想配列であ
    る。という事は -g の指定が怪しい。実際に ble.sh を関数内で source したら再
    現できた。

    然し、手元で reduced case を作ってみると動いている様な気がする。WINCH に対
    するシグナル番号を取得する時に結果が空になってしまってい
    る。_ble_builtin_trap_n2i から引いている。然し、 _ble_builtin_trap_n2i の値
    を見るとちゃんと SIGWINCH に対して 28 が割り当てられている様に見える。と思っ
    てよく見てみたら、途中で _ble_builtin_trap_n2i の中身が空になっている。もし
    かして、bash-4.2 だと属性は global まで適用されるが、値が local になってし
    まっているという事か。

    実際に試してみると確かに中身が空になる。うーん。今までは -gA を 40200 以上
    という条件で使っていたが、これは 40300 以上という条件に引き上げるべきだろう。

    * 結局最小再現コードは以下の様になった

      $ bash-4.2 -c 'a(){ declare -gA d=([k]=v);};a;declare -p d'
      declare -A d='()'
      $ bash-4.3 -c 'a(){ declare -gA d=([k]=v);};a;declare -p d'
      declare -A d='([k]="v" )'

    * reject: 判定条件を変数に入れて再利用できるようにする? と思ったがどうせそ
      の次の判定で細かく場合分けするので全体の条件だけ変数に入れて再利用しても
      却って分かりにくいだけである。これは棄却。

    * reject: 連想配列の使い方に応じて declare -gA を使う bash version を切り替える?

      使い方によっては引き続き 40200 でも大丈夫かもしれない。つまり、ble.sh を
      source した段階では空の儘で、実際に使っていく中で中に値をキャッシュすると
      いう場合。或いは、単にキャッシュとして使うという場合にも問題は起こらない。
      然し、実際に関数の中で値が初期化されるかどうかは attach の仕方にも依存す
      る。更に、これは関数内で ble.sh を source するという特殊な場合に於いての
      み影響が出るので余り細かい最適化を考えても仕方がない。

    全て 40300 に書き換えた。まあ、これで何も起こらないだろう。

2021-02-09

  * 2021-02-01: spike branch で tab completion で crash する (reported by 3ximus) [#D1469]
    https://github.com/akinomyoga/ble.sh/issues/82#issuecomment-770390986

    Ref: これは #D1452 / #D1468 と同じ問題。詳細は #D1468 で議論。

    eval-pathname-expansion の中で死んでいるのだろうか。failglob などの判定に失
    敗している可能性もある。つまり、shopt -s failglob が設定されている時に、
    globpat が含まれているのに含まれていないと判定された時に、set -f 等の操作を
    行わずにパス名展開を直接実行して、それにより強制的に終了してしまっている可
    能性。

    →でも元々 failglob があっても大丈夫な様に eval を使って評価していた筈→本
      当だろうか。eval だけで failglob を回避する事ができていたのだろうか。
      syntax の方で .set-result という関数を用意したのは何か理由があったのでは
      ないか。と思ったが、.set-result は failglob を避ける為の物ではなくて展開
      結果を格納する為の物だった。

    →更に、現在の判定方法で globpat を見逃すとも考えづらい。

    実際に手元で failglob の設定下で補完を試みたが変な事は起こっていない。bash
    version の違いかもしれないとも思ったが別に 5.1 でも dev でも変な事はない。
    3.2 や 4.0 4.3 4.4 で試しても違いはない。

    →hangは観測できたという話をしたらどうやら正確にはcrash ではなくて hang し
    ていた様だ。そして振る舞いを見る限りに於いては自分の手元で観測した hang と
    全く同じである。

  * 2021-02-03 TAB completion に於いて conditional-sync で hang する [#D1468]
    Ref: #D1452 と #D1469 は実はこの問題と同一であった。

    chatoyancy で再現している。

    3ximus の報告した crash は観測されていないが代わりに linux 上で hang すると
    いう現象は起こっている。親 shell が固まっていて一方で子 shell はいつまで経っ
    ても終了しないという状態になる。これはどういう状態だろうか。子 shell に対し
    て kill を実行するとその時点で終了して親 shell も使える様になる。時々、再び
    子 shell を生成してそれが固まるという現象は発生している。subshell が発生し
    ている状態で固まっているという様子を見る限りは恐らく conditional-sync で変
    な問題が起こっているのだと思われるが分からない。

    * 親shellの CPU が微妙に動いている。
    * ユーザー入力しても何故か親シェルが中断しない

    改めて condtional sync の実装を確認してみると2回 fork している。1つの fork
    はジョブ管理によって変なメッセージが発生するのを避ける為。2つ目の fork が実
    際に & で bg job を起動する為の物。症状として見られていた hanging shell は
    実は worker ではなくて最初の subshell の様だ。更に詳しく調べてみるとどうや
    ら msleep の中で停止してしまっているようだ。つまりこれは Cygwin 上で発生し
    ていた #D1452 のフリーズと全く同じ問題である。

    Cygwin のテストケースと同じ物で再現できるだろうか。

    ( echo {1..1000} & builtin read -t 0.000100 v < /dev/udp/0.0.0.0/80 ) >/dev/null

    Linux では /dev/udp ではなくて fifo を使っている筈。

    OK 再現した。

    $ mkfifo a.pipe
    $ exec 9<>a.pipe
    $ test1() { (eval "echo {0..$count}" & builtin read -u 9 -t 0.001 v) >/dev/null; echo ok $((count++)); }
    $ bind -t '"\C-t":test1'

    これは結局 bash のバグなので別の場所で議論する事にした。

    workaround を考える。

    A 一つの方向は先ず変な事が起こる発生確率を下げるという事。
      然し、それでも read -t がブロックする可能性は 0 ではない。
      これは実の所 /dev/zero を使っていても同様の筈である。
      とにかく変な事が発生する確率は 0 ではないという事。

      変な事が起こる確率を下げる為に。もう一つの可能性は以下の様に、
      $() を使って fork して、その後で read timeout を
    一番外側で実行するという事。

        { pid=$({ echo OK >&3; sleep 10; } &>/dev/null & echo $!); } 3>&1

      疑問としは孫シェルを wait できるのかという事。→うーん。駄目だった。

        bash: wait: pid 9447 はこのシェルの子プロセスではありません

      wait できない。という事は終了ステータスを検知する方法がない。或いは
      ble/util/assign と同様に終了ステータスは自前のファイル経由で読み取るとい
      う手もあるのかもしれないが…。とにかく面倒になってしまうという事は避けら
      れない。

      そもそもこの方向で問題を軽減できるのかどうかも非自明である。

    B read timeout を使わない方法を模索するべきなのかもしれない。
      然し read timeout が使えないとなるとやはり方法は絞られてくる。
      一つの方法は普通にコマンドの sleep を呼び出すという事。

      然し、spawn のコストと、更に sleep の分解能が秒単位しか無いという可能性が
      ある。そう考えると read timeout はどのシステムでも使う事ができるかなり便
      利な機能だったのである。

    c というよりそもそも conditional-sync ではデフォルトでユーザの入力を待って
      いるのだから、read -t を sleep に使うのではなくて、直接ユーザー入力を検出
      するのに使えば良いのではないのか? と思ったが駄目だ。read -t 0 ならばユー
      ザー入力を読み取らずに検査する事ができるが、read -t 0.001 だとユーザー入
      力を消費してしまう。そうなると気軽に実行できない。或いは、ユーザー入力を
      読み取る事ができた暁にはその場で ble-decode-char するという手もある?

      うーん。然し、_ble_bind_hook の中で実行した bind/.tail の中で
      ble-decode-char するとすると、例えば其処でコマンド実行が _ble_bind_hook
      に大して設定された時に、それがその場で実行されない可能性がある。更に、設
      定した物が実行される前に消滅してしまう可能性すらある。ble-decode-char を
      その場で実行する方式にすると色々木にしなければならない事が多い。

    d conditional-sync に限っては ALRM を subshell から投げれば良いのでは。と思っ
      て試してみたが、何も設置していない状態で kill -ALRM $$ すると親シェルが終
      了してしまう。ALRM に何か無視する様に ble.sh でハンドラを設置しても良いが、
      それはそれでまた面倒事が増える。

    うーん。二つの方向性がある。全般に msleep の問題を解決するという事と
    conditional-sync の問題を解決するという事。今までの発生頻度から考えると
    conditional-sync の対策だけをしても当面は大丈夫な気もするが、何れは msleep
    の問題を完全解決したい。そうなった暁には conditional-sync の対策は不要にな
    るし、また conditional-sync の問題だけ解決するのは臭いものに蓋をしているだ
    けで本質的問題の解決にはなっていない。それよりは msleep 自体の問題を解決す
    る様に考えたいのである。

    仕方がないので cygwin と同じ手法で回避する事にした。

    2021-02-13 /dev/zero による workaround を追加したがよく考えたら /dev/zero
    が全ての環境にあるとは限らないし、ある環境でも read をブロックしてくれるか
    は微妙である。と思ったが /dev/zero で止まるかどうかは bash の側の実装の問題
    なので、もし /dev/zero が 0 を出力し続けるのであれば、ちゃんとブロックはす
    るだろうと思われる。

    /dev/zero が存在する環境について一度確認はしておきたい。Solaris, Minix に存
    在する。FreeBSD, Haiku にも存在した。当然 Cygwin と Linux にも存在する。
    MSYS2 でも OK だった。何れも read -t 0.2 < /dev/zero がちゃんと期待通りに動
    いた。という事を考えれば基本的に全ての環境で /dev/zero が使えると考えて良い
    のではないだろうか。

2021-02-04

  * global: read timeout は $?==142 とは限らない [#D1467]

    read timeout は本当に常に 142 なのか。と思ったが現在の用例では 142 は
    conditional-sync によって固定で返されているので気にしなくて良い。因みに
    bash のソースコードを確認する限りは 142 は hardcoded ではない。

    * edit (ble/builtin/read/.loop): うーん。予め 142 に対応する終了ステータス
      を調べておくか、或いは 128 以上を一括で timeout と解釈するか。マニュアル
      には "128 より大きな値になる" とだけ書かれている。マニュアルに従った判定
      にするのが良い気がする。

    * util (ble/util/msleep/.use-read-timeout): これは現在は使っていない。何れ
      にしても Cygwin/MSYS の時にだけチェックする様にすれば、これらのシステムで
      は 142 固定と期待されるので大丈夫。

  * util (bleopt): bleopt でパイプに繋いでいても _ble_term_sgr0 が出力されている場合がある [#D1466]
    追加で関連する関数に於いて --color オプションで着色を制御できるようにする。
    * "--color" options for bleopt, blehook, ble-color-setface

  * 2021-02-01 highlight: highlight_timeout_sync=0 にしても遅い (reported by 3ximus) [#D1465]
    https://github.com/akinomyoga/ble.sh/issues/82#issuecomment-770390986

    % OK. Sorry, I actually reproduce this level of delay at my side too, but I
    % haven't regarded it as *terrible*. That's probably because I know what
    % `ble.sh` is doing in the background. I felt that it's actually doing a good
    % job considering how strange things `ble.sh` is doing in the background.
    %
    % →と思ったが、bleopt highlight_timeout_sync=0 を実行していなかった。これを
    % 実行したら自分のところでは特に問題もなく動く様になった。当初は実装のバグか
    % とも思ったが、一部の host の上でだけ動作しないという事があるだろうか。
    %
    % Do you think it is related to `ffmpeg` running in the background? I see in
    % the `top` pane multiple instances of `ffmpeg` are running, but the load
    % average is smaller than 2, which means that those `ffmpeg` instances are
    % waiting for an interrupt in more than half of their running time. If those
    % `ffmpeg` are encoding some video clips, they may be waiting for disk I/O.
    %
    % →と思ったが disk I/O 待ちだと status D になる筈である。画面を見る限りはそ
    % うなっていない。更に -x11grab というオプションについて調べてみるとこれはス
    % クリーンキャプチャである。つまり、これらの ffmpeg は単にこの説明を作るため
    % に起動しているだけで、問題には関係してこない。

    何れにしてもこれは background highlighting におけるユーザー入力による中断速
    度に関係している。でもどの部分が悪さをしているのか分からない。

    1. 入力検出?
    2. 生存検出?
    3. 或いは kill & wait だろうか。

    どうも background highlighting のユーザー入力によるキャンセルの応答が遅い様
    である。自分の手元では残念ながら再現しない。取り敢えず勘で可能性のある時間
    のかかりそうな箇所に関連した時間計測を依頼したがぴんと来ない。多分、別の所
    に原因があるのではないか。

    2021-02-04 追加報告では遅い時もあるしそうでない時もあるそうだ。後、遅いとは
    言っている割にそれ程遅い訳でもない気がする。単に複数のパス名展開が試みられ
    るのでそれぞれについてタイムアウトが試みられて遅くなっているというだけなの
    ではないか。という訳で、取り敢えずの修正として一度 timeout を起こしたら後続
    の eval も即刻で timeout する様に修正した。

    それから conditional-sync をチェックする頻度も変更する事にする。取り敢えず
    これで改善するかどうか判断する事にする。

    | 後、timeout は total でカウントするべきなのかもしれない。或いは一つ
    | timeout したらそれ以降は timeout が必要になる物はもう処理しない様に変更す
    | る。

    2021-02-05 新しい報告で上記の cumulative timeout & shorter polling interval
    で改善するという事が確かめられた。問題は現在の cumulative timeout によって
    本来短時間で着色できる単語が着色されずに残ってしまう可能性について。

    然し、そもそも cumulative timeout で本当に改善しているのかというのは謎であ
    る。今 highlight_timeout_sync=0 にしている。とすると highlight_timeout_sync
    が効いていないか、或いは highlight_timeout_async の側での cumulative
    timeout が効いているか。highlight_timeout_async の側での timeout が効いてい
    るとすると何故なのか。ユーザー入力がある場合には何れにしても has-input の
    チェックによってキャンセルされるのではないか。うーん。手元で試してみたが余
    り違いが分からない。

    * done: syntax_eval_polling_interval について doc を記述する

  * 展開済みであっても展開される単語の数に比例して遅い (reported by 3ximus) [#D1464]
    https://github.com/akinomyoga/ble.sh/issues/82#issuecomment-772529714

    * 以前大量の入力を与えた時に遅いという事を解決した時に似たような事があった
      気がする。パス名展開がなかったとしても大量の単語を含む配列をコピーすると
      遅いという話。

      前に経験した時にはどの様な事が原因でどのように対策したのだったか。記録を
      漁ってみると #D1302 に関連しそうな内容が書かれている。

      > chars=("${...[@]}" "$@") が 13 秒もかかっている。何故?

      うーん。改めて試してみたがそんなに遅くない。関数経由で代入して改善したと
      いう事が書かれているが、実際に試してみても関数経由で代入すると却って遅く
      なる。またパス名展開の影響かとも思ったが set -f しても大して変化しない。
      結局再現はできない。

      再現ができないので現在発生している問題が具体的にどういう物なのか調べる事
      もできない。取り敢えずまた計測をお願いするしかないのだという気がする。予
      想では cache が巨大である為に起こっている事ではないか。

    * reject: そういう意味では既に議論した様に、単語ごとに展開済みの単純な情報
      を記録する事にして必要になった時は eval まで取りに行くのではなくて一部だ
      け記録する事にするという手もある。

      →今は其処までしなくても良いという気がする。

    取り敢えず simple-word/eval のキャッシュとして完全な情報を記録する物と、最
    初の単語だけ記録する物を用意して、highlighting の内部では主に最初の単語だけ
    を参照する様に変更した。

  * syntax: tilde で始まる単語の着色がされない? (reported by 3ximus) [#D1463]
    https://github.com/akinomyoga/ble.sh/issues/82#issuecomment-772529714

    と思ったがそうでもない。条件が不明

    % notilde 関連かと思ったが違った。どうも evaluate-path-spec が after-sep の時
    % に変な振る舞いをしている。spec の抽出に失敗している。
    %
    % $ ble/syntax:bash/simple-word/evaluate-path-spec '~/work/idt/**/*.sh' after-sep
    % $ declare -p spec path
    % declare -a spec=([0]="~/wo" [1]="~/work/id" [2]="~/work/idt/**/*." [3]="~/work/idt/**/*.sh")
    % declare -a path=([0]="/home/murase/wo" [1]="/home/murase/work/id" [2]="" [3]="/home/murase/work/idt/agh/src/addon/make_latex_embedfont_css.sh")
    %
    % と思ったら単に evaluate-path-spec の使い方を間違っていただけだった。
    % 正しく sep を指定したら evaluate-path-spec の結果は期待した物になった。

    改めて evaluate-path-spec の中で何が起こっているのか調べたら確かに失敗している。

    wtxt='~/**/*.sh' path_opts='stopcheck:timeout-highlight:cached:after-sep' ext='1'
    spec=('~/' '~/**/' '~/**/*.sh')
    path=('/home/murase/' '' '')

    どうも stopcheck の有無で結果が変わる様である。
    ble/syntax:bash/simple-word/eval '~/**/*.sh' stopcheck; ext=$?; ble/debug/print-variables ext ret

    問題を狭めて行った所、原因が分かった。これは単純なミスである。
    command="print-result $word" とするべき所を 'print-result $word' にしていた。修正した。

2021-02-03

  * edit: status line に対応しても良いのではないか [#D1462]

    →改めて確認してみた所、prompt_status_line という設定が既に存在していた。

    ? terminfo tsl/fsl に対応している TERMは存在するのか

      これは terminfo の tsl fsl を使って何かを表示する物だが、実のところ
      tsl/fsl に対応している TERM はなかなかない。少なくとも screen, xterm は違
      う。

      * tmux の term entry には tsl/fsl が存在しているが、シーケンスを見るとこ
        れは prompt_xterm_title と同じ OSC であって間違っている。terminfo の説
        明を読む限りに於いては、tsl/fsl は端末の特別な行で内部ではエスケープシー
        ケンスなども普通に使える物と見られる。という事を考えると、tmux の様に振
        る舞うのは間違っている気がする。

      * cygwin も tmux と同様である。但し、OSC 0 ; ではなくて OSC ; になってい
        る。0 は省略可能という事なのだろう。

      * kterm には \e[?E\e[?..T ... \e[?F という物が登録されている。
      * aixterm は \e[?..T ... \e[?F
      * aixterm は \e[?..T ... \e[?F

      うーん。何れにしても最近の端末エミュレータに存在する様な物ではない気がする
      ので、取り敢えず prompt_status_line は ble.sh の新しい機能の為に使う事にし
      てしまって良い。

    既存の tsl/fsl によるタイトルは別名の設定にする事にする。
    prompt_terminfo_status という名前にでもするか。terminfo だけでなく termcap
    にも存在するようだから、prompt_termcap_status の方が良いのかもしれない。或
    いは、prompt_term_status にするか。

    * status line の区別がやはり付きにくい。背景色を設定できる様にしても良いのではないだろうか。
      元々 trace にその様な機能があった様な気がする。改めて確認する。なかったので新しく実装した。

  * syntax: echo ${!_} と入力すると誤った代入ですというエラーメッセージが表示される [#D1461]
    そもそも "${!_}" を実行しようとするとエラーメッセージが出るが、
    これが着色等の際に発生するのは良くない。何処で発生しているのか確認する必要がある。

    これは新しく追加した ble/syntax:bash/simple-word/is-simple-noglob の中で起
    こしている展開に対して2>/dev/null を付加すれば良かった。未だ master に push していない
    修正なので commit を fixup しようかと思ったが、実装ログが面倒な事になるので、
    下手に fixup するのは止める事にする。

  * benchmark: EPOCHREALTIME は LC_NUMERIC 依存 (reported by 3ximus) [#D1460]

    報告の画像で出ているエラーが何だろうと思って ble-measure の実装を
    見たが変な事はない。と思ったが此処で気づいた。EPOCHREALTIME の小数
    点は locale 依存である。という訳で対策する事にした。

  * global: help の類の整理 [#D1459]
    * bleopt: --help に対応していない
    * blehook: --help が単純すぎる

  * canvas: status line を最終行に表示する可能性 (suggested by 0neGuyDev) [#D1458]
    https://github.com/akinomyoga/ble.sh/issues/85

    元々の提案は vim の mode 名という事だったが、vim の mode 名だけを最終行に表
    示するのか、或いは補完候補等の情報も全て最終行付近に表示するのかという可能
    性がある。Emacs 等を考えると補完候補も最終行に表示するのが自然な気がする。
    なので、実装としては info を丸ごと一番最後に表示する可能性について考えて良
    い気がする。

    最終行に表示する為に必要な事。

    a 一つの方法は \e7 \e8 で現在位置を記録するという事。これは visible-bell で
      既にやっている事。問題になるのは info の内容を構築する時に \e7 \e8 を使え
      ないという事。trace に明示的に禁止・代替するオプションを付ける必要がある
      かもしれない。

    b もう一つの方法は DSR(6)/CPR で問い合わせるという方法。実はこの方法は未だ
      ble.sh には積極的に取り入れた事はない。とはいいつつも歴史的な端末でも軒並
      みこれに対応しているので、全ての端末で使えると思って良い。問題になるのは
      応答に時間がかかるので頻繁に問い合わせる訳には行かないという事。どのタイ
      ミングで問い合わせるのが良いのか非自明であるという点。

    取り敢えず実装としては a の方針を試すのが自然な気がする。実は canvas の
    panel を調整するだけで、他の部分は触れずに実装できてしまうのではないだろう
    か。前にも似た様な事を考えた事があるような気がしないでもない。

    自身の高さ変更だけでなく他の panel の高さ変更の時にも注意が必要。
    特に高さを増やす時。

    * ok: bell を表示する為の行が canvas origin の一つ上に確保されている事に注
      意する。と思ったが、\e7\e8 で移動するのであれば実は余り関係ないという気が
      する。

    ? reject: 間に適当な高さの空 panel を設置すれば良いのではないか、と思ったが
      間の高さが不明なので関係ない。

    * vfill 以降の高さが 0 の時に変な事が起こらないか
      →これについてはちゃんと意識して実装する事にした。

    うーん。取り敢えず実装した。canvas.sh に対する修正だけで大体動いているが細
    かい所で変な事が起こっている。

    x fixed: C-l をしても画面の一番上に移動しなくなってしまう。何故だろうか。
      →これは clear-screen する時に下部に excursion している状態で行っていたので、
      その後 textarea を描画する時に _ble_term_rc で位置が復元されるのが原因だった。

    x 空コマンドを実行した時に info が押し出されて消える。実装を見ると
      ble/widget/.insert-newline の *:keep-info:* が該当する部分だがちゃんと動
      きそうな気がする。と思ったら canvas.sh の panel#increase-total-height が
      未実装だったのを思い出した。

      % と思ったがよく見たらちゃんと実装できている気がする。然し整理した。それで
      % も動かない。そもそも普通に C-q C-j で改行を入力した時も info が消えてしまっ
      % ている。うーん。increase-height に失敗している?

      やっぱり実装できていなかった。端末の高さが十分に高い時は、全体の高さは増
      えない。うーん。制御機能を工夫してこれを何とかする方法は実際に存在するの
      だろうか。勿論 CPR や他の機能を使えば可能なのだろうと思うが基本的な移動と
      IND RI の組み合わせでできない物だろうか。

      うーん。無理の気がする。CUU&CUD の累積でできるのではないかと考えたが、累
      積させる方法が存在しない。


      やはり DECSTBM 等に依存するしかないのだろうか。或いは CPR を利用する。も
      しくは、再描画する。再描画が現実的な気がする、と思ったがサイズが変化する
      可能性がある場合全般に問題が発生するので、やはり現実的ではないように思わ
      れる。うーん。CPR を毎回発行して現在位置を記録する様にした方が良いのだろ
      うか。

      a reject: CPR の可能性について→余り現実的でない気がする

        ble/term/enter の辺りで CPR を発行する様にする事を考えたが。或いは
        ble/textarea#invalidate を発行する度に実行した方が良いのではないか。うー
        ん。然し、描画しようとしている時に即座に返答が帰ってくる訳でもない。と
        いって CPR が帰って来るまでブロックするというのも変だし、続きを async
        に処理するとういのも変である。やはり CPR は飽くまで補助的に使うべきなの
        だという気がする。或いは、画面の大きさが変わる時に初めて CPR 要求を出す
        という考え方もある。然し、そうすると async に処理しなければならなくな
        る…或いはその場で入力を待っても良いのかもしれないが…やはり駄目。別の
        入力を先に受信したりすると変な事になる。

      b done: 再描画の可能性について→呼び出し元で再描画が必要化判定するのは困難なの
        で event を発火するなどして対処する。

        実の所、再描画の為の関数を用意する筈だったので丁度良いのではないか。うー
        ん。再描画というよりは invalidate して、後で再描画するという形にするの
        が良い。invalidate については…。全体を invalidate するというのも考えら
        れるが一部を invalidate するというのも考えられる。矩形で invalidate さ
        れた領域を記録できる様にするのが良い気がする。

        →invalidate を呼び出してそれからそれを記録して、更に次の render の時に
        改めて反映させるというコードを ble-edit/info について新しく書いた。
        ble/textarea に関しては既に実装した関数を適当に呼び出すだけで良いという
        事にする。

      c done: DECSTBM を使う可能性について。取り敢えず最近の端末はこれに対応している
        だろうと想像されるのでこれを使うというので良い気がする。ble.sh 起動時に
        DECSTBM に対応しているかどうかを検出する。

    * done: DECSTBM の判定コード
      取り敢えず判定コードを書いた。

      →と思ったら行が消滅してしまう。うーん。→ IND の代わりに CUD を使って
      DECSTBM をテストする事にした。動いている。OK

    x fixed: cursor-position (DECSTBM が使えない場合) が info の中になってしまっている
      _ble_canvas_panel_focus という変数を用意した。
      然し、それでも振る舞いが変である。

    x fixed: (DECSTBM が使えない場合) 一番最後の行での描画が重複している。

      DECSTBM の有無で振る舞いが逆になってしまっている。これは明らかに
      set-height の振る舞いに (少なくとも片方は) 間違いがあるという事。

      →これは単純にバグだった。

    x fixed: DECSTBM を使っている時に一番最後から二行目が使われない。

      DECSTBM を使わない場合にはちゃんと動いているのでここにも何が間違いがある。

    * util (visible-bell) との干渉について

      x fixed: 実は visible-bell の実装にバグがある。

        RI を使って現在編集のコマンドと被らない様にしているが、実は現在行と被らな
        い様にしているだけであって、実際には編集文字列の2行目以降にいる時には
        visible-bell が上書きしてしまう。

      x fixed: 先頭行の visible-bell で info が消滅する。

      * resolved: _ble_term_{sc,rc} ... util.sh で使っている箇所がある

      * ok: visible-bell の中の trace で sc rc を使えない様にするべきでは? と思っ
        たが、visible-bell は純粋な text という事になっているので今は関係ない。
        将来的には esc seq も指定できる様にする可能性もあるが今は考えない。

    * resolved: ble/canvas 内で他にも _ble_term_{sc,rc} を使っている箇所がある。
      これは曖昧文字幅の問い合わせに使っていた。

    * ok: _ble_term{sc,rc} は edit.sh でも使っている箇所がある。
      →adjust-eol で使っている。これは大丈夫の筈。

    * ok: ble/canvas/panel#report-cursor-position 等については影響がないか確認
      が必要。ble/canvas/panel#get-origin についても。

      get-origin に関しては core-complete.sh で menu の構築で使われている様だが、
      絶対位置として他の panel の座標系と混ぜて使っている訳ではないので問題ない。

      report-cursor-position に関してはパネルの局所座標を引数に指定しているので
      呼び出し元は気にしなくて良い。特に問題も無い様に思われる。

    * done: trace で SC/RC を emulate する (with opts=noscrc)

    * done: bleopt で制御できる様にする

    * blerc に bleopt info_display を追記する。

2021-02-01

  * complete: support "bleopt complete_timeout_compvar" (motivated by 3ximus) [#D1457]
    https://github.com/akinomyoga/ble.sh/issues/82#issuecomment-770390986

    これは progcomp の関数を呼び出す時にパス名展開を実行しているからである。
    一応、応答がなくなるという事はないが補完に不自然に時間がかかるのは避けたい。
    progcomp の為に展開する時は noglob で展開する事も考えたが、
    展開した文字列を quote しているので、noglob で呼び出すと例えば *.txt
    が '*.txt' 等になってしまって意図しない結果になってしまう。

    どの様にするのが良いのかは不明である。或いは timeout したら '*.txt' にして
    しまうというのでも良いのかもしれない。

    bleopt complete_timeout_progcomp_glob=200 等の設定にして、timeout したら
    noglob で呼び出すというので良い気がする。

    retry-noglob-on-timeout という opts を追加する事にする。

    新しい bleopt の変数名は何が良いだろうか。

      complete_timeout_progcomp_glob だと長い。
      それに似たような変数が沢山あって気になる。
      そもそも単に timeout としていると何の timeout か分からない。

      ちゃんとした名前にするなら glob_timeout が良いが長い。
      一単語でこれを表現できないか。fsys_timeout, path_timeout, ...
      やはり専用の単語は存在しない以上は一単語にするのは難しい。
      また、似たような設定をまとめるという立場からすると以下の様な
      変数名で良いのではないかという気もしないでもないが、微妙。

        glob_timeout_progcomp
        glob_timeout_sync_highilght
        glob_timeout_async_highilght
        glob_timeout_auto_complete

      やはり highlight_*, complete_* という名前にしたい。

        highlight_timeout_sync
        highlight_timeout_async
        complete_timeout_auto
        complete_timeout_compvar

    →これは実際に試してみたが改善していない。

  * setup を動詞の様に使っている箇所が多くて気になるので修正する [#D1456]

    set up に代わる動詞を探しても余り良いのが見つからない。文脈に応じて全く違う
    表現に改めた関数もある。set up だけの場合には関数名としてはくっつけて setup
    としても良い事にした。setup-xxx というのは気になるのでせめて set-up-xxx の
    様に変更した。

2021-01-30

  * edit: emoji の表を更新する (reported by endorfina) [#D1455]
    https://github.com/akinomyoga/ble.sh/issues/84

    更新しようと思ったが現在のコードを確認すると色々工夫して高速化している。
    少し面倒である。取り敢えずデータのダウンロードだけは行う事にする。

    https://unicode.org/Public/emoji/

    色々考えて現在のコードの構造に近い形で再実装した。実は以前の実装に
    はバグがあった。

    以前のテーブルは https://github.com/vim-jp/issues/issues/1086 から
    拾ってきた物だったが、これは 2017 年の物だったので報告のあった
    flamingo の絵文字 (2018) は含まれていなかったのだ。

  * syntax: 構文解析で無限ループになっている [#D1454]

    特定のコマンドの編集で固まってしまったので gdb でアタッチしてみたらstack が
    300 段ぐらいまで成長している。問題の起こるコマンドを探ってみると、[[ ]] が
    あるかどうかで振る舞いが変わる様だ。

    [再現]

    $ for f in *; do [[ ]]; done

    に於いて、* の直前に "out/" を挿入しようとすると無限ループになる。 [[ ]] で
    はない別のコマンドの時には発生しない。


    [原因]

    | 構文構造を確かめてみると確かに構造が破壊されている。正常な場合にはちゃんと
    | 単語の chain が繋がって木構造を形成している。しかし、問題が起こるコマンドの
    | 場合、[[ ]] の兄要素が記録されていない。唯、これだけで無限ループになるとい
    | うのも変である。無限ループになってしまう原因も探りたい気がする。
    |
    | 正常時
    |
    | | $ for f in *; do :; done
    | | _ble_syntax_attr/tree/nest/stat?
    | | 18*a    000 'f' | stat=(CMDX w=- n=- t=-:-)
    | |  |*a    001 'o' |
    | |  |*a    002 'r' + word=CMDI:0-3/(wattr=d)
    | | 16*a    003 ' '   stat=(FARGX1 w=- n=- t=$3:-)
    | |  7*a    004 'f' + word=ARGI:@2>4-5/(wattr=d) stat=(FARGX1 w=- n=- t=$3:-)
    | | 36*a    005 ' '   stat=(FARGX2 w=- n=- t=$5:-)
    | | 37*a    006 'i' | stat=(FARGX2 w=- n=- t=$5:-)
    | |  |*a    007 'n' + word=FARGI2:@4>6-8/(wattr=d)
    | | 58*a    008 ' '   stat=(FARGX3 w=- n=- t=$8:-)
    | | 31*aw   009 '*' + word=ARGI:@7>9-10/(wattr=m1:72057594037934596) stat=(FARGX3 w=- n=- t=$8:-)
    | | 12*a    010 ';'   stat=(FARGX3 w=- n=- t=$10:-)
    | | 68*a    011 ' '   stat=(CMDXD w=- n=- t=$10:-)
    | | 20*a    012 'd' | stat=(CMDXD w=- n=- t=$10:-)
    | |  |*a    013 'o' + word=CMDI:@9>12-14/(wattr=d)
    | | 17*a    014 ' '   stat=(CMDX1 w=- n=- t=$14:-)
    | |  2*aw   015 ':' + word=CMDI:@13>15-16/(wattr=72057594037930241) stat=(CMDX1 w=- n=- t=$14:-)
    | | 12*a    016 ';'   stat=(ARGX w=- n=- t=$16:-)
    | |  1*a    017 ' '   stat=(CMDX w=- n=- t=$16:-)
    | | 19*a    018 'd' | stat=(CMDX w=- n=- t=$16:-)
    | |  |*a    019 'o' |
    | |  |*a    020 'n' |
    | |  |*a    021 'e' + word=CMDI:@15>18-22/(wattr=d)
    | |  |    s 022 ^@   stat=(CMDXE w=- n=- t=$22:-)
    | | \_ 'for'
    | | \_ 'f'
    | | \_ 'in'
    | | \_ '*'
    | | \_ 'do'
    | | \_ ':'
    | | \_ 'done'
    |
    | 異常時
    |
    | | $ for f in *; do [[ ]]; done
    | | _ble_syntax_attr/tree/nest/stat?
    | | 18 a    000 'f' |  stat=(CMDX w=- n=- t=-:-)
    | |  | a    001 'o' |
    | |  | a    002 'r' +  word=CMDI:0-3/(wattr=d)
    | | 16 a    003 ' '    stat=(FARGX1 w=- n=- t=$3:-)
    | |  7 a    004 'f' +  word=ARGI:@2>4-5/(wattr=d) stat=(FARGX1 w=- n=- t=$3:-)
    | | 36 a    005 ' '    stat=(FARGX2 w=- n=- t=$5:-)
    | | 37 a    006 'i' |  stat=(FARGX2 w=- n=- t=$5:-)
    | |  | a    007 'n' +  word=FARGI2:@4>6-8/(wattr=d)
    | | 58 a    008 ' '    stat=(FARGX3 w=- n=- t=$8:-)
    | | 31 aw   009 '*' +  word=ARGI:@7>9-10/(wattr=m1:72057594037934596) stat=(FARGX3 w=- n=- t=$8:-)
    | | 12 a    010 ';'    stat=(FARGX3 w=- n=- t=$10:-)
    | | 68 a    011 ' '    stat=(CMDXD w=- n=- t=$10:-)
    | | 20 a    012 'd' |  stat=(CMDXD w=- n=- t=$10:-)
    | |  | a    013 'o' +  word=CMDI:@9>12-14/(wattr=d)
    | | 17 a    014 ' '    stat=(CMDX1 w=- n=- t=$14:-)
    | | 12 a    015 '[' || nest=(ARGX0 w=- n=- t=-:-) stat=(CMDX1 w=- n=- t=$14:-)
    | |  | a    016 '[' |+ word=CMDI:15-17/(wattr=d)
    | | 32 a    017 ' ' |  stat=(CONDX w=- n=@15 t=$17:-)
    | | 12 a    018 ']' || stat=(CONDX w=- n=@15 t=$17:-)
    | |  | a    019 ']' ++ word="none":15-20>@19 word=CONDI:@16>18-20/(wattr=d)
    | | 12 a    020 ';'    stat=(ARGX0 w=- n=- t=$20:-)
    | |  1 a    021 ' '    stat=(CMDX w=- n=- t=$20:-)
    | | 19 a    022 'd' |  stat=(CMDX w=- n=- t=$20:-)
    | |  | a    023 'o' |
    | |  | a    024 'n' |
    | |  | a    025 'e' +  word=CMDI:@19>22-26/(wattr=d)
    | |  |    s 026 ^@    stat=(CMDXE w=- n=- t=$26:-)
    | | \_ '[[ ]]'
    | | |   \_ '[['
    | | |   \_ ']]'
    | | \_ 'done'
    |
    | どうも auto-complete が有効になっていると発生する様だ。
    | 入力のタイミングにも依る。一旦構文解析が終了してから無限ループに入る。
    |
    | 無限ループに入る時の構造
    |
    | | $ for f in out/*; do [[ ]]; done
    | | _ble_syntax_attr/tree/nest/stat?
    | | 18 a    000 'f' |  stat=(CMDX w=- n=- t=-:-)
    | |  | a    001 'o' |
    | |  | a    002 'r' +  word=CMDI:0-3/(wattr=d)
    | | 16 a    003 ' '    stat=(FARGX1 w=- n=- t=$3:-)
    | | 26 a    004 'f' +  word=ARGI:@2>4-5/(wattr=d) stat=(FARGX1 w=- n=- t=$3:-)
    | | 36 a    005 ' '    stat=(FARGX2 w=- n=- t=$5:-)
    | | 37 a    006 'i' |  stat=(FARGX2 w=- n=- t=$5:-)
    | |  | a    007 'n' +  word=FARGI2:@4>6-8/(wattr=d)
    | | 58 a    008 ' '    stat=(FARGX3 w=- n=- t=$8:-)
    | | 59*a    009 'o'    stat=(FARGX3 w=- n=- t=$8:-)
    | |  |*a    010 'u'
    | |  |*a    011 't'
    | |  |*a    012 '/' |
    | | 31 a  s 013 '*' +  word=ARGI:@10>12-14 stat=(FARGI3 w=FARGX3:9- n=- t=-:$8)
    | | 12 a  s 014 ';'    stat=(FARGX3 w=- n=- t=$14:-)
    | | 68 a  s 015 ' '    stat=(CMDXD w=- n=- t=$14:-)
    | | 20 a  s 016 'd' |  stat=(CMDXD w=- n=- t=$14:-)
    | |  | a  s 017 'o' +  word=CMDI:@13>16-18/(wattr=d)
    | | 17 a  s 018 ' '    stat=(CMDX1 w=- n=- t=$18:-)
    | | 12 a  s 019 '[' || nest=(ARGX0 w=- n=- t=-:-) stat=(CMDX1 w=- n=- t=$18:-)
    | |  | a  s 020 '[' |+ word=CMDI:19-21/(wattr=d)
    | | 32 a  s 021 ' ' |  stat=(CONDX w=- n=@19 t=$21:-)
    | | 12 a  s 022 ']' || stat=(CONDX w=- n=@19 t=$21:-)
    | |  | a  s 023 ']' ++ word="none":19-24>@23 word=CONDI:@20>22-24/(wattr=d)
    | | 12 a  s 024 ';'    stat=(ARGX0 w=- n=- t=$24:-)
    | |  1 a  s 025 ' '    stat=(CMDX w=- n=- t=$24:-)
    | | 19 a  s 026 'd' |  stat=(CMDX w=- n=- t=$24:-)
    | |  | a  s 027 'o' |
    | |  | a  s 028 'n' |
    | |  | a  s 029 'e' +  word=CMDI:@23>26-30/(wattr=d)
    | |  |    s 030 ^@    stat=(CMDXE w=- n=- t=$30:-)
    | | \_ '[[ ]]'
    | | |   \_ '[['
    | | |   \_ ']]'
    | | \_ 'done'
    |
    | うーん。変だ。やはり構文解析で起こっている無限ループではない様だ。とすると
    | 何が別の箇所で無限ループになっている。特に auto-complete で起こっているとい
    | う事、応答もしなくなる (SIGINT にも反応しない) という事から、
    | eval-pathname-expansion が怪しいのではないか。
    |
    | やはり /dev/zero で問題が発生しているという事なのだろうか…と思ったが、
    | msleep を read -t を使わない手法に置き換えても同様に無限ループになる事から
    | read -t ... /dev/zero の問題ではない。(それに [[ ]] によって構文構造がおか
    | しくなっている時にのみ発生するという事だから、やはり構文構造に関係のある問
    | 題なのだろう)。
    |
    | * 一つ怪しい箇所は extract-command である。core-complete.sh 関連でコマンド
    |   ライン内部の文法構造に関連する所と言えばこれしかない気がする。→実際に確
    |   かめてみたが無限ループは extract-command とは関係ない所で起こっている様だ。
    |
    | * パス名展開の中で起こっているとも考えにくい。何故ならばファイルの少ない場
    |   所でも問題が発生しているから。それに関数呼び出しが何十段にもなる事から、
    |   関数呼び出し自体で問題が発生しているというのは明らかである。
    |
    | 呼び出されている関数名を調べる事ができれば簡単なのだが難しい。
    |
    | * そもそも本当に auto-complete.idle の中で発生しているのだろうか。と思って
    |   確かめたらどうやら違う様だ。だとすると、bgworker による textarea#render
    |   が怪しい?
    |
    |   調べてみたらそうだった。更に textarea#render の中で怪しい所に絞り込みをか
    |   ける。どうやら update-text-buffer の中で問題が発生している。update-syntax
    |   の問題ではないようだ。update-text-buffer の中では layer/update を呼び出し
    |   ているので、恐らく layer:syntax/update が変な事になっているのだろう。
    |
    |   やはり ble/highlight/layer:syntax/update-word-table の中で無限ループになっ
    |   ている様だ。
    |
    |   ble/syntax/tree-enumerate-in-range で無限に要素が列挙されているか、或いは
    |   ble/highlight/layer:syntax/word/.update-attributes/.proc の中で無限ループ
    |   になっているかである。後者だった。
    |
    |   ble/syntax:bash/extract-command-by-noderef が怪しい。実際に中を調べるとど
    |   うやら ble/syntax/tree#previous-sibling が無限に兄要素を生成している様だっ
    |   た。何故その様な事になるのか。
    |
    | OK. 原因が分かった。
    | 1. 木構造が壊れている
    | 2. 単語情報のシフトに失敗する
    | 3. 兄要素の位置がずれて何も単語が登録されていない位置を参照している
    | 4. 空の単語情報なので兄の相対位置が '' = 0 に評価されて自己参照している。
    | という具合にして空単語でループが出来上がっている。実際に問題が起こっている
    | 時の木構造を見るとその様になっている。

    まとめると二つの問題がある。

    * [[ ]] の解析で構文木の兄情報が欠けてしまっている。nest-push する時に何故
      か tprev が記録されていないのが原因であろう。

    * 木構造が壊れている時に ble/syntax:bash/extract-command-by-noderef の中で
      兄ノードを探索する時に、一旦、空の単語情報に行き当たると自己参照して無限
      に兄ノードを取得してしまうという問題がある。

    [修正]

    後者に関しては、単語がちゃんと登録されているかどうか確認する様に実装を変更
    した。構文木の欠陥があった場合にそれを出力する様にした。これで構文木が壊れ
    ていても無限ループにはならない。

    前者に関しては何処で問題が生じているか分かった気がする。word-cancel した時
    に tprev の情報を復元しきれていないという事。然し、不思議なのは word-cancel
    は単語が設置された後に呼び出されるのだから tprev は既にその新しい値になって
    いる筈だという事。なので、改めて tprev を計算する必要はない筈なのである。

    うーん。もしかして二回連続で word-pop が起こった為に情報が消滅しているとい
    う事だろうか…。つまり nest-pop も既に終わっている状態という可能性?

    →恐らく2回連続で word-pop をした時に、外側の word から順に pop しているの
    がいけないのではないか。内側の word から順に pop するべきという事の気がする。
    いや、それも変だ外側の word を pop する時に内側の単語も全部削除するべきなの
    ではないか。うーん…? 或いは単語を設置する直前の状態に復元するというのが正
    しい振る舞いだろうか。

    改めて振る舞いについて何が起こっているのか考える事にする。

    A B [ [ X Y ] ] という状態になっている。但し [...] が単語の範囲である。そも
    そもどう言った情報が記録されているかというと。

    * 外側の単語については、tchild=(Yの位置), tprev=(Bの位置) になっている。
    * 内側の単語については、tchild=- tprev=- になっている。
    * 二つの単語を設置し終わった時の解析状態は、tchild=(Yの位置) tprev=- である。
    * 一つ単語終端を削除した時の解析状態は tchild=(Yの位置) tprev=(Bの位置) であるべき。
    * 更にもう一つ単語終端を削除した時の解析状態は tchild=- tprev=- になる。
      → word-cancel を2回施した時はこの状態を復元しているという事。

    実際の振る舞いを見ると tprev が初めから空になっている。これは nest-push を
    実行した為の気がする。nest-pop もちゃんと実行しておくべきの気がする? うーん。
    確認してみると別に nest-push した事によって tprev になっている訳ではない気
    がする。どういう事だろうか。そもそも inest=-1 になっている。変だ。

    ※現在の解析状態は "もしここで単語を閉じたらその単語にどの様な tchild,
    tprev が割り当てられるか" を表している。つまり、現在の文脈における
    tchild/tprev ではなくて、一つ上に上がった時の tchild/tprev である事に注意す
    る。

    よく分からなくなった。取り敢えず現在の実装を理解することは諦めて、改めてど
    の様に実装するべきかについて考えてみることにする。word-cancel は二種類の考
    え方がある。それぞれについて適切な実装は何だろうか。

    a 閉じてしまった単語を閉じる前の状態にする。

      この場合には実は単純に word に格納されている tclen tplen をそれぞれ
      tchild tprev に変換すれば良い。

    b そもそも単語がそもそも始まるよりも前の状態に戻す。

      この場合には tchild は記録されている単語の tprev で、tprev については変化
      はない。という事を考えると…。実は現在の実装はこちらを狙った物であると考
      える事ができる。

      この場合には word-cancel は実は一回だけしか呼び出さなくて良い。そして、一
      番外側の単語を削除すると同時に中に設置されている単語も全て削除するべきで
      ある。中に設置されている単語を削除するにはどうすれば良いか。tchild を辿っ
      て削除していく必要がある。面倒な事である。というか、tprev に至る迄を全削
      除で良いのではないだろうか。

2021-01-28

  * syntax/simple-word/eval: キャッシュ機能を付ける [#D1453]

    特に一回の着色 (layer:syntax/update) の中では同じ評価は一回しかしない様に工
    夫したい。キャッシュは dict に保存したいが二種類の問題がある。

    1. eval の展開結果は配列なのでそれをどうにか再評価可能な形式に変換する必要
      がある。bash-4.4 以降であれば ${ret[@]@Q} を用いれば良い。古い bash では
      この形式に合わせて記録を行う。

    2. bash3 では dict がないので工夫が必要

    取り敢えずこれは必要である。

    | うーん。それどころか一つのキーストロークの中でずっとキャッシュしても良いの
    | ではないか。tail 辺りで clear すれば良い。と思ったが余り変な事をしても駄目
    | な気もする。これだと bind 以外の枠組みで syntax/simple-word/eval を呼び出し
    | た時にキャッシュが全くクリアされなくて問題に成るのではないか。
    |
    | 例えば ble/builtin/read を使った時にキャッシュクリアが全くされないという事
    | になってしまう。但し、現在は read に対しては構文着色も auto-complete も有効
    | にしていないが。うーん。或いは widget を呼び出すタイミングでキャッシュをク
    | リアするという手もあるかもしれない…が、やはり ble/textarea#render と同じタ
    | イミングでクリアするのが自然な気がする。うーん。
    |
    | ble/textarea#render の中で clear してしまう? と思ったが、それはそれでやはり
    | 問題になる。将来的に textarea ではない物に対するキーボード操作も考えたいと
    | いう事を思うと、textarea#render の中からキャッシュをクリアするというのはや
    | はり変だ。
    |
    | そもそも汎用性を考えるのだとしたら cache は opts に指定した時にだけ使うとい
    | うので良い気がする。キャッシュをクリアする関数も別に公開しておいて、cache
    | を使う場合には自分でキャッシュの管理をせよという事にすれば良いのである。


    * done: dict を整備する。
    * done: キャッシュする様にする
    * done: キャッシュクリア用の関数を公開する

  * 2021-01-26 util: Cygwin 上で ble/util/msleep がフリーズしてしまう [#D1452]

    | 何故だろうか。普通にユーザコマンドとして実行した場合には特に問題は発生して
    | いない。サブシェルで実行しても問題は発生していない。内部 stty でサブシェル
    | で実行すると問題が起こる?
    |
    | →どうも繰り返し実行すると発生する様である。
    |
    | 以下を実行するとかなりの確率で固まる。
    | ( echo {1..1000} & builtin read -t 0.000100 v < /dev/udp/0.0.0.0/80 ) >/dev/null

    以下によって通常の bash でも固まるという事が分かった。Cygwin 特有の振る舞い
    である。Linux 上で試した限りでは問題は起こらない。

    ( echo {0..1000} >/dev/null & builtin read -t 0.001 v < /dev/udp/127.0.0.1/80 )

    他の実装だと exec 9<(sleep) を起動して置くという物や、builtin sleep を使う
    という物がある。

    a builtin sleep

      builtin sleep はコンパイラが利用可能なときにしか使えないのでこれに依存し
      たくない。飽くまで exec 9<(sleep) を使って実装して可能であれば builtin
      sleep を使うという様にする形になる。

    b 現在の /dev/udp/0.0.0.0/80 を弄って解決できないか

      うーん。不思議だ。'echo {1..1000}' を a.sh に書き出して置いて以下の様にす
      ると再現しない。

      ( . a.sh >/dev/null & builtin read -t 0.001 v < /dev/udp/127.0.0.1/80 )

      関数を function a { echo {1..1000}; } として a>/dev/null とした場合は再現する。

      * builtin read は read に置き換えても発生する。
      * 0.0.0.0 を 0.0.0.1 にすると通信エラーになって別の意味で使えない。
      * 127.0.0.1/80 でも再現する。
      * >/dev/null を >a.txt にしても再現する。
      * read を試みる前に様々なリダイレクトをしてみても状況は変わらない。
      * {0..1000} の部分や 0.001 の部分を変えると発生確率が下がる。

      うーん。微妙。というか環境が Cygwin だけというのであれば、最初からバイナ
      リを用意しておくという手もある。

      うーん。やはり Cygwin ではもっと別の実装を考えた方が良いだろうか。

    c exec 9< <(sleep)

      改めて exec 9< <(sleep) を試してみた所、遅延は殆どない様なので、これを採
      用する事にする。

    思えば今までにも時々あった Cygwin で固まってしまう問題はこれが原因だったの
    かもしれない。直前に fork してから is-stdin-ready を確認する機会が余りなかっ
    たり、或いはその他の条件で発生しにくかったりして再現しにくかったという事の
    気がする。という事を考えるとやはり /dev/udp/0.0.0.0/80 は今後は使わない方が
    良い気がする。

    →c の方法を使う事にした。古いコミットを参考にしてコードを復元する。
    8bb54be acb7163 d14557c f53c26d

    また udp によるコードを使いたくなるかもしれないので、取り敢えず今の所は
    bleopt internal_msleep_socket というオプションで udp 方式に切り替えられる様
    にしてコードを残しておく事にする。

    ----------------------------------------

    procsubst による実装に切り替えてもやはり同様の問題が発生する様だ…。
    うーん。どうした物だろうか。というかこれは bug-bash に報告しても良いのではないか。
    然し、normal Bash で再現させようとしても再現しない。然し症状としては同じなので、
    Cygwin における read のタイムアウトに問題があるという事は確かなのだろう。

    うーん。やはり Cygwin 用に特別にコンパイル済み sleep builtin を提供する?

    今試したら fifo が Cygwin 上でも動く様になっている。最近動く様になったのだ
    ろうか。或いは cygwin バージョンの問題だろうか。うーん。取り敢えず試しに動
    かしてみて、それで失敗したら procsubst に切り替えるという作戦にする。

    →駄目。やはり同じ問題が発生する。FIFO でも駄目という事。
    read -t を使うのが本質的に駄目という事なのだろう。
    唯、確率は格段に小さくなっている。

    sleep 10 | { echo {1..1000} >/dev/null & read -t 0.001 v; echo end; }

    この様にしている時には特に問題も発生しない様だ。

    builtin read -t "$v" v < "$$.pipe"

    この実装にしても固まる時には固まる。

    % 何と、builtin sleep を使っても同様に固まるという事が判明した。
    % つまり、read -t の問題ではない。Cygwin 自体に問題があるという事?
    % スレッドが停止するともう二度と動かないという種類の何か…。
    % →と思ったら勘違いだった。builtin sleep を使っているつもりが、
    % 別の方式をつかっていたのだった。

    一応 /dev/zero は期待通りに動く。但し、CPU 100% になるという事には注意する。
    短時間の sleep であれば /dev/zero に頼っても良いかもしれない。と考えたが、
    短時間の sleep を繰り返し使う場合などを考えるとやはり cpu100% になるのは好
    ましくない気もする。

    /dev/ptmx を試してみた。これはちゃんとブロックするし、勝手に停止してしまう
    事もないが代わりの問題として bash が終了しなくなってしまうという物がある。
    然し、通常の bash で同様の事をしても特に問題は発生しない様だ。何故だろうか。
    というか exec 9<&- を実行しようとしただけで固まってしまう。これは問題である。

    ble/util/msleep/.use-read-timeout socket check
    ble/util/msleep/.use-read-timeout fifo.exec2 check ||
      ble/util/msleep/.use-read-timeout procsub
    ble/util/msleep/.use-read-timeout fifo.open1
    ble/util/msleep/.use-read-timeout zero.open1
    ble/util/msleep/.use-read-timeout zero.exec1

    --------------------------------------------------------------------------

    結局 loadable builtin を使う事にしようと思って実装したが…。loadable
    builtin のライセンスはどうなっているのだったか。普通に考えるとこれは GPLv2
    に感染する気がする。という事は loadable builtin のソースコードをつけて配布
    するのは難しいという事になる。うーん。loadable builtin ならば OK という訳
    は…ないだろう。GPLv2 的に。調べたら正にそういう項目について記述されていた。

    https://www.gnu.org/licenses/gpl-faq.ja.html#GPLAndPlugins

    従って loadable builtins を使う方針は採用できない。結局、他の手法について考
    える必要があるのである。或いは確率が小さければ cygwin でも read -t を使って
    大丈夫だろうか、と思ったが conditional-sync を使っている限り、従来よりも格
    段に問題が起こる確率が高い。やはり read -t は諦めるべきだろうか。

    或いは conditional-sync の時だけ別の方法を用いるという可能性もある…。が、
    別の方法に心当たりがある訳ではない。どうしようもない。バイナリを添付する訳
    にも行かない。

    --------------------------------------------------------------------------

    取り敢えず /dev/zero では未だ hang が起きた事はないので、これで様子見する事にする。

  * util,syntax,complete: 配列内容の記録時に @Q を使った print に切り替える [#D1451]
    大した高速化ではないと思うがコードの整理も兼ねて。

  * syntax: auto-complete 内部の pathname-expansion についても conditional-sync を使う (motivated by 3ximus) [#D1450]
    https://github.com/akinomyoga/ble.sh/issues/82 (for auto-complete)

    取り敢えず [[ :$comp_type: != *:sync:* ]] の時には stop_check で実行して、
    それ以外の場合には強制的に実行するという方針で行く。

    ble/complete/util/eval-pathname-expansion に関してはそんなに面倒そうではない。
    ble/complete/util/eval-pathname-expansion は常にグロブパターンを伴って呼び出されるので場合分けは必要ない。
    常に conditional-sync を使えば良いのではないかという気がする。
    うーん。 *:sync:* が含まれる時だけはそのまま展開を実行する。
    →eval-pathname-expansion については対応した。恐らくこれで良いだろう。

    次に complete の内部から沢山の simple-word/eval を利用している。
    これらについても一つずつ確認して行く必要がある。

    以下の四つの関数が core-syntax.sh における stop_check を指定して実行するべき関数である。
    実際に使われているのは前者2つだけの様である。

    - ble/syntax:bash/simple-word/eval
    - ble/syntax:bash/simple-word/evaluate-path-spec
    - ble/syntax:bash/simple-word/detect-separated-path
    - ble/syntax:bash/simple-word/locate-filename

    |   $ grc 'simple-word/(eval|locate|detect)' lib/core-complete.sh
    | f lib/core-complete.sh:1970:    ble/syntax:bash/simple-word/eval "$subword" "$eval_opts"
    | f lib/core-complete.sh:1980:      ble/syntax:bash/simple-word/eval "$subword" noglob
    |   lib/core-complete.sh:2006:  ble/syntax:bash/simple-word/eval "$ret"; local value1=$ret
    |   lib/core-complete.sh:2011:      ble/syntax:bash/simple-word/eval "$ret"
    |   lib/core-complete.sh:2072:    ble/syntax:bash/simple-word/eval "$ret"; word=$ret
    |   lib/core-complete.sh:2093:          ble/syntax:bash/simple-word/eval "$ret"; left=$ret
    |   lib/core-complete.sh:2806:      ble/syntax:bash/simple-word/eval "$word" &&
    |   lib/core-complete.sh:2861:    ble/syntax:bash/simple-word/eval "$ret*" && ((${#ret[*]})) &&
    |   lib/core-complete.sh:3048:  local ret; ble/syntax:bash/simple-word/eval "$pattern"
    |   lib/core-complete.sh:3050:    ble/syntax:bash/simple-word/eval "$pattern*"
    |   lib/core-complete.sh:3223:    elif ble/syntax:bash/simple-word/eval "$reconstructed"; then
    |   lib/core-complete.sh:3229:        ble/syntax:bash/simple-word/eval "${reconstructed::${simple_ibrace#*:}}"
    |   lib/core-complete.sh:3234:      # Note: failglob により simple-word/eval が失敗した時にここに来る。
    |   lib/core-complete.sh:3624:  ble/syntax:bash/simple-word/evaluate-path-spec "$word0"; spec0=("${spec[@]}") path0=("${path[@]}")
    |   lib/core-complete.sh:3625:  ble/syntax:bash/simple-word/evaluate-path-spec "$word1"; spec1=("${spec[@]}") path1=("${path[@]}")
    |   lib/core-complete.sh:3705:        if ble/syntax:bash/simple-word/eval "$common_reconstructed" &&
    |   lib/core-complete.sh:3731:             ble/syntax:bash/simple-word/eval "$notilde$ret" noglob &&
    |   lib/core-complete.sh:3733:             ble/syntax:bash/simple-word/eval "$notilde$common_reconstructed" noglob &&
    |   lib/core-complete.sh:3761:                 ble/syntax:bash/simple-word/eval "$ret" &&
    |   lib/core-complete.sh:4206:      ble/syntax:bash/simple-word/eval "$ret"
    |   lib/core-complete.sh:4706:        ble/syntax:bash/simple-word/eval "$ret"
    |   lib/core-complete.sh:4930:  ble/syntax:bash/simple-word/eval "$ret"
    |   lib/core-complete.sh:5573:      if ble/syntax:bash/simple-word/eval "$ret" && local compv_new=$ret; then
    |   lib/core-complete.sh:5968:      ble/syntax:bash/simple-word/eval "$ret" || continue

    - ble/complete/progcomp/.compvar-generate-subwords/impl2
      この関数は eval を呼び出している。複数の単語に展開される時にそれを全て取得している。

    - ble/complete/source:argument/.contains-literal-option
      この関数は noglob を指定して変換を試すべきの気がするのでその様に変更する。

    - ble/complete/progcomp/.compvar-quote-subword

    - ble/complete/source:argument
      failglob で展開に失敗した時に * を付加して再度挑戦するのに使っている。
    - ble/complete/source:glob
    - ble/complete/candidates/.pick-nearest-sources
    - ble/complete/candidates/determine-common-prefix
    - ble/complete/candidates/determine-common-prefix/.apply-partial-comps
      ここでは evaluate-path-spec を使っている。
    - ble/complete/insert-common

    以上は候補生成時に使われる関数群である。
    全てユーザー入力があったらキャンセルという形で良い気がする。
    元々 148 を返す仕様の関数になっているので 148 の伝播についても面倒な対応は不要。

    - ble/complete/menu-filter
      これは .filter-candidates の戻り値を返すのを忘れている気がする。
      →修正した。

    - ble/widget/auto_complete/self-insert
      これは微妙。どの様にすればよいだろうか。
      timeout はまあいらない気がする。
      ユーザー入力によって interrupt されたらそのまま false を返せば、
      auto_complete モードから抜けるという動作になる。これで良い。

    - ble/complete/source:sabbrev
      % 展開した結果が使用されていない。バグが有る気がする。
      % →と思ったが iniitialize の中で参照されていた。

    [修正]

    * done: 毎回 timeout 等を設定するのは大変なので関数を用意する。
    * done: simple-word/{eval,evaluate-path-spec} の呼び出しを置き換える。

    x timeout した時に 142 を返すのを 148 に置き換えているが、
      これだと auto-complete 内部で timeout した時に、
      後続の idle まで中断してしまうのではないだろうか。

      →これは idle.do の側で修正する事にした。そもそも IS_IDLE で条件を差し替
      える事ができるようにしているので、呼び出した task の終了ステータスを信用
      する訳には行かない筈なのだ。

      此処で気になるのは complete における 148 の意味が必ずしもユーザ入力ではな
      くて、auto-complete における timeout の場合もあるという事になってしまった
      事だが、これが重大な結果を生み出す様には思われないので、取り敢えずはこれ
      で良いとする。

  * highlight: グロブパターンが含まれるファイル名の着色が遅い (reported by 3ximus) [#D1449]
    https://github.com/akinomyoga/ble.sh/issues/82 (for highlighting)

    glob expansion を subshell で実行してユーザー入力があったら timeout させる
    方針について考察。timeout は必要だろうか。

    * 或いは、もういきなり中断しても良いかもしれない。着色は次の rendering の時
      に反映させれば良いという発想。然し、その場合には再 rendering を発生させる
      為にどうにかして部分 invalidate しなければならない。或いは再描画の条件に
      着色未完の状態を含めても良いのかもしれない。着色の更新に関しては
      ble/textarea#update-text-buffer を呼び出した時に実行される。実は dirty
      range の有無に関わらず毎回 layer/update は呼び出される様だ。考えてみれば
      region の着色等は dirty range に関係なく変化する可能性があるので、この振
      る舞いも妥当である。

      一般に単語着色に関してはユーザーの入力があったら中断してしまって良いので
      はないだろうか。background worker の方で処理する事にすれば良い (但し、
      bash3 だと判定できないので難しい。bash3 に関しては loadable builtin が使
      えれば自前でそれを使ってしまうという手もある)。

    * キャッシュする可能性。同じ単語が繰り返し使われている場合に処理を短縮する
      為。これは特殊な場合にしか効果が現れない。余り効果はないのではないかとい
      う気がする。

    * globpat が含まれる場合にだけ subshell 実行する?
      globpat があるかどうかに関しては正規表現で判定すれば良い。

      "**" が含まれる場合にだけ subshell 実行するという可能性も考えたが、"*" や
      "?" だけでも大量のファイル名に展開される可能性もあるので、"*" だけ特別扱
      いしても仕方がない。

    * reject: ファイル数が多いディレクトリだけで subshell 実行する?

      ディレクトリ移動はそんなに頻繁に行わない筈なのでファイル数をディレクトリ
      移動をする度に確認すれば良いのではないか。と思ったが引数に
      dir1/dir2/... と指定する事もできるのでファイル数が多いディレクトリに現在
      いるかどうかという情報は余り当てにならない。

      "/" が含まれるかどうかを事前に判定する可能性もあるが、変数展開の中に / が
      含まれる可能性もあるので、完全に判定するのは難しい。

    * そもそも単語が単純な場合には展開の操作すら必要ないのではないか。

      {} も quote も history expan も param も ~ もない場合。

    [実装]

    * done: 取り敢えずユーザーからの入力がある場合には着色を中断する。サブシェ
      ルの中で実行する。後で着色し直す可能性については取り敢えず考えない。

      取り敢えず実装してみたが、微妙。とにかく入力を続ければ応答が全くないとい
      う訳ではないが、常に位置文字分だけ遅延している。何故だろうか。一文字だけ
      次の文字が来ている場合に次の文字が来ているという事を検出できていないとい
      う事だろうか。うーん。ble/decode/has-input の問題であろう。

    * done: simple-word/eval-noglob を eval ... noglob に書き換える

    * done: 以下の関数の呼び出し元で適切に stop_check を設定する様にする?

      ble/syntax:bash/simple-word/detect-separated-path
      ble/syntax:bash/simple-word/evaluate-path-spec
      ble/syntax:bash/simple-word/locate-filename

      特に bash3 で stop_check を行うかどうか。bash3 で stop_check をしたとして
      も常に is-stdin-ready は false になるので、唯単に今まで通りにブロックされ
      るだけである。然し、そうであるならば最初から subshell を生成する必要もな
      い。やはり bash3 では stop_check を省略する様に工夫する必要があるのではな
      いか。と思ったが、それならば simple-word/eval の側で bash3 では
      stop_check しないという様にしても良い気がする。
      →その様にする事にした。

      結局上記の3関数では常に stop_check を指定して、
      bash3 についての特別な取り扱いは simple-word/eval の側で実装した。

    * done: 以下の関数について 148 を返した時の振る舞いを正しく実装する。

      148 を返した時に現在はエラー着色にしているが、
      そうではなくて着色せずに抜ける事にする。

      ble/syntax:bash/simple-word/evaluate-path-spec [done]
        ble/syntax/progcolor/word:default/.highlight-filename [done]
          ble/syntax/progcolor/word:default [ok]
      ble/syntax:bash/simple-word/locate-filename/.exists [done]
        ble/syntax:bash/simple-word/locate-filename [done]
          ble/syntax/progcolor/word:default [ok]
        ble/syntax:bash/simple-word/detect-separated-path [done]
          ble/syntax/progcolor/word:default/.detect-separated-path [done]
            ble/syntax/progcolor/word:default [ok]

      取り敢えず ble/syntax/progcolor/word:default まで行って抜ければ、
      単語情報として何か間違った物が登録される事はない。

    x ok: ble/decode/has-input で次の文字が来ている判定しているが、一文字分だけずれ
      がある様に見える。何が起こっているのか調べる必要がある。

      調べてみると既に次の文字は受信している様である。
      問題は未だ処理しきっていないのに描画が実施されているという事である。
      コールスタックを見るとちゃんと EPILOGUE から呼び出されている。
      つまり、ちゃんと文字を処理してからという事になっている筈である。

      と此処で理由が分かった。入力した文字を表示する為に配色を計算しているのだから、
      配色を計算している間は未だ文字が描画されないというのは道理である。
      やはり timeout を入れないと変である。

      conditional-sync に timeout 機能も付ける事にする。

    * done: 着色せずに抜けた場合にはその事を記録に残す (progcolor_dirty)。
      これは ble/syntax/progcolor/word:default に対して実行すれば良い。
      或いは idle に bgworker を登録するだけでも良い?
      と思ったが、それだと沢山の bgworker が生成されてしまう気がする。
      idle に bgworker を登録するとしても、
      未着色単語がある事の情報は何処かに記録する必要がある。

      実は未着色範囲を管理した方が自然な実装になる気もする。
      例えば _ble_syntax_word_async_u{min,max} 等の変数に記録する。
      bgworker ではこれを _ble_syntax_word_u{min,max} に反映させて
      その上で着色を実行する…と思ったが shift 等の取り扱いがどうなるのか分からない。
      _ble_syntax_word_u{min,max} の場合にはどの様にしていただろうか。
      というより、_ble_syntax_word_u{min,max} が設定されるのはどのタイミングだろうか。

      % うーん。ble/syntax/parse/touch-updated-word で変更している。そしてこれは
      % ble/syntax/parse の中で呼び出される物である。一方で、ble/syntax/parse は
      % ble-edit/content/update-syntax から単体で呼び出される事もある。という事を
      % 考えると、此処で設定された _ble_syntax_word_u{min,max} は処理される事なく
      % 次の ble/syntax/parse に伝播する可能性があるという事。その時に必要になる
      % と考えられる shift が実行されていない。
      %
      % _ble_syntax_attr_u{min,max} についても同様である。これらもちゃんと shift
      % する必要がある。
      %
      % →と思ったら、ble/syntax/parse/shift の中でちゃんと shift されていた。
      % _ble_syntax_word_ 及び _ble_syntax_attr_ が接頭辞になっていたのだった。


    * done: 着色せずに残っている部分を着色する bgworker を実装する。
      最後まで完了した時に progcolor_dirty を clear する。

    * done: highlight_timeout_background: bg で着色している時の timeout は長めに取る。

    x fixed: 実際に試してみると相変わらず止まってしまう。CPUがぶんぶん回っている。

      調べてみると eval が stop_check なしで呼び出されている。
      stackdump してみると以下の様な呼び出しになっている。
      どうやら simple-word/eval の呼び出し元のチェックに漏れがあった様だ。

      stackdump:
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:27 (ble/syntax:bash/simple-word/eval)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:17 (ble/syntax/progcolor/eval-word)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:5 (ble/syntax/progcolor/word:default/.is-option-context)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:26 (ble/syntax/progcolor/word:default/.impl)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:3 (ble/syntax/progcolor/word:default)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:7 (ble/syntax/progcolor/default)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:31 (ble/syntax/progcolor)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:8 (ble/highlight/layer:syntax/word/.update-attributes/.proc)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:12 (ble/syntax/tree-enumerate-in-range)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:2 (ble/highlight/layer:syntax/word/.update-attributes)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:4 (ble/highlight/layer:syntax/update-word-table)
        @ /home/murase/.mwg/src/ble.sh/out/lib/core-syntax.sh:32 (ble/highlight/layer:syntax/update)
        @ /home/murase/.mwg/src/ble.sh/out/ble.sh:12 (ble/highlight/layer/update)
        @ /home/murase/.mwg/src/ble.sh/out/ble.sh:9 (ble/textarea#update-text-buffer)
        @ /home/murase/.mwg/src/ble.sh/out/ble.sh:75 (ble/textarea#render)
        @ /home/murase/.mwg/src/ble.sh/out/ble.sh:2 (ble-edit/bind/.tail)
        @ /home/murase/.mwg/src/ble.sh/out/ble.sh:17 (ble-decode/EPILOGUE)
        @ /home/murase/.mwg/src/ble.sh/out/ble.sh:78 (ble-decode/.hook)

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

    x ok: 次におかしいのは、既に着色済みの筈単語も改めて毎回着色されている様な気がするという事。

      と思ったらやはり気の所為だろうか。。。今度はちゃんと新しい単語に対しての
      み処理が行われている様な気がする。と思ったが、どうも word:default 自体は
      新しい単語に対してのみ呼び出されているが、simple-word/eval は何度も呼び
      出されているという事の様である。呼び出し履歴を探ると以下の様になっている。

        ble/syntax:bash/simple-word/eval
        ble/syntax/progcolor/eval-word
        ble/syntax/progcolor/word:default/.is-option-context
        ble/syntax/progcolor/word:default/.impl
        ble/syntax/progcolor/word:default
        ble/syntax/progcolor/default
        ble/syntax/progcolor
        ble/highlight/layer:syntax/word/.update-attributes/.proc
        ble/syntax/tree-enumerate-in-range
        ble/highlight/layer:syntax/word/.update-attributes
        ble/highlight/layer:syntax/update-word-table
        ble/highlight/layer:syntax/update
        ble/highlight/layer/update
        ble/textarea#update-text-buffer
        ble/textarea#render
        ble-edit/bind/.tail
        ble-decode/EPILOGUE
        ble-decode/.hook

      うーん。分かった。ble/syntax/progcolor/word:default/.is-option-context で
      全ての引数に対して評価を行っている。ble/syntax/progcolor/eval-word で一応
      キャッシュはしているが、これは一回の着色の内部でのキャッシュであって、着
      色を跨いだキャッシュは行っていない。これはまた別の箇所で対策するべきの気がする。

    x fixed: 展開が timeout した時にエラー着色になっている。
      timeout の時には d で削除する事にしてみたが、
      d ではなく 0 になってしまって黒で塗潰されている。

      どうやら #setattr は g を設定するのであって、
      wattr の指定を行える物ではない様だ。

    * reject: 実は pathname expansion に限らずユーザー入力がある時には単語着色
      は中断して良いのではないだろうか。

      うーん。これは様子見。早く着色が終わる物から順に着色して行かないと、一番
      遅い着色によって他の着色がブロックされてしまう。なので、軽い物は先に処理
      するべき。何段階にも分けるのは現実的でないので、現状は重い単語だけ処理を
      後回しにする事にする。

    x fixed: ble/util/assign の混線に関連して発生していた様々な問題

      x "bash: 予期しないトークン `(' 周辺に構文エラーがあります" というエラー
        メッセージが出る。何処かにバグが有るという事。background で実行している
        時に発生している気がする。先ずは再現性。

      x うーん。操作していると突然 hang して暫くして emacs が起動した

        何やら操作していたら "# reached line_limit_length=10000" に抵触して、そ
        の後に emacs が起動した。2500項目の要素を含んだ "ret=(......) fdsa1
        aaaa" と言った感じの内容が入力されている。これが意味する所は何
        か。_ble_edit_str に内容が展開されているのが原因と考えられるが何が起こっ
        ているのだろうか。

        a ble-decode-char に紛れ込むとは考えにくい。

        b terminal の echo back に引っかかっているとも考えにくい。そもそもその為
          にはそれ専用の escape sequence で囲まなければならないし、それを出力する
          ような事が起こるとも思えない。

        c _ble_edit_str を直接編集している箇所もないだろうし、

        d 一つの可能性は ble/util/assign の混線である。然し、そうだとしても
          ble/util/assign で挿入内容を決定する様な機会があるだろうか。

        TAB は入力していなかったと思う。従って補完が関係している可能性は取り敢
        えず除外する事にする。

        →あー。分かった。ble/util/assign の混線である。conditional-sync で
        timeout した時に動かしていたプロセスを kill するのを忘れていた為に、遅
        延して ble/util/assign の一時ファイルに様々な情報が書き込まれて変な事が
        起こっていたという事。一つ前の問題もこれに関連して発生していた現象であ
        ろうと推測される。取り敢えず再びいろいろ試して問題が再現しないか確認す
        る必要がある。

      x fixed: failglob が発生する様な状況で failglob にならなくなっている。何
        故だろうか。これは瞬間的に timeout になっている所為で、failglob で失敗
        するよりも先に timeout 142 を返して、その為に着色が無効化されているのが
        原因だった。

    * done: glob が有効な場合でも実は最初に noglob で展開を行って、其処に
      rex='[*?]|\[.*\]|[@+!]\(.*\)' が含まれている時に限り改めて
      subshell で実行するという形式にしても良いのではないだろうか。

      これに関してはわざわざ noglob で展開を行わなくても、
      変数代入を実行すれば良いのではないだろうか。
      builtin eval -- "tmp=$word"

    * done: bash3 では globstar を一時的に off にする事も考える。

      然し、そうするとユーザに対して嘘の情報を提供する事になる。本来は一致する
      筈なのに failglob して赤色に着色される等の可能性。そういう事を考えるとや
      はり時間がかかっても良いから着色するか、或いは着色自体を諦めるか。簡単な
      内容の場合には着色を諦めても良いのではという気がする。

      或いは、** が含まれる場合に限って着色を諦めるという手もある。即座に 142
      を出力する様にすれば良い。これで OK

    * done: 変数展開の中まで参照して noglob かどうかを判定する前に、
      先に extract-parameter-names & 変数内容の復元をするべき。

      再び eval の構造を大きく書き換えたが取り敢えずは動作している模様である。
      取り敢えず conditional-sync を経由した展開も動いている様子だ。OK

    x 別項目: 全く同じ内容で eval を連続して2回試すという事が頻繁に起こっている。
      これは何だろうか。やはり eval-word による呼び出しと、それから本当の着色用
      の呼び出しが混ざっているという事だろうか。これに関しては、eval の呼び出し
      をキャッシュする事で対応できる気がする。

      但し呼び出しをキャッシュすると言っても、bash3 でどの様に対処するべきかは
      微妙である。やはり汎用の hash 辞書のインターフェイスを準備するべきかもし
      れない。

      これは調べてみた所、ble/syntax:bash/simple-word/detect-separated-path と
      ble/syntax:bash/simple-word/evaluate-path-spec の二箇所で発生していれう事
      の様である。これは eval の内容をキャッシュする様にすれば解決する話である。
      独立項目で取り扱う事にする。

2021-01-25

  * edit: change default behavior of "C-w" and "M-w" to operate on backward words (reported by 3ximus) [#D1448]

    ? done: C-w の振る舞いを readline に合わせる?

      後、やはりここまで来ると普通の bash との振る舞いの違いが俄然気になってくる。
      やはり C-w は kill-uword ではなくて kill-backward-uword であるべきなのではないか。
      やはり既定で kill-backward-uword にする様に変更する。
      M-w による copy-backward-word についてはどうするか。
      どうも readline の copy-backward-word は widget copy-uword と同じ振る舞いの様である。
      しかし、M-w は元の readline では使われていないし、
      ble.sh の M-w でどの様に振る舞っても問題はない気がする。

    ? ok: C-w で kill-uword する現在の振る舞いに何か理由があっただろうか。
      何か理由があって敢えて現在の振る舞いにしている可能性もある。

      bbbd155f src/edit.sh (Koichi Murase     2019-03-22 07:28:24 +0900 6763)   ble-decode/keymap:safe/.bind 'C-w'       'kill-region-or kill-uword'
      1fc7cbaf ble-edit.sh (Koichi Murase 2017-12-04 20:48:17 +0900 6185)   ble-decode/keymap:safe/.bind 'C-w'       'kill-region-or uword'
      f18485f0 (Koichi Murase 2017-12-04 14:36:52 +0900 4442)   ble-bind -f 'C-w'       'kill-region-or uword'
      3aa7fa66 (Koichi Murase 2017-12-03 18:31:00 +0900 4461)   ble-bind -f 'C-w'      'kill-region-or uword'
      6ca737d2 (Koichi Murase 2015-02-28 12:48:55 +0900  54)   ble-bind -f 'C-w'      'kill-region-or uword'
      ^c68412b (Koichi Murase 2015-02-09 03:13:19 +0900 3381)   ble-bind -f 'C-w'      'kill-region-or uword'

      どうやら一番最初に commit した時から現在の振る舞いだった様だ。
      ここから分かる事は現在の振る舞いに根拠はないという事。
      実装初期に kill-backward-uword がなかったか不完全だった時からこうである可能性がある。
      なので、振る舞いを現時点で変更しても何の問題もない。

      copy-uword vs copy-backward-uword についても全く同じだった。
      最初から M-w は copy-uword になっていた。

    これは他の ble versions にも適用した方が良いと思われるので独立した commit にする事にした。

  * edit ({kill,copy}-region-or): fix unconditionally combined kills/copies (reported by 3ximus) [#D1447]
    https://github.com/akinomyoga/ble.sh/issues/83#issuecomment-766831785

    C-w で無限に文字列が追加されてしまうという事を指摘された。

    % 何故だろう。手許で確認した時には動いている様に見えたのに。と思ったが手許で
    % 試した時は C-k や C-u を使っていたために気づかなかったという事の気がする。
    % →と思ったら分かった。テストのために自分で ble-bind していたが、
    %   その時に kill-region-or を使っていなかった。

    kill-region-or または copy-region-or の中で
    ble/decode/widget/call を用いて widget を呼び出した時に
    LASTWIDGET が {kill,copy}-region-or に書き換わる為に、
    無条件に前回のコマンドが切り取りコマンドであったと判定されてしまうのが原因。
    取り敢えず修正した。ble/decode/widget/* の関数がまた増えてしまったが仕方がない。

  * mandb: man のオプションの情報が文字化けしている [#D1446]

    % キャッシュが全然使われていない。毎回再生成されている様に見える
    % と思ったが、これは単に core-complete.sh が更新されたから、
    % それに応じて更新されているというだけの事だった。

    データを再生成してもやはり同様に文字化けしてしまう。

    調べると nroff は UTF-8 には対応していない様だ。groff は groff -k にて
    UTF-8 に対応する様だ。更に -k に加えて -Tutf8 も必要だった。

    groff ではなくて nroff の時にはどうするのかという問題は残るが、まあ groff
    のないシステムでは UTF-8 の man は存在しないと思って良い気がする。なので取
    り敢えずは気にしない事にする。

  * 2020-11-02 complete: support complete_limit{,_auto} (contributed by timjrd) [#D1445]
    https://github.com/akinomyoga/ble.sh/issues/64
    https://github.com/akinomyoga/ble.sh/issues/65

    これは時間はかかったが無事に merge まで行った。

    * done: source:file において substr を実装する。
    * done: filter を自前で実行する場合には cand/yield 内部での filter は不要。
      これは flag_source_filter=1 を設定して実行する事にした。
    * done: timjrd を README/acknowledgement に追加する。
    * done: complete_limit_reached にリークが存在している。
      ちゃんと source:* や candidates/generate などのコメントに使う変数を記述して、
      それから auto-complete の中で candidates/generate を呼び出す前に local で宣言する。

  * main: nfs の上に _ble_base_run があると問題になるのでは [#D1444]
    取り敢えずローカルに runtime directory を作る時には $HOSTNAME も含める事にした。
    XDG_RUNTIME_DIR 及び /tmp を使う場合には host specific であると期待してその儘にする。

2021-01-22

  * edit: C-w で kill-ring への追加を実装するという事 (suggested by 3ximus) [#D1443]
    https://github.com/akinomyoga/ble.sh/issues/83#issuecomment-764893198

    これについては先ず初めに仕様を確定しなければならない。

    例えば前方を切り取るコマンドの場合には必ず左に挿入する事にする? と思ったが、
    そうすると C-k を連続で使用した時に、切り取られる行の順序が逆になってしまう。

    ? というよりどの様なコマンドが存在しているだろうか。

      | 調べると C-k, C-u, C-w, M-d, M-h で kill-... を実行している。
      |
      | widget 名で言うと
      | - kill-{forward,backward}-{?word,{graphical-,logical-,}line,text}
      |   これの対応は簡単。backward に削除する場合には prepend し、
      |   forward に削除する場合には append すれば良い。
      | - kill-{?word,{graphical-,logical-,}line}
      |   これは微妙。emacs でどの様に振る舞っているだろうかと考えたが、
      |   よく考えてみたらその様に振る舞う物は存在しない気がする。
      |
      |   emacs.rlfunc.txt で対応表を見てみたが、kill-line に対応する
      |   rlfunc kill-whole-line しか振る舞いを確認できる物が存在しない。そして、
      |   この rlfunc kill-whole-line は kill-line と違って、
      |   コマンドライン全体を切り取ってしまうのでやはり振る舞いとして異なる。
      |
      |   と思ったが、実際に readline で実行してみると kill-whole-line は
      |   前回の内容に append する様である。取り敢えず ble.sh でもその様に振る舞う事にする。
      |
      | - kill-region
      |   これは前回の内容は完全に忘れるという振る舞いで良い。
      |
      | - vi_imap/delete-backward-word
      |   これは実は kill-ring には何も影響を与えない様だ。取り敢えず無視する事にする。
      |   readline の vi mode の時には kill するが combine はしない様だ。

      →結論としては、kill-region,kill-region-or 以外の kill-* は全て対象という事。
      kill-backward-* に関しては prepend で、それ以外については append という事。

    ? ok: append/prepend をした時に元々あった内容を上書きするのか、
      新しく項目が追加されるのか。
      →試して見た所、上書きする様である。

    ? done: /.*-range の allow_empty という引数は必要なのだろうか。
      kill,copy,delete に関しては決して指定される事はない。
      replace に関しては大体指定されている。
      指定されていない物は意図的な物かどうか確認する必要がある。

      - ./keymap/vi.sh:3995:    ble/widget/.replace-range "$eol1" "$eol2" "$text"
      - ./keymap/vi.sh:4016:    ble/widget/.replace-range "$eol1" "$bol2" "$text"
        上記二つに関しては eol1<eol2 が保証されているのでどちらでも良い。
      - ./lib/core-complete.sh:5832:    ble/widget/.replace-range "$pos" "$comp_index" "$value"
      - ./lib/core-complete.sh:5865:      ble/widget/.replace-range "$pos" "$comp_index" "$value"
      - ./lib/core-complete.sh:5871:    ble/widget/.replace-range "$pos" "$comp_index" ''
        上記3つに関しても同様に pos<comp_index が保証されている。
      - ./lib/vim-surround.sh:509:  ble/widget/.replace-range "$beg" "$end" "$content"
        operator なので幅0になる事は余りない気がするが、例えば編集文字列が空の時?
        →うーん。その様な場合であっても cs 経由でしかこの operator は呼び出されないので、
        結局、delimiter を使って範囲を切り出そうとする段階で失敗してしまう。
        結局、この operator が空文字列に対して呼び出される事はない気がする。

        もし仮に呼び出される事があったとしても、allow_empty を指定する方が自然。

      replace-range については常に allow_empty という事にする。
      kill,copy,delete については常に not allow_empty という事にする。
      →書き換えた。

    ? done: copy でも同様に振る舞う必要があるだろうか。
      →実際に試してみた所、同様に振る舞う様である。。。

    動かしていて気づいたが、C-k で行末の改行を削除できていない…。
    これは別 commit での bugfix にする事にする。

  * edit: support "bleopt edit_line_type" (motivated by 3ximus) [#D1442]
    https://github.com/akinomyoga/ble.sh/issues/83

    手で一つ一つ logical-line を明示的に指定するよりは、
    一つのオプションで一括で切り替えられる様にした方が良い。
    更に、今まで既定で graphical line を使っていたのを、
    logical line を使う様に変更する事にする。

  * edit (sword): fix definition of sword (motivated by 3ximus) [#D1441]
    https://github.com/akinomyoga/ble.sh/issues/83#issuecomment-764893198

    この質問で具体的に各単語がどのような定義になっているのか説明しようとして
    コードを参照した時に気づいた。sed によって & が置換前の文字列に展開されて、
    変な事になっていたのが原因。

2021-01-17

  * LC_CTYPE の切り替えエラーが出る (reported by 3ximus) [#D1440]
    https://github.com/akinomyoga/ble.sh/issues/81

    実際に確かめてみたら確かにエラーメッセージが出る。
    過去に対策したつもりだったが対策の仕方が間違っていた。
    色々実験した所、結局余計に一つ関数呼び出しをしなければ駄目な様だ。
    自動で stderr を抑制するように書き換える汎関数を作って対応する事にした。

2021-01-01

  * decode (ble-decode-kbd): support various keyseq specifications [#D1439]
    https://github.com/urbainvaes/fzf-marks/pull/41
    https://github.com/urbainvaes/fzf-marks/pull/43

    上記で ble.sh 特有の binding を追加してもらったが、ble-bind がユーザーが自
    由に対応キーを指定できる様に公開されている変数 FZF_MARKS_JUMP の形式に合わ
    ない為に C-g 決め打ちになってしまっている。ble-bind でも bind と同様の形式
    で keyseq を指定できる様にしたい。

2020-12-25

  * edit: f1 で関数定義を表示する時に LESS=-r が効いていない [#D1438]
    これは bash のバグの様である。バグ報告は bug-report でする事にして、
    ここでは簡単に修正してしまう。

  * edit: 2020-12-09 READLINE_MARK, etc. の値が残ってしまっている [#D1437]

    これは ble/textarea#adjust-for-bash-bind によって設定されている値である。
    コマンドを実行する時に復元・保存する様にするのが良いのではないだろうか。

    * 何故か READLINE_LINE, READLINE_POINT が export されている。
      と思ったが、これは ble.sh を bind -x の内部で動かしているからであった。
      READLINE_LINE 及び READLINE_POINT が

    * 普通の bash で実行するとどうなるのかと思ったが、どうやら自分で設定した
      READLINE_LINE 及び READILNE_POINT があっても bind -x の実行と共に削除され
      てしまう様である。

    取り敢えず adjust/restore する様にした。コマンドの実行の間で値が保存される
    様にした。bind -x が実行されても値がクリアされる事はない。

2020-12-20

  * [解消] 2020-09-27 SIGWINCH で job メッセージが出る [#D1436]
    2020-12-20 これは #D1435 と同一の問題であろう。直ったと見て良い。

    SIGWINCH に対して次の様な job メッセージが表示される様になっている。
    [1] 終了 [[ -n $_dotfiles_blesh_manual_attach ]] | [[ -n $_dotfiles_blesh_manual_attach ]]
    これは .bashrc で設定されている関数の一部である。何故?

    調べてみるとそもそも関数ですらなくて、
    これは ble-attach を呼び出す条件の中に含まれているコマンドだと分かった。
    つまり SIGWINCH に際して ble-attach 関連の何かが呼び出されて、
    そして最後に呼び出された ble-attach の呼び出し時のコマンド文字列が何処かに保持されている?
    もしくは再び .bashrc が source されている可能性もあるがやはりそれは変だ。

    2020-10-10 今試してみると再現しない。


  * edit: WINCH 後に偽のジョブ情報が表示される (reported by 3ximus) [#D1435]
    https://github.com/akinomyoga/ble.sh/issues/78

    前回報告を受けていた謎のジョブ終了メッセージについて。
    これは端末のサイズを変えた直後に起こるという新情報を得た。
    3ximus/dotfiles の .bashrc を確認して再現を試みた所、
    git-prompt.sh, prompt_7.sh, ble.sh の組み合わせで再現できた。

    更に設定を最小化していく。どうやら fork があると
    jobs にメッセージが乗る様になってしまうらしい。

    これの回避方法としてどの様な方法があるか。

    a jobs で得た新しいイベントを除去する?
      然し、これの問題点は唯の fork と、
      本当にジョブとして起動したコマンドの区別が付かないという事。

      振る舞いの違いとしては trap handler の中で発生したfork に対応するジョブの
      情報は trap handler を抜けた時に消滅しているという事である。

      但し、バックグラウンドとして起動したコマンドのジョブ情報もtrap handler を
      抜けると消えてしまうのかもしれない。試せば分かるが面倒なので必要になった
      ら確認する事にする。

    b もう一つの方法はシグナルを処理している時は
      jobs の更新は行わないという物。これが妥当な気がする。

      ? この現象が起こるのは WINCH だけなのか、或いは別のシグナルでも発生するのか。
        →確認した所、INT でも同様にジョブ情報に fork が乗る様である。

        trap '(true); jobs' INT

      ? 現在シグナルの中にいるかどうかを判定する方法は存在するだろうか。
        或いは ble.sh の枠組みの中で trap-handler 経由で呼び出されたか
        どうかの情報を用いて判定する?

        trap-handler の中にいるかどうかの判定方法。一つは return を
        使って関数を抜けた時に、直前の exit status を返すか、
        或いは固定の exit status を返すかを見るという方法。
        よく考えたらこれは bash-4.4 以降でしか使えない。
        Bash はこの部分について振る舞いを変更したのだった。

    % 取り敢えず b の方向で実装する事にする。
    % ble.sh の中での jobs の仕様実態について確認する。
    %
    % どうやら指定した名称に対応する jobs が存在するかどうかの確認にも
    % jobs -- "$value" を使用している様である。これについては、偶々
    % value に一致する終了したジョブ名が存在すると jobs -- "$value" を実行する事によって
    % その情報がジョブ情報のリストから削除されてしまう。この問題を回避する為に
    % jobs -- "$value" を実行する為に ble/util/joblist.check を実行しているが、
    % trap handler の中で joblist.check をスキップしてしまうと、
    % そのジョブ情報が正しく拾われずに消滅してしまう可能性が残る。
    % trap handler の内部では jobs はサブシェルで実行するのが良い気がする。
    %
    % 1 done: 何れにしても最初に trap handler の中で実行しているかどうかを確認す
    %   る必要がある。特に ble.sh の実装が原因で発生する変なメッセージを防げれば
    %   良いので、trap/.handler の中でローカル変数を定義する事にする。
    %
    % 2 done: jobs を使っている箇所を確認する。
    %
    %   * util.sh は ble/util/joblist だけでしか jobs を呼び出していない。修正した。
    %   * core-syntax.sh も ble/syntax/highlight/cmdtype/.is-job-name だけで使っ
    %     ている。対策した。
    %   * edit.sh では ble/builtin/exit で終了する時にユーザに確認を求める所で実
    %     行しているが、exit する時には何れにしてもジョブ一覧を出力するので敢えて
    %     直接実行する。変なジョブ情報が出力される事になってしまうがこれは仕方が
    %     ない。
    %   * 他に ble/widget/command-help/.type で jobs -- "" を実行している。これに
    %     ついても修正を行った。
    %
    % 3 動作確認: さて、実際に修正して見た所直っていない。どうも trap を抜けた後
    %   も変なジョブ情報は残っている様である。ユーザのコマンドとして jobs を実行
    %   すれば変なジョブは消えてなくなっているが、bind -x の中から jobs を呼び出
    %   すと全て出力されてしまうという事だろうか。
    %
    %   サブシェルの中で jobs を実行する様にした結果か、余計に大量の偽ジョブが登
    %   録されてしまっている。
    %
    % 改めて bind -x を組み合わせた時の動作についても確認する→うーん。再現した…。
    % WINCH の直後の bind -x の中で jobs を実行すると偽情報が出る。
    % 別の bind -x を一回実行してから次の bind -x で jobs を実行しても再現する。
    % bind -x 以外の入力を行った後でも、bind -x の中で jobs を実行すると再現する。
    % 一回でもユーザコマンドを (空でも良いので) 実行すると、偽情報は出なくなる。
    %
    % こうなって来ると変なジョブ情報が消えるのを待つ作戦に頼るのは困難である。
    % 今までの変更は取り敢えずなかった事にする。

    うーん。trap/.handler の中で jobs を敢えて実行して結果が描画に回る前に
    偽情報をクリアしてしまう事にする。blehook WINCH を実行する前に joblist 更新をして、
    更に実行した直後にも joblist の更新を行う。二回目の joblist の更新では、
    一時的に現れてそれで直ぐに消滅したイベントはイベントとして登録しない事にした。

    これだと blehook WINCH を実行している最中に終了した本当のジョブ終了の情報が
    消滅すrことになるが、実際に blehook を実行している途中に jobs の状態変化を
    Bash が受信するのか不明だし、もしそうだとしても blehook WINCH の処理のよう
    なごく短時間でその様な事が起こる確率は低いと考えられる。なので、気にしない
    事にする。

    取り敢えず動いてはいる様子である。

2020-12-14

  * progcomp: : や = の quote の取り扱い (reported by 3ximus) [#D1434]
    https://github.com/akinomyoga/ble.sh/issues/77

    ? そもそも \=, \: の様にエスケープしていたのは何故だったか。

    ? bash-completion の提供した補完に対して \= や \: の様にエスケープを実施す
      る必要はあっただろうか。その辺りの実装はどの様になっていたのだったか。

    関連しそうな物を探す。ble-0.3 では = のエスケープはしていない。

    #D1133 でコマンド名に関しては =, : の quote はしない様にしている。
    #D1098 6c6bae56 で = や : のエスケープが導入されている。
    #D1094 では = や : による候補の分割を議論している。

    うーん。元々エスケープは #D1098 で導入された物の様だが深くは考察していない。
    改めてどの様に振る舞うのが自然か考察する必要がある。

    * そもそも ble.sh の補完は展開後の結果を生成して貰う前提になっている。
      一方で bash の補完は展開前の結果を生成する事を許容している。
      例えば abc$(echo hello) の様な文字列を補完で生成する事すら可能なのである。
      それどころか複数単語からなる展開結果にする事も可能の筈である。

    * それでは progcomp の結果はそのまま挿入する事にすれば良いのではないか
      とも思われるが此処で問題になるのは、ble.sh の側で適当に展開を実行してから
      COMP_LINE を構築して progcomp に渡しているという事である。

      これは途中に $var 等の単純な展開等が含まれている場合でも
      progcomp で補完を実行できる様にする為に必要。

      この時、progcomp が展開前の補完結果を生成した時に、
      それを如何に元のコマンドライン文字列に反映させるのかが問題になる。

    x [OK] 手許では再現していないが scp chat\:down[TAB] で chat\: が消滅してしまう?

      notepc の方は bash_completion が入っていないので今試せない。
      * chat は port を変えているので localhost: から試そうとしてもできない。
        localhost や chat を .ssh/config に登録してパスワード無しで補完できる様にしたが、
        補完候補は出してくれない様である。
      * hp2019 -> chat を試してみたが再現しない。local にも mkdir downloads したが再現しない。

      うーん。取り敢えずそもそも何故失敗するのか考える?
      plain bash で実行したところ failglob で失敗している。
      shopt -u failglob にしたら ble.sh の中でも補完が動く様になった。

      そして chat\: が消滅してしまう問題に関しては、
      plain bash でも再現する事ができた。
      これは bash-completion の問題である。

      特にローカルのカレントディレクトリに "host:..." というファイルが存在する時に、
      host\:... と入力している可能性があって、この時に host: の部分が消滅してしまう
      という問題が発生する。

      https://github.com/scop/bash-completion/issues で報告をしようかと考えたが、
      もしかすると最新版で直っている可能性もあるので、
      最新版の bash-completion を試してみても良い。

    うーん。progcomp による展開結果が空白などを含んでいる時にどのように振る舞うのか。
    plain bash はそのまま何も加工を行わずに展開してしまう。うーん。
    blesh ではどの様に取り扱うべきか。

    * できるだけ progcomp が提供した quote を保持する様にしたい。
      然し、これは現実的には難しいのではないか。

      a = 及び : についてだけ quote しているかそうでないか保持する? それ以外の
        文字については自分で quote し直す。

        その為には progcomp が生成した単語について = や : で分割を試して、その
        上でそれぞれ quote してから再結合する? これだといかにも処理量が大きい。
        非効率的である。

        これは処理方法として複雑でありユーザから見たら不自然で予測不能に見える
        かもしれない。処理の重さとしては次に述べる方法よりは現実的である。

      b 入力済みの部分に一致する部分を除去してそのまま挿入。

        ここで問題になっているのは既に入力済みの部分に対応する文字列を
        どの様に取り除くのかという事であった。二分法を用いる等して
        これについて既に入力済みの部分を除去する方法はないだろうか。

        どの様にしたら良いのかを調べる必要がある。二分探索で調べるという方法と、
        1 unit ずつ読み取って行くという方法の二種類を考える事ができる。

        * 二分探索で調べるというのは複雑な気がする。元の文字列について途中で切
          断して二分探索していくという手も考えられるが、変数名の途中など変な所
          で切断すると内容が空になるなどして意図しない結果になってしまう。

        * 取り敢えず 1 unit (simple word element) ずつ読み取って行って、切断す
          るという方法? 然し、'...' 等の様に一気に読み取る事ができるliteral 等
          になっているとすると、実装が複雑になる。面倒である。そもそも処理が複
          雑になる。面倒である。

      c 今まで通り基本的に progcomp が生成した物は展開毎と見做して quote を行う。
        = 及び : は基本的には quote を加えない。compopt -o filename で quote が
        明示的に指定された時にのみ =, : の quote を行う。

        これは progcomp が quote を自前で行って候補を生成した時に問題になる。つ
        まり quote が二重に為される事になり、意図しない結果になってしまう。然し、
        この問題は今までにも存在していた問題の筈である。取り敢えずの修正として
        は妥当である。

    取り敢えず今までも quote を勝手にする事による問題はあった。
    全てを一度に解決するのは難しいししなくても良い。
    此処は c の方針で修正する事にする。

2020-12-13

  * README: ((_ble_bash)) && ble-attach だと set -u の時駄目 [#D1433]
    ble.sh ロードに失敗した時や ble.sh を意図的に読み込まなかった時に
    _ble_bash が存在しないので内容をチェックする前にエラーになってしまう。

    [[ ${BLE_VERSION-} ]] && ble-attach にするべき。

2020-12-10

  * complete/mandb: FreeBSD 上で man 情報の抽出に失敗している [#D1432]

    | freebsd には roff, nroff, troff 等が存在していない。
    | それでも man が動作している事を考えると、
    | 何らかの方法で man pages を変換しているという事の筈。
    | それについて調べて対応する。

    対応した。FreeBSD では mandoc というコマンドを使って変換を行っている。
    nroff と同様に -man 等を指定する事ができる様だが、
    どうやら FreeBSD は -man ではなくて -mdoc を想定して man pages を書いている様だ。
    という訳なので -mdoc を前提として抽出をする様に書き換えた。

    ちゃんと nroff を使う版も動いている。OK

  * highlight: command \^J-a とした時に -a がオプションとして着色されない (reported by cmplstofB) [#D1431]
    https://github.com/akinomyoga/ble.sh/issues/76

    現在の着色では \-a や ''-a 等の様に quote がある場合には、
    意図的にオプションとしての着色を避けている。
    そういう意味に於いて \^J-a もやはりオプションの前に quote が
    ある物として取り扱ってオプションとしての着色が無効になっている。

    a 然し意味的に考えるとやはり \^J は単語の一部に含まれない様にするのが自然に
      も思われる。

      ? その様に構文解析を変更する事は恐らく簡単だろうが、単語の一部として解析
        しない部分文字列がコマンドラインに含まれる事による副作用などはあるだろ
        うか。思うにリダイレクションなども単語の一部として登録していないので、
        特にこの事で問題が発生する事はない気がする。

      また sabbrev の単語判定でもやはり語頭の \^J は含まれない様にしたい。

    語頭の \^J は skip する事にする。これはどの様に実装すれば良いか?
    ^J や空白を処理している箇所で一緒に処理すれば良いだろうか。

    取り敢えず構文解析は修正した。多分大丈夫。副作用が起こるかもしれないが、
    それは実際に何かが起こってから見るという事で良いだろう。
    うーん。問題が起こるとすれば二次的に起こる問題ではなくて、
    構文解析自体が変になる可能性が高い気がするが多分大丈夫。

  * color: italic が描画できていないという (by rlanore) [#D1430]
    https://github.com/akinomyoga/ble.sh/issues/73

    試してみると手許では動いている。対応していない端末で使おうとしているのではないか。
    この Issue には返信がないがもう一つの新しい Issue に対して Terminal 情報を載せている。
    Terminator 1.92 を使っている様である。

    Cygwin 付属の Terminator 0.98 は italic に対応していない。
    Cygwin 附属の GNOME terminal は対応している。
    vte のソースコードを見ると 2012 には italic 関連のコードが存在している様だ。
    2014 にまた別のフォント初期化コードが追加されている。然し一方で pango も呼び出している。
    これが実際に X11 環境で使われるのかどうかはよく分からない。

    →これは結局向こうの tmux の設定が問題であった。手許で試して見たところに依
    るとどうも tmux は default-terminal の値に応じて自身の振る舞いも変更する様
    である。これについて wiki の manual にも書いておく必要があるのではないか。
    →wiki に説明を追加した。

  * complete/mandb: ^H が大量に挿入される (reported by rlanore) [#D1429]
    https://github.com/akinomyoga/ble.sh/issues/75

    これは nroff で太字を表現するのに <CHAR>^H<CHAR> を出力する物がある為。
    なので、単に .\b を削除すれば良い。

    取り敢えず修正してみたが本当に動くか微妙。複数の OS で試す必要があるのではないか。
    freebsd で試して見たところ、troff がないので動いていない。
    これについては後で対応する事にする。

2020-12-09

  * complete: 補完候補が更新されない問題 (reported by 3ximus) [#D1428]
    https://github.com/akinomyoga/ble.sh/issues/74

    これは明らかに menu-filter で候補がなくなった時に、
    元の候補を全て表示する様に変更したのが原因である。
    やはり一致しなくなった時点で候補は表示しない様に変更する事にした。

    b 或いは別の変更方法として、候補再生成のフラグを設定して、
      この時にはメニューから候補を拾う事はしない様にする?

      x と思ったが、そうすると結局候補を全て表示する意味がない? 候補を表示する
        のはメニューから選択させる為であるが、メニューから候補を拾わない様にし
        た時点でそれが使えない?

        % x と思ったが連続 TAB や、明示的な menu-complete の bind の時には、候
        % 補の再生成をせずに menu に入る事が可能になる。

        でも連続 TAB の場合は最初の TAB の時点で候補再生成が起こるので、表示し
        ている候補が使われる事はない。明示的な menu-complete の bind についても
        既定では C-TAB 等余り使われなさそうな物になっているので設計に考慮に入れ
        なくて良い気がする。

      此処まで処理を複雑にしても余り有用ではなさそう。次の TAB で候補一覧はすぐ
      に消えてしまうので、絞り込み前の候補一覧を表示しても却って混乱を生むだけ
      である。この選択肢は却下である。

2020-12-08

  * util/term: lxterminal, gnome-terminal で vte の検出に失敗している [#D1427]
    これはソースコードを確認してみた所、xterm の version 抽出コードを追加した時
    に動かなくなった物の様に見える。修正した。