検索、置換で改行を含む文章が選択できません
-
改行を含む文章を選択した状態で検索（置換）をしようとすると、検索文字列に前回検索した文字列が表示されたままで、検索したい文章が表示されません。検索文字列は「選択テキスト」にしています。
手動で￥ｎを入力し1行ずつ繋いで実行すれば行えますが、解決策はございますでしょうか。
お忙しいところ申し訳ありませんが、宜しくお願いします。win10 64bit、ver3.3.9 64bit
| ksk | 返信 -
改行を含む文字列の検索には対応していないため、[選択テキスト] が指定されている場合、選択範囲に改行が含まれていない場合は選択したテキスト、改行が含まれている場合は前回検索したテキストが渡される仕様となっています。
> 手動で￥ｎを入力し1行ずつ繋いで実行すれば行えますが、解決策はございますでしょうか。
そうですね。一応、改行を「\n」として入力し、[正規表現を使用する] をオンにすれば改行を含む文字列の検索もできますから、やるとしたら、改行を含む文章が選択されている場合は、[選択テキスト] は改行を「\n」に置き換え、[正規表現を使用する] をオンにする、とここまでを自動でセットするようにすれば便利かもしれないですね。検討してみたいと思います。
| Kuro | 返信 -
実際に作って検討してみたのですが、[正規表現を使用する] まで自動でオンにされてしまうと煩わしいときもありそうでした。
とりあえず、改行を「\n」に置き換えるところだけ実装するか検討してみます。
| Kuro | 返信 -
ご回答、ご検討ありがとうございます。
正規表現のオンオフも設定などで選べると助かりますが、改行だけでも大変便利になるのでありがたく存じます。
「\n」置き換えの実装を心待ちにしております。| ksk | 返信 -
いつから Kuro 様がご実装下さったのかわからないのですが…、
検索ダイアログを、正規表現を使用する がチェックされていない状態にして閉じます。
改行を含む、複数行を選択して、
次の文字列を検索 Shift+Ctrl+↓
前の文字列を検索 Shift+Ctrl+↑のいずれかを使うと、複数行の検索ができ、「検索する文字列」には
文字幅ゼロの改行を含んだ複数行の内容が入ります。
(改行文字の位置ではカーソルが一度止まります)これとは別に従来から、次のマクロをショートカットに割り当てると、
複数行を選択して実行すると「検索する文字列」に入れて検索ができました。選択行検索.js
document.selection.Find(document.selection.Text, meFindNext | meFindReplaceCase);なお、どちらも検索文字列の強調(ハイライト)は、最初の改行の手前までだけとなります。
> 改行を「\n」に置き換えるところだけ実装…
正規表現を使用する
改行を「\n」に置き換えるの方法だと「.」 や「()」など正規表現メタ文字の無効化のために、少々細工が必要です。
Windows 10 Pro 21H2 64bit 19044.2075
Mery (x64) Version 3.3.9
Oniguruma 6.9.8| inuuik | 返信 -
ご連絡ありがとうございます。
うわぁ、これは想定外でした。Mery は改行をいくつでもまたげてしまうというのが仕様上のネックだったもので、他のエディターのように改行をまたげないように制限をかけていたのですが、そんな落とし穴が…。
> 「検索する文字列」には文字幅ゼロの改行を含んだ複数行の内容が入ります。
これは想定外の操作なので、そのまま [すべて置換] をしてしまうとデータが破壊されてしまいますね。どうか、お気を付けくださいませ。
> .」 や「()」など正規表現メタ文字の無効化のために、少々細工が必要です。
そうですよね。[正規表現を使用する] まで自動でチェックされると問題がありそうなので、そこはナシの方向で検討しています。
しかし、Mery の仕様的にはそもそも改行をまたいで検索できるので、その仕様をあえて潰すよりは [検索する文字列] に文字幅ゼロの改行を含んだ複数行の内容がはいってもそのまま検索できる仕様にしたほうが面白いかもしれないですね。
うーむ…。
| Kuro | 返信 -
ご返信おそれいります。
やややっ、そうでしたか。便利に使っていました。
> これは想定外の操作なので、そのまま [すべて置換] をしてしまうとデータが破壊…
ほとんどは検索だったので無事でした。気をつけます。
> [検索する文字列] に文字幅ゼロの改行を含んだ複数行の内容がはいってもそのまま検索できる仕様にしたほうが面白いかも…
はいっ、ぜひともお願いいたします。
えーとたしか…、
「Mery 羊の名と穏やかな姿をもつモンスター エディタ」
のモットーは「見えないところにこそ気合の高機能を！」じゃありませんでしたっけ？(笑)「すべて検索」でマルチカーソルにも応用できそうですね。
> … [正規表現を使用する] まで自動でチェックされると問題がありそうなので…
「ナシの方向」に賛成です。
なのですが、一時的な正規表現の無効化は、他の場面にも役立つので、ご検討いただくため
細工の具体的な内容をご案内します。手数はほとんどかかりません。--------------------------------------------------------------------------------
正規表現メタ文字の無効化のために、\Q \E を使います。doc/RE.ja
補記 3. Perl 5.8.0と比較して存在しない機能
…
* \Q...\E
但しONIG_SYNTAX_PERLとONIG_SYNTAX_JAVAでは有効--------------------------------------------------------------------------------
perldoc\Q quote (disable) pattern metacharacters till \E or
end of string
\E end either case modification or quoted section【使い方】
\Q から \E または正規表現文字列の終わりまで、メタ文字が無効化される
↓
改行文字だけを有効にする細工は…正規表現文字列の先頭に \Q を追加
すべての改行文字 \n を \E\n\Q に置換↓
一時的に正規表現文字列そのものを検索するには…正規表現文字列の先頭に \Q を追加
--------------------------------------------------------------------------------
ライブラリのビルド前にそれぞれ１か所を変更して、
この \Q...\E をデフォルトでも有効にする
--------------------------------------------------------------------------------
【onigmo 6.2.0】regparse.c
const OnigSyntaxType OnigSyntaxRuby = { (( SYN_GNU_REGEX_OP | ONIG_SYN_OP_QMARK_NON_GREEDY | ONIG_SYN_OP_ESC_OCTAL3 | ONIG_SYN_OP_ESC_X_HEX2 | ONIG_SYN_OP_ESC_X_BRACE_HEX8 | ONIG_SYN_OP_ESC_CONTROL_CHARS | ONIG_SYN_OP_ESC_C_CONTROL ) & ~ONIG_SYN_OP_ESC_LTGT_WORD_BEGIN_END ) , ( ONIG_SYN_OP2_QMARK_GROUP_EFFECT | ※↓この 1 行を変更※ , ( ONIG_SYN_OP2_ESC_CAPITAL_Q_QUOTE | ONIG_SYN_OP2_QMARK_GROUP_EFFECT |【oniguruma 6.9.8】
regparse.c
OnigSyntaxType OnigSyntaxOniguruma = { (( SYN_GNU_REGEX_OP | ONIG_SYN_OP_QMARK_NON_GREEDY | ONIG_SYN_OP_ESC_OCTAL3 | ONIG_SYN_OP_ESC_X_HEX2 | ONIG_SYN_OP_ESC_X_BRACE_HEX8 | ONIG_SYN_OP_ESC_O_BRACE_OCTAL | ONIG_SYN_OP_ESC_CONTROL_CHARS | ONIG_SYN_OP_ESC_C_CONTROL ) & ~ONIG_SYN_OP_ESC_LTGT_WORD_BEGIN_END ) , ( ONIG_SYN_OP2_QMARK_GROUP_EFFECT | ※↓この 1 行を変更※ , ( ONIG_SYN_OP2_ESC_CAPITAL_Q_QUOTE | ONIG_SYN_OP2_QMARK_GROUP_EFFECT |--------------------------------------------------------------------------------
この機能を１０年使っていますが、副作用などで困ったことはなく、お勧めです。
| inuuik | 返信 -
ご返信ありがとうございます。
> 「Mery 羊の名と穏やかな姿をもつモンスター エディタ」のモットーは「見えないところにこそ気合の高機能を！」じゃありませんでしたっけ？(笑)
モットーはそうなのですが、キャッチコピーは「メモ帳に毛が生えた程度のエディター」ですねw
> [検索する文字列] に文字幅ゼロの改行を含んだ複数行の内容がはいってもそのまま検索できる仕様にしたほうが面白いかも…
上記の仕様について検討してみましたが、いくつか問題があって制限付きではありますが以下のような仕様なら実装できそうではあります。
(1) Ctrl + Shift + ↓ or ↑ で改行を含む文字列を検索できるのは現状維持
(2) 検索ダイアログの [検索する文字列] に文字幅ゼロの改行を含んだ文字列が入るのも現状維持
(3) テキストを選択した状態で検索ダイアログを開いたときに [選択テキスト] として渡す文字列の改行は \n に置き換えるのではなく、(2) の仕様どおり、文字幅ゼロの改行で渡す
(4) 上記、3 つのケースにおいて [すべて置換] を正常動作するように改善する
…と、ここまでは行けそうな部分です。
以下は仕様上、対応が難しい部分です。
・INI ファイルの仕様上、改行文字 (0x10) を含んだ文字列は扱えないため、[検索する文字列] や検索履歴に改行文字が含まれていると復元できない
その対策として次の 4 つを考えてみましたがいずれも一長一短です。
------------------------
(1) [検索する文字列] に改行文字 (0x10) が含まれている場合は検索履歴に追加しない→ シンプル。
(2) [検索する文字列] が検索履歴に追加される時点で改行文字 (0x10) を "\n" に置き換えてから追加する
→ 次に検索するときは正規表現で検索してもらう必要があります。
(3) 検索履歴の改行文字 (0x10) は維持しつつ、検索履歴を INI ファイルに保存するときに改行文字 (0x10) を "\n" に置き換える
→ Mery を起動中は検索履歴から改行文字 (0x10) を含む文字列を呼び出せますが、Mery を終了して次回起動したときは履歴の改行文字 (0x10) は "\n" に置き換わって (2) の状態になります。
(4) INI ファイルに保存するときに改行文字 (0x10) を含む文字列を別の形式にエンコードしてから保存、復元する
→ 改行を含む文字を保存、復元できますが、INI ファイルの下位互換性が失われます。
------------------------と、こんな感じで頭を抱えているところです。
> ライブラリのビルド前にそれぞれ１か所を変更して、この \Q...\E をデフォルトでも有効にする
情報ありがとうございます。こちらでもビルドして試してみましたが、なるほど、これは面白いですね。
\t とか \n など、ちょっと正規表現を使いたいだけなのに、他の部分がメタ文字に引っかかっちゃうかも？と、毎回、エスケープが必要な文字をググってるものですから、部分的に正規表現を無効にできる機能は便利そうです。
検討してみますね。
| Kuro | 返信 -
いろいろとご思案いただき、誠にありがとうございます。
プリミティブな仕様について、このように考える機会があるなんて、実に楽しいです。
> (1) Ctrl + Shift + ↓ or ↑ で改行を含む文字列を検索できるのは現状維持
>
> (2) 検索ダイアログの [検索する文字列] に文字幅ゼロの改行を含んだ文字列が入るのも現状維持
>
> (3) テキストを選択した状態で検索ダイアログを開いたときに [選択テキスト] として渡す文字列の改行は \n に置き換えるのではなく、(2) の仕様どおり、文字幅ゼロの改行で渡す
>
> (4) 上記、3 つのケースにおいて [すべて置換] を正常動作するように改善する
>
> …と、ここまでは行けそうな部分です。上記は、自然な操作感を保てるので、とても良いのでは…と思います。
それと、選択範囲をなくして置換ダイアログを開けば、置換は問題なく動作しました。
改行コードが CR+LF と LF と CR のそれぞれでの動作もテストしないと、ですね。
また、改行コードが LF 以外では、文字幅ゼロの改行はクリップボードとダイアログ内では扱えますが、
エディタの編集領域では必ず変換されてしまうので、扱うのにひと手間いります。ClipboardData.SetData("\x0a");
これを「クリップボードのLFコード」とかの名前でマクロ化してショートカットにしておけば、
一旦ダイアログの外でカーソルをクリックしてマクロ起動、ダイアログに戻って Ctrl+V で
目的のところにゼロ幅改行を挿入できます。「ファイルから検索」でも複数行検索は動作しました。
これについては、検索結果のタブに、本来の「無題-…」という名ではなく、検索文字列が表示されるので、ゼロ幅改行文字のままでは表示が乱れます。何かの策があったほうがよさそう。「次を検索」でも「前を検索」でも一致がなくなるとステータスにメッセージと共に検索文字列が表示されますが、これは文字列リテラルのエスケープがされて、\ は \\ に、改行文字は \n に、タブ文字は \t として表示されます。
上記のタブの表記もこのエスケープをした上で文字数を長さで切るなどはどうでしょうか。さて…、課題ですが、
> … [検索する文字列] や検索履歴に改行文字が含まれていると復元できない
INI の読み出しではキー単位で、キーの = 直後から改行直前まで、となっていますね。
一方、書き込みでは、セクション内の順読みも想定されているのか、キーの = 直後から
改行を含めて書き込まれています。ただし、消去との不整合があるようで、キーの間にある行は更新とともに、どんどん
消去されない最終行が増殖してガーブル(ゴミ)の蓄積となっています。
今回の仕様変更で、もし可能なら、改行以降の書き込みを抑止するような対策が
できればよいのかもしれません。すでに溜まってしまっているものは、INI を手動で編集して除去するか、何かスクリプト
を作って [Search] セクション内の掃除をすることになりますね。以下で改行文字は LF なので 0x0A (10) だろうと読み替えてます。
ご質問主は、複数行を「自然な操作で…」検索・置換したい、とのご希望だと思うので、
正規表現との使い分けを常用するというよりは、文字列選択からの検索の操作にできる
だけ近いもので、機能を実現するのがよさそうに思います。> (1) [検索する文字列] に改行文字 (0x10) が含まれている場合は検索履歴に追加しない
>
> → シンプル。起動からの連続した編集過程で、複数行だとまったく検索履歴が使えないのは、さすがに不便だと思います。
> (2) [検索する文字列] が検索履歴に追加される時点で改行文字 (0x10) を "\n" に置き換えてから追加する
>
> → 次に検索するときは正規表現で検索してもらう必要があります。メタ文字無効の話も関連しますが、その上で、頻繁に正規表現とそうでない検索を☑で切り替えるのは煩雑です。「自然な操作」から離れてしまうように思います。
それに履歴の一覧から \n に置き換えているものを見分けるのも簡単ではなさそうですし。>
> (3) 検索履歴の改行文字 (0x10) は維持しつつ、検索履歴を INI ファイルに保存するときに改行文字 (0x10) を "\n" に置き換える
>
> → Mery を起動中は検索履歴から改行文字 (0x10) を含む文字列を呼び出せますが、Mery を終了して次回起動したときは履歴の改行文字 (0x10) は "\n" に置き換わって (2) の状態になります。上記と同様ですが、起動してしてから今までの検索履歴と、前回以前の履歴が混在するので、さらに正規表現の切り替えが増えてしまいそうです。
> (4) INI ファイルに保存するときに改行文字 (0x10) を含む文字列を別の形式にエンコードしてから保存、復元する
>
> → 改行を含む文字を保存、復元できますが、INI ファイルの下位互換性が失われます。互換性を保ったうえで、改行文字を「文字列リテラルのエスケープ」で保存するのはいかがでしょうか。
エスケープの対象は、
\ 0x5c \\ ←※優先または同時の置換(二重回避)※
LF 0x0a \n
HT 0x09 \t
の３つだけでよいと思います。たとえば、
// revised inuuik 2022-08-25 doMultiActionA
// revised inuuik 2022-08-26 \行置換しないという２行を、行末改行まで含んで選択して検索、同じ内容で置換した場合は…、
FindText=
FindList0=
FindList1=
…
は従来との互換性を保ち、
複数行の時だけ
FindText#=
FindList0#=
に文字列エスケープして保存読み出しのときは、# 付きのキーを先に見て、内容が空なら、従来のキーを読む、という流れ…
例:
FindText=// revised inuuik 2022-08-25 doMultiActionA
FindText#=// revised inuuik 2022-08-25\tdoMultiActionA\nrevised inuuik 2022-08-26\t\\行置換しない\n
FindList0=// revised inuuik 2022-08-25 doMultiActionA
FindList0#=// revised inuuik 2022-08-25\tdoMultiActionA\nrevised inuuik 2022-08-26\t\\行置換しない\n
FindList1=// revised inuuik 2022-08-25 doMultiActionA
FindList1#=
…
ReplaceText=// revised inuuik 2022-08-25 doMultiActionA
ReplaceText#=// revised inuuik 2022-08-25\tdoMultiActionA\nrevised inuuik 2022-08-26\t\\行置換しない\n
ReplaceList0=// revised inuuik 2022-08-25 doMultiActionA
ReplaceList0#=// revised inuuik 2022-08-25\tdoMultiActionA\nrevised inuuik 2022-08-26\t\\行置換しない\n
ReplaceList1=// revised inuuik 2022-08-25 doMultiActionA
ReplaceList1#=
…キーの数が増えますが、複数行の時だけ内容を記録すれば、文字数が倍になることはなく、読み出しの処理に判定が追加されるものの、起動時と終了時の処理なので、編集中の負荷は少ないのではと…。
…というわけで (4)改 をご提案したいのですが、いかがでしょうか。
それから…、
> … 毛が生えた程度羊さんの毛は素晴らしく尊いですw
| inuuik | 返信 -
ご返信ありがとうございます。
> 羊さんの毛は素晴らしく尊いですw
私の毛根と等価交換ですがw
> それと、選択範囲をなくして置換ダイアログを開けば、置換は問題なく動作しました。
[置換] ボタンで順番に置換していく場合は問題ありませんが、正規表現オフで [すべて置換] はテキストが破壊されるケースがあります。
というのも、正規表現オフで [すべて置換] は検索文字列に改行文字が混入しない前提で、高速化のために行単位で置換しているからです。
> ダイアログに戻って Ctrl+V で目的のところにゼロ幅改行を挿入できます。
今回の件ではダイアログに手動で改行文字を入力する、といったことまでは想定していないものですから、そこにツッコミがはいると厳しそうですね。
本格的に改行文字を検索で扱えるようにするには、[正規表現を使用する] とは別に [エスケープシーケンスを使用する] という項目を設けて、\n などのエスケープシーケンスに対応していく必要があると思います。
> 以下で改行文字は LF なので 0x0A (10) だろうと読み替えてます。
すみません、0x0A でしたね。つい、Delphi (#10) のノリで書いてしまいました、お恥ずかしい (*ﾉωﾉ)
> ご質問主は、複数行を「自然な操作で…」検索・置換したい、とのご希望だと思うので、正規表現との使い分けを常用するというよりは、文字列選択からの検索の操作にできるだけ近いもので、機能を実現するのがよさそうに思います。
そうですよね。[エスケープシーケンスを使用する] みたいな項目を設けて、エスケープシーケンスとは、などと説明してまで使ってもらうよりは、現状の操作感でそのまま使えるほうが良さそうですね。
Mery としても、改行をまたいで検索したいときは秀〇エディタさんやサク〇エディタさんみたいに「正規表現を使ってね」というかたちで良いと思っています。
> 上記のタブの表記もこのエスケープをした上で文字数を長さで切るなどはどうでしょうか。
改行文字をそのまま扱えるようにしてしまうと、そういった問題も出てくるのですね。他にも影響のある箇所が出てきそうな気がしてきました…。
> 今回の仕様変更で、もし可能なら、改行以降の書き込みを抑止するような対策ができればよいのかもしれません。
INI ファイルの仕様をハックすればできなくはないと思いますが、(4) のエンコード案を採用すればそこは解決しそうですね。
> (1) [検索する文字列] に改行文字 (0x10) が含まれている場合は検索履歴に追加しない
> 起動からの連続した編集過程で、複数行だとまったく検索履歴が使えないのは、さすがに不便だと思います。もともと複数行検索に対応するつもりはなく、改行文字が混入した場合にデータの破損さえ防げれば良いかなと考えていたものですから、検索履歴については重要視しておらず、(1) は開発工数を優先した案となっています。
> (2) (3)
> メタ文字無効の話も関連しますが、その上で、頻繁に正規表現とそうでない検索を☑で切り替えるのは煩雑です。(2)、(3) も複数行検索はイレギュラー対応というのが前提となっており、(1) よりは手間がかかるけどある程度、利便性も考慮した中間の案といった感じです。
> …というわけで (4)改 をご提案したいのですが、いかがでしょうか。
きちんと実装するなら (4) ですね。
私も (4) の方向は想定しており、その中でも 4 パターンぐらい案を考えていたのですが、書いてたら長文になってしまったので、(4) の方向なら改めて検討を。ということで前回は割愛させていただきました。
> 読み出しのときは、# 付きのキーを先に見て、内容が空なら、従来のキーを読む、という流れ…
互換性を完全に維持するにはその方法がベストですね。
ただ、[検索する文字列] と [置換後の文字列] の履歴を合わせると 64 (+2) 個ものキーを増設することになるのが気になるところではあります。
いただいたご提案を参考にさせていただき、私のほうでも改めて検討してみたいと思います。
| Kuro | 返信 -
ご返信、ご解説ありがとうございます。
> [置換] ボタンで順番に置換していく場合は問題ありませんが、正規表現オフで [すべて置換] はテキストが破壊されるケースがあります。
今は危ないですね、[NUL] の花が乱れ咲きます。やってしまったらすぐに Ctrl+Z で「元に戻す」です。
> というのも、正規表現オフで [すべて置換] は検索文字列に改行文字が混入しない前提で、高速化のために行単位で置換しているからです。
改行文字を許容するには、複数行の行単位での置換への改造…、などが必要なわけですね、大変、、、。
> 今回の件ではダイアログに手動で改行文字を入力する、といったことまでは想定していないものですから、そこにツッコミがはいると厳しそうですね。
>
> 本格的に改行文字を検索で扱えるようにするには、[正規表現を使用する] とは別に [エスケープシーケンスを使用する] という項目を設けて、\n などのエスケープシーケンスに対応していく必要があると思います。それほどではなくても…、
検索ダイアログでは、検索する文字列の右の > クリックで表示／選択できる所を応用して、選択テキストまたはカーソル位置の単語
…
固定値の下に、正規表現を使用する の時の表示内容
固定値
------
^ 行頭
$ 行末
------
…の代わりに、
固定値
------
改行
タブの２項目を追加し、それぞれ 0x0A と 0x09 を挿入するのが使い易いように思います。
置換後の文字列の右の > は「正規表現を使用する」ではない時には、上記と同じ
改行
タブを表示／選択できるようにするといい感じです。
少し話が脇にそれます…。
今回は「正規表現を使用する」ではない場合に注目していますが、
改行文字(0xA)などは、エスケープしないでも、正規表現の文字列の中で使用できます。
正規表現ライブラリのパーサーでは、エスケープ文字は内部コードに置き換えています。2018年に 8 番目として [BS] \b (0x08) を追加していただいたので、
\n \x0A
\t \x09
\r \x0D
\f \x0C [FF]
\a \x07 [BEL]
\b \x08 [BS]
\e \x1B [ESC]
\v \x0B [VT]
は「検索する文字列」「置換後の文字列」で使えます。どちらもエスケープ表記は「正規表現を使用する」の時だけですが、
直接の文字、内部コードそのものなら、普通文字列でも正規表現文字列でも使えます。…ということは、複数行選択で検索・置換ダイアログに入力できるようになれば、
「正規表現を使用する」でも貼り付けを経由しないで文字列を取り込めて、
とりあえずは、そのまますぐに検索・置換できる、ことになり、手間が省けます。
必要な所は、後からゼロ幅改行文字をエスケープに書き換えればよいわけです。> > ご質問主は、複数行を「自然な操作で…」検索・置換したい、とのご希望だと思うので、正規表現との使い分けを常用するというよりは、文字列選択からの検索の操作にできるだけ近いもので、機能を実現するのがよさそうに思います。
>
> そうですよね。[エスケープシーケンスを使用する] みたいな項目を設けて、エスケープシーケンスとは、などと説明してまで使ってもらうよりは、現状の操作感でそのまま使えるほうが良さそうですね。はいっ、そう思います。
> Mery としても、改行をまたいで検索したいときは秀〇エディタさんやサク〇エディタさんみたいに「正規表現を使ってね」というかたちで良いと思っています。
秀〇エディタさんは、「複数行検索」で検索ダイアログの文字列が拡大する仕様に…、
これはあまりに力技だと思いますので、ここには追従しないほうが、、、w> 改行文字をそのまま扱えるようにしてしまうと、そういった問題も出てくるのですね。他にも影響のある箇所が出てきそうな気がしてきました…。
タブ名の場所の文字列は、長くなったり改行で戻ったりするものの、領域からはみ出すなど表示が破綻してはいないので、放置でもいいかもしれませんw
完璧にとらわれると、なかなか一歩先に進めないので…> INI ファイルの仕様をハックすればできなくはないと思いますが、(4) のエンコード案を採用すればそこは解決しそうですね。
これは動作に実害はないので、放置でもいいと思います。INI が肥大したときの掃除で考慮すれば十分かも。
> …データの破損さえ防げれば良いかなと考えていたものですから、検索履歴については重要視しておらず、(1) は開発工数を優先した案…
> (2)、(3) も複数行検索はイレギュラー対応というのが前提となっており、(1) よりは手間がかかるけどある程度、利便性も考慮した中間の案…ご説明ありがとうございます、了解です。
> 私も (4) の方向は想定しており、その中でも 4 パターンぐらい案を考えていたのですが、書いてたら長文になってしまったので、(4) の方向なら改めて検討を。ということで前回は割愛させていただきました。
そうでしたか。すっかり出しゃばってしまい、失礼しました。
> ただ、[検索する文字列] と [置換後の文字列] の履歴を合わせると 64 (+2) 個ものキーを増設することになるのが気になるところではあります。
たしかに 32(+1) x 2 = 66 個のキーは少なくない…。
使わないときはキー自体を省ければ、とも思いますが、履歴が「複数行」で埋まってしまえば同じですね。
従来版からの INI を読む時にはそのキーが存在しないので、省く処理に無駄はないですが…。> いただいたご提案を参考にさせていただき、私のほうでも改めて検討してみたいと思います。
この機能は地味ながら深い魅力が感じられますもので、どうぞよろしくお願いいたします。
| inuuik | 返信 -
ご返信ありがとうございます。
> の２項目を追加し、それぞれ 0x0A と 0x09 を挿入するのが使い易いように思います。
これは私も考えたのですが、タブ文字は置いといて、改行文字のほうは入力できても視認できないものですから、UI としてはあまりよろしくないかなと思いました。
メニューに表示するよりは、見えないところに置いといて知ってる人だけ使える感じのほうが良いかなと。(例えば Ctrl + Tab でタブ入力、Ctrl + Enter で改行文字入力とかw)
> 秀〇エディタさんは、「複数行検索」で検索ダイアログの文字列が拡大する仕様に…、これはあまりに力技だと思いますので、ここには追従しないほうが、、、w
ほんとですね、改行を含む文字列を貼り付けた瞬間にビヨン！と入力欄が拡大しました。これは「すっご」と声に出してしまいましたw
E〇Editor さんも秀〇エディタさんに追従するかたちなのかどうかは分かりませんが、[複数行] というメニュー項目を選択すると秀〇エディタさんみたいに入力欄が拡大する方式を採用されているようです。
そんなに改行をまたいで検索したい需要ある？と心の声を漏らしつつ、みなさんがっつり作りこまれてて、Mery は心が折れそうです。
> 使わないときはキー自体を省ければ、とも思いますが、履歴が「複数行」で埋まってしまえば同じですね。
確かにそうですね。最大で 66 個というだけで、キーを省けばそんな負荷にもならなさそうでした。
それも踏まえて、前回、書こうとした (4) 案の詳細、エンコード方式のパターンを 4 つ、ダメな順に紹介させていただきますと…
(第4位) Base64 や URL エンコードで保存、復元する
→ 互換性が完全に失われてしまう(第3位) \ は \\ に、改行文字は \n にエスケープして保存、復元する
→ 正規表現を使う人の場合、互換性がそこそこ失われてしまう(第2位) % は %% に、改行文字は %n にエスケープして保存、復元する
→ あまり使われない文字に変換することで互換性をある程度維持できそう(第1位) 改行文字を 0x07 に変換して保存、復元する
→ ほとんど使われない文字に変換することで互換性が失われるリスクは低そうといった感じでした。
また、inuuik さんの (4) 改の案は互換性という点ではベストだと思いました。
それらを踏まえて改めて検討してみました。
まず、INI ファイルの互換性という点において、前提から覆してしまうことになりますが、検索履歴ってすぐに消えていくものですし、現在、ベータ版ということもあるので、互換性が微妙に失われるけどゴメンネ、テヘペロ… (と、更新履歴に記載するなど) で乗り切れるんじゃないかなと。
これを前提に、inuuik さんのエスケープ案、私の案では (第3位) の案になりますが、\ は \\ に、改行文字は \n にエスケープして「キーを新たに設けずに」現状のキーに上書きで保存、復元する案が最善なのではないかと考えています。
一部のユーザーさんにおいては、正規表現で検索した履歴として \n という文字列が含まれている可能性があり、これは互換性としては 0x0A に変換されて復元されてしまいます。
その点については、inuuik さんからいただいた情報をもとに、
> 改行文字(0xA)などは、エスケープしないでも、正規表現の文字列の中で使用できます。
↑ これの対象となるので、\n が 0x0A として復元されたとしても、ある程度の互換性は維持できているのではないかなと…。(\\ は \ として復元されてしまうので、そこはご愛敬w)
また、新たにキーを設けず、現状のキーに上書きすることのメリットとして、マクロ (ReadSettingString) から検索履歴にアクセスするときに扱いやすいという点が挙げられます。
改行を含むキーとそれ以外のキーで分離してしまうと、マクロ側でその解析処理が必要になりますからね。
と、こんな感じで検討していますがいかがでしょうか。
| Kuro | 返信 -
> また、新たにキーを設けず、現状のキーに上書きすることのメリットとして、マクロ (ReadSettingString) から検索履歴にアクセスするときに扱いやすいという点が挙げられます。
検索履歴の INI、リアルタイムで更新されるわけじゃないのでマクロからアクセスしてもあんまり意味なかったー。
| Kuro | 返信 -
ご返信ありがとうございます。
> > の２項目を追加し、それぞれ 0x0A と 0x09 を挿入するのが使い易いように思います。
>
> これは私も考えたのですが、タブ文字は置いといて、改行文字のほうは入力できても視認できないものですから、UI としてはあまりよろしくないかなと思いました。
>
> メニューに表示するよりは、見えないところに置いといて知ってる人だけ使える感じのほうが良いかなと。(例えば Ctrl + Tab でタブ入力、Ctrl + Enter で改行文字入力とかw)これは…、うーん、視認できないから明示してある方が良いな、と思ったのでした。
ショートカットキーだと押したかどうだかも不確かで結果も見えない、かなぁと…。やはりお勧めは > への追加です。
複数行の検索は、改行から始まって改行まで、の行検索を正規表現 ^ $ \n 等を使わずに
できる場合もあるし、置換では改行の位置変更や行の分割をする、という
「あまり慣れてない人」の使い方も想定されるように感じます。覚えて使う、よりは、開いたら書いてある、操作が好ましいように思いました。
こういう機能もありますが、画面を見ただけだとわからないので、あまり知られていない
はずです（告知のない Alt + C はさらに…）。これと似たことになりそうな気がします。検索する文字列
履歴ドロップダウンが開いている状態のみ
Alt + Del 検索履歴の全削除
Alt + C 検索履歴の全コピー置換後の文字列
履歴ドロップダウンが開いている状態のみ
Alt + Del 置換履歴の全削除
Alt + C 置換履歴の全コピーちなみに Ctrl + Tab は、ダイアログの外で、よく使われる機能「次の文書」が
割り当ててあるのでさらに混乱するかも、と心配だったりします。> そんなに改行をまたいで検索したい需要ある？と心の声を漏らしつつ、みなさんがっつり作りこまれてて、Mery は心が折れそうです。
見るからに力任せなので…、どうぞ競おうとはしないで下さいませw
そもそも、ここにご質問をいただいた時点で、需要の盛り上がりかも、と受け止めるべき
だったのかも知れませんが、、、> まず、INI ファイルの互換性という点において、前提から覆してしまうことになりますが、検索履歴ってすぐに消えていくものですし、現在、ベータ版ということもあるので、互換性が微妙に失われるけどゴメンネ、テヘペロ… (と、更新履歴に記載するなど) で乗り切れるんじゃないかなと。
ぐふっ「ベータ版」！
またまた伝家の宝刀を抜きますのか－！> これを前提に、inuuik さんのエスケープ案、私の案では (第3位) の案になりますが、\ は \\ に、改行文字は \n にエスケープして「キーを新たに設けずに」現状のキーに上書きで保存、復元する案が最善なのではないかと考えています。
>
> 一部のユーザーさんにおいては、正規表現で検索した履歴として \n という文字列が含まれている可能性があり、これは互換性としては 0x0A に変換されて復元されてしまいます。
>
> その点については、inuuik さんからいただいた情報をもとに、
>
> > 改行文字(0xA)などは、エスケープしないでも、正規表現の文字列の中で使用できます。
>
> ↑ これの対象となるので、\n が 0x0A として復元されたとしても、ある程度の互換性は維持できているのではないかなと…。(\\ は \ として復元されてしまうので、そこはご愛敬w)…まさかこういう展開が待つとは。
長い正規表現はどこかに取ってあるのだろうと思うので、検索履歴が流れても…、
なのですが、
わたくし、ガチめの「正規表現を使う人」なので…、
\n はまあいいとしても、
\\ は \ として復元されてしまう、のは心情的に(笑)…ツライですね。というわけで、気合を入れて、Kuro さん案で互換性を保つ方法を考えました。
--------------------
複数行検索・複数行置換に対応した Mery.ini の仕様変更案【概要】
[Search]
…
FindMultiline=0[Search]
…
FindMultiline=1新設キー FindMultiline により対象 66 個のキー値の読み書き動作を切換
FindMultiline=0 なら従来通り
FindMultiline=1 なら複数行に対応した文字列エスケープ(\\, \n)【対象キー】
合計 66 個 (既存)[Search]
FindText=
FindList0=
～
FindList31=
ReplaceText=
ReplaceList0=
～
ReplaceList31=【動作】
INI の読み込み時に…
FindMultiline=1
が存在したら、以下の文字列エスケープを復元して読み込み
\\ → \
\n → LF (0x0A)FindMutiline=0
が存在したら、復元せずにそのまま読み込みFindMultiline=
キーが存在しなかったら、復元せずにそのまま読み込み ※重要: 従来版読み込み※
内部のキー値を
FindMultiline=1
として設定 ※重要: 互換性を保って新仕様をデフォルトで有効にする※INI の書き込み時に…
FindMultiline=1
が存在したら、以下の文字列エスケープをして書き込み
\ → \\
LF (0x0A) → \nFindMultiline=0
が存在したら、そのまま書き込み
--------------------このようにすれば、キー新設は 1 個だけで、互換性を保った上で、
従来通りと新仕様を選べる仕組みになります。
いかがでしょうか。さらなるご検討をお願いいたします。> 検索履歴の INI、リアルタイムで更新されるわけじゃないのでマクロからアクセスしてもあんまり意味なかったー。
なるほど。起動時に履歴の収集をする場合ぐらい、かもですね。
[追記]
ご質問主には失礼をお詫びします。申し訳ありません。
別のテーマを混ぜるのはダメなのはわかっているのですが、たぶんこの流れで更新の機会を
下さると思うので、次の２点のご検討事項を便乗させて下さいませ。Markdown プレビュー なのですが、折角作って下さったのでお蔵入りにしないで、
「縦書き」機能の公開もどうかよろしくお願いします。タイプライタースクロール なのですが、固定位置を、あとほんの少し上下に動かせると、
さらにとても快適になるのですが、以前に没となった自由な行位置指定ではなく、
現在の位置の設定から少しだけの行差分を調整する機能は、むずかしいでしょうか。
（せめて１行だけでも）これができれば、物書きさんの「感覚的な」位置に関する要望はほぼすべて叶えられ
そうに思います。タイプライタースクロール
位置 中間行差 －２行
－１行
なし
＋１行
＋２行お手数ですが、どうぞよろしくお願いいたします。
| inuuik | 返信 -
ご返信ありがとうございます。
> これは…、うーん、視認できないから明示してある方が良いな、と思ったのでした。
なるほど、これについては平行線になりそうですね。ひとまず保留ということで、将来的に実装する際にはご意見を参考にさせていただきたいと思います。
> ぐふっ「ベータ版」！
> またまた伝家の宝刀を抜きますのか－！そのためのベータ版ですからねw
> \\ は \ として復元されてしまう、のは心情的に(笑)…ツライですね。
確かに、正規表現を多用してるかたにはご迷惑をおかけすることになりそうですね。
> というわけで、気合を入れて、Kuro さん案で互換性を保つ方法を考えました。
ご提案ありがとうございます。そこまで互換性を重要視されてるとは思っていなかったもので、互換性は微妙に失われるけど、なるべくシンプルで負荷の少ない案ということで提案させていただきました。
> このようにすれば、キー新設は 1 個だけで、互換性を保った上で、従来通りと新仕様を選べる仕組みになります。
これだと上位互換性はありますが、下位互換性は失われてしまいますよね。アップグレードは大丈夫だけど、ダウングレードだと互換性が失われる感じ？
↑ 私の解釈があってるか分かりませんが、そういう方向で良ければまた別の案がありますので、その場合は再度、改めてご提案させていただきたいと思います。
> Markdown プレビュー なのですが、折角作って下さったのでお蔵入りにしないで、「縦書き」機能の公開もどうかよろしくお願いします。
ツイッターでつぶやいた機能ですね。反応があれば実装しようと思っていたのですが、予想以上に反応なくて…。今はもう削除しちゃってますね、すみません。
そもそも Markdown プレビュー自体、多くの人は使わなさそう、といった手ごたえで Markdown プレビューごとお蔵入りしてますね… ^^;
> タイプライタースクロール
これは Zen モードとあわせてご利用されている場合は、Alt キーを押しながらエディターの端をドラッグすることでエディター画面の位置自体をずらすことができるので、見やすい位置に中央部分を持ってこられると思います。
また、その他のご利用方法でこういった使い方の場合だよ！といったご意見があれば、具体的な状況を書いていただけると開発の参考にさせていただきますので、お手数をおかけしますが別のトピックで詳細を添えてご投稿いただければと思います。
| Kuro | 返信 -
ご回答ありがとうございます。
> なるほど、これについては平行線になりそうですね。ひとまず保留ということで、将来的に実装する際にはご意見を参考にさせていただきたいと思います。
はい、ありがとうございます。
> 確かに、正規表現を多用してるかたにはご迷惑をおかけすることになりそうですね。
> そこまで互換性を重要視されてるとは思っていなかったもので、互換性は微妙に失われるけど、なるべくシンプルで負荷の少ない案ということで提案させていただきました。
いや「心情的に…」なので、迷惑というほどではございません。重要視というか…、
正規表現では \\ を多用しているのですが、これを書くのも読むのも目がチカチカして気疲れ
するもので、履歴を読み直して \ と見分けるのは大変かな～と… ^^;> これだと上位互換性はありますが、下位互換性は失われてしまいますよね。アップグレードは大丈夫だけど、ダウングレードだと互換性が失われる感じ？
片方向のつもりではありませんでした。
そうですよね、どっちもイケルつもりだったのですが、ネジが抜けていたようで、
考えたときに、実行中に画面で設定を変更できないことをすっかり忘れていました。ということで…、マクロで設定すれば回避できるのではと、、、
【複数行検索解除.js】
editor.WriteSettingInteger("Search", "FindMultiline", 0);
editor.ReadSettings();この２行マクロを登録して実行してから、Mery を終了すれば、
従来通りの文字列エスケープしていない検索履歴の INI に戻せるはず…なので、
前バージョンでも使えるのではないかと思いますが、これではダメでしょうか。INI の書き込みの時点でこのキー内容が判定に反映できないとむずかしいですね。
まあ、これでできなければ、検索履歴文字列を、他バージョンや他エディタで
直接に Mery.ini から編集すればいいのですけど。これにそれほどの手間をかけるぐらいなら、Kuro さん案でエイヤッとした方が
よほどシンプルですね。内部機能で複数行検索・置換が安定すれば、表現方法はあとからモリモリ実装
できるわけで、「ビヨン！」への挑戦もきっと…w> ツイッターでつぶやいた機能ですね。反応があれば実装しようと思っていたのですが、予想以上に反応なくて…。今はもう削除しちゃってますね、すみません。
>
> そもそも Markdown プレビュー自体、多くの人は使わなさそう、といった手ごたえで Markdown プレビューごとお蔵入りしてますね… ^^;なんと、そうでしたか…、それは惜しいことをしました。キビキビ動くので気に入っています。
青空文庫形式のルビをよく使うのですが、プラグインをいろいろ試行錯誤していたので、
ぜひ縦書きでも、とずっと思っていたのでした。
遅くてすみません、作って下さってありがとうございました。> これは Zen モードとあわせてご利用されている場合は、Alt キーを押しながらエディターの端をドラッグすることでエディター画面の位置自体をずらすことができるので、見やすい位置に中央部分を持ってこられると思います。
ありがとうございます。Zen モード（よそ見排除モード）の全体位置をずらす方法は以前に
発言を拝見していました。
これはタイプライタースクロールの基本設定について以前から気にかかっていたことだった
ので、便乗してしまいました。
集中できる画面の場所には微妙な個人差があって、フォーカスモードにまでしなくても、
そこを調整すると使い勝手がさらに上がる…かも、という理由が主でした。
これはここで終わりにします。お手間をいただきまして恐縮です。| inuuik | 返信 -
寒くなりましたね、ご返信ありがとうございます。
> INI の書き込みの時点でこのキー内容が判定に反映できないとむずかしいですね。
なるほど、確かに、このトピックを読んでくれてるユーザーさんじゃないと知りようがない裏技的な位置づけになってしまいそうな気がしますね。
> 青空文庫形式のルビをよく使うのですが、プラグインをいろいろ試行錯誤していたので、ぜひ縦書きでも、とずっと思っていたのでした。
そうでしたか。縦書き機能は削除してしまいましたが、Markdown プラグインのほうは、また機会があればどこかのタイミングでリリースできるよう検討してみたいと思います。
> 集中できる画面の場所には微妙な個人差があって、フォーカスモードにまでしなくても、そこを調整すると使い勝手がさらに上がる…かも、という理由が主でした。
視線移動をなるべく少なくするというのがタイプライタースクロールのコンセプトだったもので、ウィンドウモードの場合はウィンドウの位置をズラせば良いと考えていました。
また、実験的な機能の Zen モードと同時に開発していたものですから、数値入力じゃなくてファジー (死語？w) な感じにしたいなーという思惑があって、[中間] とか [3 分の 1] とかの大雑把な選択肢にしてますね。
この要素はハマる人にはハマると思いますが、賛否両論あるだろうなぁとも思っていました。設定項目を増やして詳細な設定ができるようにすることもできますから、ご意見は今後の開発の参考にさせていただきたいと思います。
さて、だいぶ本題からズレてしまいましたが、今回の案件について検討した結果ということで、次のバージョンでの実装予定を以下にまとめさせていただきます。
(1) Ctrl + Shift + ↓ or ↑ で改行を含む文字列を検索できるのは現状維持
(2) 検索ダイアログの [検索する文字列] に文字幅ゼロの改行を含んだ文字列が入るのも現状維持
(3) テキストを選択した状態で検索ダイアログを開いたときに [選択テキスト] として渡す文字列の改行は \n に置き換えるのではなく、(2) の仕様どおり、文字幅ゼロの改行で渡す
(4) 上記、3 つのケースにおいて [すべて置換] を正常動作するように改善する
(5) INI ファイルの互換性が保たれなくなる件については非常に悩みましたが、こればっかりはどこかで妥協しなければならないという結論に達しました。
正直、まだ悩んでます (結論に達してないやんw) が、ユーザーさんのご希望と今後の開発のしやすさという天秤でどちらを優先するか、これは私には決められませんでした。
クレームも覚悟しなければならないなと思いつつ、ソースコードは汚れてしまいますが上位互換性だけは維持しつつ、怒られたらテヘペロ作戦かなぁと。(つまり、ユーザーさん側と開発側の中間の妥協点)
(6) その代わり \Q...\E には対応させていただくということで、等価交換、プラマイゼロ。…で、ご容赦いただければ助かります。
しかし、これは無理ですね。この案件、私には荷が重すぎて夜も眠れませんでしたよ ^^;
| Kuro | 返信 -
ご返信ありがとうございます。
> しかし、これは無理ですね。この案件、私には荷が重すぎて夜も眠れませんでしたよ ^^;
必要以上に不安をあおってしまい、申し訳ありません。
よ～くよく考え直しまして今はシンプルに Kuro さん案で行くことに賛成です。
\\ と \n の変換だけですね。> (5) INI ファイルの互換性が保たれなくなる件については非常に悩みましたが、…
何もキーの新設なしでも、元から残っている検索履歴は、読み込み変換→書き込み変換で、互換性を保ったままになるので、実際に困る場面はさらに少ないのではそうです。
正規表現のそこそこ複雑なものを使う方なら、検索履歴をその都度直すのも、Mery.ini をまとめて直すのも、手間はかかってしまうとしても、きっとできるし、やって頂けると思ってよいのではないでしょうか。
多くの方にとっては、正規表現を使わないと今までできなかった、複数行の検索／置換が従来同様の操作でできるようになることの価値がとても大きいはずで、こちらを優先して考えていただければと思います。> (6) その代わり \Q...\E には対応させていただくということで、等価交換、プラマイゼロ。
いや、これは交換条件などではなく、純粋に(笑)便利なのでご案内したものです。もしご採用いただければとてもうれしいです。
> 視線移動をなるべく少なくするというのがタイプライタースクロールのコンセプトだったもので、ウィンドウモードの場合はウィンドウの位置をズラせば良いと考えていました。
>
> …、数値入力じゃなくてファジー (死語？w) な感じにしたいなーという思惑があって、[中間] とか [3 分の 1] とかの大雑把な選択肢にしてますね。最初は 2018年に scrivener の「クリックした所を軸にスクロール」準拠を見送ったのでしたね。
(抜粋)
Typewriter ScrollingTypewriter scrolling—one of my favorite features—which keeps the line you’re working on at a fixed position on the screen (set your preferred location in Scrivener>Preferences>Editing), has always been available in both the Editor (off by default) and in Composition Mode (in which it’s on by default), but there are a few changes to note.
* If you edit text somewhere else on the screen, typewriter scrolling uses that position as the new scroll point to prevent the document from moving around. This solves the problem of the line you’re working on leapfrogging to the center of the screen when you click in the text to make a change. Trust me, it’ll save your eyeballs.
* As long as there is room to do so, you can move the current line back to the center of the Editor, via Command+J or Edit>Find>Jump to Selection.
でもその後、固定スクロールをオフにすることで、カエル飛びにも対応できていて、たいしたものです。
リリース後の意見を見ていて、画面と目の位置の違いや、扱うテキストの形によって、スクロール位置への要望が多様だけれども、その差は少ないように感じていたことが、今回の話の原点でした、ご参考までに…。
さてさて…、寄り道はそこそこに、
どうぞ、ご質問主のご期待をかなえて下さいますよう、よろしくお願いいたします。| inuuik | 返信 -
ご返信ありがとうございます。
> よ～くよく考え直しまして今はシンプルに Kuro さん案で行くことに賛成です。
> \\ と \n の変換だけですね。そうですね。(というか、ちょっと誤解されてるかも？)
これは上位互換性のみ保証するかたちでの実装にしたいと思ってます。(上位互換、下位互換ってどっちがどっちだかややこしいですね ^^;)
つまり、ユーザーさん側は何もしなくてもデータを引き継いで新しいバージョンにアップグレードできます。
ダウングレードの場合、新しいバージョンから古いバージョンにデータを引き継ぐことはできません。(古いバージョンと新しいバージョンを混在させて、ひとつの INI を共有といった遊び方もできません)
ただし、古いバージョンのデータはそのまま残しておくので、ダウングレードした場合はアップグレードする前のデータが復元されます。
> 最初は 2018年に scrivener の「クリックした所を軸にスクロール」準拠を見送ったのでしたね。
なるほど、あの機能でしたか。当時、私の技術では開発できなかった機能のひとつですね。
> リリース後の意見を見ていて、画面と目の位置の違いや、扱うテキストの形によって、スクロール位置への要望が多様だけれども、その差は少ないように感じていたことが、今回の話の原点でした、ご参考までに…。
ご意見はありましたね。しかも私、将来的には実装できるように頑張ります。って書いてましたね。3 ～ 4 年前かぁ…。お、覚えてましたとも (w
https://www.haijin-boys.com/software/mery/mery-2-6-15#comment-2138
できればその場しのぎではなく、きちんと「クリックした所を軸にスクロール」の開発に挑戦したいところではありますね、検討してみます。
| Kuro | 返信 -
ありがとうございます、了解しているはずでしたが…w
> ただし、古いバージョンのデータはそのまま残しておくので、ダウングレードした場合はアップグレードする前のデータが復元されます。
…はないものと思っていました。現状のキーに上書きで…、だったのでは？
> 検索履歴ってすぐに消えていくものですし…
> これを前提に、inuuik さんのエスケープ案、私の案では (第3位) の案になりますが、\ は \\ に、改行文字は \n にエスケープして「キーを新たに設けずに」現状のキーに上書きで保存、復元する案が最善なのではないかと考えています。
上記でもう納得してますので、どうぞ軽装でお手間にならぬ方向でお願いいたします。
開発室に「固定する位置を微調整」追加、ありがとうございます。
> ご意見はありましたね。しかも私、将来的には実装できるように頑張ります。って書いてましたね。3 ～ 4 年前かぁ…。お、覚えてましたとも (w
> できればその場しのぎではなく…
急かしたわけではありません。日本語の「将来」のスパンはもっと長いです。
高校生の「近い将来」でも５年くらい先でしょうし、バージョン 18.0.0 (2040年…w)あたり？と思ってましたしww、もはや私の寿命では見届けられない。でも「ビヨン！」対応を先にした方が、皆さんには受けが良さそうですね。
| inuuik | 返信 -
> …はないものと思っていました。現状のキーに上書きで…、だったのでは？
いえいえ。↓ の内容で回答させていただいたときの案ですよー。
> ↑ 私の解釈があってるか分かりませんが、そういう方向で良ければまた別の案がありますので、その場合は再度、改めてご提案させていただきたいと思います。
↑ の案件と Markdown とタイプライタースクロールと、重めの話題が混在してしまい、うやむやになってしまいましたね。
> 上記でもう納得してますので、どうぞ軽装でお手間にならぬ方向でお願いいたします。
了解しました。とりあえず、私のほうで考えている方向で進めてみます。念のための注意事項ですが、バージョンアップのときに事前に INI ファイルを直接編集して \ を置き換えて…、とかそういった作業は必要ないので、何も気にせず普通にバージョンアップしてみてくださいね。
普通に使ってるユーザーさんには影響ないはずなので、ブログ記事などにも互換性うんぬんは記載しない予定です。
> 急かしたわけではありません。日本語の「将来」のスパンはもっと長いです。
システム屋の言う「将来的には…」は割と大雑把ですからね (w
今はできないけどそのうちやるかもね。って感じのノリですから、時間がかかっても必ずやり遂げる！っていう高校生とは違っていて、時間に余裕が出来たらやるとか、気が向いたらやるとか、そんなものですよ。
> でも「ビヨン！」対応を先にした方が、皆さんには受けが良さそうですね。
確かに、VS Code も Sublime Text もビヨンができる (Visual Studio はできないぞー) ようになってますね。次の案件はビヨン対応かぁ。うーん、重っ！次のバージョンをリリースしてから考えることにしましょう。将来的に…。
| Kuro | 返信 -
Kuro さま さま さま さま
まことにもって『感謝』でございます。素晴らしいです。
改行を含む検索・置換、いい感じです。エスケープのある履歴もスムーズに移行できました。
「すべて検索」、「すべて置換」もしっかり動いてます。メタ文字保留の \Q は先頭に書くと末尾までそのまま通せるので、色々な場面で助かります。
可変、可変+固定スクロール、…思い描いていたタイプライタースクロールが遂に完成！ばんざーい！。
プロ生ちゃん付箋はコルクボードとして使えるので、執筆用具の充実度がさらにグイッと上がりました。「マウス ホイールでタブを選択する」がオプションに昇格、地味にうれしい。
長らく頑なだった URL 判定が、とっても柔軟に全角にも拡張されてずいぶん便利になりました。
「、」を含むとそこ区切りになるけど…、でもバランスはいい感じです。重いお願いをしてしまい…、基本的な仕様が大きく変化したので、使うだけなのに緊張しますww
まだまだ使い始めたばかり、これからじっくり味わいます。本当にありがとうございました。| inuuik | 返信 -
早速お試しいただきありがとうございます。
> エスケープのある履歴もスムーズに移行できました。
その節はご協力ありがとうございました。INI ファイルの仕様変更が発生していますが、たぶん誰にも気付かれない感じでしれーっとできたかなと思います (w
> メタ文字保留の \Q は先頭に書くと末尾までそのまま通せるので、色々な場面で助かります。
これは喜んでくれてるユーザーさんもいらっしゃるようです。私としては鬼車、鬼雲がバージョンアップとか仕様変更とかしないことを祈るのみですが… (ソースを追うのが大変)
> 可変、可変+固定スクロール、…思い描いていたタイプライタースクロールが遂に完成！ばんざーい！。
これはプログラム的には Scrivener モードと Ulysses モードをうまくひとつのオプションに落とし込めた気がしてます。
でも最近、執筆とかしてないものですから、この機能が便利なのかどうか実感がないところです。使い勝手が良かったらぜひ教えてくださいね！
> 「マウス ホイールでタブを選択する」がオプションに昇格、地味にうれしい。
お、気づいていただけましたか。ホイールの誤スクロールや誤クリックについてご要望をいただくようになったので、ようやく表に出してみました (w
> 長らく頑なだった URL 判定が、とっても柔軟に全角にも拡張されてずいぶん便利になりました。
> 「、」を含むとそこ区切りになるけど…、でもバランスはいい感じです。これはね…、正直、今でも悩んでます (w
Visual Studio 2019 だと「、」は CANNOT_END_WITH_CHARACTERS の挙動で、URL の途中にあるときは認識されていたのですが、Visual Studio 2022 にアップグレードしてみたら「、」はそもそも URL として認識されなくなってたんです。
それどころか、Visual Studio 2022 だとユニコード文字はのきなみ NG になったようで。
マイクロソフトも迷走してるなぁ…と思いまして、今回は結局、開発が活発な VSCode に準拠というかたちにさせていただきました。
> 重いお願いをしてしまい…、基本的な仕様が大きく変化したので、使うだけなのに緊張しますww
私もこのクリスマス更新は口から砂がでそうなぐらい緊張していました。どうか、お手柔らかにお楽しみくださいませ (w
| Kuro | 返信 -
はいっ、緊張しながらもゆっくり楽しんで使っていきます。w
> …たぶん誰にも気付かれない感じで…
しばらくそっとしておきますww
ご質問主さまに「検索、置換」でご満足いただけるといいですね。> …仕様変更とかしないことを祈るのみですが… (ソースを追うのが大変)
これは結構長いこと安定していて、そんなに心配いらなそうですが…、全力でお手伝いしますので(笑)
> …ホイールの誤スクロールや誤クリック
やってしまったとき、直ぐに元に戻せなくて、作業の中断がぁ…を防止できて助かります。
> これはプログラム的には Scrivener モードと Ulysses モードをうまくひとつのオプションに落とし込めた気がしてます。
見てすぐ「おぉっ、スゲー！」と思いました。
一気にひたすら打ち込むときは Scrivener モードが一直線に投込む感覚でイケてます。
そして、一番のお気に入りは Ulysses モード の『可変 + 固定スクロール』、
読み直しや書き足しでも視線が落ち着くので、気持ちいいです。
…ぜんぜん執筆というほど書けませんので、作文の感想から(w> …ユニコード文字はのきなみ NG になったようで。
うーん、基準や指標があまり見つからないですからね～。
実際のところ、雑多に大量に収集した日本語の文章から判断して、URL の直後に区切りの「、」や「。」を置かれることはほぼなさそうなんです。でも英語文だと空白を続けて「, 」や「. 」で終わることはよくありますから、一様に CANNOT_END_WITH_CHARACTERS を置き換えて考えるのはむずかしいものです。迷うのはよくわかります。
ただ、長く誤認した URL を正しい所まで短くするには、空白を置くだけで良いのですが、短く認識してしまった URL を延ばす方法がないので、これもまた悩ましいところです。
経験的に落ち着くところを探す一歩目を踏み出した、というところかもですww
| inuuik | 返信 -
> Ctrl + Enter で改行文字入力とかw
もしかして搭載してたりして、と思ってやってみたら使えてしまいました (ﾎﾞｿ...
| yuko | 返信 -
>> inuuik さん
> そして、一番のお気に入りは Ulysses モード の『可変 + 固定スクロール』、読み直しや書き足しでも視線が落ち着くので、気持ちいいです。
厳密にいうと、Ulysses とは仕様が若干異なるのですが、ひとまずうまく動作しているようで安心しました。
> 経験的に落ち着くところを探す一歩目を踏み出した、というところかもですww
そうですね。「自由にカスタマイズできるように～」が一番簡単なんですけど、それをやらないのが Mery のコンセプトですしねw
ひとまず Microsoft の動きに注目しつつ、のんびりやっていこうと思います。
>> yuko さん
> もしかして搭載してたりして、と思ってやってみたら使えてしまいました (ﾎﾞｿ...
気付かれてしまいましたか😅
この操作は VSCode の検索の入力欄でも使えるので、知らない人の邪魔にはならないし、知ってる人はやってみたらできた。っていう感じを想定して、こっそり実装しておきましたw
残念ながら Windows 標準のコンボボックスだと VSCode の入力欄みたいに改行に応じてグイっと引き延ばしたりできないもので、そのあたりは将来的にはなんとかしたいところですね。
| Kuro | 返信 -
気付くのが遅くなりましたが、実装されているのを確認しました。
ありがとうございました。とても助かります。（すごい熱量のやり取り圧巻です！Kuroさんもinuuikさんもありがとうございました）
| ksk | 返信 -
ご確認とご報告いただきありがとうございます。
途中から本題とは別の話題になってしまっていたようで、すみません。
本題の件、うやむやになりつつあったもので、うまく動作しているとのことでご報告をいただけて安心しました。
| Kuro | 返信
