Ble.sh: Support vi-mode

Created on 30 Aug 2017  Âˇ  103Comments  Âˇ  Source: akinomyoga/ble.sh

set -o vi 対応を行う (参照: #1)。

  • 取り敢えずは基本的な操作に集中する
  • 機能に名称はついているのか? → これは bind -p を参考にする。
enhancement

All 103 comments

support-vi-mode ブランチで作業する。
取り敢えず keymap を切り替える機能は整備した daee0b8...f82cbc4

f82cbc4...449dd70 基本的なところは実装した気がする。

挿入モードからノーマルモードへは ESC C-[ C-c で移行する。ノーマルモードでは以下に対応した。

  • 引数
  • i I a A R
  • x X p P
  • yy dd cc Y D C [ydc]?[hjkl] [ydc]?[0$^+-]

未だ対応していないが優先順位の高いものは以下の通り

  • C-h DEL SP | G [編集 (2017-09-10 01:46): 実装完了]
  • w W b B e E [編集 (2017-09-10 01:46): 実装完了]
  • r [編集 (2017-09-10 01:46): 実装完了]

449dd70...14223ec 取り敢えずここまで。後は相談の上で実装の予定

新しく対応したもの:

  • o O gR gI
  • [ydc]?C-h, [ydc]?DEL, [ydc]?SP, [ydc]?[wWbBeE], [ydc]?[fFtT;,]
  • s, S, J, gJ
  • [ydc]?|, [ydc]?[HL], G, gg
  • K
  • 俎正 RET, C-m, I, [ydk]?[-+jk] なお

実装仕様:

  • H と L は現在の編集文字列内の移動で、G と gg はコマンド履歴の移動とした。
  • K は現在のコマンドラインに含まれるコマンド名で cmd --help または man cmd を実行した結果を返す。
  • j, k, +, - は現在の編集文字列の最下行・最上行を踏み越えると、コマンド履歴を移動する。
  • gR および gr の実装は [1] の記述を元にしたが怪しい。vim で試したができなかった(?)
  • 追記: 挿入モードは (ESC で始まるものを削除したこと以外は) emacs mode から殆ど変えていない
  • 追記: a A i I gI o O R gR の引数には未対応である 追記: 実装した 4b68c1cdc9d1ae8379b3f67a343b6312cc8a8497

引用:

  • [1] [vimのノーマルモードのコマンドまとめ (その1) - Qiita](http://qiita.com/sfuta/items/0de4ead865c15e9e9b68#-44)

@cmplstofB (B-bar) さま。ble.sh における vi-mode の基本的なところはできたように思いますので、改めてテストユーザになっていただくこと、お願いしてもよろしいでしょうか。

もし引き受けて下さる場合は、追って以下についてご説明します。

  • 特に確認して頂きたいこと・提案して頂きたいこと
  • ble.sh における複数行編集の方法について

何卒、よろしくお願い致します。

@akinomyoga 様
貴重な時間を割いていただいて申し訳無いです。テストユーザの件ですが、よろこんで引き受けます。
早速ですが、素の urxvt 及び「urxvt 上の tmux で起動した Vim 上の :sh (Zsh の Vim-mode はここでのバグがあります)」とで確認しました。
素晴しいです! 一通り試しましたが、readline 本来の set -o vi と遜色ないです。
ただ、ちょっと気になった点がありました。これは support-vi-mode ブランチでは再現しませんが、そもそも support-vi-mode ブランチでは C 等の操作が出来ませんでした。

  • ble.sh を読み込んだ後に set -o vi 等として vi-mode に移行した場合、vi-mode は実装されていないという旨の警告が表示された後、コマンドラインに stty sane という文字列が入力された状態になります。 行を確定してみると stty sane が実行されたので描画の残り滓という訳ではなさそうです。

@cmplstofB (B-bar) さま。早速のご報告ありがとうございます! 取り敢えずご報告の点について確認させていただいて宜しいでしょうか。

  • これは support-vi-mode ブランチでは再現しませんが、

    再現しないのはどのような動作か詳しく教えて頂けますか。

  • そもそも support-vi-mode ブランチでは C 等の操作が出来ませんでした。

    確認しました。これはとんだミスです…。 ab6bd163b9239739462076dfd137c03c40fa8319 で C と D を修正しました。突貫の修正なので、動作について問題がないか確認して頂けると幸いです。

  • ble.sh を読み込んだ後に set -o vi 等として vi-mode に移行した場合、vi-mode は実装されていないという旨の警告が表示された後、コマンドラインに stty sane という文字列が入力された状態になります。 行を確定してみると stty sane が実行されたので描画の残り滓という訳ではなさそうです。

    master ブランチの話ということで良いでしょうか。分かりにくくてすみませんが、これは仕様です。

    現状の ble.sh では set -o vi されたときに元の readline に戻るようにしています (この動作は一時的なもので support-vi-mode ブランチがマージされた後には新しく実装した vi mode に移行するようにします)。ただし readline に移行する前に仮想端末の状態を元に戻さなければなりません。実は技術的な問題により ble.sh の中からはこの設定を戻すことができないので、ble.sh を抜けた後にユーザに手で stty sane を実行して頂く必要があります。そのために ble.sh はコマンドライン文字列に stty sane を設定して抜けるのです。

    もし master ブランチではなく support-vi-mode ブランチでこれが再現する場合は、何らかのミスなのでその時の状況が分かれば教えて頂けると幸いです。


追ってテストについてご説明いたします。

@cmplstofB (B-bar) さま。特にみていただきたいことは 複数行編集での動作 と 欠けている使用頻度の高いコマンド です。以下、長くなってしまいましたが、気が向いた時に見て頂ければ幸いです。

1. 動作確認: 複数行編集と各コマンド

ble.sh では編集文字列に改行 LF (\n) が含まれているときを複数行編集とし、そうでないときを単一行編集としています。

  • 移行方法: 単一行編集から複数行編集に移るためには LF を挿入する必要がありますが、これには挿入モードで C-v C-j と入力して下さい (emacs mode では M-RET (C-M-m) でもいけます)。
  • 改行挿入/コマンド実行: 複数行編集のときは RET (C-m) は "コマンド実行" ではなく、エディタと同様の動作 ("改行の挿入/次の非空白行頭") としてはたらきます。コマンド実行をするには C-j を入力して下さい。
  • 制限: ターミナルの高さよりも多くの行数を含むコマンドの編集は現在想定していません。

特に複数行編集のときも含めて、ノーマルモードの各コマンドが動作するか確認して頂きたく思います。

  • 特に、さきの C の件のように (下らない間違いで) 変な動作をするものがないか、
  • (できるだけ違和感なく操作できるようにしたいので) 細かい動作で不自然な点・気になる点はないか

2. 提案など

当然 vi/vim の機能を完全に実装するわけには参りませんので、要望の出たものから順に実装していこうと考えています。そのため "このコマンドは自分はよく使うので実装した便利である" というようなものがありましたら、幾つか提案して頂きたいなと考えています。

3. bashrc の設定について

簡単に使用していただいてもし実用に耐えうると判断できる場合には、もしよろしければで問題ないのですが しばらく使用をしていただいて vi mode の動作に問題がないか検証していただきたいなとも考えております。その場合には

  • README-ja_JP.md にある ~/.bashrc の設定をして下さい。
  • また ~/.inputrc にあるキーバインディングの設定や ~/.bashrc にある bind コマンドの設定がある場合は ble.sh では反映されません。ble.sh 用の ble-bind シェル関数によって設定を追加する必要があります。ble-bind -d を実行して頂ければ ble-bind の使い方は大体分かるのではないかと思いますが、質問があればどうぞ遠慮なく申し付け下さい。
  • その他、分からないことがあればどうぞお尋ね下さい。

もし使っている内に vi mode の動作について何か提案などが出てきましたらどうぞお気軽にお知らせ下さい (もちろん vi mode 以外の ble.sh の機能についてでも問題ありません)。

4. 質問

私は普段 vi/vim は使わないので以下のページでどのようなコマンドがあるか調べて、実際に vim でどのように動作するのか調べて、それを模倣して実装するという原始的なことをしています。

ところで、そのようにしても動作が良くわからないものというのが存在します。以下についてお聞きしてよいでしょうか。

  • gr で全角・半角の幅も考慮して1文字上書きすると上記ページには書かれていますが、手許の vim (VIM - Vi IMproved 8.0) で再現しません (エラーになる?)
  • gR で全角・半角の幅を考慮した上書きモードになるとありますが、これも同様に再現しません

たぶん、何か勘違いしているのだと思いますが、もし何かご存知のことがありましたら教えて頂けると幸いにございます。

@akinomyoga 様

長くなってしまいました。すいません。

バグだと思ったのは私の認識不足でした。また、「vi-mode で再現」云々はその stty sane について述べているので既に自己解決しています。

動作確認

と

bashrcの設定

については ble.sh を vi-mode で常用させていただく形で使用します。
しかし失礼ながら学校でサーバ等に対する操作として使うには今の段階で少し怖い面もあるので、基本的に家の Debian 9 のみで使わせてください。
その結果、報告のペースが @akinomyoga 様の想定より遅れることと思います。申し訳無いです。

いまの所、不具合らしきものとして、

  • ノーマルモードから挿入モードに移った直後くらいに C-c、C-m 等及び通常のキー入力が「そのようなキーは設定されていない」という警告とともに無視される時がある。

  • 複数行編集において、最初の行を削除した後に移動モードが機能しない。

しかしその孰れもその正確な再現がまだ出来ない(上手くいくときもある)ので、ある程度使って場数を踏んでから詳細を報告します。

質問

仮想置換モードのことですね。
私の環境 Vim 8.0 1-992 (多分最新版) では特に問題はなかったです。

  • 「あ」の上で gra と打つと、文字「あ」の幅が考慮され、「a」となります。(従って、文字数は変動しますが画面上では「あ」以降の文字はずれません)

  • また「あ」の上で ra と打つと、文字「あ」は一文字なので、「a」となります。(「あ」以降の文字は画面上ではずれますが、その行の文字数は変化しません。)

念の為仮想端末(urxvt)及び端末多重化ソフトウェア(tmux)、Vim が解釈する文字幅を変えてみましたが全ての場合において問題なかったです。

提案

Bash の vi-mode にはないのですが、テキストオブジェクトを実装して欲しいです。Zsh の vim-mode では実装されています。
というかそもそもテキストオブジェクトは Vim の機能ですので vi-mode に実装するというのは少し不自然ですが、個人的には非常に重宝しているので是非とも欲しいです。

テキストオブジェクトについて以下に簡単に説明します。

テキストオブジェクト

テキストオブジェクトというのは簡単に言うと、「マウスの単語上でのダブルクリックのキーコマンド版」です。
例えば次の文がメモ帳などのテキストエディタにあったとして、(ブラウザやコンソールでも同じです)

Lore ipsu dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

"ipsum" という単語の上でダブルクリックするとその位置に拘わらず "ipsum" という単語全体が選択されると思います。これは Bash の Emacs モードだと \eb(選択開始)\ef(選択終了) という動作で模倣できると思います。

テキストオブジェクトはそうした範囲に対して一定の操作を施すという概念です。めちゃ便利です。
実際私は ble.sh に移行する前に似非テキストオブジェクトとして、カーソル位置の単語全体を引用符で囲む \xqと\xQ というコマンドを

```rc:~/.inputrc

~/.inputrc

"\eq": "\eb\"\ef\""
"\eQ": "\eb\'\ef\'"
```

という感じで実現していました。めちゃ便利です(しつこい)

Vim におけるテキストオブジェクトはノーマルモードにおいて {operation}iw に割り当てられています。{operation} には c``d``y があります。
例えばノーマルモードでカーソル以下の単語を別の単語にしたい時は ciw と打った後新しい単語を入力します。
本当はもっと沢山種類があるのですが、とりあえずこの {operation}iw だけでも欲しいです。

尚、上述した \xq は Vim では ysiw" です。ややこしくてすいません。(ysが「範囲の両端に操作を施す」、iwが「単語全体に」、"が「"を入力せよ」と分解できます)

@akinomyoga 様
ble.sh における vi-insert モードでの C-o は "accept-and-next" となっていますが、vi/Vim の標準では「次に入力される「一回」のキー[^1]をノーマルモードに対するキーとして解釈し実行した後、再び挿入モードに移る。[^2]」という設定になっています。
Bash 及び Zsh, Fish では実装されていません。私個人としては欲しいことは欲しいですが、この機能はあまりにエディタ的で、シェルの機能を逸脱しているようにも思うというのもあります。
とりあえずの希望としては C-o を未定義(この「未定義」は ble.sh(ble-bind) における nop です)にしていただくと嬉しいです。

私が悪いのですが、何気無く C-o を入力したところプロンプトの行が実行されてしまい驚いたので。

@cmplstofB (B-bar) 様

早速、ありがとうございます!

その結果、報告のペースが @akinomyoga 様の想定より遅れることと思います。申し訳無いです。

いえお気になさらないで下さい。先の返信にて大量に文章を書いてしまったせいで圧力をかけているようになってしまって申し訳ないです。こちらの想定では、ble.sh を使っているということを余り意識せずに暫く使っていただいて、もし気になることが自然に出てきたらその時点で報告して頂ければと思っておりました。また、やはり ble.sh は駄目だという気になったらいつでも見放しで頂いて問題ありません。

いまの所、不具合らしきものとして、

  • ノーマルモードから挿入モードに移った直後くらいに C-c、C-m 等及び通常のキー入力が「そのようなキーは設定されていない」という警告とともに無視される時がある。
  • 複数行編集において、最初の行を削除した後に移動モードが機能しない。

いまのところ、こちらでは再現しませんね…。暫く様子を見てみます。

質問

仮想置換モードのことですね。
私の環境 Vim 8.0 1-992 (多分最新版) では特に問題はなかったです。

なるほど! ご説明を読みますに私が想像した機能のようで間違いないようですね…と思って改めて調べてみましたら vi で起動すると有効にならないのですね (@ Fedora 25)。vim で起動したところ確認できました。ありがとうございます! vim 素人なので、勝手に vi/vim のどちらで起動しても機能的に同じなのかと勘違いしておりまして、お騒がせしました。

Bash の vi-mode にはないのですが、テキストオブジェクトを実装して欲しいです。Zsh の vim-mode では実装されています。

これば便利そうですね。テキストオブジェクトについて承知しました。vimindex を見るといろいろありますね。振る舞いを色々調べてから実装することにします。

ble.sh における vi-insert モードでの C-o は "accept-and-next" となっていますが、vi/Vim の標準では「次に入力される「一回」のキー[^1]をノーマルモードに対するキーとして解釈し実行した後、再び挿入モードに移る。[^2]」という設定になっています。

これは実装することにします。

実は挿入モードは emacs mode をベースにして未だ余り弄っていないので、気になることは他にもあるのではないかと思います。Vim の動作の中にシェルとしての機能 (コマンド実行、履歴検索など) を織り込まなければならないので、どの程度残すのが良いのかというのも意見を伺いたい点の一つです。

因みにシェルの機能としての C-o は過去に連続して実行したコマンドを同じ順序で連続して実行するときに使うものですね。例えば

$ gcc a.c
$ ./a.out

の後に up up としてコマンド履歴から gcc の行を取り出したあと、C-o を連打するだけで gcc a.c と ./a.out を繰り返し交互に実行するということができたりします。

@akinomyoga 様
色々実装していただくことになり感謝しています。お手を煩わせて申し訳無いです……。

emacs-mode の C-o も使い慣れると便利ですね。
Vim で言うとインサートモードでの C-@ にに似ている印象があります (:help i_CTRL-@)。
といっても C-@ には「以前の入力を再度入力した後ノーマルモードへ戻る」程度の機能しかなく、
「確定する」という動作はやはり不自然かもしれませんが……。


報告していた以下の二つの挙動ですが、

  • ノーマルモードから挿入モードに移った直後くらいに C-c、C-m 等及び通常のキー入力が「そのようなキーは設定されていない」という警告とともに無視される時がある。

  • 複数行編集において、最初の行を削除した後に移動モードが機能しない。

どうも私の端末の問題でした。
Vim で Esc キーを多用するので Esc キーが押下された時 "Meta-" に続く文字をなるべく待たないようにしているのですが、その設定を無効にすると発生しなくなりました。
厳密な再現条件は未だ不明ですが、一応の解決を見たので取り下げます。

提案/質問 --- モードの判定

Vim の最大の利点にして最大の難点はモードの存在ですが、今どんなモードかが一目で分かればその難点は緩和されると思います。

私は

let &t_ti = "\<Esc>[2 q"
let &t_te = "\<Esc>[2 q"
let &t_SI = "\<Esc>[5 q"
let &t_SR = "\<Esc>[4 q"
let &t_EI = "\<Esc>[2 q"

のような記述を ~/.vimrc にすることで、モード毎にカーソルの形状を変えています。(:help terminal-output-codes)
(これは端末多重化ソフトウェアによる CS の奪取を考慮していません。ですので実際はもっと複雑な設定になっています。)

bash の vi-mode の場合、inputrc に以下を記述することで実現できました。

set editing-mode vi
$if mode=vi
    set show-mode-in-prompt on
    set vi-ins-mode-string "\1\e[5 q\2"
    set vi-cmd-mode-string "\1\e[2 q\2"
$endif

しかしこれは (GNU) readline の設定ですので、ble.sh では当然有効ではありません。

そこで例えば $KEYMAP という変数に emacs、vi-ins、vi-cmd といった値を格納するようにしてくださると、
プロンプトの最後にカーソル形状を制御する CS を配置し、その値を $KEYMAP に応じて分岐させるといったことが可能になり、
個人的に助かります。
因みに $KEYMAP という変数は Zsh で実際に用いられているものを挙げただけで、名前に意味はないです。

もし $KEYMAP を実装せずとも、現在の段階でなにかモードの判定ができる方法があるのなら、そちらの方法を教えてくださると泣いて喜びます。

14223ec...c2cd318 現時点の様子 (前回からの変更)

少しずつ対応しているところで、一区切りしたら更新しようと思っていたのですが、モードの判定についての提案・質問がありましたのでこの時点で取り敢えず push します。というのも、自分でも現在のモードがわからないのが不便に思ったので、モードを表示する機能を既に加えたからでした。

新しく対応したもの

  • 挿入モードにおける C-o
  • テキストオブジェクト [ia][][b()B{}<>wW`'"]
  • オペレータ g~ gu gU g?
  • 現在のモードの表示

対応予定 (現在中途半端なところですが)

  • テキストオブジェクト [ia][pst]
  • オペレータ g< g> (訂正 (2017-09-16 11:24): < > だった)
  • guu gUU g?? (追記 (2017-09-16 11:24): g~~ も)
  • surround.vim ぎ ys, yss, etc.

@cmplstofB (B-bar) 様

ご報告ありがとうございます!

Vim で言うとインサートモードでの C-@ にに似ている印象があります (:help i_CTRL-@)。

上の報告の通り vi の C-o には対応しました。現在 C-o は一時的にコマンドを受け付けるものになっております。C-@ については考えてみます。ただ、これはユーザの皆様に任せて各自の好みに合わせて

ble-bind -m vi_insert -f  C-@ 'vi-insert/@norepeat accept-and-next'

と書いてもらうということにするのが良いかもしれませんね。

どうも私の端末の問題でした。Vim で Esc キーを多用するので Esc キーが押下された時 "Meta-" に続く文字をなるべく待たないようにしているのですが、その設定を無効にすると発生しなくなりました。

この説明を見て思い出しました。実は、今回の vi-mode の実装の過程で ee5c82c291bbd83730a91dbb81f516a0f72b2078 でバグ (複数のキー入力が溜まっているときに2つ目以降の文字が処理されない) を埋め込んでしまいまして、それは 12f332975270112cbbf69395efcbffadaf507905 にて既に修正されました。もしこれに関連しているとすれば、最新版では上記の設定を無効にしなくても動く可能性があります。もしお時間がありましたら簡単に確認して頂けますと幸いです。

Vim の最大の利点にして最大の難点はモードの存在ですが、今どんなモードかが一目で分かればその難点は緩和されると思います。

実は上の報告にも書きましたように、こちらでも独自に気になっていたので既に対応しました。実はノーマルモードに入った直後に C-m などが効かないというご報告の原因を独自に考えまして、もしかして C-l でノーマルモードに戻る設定にしているのが混乱の元かもしれないと考えて、以下の2点の変更を行いました。

  • C-l は Zsh に倣って clear-screen とする。
  • 現在のモードを編集している文字列の次の行に表示する。

そこで例えば $KEYMAP という変数に emacs、vi-ins、vi-cmd といった値を格納するようにしてくださると、

ble.sh の内部的な変数で $_ble_decode_key__kmap がこれに対応しますね…。ただ、これは内部的な変数なので将来的に名前が変わる可能性もあります。公開用のコピー (例えば $BLE_KEYMAP) を作成しても良いのですが、実はそうしたとしても以下の2つの理由により、現状では動きません

  • プロンプト内容はキーの入力を行うたびに再計算されるのではなく、コマンドを実行するたびに再計算されます。

    というのもキー入力のたびにプロンプトの計算をすると、毎回全体を再描画する必要がありちらつきの原因になるためです。これは、既存の readline でも同じ動作です。ただし readline で show-mode-in-prompt のときには (キー入力のたびにではなく) モードの変更が行われた時に限って 特別にプロンプトを再計算するのではないかと思われます。従って、もし ble.sh でも実装する場合は同様に show-mode-in-prompt 的な設定を提供するのが適切かと考えます。ただ、取ってつけたような設定項目なので今のところ実装するかは分かりません。

  • プロンプトの内容は制御シーケンスも含めて ble.sh で全て解析しています (制御シーケンスによるカーソル移動なども全て追跡しないと描画位置がずれてしまうので…。余談ですが、このために ble.sh では大体の場合でシーケンスを \[\] で囲む必要はなかったりします)。

    更に、制御シーケンスの翻訳 (ECMA-48 から terminfo (tput) によるシーケンスへ; 特に SGR) もしています。その際に、ble.sh が解釈(翻訳)できない CSI sequence は現状で捨ててしまっています。つまり現状ではカーソルの形状指定 CSI q は捨ててしまうようになっていたはずです。これをプロンプトに埋め込むには、解釈できない制御シーケンスを透過させるようにするか、CSI q に対応するかの対処が必要になりますね…。

もし、今回の変更によるモード表示にご満足いただけた場合にはそれで良いのですが、そうでなければどのように機能を提供するのかもう少し相談が必要になりますね…。

@akinomyoga 様

対応ありがとうございます。


この説明を見て思い出しました。実は、今回の vi-mode の実装の過程で ee5c82c でバグ (複数のキー入力が溜まっているときに2つ目以降の文字が処理されない) を埋め込んでしまいまして、それは 12f3329 にて既に修正されました。

この件ですが、すいません、設定を元に戻すとやはり発生しました。


プロンプトの内容は制御シーケンスも含めて ble.sh で全て解析しています
現状ではカーソルの形状指定 CSI q は捨ててしまうようになっていたはずです。

とのことですが、私の Bash のコマンドプロンプトは

PS1="\w\$\[\033[00m\]\$\[\033[5 q\] "
           ^^^^^^^^^^^^^^^^^^^^^^

となっており、カーソルの形状に関する CS が含まれています。
そしてこの CS はきちんとカーソルの形を変えています。

これだけ見ると、ble.sh がカーソル形状に係る CS を無視していないように思うのですが、これはまた違うのでしょうか。


~ の実装

Vim のノーマルモードにおいて、~ は「カーソル下の英単語の大/小文字をトグルする」という機能です。(:help ~)
私はこの機能をよく使うので、是非実装して欲しいです。

テキストオブジェクト (iw/W 及び aw/W の違い)

テキストオブジェクト、非常に使い易いです! sorround.vim も盛り込んでくださって嬉しいです。
一点、iw/W 及び aw\W の挙動が i a で同じに見えます。
Vim の挙動は iw なら inner word、つまり空白文字を含まない単語を範囲に指定し、aw なら a word、つまり空白文字を範囲に含むのですが、
ble.sh の vi-mode ではどちらも同じ挙動をするように思います。

補完時のカーソルの位置がずれる

$ cat /usr/share

等という文の / の位置で補完しようとすると、補完すべき候補が一行に収まる時は良いのですが、
そうでない場合にカーソルの位置が補完候補の最後から二番目の行(5行に亘るなら4行目)に移動してしまい、以後の入力に支障を来します。

ヒアストリングの補完

vi-mode と直接関係なく、差し出がましいのですが、ヒアストリングの補完について少し気になるところがありました。
例えば

$ python3 <<< 'imp

という文の時、補完に割り当てられたキー(CTRL-I)を押下すると、現在のディレクトリ配下の内容が補完されます。
ちょうど $ cat ./ の / の位置で補完した時の様な挙動です。


カーソルの形状についてですが、今回加えていただいた "--INSERT--" の表示で大満足です。ありがとうございます。

これだけ見ると、ble.sh がカーソル形状に係る CS を無視していないように思うのですが、これはまた違うのでしょうか。

本当ですね。コードを改めてよく見てみたところ、解釈をしてカーソルの位置と SGR の状態遷移の計算はしているけれども、翻訳・プロンプト内容の変更はしていませんでした…。大分前に実装した所なのでうろおぼえて書いてしまいました。なので、この点に関しては大丈夫ですね

(あと提示された PS1 を見て気付いたのですが、さきにお見せ下さった readline の設定を読み違えて CSI q
と書きましたが、CSI ... SP q (DECSCUSR) ですね。この点も訂正しておきます。)

解釈をしてカーソルの位置と SGR の状態遷移の計算はしているけれども、翻訳・プロンプト内容の変更はしていません

す、すいません。何をおっしゃっているのか理解できません……。
とりあえず「読み込み初期はカーソル変形の CS は有効だが、モードの変更を監視できる頻度では、カーソル変形の CS は解釈されない。」という理解でよろしいでしょうか。
違っていたらわざわざ解説せず、一言「違います」と言っていただければいいです。

すみません。もしかしてお気づきになったかもしれませんが、部分的な返信になってしまったのは、編集の途中で誤って投稿してしまっていました。今、全体に対する返信を編集しているのですが、先に上記の点についてだけ。

「読み込み初期はカーソル変形の CS は有効だが、モードの変更を監視できる頻度では、カーソル変形の CS は解釈されない。」という理解でよろしいでしょうか。

すみません。舌足らずでした。言いたかったことは違いますね。「ble.sh がカーソル形状に係る CS を無視していない」に関する話で、頻度の話ではありませんでした

@cmplstofB (B-bar) 様

改めて

Re: 続きを待たず ESC を送信するときの不具合について

この件ですが、すいません、設定を元に戻すとやはり発生しました。

確認していただきましてありがとうございます。手間をかけさせてしまったようで恐縮です。タイミングの問題でうまく動作しないというのは、ble.sh のどこかでミスしている可能性があるので、また暫く様子を見てみます。

Re: ~ の実装

これは実装しますね。実は実装候補には入っていたのですが、いろいろの提案を下さった段階で優先順位を下げていました。

Re: テキストオブジェクト (iw/W 及び aw/W の違い)

Vim の挙動は iw なら inner word、つまり空白文字を含まない単語を範囲に指定し、aw なら a word、つまり空白文字を範囲に含むのですが、ble.sh の vi-mode ではどちらも同じ挙動をするように思います。

これはミスですね…。引数をしたときのカウント (2yaw vs 2yiw) しか対応できていませんでした。後で改めます。

Re: 補完時のカーソルの位置がずれる

すみません。これは -- INSERT -- に対応する時に配置計算のコードを整理したのですが、そのときに埋め込んだバグで、 df4685891ad069f74aa67a6cc22a94c37d638fed で直したつもりだったのですがいかがでしょうか。現在こちらでは再現しないのですが、これで直っていなければまた調べます。(今まで意識していなかったのですが、どの commit id で試しているのかも報告のたびに教えて頂けると確認の二度手間を防げて良いかもしれませんね…)

Re: ヒアストリングの補完

vi-mode と直接関係なく、差し出がましいのですが、ヒアストリングの補完について少し気になるところがありました。

いえ、気になることがあれば是非教えて頂ければと思います。こちらの件について、何も候補がなければデフォルトではファイル名を補完候補にすることにしています。ヒアストリングとして何か適切な候補生成の案があれば教えて頂けると助かります。現状では、他に候補も思い浮かばないので、(標準入力にファイル名を入れたいと思うことがないとも限らず) ファイル名を補完するのはまあ妥当かなというように考えておりました。

Re: モード表示に関して

カーソルの形状についてですが、今回加えていただいた "--INSERT--" の表示で大満足です。ありがとうございます。

ありがとうございます! 余り確認する時間もなく push してしまったので、まだ不十分な点が出てくるかもしれませんが、その時はまた教えて頂ければ幸いです。

c2cd318...32f1e67 更新

修正したもの

  • カーソルの位置計算のバグを修正
  • ノーマルモードにおいて M-? を ESC ? と解釈し、ESC は beep。
  • aw の振る舞い。現在の文字が空白以外のとき単語に続く空白を含める。現在の文字が空白のとき単語に先立つ空白を含める。

新しく対応したもの

  • surround.vim ぎ ys{move}{foo} と yss{foo} ({foo} = <... や t... には未対応 )
  • ~
  • オペレータ < >
  • >> << g~~ guu gUU g??

未対応のもの

  • テキストオブジェクト [ia][pst]

@cmplstofB (B-bar) 様

お世話になっております。以下については修正しました。

  • Re: ~ の実装
  • Re: テキストオブジェクト (iw/W 及び aw/W の違い)
  • Re: 補完時のカーソルの位置がずれる

surround.vim 対応について

先に要望のありました ysiw" についてですが、素の vim で動かなかったので調べた所 surround.vim というものを入れると使えるようになるらしいということが分かったので、その前提で実装することにしました。取り敢えず、surround.vim の機能の中でも ys と yss だけ対応することにしました。

元の vim で拡張のようなので、ble.sh でも拡張として実装することにしました。使う場合には、~/.bashrc の ble.sh の設定で以下のように記述して下さい。

if [[ $- == *i* ]]; then
  source /path/to/blesh/ble.sh noattach

  # 以下の行を追加
  source "$_ble_base/lib/vim-surround.sh"
fi

注意点

  • ただし、タグ (<tag>...</tag> の形のもの) には未対応です。
  • 元の surround.vim では ys3iw" などのように引数を指定したときの動作が分からなかったのですが、現状で ble.sh では y3iw などと指定した時と同様の範囲を括るようになっています。もし、より良い動作がありましたらご教示下さい。
  • yss に関しては g~3~ などと違って ys3s のような指定方法は使えません。これは元の surround.vim と同じ制限です。

特に要望があれば以下も実装できます

  • <tag>...</tag> の形のタグ
  • ds cs yS ySS なお surround.vim に含まれる他の機能
  • let g:surround_45 = "<% \r %>" などに対応する設定方法

Re: 続きを待たず ESC を送信するときの不具合について

関連するか分かりませんが、ノーマルモードで ESC を正しく処理できていなかった (Meta 修飾として扱ったままになっていた) のを修正しました。またハズレかもしれないので恐縮ですが、もし興味があるようでしたらまた試していただくことも可能です。

未決着項目

今までにご報告いただいたものについて、一旦この時点での未決着項目を整理します。

  • ヒアストリングの補完候補 → より良い候補として何が考えられるか?
  • 挿入モード C-@ き accept-and-next を割り当てる可能性 → 後でこちらで考察
  • Esc キーが押下された時 "Meta-" に続く文字を待たずに送信するとキーが認識されないときがある
  • 複数行編集において、最初の行を削除した後に移動モードが機能しないことがある

@akinomyoga 様

どの commit id で試しているのかも報告のたびに教えて頂けると確認の二度手間を防げて良いかもしれませんね…

すいません、思慮不足でした。これからはそうします。
私は Git 作業には全くの初心者ですので、他に注意すべき点(報告の形式等)があれば是非教えてくださると助かります。


Re: テキストオブジェクト iw/W、aw/W の挙動

1b9e2a4 で確認しました。ありがとうございます。

vim-surrond.sh 拡張

すいません。今見直したらテキストオブジェクトを紹介する際、surrond.vim が必要だという旨の注釈を付け忘れていました。
手間を掛けさせることとなり申し訳無いです。

Re: vim-sorround.sh 拡張への要望

できたら ds、cs を加えていただけないでしょうか。お願いします。

また、surround_45 変数に相当する機能というより寧ろ ble.sh 謹製の vim-sorround.sh 独自の機能といった方がいいですが、
コマンド展開及び行内演算のマーカを簡単に挿入できると嬉しいです。
具体的には、適当なプレフィクスで $(/) や $((/)) を入力したいということです。
個人的に yss- で $( line )、ysiW= で $(( 4+6 )) といった操作が理想です。
(つまり - が $(/) に、= が $((/)) に対応しているといった感じです)

Re:Re: 複数行の補完候補

1b9e2a4 にて、
複数行に亘る補完候補がある時の不具合が修正されていることを確認しました。ありがとうございます。

Re:Re: ヒアストリング補完

言われてみると、ヒアストリングでの補完は現在ディレクトリ下のファイル/ディレクトリ補完しかないですね……。

行内前後方跳達で検索失敗した時の単語の保存 (:help f)

多分この題を見ても分からないと思います。具体例で示します。
^ はカーソル位置です。

現在ノーマルモードです。
次のような行において、fs という入力をします。

$ cat ~/doc/a.csv | sort -r | uniq
                               ^  

当然前方に "s" は無いので検索は失敗し、カーソルは不動です。

$ cat ~/doc/a.csv | sort -r | uniq
                               ^  

ここで、本当は後方を検索するのだったと思い直し、Fs とする代わりに
fs で "s" が検索されたものと見做して , を入力します。
そうした時に、現状 (1b9e2a4)
ではカーソルは不動、もしくは前回成功した捜達で検索された単語に移動してしまいます。

これは Vim の挙動と似わないので、できれば
「検索が失敗してもその単語を記憶し、;/, が入力された時はその単語を前方/後方に再検索する」
という機能にして欲しいです。

% の実装

Vim のノーマルモードにおいて % は「対応する括弧(もしくはそれに準ずるもの)の対に飛ぶ」という機能が割り当てられています。(:help %)
実装していただくととても嬉しいです。
なお、Vim ではこの「対応する括弧」の文字を matchpairs を変更することで設定できますが、シェルのラインエディタとしては標準の ()、{}、[] で十分な気がします。
(下手に <> の組などに対応するとリダイレクトの演算子に反応して面倒なことになりそうですし)

範囲選択

emacs-mode での操作動画 を見てみると、"'select, copy, and paste'" という
句を選択し、貼り付けていますが、vi-mode では不可能なのでしょうか。
理想としてはノーマルモードで v で選択開始、c、d、y 等の操作を受け付け、^C/^[ で選択を解除、といったものがいいです。

undo

bash 標準 (set -o emacs) では CTRL-_ に「変更を破棄」という機能が割り当てられていますが、これは ble.sh による Readline にはないのでしょうか。
もしあれば、ノーマルモードでの u に割り当てて欲しいです。

Re: 未決着項目

  • ヒアストリングの補完候補 → より良い候補として何が考えられるか?
  • 挿入モード C-@ き accept-and-next を割り当てる可能性 → 後でこちらで考察
  • Esc キーが押下された時 "Meta-" に続く文字を待たずに送信するとキーが認識されないときがある
  • 複数行編集において、最初の行を削除した後に移動モードが機能しないことがある

ヒアストリングの補完候補 → より良い候補として何が考えられるか?

上述しましたが良い補完候補は思い付きませんでした。

挿入モード C-@ に accept-and-next を割り当てる可能性 → 後でこちらで考察

私は既に ~/.bashrc で

ble-bind -m vi_insert -f  C-@ 'vi-insert/@norepeat accept-and-next'

という割り当てを行なっていますが、確定を伴なう動作なので標準にしないほうが良いと感じました。
というか正直 Vim での CTRL-@ の挙動とは少々違うので……。

Esc キーが押下された時 "Meta-" に続く文字を待たずに送信するとキーが認識されないときがある

すいません。まだ発生します。@akinomyoga 様の手元で発生しないということは確実に私の端末側の問題ですので、こちらで対処します。
どうかお気になさらないでください。

複数行編集において、最初の行を削除した後に移動モードが機能しないことがある

これは 1b9e2a4 において発生しませんでした。ありがとうございます。


蛇足気味ですが,vim を一々開いて :help するのが鬱陶しい場合は
いつでもどこでも :help する というサイトがありますので,オンラインで手引きが閲覧できます。

すいません。あまりに多機能を望みすぎました。面倒な案件は遠慮なく放置してください。

@cmplstofB (B-bar) 様

ありがとうございます。

Commit id

commit id の記述ありがとうございます!

どの commit id で試しているのかも報告のたびに教えて頂けると確認の二度手間を防げて良いかもしれま せんね…

すいません、思慮不足でした。これからはそうします。

いえ。これに関しては私も意識していなくて、先の返信を書いているときに想到したことですので思慮不足ということは決してありません (考えてみれば GitHub の他のプロジェクトでも Issue を報告するときに commit id を記述しているのを余りみたことがありませんしね…)。

それでも、やはり今回のご報告を読んで commit id があると分かりやすいと感じますね。そうしていただけると助かります。

私は Git 作業には全くの初心者ですので、他に注意すべき点(報告の形式等)があれば是非教えてくださると助かります。

  • 注意すべき点ではないのですが (恐らくご存知なのではないかと思うので、わざわざ言及して恐縮ですが) git pull はお使いですか。ble.sh を最新版に更新するときは git pull & make (& make install) で済みます。
  • あと、恐らく普通は GitHub では各要望毎に1つ1つ Issue を立てるのが普通ですね。ただ、私は今の形式 (vi mode に関連するものを全てここで議論する) の方が分かりやすいので、このままで問題ありません。

Re: vim-sorround.sh 拡張への要望

ds cs 対応しますね。$( \r ) と $(( \r )) も対応します。

Re:Re: ヒアストリング補完

言われてみると、ヒアストリングでの補完は現在ディレクトリ下のファイル/ディレクトリ補完しかないですね……。

そうなのですよね…。

先の返信後にいろいろ考えていたのは (例えば先の例では) python3 に対して import を補完できたら嬉しいということなので、"ヒアストリング用の補完関数" をユーザで設定できるようにするという手もあるなあ、ということでした。ただ、個人的に現状の補完の枠組みを大幅に整理したいので、もし対応するにしても vi mode の実装が終わってからにします。

Re: 行内前後方跳達で検索失敗した時の単語の保存 (:help f)

なるほど。これは気づきませんでした。対応します。やはり自分だとこういったことには気づけないので、vim をお使いの方に試していただけて心強いです。

Re: % の実装

これは実装しますね。

Re: 範囲選択

ビジュアルモード・選択モードというもののことで良いでしょうか。実は使ったことが全くなかったので怖がって実装していませんでした…。多分、"雰囲気実装" になってしまいますが取り敢えず実装を試してみます。

Re: undo

すみません。やはりこれは欲しい機能ですよね。ble.sh では未実装 (emacs mode でも使えない) です。

実は昔考察 (memo.txt#L1571-L1591) をしたのですが、自分自身が余り使わないものですから仕様確定できずに終わったのでした。少し議論させて頂ければ、仕様確定して実装できると思います。以下のそれぞれについて主観で構いませんのでどちらの方が自然に思われるか率直な意見を頂ければと思います。

  • 履歴項目 (過去に実行したコマンドの1つ1つ) の移動も redo/undo の対象に含めるか否か?

    参考: Zsh は含めている。Bash は含めていない。

  • 履歴項目毎に編集履歴を記録するか、全体に対して編集履歴を記録するか

    参考: Bash は項目ごと。Zsh は全体に対して (もしかすると項目ごとに undo する方法もあるかもしれない)。※全体に対して編集履歴を記録すれば、原理的には一つ一つの履歴項目に対する履歴も抽出できるわけですが、その分処理が非効率になります。

  • 1文字の入力ごとに undo できるようにするか、連続する文字入力は一つにまとめて undo できるようにするか?
    参考: Zsh は1文字ごと。Bash はまとめる。Vim もまとめる。
  • コマンドを実行したときに今までの編集履歴をどうするか?
    参考: Bash は確定した履歴項目の編集履歴だけをクリアする。Zsh は全ての編集履歴をクリアする。

個人的には Zsh よりも Bash の動作のほうが概ね分かりやすいと考えているのですがいかがでしょうか。

ところで vimindex の U の箇所に

U 2 1行中の最近の変更をすべて取り消す。

と書かれているのですが「すべて」というところを量りかねています。実際に試してみると、すべて取り消すという雰囲気ではなく、最近の変更 (U 自身も含む) を取り消すだけのように見えます。何かご存知でしょうか。また u に関しても注意点などあれば教えて頂ければ幸いです。

Re: 未決着項目

確定を伴なう動作なので標準にしないほうが良いと感じました。というか正直 Vim での CTRL-@ の挙動とは少々違うので……。

やはり標準で実装するのは分かりにくいのですね。vi mode ユーザからの視点ありがとうございます!

こちらで対処します。どうかお気になさらないでください。

毎度試して頂きありがとうございます。この問題は取り敢えず保留として、頭の片隅にでも置いておくことにします。

これは 1b9e2a4 において発生しませんでした。ありがとうございます。

承知しました。また何か問題がありましたらお知らせ下さい。

「いつでもどこでも :help する」サイト

蛇足気味ですが,vim を一々開いて :help するのが鬱陶しい場合はいつでもどこでも :help する というサイトがありますので,オンラインで手引きが閲覧できます。

ありがとうございます! 便利ですね! (と思って徐に surround と打ってみたらありませんと言われてしまいましたが…surround は標準機能ではありませんからね)


ほか、以下についての確認ありがとうございます!

  • Re: テキストオブジェクト iw/W、aw/W の挙動
  • Re:Re: 複数行の補完候補

すいません、追加で報告があります。
テキストオブジェクトに対する c (削除後挿入モードに移行) が、 d と同じ振舞いになります。
Ver: 1b9e2a4

また、>/< 及び大文字小文字系統の動作の確認報告を忘れていました。全て完璧に動作しました。ありがとうございます。

@cmplstofB 様

アカウント名を統一されたのですね。今後とも宜しくお願い致します。

Re: テキストオブジェクトに対する c

テキストオブジェクトに対する c (削除後挿入モードに移行) が、 d と同じ振舞いになります。

ご報告、ありがとうございます。修正しました。これは大ミスなので今 push しました 3958c51842df0b474877349f4c94966de9578fe6 (修正してから気付いたのですが、もしかして c が軒並み動かなくなっていたかもしれません)。

機能を拡張していく上で内部構造を大幅に変更することがしばしば出てくるので、このように以前動いていたものがバグで動かなくなってしまうということがあるということは、申し訳ありませんがご承知下さいませ。今回は vi_command キーマップを vi_command と vi_omap (それぞれ Vim の nmap, omap に対応) に分割した時のバグでした。

追記:

また、>/< 及び大文字小文字系統の動作の確認報告を忘れていました。全て完璧に動作しました。

一つ一つ確認いただきまして本当にありがとうございます!

修正ありがとうございます。確認しました。

アカウント名を統一されたのですね。今後とも宜しくお願い致します。

こちらこそお世話になります。

Commit ID: 3958c51

何度もすいません。しかしこれは今言うべきだと思ったので報告します。

ルートユーザになる為に、su - を実行し、パスワードを打ち込むとおかしなことになります。
最初の文字は、入力がエコーされないという尋常の挙動ですが、直後に改行(LF/CR とかは分からないです)されて、パスワードの文字列が丸見えになります。
そのまま入力して決定すると、(恐らく)最初の一文字しかパスワードとして判定されず、認識に失敗します。
また、丸見えになっていた文字列は「実行」され、「そのようなコマンドはない」というエラーも出ます。
個人的にこれはシステム上危険すぎると思ったので、修正して欲しいです。

Readline が全滅なので例えば ble.sh を読み込んだ状態で Dash を起動して、su - を実行しても同様の結果になりますが、
もちろん ble.sh を読み込まなければ正常なパスワード認証ができます。

Commit ID: 3958c51

@cmplstofB 様

ご報告ありがとうございます! cbab20b1b90e9998394e1e2a81b06553d6c1e6e3 stty の設定を直しました。いかがでしょうか。

(あー…これは ble.sh が犯人だったのですね。自分のところでも同じ現象になるということは認識していたのですが、余り root にならないこと・検索しても似た症状の人が出てこないということから放置していました。ble.sh が原因だったとは、道理で検索しても出てこない訳です…お恥ずかしい限りです)

ありがとうございます!正常な挙動になりました。
私も普段は sudo でパスワード無しの認証ばかりだったので今迄気が付きませんでした。

Commit ID: cbab20b

vim-operator-surround と vim-plug

釈迦に説法のようで失礼ですが、Twitter の方で紹介したプラグインについて説明します。

まず、Vim のプラグインマネージャとして vim-plug をお勧めします。
新しく、合理的な体系ですので。

vim-operator-surround は vim-operator-user に依存するので、vim-plug 式だとこんな感じの設定が必要です。

call plug#begin(~/.vim/plugged)
" プラグインの読み込み
Plug 'kana/vim-operator-user'
Plug 'rhysd/vim-operator-surround'
call plug#end()
" Surround.vim にコマンド体系を合わせる
nmap <silent> ys <Plug>(operator-surround-append)
nmap <silent> ds <Plug>(operator-surround-delete)
nmap <silent> cs <Plug>(operator-surround-replace)
let g:operator#surround#blocks = {}
let g:operator#surround#blocks['-'] = [
            \ { 'block' : ["'", "'"], 'motionwise' : ['char', 'line', 'block'], 'keys' : ['q'] },
            \ { 'block' : ['"', '"'], 'motionwise' : ['char', 'line', 'block'], 'keys' : ['Q'] },
            \ { 'block' : ['(', ')'], 'motionwise' : ['char', 'line', 'block'], 'keys' : ['p'] },
            \ { 'block' : ['[', ']'], 'motionwise' : ['char', 'line', 'block'], 'keys' : ['b'] },
            \ { 'block' : ['{', '}'], 'motionwise' : ['char', 'line', 'block'], 'keys' : ['B'] },
            \ ]

これを読み込んだら (:source $MYVIMRC)、:PlugUpdateを実行してプラグインを導入して下さい。
この設定ですと、適当な単語上で ysiw とすると下部に block: と表示され、例えば q と入力すると単語が '/' で囲まれます。

Surround.vim の方が情報が見つけやすいかと要らぬ思案をして、結果梃摺らせてしまったことをお詫びします。

@cmplstofB 様

ありがとうございます! 実はもう既に surround.vim 式の実装が進んでしまっているので、一通り終わってから確認いたしますね。(追記: 実は ds は一通り終わって cs に入るところです)

本当にすいません……。

@akinomyoga 様、返信が遅れていたものです。

Re: Git 管理

git pull 知らなかったです。git は間抜けでも操作できるということで "git" という名前らしいのですが、それさえも扱えないとは……。

Re2: undo

undo に関しては基本的に Bash のそれに合わせて欲しいです。

Re: U コマンドの挙動

これ、私もよく分からないです。ただ、u/CTRL-R 等と違い、U それ自身が一つの編集コマンドになっているので、u/CTRL-R で「U による操作自体を」 undo/redo できます。
実際問題 Vim の手引きでも「この動作はわかりにくいかもしれません」とあるので、余程分かりにくい挙動なんだとおもいます。
なお、U で「元に戻される」区切りは、挿入コマンドからの移行等です。(:help undo-blocks/:help i_CTRL-G)
個人的に、undo-block などは実装しない方が良いと思います。
これらが有用なのはかなり複雑な undo/redo が要求された後の作業であり、Bash の行編集ではそう頻繁には起らないだろうからです。
akinomyoga 様もおっしゃっていましたが、これを実装するとかなり重くなりそうなので。

質問

`ble.sh/lib/vim-surround.sh` の 81 行目から始まるキーと挿入される語句を編集し、`p` と `(`/`)`、`b` と `[`/`]`、`B` と `{`/`}` が対応するように編集しました。
  case "$ins" in
  (['<t'])
    ble/widget/vi-command/bell
    return ;;
  ('p') prefix='( ' suffix=' )' ;;
  ('b') prefix='[ ' suffix=' ]' ;;
  ('B') prefix='{ ' suffix=' }' ;;
  (後略)
ところが、`ysiwp` と入力しても何も起きず、`ysiwb` と入力しても `( word )` が入力されます。 最新版を使ったところ上述の問題に関しては上手く行きました。

またできれば q で '/'、Q で "/" が入力できるようにしたいのですが、

bash:ble.sh/lib/vim-surround.sh # in 'ble.sh/lib/vim-surround.sh` ('q') prefix="'" suffix="'" ;; ('Q') prefix='"' suffix='"' ;;

のように設定しても(当然といえば当然ですが)上手く行かないです。
引用符の入力を q/Q を用いて行なう設定はどのように記述すればよいでしょうか。

ダイグラフ

Vim 挿入モードでは本来 CTRL-K はキートップに印字されていないような文字の入力に使われますが(:help i_CTRL-K)、
寧ろコマンドラインにおいてそのような文字が混入することは危険な気がするので、ble.sh の vi-mode における CTRL-K は kill-line のままでお願いします。

Commit ID: 9afa3fa

@cmplstofB 様

Re3: undo

undo に関しては基本的に Bash のそれに合わせて欲しいです。

ありがとうございます! 承知しました。ただ emacs mode の方とも一緒に実装したいので今すぐ実装するかは分かりません (merge してから実装した方が良い気がするけれども、気がついたら実装しているかも…)。

Re2: U コマンドの挙動

実際問題 Vim の手引きでも「この動作はわかりにくいかもしれません」とあるので、

そうなのですね。

統計があるわけではないので定かな事は言えませんが、みなさんの Vim の設定ファイルを見ると、U に undo、つまり CTRL-R を割り当てている

なるほど。その方向も検討してみます。これも、"お好みで設定ファイルに書いて下さい" という説明をどこかに書いておくのが良さそうでしょうか。

Re: 質問 (テキストオブジェクト q で '/'、Q で "/" の設定方法)

上にお書きになった設定で正しいような気がします。ただ、([a-zA-Z]) の行よりも上に書かないといけませんね。また現在その辺りは激しい書き換えの対象であることと、さきの $(), $(()) の件の対応と同時に外部から拡張できる仕組み (let g:surround_45 的な) を与える予定ですので、そのときにご説明いたします。

Re: ダイグラフ

ble.sh の vi-mode における CTRL-K は kill-line のままでお願いします。

はい。同じ考えです! 実は一瞬 C-k はダイグラフだったのですが、戻しました。Bash の C-k が既定で kill-line であることと、自分で使ってみてこれは混乱の元だなと思ったためです。折角実装したので、敢えてダイグラフを使いたい人のために以下の Wiki ページに設定方法は書きましたが、今後既定で C-k がダイグラフになる予定はありませんのでご安心下さいませ!

32f1e67...795ceca 更新

すみません。バグを色々出していました…。

新機能

  • テキストオブジェクト [ia][pst]
  • コマンド % {count}%
  • vim-surround.sh: 設定 "bleopt vi_surround_45", etc. に対応
  • 他色々

動作変更

  • vi-mode: r{char} gr{char} で上書き対象を着色
  • vi-mode: imap: C-m, C-h, DEL; nmap: o, O でインデントを認識
  • 他色々

バグ修正

  • vi-mode: 行単位の操作 (2yj なお) をするとエラーになるバグの修正
  • vi-mode: 現在位置よりも先に操作対象があるとき (yib なお) 位置の移動が起こらないバグの修正
  • vi-mode: isearch の途中でノーマルモードに移行すると選択状態がそのままになるバグの修正
  • vi-mode: {count}L で現在行より上に行く場合、{count}H で現在行より下に行く場合などで範囲が裏返るバグの修正
  • vi-mode: + - H L yib などで非空白行頭に移る条件の修正
  • vi-mode: オペレータを指定したときの gg G (現在のコマンド内の移動) で、引数省略時に引数 1 と解釈していたバグを修正
  • $? 及び $_ の復元が動かなくなっていたバグの修正
  • char_width=emacs のとき、★などの文字 (U+2000 - U+2600) の文字幅が常に 1 になっていたバグの修正
  • 他色々

未対応

  • ビジュアルモード・選択モード
  • vim-surround.sh (ds cs): インデント、テキストオブジェクト p s t、コマンド yS, ySS
  • u C-r U / ? n N (これらは master にマージ後)

@cmplstofB 様

Re2: 質問 (テキストオブジェクト q で '/'、Q で "/" の設定方法)

引用符の入力を q/Q を用いて行なう設定はどのように記述すればよいでしょうか。

これは既に dotfiles に追加なされたもので問題ありません。

795ceca...5f95282 更新

新機能

  • vi-mode: / ? n N : gj gk _ g0 g<home> g^ g$ g<end> gm go g_ ge gE
  • vi-mode: ビジュアルモード (v char, V line, C-v block);

    • オペレータ: 既存のものに加えて ~ u U ? s x <delete>

    • 他の xmap: r C D X S R Y

  • vi-mode: vim-surround.sh にて囲み文字として t T < を指定したとき、タグ名の入力を受け付ける
  • 他: 複数行編集時スクロール (端末の高さに収まりきらないとき。補完候補が複数行出るときなどの対策はその内やるが優先度は低い)

バグ修正

  • vi-mode: 行単位のインデントオペレータ (>> なお) でエラーが出るバグを修正
  • vi-mode: オペレータ g~ を呼び出せないバグを修正
  • vi-mode: k - G gg などで履歴項目を移動したときに(最後の文字でなく)行末にカーソルが来るバグの修正
  • vi-mode: オペレータ > および < で空行が消滅するバグの修正
  • 他: "ble-bind -d" の内部でパス名展開が起こって出力が正しくないバグの修正

動作の変更

  • vi-mode: c{linewise} ({linewise} = j k H L + - gg G) のとき空行を挿入するように修正
  • vi-mode: d で最終行を削除したとき前の行に移動するように修正
  • vi-mode: f F t T r gr き C-? の形式で文字を指定できるように修正
  • vi-mode: dd, yy, etc. および D は最終行で 2 以上の引数を与えるとエラーにするように修正

未対応

  • u C-r U (マージ後の予定)
  • ビジュアルモード: I A J gJ ^] テキストオブジェクトの正しい動作 (その内)
  • インデント = (未定)
  • vim-surround.sh: cs ds のインデント, yS ySS (未定)

@akinomyoga 様

追加の様々な実装ありがとうございます。返信遅れました。
疑問と要望が追加であります。何度も何度も本当にすいません……。

: コマンドの役割

非常な失礼を承知で聞きます。これは一体何をするコマンドなのでしょうか。
Vim の ex モードのようなものだと勝手に解釈し,

$ sudo atp install emacs
-- NORMAL --

というような状態で : を押下し,

$ sudo atp install emacs
:s/atp/apt

のような入力を行なったのち,

$ sudo apt install emacs
-- NORMAL --

のような状態になることを勝手に予期したのですが,何も起こりませんでした。

カーソルの形状

しつこくてすいません。しかしながら,やはりカーソルの形状をモード間で変更したいです。
ほんの少しですが私の端末制御への理解も進み,カーソル周りの CS をモード変更毎に送信したりすることが無謀な要望だとは重々に承知しています。そこをどうにか……。
尊大な言い草になってしまいますが,不可能,もしくは手間の多さで無理ならばもう二度とカーソルの形状に係る要望はしません。


「ble.sh」という名称 (完全にオフトピです)

More Than Human---Wikipedia によると,『More Than Human』という SF 小説の中で,「blesh」という造語が,「(6人の能力者が) 力を合わせる」というような意味で用いられているそうです。

Blesh!

ちょっと無理矢理な解釈ですが,widget の組合せで強力な編集能力を発揮する ble.sh に類推できますし,『More Than Human』という題名も _More Than Bash_ な ble.sh に似合ってる気がしました。
ロゴとかに使えると面白いかもです。

@cmplstofB 様

ご要望などありがとうございます!

Re: : コマンドの役割

すみません。これは : を通して別の色々のコマンドを呼び出せるようにするために枠組みを追加しただけで、実際のコマンドは未だ整備していません (物凄く沢山ありますし…)。試験的に :q (シェル終了) などがあるのみです。検索 (/, ?) を実装するために cmap を定義する必要があって、そのために初めに : を実装したということなのでした。

今のところ、要望が出ない限りはそれぞれのコマンドの対応をする予定はありません。要望が出たとしても一旦 master にマージしてからにしますね。

因みに、ble/widget/vi-command:名前 という関数を定義していただければ、:名前 引数... に対してその関数が呼び出されるようになります (ただ、widget の実装方法についての説明がないので意味のない情報かもしれませんが。すみません…)。

Re: カーソルの形状

これの対応は実は簡単です。モードを切り替えるときに制御シーケンスを吐けば良いので。実のところ、既に、上書きモードの時には SM/RM(?25) (\e[?25h, \e[?25l) によってカーソルを非表示にするような制御を行っております。

どのように対応するのが良さそうかについてご意見をいただけませんか。ご意見がなければ勝手に実装します

  • (tput Ss がある時) デフォルトでカーソル変更を有効にするかどうか
    (調べてみると DECSCUSR は terminfo では Ss が用いられているようですね [1]。)
  • ユーザが設定できるようにするか。設定するとすれば、(a) 有効・無効の設定か、(b) カーソルの形を番号か名前などで指定できるようにするか、(c) 任意の制御シーケンスをモードに入るときに出力するように設定できるようにするか。設定項目の名称は何が良いか。

実のところ TERM に依存してユーザが場合分けで設定を書かなければならないような設定項目ではなくて、ble.sh の中で解決 (TERM 依存の切り替えは tput を用いて内部的に解決) できるような設定項目にしたいというのはあります。因みに設定の $'\e[1m-- NORMAL --\e[m' の \e[1m などは ble.sh 内部で ANSI に基づき解釈し tput の結果に応じて適切なものに置き換えて出力しています (以前、勘違いだったと書きましたが改めてコードを読むとやはり置き換えはしていました…)。その意味で DECSCUSR を ble.sh で読み取るという手もありますが、その辺りは分かりやすさとの兼ね合いです。

Re: 「ble.sh」という名称 (完全にオフトピです)

情報ありがとうございます!

blesh という単語の意味は確認したりはしていたのですが、映画については知りませんでした。色々と名前で関連を調べるのは楽しいですよね。自分もやります。(ただまあ、相当説得力がない限りは余り後付けは、"公式では" やりたくないなというのはあります。ユーザの方で色々考えていただくのは嬉しいです)

ロゴもあった方が良いですかね。実のところ ble.sh は余り個性を発揮したものではなくて空気のように存在を意識しなくても使えるものにしたいなあなどと考えていたりします (vim の細かい動作に拘っているのもそういうことにあります)。なので、ロゴを作るとしたら、ミニマリズムというのでしょうか、なにか淡白なものがいいなあと考えていました。

追記 カーソル制御の資料

5f95282...af62754 更新

今週末は進められないのでもう push します。レジスタ "x とマーク mx の対応で根幹を弄ったあと、余りテストしていないので不安定かもしれませんがご容赦下さい

新機能

  • vi-mode (mark): mx, `x, 'x (x = [][<>`'a-zA-Z"^.])
  • vi-mode (nmap): gi, <C-d> (空文字列のとき exit), "x (レジスタ)
  • vi-mode (xmap): I, A, p, P, J, gJ, aw, iw
  • lib/vim-surround.sh: nmap yS, ySS, ySs, cS, xmap S, gS
  • タブ・インデントの制御

    • bleopt tab_width: タブの表示幅, 既定値 '' (tput を使用))

    • bleopt indent_offset: > や < のインデントの幅, 既定値 4 (8 から 4 に変更した)

    • bleopt indent_tabs: > や < のインデントにタブを用いるかどうか, 既定値 1 (true)

バグ修正

  • vi-mode: 挿入モードに繰り返し回数を指定したとき ESC ? も一緒に繰り返されていたバグの修正
  • vi-mode: オペレータ g? が動かなくなっていたのを修正
  • vi-mode (nmap / ?): 検索対象の入力中に C-c してもキャンセルされないバグの修正
  • vi-mode (xmap r (visual char/line)): 全体を置換したものが選択範囲に挿入されていたバグの修正
  • vi-mode (xmap $): 行末で $ をしたときに表示が更新されないバグの修正
  • vi-mode (motion 0): オペレータを認識していなかったバグを修正
  • isearch: 一度一致したら同じものに一致し続けるバグを前回の / ? n N 対応の際に埋め込んでいたので修正
  • complete: complete -F something -D で登録されている補完関数が正しく実行されていなかったのを修正
  • prompt: PROMPT_COMMAND によって設定された PS1 を拾っていなかったバグを修正
  • textarea: 端末の下部で複数行編集時に C-z (fz) すると描画高さを正しく確保できていないバグの修正

動作変更

  • vi-mode (operator < >): Visual block での正しい振る舞い
  • vi-mode (nmap : / ?): 文字列入力中に空文字列で DEL or C-h することでキャンセルできるように修正
  • vi-mode (nmap J, gJ): 引数に対応
  • vi-mode (nmap p): 最後の行で挿入するときに余分な行が入らないように修正
  • vi-mode (xmap Y D R): 記録するビジュアルモードの種類を修正
  • lib/vim-surround.sh: タグ名入力中に '>' で確定するように修正
  • widget (.SHELL_COMMAND): 実行しないコマンドに色がついているのはややこしいのでグレーアウトする様に変更

他の変更

  • magic-space: 空白を挿入してから履歴展開していた順番を逆転

未実装

  • nmap ., xmap o, O (実装予定)
  • u, C-r, U (マージ後の予定)
  • インデント =, xmap テキストオブジェクトの正しい動作 (未定)

ごめんなさい、ビジュアルモードのテキストオブジェクトは面倒になりました。後回しです

@akinomyoga 様

# 誤操作でフォークしてたと思います。すいません。

Re: : コマンドの役割

早とちりしていました。widget の作り方はソースを見て勉強させて頂きます。

Re: カーソルの形状

ありがとうございます! 是非おねがいします。

指定方法

@akinomyoga 様に託したいです。

しかし (釈迦に説法ですが) 提案するとするなら,

  • 規定では変化させない——Vim や Ba/Zsh では規定ではカーソルは変化しないので。
  • 「カーソルの形状を変化させるかどうか」という設定形式 (例えば bleopt is_toggle_cursor_shape_in_vi_mode:=1 のようにすると発現する) はしない。——これも上と同じ理由です。上と同じ構図ですが,Vim や Ba/Zsh でカーソルを変化させる場合,「変化する」というそのものの有効化はしないからです。加えて,どのカーソル形状がどのモードに〝合っているか〟という問題は感性の問題な気がするので,それを一元的に決定するのはあまり良くないと思います。
  • どうせなら,Ba/Zsh 風の設定より,Vim 風の設定形式の方が良い——これは完全に個人的な意見ですが,Ba/Zsh でカーソル形状の変化を実現している方法はいささか hack な様相ですので 。
    以上を踏まえて,このような形式で設定したいです。
...
bleopt cs_vi_normal_mode_cursor_shape=$'\e[2 q' # ノーマル
bleopt cs_vi_ins_mode_cursor_shape=$'\e[5 q' # 挿入
bleopt cs_vi_operator_mode_cursor_shape=$'\e[4 q' # y/c/d etc...
...

ヒアドキュメント出来ない?

すいません説明を省略します。

$ cat <<. > tmp/bbbb.ttt
-bash: 警告: ヒアドキュメントの 3 行目でファイル終了 (EOF) に達しました (`.' が必要)

Esc でノーマルモードに移行しない件

結論から言うと,いまだ解決していません。また,今のところ,とりあえず確実に綴りを送信できるキー (具体的には C-c を潰してます) を vi-insert/normal-mode に割り当てています。
前にも述べましたが,これは自機の問題だと思うので,解決はこちらで頑張りますが,一応報告をしておきます。

  • Esc を押してから大体 0.4 sec 以内くらいに英数字やら_普通の_キーを送信すると,ノーマルモードに移行し,またそのキーに割り当てられている動作が実行されます。
  • Esc キーを 0.4 sec 以内の間隔で__4回__ (3回では駄目です) 叩くとノーマルモードに移行します。
    この __0.4 sec__ がどこから発生しているのか,正直見当が付かないのですが,とりあえず現状はこんな感じです。
    個人的に,「Esc に続いてある秒数_以内_で他のキーを送信すると Meta-* と見做される」という症状のほうが一般的な気がします。

Commit ID: af62754

@cmplstofB 様

Re: ヒアドキュメント出来ない?

すみません。現状では C-q RET または C-v RET などとして複数行編集にして全て入力していただいてから、C-j で実行していただかなければなりません。

「文法的に続きがあるということが明らかな時に RET が入力された場合、実行せずに改行を挿入する」というのは前々から考えていたのですが、ble.sh の文法解析に誤りがあると「実行できるはずのコマンドが実行できない」ということになり兼ねないので慎重になっていたのでした。この辺りはマージ後に対応します。

Re: Esc でノーマルモードに移行しない件

これは丁度気になっていたところでした。もし解決しないようでしたら ble.sh にキーロガー (ble.sh が実際に見ているバイト列・文字の列・キーの列を記録する機構) を組み込んで実行してもらうことを考えていました。

その前に、どのような動作を期待するのか行き違いがあるような気がしたので、確認させていただいてよいでしょうか:

  • もしかして ESC が来たら (次の文字を待たずに) その場でノーマルモードに移行することを想定していますか。現状の ble.sh では時間間隔に依存せず、次の文字が来るまで処理しません (エスケープシーケンスの先頭かもしれないので)。未だちゃんと調べていないですが、たぶん、対応できます

あと、ご報告頂いた動作について、0.4 sec 以上経過するとそれぞれどのように動作するのでしょうか。またどのように動作することを本来期待するのでしょうか。よろしくおねがいいたします。

@akinomyoga 様

Re: ヒアドキュメント

分かりました。ぶっちゃけインタラクティブシェルではあまりヒアドキュメントを使わないと思うので,別に問題ないと言えばないのですが……。

Re: Esc キー

あーこれは完全に私の認識が間違っていました。

もしかして ESC が来たら (次の文字を待たずに) その場でノーマルモードに移行することを想定していますか。

はい,そう想定していました。すいません……。

0.4 sec 以上経過するとそれぞれどのように動作するのでしょうか。

  • 英数字キーを押下した場合: その英数字がコマンドラインに挿入されます。つまり挿入モードで入力したのと同じような挙動です。

  • Esc キー連打の場合: 何も起きず,ずっと挿入モードのままです。

@cmplstofB 様

Re: Esc キー

はい,そう想定していました。すいません……。

承知しました。そのように実装してみます。

0.4 sec 以上経過するとそれぞれどのように動作するのでしょうか。

  • 英数字キーを押下した場合: その英数字がコマンドラインに挿入されます。つまり挿入モードで入力したのと同じような挙動です。
  • Esc キー連打の場合: 何も起きず,ずっと挿入モードのままです。

あら、それは不思議ですね…。やはり次でキーロガーを入れることにします

確認いたしました。
Esc キーへの対応ありがとうございます!

@cmplstofB 様
あら、書き込む前に返事が来てしまいました。確認ありがとうございます!

  • 単独で来た ESC ぎ timeout に対応しました。
  • これまで問題になっていた動作なのですが再現できました。多分直りました。確認して頂けますか。

ESC のタイムアウトに関しては、端末から Bash までの経路にある全ての timeout が累積することにご注意下さい。各々の設定 (stty, tmux, screen, bash, etc.) は Wiki に書きましたので御覧ください …と書いて Wiki を今編集していたのですが、未だ書き途中です。概要(設定の例)を書くと、

# stty (bashrc)
stty time 0 # 単位: 1/10秒

# bash-4.3 以上 (bashrc)
bind 'set keyseq-timeout 1' # 単位: ミリ秒

# tmux (tmux.conf)
set -sg escape-time 1 # 単位: ミリ秒

# screen (screenrc)
maptimeout 1 # 単位: ミリ秒

追記: Wiki 更新しました: Vi (Vim) editing mode · akinomyoga/ble.sh Wiki

af62754...2310b18 更新

★今回の修正には破壊的変更が含まれているので注意して下さい★

破壊的変更

  • vi-mode: キーマップの名称変更 vi_command -> vi_nmap, vi_insert -> vi_imap
  • vi-mode: 一部の widget の名称変更

    • ble/widget/{no,}marked -> ble/widget/@{no,}marked

    • ble/widget/vi-command/* (一部) -> ble/widget/vi_nmap/*

  • vi-mode: ble/widget/vi-insert/@norepeat 廃止。別の方法 (_ble_keymap_vi_imap_white_list) を用いるので個々に指定する必要はなくなる。

新しい機能

  • vi-mode (mode): bleopt 変数 term_vi_[inoxc]map
  • decode: 孤立 ESC のタイムアウトに対応
  • edit: shopt -s histverify, shopt -s histreedit に対応 #D0547
  • vi-mode (nmap): . は実装途中 (現状 nmap/omap におけるオペレータ経由の変更のみ記録) #D0542 #D0549 #D0550

バグ修正

  • vi-mode (xmap): p, P が正しく動作しないバグを修正
  • vi-mode (imap): 挿入モードに入るときに指定した引数 (繰り返し回数) が常にキャンセルされていたバグの修正
  • vi-mode (txtobj; nmap gg, G): レジスター指定が消失していたバグの修正
  • lib/vim-surround (nmap ds): 引数が内部使用のオペレータ y, d に正しく渡っていなかったバグの修正
  • prompt: PROMPT_COMMAND で設定された PS1 が永続化されていなかったバグの修正
  • decode: bind -x で曖昧な登録があって bash_execute_unix_command エラーになっていた問題の修正 #D0544
  • decode: vi.sh, emacs.sh において default.sh が多重に呼び出されていた無駄の修正 #D0545
  • core: bash-3.0 において ble/util/assign が壊れていたバグの修正

動作変更

  • vi-mode (nmap x, <delete>, s, X, C, D): support registers
  • ble: source ble.sh において無事にロードされたときに終了ステータス 0 を返すことを保証
  • edit: widget marked, nomarked を @marked, @nomarked に改名。元の widget は非推奨 (削除予定)
  • ble.sh: Linux 以外でも (readlink -f が動かないときも) シンボリックリンクを通したロードに対応 #D0543

ToDo

  • nmap ., xmap o, O (実装予定)

ToDo (マージ後)

  • vi-mode: u, C-r, U
  • vi-mode: インデント =, xmap テキストオブジェクトの正しい動作
  • complete: 略語展開
  • edit: 文法に基づく RET による複数行モード移行

@cmplstofB さま

お誕生日おめでとうございます! こちらは . をちんたら実装していたために急に失速して余り進んでいませんが、現状で push しますね。あと、今回の変更には破壊的な変更が含まれているために、bashrc における設定を書き換えねばなりません。後で dotfiles に伺います。

よろしくお願いいたします!

お誕生日おめでとうございます!

ありがとうございます。

後で dotfiles に伺います。

すみませんが,commit するまで少々時間を頂きたいです。

すみませんが,commit するまで少々時間を頂きたいです。

承知です。一行ずつコメントしてそちらで修正して頂く方が良いでしょうか。
或いは、こちらで PR を作りましょうか (実はこちらとしては PR の方が楽です)。

或いは、こちらで PR を作りましょうか (実はこちらとしては PR の方が楽です)。

分かりました。PR して下さい。只今 push しましたが,非常に半端な設定になっていると思います。お手間お掛けします……。

@akinomyoga 様
PR ありがとうございます。早速の報告ですいませんが挙動が不自然な点があります。

ノーマルモードでの r

ノーマルモードで r を押下した後 (何も変更せずに) Esc を入力するとカーソル下の文字が ^[ に置換されてしまいます。Vim の規定の挙動としては Esc は「単置換モードを抜ける」という動作が期待されます。

Commit ID: 2310b18

@cmplstofB 様

Re: ノーマルモードでの r

ご報告ありがとうございます! 修正しました! 89233a3c3841125a33d99515fe7849588da4d281 いかがでしょうか。

追記: ところで commit id は手でリンクを書かなくても、実はそのまま貼り付ければ自動的にリンクになりますよ。例: 2310b180d507f6f88a22a262235590508225a843

Re; ノーマルモードでの r

対応ありがとうございます。確認いたしました。

Commit ID: 89233a3


些事です; echo $*** の表示結果

Bash, Zsh, sh においては echo $*** というコマンドの実行結果は echo * と同等ですが,ble.sh においては echo */** と同等です [^1]。これには何か意図があるのでしょうか。それとも ble.sh の実装上偶々そうなったのでしょうか。ぶっちゃけこのようなシェル展開を行なうことは殆どないのでどちらでも構わないのですが,すこし気になりました。

^1: なお echo $** の結果は echo * の結果と同じであり,これは ble.sh 含め共通です。

@cmplstofB 様

Re: 些事です; echo $*** の表示結果

うーん。不思議ですね…。実際のコマンドの実行は bash に任せている (eval している) のでそのような違いは出て欲しくないのですが…はて

手許で globstar を有効・無効にして試してみたのですが再現しませんね…。

1. shopt -s globstar のとき @ Fedora 25

```bash:
[murase@padparadscha 0 ble]$ shopt -s globstar
[murase@padparadscha 0 ble]$ echo $* | wc
1 298 7347
[murase@padparadscha 0 ble]$ echo /
| wc
1 245 6728
[murase@padparadscha 0 ble]$ echo *
| wc
1 298 7347 # → ble.sh は * の振る舞い
[murase@padparadscha 0 ble]$ bash --norc # 素ぎ Bash
[murase@padparadscha 0 ble]$ shopt -s globstar
[murase@padparadscha 0 ble]$ echo $
* | wc
1 298 7347
[murase@padparadscha 0 ble]$ echo * | wc
1 65 686
[murase@padparadscha 0 ble]$ echo *
| wc
1 298 7347 # → bash は ** の振る舞い

### 2. `shopt -u globstar` のとき @ Fedora 25

[murase@padparadscha 0 ble]$ shopt -u globstar
[murase@padparadscha 0 ble]$ echo $* | wc
1 65 686
[murase@padparadscha 0 ble]$ echo /
| wc
1 126 2755
[murase@padparadscha 0 ble]$ echo * | wc
1 65 686 # → ble.sh は * の振る舞い
[murase@padparadscha 0 ble]$ bash --norc # 素ぎ Bash
[murase@padparadscha 0 ble]$ shopt -u globstar
[murase@padparadscha 0 ble]$ echo $
** | wc
1 65 686
[murase@padparadscha 0 ble]$ echo * | wc
1 65 686 # → bash は * の振る舞い
```

申し訳ございませんが、

  1. shopt の出力結果を差し支えなければ教えて頂けますか。
  2. 手許の設定に応じて上記の 1./2. のどちらかと同様のテストをしてどうなるか見て頂くことは可能でしょうか。
  3. (追記) あと echo "'$*'" の結果
  4. (さらに追記) 或いは、より具体的な再現手順が有りましたら

注意: 当然といえば当然ですが-s globstar のとき、物凄くたくさんファイルがあるディレクトリで echo ** と入力すると ble.sh 固まりますね…。これはどうしようもありません。なので、上記の -s globstar のテストをする時は余り沢山サブディレクトリ・ファイルのないディレクトリでお願いします)

@akinomyoga 様
態々調べてもらって申し訳無いです。

> 手許で globstar を有効・無効にして試してみたのですが再現しませんね…。 変ですね……。 ### 環境 (あまり関係ないと思うのですが……)
$ bash --version
GNU bash, バージョン 4.4.12(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
ライセンス GPLv3+: GNU GPL バージョン 3 またはそれ以降 <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ uname --operating-system --kernel-name --kernel-version --kernel-release
Linux 4.13.9-200.fc26.x86_64 #1 SMP Mon Oct 23 13:52:45 UTC 2017 GNU/Linux
shopt の出力結果 (長いので折り畳んでいます)

autocd          on
cdable_vars     off
cdspell         on
checkhash       on
checkjobs       off
checkwinsize    on
cmdhist         on
compat31        off
compat32        off
compat40        off
compat41        off
compat42        off
compat43        off
complete_fullquote  on
direxpand       off
dirspell        off
dotglob         off
execfail        off
expand_aliases  on
extdebug        off
extglob         on
extquote        on
failglob        off
force_fignore   on
globasciiranges off
globstar        on
gnu_errfmt      off
histappend      on
histreedit      on
histverify      on
hostcomplete    off
huponexit       off
inherit_errexit off
interactive_comments    on
lastpipe        off
lithist         off
login_shell     on
mailwarn        off
no_empty_cmd_completion on
nocaseglob      on
nocasematch     off
nullglob        off
progcomp        on
promptvars      on
restricted_shell    off
shift_verbose   off
sourcepath      on
xpg_echo        off

### 展開の様子
$ shopt -s globstar
$ echo * | wc
      1       8      35
$ echo ** | wc
      1    7238  307555
$ echo $** | wc
      1       8      35
$ echo */* | wc
      1      64     936
$ echo $*** | wc
      1    7238  307555
$ echo */** | wc
      1    7238  307555
$ shopt -u globstar
$ echo * | wc
      1       9      40
$ echo ** | wc
      1       9      40
$ echo $** | wc
      1       9      40
$ echo */* | wc
      1      64     936
$ echo $*** | wc
      1       9      40
$ echo */** | wc
      1      64     936
$ bash --norc
$ shopt -s globstar
$ echo * | wc
      1       8      35
$ echo ** | wc
      1    7238  307555
$ echo $** | wc
      1       8      35
$ echo */* | wc
      1      64     936
$ echo $*** | wc
      1    7238  307555
$ echo */** | wc
      1    7238  307555
$ shopt -u globstar
$ echo * | wc
      1       9      40
$ echo ** | wc
      1       9      40
$ echo $** | wc
      1       9      40
$ echo */* | wc
      1      64     936
$ echo $*** | wc
      1       9      40
$ echo */** | wc
      1      64     936
今見返して気付きましたが,これは ble.sh に全く関係なく,Bash の問題ですね。 Issue に投稿する前に上記のような試験をすべきでした。撤回します。

^W の挙動

すみません。書き忘れました。インサートモードでの ^W の入力で消去される区間が空白文字を基準としています。

$ ls /usr/share/bin▏
$ #ここで `^W` 押下
$ ls▏

2310b18 改訂までは確かにスラッシュやハイフンマイナスもその区切りとして認識していたので,修正して欲しいです。

$ ls /usr/share/bin▏
$ #ここで `^W` 押下
$ ls /usr/share/▏

Re: 些事です; echo $* の表示結果

ご提示の結果 (shopt -u globstar) の範囲では ble.sh と Bash で違いはないようですね… (bash --norc は既定で shopt -u globstar のはず)。wc なので詳細は分かりませんが、見たところは変な振る舞いもしていません。bash --norc の shopt -s globstar のときの振る舞いについても見て頂けませんか。

Re: ^W の挙動

これはここ 5a8b522 で変えてしまいました。

元々の設定を再現するには以下の様にして下さいませ。

ble-bind -m vi_imap -f 'C-w' delete-backward-cword

ただ、これは厳密には Vim の C-w とは振る舞いが異なるのですよね。なので、下手に似たものはやめて、Readline の vi-insert C-w に倣って空白区切りに変えてしまいました。後で、Vim の C-w と同様に動作するものを実装しますので、それまでは上記の元々の設定を使って頂けませんか。

Re; echo $*** の表示結果

ご迷惑お掛けしました。

Re; ^W の挙動

了解しました。

2310b18...1f57221 更新

★今回の修正にも多少の破壊的変更があります★

破壊的変更

  • vi-mode (widget): 名称変更 ble/widget/vi-insert/* → ble/widget/vi_imap/*
  • vi-mode (bleopt 変数): bleopt 変数名称変更 keymap_vi_normal_mode_name → keymap_vi_nmap_name
  • vi-mode (imap): vi-insert/magic-space 廃止。代わりに magic-space を直接用いる。

新機能

  • vi-mode (xmap): o O
  • vi-mode (nmap): . 取り敢えず完成?
  • vi-mode (xmap/nmap): gv

バグ修正

  • vi-mode (mark `x 'x): オペレータが呼び出されないバグの修正
  • vi-mode (txtobj [ia]w): 英数字と _ の連続ではなく英字と _ だけの連続を単語としていたバグの修正
  • vi-mode (imap): {count}i...<C-[> において <C-q>x <C-v>x が正しく繰り返されなかったバグの修正
  • vi-mode (imap): {count}i...<C-c> で繰り返しが有効になっていたバグの修正
  • vi-mode (nmap {N}%): 目的の行に移動しなくなっていたバグの修正
  • vi-mode (nmap _): d_ 及び d1_ が linewise になっていないバグの修正
  • vi-mode (xmap I A): 動かなくなっていたバグの修正
  • vi-mode (xmap I A): 実行後のカーソル位置がずれていたバグの修正
  • vi-mode (xmap I A c s C): 矩形挿入の後の編集範囲 `[`] から1行目が抜けているバグの修正
  • vi-mode (xmap ?): 検索 ? が operator g? になっているバグの修正
  • vi-mode (xmap / ? n N): ビジュアルモードの選択範囲が検索の一致範囲で上書きされるバグの修正
  • vi-mode (xmap / ? n N): 現在の履歴項目の中で一致しない時、別の履歴項目にビジュアルモードのまま移動するバグの修正
  • lib/vim-surround (nmap cs cS): nmap . 対応時に引数とレジスタが効かなくなっていたバグの修正
  • lib/vim-surround (xmap S): v によるビジュアルモードで改行が前後に挿入されていたバグの修正

動作変更

  • vi-mode (imap <C-w>): vim の単語区切り (w) による削除に変更
  • vi-mode (nmap [rRfFtT]x): <C-[> でキャンセルするように変更
  • vi-mode (nmap w b e ge): 非英数字 ASCII の連続と、Unicode 文字の連続 をそれぞれ別の単語と扱うように変更
  • vi-mode (xmap c s C): I, A と同様の矩形挿入に対応

ToDo (マージ後)

  • vi-mode: u, C-r, U
  • vi-mode: インデント =, xmap テキストオブジェクトの正しい動作
  • complete: 略語展開

- edit: 文法に基づく RET による複数行モード移行

@cmplstofB さま

破壊的変更について

今回はそれほど大きくありません。以下の2点ご確認下さいませ。

  • bleopt 変数: keymap_vi_normal_mode_name → keymap_vi_nmap_name
  • widget: vi-insert/normal-mode → vi_imap/normal-mode

Re: ^W の挙動

imap <C-w> 対応しました。

大きな機能は大体 (nmap u <C-r> 以外) 済んだので暫く寝かせてバグを叩きます。問題がなければそのままマージします。

@akinomyoga 様

ありがとうございます! 早速追従させていただきました。

ところで,このような事を尋ねるのは気恥ずかしいのですが,@akinomyoga 様の更新のご報告の後,追従後のこちらの環境で全く正常に動いている場合,私はその旨を都度報告していますが,このままの形でよろしいでしょうか。
それとも (例えば「 :+1: 」という絵文字を確認の合図にするなど) 正常な動作の報告は最小限にとどめ Unix よろしくバグや不具合の報告に徹するべきでしょうか。
というのは,issue の目的として「動きました」という報告は邪魔かなと思いまして……。

@cmplstofB 様

私はその旨を都度報告していますが,このままの形でよろしいでしょうか。それとも (例えば「 👍 」という絵文字を確認の合図にするなど) 正常な動作の報告は最小限にとどめ Unix よろしくバグや不具合の報告に徹するべきでしょうか。というのは,issue の目的として「動きました」という報告は邪魔かなと思いまして……。

どちらでも構いませんよ。色々な考え方はあるかと思いますが、特に問題が発生しない限りは問題ありません。お好きな方で。

あ、書き忘れましたが、ご報告ありがとうございます!

了解いたしました。確認の都度報告させていただきます。よろしくお願いします。

cw/cW の挙動

Vim ではカーソルが単語上にある場合の cw/cW は ce/cE と同等です(:help cw)。これは同じく移動コマンド w/W で操作される dw/dW と相矛盾しますが,Vim の実装上そうなっており,私個人としても論理的ではありませんがこちらの挙動のほうが便利です。
現在の ble.sh では cw/cW は dwi/dWi と同等の挙動を示します。

……というか ce/cE と同じならそれを使えば良い話でもあるのですが。

ブレース展開を開始する開き波括弧後の補完

# 本来は別 issue を建てるべきですが,すいません。ここで要望させてください。
Bash の機能であるブレース展開を用いる際,ファイル名及びディレクトリ名についての補完が効くと嬉しいです。

$ ls foo/
bar baz qux
$ cp foo/{b▏
$ # ここで補完キー押下
$ cp foo/{b▏
bar baz

Commit ID: 1f57221

Re: cw/cW の挙動

完全に ce / cE と同じ動作で良いですか? 直してみました 27019ee3a1d05d22df6bbf24a5b2496c93848e16 よろしくおねがいします。

他の変更点
カーソル変更のシーケンスの既定値 (terminfo に Ss が登録されていないとき) を空文字列に変更しましたのでご注意下さい。もし「terminfo に Ss が登録されていないがカーソル変更を使いたい」という時には、_ble_term_Ss=$'\e[@1 q' という具合に設定を上書きしてしまって下さい。


追記

Re: ブレース展開を開始する開き波括弧後の補完

うーん。これは面倒です。すみません、後回しです

Re: cw/cW の挙動

ありがとうございました。また,terminfo の件も把握いたしました。

Re: ブレース展開を開始する開き波括弧後の補完

分かりました。

申し訳無いです。cw/cW の挙動について,不完全な点があります。

完全に ce/cE と同じ動作で良いですか

ほんとうにすいません。良くないです。

:help cw によると

特別な場合: "cw" と "cW" は、カーソルが単語の上にあるとき、単語のあとにつづく
空白を含めず、単語の末尾までを変更する("ce" と "cE" と同じ働きをする)

です。

結論から言うと,ce/cE と同等の挙動になるのは,(カーソルが <word>/<WORD> 上) ∧ (右端以外にある) 場合です。

手元の Vim 8.0 では,恐らく次の3通りに分岐します。

  • カーソルが <Tab> 及び <space> の上にある時
    --> dwi/dWiと同一: 次に来る <word>/<WORD> の左端の直前まで削除し,挿入モードに。
$ cp ./foo.txt   █        /tmp/
-- NORMAL --
$ # cw
$ cp ./foo.txt  ▕/tmp/
-- INSERT --
  • カーソルが <word>/<WORD> の右端 (末尾の文字) の上にある時
    --> s と同一: 直下の文字のみを削除し,挿入モードに。
$ cp ./foo.tx█            /tmp/
-- NORMAL --
$ # cw
$ cp ./foo.tx▏           /tmp/
-- INSERT --
$ # ---
$ cp ./fo█.txt            /tmp/
-- NORMAL --
$ # cw
$ cp ./fo▏.txt           /tmp/
-- INSERT --
  • カーソルが <word>/<WORD> の右端以外の上にある時
    ---> ce/cE と同一: <word>/<WORD> の右端まで削除し,挿入モードに。
$ cp ./foo.t█t            /tmp/
-- NORMAL --
$ # cw
$ cp ./foo.t▏           /tmp/
-- INSERT --
$ cp ./fo█.txt            /tmp/
-- NORMAL --
$ # cW
$ cp ./fo▏           /tmp/
-- INSERT --

すいません,よろしくお願いします。私が言えることでもないのですが,この辺りの Vim の実装は使い易いのですが挙動に統一性がなくて謎です……。

@cmplstofB 様

Re: cw/cW の挙動

ありがとうございます。。何だか不思議な動作ですね…。未だ動作が確定できていません

空行が絡んでくると更によく分かりません。:help exclusive-linewise (とその前の項目) も絡んでくると思うのですが、色々試していてどんどん分からなくなってきました…。 [追記: すみません自己解決しました] :help exclusive-linewise 周りの日本語訳は質が悪いというか語弊があるので英文を引用します。

Which motions are linewise, inclusive or exclusive is mentioned with the
command.  There are however, two general exceptions:
1. If the motion is exclusive and the end of the motion is in column 1, the
   end of the motion is moved to the end of the previous line and the motion
   becomes inclusive.  Example: "}" moves to the first line after a paragraph,
   but "d}" will not include that line.
                                                exclusive-linewise
2. If the motion is exclusive, the end of the motion is in column 1 and the
   start of the motion was at or before the first non-blank in the line, the
   motion becomes linewise.  Example: If a paragraph begins with some blanks
   and you do "d}" while standing on the first non-blank, all the lines of
   the paragraph are deleted, including the blanks.  If you do a put now, the
   deleted lines will be inserted below the cursor position.
  • Note: これらの振る舞いは未だよく理解できていないので ble.sh では未実装です
  • Note: 色々試すと 1. は移動前の位置よりも移動先の位置の方が後にあるときにしか発動しないようです
  • 解湺済 以下の 5 の位置で w とすると 9 の位置に行く訳ですが dw とすると 5678 ぎ 4 文字だけ削除します。5 の位置で代わりに gj とするとやはり 9 の位置に行きますが、dgj としたときには期待通りに 5 から 9 の直前まで削除します。この違いは何でしょう? dw の時は 1. が関係しているような気もしますが腑に落ちません。
    12345678 90ab
    追記2 (解決): あー。これも書かれていました :help word-motions。お騒がせしてすみません
    > > もう一つの特殊なケース: オペレータコマンドと移動コマンド "w" を組み合わせたと > きカーソルがその上を移動した最後の単語が行末にあった場合、その単語の終わりがオ > ペレータの対象になるテキストの終わりになります。次の行の最初の単語ではありませ > ん。 >
  • 解湺済 また、以下の 1 の位置で } / 2gj / `a (予め 3ggma してある) / 12<space> すると何れも3行目の行頭に移動します。この時 1 の位置で d} / d2gj / d`a をすると 1. と 2. が適用されて初めの2行が削除される一方で、 d12<space> を行うと 1..a の範囲が削除されます。この違いは何でしょう?

    567890ab
    
    xxxx
    

    追記1 (解決): これ :help whichwrap に書かれていますね…。

    移動キーが削除オペレータや変更オペレータと共に使われたときは、<EOL> も
    文字に含まれる。このためカーソルが行末を通るときは、"3h" の動きと
    "3dh" の動きは異なる。
    

念のため: vim は以下を使っています。

$ vim --version
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Sep  1 2017 12:36:38)
適用済パッチ: 1-1030

1f57221...fb77258 更新

新機能

  • vi-mode (exclusive motion): :help exclusive-linewise 特別規則 (exclusive -> inclusive, exclusive -> linewise) に対応
  • vi-mode (omap): C-c C-[ で明示的にキャンセル
  • vi-mode: keymap/vi_test.sh 追加。regression が酷いので vi-mode の動作テストを自動化
  • complete: bleopt 変数 complete_stdin_frequency (既定値 50) 追加

動作変更

  • vi-mode (nmap e, E): 移動先が最終行の最後の文字の空白のとき、omap なら bell を鳴らさないように変更
  • vi-mode (omap/xmap <space>, <back>, <C-h>): 改行の数え方を変更
  • vi-mode (nmap cw, cW): 単語の最後の文字、および空白の上にいるときの振る舞いの変更
  • decode (ble-bind): ble-bind -D でキーマップの内部状態も出力するように変更
  • term: _ble_term_SS の既定値を空文字列に変更
  • complete: shopt -s no_empty_cmd_completion では補完を (コマンドの補完以外も) 全く行わないように変更
  • edit (ble/widget/exit): 編集中の文字列が残っているとき、灰色で再描画してから exit するように変更

@cmplstofB 様

Re: cw/cW の挙動

対応しました 62d95015c8839b2409712f40fc3ff24f2f5e691a。

  • 同時に、何度も手でテストすると気が変になりそうだったので、キーボード操作の自動テストの枠組みを追加しました (source "$_ble_base/keymap/vi_test.sh")。
  • :help exclusive-linewise の振る舞いも色々試して分かったので実装しました 5a5dca034f083d41a7c34174c0e3819cce42897a。実際の Vim の振る舞いは、:help の記述と違って以下のようなものに思われます:
    オペレータに続く移動コマンドが排他的で、移動後の位置が1桁目のとき <ol> <li>移動後の位置が移動前の位置より後に位置しているとき、オペレータの対象範囲の最後は<br /> 前の行の最後に動かされる。さらに、移動前の位置がその行の最初の非空白文字以前にあ<br /> るとき、linewise になりそれ以外のとき inclusive になる。</li> <li>移動前の位置が移動後の位置より前に位置しているとき、移動前の位置が行頭にあるとき<br /> linewise になる。<br />

  • :help word-motions の振る舞いにも対応しました fe017e19b87852248ae54d512124cdeaf89517ab。

@akinomyoga 様

cw/cW の挙動確認いたしました。ありがとうございます。

早速ですが,少々要望があります。

コマンドラインモード及び検索モードでの幾つかの挙動の実装

^[ 押下で離脱

:help c_CTRL-[ 及び :help search-commands によれば,コマンドラインモードや検索モードは ^C だけでなく ^[ によっても解除されます。

情報の保存

^[ および ^C によって離脱し (つまり実行せず中断し) た場合でも,履歴呼び出しキー (^P 等) によって呼び出せます。これについて,適当な手引き頁が見付かりませんでしたが,Vim で :foo と入力した後 ^M で実行せずに ^[ (または ^C) で実行を中断 した場合でも,: と入力してコマンドラインモードに再び遷移した後,履歴を呼び出すと :foo という入力が保存されていることが分かると思います。

K コマンドの改善・提案

例によって私の確認が甘く実際と微妙に異なる動作を述べている可能性があります,すいません。できる限り環境変数などの依存は減らして試験はしているつもりです。

ページを跨がない場合を考慮して欲しい

例えば clear などの一部のコマンドの手引きは極々短かく,仮想端末の高さを越えません。そのような場合,現状では man ページに由来すると思われる制御文字らしきものが表示されるだけで,手引きを閲覧することができません[1]。

一方 tty のように,tty --help で手引きが表示されるコマンドで,その高さが仮想端末のそれを越えないものは一応正常に表示されます。しかし結局不具合が生じてしまいます。次の段落で説明します。

手引きの終了時に表示が乱れる

ls などの長い (つまり仮想端末の画面高を越える) 手引き,及び上記の二通りの表示の後,共通する動作として空行が表示されます。この空行には,恐らくこの段階で,K を押下した時のコマンド行が格納されています[2]。挿入モードに入り何か入力するか,コマンド履歴呼び出しキー (k など) を押下するとそのキーが適切に処理されたあと先ほどの空行にコマンド行が出力されます。しかしこの場合でもプロンプト等は表示されていません。

メタ文字が内部フィールド区切り文字を介さずに存在すると手引きが検索されない

例えば以下のような場合です。

$ ls| less
-- NORMAL --
$ cd; ls -l
-- NORMAL --

【提案】K の押下位置によって手引きを表示するコマンドを変更する

Vim の既定では (:help K) K は「カーソル下の <Keyword> (:help iskeyword) を引数に man を実行するようになっていますが,これと同じような機能にして欲しいです。

ご存じだと思いますが,Bash の vi-mode には (vi の機能ではないので当然) なく,また Zsh の vim-mode には既定では K は設定されていません。大抵は run-help なる函数[3]を K キーに割り当てますが,これは基本的に最左のコマンドのみを対象とします。

ble.sh における K に望む位置別の挙動

$ test $(expr 8 / 2) -eq 4 || echo 'This will not be printed'
   ^
$ # K --> function-for-help test --> man -P 'less $LESS -p ^test' bash
$ test $(expr 8 / 2) -eq 4 || echo 'This will not be printed'
              ^
$ # K --> function-for-help expr --> expr --help | $PAGER
$ test $(expr 8 / 2) -eq 4 || echo 'This will not be printed'
                                                     ^
$ # K --> function-for-help echo --> man echo

ここまで複雑ではなくてもいいです。これはあくまで理想です。

ヴィジュアル矩形モードでの引数を解釈して欲しい

具体で示します。(カーソルの位置を @ 記号で示します)。

$ fn() {
    @ome
    sommand's
    list
}
-- NORMAL --
$ # ^V2j
$ fn() {
    @ome
    @ommand's
    @ist
}
-- VISUAL BLOCK --
$ # 3I#^[
$ fn() {
    @##some
    ###command's
    ###list
}
-- NORMAL --

Re: Commit ID

知らなかったです。教えて頂きありがとうございます。

脚註

註釈

  1. ^ 環境変数 $LESS に --quit-if-one-screen という値を取らせた際は現在行の直下に件の制御文字が表示され,--RAW-CONTROL-CHARS を取らせるとそれらの制御文字は表示されなくなります。
  2. ^ なぜなら 3l と入力したり,fy と入力すればそれらしき位置 (カーソルは見えるが文字が見えないので何とも言えないですが) にカーソルが移動するからです。
  3. ^ 因みにこの函数の便利だなと思うところはエイリアスと組込みコマンドを解釈してくれるところです。

Commit ID: fb77258

@cmplstofB 様

ご報告ありがとうございます! 色々と動作を確認して頂いて心強いです。
すみません。実際の対応は後になりますが、K については丁度先日対応したところだったので現時点で push します。

Re: コマンドラインモード及び検索モードでの幾つかの挙動の実装

コマンドラインモードにおける ^[ と履歴の件、承知しました。対応します

Re: K コマンドの改善・提案

K に関しては自分でも気になっていたところなので、折しも、先日修正を行ったところでした d83fd58ffbce61d1b07a677d1637b622a5c43266 。修正は、

  • 今まで "$command_name --help" を呼び出して、それに失敗したら "man $command_name" を呼び出すというような実装でしたが、優先順位を変えて先に man $command_name を呼び出すように変更しました。
  • 今までコマンド行の一番初めの単語をコマンドとして扱うようにしていましたが、【提案】K の押下位置によって手引きを表示するコマンドを変更する でご提案いただいたのと同様にコマンド名を抽出するように変更しました。

Re: ページを跨がない場合を考慮して欲しい

これは問題ですね…。less がユーザの設定に依存し、どのユーザの環境でも同様に動作するわけではないという事を看過しておりました。ユーザの任意の設定を継承するようにすると対処が難しくなるので、取り敢えず既定では LESS= LESSPIPE= less などとしてユーザの設定が干渉しないように修正する予定です。 [撤回 (2017-11-10 11:10): 元々 $PAGER を参照していたので詳細なページャの振る舞いはそもそも制御下にありませんでした。考えを改めて、ユーザの設定はできるだけ潰さないことに変更しました] 同時に、ble.sh 用の pager の設定をできるように bleopt 変数を追加するのが良さそうでしょうか。

例えば clear などの一部のコマンドの手引きは極々短かく,仮想端末の高さを越えません。そのような場合,現状では man ページに由来すると思われる制御文字らしきものが表示されるだけで,手引きを閲覧することができません[1]。

これは、既定で $command_name --help にしていたのがいけませんでした。echo --help, clear --help などはコマンド実行が成功してしまいます。なので、ble.sh は正しくヘルプの文字列が得られたと勘違いして、その内容を表示してしまいます。

Re: 手引きの終了時に表示が乱れる

恐らくですが、less から抜けた時に元の画面内容が復元されるという前提の実装が原因ですね…。ble.sh は端末上にプロンプトや編集中の文字列の表示が残っていると勘違いして不必要な描画は行わないために、"見えないがそこにある行" になってしまいます。

--quit-if-one-screen の時は、画面内容の保存・復元が行われずそのまま内容が出力されてしまうので、画面の表示位置がずれてしまうのが原因でしょう。

確認: 複数ページに亘る時の動作について確認させていただきたいのですが、何らかの設定で端末の alternate screen (SM(?1049) / terminfo smcup) を無効にしている環境でしょうか? 例えば、

  • 環境変数 LESS き -X を指定している、
  • ~/.tmux.conf き set-window-option -g alternate-screen off にしている、
  • ~/.screenrc で altscreen off にしている、
  • そもそも使っている端末が altscreen に対応していない、
  • terminfo き smcup, rmcup が登録されていない or 書き換えて消している

などの環境です (alternate screen が有効になっていれば、less から抜けた時に、less を呼び出した瞬間の端末の状態が復元されます)。もし、altscreen の問題ではない場合には、また調査が必要になります。

少なくとも、ユーザが altscreen を無効にしている or 端末が対応していないケースはあるので、ページャを呼び出した後には毎回再描画するように修正します。

Re: メタ文字が内部フィールド区切り文字を介さずに存在すると手引きが検索されない
これは、今までの実装で "最初の単語 (空白区切り)" でコマンドを探索していたのが原因ですね。これは d83fd58ffbce61d1b07a677d1637b622a5c43266 で発生しなくなったはずです。

Re: 【提案】K の押下位置によって手引きを表示するコマンドを変更する

  • 手引きを表示するコマンドについては、先に書いたように d83fd58ffbce61d1b07a677d1637b622a5c43266 で修正しました。
  • run-help / run-help-hoge に対応する仕組みは作成します。恐らく ble/help:default, ble/help:hoge 的な関数名にすることになると思います (或いは、後でコマンド毎の補完の仕組みと統合するかもしれませんが、このあたりはもう少し考察します)。
  • man -P 'less $LESS -p ^test' bash これは考える必要があります。手許で試しますと test は行頭にないので引っかかりません。-p "^[[:space:]]*test" にすると一致範囲に空白が含まれてしまい見苦しいことになってしまいます…。単に -p test とするともっと手前の別のものに引っかかってしまいます。難しいですね…。今 less +$((man bash | grep -n ...))g/test^M 的な方法を考えていますが、気になることがあるのでもう少し考えてみます。後、各 OS でぎ less の互換性がどうなっているのかも確認しなければなりません

Re: ヴィジュアル矩形モードでの引数を解釈して欲しい

これは手許ではご提示の通りに動いているので不思議ですね…。
もう少し分かることがありましたら教えて頂けると幸いです

@akinomyoga 様
ありがとうございます。

Re: clear の手引き

ああなるほど,clear コマンドはちょうど tput clear を送信するので,man ページ由来だと思っていた制御文字は画面制御のそれだったんですね。

Re: ble.sh 用の pager 設定

同時に、ble.sh 用の pager の設定をできるように bleopt 変数を追加するのが良さそうでしょうか。

はい,それが好いです。個人的に,$MANOPT も無効にした方が良いと思います。これも私の設定の問題ですが,$MANOPT に --all 等の値を設定していると,ble.sh と man ページが競合するか何かしてキー入力が受け付けられなくなります。

Re: 端末の設定

私は Xfce4 Terminal [1] を使っているのですが,この仮想端末は xterm-256color を terminfo として用いており,xterm-256color の terminfo ではきちんと alternate screen は有効になっておりました。

Re: 【提案】K の押下位置によって手引きを表示するコマンドを変更する

押下位置別の man ページが起動されることを確認いたしました。

man -P 'less $LESS -p ^test' bash の件ですが,私自身もちょっと無理があるなと思っています。そもそも $PAGER を less でなく (more もしくは高機能なもの) を使っていたりする場合,強制的に less が実行されてしまいますし[2]。

Re: メタ文字が内部フィールド区切り文字を介さずに存在すると手引きが検索されない

確認しました。問題なかったです。

Re: ヴィジュアル矩形モードでの引数を解釈して欲しい

あーまたやらかしてしまいました。すいません,勘違いでした。というのは,^Vで矩形選択した後iなど未定義の入力を行ない,直後 (^[ を押下せず) に 3I とやると引数が解釈されません。が,これは Vim の挙動と全く同一ですので完全に正常でした。

脚註

脚註
  1. ^ https://git.xfce.org/apps/xfce4-terminal
  2. ^ もはや ble.sh の機能からは逸脱しますが,「man が man ページ用のファイルを読み込み .TP^Mfoo という部分を解釈するとき,foo という文字列をどこかに格納しておいて,man --topic="foo" のような形で指定できる」くらいの機能,man 程度に重厚なプログラムであれば実装しても不思議じゃないんですが,今のところそういうのはなさそうですね……。

Commit ID: d83fd58

不躾ですいませんが,cache.d ディレクトリが ble.sh の起動ファイル (# bash script to be sourced from interactive shell で始まるファイル) と同一のディレクトリに作成されているのは何か理由があってのことなのでしょうか。

もしもそうでないなら,$XDG_RUNTIME_DIR/blesh にそれらのファイルを作成するようにするか,環境変数等で指定できるようにしていただくことはできないでしょうか。XDG Base Directory の仕様ではランタイムファイルは「$XDG_RUNTIME_DIR 配下の適切に名付けられたサブディレクトリにそのファイルを配置す」ることが勧告されているからです。同じ仕様によると「あまり大くの容量を使うべきでない」そうですが,私の環境では cache.d/1000 以下の総容量は 2.0 e2 KiB 強程度ですので全く問題ないと思います。

それは変更するかなどうしようかなと思っていたところでした。

今は ble.sh はユーザのホームディレクトリの下にインストールして使っていただいていますが、例えばシステムの /opt/blesh だとか /usr/local/share/blesh の下にインストールして使うという場合も考えられる訳です (cache.d/1000 のようにユーザ ID (1000) でサブディレクトリを切っているのもそういった使用を想定してのことでした)。自動的にインストール先の種類を正しく特定してディレクトリ構成を変更するのも面倒だなと思っていたのです。

取り敢えず、対応します。

あ、すみません。$XDG_CACHE_HOME ($HOME/.cache など) の話かと思って書いてしまいました。$XDG_RUNTIME_DIR の話ですね。

  • blesh/cache.d/1000 はむしろ $XDG_CACHE_HOME に対応します。
  • $XDG_RUNTIME_DIR (揮発性のデータ) に対応するものは、実は /tmp/blesh/1000 に置いています。

あと今改めて考えてみた所、blesh が $XDG_DATA_HOME ではなくシステムにインストールされていたとしても、ユーザ毎のファイルは XDG のディレクトリに置いても良いですね…。真面目に考えていなかったので、その点に想到していませんでした。

取り敢えず、$XDG_CACHE_HOME と $XDG_RUNTIME_DIR には対応します。

細かいことですいません……。
あと,もう一つ細かいのですが,failglob を有効にしていると,l* のようなコマンドを入力した場合,(決定キーを押下する前に) 「-bash: 一致しません: _ble_decode_keymap_stack[last]」というエラーメッセージが出ます。その後はもはや何を入力しようとしてもそのメッセージが出てまともに入力できなくなります。

GNU bash, バージョン 4.4.12

不具合報告ありがとうございます!

細かいことですいません……。
あと,もう一つ細かいのですが,failglob を有効にしていると,

これはまずいですね…全然細かくありません。これも対処します

fb772580ff14337010083ed5fab28adfe9349637...d886a7eea9d12e064756b3bac057f29c375688eb 更新

新機能

  • vi-mode (nmap): * # qx...q @x
  • vi-mode (cmap): 幼歴
  • core: bleopt 変数 pager (既定値 '')
  • vi-mode (nmap K): ble/cmdinfo/help:$command と ble/cmdinfo/help

バグ修正

  • vi-mode (cmap <C-[>): コマンドラインモードをキャンセルするキーマップが bell で上書きされていたバグの修正
  • decode: shopt -s failglob, shopt -s nullglob で unset が正しく動かないバグの修正
  • vi-mode (nmap K): MANOPT=-a で操作できなくなるバグの修正

動作変更

  • edit (ble/widget/command-help), vi-mode (nmap K): カーソル位置のコマンドの man を表示するように変更
  • base: キャッシュディレクトリ・一時ディレクトリの決定で、それぞれ XDG_CACHE_HOME, XDG_RUNTIME_DIR を参照するように変更
  • Makefile: インストール先ディレクトリで、XDG_DATA_DIR を参照するように変更
  • isearch: 実際に必要になるまでコマンド履歴のロードを遅延するように変更
  • vi-mode (nmap K): 組み込みコマンド・キーワードは man bash を表示する。
  • vi-mode (nmap K): シェル関数は関数定義を表示する。

@cmplstofB 様

数々のご報告ありがとうございます。遅くなりましたが、一通り対応しました。

Re: コマンドラインモード及び検索モードでの幾つかの挙動の実装

  • ^[ 押下で離脱 → 対応しました 884e387cdeba76d18bc608105ff9e4242cd1fa65 (実はバグでした)
  • 情報の保存 → 履歴に対応しました 6bc5caf8ff98e4572fb32706c22cb845538b674c

Re: K コマンドの改善・提案

  • ページを跨がない場合を考慮して欲しい → 先の返信にて対処 d83fd58ffbce61d1b07a677d1637b622a5c43266
    完全な解決ではありませんが、これは clear --help などによる不適切な表示でしたが、man を優先させることにより起こりにくくなりました。
  • 手引きの終了時に表示が乱れる → 毎回再描画するようにしました d886a7e
  • メタ文字が内部フィールド区切り文字を… → 先の返信で解決済み d83fd58ffbce61d1b07a677d1637b622a5c43266
  • 【提案】K の押下位置によって… → 先の返信で解決済み d83fd58ffbce61d1b07a677d1637b622a5c43266
  • 大抵は run-help なる函数[3]を… → d886a7e
    ユーザ定義のヘルプをシェル関数 ble/cmdinfo/help で定義可能に (Zsh run-help に相当)。個別のコマンドのヘルプをシェル関数 ble/cmdinfo/help:コマンド名 で定義可能に (Zsh run-help-コマンド名 に相当)。※エイリアスにはできません。必ずシェル関数として定義して下さい。
  • man -P 'less $LESS -p ^test' bash → 対応しました d886a7e
    組み込みコマンドおよび予約語に対しては man bash に対応しましたが 2 回 man bash を呼び出している(後述 "日本語 man の内容の取得の仕方?")ので遅いです。
  • ble.sh 用の pager 設定 → 対応しました d886a7e 現在の振る舞いは:

    • man を使って表示するときのページャは man に任せます。

    • それ以外のときは ble.sh がページャを選びます。bleopt pager が設定されていればそれを使います。それ以外のとき $PAGER があればそれを使います。どちらも定義されていないとき less / pager / more の順にコマンドを探索します。何れも定義されていないとき cat を用います。

  • $MANOPT き --all 等の値を設定していると… → バグでした。修正しました d886a7e

日本語 man の内容の取得の仕方?

実装を改善できないかと少し悩んでいることがあります。
何か情報・アイディアをお持ちでないかお尋ねするものです。

現在、組み込みコマンドおよび予約語に対しては、man bash の該当位置にジャンプするようにしていますが、ジャンプ先の位置を特定してから実際に表示するために 2 回 man bash を呼び出しているので多少遅くなっています (man は内部で gunzip や groff などを毎回呼んでいるので遅い)。この無駄を省くために

man_contents=$(man bash) # man bash の内容を変数に記録する
line_number=$(grep ... <<< "$man_contents") # 組み込みコマンドの該当位置を探索
less -r +${line_number}g <<< "$man_contents" # もう一度 man bash を呼び出すのではなく記録したものを表示

的なことをしたいのですが、ここで以下の問題が発生します。$(man bash) とすると

  1. 日本語の見出しの2文字目以降が何故か消える。
  2. また、太字・強調などの制御シーケンスが出力されない。

これは man bash > a.txt のようにファイルにリダイレクトしても、man bash | cat の様にパイプに流しても同様です。Fedora/Ubuntu/Cygwin で再現します。これは大分問題な気がするのですが、検索しても同じ症状を訴えている人は見当たりません (単に検索力不足かもしれませんが)。この症状に関する対処法などご存知でしょうか (例えば、出力を制御するオプションなどで…)。

実は、以下のような感じで日本語の man の内容を読み出すことはできました。

stealer='sh -c "cat >> $tmpfile"'
MANPAGER=$stealer PAGER=$stealer man bash
IFS= read -r -d '' man_output < "$tmpfile"

しかし $MANPAGER / $PAGER / オプション -P は POSIX で定められていないので、可搬ではありません [追記 (2017-11-11 1:12): 今あらためて POSIX を見たらオプションはなくても PAGER はちゃんとありますね…。何れにしても日本語で問題が生じていたのは謎ですが…]。 ということで MANPAGER=$stealer PAGER=$stealer man bash > $tmpfile2 などとして $tmpfile と $tmpfile2 の内容を結合しようとも考えたのですが、こうすると途端にまた問題が再発します。というわけで、今はこの方法は使っていません。

Re: 端末の設定

私は Xfce4 Terminal [1] を使っているのですが,この仮想端末は xterm-256color を terminfo として用いており,xterm-256color の terminfo ではきちんと alternate screen は有効になっておりました。

情報ありがとうございます! alternate screen が有効になっているのにも拘らず "複数画面に亘るヘルプの内容で less から抜けたとき空行になってしまう" のは原因が未だ分かりません。何れにしても、今回の修正で毎回再描画するようにしたので、この問題が解決していると良いのですがいかがでしょうか。

Re: 【提案】K の押下位置によって手引きを表示するコマンドを変更する

押下位置別の man ページが起動されることを確認いたしました。

確認ありがとうございます!

Re: メタ文字が内部フィールド区切り文字を介さずに存在すると

確認しました。問題なかったです。

こちらもありがとうございます!

Re: $XDG_RUNTIME_DIR

対応しました e892d42795785cb01edc75dd34dcfbf2cb687342 49ee5be367ab47dd95cf46fc30d8aeff02afc9c1

  • 事前計算のキャッシュは ${XDG_CACHE_HOME:-$HOME/.cache}/blesh → $_ble_base/cache.d/$UID の優先順で確認・作成します
  • 実行時の作業データは ${XDG_RUNTIME_DIR:-/run/user/$UID}/blesh → /tmp/blesh/$UID → $_ble_base/tmp/$UID の優先順で確認・作成します
  • インストール先は (make 引数の INSDIR) → ${XDG_DATA_DIR:-$HOME/.local/share}/blesh の優先順位で決めます

Re: failglob を有効にしていると,l* のようなコマンドを…

修正しました f15f8c5cc3c45ce77e7b1a8ac4df2d50d49c2283 98b6546c6d7a1c8752439d7918506f7723ceef95 追記: こちら完全かどうか自信がないので確認して頂けますと幸いです

@akinomyoga 様

返信が遅れてしまって申し訳ありません。

また,基本的に,カーソル位置は @ で示すことにします。

コマンドラインモードでの ^D

たとえコマンドラインに文字があっても終了してしまいます。

$ some command
:@
$ # ^D
ログアウト
# 終了する

Re: failglob

中止キーは受け付けるようにはなりましたが,依然として入力には支障が生じます。
コマンドラインで $ l* と入力すると bash: 一致しません: l* という
エラーメッセージらしい表示が入力位置の右隣に発生し,続く入力が妨げられます。
自分勝手ですいみませんが,私は failglob の他にも様々な機能を掛け合わせており,
それらの組合せを手動で試験するのは正直に言ってしんどいです。
多分 glob 関係の機能の幾つかが絡み合っているのだと思うのですが,それらを自動で組合せ,
なおかつ「入力に支障が生じたかどうか」を見極めるテストコードは自分には書けないです。

Vim 等から ^Z で戻ったときのカーソル形状

私は Vim のノーマルモードにおいて矩形カーソルを表示させているのですが,
ここから ble.sh に ^Z で戻ると ble.sh vi-mode の挿入モードにも拘わらず矩形カーソルのままになります。
Vim でなくても,カーソルの形状が ble.sh 以外によって変化した時に発生するようです。
一度モードを切り替えると直ります。

非挿入モードでの外部貼り付け

非挿入モードで仮想端末に文字列を貼り付けると,その内容がそのモードの時のコマンドとして入力されます。
仕方無いことならばそれでもいい
(非挿入モードから挿入モードに戻るのには最悪 2キーを押すだけで十分なので,さしたる手間ではない)
のですが,できれば外部からの貼り付けの際には挿入モードでのそれとして一律に解釈されるようにして貰いたいです。

vi-mode と関係ない事柄

すいません。本来は別 issue/PR 案件なのでしょうが許して下さい。

存在するパスを示すシンタクスハイライトが特定条件下で崩れる

既定では,存在するパスには下線が引かれますが
これが次のような状況で,(存在しない /not/exist/path を存在する /now/exist/path に変更)

$ cmd /not/exist/path some string
$ cmd /now/exist/path some string
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^

^ のように行末まで下線が引かれていしまいます。

  • 発生するのがこの場合のみなのか

    • 複数行の編集時にも発生する (行内で)
  • このハイライトが編集によりどのように変化するか

    • /another/path空白を含まない文字列の編集では解消されない。
    • /not/exist/path の編集で即座に解消される。

といったことはちょっと調べ尽せていないです。

sudo, xargs 後のシンタクスハイライト

節題の通りです。これがあるとすごく捗るのですが,厳しいでしょうか。

d886a7eea9d12e064756b3bac057f29c375688eb...256d05c7aed6491899b3d4961217d63d004c94ae 更新

バグ修正

  • general: failglob で問題が生じるバグの修正 #D0630
  • keymap/vi (nmap q): bash-3.0 で動かなかったバグの修正
  • keymap/vi (cmap): C-d で終了してしまうバグを修正 #D0629
  • edit (ble/widget/command-help): エイリアスの上でヘルプを実行しようとすると無限ループになるバグを修正
  • edit (ble/util/type): "-" で始まる名前のコマンドの種類の判定に失敗し着色されなかったバグの修正
  • complete: 変数代入の右辺やリダイレクト先で補完できないことがあるバグの修正 #D0627
  • complete: 補完する単語にパラメータ展開が含まれるとき ble.sh のローカル変数の値を参照している問題の修正 #D0628

動作変更

  • bind/decode: 孤立 ESC の読み取り方法を変更。
  • bind/decode: input_encoding=C の時の孤立 ESC および C-@ の読み取りに対応
  • complate: 重複して列挙される候補を統合する #D0606
  • complete: 厳密一致するディレクトリ名が何故かコマンド候補に現れる問題の修正 #D0608
  • edit (command-help): 幾つかの組み込みコマンド・予約語について man bash の正しい位置に移動するように修正 #D0609
  • edit (command-help): クォートなどを除去してからコマンドのヘルプを探索するように変更 #D0610
  • core: 条件コマンドの比較で右辺をクォートし忘れていた箇所を修正 #D0618
  • highlight: shopt -s failglob の時、失敗する単語にエラー着色をする #D0630

構文解析 - 新機能

  • syntax: [...] によるパターンの解析に対応 #D0612
  • syntax: ブレース展開の着色に対応 #D0622
  • syntax: チルダ展開の着色に対応 #D0626

構文解析 - バグ修正

  • syntax: $({ echo; }) や $(while false; do :; done) において }, done 等の後にコマンドがないと構文エラーになっていたバグの修正 #D0593
  • syntax: - で始まる名前のコマンド・関数名が正しく着色されないバグの修正 #D0595
  • syntax: if :; then :; fi $(echo) などの構文エラー着色が実行されないバグの修正 #D0597
  • syntax: 先読みによる不整合が起こるバグの修正・先読みの枠組みの整備 #D0601

    • プロセス置換周りで部分更新により不整合が生じるバグを修正

    • function hello (()) としておいて ) ( を挿入して function hello () (()) にすると不整合が生じるバグを修正 #D0602

  • syntax: 途中で shopt -u extglob にしても _ble_syntax_bashc が更新されないバグの修正 #D0615

構文解析 - 動作修正

  • syntax: > a.txt; echo は構文エラーではないことに対応 #D0591
  • syntax: 変数代入・リダイレクトの後では予約語は意味を失いコマンドとして扱われることに対応 #D0592
  • syntax: time や time -p は構文的に正しいことに対応 #D0593
  • syntax: echo $(echo > ) なおぎ > の引数がない構文エラーにより $() が閉じず別の構文エラーを引き起こしていたのを抑制 #D0601
  • syntax: function hello (()) は bash-4.2 未満では構文エラーとして扱うように変更 #D0603
  • syntax: time -p -- command を独立した文脈で解析するように変更 #D0604

    • complete: これにより time の引数のコマンド補完ができなかった問題は解消した #D0605

  • syntax: extglob 内部のプロセス置換 @(<(echo)) に対応 #D0611
  • syntax: 変数代入の右辺にある不活性になった extglob の入れ子 @(@()) も不活性にする #D0613
  • syntax: shopt -u extglob の時でも * や ? を着色する #D0616
  • syntax: for var in args... ぎ args におけるリダイレクトの禁止 #D0623
  • highlight: ヒアストリングの場合はパス名展開・ブレース展開を行わない #D0624
  • highlight: リダイレクト先ファイル名が複数語に展開されたらエラー着色 #D0625

@cmplstofB 様

ご報告ありがとうございます!

Re: コマンドラインモードでの ^D

ありがとうございます。修正しました d0056ba9812fe859146101966b1380b454b8fb2c

Re: failglob

256d05c7aed6491899b3d4961217d63d004c94ae

コマンドラインで $ l* と入力すると bash: 一致しません: l* という
エラーメッセージらしい表示が入力位置の右隣に発生し,続く入力が妨げられます。

  • ありがとうございます。修正しました。これは単語を着色するために起こしていたパス名展開が原因でした。
  • 他にも試してみると、単語分割 words=($var) を実行しているところでグロブパターンが含まれていると駄目です…これは大分広範囲に亘ります…。修正しました。

取り敢えず分かる範囲で修正はしましたが、もしかすると他にもあるかもしれません。

本当のことを書くと「ble.sh の処理中は shopt -u failglob にしておいて、コマンドを実行するときだけ shopt -q failglob の状態を復元する」というようにすれば原理的に問題は発生しなくなるはずです。或いは、Bash の出すエラーメッセージを全て黙殺する (/dev/null に繋ぐ) ということでも良いはずです。しかし ble.sh の実装自体本来はパス名展開に依存してはならないはずなので、バグが顕れやすいように現状の実装のままにさせて下さい。

自分勝手ですいみませんが,私は failglob の他にも様々な機能を掛け合わせており,
それらの組合せを手動で試験するのは正直に言ってしんどいです。

お手数をおかけして申し訳ございません。症状さえ教えて頂ければ、多くの場合は原因究明はこちらで行った方が早い気がするので (ble.sh の中身や現状の問題点を把握しているので)、最初に簡単に報告していただいた方が良さそうです。こちらで思い当たることがなく再現もできない場合には、御協力をお願いすることにします。

多分 glob 関係の機能の幾つかが絡み合っているのだと思うのですが,それらを自動で組合せ,
なおかつ「入力に支障が生じたかどうか」を見極めるテストコードは自分には書けないです。

テストケース (問題が起こる可能性のあるケース) さえ頂ければ様々の組み合わせで自動実行するというのはこちらで書くこともできます。(本当は今回ご報告いただいた l* の場合についてもテストに加えるべきなのかもしれないですが…)

Re: Vim 等から ^Z で戻ったときのカーソル形状

この点に関しては思い至っていませんでした。普通、端末の状態を変更したら終了時や C-z (SIGTSTP) を受け取った時に端末の状態を復元するのが礼儀なのですが、カーソル形状に関しては変更前の状態を知ることができないので Vim は復元してくれないのですね…。

個別に対応することはできますが、これは外部コマンドを呼び出すとき全般の問題になりますね…。現状では keymap/vi.sh で bleopt term_vi_nmap を何も考えずに出力するようにしていますが、やはり ble.sh の枠組みとして明示的にカーソル状態を管理するようにしたい気がします。現状では、先の Vim と同様の設定方法という要望を反映して制御シーケンスを設定できるようにしていますが、これだと ble.sh 的には現在のカーソル状態がどうなっているのか分からない (一応 bleopt term_vi_nmap を解析するという手もありますが回りくどい) ので、"カーソル形状を指定する設定項目" を作るという案です。あるいは、何か良い案や考えなど有りましたらどうぞお知らせ下さい。


以降の項目については vim と関係なく深刻でもないので、取り敢えず merge の方を優先させることにします。

Re: 非挿入モードでの外部貼り付け

Bracketed paste mode (DECSET(2004)) への対応ということで宜しいでしょうか (cf memo.txt ToDo 2015-08-14/3)。これも、現在の mode の状態を管理して、外部コマンドを呼び出すときなどに復元するというように実装する必要があるので、上記のカーソル形状の対応と同時に行うことにします。

Re: 存在するパスを示すシンタクスハイライトが特定条件下で崩れる

ご報告ありがとうございます。調べていただいてすみません。実は、これは既知の問題で原因も分かっています。変更の範囲を検出する効率の良い処理方法が複雑になるので保留になっていました (cf memo.txt ToDo 2015-08-16 / memo.txt #D0231)。また改めて考えてみて可能そうであれば対応します。

もし気になるようでしたら効率の悪い実装 (1文字入力する度に全単語について着色を再度計算する) に切り替える手もありますが、長いコマンドラインで遅くなります。

Re: sudo, xargs 後のシンタクスハイライト

プログラム補完と似た枠組みで、コマンド毎の単語の着色に対応しようと考えていましたので、その方向で考えてみます。


操作の様子 (animated GIF) の依頼?

未だバグは沢山あるとは思いますが、全く使えないということもなさそうなので、そろそろ merge しようかと考えています。何れにしてもバグは多くの人に使っていただかないとなかなか取り除けません (実際ユーザがいるのかは不明ですが…)

それで merge する前に最後に vi-mode による操作の様子を animated GIF にしようかと考えています。しかし、自分で作るとなると vim 初心者なのでなかなか難しいので、作成を依頼したいのですがいかがでしょうか。何卒御一考頂ければと考えております。

@akinomyoga 様,様々の追加ありがとうございます。

Re: コマンドラインモードでの ^D

確認しました。

Re: failglob

うーん,まだ問題があります。(dotfile のコミットには解決した旨を書いてありますがあれは勘違いです)
コマンドに glob が含まれている場合などはいいのですが,
存在しないパスを補完しようとすると不具合が発生します。

$ ls /usr/share/foo@
$ # 補完キー
$ ls /usr/share/foobash: 一致しません: /usr/share/foo*
@

とりあえず,glob 関係のオプションは以下の通り有効にしてあります。

shopt -s globstar
shopt -s nocaseglob
#shopt -s failglob
shopt -s dotglob
shopt -s extglob

Re: 動画の作成

私でよければ慶んで承ります。

動画について,なにか特別な指定等ありますでしょうか。
Emacs モードでの動作風景を見ると,XTerm 既定の配色及びフォントで,何のキーを入力したかは
(例えば ^A という入力) 表示されていませんが,それを踏襲する形でいいでしょうか。
個人的に,特に Vim モードでの特徴を示す為にはどんなキーが押下されているかが表示されている方が
良いかなと思うのですが。


追記

起動時の履歴

起動直後に履歴を遡る (というより ^P を押下する) と一番始めの履歴にまで戻ってしまいます。
確認お願いします。

@cmplstofB 様

ありがとうございます。

Re: failglob

穴だらけですみません…。直しました d0b8576a06a1cffe255945da34717d00f078d56c

本当はご提示の設定でこちらも暫く使ってみて自分で直すべきところなのかもしれませんが、引き続き failglob 周りの不具合がないか使っていただいて確認していただくこと、お願いしても良いでしょうか。その間、他の項目について攻めることにします。

Re: 動画の作成

取り敢えず自由に作っていただいて問題ありません。

Emacs モードでの動作風景を見ると,XTerm 既定の配色及びフォントで,何のキーを入力したかは
(例えば ^A という入力) 表示されていませんが,それを踏襲する形でいいでしょうか。

いえ…あの GIF は自分でも余り見栄えがしなくて今一つだなと思っていた所なのでした。GUI のソフトウェアを入れてキャプチャするのが面倒だなと思ったので、リモートホストの上で端末から使える saitoha/seq2gif を改造して使って作ったのでした。そうするとフォントも seq2gif に組み込みのものしか使えず、キー入力の表示機能もないのでした。

配色に関しても、もしお使いの環境が黒地に白であればその環境で作って頂ければ幸いです。最近は端末といえば黒地に白文字にまた戻ってきたようで、白地に黒文字だと端末の画面だと認識してもらえないようなので…。また、現在の ble.sh の構文着色は白地前提に調整されたものなので ble-color-setface で適宜配色を変えて頂くと良いのではないかと思います。(私は乱視のせいで黒地だと文字が見えないので、どうにも黒背景の調色ができません…ぎりぎり読める文字の色ということで、全部白か緑か黄色の文字になってしまいます…)

個人的に,特に Vim モードでの特徴を示す為にはどんなキーが押下されているかが表示されている方が良いかなと思うのですが。

もし面倒でなければ、是非そのように (キーの入力も分かるように) お願いしてよいでしょうか。よろしくおねがいいたします。

追記: 実のところそもそも GIF でなくても良いです

Re: 起動時の履歴

再現しませんね…。Bash の version かもと思いましたがそうでもないようです (bash-3.2, 4.0, 4.3, 4.4 確認済み)。もう少し状況を確認させていただいて良いでしょうか。

  • 同じ設定のもとで毎回必ず再現するか?
  • "直後" というのは時間制限か、それとも、最初のキー入力ということか

また、以下を .bashrc (source "$_ble_base/keymap/vi.sh" より後) に記述していただいて実行したとき、再現したときに a.txt にどのような内容が出力されているか確認して頂くことはできますか。あと、history 1 の出力内容 (最後に実行したコマンド) は一応個人情報なので、もし不味いものが含まれていましたら適宜伏せ字にして下さいませ。

function ble/widget/debug {
  echo 0 >> a.txt
  declare -p _ble_edit_history_{loaded,ind,prefix,count} >> a.txt
  local index; ble-edit/history/getindex
  local count; ble-edit/history/getcount
  echo "1:index=$index:count=$count" >> a.txt
  history 1 >> a.txt
  ble/util/assign lastcmd 'history 1'
  echo "2:(lastcmd=$lastcmd)" >> a.txt
  ble/widget/@nomarked backward-line-or-history-prev
  declare -p _ble_edit_history_{loaded,ind,prefix,count} >> a.txt
  echo 3: >> a.txt
}
ble-bind -m vi_imap -f 'C-p' debug

対応ありがとうございます。

再現しませんね…。

うーん。Bash の個人設定を読み込まずに ($ bash --norc) 起動して,
その状態で ble.sh を起動 ($ source path/to/ble.sh) しても再現したのでおかしいですね。

一応 Bash のバージョンは

GNU bash, バージョン 4.4.12(1)-release (x86_64-redhat-linux-gnu)

です。

以下デバッグ結果の a.txt の内容です。

0
declare -- _ble_edit_history_loaded=""
declare -- _ble_edit_history_ind="0"
declare -- _ble_edit_history_prefix=""
declare -- _ble_edit_history_count=""
1:index=0:count=0
3966 rm a.txt
2:(lastcmd= 3966 rm a.txt )
declare -- _ble_edit_history_loaded="1"
declare -- _ble_edit_history_ind="0"
declare -- _ble_edit_history_prefix=""
declare -- _ble_edit_history_count="3966"
3:

また,参考になるか分かりませんが,

$ history $(history | wc -l) | head -1

の結果は起動時に ^P した時に表われる文字列と同一でした。

@cmplstofB 様

Re: 起動時の履歴

試していただいてありがとうございます。

2:(lastcmd= 3966 rm a.txt )

ああ、分かりました。history 1 の形式が違うのですね。実はスペースが先頭に入るのですね。再現もできました。直しました 8a1b8b04e3cc022572a3be950261fcd539121cf8 (手許の環境だと履歴の数が 5 桁なので再現しなかったのでした。履歴の数を減らしたら再現しました)

修正ありがとうございます! 無事直前の履歴が表示されました。

Re: 動画

了解しました。

蛇足も蛇足ですが……

仮想端末の既定の背景色は 180 度というか 360 度転換していたとは知らなかったです。
そういえば昔の GNOME2 の GNOME Terminal のスクリーンショットは,確かに白地に黒でした。
私は寧ろ印刷物のように白い背景に黒い文字というのがすごく苦手なので,
書籍なども色を反転して読んでいたりします。

256d05c7aed6491899b3d4961217d63d004c94ae...3aa7fa6697a46745b0c8fe5e4d0a82a84fc3a652 更新

新機能

  • edit, vi-mode: bracketed paste mode に対応 #D0639

動作修正

  • core: 端末の状態設定・復元とカーソル形状の内部管理 #D0638

    • 外部コマンドを呼び出すときに既定のカーソル形状にする

    • 外部コマンドから戻ったときにカーソル形状を復元する

  • syntax (extract-command): より下の構文階層にいてもコマンドを見つけられるように修正 #D0635
    これによりリダイレクトの単語などの上でも command-help (nmap K, emacs f1) が動くように。
  • syntax (チルダ展開): 変数代入の形式を持つ通常単語内部でのチルダ展開に対応 #D0636
  • syntax: [...] 内部でチルダ展開が起こったとき [...] は意味を失う #D0637
  • vi-mode (cmap <C-w>): imap <C-w> と同様に Vim の動きに変更

バグ修正

  • complete: 補完候補がない時に空文字列で確定するバグの修正 #D0631
  • complete, highlight: failglob 周りのバグの修正 (3) #D0633 #D0634
  • vi-mode: ret グローバル変数が汚染されていたバグの修正 #D0632
  • highlight: 読み取り専用の変数名を入力するとエラーメッセージが出るバグの修正
  • decode: __defchar__ から呼び出された widget が 125 を返したとき
    __default__ から呼び出された widget にキー列が渡されないバグの修正
  • core: set -u にすると全く動かないバグの修正 #D0642
  • edit: ble.sh ロード中に read -e が動かないバグの修正 #D0643

未対応

  • vi-mode: u, C-r, U
  • vi-mode: インデント =
  • vi-mode (xmap): テキストオブジェクトの正しい動作
  • lib/vim-surround.sh: cs ds のインデント
  • complete: 略語展開
  • complete: ブレース展開の中
  • edit: 文法に基づく RET による複数行モード移行
  • highlight: 単語削除に伴って着色範囲が壊れる問題
  • highlight: コマンドに依存した着色 (xargs, sudo なお)

@cmplstofB 様

Re: Vim 等から ^Z で戻ったときのカーソル形状

対応しました 21cf9b187083e99dcddb0b7193615ceec20baa72

カーソル形状の設定方法が以下のように変更になりましたので修正をお願いします。

# 従来の設定例
# bleopt term_vi_nmap="${_ble_term_Ss//@1/2}"
# bleopt term_vi_imap="${_ble_term_Ss//@1/5}"
# bleopt term_vi_omap="${_ble_term_Ss//@1/4}"
# bleopt term_vi_xmap="${_ble_term_Ss//@1/2}"
# bleopt term_vi_cmap="${_ble_term_Ss//@1/0}"

# 新しい設定方法 (例)
bleopt keymap_vi_nmap_cursor=2
bleopt keymap_vi_imap_cursor=5
bleopt keymap_vi_omap_cursor=4
bleopt keymap_vi_xmap_cursor=2
bleopt keymap_vi_cmap_cursor=0

Re: 非挿入モードでの外部貼り付け

対応しました f53be71df81998acac153172b700930a559f71a0

矩形ビジュアルモードにおける貼り付けは矩形挿入として実装してしまったのですが、後で Vim の振る舞いを確認したら矩形挿入ではありませんでした…。しかし、矩形挿入の方が自然に思われるので取り敢えずそのままにしてあります。問題がありましたらお知らせ下さい。


追記

Re: undo

対応しました 47540541484cdb95ba88acecf547345a8d1bd8ba

u で一つ元に戻し、<C-r> で一つやり直します。U は戻ることができるとき全て元に戻し (初期状態に戻す)、それ以外のとき全てやり直します (最新の編集状態にまで進む)。

@cmplstofB さま

動画の方はいかがですか。何かとても素晴らしいものを作ろうと気負ってしまって、却って手が止まってしまって悩まれているのではないかと思って心配しています (ただお忘れになっているか忙しいだけでしたら良いのですが)。色々とキー入力の表示だとか色の調整だとか注文を付けてしまいましたが、そういったものを全て無視して取り敢えずは滅茶苦茶なやっつけ仕事でも (というか何なら静止画でも) 大丈夫ですし、何か迷うことがあればどうぞ何でも相談して下さいませ。少しずつ作って行けば良いので。あるいは、忙しくてなかなか難しそうとか飽きてしまったとかであれば、その旨お知らせ頂ければ幸いです。

@akinomyoga 様。
遅れていて本当に申し訳ないです。もう全然駄目そうです。とりあえず今出せるものを上げます。

demo

言い訳です:
私が ble.sh (特に vim mode) の特徴であり、動作風景に入れようと考えていたのは

  • テキストオブジェクト

    • ci"なお (他 shell ぎ vi/vim mode にない)

    • surround.vim

  • ^o なお正確な vi/Vim の模倣
  • 複数行の編集

    • 矩形選択など

  • 位置に基づく適宜な man

などでしたが、これら全てを入れるのはあまりに冗長だと感じ、また、これらの動作を自然に行うコマンドラインの状況設定が思い付かないので、これほど時間がかかっています。

@cmplstofB さま

ありがとうございます! せかしてしまったようですみません。素晴らしいものに仕上がっているではありませんか。自分で作っていると色々と問題点のようなものは見えてくるものですが、傍から見ると大したことではないことも多いものです。

取り敢えず、いま貼っていただいた GIF の内容で十分インパクトはあります。一点だけ注文をつけてしまって申し訳ないのですが、手頃な大きさの画像で文字も大きめにしたいので、端末の列数を 60 か 50 くらいに減らして(行数もそれに応じて減らして) 同一の操作で GIF 動画を作っていただくことは可能でしょうか。お手数をおかけしてすみません。時間のあるときに作って頂ければ幸いです。また、差し替えはいつでも何度でも承りますので、ご自身で満足なされていない場合でも取り敢えずということで気軽に作って頂ければ幸いです。

などでしたが、これら全てを入れるのはあまりに冗長だと感じ、また、これらの動作を自然に行うコマンドラインの状況設定が思い付かないので、これほど時間がかかっています。

色々と考えてくださってとてもありがたいことです。そうですね。。GIF を操作毎に分けるという考えはいかがですか。一つの GIF にまとめるのは難しそうですし、何より一連の自然な流れを作っても恐らく (字幕などで解説しなければ) 閲覧者に伝えるのは難しそうです。なので、色々の機能を紹介していただけるのであれば、各操作についての短いものを幾つか作って頂いて、見せるときに各画像のタイトルか説明として機能名 (テキストオブジェクト ci" や surround.vim など) をそれぞれ付記する方が確実で宣伝にもなるかなと思います。

あと、すみません…今まで使用目的を書き忘れていたのですが、画像は README.md や Wiki に使わせていただきたいと考えております。また、もし宜しければ Twitter などで ble.sh の紹介のために使わせて頂ければとも考えております。すみませんが、その点を改めてご確認いただけますか (あとそれとは別に、画像を使うときその都度、画像を @cmplstofB さんに作って頂いた旨も書いてよろしいでしょうか)。

了解いたしました。分割というのは思い付きませんでした。そうしようと思います。

作成者表示について

態々言うのも烏滸がましいとは思いますが、動作風景それ自体は WTFPL にするつもり [1] ですので、 @akinomyoga 様のご都合のいいように計らってください。例えばもう全くの匿名でも何でもいいです。

[1] すみません、私がきちんと知らないのが悪いのですが、こういった動画に利用した諸々のツール、フォント、ユーティリティの著作権はその動画自体に影響するのでしょうか。一応、例の動画に利用した一連: ble.sh (BSD), Bash (GPL), screenkey (GPL), FFmpeg (LGPL; WebM と JPEGPNG に関してのみ利用。mp4 等経由せず), GraphicsMagick (MIT; JPEGPNG と GIF に関してのみ利用。その他商用画像形式に依存せず), VL ゴシック (フォント制作を目的としない利用には制約なし), Xfce4 Terminal (GPL) の孰れも非プロプライエタリ・オープンソースなので特に留意すべきことはないとは思っています。しかし、もしも例えば GPL のソフトウェアを利用した動画が GPL になるのなら、WTFPL を取り消さなければいけないので。

作成者表示について

態々言うのも烏滸がましいとは思いますが、

いえ、明示していただいた方が扱いやすいのは事実ですので、態々仰っていただいたほうがよいと思います。

[1] すみません、教えていただきたいのですが、

そういえば、私もよく分かりません…。例えば GPL の場合には、そのソフトウェアを使用して作成された制作物の配布・使用には制限がないということが明示されていますが、他のライセンスに関しては態々そのように述べているかどうかも分かりません。そもそもプログラムの出力に対して権利を主張しだすと殆ど何にも使えなくなってしまうので、態々主張していなければまあ利用して良いと皆解釈しているのではないでしょうか。フォントだけは、そのデザイン自体に意味があるのでソフトウェアのライセンスとはまた性格が異なるとは思います。


追記

しかし、もしも例えば GPL のソフトウェアを利用した動画が GPL になるのなら、

それはないので安心して良いです。この辺りですね:

元々 GPL は 実行可能なコードの動作を修正するまともな手段を確保する ためのものなのでプログラム以外のものには適用されない (しにくい) と考えて良いです。

@cmplstofB 様

いかがでしょうかね。難しく考えていただかなくても大丈夫ですし、進捗がなくても大丈夫なので、気軽に近況を聞かせて頂ければ幸いです (難しそうであればやはり降りて頂くということでも大丈夫なのですが、その際はご一報頂ければ幸いです)。

3aa7fa6697a46745b0c8fe5e4d0a82a84fc3a652...7d365d50eeee80985fab02e909552562715519fb 更新

新機能

  • undo: vi-mode u <C-r> U (#D0644 #D0648); emacs #D0649; #D0662
  • vi-mode (nmap/xmap): f1 で command-help 呼び出し
  • vi-mode (nmap): C-a C-x 対応 (nmap #D0650, xmap #D0661)
  • vi-mode (operator): 各種オペレータ対応 #D0655 (gq, gw #D0652; ! #D0653; g@ #D0654)
  • vi-mode (operator): 追加入力のあるオペレータで作用対象を着色 #D0656
  • vi-mode (registers): registers "[0-9%:-] #D0666 #D0668, :reg #D0665
  • vi-mode (smap): 選択モード #D0672
  • emacs: 主要なコマンドで引数に対応 #D0646
  • emacs: 複数行モードの時にモード名を表示。引数も表示。 #D0683
  • edit: safe keymap
  • edit: 絵文字の文字幅 bleopt emoji_width=2 #D0645
  • core: 誤った PATH に対する対策 #D0651

動作修正

  • vi-mode (nmap/xmap/omap <paste>): 引数を無視するように変更
  • vi-mode (map / ? n N): 検索の一致の仕方を vim と同様のものに変更 #D0658
  • vi-mode (omap): g~? で検索して一致した範囲まで大文字・小文字を切り替えるように変更 #D0659
  • vi-mode (map): 最終行付近で + _ g_ などを呼び出したときの振る舞いを vim と同様のものに変更 #D0663
  • vi-mode (xmap): テキストオブジェクト [ia]['"] ぎ xmap での正しい振る舞い #D0670
  • vi-mode (nmap): Y で行頭に動かないように変更 #D0673
  • vi-mode (xmap): 矩形範囲抽出の効率化 #D0677
  • core: ble.sh ロード時間の改善 #D0675, #D0682, (遅延読込 #D0678 #D0679 #D0680, 裏で履歴読込 #D0681)

バグ修正

  • vi-mode (omap): cw や y? が動かなくなっていたバグの修正
  • vi-mode: マクロで記録される内容に空白が挿入されるバグの修正 #D0667 (テスト追加 #D0669)
  • vi-mode: 行指向の貼り付けが動かなくなっていたバグの修正 #D0674
  • complete: コマンド名によって第一引数の補完が正しく実行されないことがあるバグの修正 #D0664
  • syntax: ヒアストリングで $ret を指定するとエラーメッセージが現れたバグの修正 #D0660
  • syntax: bash-3.0 でコマンドの着色が常にエラーになっていたバグの修正 #D0676
  • decode: ble-decode-unkbd があらゆる文字について ESC を返す様になっていたバグの修正 #D0657
  • Makefile: 削除したファイル isearch.sh が要求されるバグの修正
  • Makefile: 最新の gawk で動かないバグの修正

未対応

  • vi-mode: インデント =
  • vi-mode (xmap): テキストオブジェクトの正しい動作
  • lib/vim-surround.sh: cs ds のインデント
  • complete: 略語展開
  • complete: ブレース展開の中
  • edit: 文法に基づく RET による複数行モード移行
  • highlight: 単語削除に伴って着色範囲が壊れる問題
  • highlight: コマンドに依存した着色 (xargs, sudo なお)

@cmplstofB 様、幾つか対応を延期していたものに対応しました。

Re: ヒアドキュメント出来ない?

「文法的に不完全な場合 RET または C-m で改行を挿入する」動作を実装しました #D0684 029704c6a42ddf6dbcb06f6714d60a293257278a

Re: 存在するパスを示すシンタクスハイライトが特定条件下で崩れる

修正しました #D0687 e39977152bc2c4d63e5ff79e6f7e4a99b76c8721

これは単語着色の枠組みの根本的な問題により対応が難しいというようなことをご説明しましたが、今回調べてみた所、単純なバグだったので修正しました (枠組みの問題は依然として存在していますが、この振る舞いとは関係のないものでした)。

@cmplstofB 様

未だ残っているものも幾つかありますが、取り敢えずこれで support-vi-mode ブランチをマージします。様々なテストに長らくお付き合い頂きまして、また様々な提案をして頂きまして、本当にありがたく思っております。今後も、何かあれば気楽に Issue/PR を立てていただくか Twitter で話しかけて頂ければ幸いに思います。残っている項目については、今後気が向いた時に実装させて頂く予定です。

Commit ID: 9e68058
Version of GNU bash: 4.4.12
OS: Debian GNU/Linux 9.5 x86_64
もしも@akinomyoga様側で再現しない場合,私の環境に問題があるということでしょう。それほど複雑な設定はしていないので,そちらで再現しない,ということはあまりないと思います。しかし,もしも再現しない場合は,面倒を掛けますが,ちょっと設定などを確認していただけるとありがたいです。私の設定ファイルはここにあります。

ほとんどのコマンドで,第二引数を補完しようとすると端末を巻き込んで落ちる。

e.g. cat ~/@
↑ここでTab⭾を押下すると,端末ごと終了してしまう。(註: @はカーソルの位置)

構文強調の設定が効かない。

ble.shの設定ファイル内で,ble-color-setfaceを用いて構文強調の装飾を設定している(これはもともとのbleshrcの設定をほぼ丸写ししている為構文自体には間違いはないと思います)のですが,反映されない。だたし同じファイルにおけるその他の設定は有効になっているので,ファイル自身は読み込まれble.shが解釈している筈。
また,新規対話シェルを立ち上げた際,最初の入力時に,

ble.sh: the specified face `XXX' is not defined.

という警告(もしくはエラー)表示が出力される。

すみません。今は少し忙しいので対応できないですが (すみません、対応は今日の夜中か明日の午後になるかと思います)、前者については再現できていません。Fedora ですが 4.4.12, 4.4.19, 4.4.23 の何れでも再現できませんでした。

  • 端末ごと終了するというのは、端末がクラッシュする形でしょうか。それともシェルがクラッシュする形でしょうか。例えば、シェルが立ち上がった状態で bash として入れ子でシェルを立ち上げて試して頂けるとどちらか判別できます。
  • また、シェルが立ち上がった時 (bashrc 読み込み直前) のロケール (LANG 環境変数) と、inputrc における convert-meta の設定も確認していただけますか。シェル起動時のロケールを ja_JP.UTF-8 として、また convert-meta off にした時にも再現するかどうか、もし可能であれば確かめていただきたく思います。

後者については問題があるようであるということが分かりましたので、後で修正いたします。

@akinomyoga 様
お忙しい中もうしわけないです。

Re:「端末ごと終了」の意味

ちょっとよく分からない状態です。bashを入れ子で起動すると($ bash --rcfile ~/.profile),第二引数も通常通り補完できました。つまり,問題ないということです。
ホームディレクトリにはBashが読み込みうるファイルとしては~/.profileしかないので,bashは上記のように起動しているはずです。うーん。これは明かに〝おま環〟ですねぇ……。また,(少なくとも)cd(1)コマンドに関しては引数の補完が可能です。不思議すぎます。ちょっと仮想環境かなにかで精査してみます。当面は,起動後もう一度bashを呼び出すことで対処します。
$LANG環境変数およびinputrcにおけるconvert-metaの設定は,元々ja_JP.UTF-8,offでした。

確認ありがとうございます! うーん。不思議ですね…。他の確認事項です:

  • 他の端末 (ターミナル) を使っても再現するでしょうか。或いは、現在のターミナルは何でしょうか
  • 2回起動すると治るということだとやはり環境変数の違いが怪しいです。.bash_profile と .bashrc の「先頭」で環境変数を出力して (env > file.tmp もしくは export > file.tmp)、最初の Bash と入れ子の Bash で diff を取って見ていただけないでしょうか。何か怪しそうなものがあったら、(セキュリティー・プライバシー的に) 差し支えない範囲で情報提供頂けると幸いです。(先程は 「.bashrc 読み込み直前」と書きましたが、ターミナルを最初に起動した時は .bash_profile が使われるのでそちらでもチェックしなければなりませんでした…。)
  • enhance-complete ブランチの先端でも同様に再現するでしょうか。
  • 過去の版では問題は発生しなかったということでよろしいでしょうか (もし、過去の版で問題が発生しなかったということであれば、大変面倒な最終手段になりますが、二分法 (なお) でおぎ commit で問題が発生する様になったかということを特定することもできます)。

今から ble-color-setface の方は直していこうと思います。

あと、上記確認事項に書きました enhance-complete の方は Makefile に問題がありましたので、今新しく commit を追加しました。そちらの方を使っていただけると幸いです。確認事項に関しては小出しにして頂いて構いません。二分法は最終手段なので未だ試していただかなくて問題ありません

あと、この issue は取り敢えず vim mode として公開に至ったこと、また、読み込みが重くなってしまったことから、新しく個別の Issue として問題点を報告していただけると良うございます。どんどん Issue を作っていただいて問題ありません。或いは、今までの形式が良いということでしたら、色々報告する新しい Issue を一つ作っていただいても構いません。お好みでお選びくださればよいですが、この Issue は今の所 reopen する予定はないので、その点はご留意くださいませ。

Re: 構文強調の設定が効かない。

  • 856c85f 一つ問題を修正しました。多分直っていると思うのですが確認していただけますか。よろしくお願いいたします。

@akinomyoga 様

構文強調の設定について

856c85fにおいて修正されているのを確認しました。ありがとうございます。

Re: 端末の種類

現在,端末エミュレータとしてXfce4 Terminal (v0.8.3)を使っています。
また,rxvt-unicode 256color (v9.22)では再現しました。それ以外の端末エミュレータ(例えばGNOME TerminalやXterm)については,Xfce4 Terminalがlibvteに依存した端末エミュレータの一種であること,rxvt-unicodeがXterm系列であることから,必要性は低いと勝手に判断しました。起動して当該する操作を行うだけの確認なので,もしこれらで足りなければまた追加して実験することはできます。

Re: 環境変数の違い

とりあえず,diffした結果をほぼそのまま載せます。見辛いと思います,すいません。

diff結果($diff /tmp/{1,2}.env)

1a2,3
> LD_LIBRARY_PATH=/opt/intel/compilers_and_libraries_2018.3.222/linux/compiler/lib/intel64:/opt/intel/compilers_and_libraries_2018.3.222/linux/compiler/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.3.222/linux/mpi/intel64/lib:/opt/intel/compilers_and_libraries_2018.3.222/linux/mpi/mic/lib:/opt/intel/compilers_and_libraries_2018.3.222/linux/ipp/lib/intel64:/opt/intel/compilers_and_libraries_2018.3.222/linux/compiler/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.3.222/linux/tbb/lib/intel64/gcc4.7:/opt/intel/compilers_and_libraries_2018.3.222/linux/tbb/lib/intel64/gcc4.7:/opt/intel/debugger_2018/iga/lib:/opt/intel/debugger_2018/libipt/intel64/lib:/opt/intel/compilers_and_libraries_2018.3.222/linux/daal/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.3.222/linux/daal/../tbb/lib/intel64_lin/gcc4.4
> XDG_CONFIG_HOME=/home/ry/etc
3c5,6
< LANG=ja_JP.utf8
---
> LANG=ja_JP.UTF-8
> LESS=--no-init --force --quit-if-one-screen --hilite-search --ignore-case --LONG-PROMPT --line-numbers --QUIET --raw-control-chars --tilde
4a8,10
> IPPROOT=/opt/intel/compilers_and_libraries_2018.3.222/linux/ipp
> EDITOR=vim
> GDB_CROSS=/opt/intel/debugger_2018/gdb/intel64/bin/gdb-ia
5a12,13
> GDBSERVER_MIC=/opt/intel/debugger_2018/gdb/targets/intel64/x200/bin/gdbserver
> MPM_LAUNCHER=/opt/intel/debugger_2018/mpm/mic/bin/start_mpm.sh
7a16,18
> CR=
> INTEL_PYTHONHOME=/opt/intel/debugger_2018/python/intel64/
> CLASSPATH=/opt/intel/compilers_and_libraries_2018.3.222/linux/mpi/intel64/lib/mpi.jar:/opt/intel/compilers_and_libraries_2018.3.222/linux/daal/lib/daal.jar
12a24
> PAGER=less
18a31
> CPATH=/opt/intel/compilers_and_libraries_2018.3.222/linux/ipp/include:/opt/intel/compilers_and_libraries_2018.3.222/linux/mkl/include:/opt/intel/compilers_and_libraries_2018.3.222/linux/pstl/include:/opt/intel/compilers_and_libraries_2018.3.222/linux/tbb/include:/opt/intel/compilers_and_libraries_2018.3.222/linux/tbb/include:/opt/intel/compilers_and_libraries_2018.3.222/linux/daal/include
20a34,35
> VIMINIT=let $MYVIMRC = expand($XDG_CONFIG_HOME) . "/vim/init.vim" | source $MYVIMRC
> NLSPATH=/opt/intel/compilers_and_libraries_2018.3.222/linux/compiler/lib/intel64/locale/%l_%t/%N:/opt/intel/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64_lin/locale/%l_%t/%N:/opt/intel/debugger_2018/gdb/intel64/share/locale/%l_%t/%N
21a37,39
> LIBRARY_PATH=/opt/intel/compilers_and_libraries_2018.3.222/linux/ipp/lib/intel64:/opt/intel/compilers_and_libraries_2018.3.222/linux/compiler/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.3.222/linux/tbb/lib/intel64/gcc4.7:/opt/intel/compilers_and_libraries_2018.3.222/linux/tbb/lib/intel64/gcc4.7:/opt/intel/compilers_and_libraries_2018.3.222/linux/daal/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.3.222/linux/daal/../tbb/lib/intel64_lin/gcc4.4
> DAALROOT=/opt/intel/compilers_and_libraries_2018.3.222/linux/daal
> INTEL_LICENSE_FILE=/opt/intel/compilers_and_libraries_2018.3.222/linux/licenses:/opt/intel/licenses:/home/ry/intel/licenses
23a42
> VISUAL=vim
29a49
> LS_OPTIONS=--color=always --group-directories-first --indicator-style=classify --show-control-chars
33a54
> MANPATH=/opt/intel/man/common:/opt/intel/compilers_and_libraries_2018.3.222/linux/mpi/man:/opt/intel/documentation_2018/ja/debugger//gdb-ia/man/:/opt/intel/documentation_2018/ja/debugger//gdb-igfx/man/:/usr/local/man:/usr/local/share/man:/usr/share/man:
34a56
> MANOPT=--default --all --wildcard
35a58
> XDG_CACHE_HOME=/home/ry/var/cache
39a63,65
> MKLROOT=/opt/intel/compilers_and_libraries_2018.3.222/linux/mkl
> XDG_DATA_HOME=/home/ry/share
> PSTLROOT=/opt/intel/compilers_and_libraries_2018.3.222/linux/pstl
42c68,72
< PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
---
> PATH=/home/ry/.cargo/bin:/opt/intel/compilers_and_libraries_2018.3.222/linux/bin/intel64:/opt/intel/compilers_and_libraries_2018.3.222/linux/mpi/intel64/bin:/home/ry/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
> TBBROOT=/opt/intel/compilers_and_libraries_2018.3.222/linux/tbb
> PKG_CONFIG_PATH=/opt/intel/compilers_and_libraries_2018.3.222/linux/mkl/bin/pkgconfig
> INFOPATH=/opt/intel/documentation_2018/ja/debugger//gdb-ia/info/:/opt/intel/documentation_2018/ja/debugger//gdb-igfx/info/
> I_MPI_ROOT=/opt/intel/compilers_and_libraries_2018.3.222/linux/mpi
43a74
> LF=

Re: 過去の版では問題なかったのか

過去の版(少なくとも18cd661)では問題はなかったということを伝えておきます。
しかしながら,実を言うと,補完すると端末が落ちるという問題は,過去の版でも,もう少し特殊な条件で発生していました(すいません,これは条件が特殊なため,一体全体どの版で発生した問題なのか・あるいは始めから存在していた不具合なのか不明です)。それは,以下のようなコマンドラインで

$ find . | xargs echo @

@の位置で*補完キーを押下すると落ちるというものです。少なくとも18cd661,しかし恐らくそれ以前から発生していました。

Re: enhance-completeブランチ

相変らずですね……。やはり不明な落ち方で強制終了してしまいます。
(僕が行ったブランチ切り替えの方法が誤っているかもしれませんので,念のため: ワークツリーの最上階にて$ git checkout enhance-complete && make installを実行しました)

* 以後@は特別に断らない限りカーソルの位置を示すものとします。より見易い・判別しやすい表記法などありましたら教えていただけると助かります

申し訳ないです。

新しく個別の Issue として問題点を報告していただけると良うございます

を読み飛ばしておりました。別issueに移行します。つきましては,どういった内容のissueを立てればよろしいでしょうか(質問ばかりですね……)。「初回起動セッションにおいて引数の補完が失敗する」などといった題名がいいでしょうか。

ありがとうございます。様子を見ると端末が落ちているという訳ではなさそうですね… (確証はないですが)。

別issueに移行します。つきましては,どういった内容のissueを立てればよろしいでしょうか(質問ばかりですね……)。「初回起動セッションにおいて引数の補完が失敗する」などといった題名がいいでしょうか。

ありがとうございます。それならば作っていただくことにしましょう。上でコメントいただいた内容に対する返答は新しい Issue に書かせていただきますね。内容・題名については気になさらなくても大丈夫です。

  • 実は題名も本体も後から編集できるので、最初は分かっている範囲で書いていただければ良いです。題名は内容が他の Issue と判別できれば良いので、ご提示いただいたものでOKです。例えば、問題の厳密な発生条件が分かった後で、気になれば題名を変えるという形で良いです。
  • 内容については今までコメント下さったような形式で大丈夫です。
  • 今回の場合は、既にこちらでいくらか議論が進みましたので、こちらの最初のコメントへのリンク https://github.com/akinomyoga/ble.sh/issues/2#issuecomment-418600724 を貼っていただけると良いと思います。こちらで新しく分かったことに関しては、今回は改めて内容に書く必要はありません。もし書きたい場合はできるだけ簡潔に。
Was this page helpful?
0 / 5 - 0 ratings