zeero

This may help you https://developpaper.com/ios-implements-transverse-waterfall-flow-based-on-uicollectionview/

コメントありがとうございます。 > 一応, vim-operator-furround で実現できます. - furroundでインプット待ちの対応をしていたのですね。yankしてからという操作が不便に思っていたので、やりたかったことはほぼ実現できているように思います。 - ただ逆にいうとsurroundのオプションを増やすことでsurroundでもできるようになるのであれば、操作を統一できるというメリットがあるのではないでしょうか？ - 使い分けたい人と操作を統一したい人、それぞれの選択を阻害する理由はないように思います。 > `a` を使って `hoge()` を入力する設定をしている場合に、`hage()` を入力できないので中途半端な機能にならないでしょうか. - `a`といった短い単語でキー設定している場合、そういった事象は起こりうると思います。その場合にはおすすめできるものではないですが、それは極端なケースだと思います。 - 専用特化することと汎用性をもたせることは時に相反するものだと思います。ブロックキーの設定をデフォルト状態で使っている人には有効であるし、オプションでユーザが選択できるようになっているのであれば、十分に機能すると思います。

> 「それ」はどれを指していますか？ > そして「それは極稀」というのはどこで得た情報ですか？ 「稀」なんて書いていません。 「それ」＝「`a`といった短い単語でキー設定している場合」＝「極端なケース」と表現したまでです。 > ブロックキーの設定を使っている人も使えるようになればより良いのではないですか? -> パッチ改善の余地 > ブロックキー設定を使っている人は使うべきではないという方針ですか？ -> ドキュメント改善の余地 どちらかというと後者に近いですが、極端に短いブロックキー設定をしている場合にこの設定との相性は悪い、というレベルと思います。 「相性が悪い」といった情報をドキュメントに書くべきかどうか含めて@rhysdさんに判断してもらうのがよいのではないでしょうか。 > > 操作を統一できるというメリットがあるのではないでしょうか？ こちらについてはどのような意見でしょうか？

回答ありがとうございます。前向きに検討頂けてすごく嬉しいです。 > `keeps_input_if_no_block` この変数名は分かりにくいと思います． `uses_input_if_no_block` にあわせてみたのですが、仰る通りと思います。私の意見としては `enable_xbrackets_mode`の方がわかりやすいかと思います。ファンクションに使い方を限定していない（ブロックキーであればなんでも同様に働く）ので`enable_function_call_mode`だと語弊がありそうです。 同様にプロンプトも`block (xbrackets):`とするのがよいと思います。 コードレビュー頂いた中で一つ認識齟齬がありそうです。 ドキュメント中の`non-zero` → `zero`の部分ですが、ここは`non-zero`が正しいです。オプションを有効（`non-zero`）にした場合に`uses_input_if_no_block` を無視するようになります。 > > a を使って hoge() を入力する設定をしている場合に、hage() を入力できない すみません、言及箇所は私もよくわかっていません。 意味としてはブロックキーに`a`、ブロックに`["hoge(", ")"]`と登録していて、このオプションを有効にした場合、`hage(`と入力しようとすると`ha`の時点でブロックキーに該当することになり、`hhoge()`で囲まれてしまうということかと思います。

いったんコードレビューの指摘とオプション名の変更に対応しました。ドキュメントについてはもう少し書きっぷりを変える必要がある認識ですが取り急ぎ。 > o`perator-surround-append` を使わずに `operator-furround-append` を使えば良いだけだと思います `operator-surround`のPRの話をしているのに`operator-surround`を使わなければよいというのは如何なものかと思います。 > で、極端なんでしょうか。 > 設定可能な最小文字数で短縮登録するのであれば極端であると思います。 > デフォルトで有効になっている`uses_input_if_no_block`も意味を為さなくなる使い方ではないでしょうか。（再三出ている例の場合、`a`で囲むことができなくなる。） > > 例えば、xbrackes-mode の入力待ちなら、デフォルトのカッコしか使わないとかになってくれると嬉しいかも。 その場合せっかく設定できるブロックキー設定が意味を為さなくなるのではないでしょうか。オプションはコロコロと切り替えるようなものでもないと思いますので。

> @syngan さんがある程度納得できる案で摺り寄せて，僕なり @zeero さんが実装修正して最終的に取り込む感じでいきたいです． わかりました。以下の案ではどうでしょうか？ - xbracketsの文字部分とブロックを二段階で入力させる - はじめのプロンプトで文字を入力させる - Enterで次のプロンプトに移り、ブロックを入力させる ただ、デフォルト設定のままの人には現在の実装が最適だと思います。 なので、モードを複数用意する方式（`let g:operator#surround#xbrackets_mode = 2`のような）にするのはどうでしょうか。

返事遅くなっていてすみません。 極端かどうかについては@rhysdさんと同意見です。 > ところで、この機能っていつ使われるか @zeero　さんはイメージされていますか？ > furround 作っておいてあれですが、あとから関数で囲いたいと思うケースってかなり稀（かつ同じ関数であることが多い）だと思っています。 初めに書いた通り、特にVimScriptを書いているときに便利だと思っています。私の場合はすでに手放せないレベルです。 JavaやRubyなどの他の言語の場合はメソッドチェーンでつなぐことができるので処理の順番と記述の順番を一致することができるので特に必要に感じません。 VimScriptの場合は逆なのでこの機能が無いと書きづらく思います。あまり特定の関数に偏ることもなく、頻繁に使用しています。 そう考えると、`b:`変数での設定を優先的に見るようにできることが有効だったりしますか？ `autocmd FileType vim let b:enable_xbrackets_mode = 1` のイメージですが。

> 仮に mode=3 として別の案を.　furround と同じ動作になるのですが > 改行を入力の区切りにする。入力の末尾で、定義されているものにマッチするもの以外を補完する。 上記を`mode = 2`として実装する、でいいのではないかと思います。 私の`mode = 2`は代替案として提示して@synganさんの同意も得られなかったので取り下げます。