「すべて検索」の不具合?仕様?

  1. (例文)

    ああ
    
    あかかかあ
    

    **
    この例文に対して、

    1. 以下の条件で「すべて検索」を実行する。
    - 検索文字列:あ
    - 検索条件:何でもよい。

    2. 検索実行時にマルチカーソルが有効化されて、以下のような選択状態(下線)とカーソル位置(|)になる。

    (検索直後の状態)

    ああ|   ←二文字選択&行末にカーソル
     ̄ ̄
    |あかかか|あ ←それぞれ一文字選択&文字の前にカーソル
      ̄     ̄
    

    3.「い」を入力する。

    (「い」を入力した後の状態)

    い|   ←一文字に置き換わる&行末にカーソル
     ̄
    い|かかかい| ←それぞれ置き換わる&文字末にカーソル
     ̄     ̄
    

    (注)文字選択及びカーソル位置を明示するため、下線文字と縦線文字を加えている点に留意ください。

    **
    2.の段階において、検索文字列が連続したとき、自動(?)で「範囲選択」にされるのは仕様でしょうか?

    P.S.
    文字列指定を二重引用符から一重引用符に替える際、空文字列(””)に対しての挙動で気が付きました。

     |  noname  |  返信
  2. ご報告ありがとうございます。

    マルチカーソルの仕様として、隣り合った選択範囲は自動的に結合される仕様にしているのですが、確かにご指摘のシーンにおいてこの仕様は良くないですね。

    少し調べてみましたところ、マルチカーソルに対応している有名どころのエディターですと、Adobe Brackets は Mery と同じく隣り合った選択範囲は結合される仕様ですが、Microsoft Visual Studio Code は隣り合った選択範囲は分離されたままという仕様でした。

    [すべて検索] などの機能を考えると Visual Studio Code の仕様のほうが良さそうですね。

    この仕様変更はちょっと大掛かりになりそうですが、何か対策を考えてみたいと思います。

     |  Kuro  |  返信
  3. 横から失礼します。

    ああ
    あああああ
    ああ
    あいあ
    あいあいあいあ
    あいあ

    ➀ このような3行の文書で1行目の「ああ」または「あいあ」を範囲選択した状態から [Ctrl+D] の連打で「選択範囲に次の候補を追加」をすると、2行目の途中「ああああ」または「あいあいあ」までが選択されたところで1行目の「ああ」「あいあ」の選択状態は解除されます。
    検索ダイアログ内の [>] ボタンのオプションは関係ないようなので、マルチ選択のマージと Mery の検索メソッドにおける再検索開始位置の仕様(「あああああ」にたいして「ああ」で検索すると4回、「あいあいあ」にたいして「あいあ」が2回ヒットする)の折り合いがよくないようです。 :(
    (私も「検索ヒット数表示(選択文字列) 」マクロの仕様を決めるときに悩んで、結局は再検索開始のオフセット指定用の変数を設けたりしました)

    ➁ 上の例文でそれぞれ1行目を選択した状態から「すべて検索して選択(Shift+Ctrl+A)」または検索ダイアログの「すべて検索」コマンドを実行すると、それぞれ3行目まで検索/選択が働きますが、2行目で1文字ずつ取りこぼします。
    (これは「置換」や「マーカー」機能での検索方法と同じパターンだとおもいますが)

    個人的には ➁ のパターンは好きですが、通常の「次/前を検索」や「次/前の文字列を検索」、「自動マーカー」の動作パターンとは解釈がことなるので違和感を感じる人がいるかも? という気がしますし、
    ➀ のばあいのような「選択範囲に追加」を繰りかえす操作が途切れてしまうのは…。

    既存の「検索」「マーカー」系の機能との折り合いや、マルチ選択を利用した簡便な置換操作やテキスト再編集操作の目的で「選択範囲に次の候補を追加」や「すべて検索(して選択)」を使用するばあいを考えると非常に悩ましいところだとおもいますが、トピ主さんの事例とあわせてご確認・ご検討ください。

     |  sukemaru  |  返信
  4. はい、noname さんがご指摘くださっているとおり、これらは隣り合った選択範囲を自動的に結合する仕様によるものです。

    隣り合った選択範囲を結合しない仕様に変更する方向で検討していますので、今しばらくお待ちくださいませ。

     |  Kuro  |  返信
  5. これはあまり考慮する必用ないかもしれない操作ですが…

    ➂ 前レスのひとつめの例文で最初の2行にたいして末尾改行をふくめずに矩形選択(i.e. 「ああ」「ああ」)した状態から「選択範囲に次の候補を追加」や「すべて検索」をすると、

    「選択範囲に次の候補を追加」:
    - 1回目の操作では、一見するとなにも起きてないが、「ああ」と「ああ」のマルチ選択状態になっている。
    - もういちど実行すると、「ああ」「あああ」が選択されて3行全体に検索ハイライトがかかる。
    - さらにもういちど実行すると、1行目の「ああ」と2行目の「ああああ」が選択されて、「あああああ」だけに検索ハイライトがかかる。
    - ...

    「すべて検索(して選択)」:
    もとの矩形選択部分は解除されて、2行目末尾の「ああ」+ \n と、3行目の「ああ」+ \n とがストリーム選択状態になる。
    ※ 改行をふくむためか、検索ハイライトなし。

    ➃ マルチ選択で1行目「ああ」、2行目「ああ」を選択した状態から「選択範囲に次の候補を追加」や「すべて検索」をすると…。

    ----
    あと、トピックの表題案件とはべつで… (これもどうでもいいことですが)
    これまでは範囲選択しているとアクティブ行の水平罫線が表示されない仕様でしたが、マルチカーソルで選択範囲(Ctrl+ドラッグ)とゼロ幅選択(Ctrl+クリック)とを組み合わせると、ゼロ幅でキャレットだけ置いた行には水平罫線が(複数)表示されて選択範囲のある行の仮想キャレット位置にはされなくて、見たかんじの統一感がような…。

     |  sukemaru  |  返信
  6. [選択範囲に次の候補を追加] は最後に選択した箇所の文字列を基準に次の文字列を検索しにいくので、そういう動作になります。

    これは隣り合った選択範囲を結合しない仕様に変更することで改善されると思います。

    > これまでは範囲選択しているとアクティブ行の水平罫線が表示されない仕様でしたが、マルチカーソルで選択範囲(Ctrl+ドラッグ)とゼロ幅選択(Ctrl+クリック)とを組み合わせると、ゼロ幅でキャレットだけ置いた行には水平罫線が(複数)表示されて選択範囲のある行の仮想キャレット位置にはされなくて、見たかんじの統一感がような…。

    複数選択のときも通常選択の場合と同様で、選択範囲がある場合は水平罫線を非表示とし、選択範囲がない場合は水平罫線が表示される仕様はそのままです。

    ちなみにマルチカーソル搭載の Sublime Text もこの仕様です。

    複数選択のときは常に水平罫線不要、というご意見でしたら描画速度が高速化できるので大歓迎です (w 反対派もいると思いますが…

     |  Kuro  |  返信
  7. ご返信ありがとうございます。
    マルチ選択や矩形選択の使い方をおぼえるべく色々いじっていますが、まだまだ慣れていないため、掴みきれないところが多くて難し~。 XD
    マクロをいじりなおすどころじゃないような有様ですが、マクロにかんしては kuro さんのコード(まだ解読できてないのですが…)がありますから、無理して短期間で慣れる必要もない気がしてきたり…。

    > これは隣り合った選択範囲を結合しない仕様に変更することで改善されると思います。
    基本的にこれでいろいろと改善しそうですけれど、置換の「すべて置換」や「マーカー」のような検索パターンでということでしたら、もしかすると検索ハイライトと不一致になる部分が残ってしまうかもしれないですね。

    さいきんはすっかりご無沙汰しちゃってますが、サクラ、g、npp は再検索開始位置が選択範囲末尾だったとおもうので乗り換えや併用の人には Mery の「検索」パターンはややこしそう(再検索開始位置を指定するスイッチでもあるとよいのかもしれませんが)。 XD

    > 複数選択のときも通常選択の場合と同様で、選択範囲がある場合は水平罫線を非表示とし、選択範囲がない場合は水平罫線が表示される仕様はそのままです。
    > 複数選択のときは常に水平罫線不要、というご意見でしたら描画速度が高速化できるので大歓迎です (w 反対派もいると思いますが…
    いままでの水平罫線の仕様からすると、やはり現在の状態のままというのが無難そうですよね。 :)
    マルチカーソルのゼロ幅キャレットをポンポン置いたときに「あれ?」とおもっただけのことでして、むしろいままでの仕様(ストリーム)でも範囲選択すると水平罫線が非表示になっていたことにはじめて気が付いたという…。 LOL

     |  sukemaru  |  返信
  8. > さいきんはすっかりご無沙汰しちゃってますが、サクラ、g、npp は再検索開始位置が選択範囲末尾だったとおもうので乗り換えや併用の人には Mery の「検索」パターンはややこしそう(再検索開始位置を指定するスイッチでもあるとよいのかもしれませんが)。 XD

    残念ながら、取りこぼしや検索と検索ハイライトが不一致となるパターンは Mery に限らずどのエディターでも発生してしまいます。

    ちなみにサク〇さんはおっしゃるとおりの仕様ですが、Notepad++ は [次を検索] はサク〇さん方式、[前を検索] は Mery 方式というハイブリッド (というか統一されていない?) な感じですね。

    以下の記事にていくつかのエディターの検索と検索ハイライトの精度や取りこぼし状況を調べた結果を掲載していますのでご参考にどうぞ。
    https://www.haijin-boys.com/software/mery/mery-2-2-2

    どのエディターでもそれぞれの設計思想に基づいた仕様となっていると思いますから、好みの仕様のエディターを選択されるのがよろしいかと思います。

    > いままでの水平罫線の仕様からすると、やはり現在の状態のままというのが無難そうですよね。 :)

    そうですね。この方式にはひとつメリットがあって、複数選択状態と通常選択状態を見分けやすいんです。

    マルチカーソルだと、複数のカーソルが設置されていることを忘れて編集してしまうということが起きやすそうですからね。

    オプションで [選択範囲 (複数選択)] の項目から複数選択のときの選択範囲の色を変更できるようになっているので通常選択か複数選択かを見分けやすくはできるのですが、カーソルのみ (ゼロ幅選択) が複数あるときは、水平罫線が複数になるので見分けやすいというわけです。

     |  Kuro  |  返信
スポンサーリンク