編集モードで折り返し時、3行目から意図した色にならない
-
Kuroさん
Mery安定版リリースに向けた作業、大変お疲れさまです。
そんな中でご報告するのもなかなか恐縮なのですが…😅
折り返し表示中の編集モード反映でちょっと不思議な事象がありましたのでご報告します。環境情報:
- Mery ver 3.7.8
- 自前作成の編集モード「CSV」(後述)
VSCodeでの Rainbow CSV という拡張機能が気に入りまして、Meryでも同じことをしたいなーと思い編集モードをこねくり回しているところでした。
そうしたところ、折り返し3行目以降のハイライトが意図せぬものとなることに気づきました。
後述する自前作成の編集モード「CSV」では列番号24までがハイライトされ、列番号25以降は未定義なので白文字になる想定でした。しかし実際には、折り返し2行目までは想定通りの色になり、3行目の色が何故だが想定外の色が着く挙動になっていました。
また以下キャプチャでよく見ると、1つのカラムに収まっている「列番号25」という文字列が折り返される際、
- 「列番号」が2行目に、「25」が3行目に折り返されている瞬間
- 「列番号」→白色
- 「25」→青緑色
というような状態になっています。
キャプチャ:
https://imgur.com/a/GWCC2cE自前作成の編集モード「CSV」:
※先読み、後読みや繰り返しを駆使してもう少しアイテム数を少なくスマートに書けないものかと腐心したものの、動作スピードが大きく落ちるのでこんな形に…😅#TagBegin= #TagEnd= #CommentBegin1= #CommentEnd1= #LineComment1= #CommentBegin2= #CommentEnd2= #LineComment2= #SpecialSyntax=None #ScriptBegin= #ScriptEnd= #QuoteSingle=False #QuoteDouble=False #QuoteContinue=False #EscapeCharacter= #Word Color=0, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^("[^^",]*"|[^^,]*), #Word Color=1, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^("[^^",]*"|[^^,]*),("[^^",]*"|[^^,]*)(,|$) #Word Color=2, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){2}("[^^",]*"|[^^,]*)(,|$) #Word Color=3, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){3}("[^^",]*"|[^^,]*)(,|$) #Word Color=4, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){4}("[^^",]*"|[^^,]*)(,|$) #Word Color=5, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){5}("[^^",]*"|[^^,]*)(,|$) #Word Color=6, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){6}("[^^",]*"|[^^,]*)(,|$) #Word Color=7, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){7}("[^^",]*"|[^^,]*)(,|$) #Word Color=0, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){8}("[^^",]*"|[^^,]*)(,|$) #Word Color=1, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){9}("[^^",]*"|[^^,]*)(,|$) #Word Color=2, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){10}("[^^",]*"|[^^,]*)(,|$) #Word Color=3, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){11}("[^^",]*"|[^^,]*)(,|$) #Word Color=4, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){12}("[^^",]*"|[^^,]*)(,|$) #Word Color=5, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){13}("[^^",]*"|[^^,]*)(,|$) #Word Color=6, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){14}("[^^",]*"|[^^,]*)(,|$) #Word Color=7, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){15}("[^^",]*"|[^^,]*)(,|$) #Word Color=0, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){16}("[^^",]*"|[^^,]*)(,|$) #Word Color=1, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){17}("[^^",]*"|[^^,]*)(,|$) #Word Color=2, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){18}("[^^",]*"|[^^,]*)(,|$) #Word Color=3, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){19}("[^^",]*"|[^^,]*)(,|$) #Word Color=4, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){20}("[^^",]*"|[^^,]*)(,|$) #Word Color=5, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){21}("[^^",]*"|[^^,]*)(,|$) #Word Color=6, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){22}("[^^",]*"|[^^,]*)(,|$) #Word Color=7, WholeWord=False, RightSide=False, RightAll=False, MatchCase=False, InsideTag=False, RegEx=True ^^(("[^^",]*"|[^^,]*),){23}("[^^",]*"|[^^,]*)(,|$)| yuko | 返信 -
ご報告ありがとうございます😊
> そんな中でご報告するのもなかなか恐縮なのですが…😅
いえいえ、いつでもお気軽にご報告いただけると助かります！
> 折り返し表示中の編集モード反映でちょっと不思議な事象がありましたのでご報告します。
いただいた編集モードを適用して確認してみましたが、これは Mery の仕様上の制限事項にあたるようです。
正規表現による色分けの場合、解析の範囲には以下の制限があります:
- 前方: ひとつ前の行 (折り返し 2 行分)
- 後方: 255 文字
そのため、3 行以上にわたる折り返しの場合、2 行目までは正常に色分けされますが、3 行目以降は、ひとつ前の行 (2 行目) の行頭を基準に解析が始まるため、意図しない色分けになることがあります。
これは動作速度を保証するための仕様ですが、「遅くなっても良いので、解析範囲を広げてほしい」というご意見を過去にいただいたこともありますね。
【参考】編集モードの強調文字列の設定が反映される表示行数(現在2行)を増やしたい
https://www.haijin-boys.com/discussions/7063(なお、リンク先で触れている 240 文字の制限は、現在では 255 文字に緩和されています)
とはいえ、折り返し 2 行という制限は 15 年ほど前の PC スペックに合わせたものなので、最近のパソコンなら行数を増やしても快適に動作するかもしれませんね。(私自身は最近のパソコンを持っていないので未確認ですが…😅)
| Kuro | 返信 -
> そのため、3 行以上にわたる折り返しの場合、2 行目までは正常に色分けされますが、3 行目以降は、ひとつ前の行 (2 行目) の行頭を基準に解析が始まるため、意図しない色分けになることがあります。
なるほどー、仕様だったのですね。1行前から見るということであれば、確かにこういうことになりそうです。
ということは仕様を理解しつつ、この編集モードについては折り返しなしで使うのがベターという感じですね。> これは動作速度を保証するための仕様ですが、「遅くなっても良いので、解析範囲を広げてほしい」というご意見を過去にいただいたこともありますね。
> とはいえ、折り返し 2 行という制限は 15 年ほど前の PC スペックに合わせたものなので、最近のパソコンなら行数を増やしても快適に動作するかもしれませんね。(私自身は最近のパソコンを持っていないので未確認ですが…😅)影響が出るかはその際の表示量、PCスペックにも依るところで、なかなか判断が難しいですね。
それに今回のやりたいことは「各行で列毎に同じ色にしたい」というものですから、「CSVの行長によっては折り返し行数が増えるため、遡る行数を増やしても起こるときには起こる」というものでしょうし、特に折り返し行数を増やしてほしいといった要望は私からは今のところ無いのでご安心を。うーん、なんとか折り返しても実現する上手い方法が見つけられればいいですが、「何番目の列かを正規表現で判断する」という特性上、行頭位置の判定がその都度変わってしまうのでやはり厳しいかもしれませんね…🤔
| yuko | 返信 -
ご返信ありがとうございます。
> なるほどー、仕様だったのですね。1行前から見るということであれば、確かにこういうことになりそうです。
> ということは仕様を理解しつつ、この編集モードについては折り返しなしで使うのがベターという感じですね。そうなんですよ～。ちなみに、私が決めた仕様ではなく、エディターコンポーネント TNotePad の仕様になります。
ソースコードには、作者様のコメントで 3 行以上にまたがるハイライトをサポートするとボトルネックになる旨の注意書きがありました。
それに加えて、正規表現によるハイライトは行をまたがない仕様で、その処理もコメントアウトされているんです。ただ、Mery ではこっそりそのコメントアウトを解除して、1 行だけはまたげるようにしています😏
> それに今回のやりたいことは「各行で列毎に同じ色にしたい」というものですから、「CSVの行長によっては折り返し行数が増えるため、遡る行数を増やしても起こるときには起こる」というものでしょうし、特に折り返し行数を増やしてほしいといった要望は私からは今のところ無いのでご安心を。
お気遣いいただきありがとうございます！😅
技術的には、リミッターを外せば何行でも折り返しをまたぐことは可能ですが、作者様のコメントによると、1 行増やすだけでも動作速度に影響が出るらしくて…そのあたりが悩ましいところですね。
ちなみに、折り返しとは少し違いますが、EmEditor さんには「正規表現で検索する追加行数」という設定項目があって、それでまたげる行数を増やせるみたいなんです。
Mery は改行単位ではなく、折り返し単位で管理しているので仕組みはちょっと違いますが、「正規表現でまたげる行数を増やすオプション」をつけるのはアリかもしれませんね。
ただ、EmEditor さんのフォーラムでは「正規表現で検索する追加行数」を大きくしすぎて、正規表現がフリーズした…なんて話も見かけました。設定を増やすとそれはそれで新たな問題が出てくるかもです💦
> うーん、なんとか折り返しても実現する上手い方法が見つけられればいいですが、「何番目の列かを正規表現で判断する」という特性上、行頭位置の判定がその都度変わってしまうのでやはり厳しいかもしれませんね…🤔
そうなんですよね。行頭から数える必要があると、どうやっても厳しそうです。
ただ、前回ご紹介したリンクのトピックでは、括弧 (「...」) を正規表現で色分けして、3 行以上の折り返しをまたげる例があったんですよね。
何か裏技があるのかもしれませんが、その正規表現を見ても正直…私には何をしてるのか全然わからなくて、ただただポカーンでした😅
| Kuro | 返信 -
> 技術的には、リミッターを外せば何行でも折り返しをまたぐことは可能ですが、作者様のコメントによると、1 行増やすだけでも動作速度に影響が出るらしくて…そのあたりが悩ましいところですね。
個人的には折り返しのまたぎ範囲の仕様は構わないのですが (パフォーマンス上の理由といったユーザーメリットのある話ですし)、それよりも折り返しによって行頭を示す
^のアンカー位置が論理行頭でなくなってしまうケースが痛いなぁと思っているんです。^が使われた検索の場合、「ちゃんと論理行頭から見る」か「そうでないなら、^の入った正規表現は反映しない」のいずれかの方が挙動として一貫すると思うので、理解しやすい感じがします。折り返しなどパフォーマンス考慮から論理行の途中からの検索になっているなら行頭検索は反映されない、といった具合ですね。とはいえ技術的に、なかなか難しいのでしょうが…😅
また、おそらくこのあたりの仕様によるところなのでしょうが、行頭を示す
^を使った正規表現であっても折り返しが発生することで同じ論理行上で何度も検索ヒットが発生するケースがあるようで、これは直感に反する感じがあります。一方、行末を示す$を使った正規表現ではこのような繰り返しヒットになるような挙動はせず、どういう違いなんだろうかと頭をひねっています。- 編集モードで指定した正規表現:
- オレンジ色文字:
(?<=^.{20}). - 黄色文字:
.(?=.{20}$)
- オレンジ色文字:
- キャプチャ: https://imgur.com/a/zcMuAqv
> 何か裏技があるのかもしれませんが、その正規表現を見ても正直…私には何をしてるのか全然わからなくて、ただただポカーンでした😅
うーん、見てみましたが私にもさっぱり😅
もしかしたら、またいでいるのではなく「またいでいる風」なのかも…という感じも受けましたが、なかなかあの力作を読み取る体力も無く…ｗ| yuko | 返信 - 編集モードで指定した正規表現:
-
> ^ が使われた検索の場合、「ちゃんと論理行頭から見る」か「そうでないなら、^ の入った正規表現は反映しない」のいずれかの方が挙動として一貫すると思うので、理解しやすい感じがします。
ちょっと語弊がありそうな表現になってしまったので訂正を…
『「論理行頭から検索できる状況では ^ の入った正規表現を反映する」、「折り返しによって正しく論理行頭から検索できない状況では、^ の入った正規表現は反映しない」という動きになる方が挙動として一貫する』
と言う方が適切でした。| yuko | 返信 -
ご返信ありがとうございます。
> 個人的には折り返しのまたぎ範囲の仕様は構わないのですが (パフォーマンス上の理由といったユーザーメリットのある話ですし)、それよりも折り返しによって行頭を示す ^ のアンカー位置が論理行頭でなくなってしまうケースが痛いなぁと思っているんです。
折り返しのまたぎ範囲の仕様は、「行頭が論理行頭でなくなる」という問題と直結します。
^を正しく論理行頭として認識させるには、折り返しのまたぎ範囲を広げるか、制限を外すしかないんですよね。(ご指摘いただいた別のアプローチについては後述します)試しに手元の PC (かなり古めのスペックですが…) で折り返しのまたぎ範囲制限を外してみたのですが、テキスト内容や正規表現の種類、折り返し位置にもよるものの、改行なしで 10 万文字くらいになると動作がかなり重くなって、さすがに実用は厳しいなぁと感じました。
> また、おそらくこのあたりの仕様によるところなのでしょうが、行頭を示す ^ を使った正規表現であっても折り返しが発生することで同じ論理行上で何度も検索ヒットが発生するケースがあるようで、これは直感に反する感じがあります。一方、行末を示す $ を使った正規表現ではこのような繰り返しヒットになるような挙動はせず、どういう違いなんだろうかと頭をひねっています。
行末については、前回お話ししたように、正規表現の解析範囲が後方に 255 文字拡張されているため、
.(?=.{20}$)のような正規表現では繰り返しヒットしません。ただ、解析範囲を超えるケースでは、行頭と同じように解析範囲の終端が行末とみなされるので、繰り返しヒットすることもあります。
> 『「論理行頭から検索できる状況では ^ の入った正規表現を反映する」、「折り返しによって正しく論理行頭から検索できない状況では、^ の入った正規表現は反映しない」という動きになる方が挙動として一貫する』
> と言う方が適切でした。おっしゃるとおりです。その仕様については以前試したことがあり、技術的には対応可能です。(鬼車の
ONIG_OPTION_NOTBOLオプションを使用して、「文字列の先頭を行頭と見なさない」動作が実現できます)ただし、その仕様を導入すると、正規表現の動作が若干厳密になる一方で、折り返しをまたぐ「抜け道」が使えなくなるというデメリットが発生します。
具体的には、前回ご紹介したリンク先のトピックで公開されている、Mery の「折り返し行頭がマッチする」仕様を利用した正規表現が動作しなくなってしまうため、その正規表現を活用しているユーザーさんにとっては不都合が生じます。
こうした背景もあり、最終的にその仕様は見送りました。
もしその仕様を採用する場合、代償として折り返しまたぎの 2 行制限を緩和する必要が出てきます。さらに言えば、折り返しまたぎの制限を完全になくしてしまえば、その仕様自体が不要になるわけですが… (…そして冒頭に戻るというループですね😅)
| Kuro | 返信 -
解説ありがとうございます。
やっと状況が見えてきました。 (そして、なかなかジレンマな状況であることも…😅)> 正規表現の解析範囲が後方に 255 文字拡張されているため、
.(?=.{20}$)のような正規表現では繰り返しヒットしません。たしかに、
.(?=.{255}$)まで拡大してみたら、繰り返しヒットされました…。> 具体的には、前回ご紹介したリンク先のトピックで公開されている、Mery の「折り返し行頭がマッチする」仕様を利用した正規表現が動作しなくなってしまうため、その正規表現を活用しているユーザーさんにとっては不都合が生じます。
ふむ…やっぱりこれはそういう裏技だったんですね。
たしかに突然仕様が変わる (そして代替策も無い) のは困ってしまいますね。> Mery は改行単位ではなく、折り返し単位で管理しているので仕組みはちょっと違いますが、「正規表現でまたげる行数を増やすオプション」をつけるのはアリかもしれませんね。
前回の回答で上記がいいかも、とKuroさんが仰っていた意味がやっと分かってきました。現状の「折り返しに伴う繰り返し検索 & 繰り返し時に行頭行末も繰り返し扱われる」という仕様を使った裏技を維持できるから、ということだったんですね。
それならたしかに、またげる範囲を拡大するオプション、良さそうに感じます。
ただ個人的には、折り返し行数設定よりも、「正規表現は論理行単位で扱う」のような強調文字列ごとのオプションとして折り返しリミットを外すか選べる方が嬉しいかもしれません。正規表現の検索量は作り手で調整できるものなので、「動作が重かったら正規表現側で調整してね」とできるのではないかなと。
| yuko | 返信 -
ご返信ありがとうございます。
> 現状の「折り返しに伴う繰り返し検索 & 繰り返し時に行頭行末も繰り返し扱われる」という仕様を使った裏技を維持できるから、ということだったんですね。
そうですね、その点もありますが、それだけではないんです。
仕様についてご理解いただいたほうが話がスムーズかなと思いますので、少し技術的な話になりますが、Mery の色分けの仕組みと、折り返し範囲を広げた場合の影響について説明させてください😅
まず、前提として「改行がなく、右端で折り返されている長いテキスト」がある状況を想像してください。
ここでいう「1 行目」「2 行目」といった表現は、折り返された表示上の行を指しているので、そのつもりで読み進めてもらえるとうれしいです。
Mery の色分け処理は、この表示上の行ごとに行われています。
具体的には:
- 1 行目を色分け
- 次に 2 行目を色分け
- さらに 3 行目を色分け…
という感じで、画面に表示されている行を順番に処理しています。
現行の仕様では、折り返し 1 行分だけ手前にさかのぼって処理しているので:
- 2 行目の色分けは、1 行目の行頭から 2 行目まで
- 3 行目の色分けは、2 行目の行頭から 3 行目まで
といったかたちで、必要な範囲のテキストを取得して処理しています。
では、「リミット」を外した場合にはどうなるのか、説明しますね。
たとえば、2 行目を色分けするとき、論理行頭 (1 行目の行頭) を探しに行き、そこから 2 行目までのテキストを取得して処理します。
同じように、3 行目を色分けするときも、論理行頭を探しに行き、そこから 3 行目までのテキストを取得して処理します。この動作を、折り返しの行数分だけ繰り返します。
ここで問題なのは、もし折り返しが 10 行もあるとすると:
- 各行で論理行頭を探す
- その位置を起点にテキストを取得する
- 色分け処理を行う
これを毎回繰り返すため、行が増えるほど負荷が加速度的に増加してしまいます。
【参考画像】https://imgur.com/a/9Px9b7v
「正規表現でまたげる行数を増やすオプション」というのは、こういったプログラム的に好ましくない状況を避けるためでもあります。
> ただ個人的には、折り返し行数設定よりも、「正規表現は論理行単位で扱う」のような強調文字列ごとのオプションとして折り返しリミットを外すか選べる方が嬉しいかもしれません。正規表現の検索量は作り手で調整できるものなので、「動作が重かったら正規表現側で調整してね」とできるのではないかなと。
そのお気持ちは、とてもよくわかります。
ただ、色分け範囲のテキストを取得する処理自体がボトルネックになるため、仕様上、最初に色分けの範囲を決めてテキストを取得し、その後、そのテキストに対して、強調文字列のリストから色分けを順番に適用するという流れになっています。
そのため、リミットを外す場合、すべての強調文字列に対してその範囲が適用されるかたちになります。
なので、「動作が重かったら正規表現側で調整してね」という対応にしたとしても、「フリーズやクラッシュのリスクが出てしまうため、自己責任でお願いします」という免責事項が必要になっちゃいますね🤔
もし実装する場合は、開発者としては非推奨、初心者の方の目には触れない、隠しオプションのようなかたちにするのが現実的かな、と思います。
そういうわけで、一度整理してみました。考えられる方法としては次の 4 つかなと思います。
-
何もしない (現状の仕様のまま)
-
現状の仕様 + 『「論理行頭から検索できる状況では ^ の入った正規表現を反映する」、「折り返しによって正しく論理行頭から検索できない状況では、^ の入った正規表現は反映しない」という動きになる方が挙動として一貫する』のみ、隠しオプションで適用
折り返しまたぎ範囲は現状どおりで、正規表現の行頭
^が論理行頭にマッチするようになります。…というより、正規表現の行頭
^が折り返し行頭にマッチしなくなります。といったほうが的確ですね。また、
^が論理行頭にマッチした場合、折り返された 3 行目以降は、正規表現は反映されません。動作速度への影響はほぼ問題ないかと思います。
- 「正規表現でまたげる行数を増やすオプション」を隠しオプションで適用
指定した行数の範囲内なら、正規表現の行頭
^が論理行頭にマッチするようになります。また、
^が論理行頭にマッチしたとき、折り返された 3 行目以降も指定した行数の範囲内なら正規表現が反映されます。動作速度は前述のとおりですが、PC のスペックや求められる色分け精度に応じて調整可能です。
- 「リミットを外す」を隠しオプションで適用
正規表現の行頭
^が厳密に論理行頭にマッチするようになります。また、^が論理行頭にマッチしたとき、折り返された 3 行目以降も正規表現が反映されます。ただし、動作速度への影響が大きく、フリーズやクラッシュのリスクがあります。
いずれの設定も共通設定として適用され、編集モードの強調文字列の正規表現と、マーカー機能の正規表現に適用されます。
こんな感じで考えてみました。長文になったので、ひとまずこの辺で😊
| Kuro | 返信 -
解説ありがとうございます🙇♂️
テキストエディタ、深淵な仕組みのもと成り立っているのですね…。話をお聞きする度に、それを改善し続けるKuroさんに脱帽です。> 具体的には:
> - 1 行目を色分け
> - 次に 2 行目を色分け
> - さらに 3 行目を色分け…
> という感じで、画面に表示されている行を順番に処理しています。
>
> では、「リミット」を外した場合にはどうなるのか、説明しますね。
> たとえば、2 行目を色分けするとき、論理行頭 (1 行目の行頭) を探しに行き、そこから 2 行目までのテキストを取得して処理します。
> 同じように、3 行目を色分けするときも、論理行頭を探しに行き、そこから 3 行目までのテキストを取得して処理します。この動作を、折り返しの行数分だけ繰り返します。折り返し毎にどうしても検索処理が発生する仕組み、ということですね。
たしかに折り返し行数の多い、長蛇な一行で論理行で見始めたら、計算量がすごいことになりそうです…😱軽量さにこだわるKuroさんがここまで仰っている以上、どうしても「折り返しているときに論理行で1回の検索」にはできないものなのだろうとお察ししました。無理を言ってすみません。
> もし実装する場合は、開発者としては非推奨、初心者の方の目には触れない、隠しオプションのようなかたちにするのが現実的かな、と思います。
> 1. 何もしない (現状の仕様のまま)
> 2. 現状の仕様 + 『「論理行頭から検索できる状況では ^ の入った正規表現を反映する」、「折り返しによって正しく論理行頭から検索できない状況では、^ の入った正規表現は反映しない」という動きになる方が挙動として一貫する』のみ、隠しオプションで適用検討いただいてありがとうございます。
1 か 2 に票を入れたいと思います。やはり私の脳内では「
^といえば行頭、$と言えば行末」というイメージが湧いてしまうので、2の隠しオプションがあれば是非使わせていただきたいところですね。3については恐らく自分は使わないだろうなと感じ、4についてはご説明いただいたように不意な鈍重に悩まされることがありそうだと分かったので、出しといてすみませんが意見を引っ込めたいと思います😅
| yuko | 返信 -
ご返信ありがとうございます。
> 軽量さにこだわるKuroさんがここまで仰っている以上、どうしても「折り返しているときに論理行で1回の検索」にはできないものなのだろうとお察ししました。無理を言ってすみません。
いえいえ、お気になさらないでください😊
そうですね。他のテキストエディターだと、論理行単位でデータを管理しているものが多いので、そういった場合は Mery よりも有利なところがありますね。(その代わり、改行をまたぐ検索が苦手だったりするのですが…)
ちなみに、Mery もすべての行を常に再描画しているわけではないので、計算量が毎回最悪というわけではないんです。
ただ、画面をスクロールしたり選択範囲を変更したりする場面では、複数行を再描画する必要が出てくるので、どうしてもその分速度に影響が出てしまうんですよね。ここは避けられない課題です…。
> 1 か 2 に票を入れたいと思います。
ご意見ありがとうございます。
そうですね、私も 2 は「例の裏技」の事例がなければ…というか、最初から
ONIG_OPTION_NOTBOLの存在を知っていれば、たぶん迷わず採用してたと思います。それから、4 については、最近の PC スペックでどれくらいのパフォーマンスが出るのか試してみていただきたい気持ちもあって、こんな案を考えてみました。
隠しオプションとして、正規表現のモードを、Loose モード (案 1)、Fast モード (案 2)、Strict モード (案 4) の 3 つを用意します。
- Loose (現状の仕様):
- 前方: 折り返し 1 行
- 後方: 255 文字まで
- 改行をまたげる
- Fast (論理行単位で高速モード):
- 前方: 折り返し 1 行
- 後方: 折り返し 1 行
^が折り返し行頭にマッチしない$が折り返しの行末にマッチしない- 改行をまたげない
- Strict (論理行単位で厳密モード):
- 折り返しまたぎの制限なし
^が論理行頭にマッチする$が論理行末にマッチする- 改行をまたげない
※補足: Fast モードと Strict モードは論理行単位の処理になるので、改行文字をまたぐ色分けはできなくなります。
…と、こんな感じでどうでしょう？
まずはこの案で試してみてもらって、結果を見てから「折り返しまたぎ範囲の行数」を別オプションにするとか、安定版をリリースしたあとで設計をゼロから見直すのもアリかな…なんて思うのですが😋
| Kuro | 返信 - Loose (現状の仕様):
-
ご検討重ねていただいてありがとうございます🙇♂️
> それから、4 については、最近の PC スペックでどれくらいのパフォーマンスが出るのか試してみていただきたい気持ちもあって、こんな案を考えてみました。
ありがとうございます。
「重くなる場面が多くて結果的に使わなくなってしまった…」ってなるのが申し訳ないので引っ込めてしまったものの、試してみたかったんです。そう言っていただけるのであれば、是非試してみたいですね。> 隠しオプションとして、正規表現のモードを、Loose モード (案 1)、Fast モード (案 2)、Strict モード (案 4) の 3 つを用意します。
3段階、良いと思います。
> - Loose (現状の仕様):
> - 前方: 折り返し 1 行
> - 後方: 255 文字まで
> - 改行をまたげるまさに、この並びで言えば確かに現行仕様はLooseモード。うまい落とし所な表現だと思いますｗ
> - Fast (論理行単位で高速モード):
> - 前方: 折り返し 1 行
> - 後方: 折り返し 1 行
> -^が折り返し行頭にマッチしない
> -$が折り返しの行末にマッチしない
> - 改行をまたげない「後方: 折り返し 1 行」のところ、現行の「255文字まで」でもいいのではないかとふと思ったのですが、どういった意図でしょうか？
「^は先頭から折り返し2行分までしか反映されないから、$も末尾から見て折り返し2行までしか反映されない」といった、雰囲気を揃える意味合いかな…とは想像しました。
あるいは「^が折り返し行頭にマッチしない」「$が折り返しの行末にマッチしない」を実現するための仕様上の制限、とかでしょうか？また、後方が折り返し1行ということは「ウィンドウの右端で折り返し」を使っていると文字サイズ・ウィンドウサイズにもよりますが概ね255文字より少ない検索範囲にはなりそう (まさしく Fast) ですが、「折り返さない」で8000文字を超えて折り返すケースや、「指定文字数で折り返し」で数千文字で折り返すようにしているケースにおいては、後方向け検索範囲が255文字を超えるケースもありそうで、そうなると「Fast」というのが字面通りではなくなるケースもあるのでは、と思いました (ちょっと揚げ足取りですが😅)。
そういうところで、デフォルト (Loose) と違い
^$の意味合いが正しく「行頭、行末」になるということで、個人的には、このモードが「Strict」なイメージを持ちました。
となると後者の「Strict」はどうなるの、という問題が出てくるのですが、「超厳密だけど重くなるよ」ということで「Strict Full」とか…？> - Strict (論理行単位で厳密モード):
> - 折り返しまたぎの制限なし
> -^が論理行頭にマッチする
> -$が論理行末にマッチする
> - 改行をまたげない最も厳密 (その代わり重くなる可能性もある) という選択肢を設けるということで、特に異論ありません。
> まずはこの案で試してみてもらって、結果を見てから「折り返しまたぎ範囲の行数」を別オプションにするとか、安定版をリリースしたあとで設計をゼロから見直すのもアリかな…なんて思うのですが😋
そうですね、まずはお試しで出すのに支障なければ、是非試してみたいです！
| yuko | 返信 -
ご返信ありがとうございます。
> 「後方: 折り返し 1 行」のところ、現行の「255文字まで」でもいいのではないかとふと思ったのですが、どういった意図でしょうか？
> 「^ は先頭から折り返し2行分までしか反映されないから、 $ も末尾から見て折り返し2行までしか反映されない」といった、雰囲気を揃える意味合いかな…とは想像しました。
> あるいは「^が折り返し行頭にマッチしない」「$が折り返しの行末にマッチしない」を実現するための仕様上の制限、とかでしょうか？そのあたりは、仕様上の制限と言える感じですね。
「
$が折り返しの行末にマッチしない」を実現するには、正規表現エンジン (鬼車) に渡す文字列の終端が「折り返し行末」なのか「論理行末」なのかを事前に判断する必要があります。現行の「255 文字まで」という仕様では、行の途中で分断された文字列が鬼車に渡されるため、以下のような挙動が発生します:
- 後方 255 文字内に論理行末が含まれていれば
$がマッチする - 含まれていない場合、255 文字目が終端として
$にマッチしてしまう
その結果、
$が意図せず繰り返しマッチしてしまうケースが出てきます。そこで、「後方: 折り返し 1 行」とすることで、鬼車に渡す文字列の末尾が「折り返し行末」なのか「論理行末」なのかをチェックし、
$のマッチング動作 (ONIG_OPTION_NOTEOLフラグを渡すかどうか) を切り替える仕組みを検討しています。> 「折り返さない」で8000文字を超えて折り返すケースや、「指定文字数で折り返し」で数千文字で折り返すようにしているケースにおいては、後方向け検索範囲が255文字を超えるケースもありそうで、そうなると「Fast」というのが字面通りではなくなるケースもあるのでは、と思いました (ちょっと揚げ足取りですが😅)。
確かに、後方検索範囲が最大で次の行 (8000 文字) まで広がることになりますね。
ただ、この問題は「前方: 折り返し 1 行」でも同じで、処理負荷としては 1 行分増えるだけなので、フリーズするほど重くはならないはずですし、試してみないとわかりませんが、動作速度への影響も許容範囲内かなと思っています。(「Fast」かどうかは置いといてw)
> そういうところで、デフォルト (Loose) と違い ^ $ の意味合いが正しく「行頭、行末」になるということで、個人的には、このモードが「Strict」なイメージを持ちました。
モード名はあくまで説明用の便宜的なもので、画面に表示されるわけではないので、あまり気にしないでください。設定は「RegExMode=1」のような形式で記述するだけなので😅
> そうですね、まずはお試しで出すのに支障なければ、是非試してみたいです！
まずは仕様がうまく動くかどうか試してみないとわからないですが、たとえば、
「.+?」で折り返しをまたぐ長い行があって、その末尾の」を削除した場合に正規表現にマッチしなくなると、1 行目から末尾までの色を一気に変えないといけないシーンなんかは、対応しきれないかもしれません。現行の仕様では折り返しをまたぐのはサポート外なので、そういう場合は色分けが即時反映されないこともありますが、「てへぺろ」で済ませてる部分もあるんですよね😋
今回は隠しオプションとして試験的に実装するかたちになるので、使いづらければ廃止する選択肢もありますし、まずはうまく動くか試してみるしかないですね。
| Kuro | 返信 - 後方 255 文字内に論理行末が含まれていれば
-
> 「`$`が折り返しの行末にマッチしない」を実現するには、正規表現エンジン (鬼車) に渡す文字列の終端が「折り返し行末」なのか「論理行末」なのかを事前に判断する必要があります。
> そこで、「後方: 折り返し 1 行」とすることで、鬼車に渡す文字列の末尾が「折り返し行末」なのか「論理行末」なのかをチェックし、`$`のマッチング動作 (`ONIG_OPTION_NOTEOL`フラグを渡すかどうか) を切り替える仕組みを検討しています。なるほど。やはりそういう事情があり、後方も行単位で扱うしかないということなんですね。
> モード名はあくまで説明用の便宜的なもので、画面に表示されるわけではないので、あまり気にしないでください。設定は「RegExMode=1」のような形式で記述するだけなので😅
そうですよね、これは失礼しました😅
> 今回は隠しオプションとして試験的に実装するかたちになるので、使いづらければ廃止する選択肢もありますし、まずはうまく動くか試してみるしかないですね。
まずはStrictモードで常用してみたいですね。これで例のCSV用編集モードが実用的な速度で動いてくれるととても嬉しい……
編集モード「Markdown」なんかはその判定にふんだんに正規表現が用いられているようですので、試金石によいかもしれませんね。
楽しみにしています😁
| yuko | 返信 -
ご返信ありがとうございます。
> まずはStrictモードで常用してみたいですね。これで例のCSV用編集モードが実用的な速度で動いてくれるととても嬉しい……
その後、色々と試行錯誤していたところ、Strict モード (論理行単位で厳密) での折り返し完全またぎをかなり高速化できるアイデアが浮かびました。
さすがに改行なしで 100 万文字くらいになると重くなっちゃいますが、前回問題になった 10 万文字程度なら、十分実用的に動きそうだなと感じています。
改行なしの 100 万文字で同じ正規表現を試してみたところ、カーソル移動は再描画の影響でちょっと遅くなりますが、スクロールや範囲選択はサクラエディタさん並みの速度が出せそうです。
なので、Fast モード (論理行単位で高速) は必要ないかもしれません。
ただ、正規表現による色分け処理を大幅に作り直さないといけないので、Loose モード (従来の仕様) との共存には、従来のコードをそのままにして新しい仕組みを別途、作らないといけないので大変ですが…😅
まだ実験段階なので、もしかしたら「やっぱりダメでした」ってことになるかもしれませんが、とりあえずご報告まで😊
| Kuro | 返信 -
> その後、色々と試行錯誤していたところ、Strict モード (論理行単位で厳密) での折り返し完全またぎをかなり高速化できるアイデアが浮かびました。
> さすがに改行なしで 100 万文字くらいになると重くなっちゃいますが、前回問題になった 10 万文字程度なら、十分実用的に動きそうだなと感じています。おおーっ！すごい！
さすがに1行にそれだけの文字が詰め込まれているケースってそうそうないと思いますし、そのアイデアが実装されたら実用上は問題なしと言えそうですね。> ただ、正規表現による色分け処理を大幅に作り直さないといけないので、Loose モード (従来の仕様) との共存には、従来のコードをそのままにして新しい仕組みを別途、作らないといけないので大変ですが…😅
こちらとしては大いに楽しみですが、なかなか大掛かりになりそうですね…ご面倒をおかけします🙇♂️
いずれにせよまだまだ先の話ですが、完成度次第では「正規表現の試験的機能を有効にする > [...] ボタン」みたいなオプション小窓として、「鬼車を使用する」と並べて設定できる感じにしてもよいかもしれませんね。
| yuko | 返信 -
Ver 3.7.9 でのご対応、ありがとうございました！
前述の編集モードCSVを32列目 (さすがにそんな列数多いCSVは扱わないかな…という想定でこの程度で) まで拡張してみまして、折り返しありの着色具合を見てみましたが… 素晴らしいです！想定通りの色順になっています。
https://imgur.com/a/YKwU1wTまた、動作速度についてですが、このくらいの文字数、表示量ではさすがにまったく問題ありませんね。
試しに「『列数は50列、1行全体で10万文字』を複数行…」なCSVを作ってみましたが、ややカーソル移動や入力に遅延感は出るものの、操作ができないほどではありませんでした。(参考までに、スペック情報は後述)
また編集モード「Text」(Markdown風カスタム入り) を使った場合にはさらに早く、10万文字でも遅延は感じませんでした。
検証環境スペック:
- CPU: AMD Ryzen 5 3600 6-Core Processor 3.60 GHz
- メモリ: 64.0 GB
- GPU: GeForce RTX 3060これでだいぶCSVでの列の対応が見分けやすくなり、CSVビューワーとしての機能性が上がりそうです！
今のところ大丈夫そうですが、ちょっと常用して様子を見てみますね😉
| yuko | 返信 -
以前に同様の要望を出した者です。
対応ありがとうございます。テキスト全体で約5000行、全体に満遍なくある折り返しは多くて4・5行。
「RegExMode=2」で試してみましたが速度的には特に問題なかったです。Win11, i5-9500T, メモリ16GB
| 村人 | 返信 -
>> yuko さん
早速お試しいただきありがとうございます。
おー！うまく動作しているようで安心しました。カラフルな CSV、こうして見るとすごい迫力ですねw
> 試しに「『列数は50列、1行全体で10万文字』を複数行…」なCSVを作ってみましたが、ややカーソル移動や入力に遅延感は出るものの、操作ができないほどではありませんでした。
おーん、最近の PC はすごいですね。私の環境だと、10 万文字が 1 行のみの場合で、上記のような速度感です。ちょっと重いけど「まあ許容範囲内かな？」という感じ。
検証環境スペック:
- CPU: Intel® Core™ i5-4670 CPU @ 3.40GHz 3.40 GHz
- メモリ: 16.0 GB
- GPU: Intel® HD Graphics 4600
> 今のところ大丈夫そうですが、ちょっと常用して様子を見てみますね😉
検証へのご協力、ありがとうございます！正規表現での色分けはあまり使いこなせていないので、とても助かります。
>> 村人さん
早速お試しいただきありがとうございます。
その節はご意見ありがとうございました。当時は技術不足で速度の問題がかなり大きく、対応に時間がかかってしまいました。
今回は、このスレッドの途中で高速化のヒントがひらめいたのが大きかったですね。当時の技術のままだったら、たぶん今の 50 倍ぐらい遅かったと思います。
> テキスト全体で約5000行、全体に満遍なくある折り返しは多くて4・5行。
> 「RegExMode=2」で試してみましたが速度的には特に問題なかったです。4、5 行ぐらいなら大丈夫そうですね。でも、以前ご意見いただいた正規表現
「.+」みたいなのだと、やっぱりちょっと影響が出ちゃいそうな気がします。ちなみに、秀丸エディタさんや EmEditor さんの正規表現の色分けって爆速なんですが、メモリの使用量を見る感じ、内部で検索結果をキャッシュしてるっぽいんですよね。その分、メモリを結構食うケースもあるみたいです。
Mery もメモリ消費を気にしなければもっと速くできそうですが、1 行が 10 万文字のテキストを編集する機会ってそんなにないですよね…。なので「そこそこ速くて省メモリ」な現状の仕様でひとまずリリースしてみました。
また何かお気づきの点がありましたら、ぜひ教えていただけると助かります。
| Kuro | 返信 -
> 検証環境スペック:
> - CPU: Intel® Core™ i5-4670 CPU @ 3.40GHz 3.40 GHz前に使ってたのがi7-4790で、今のi5-9500Tがほぼ同じかちょっと速いぐらいのスペックらしいので、そちらとも似たような環境かなと思ってます。ネットにあるベンチマーク結果見ると1.1～1.3倍ぐらいの性能差。
> 4、5 行ぐらいなら大丈夫そうですね。でも、以前ご意見いただいた正規表現
「.+」みたいなのだと、やっぱりちょっと影響が出ちゃいそうな気がします。まさにそのパターンでです。具体的には
(『[^『]+』|“[^“]+?”|〝[^〝]+?〟)
^「.+?」$
のような感じです。強調表示の設定は25パターンほど。青空文庫形式のタグやセリフ部分の色分けに使ってます。カッコの閉じ忘れとかを見やすくするために設定しているのですが、3行目以降に色が付かなかったので少し困ってました。解決してよかったです。ありがとうございます。
| 村人 | 返信 -
情報ありがとうございます。
> ネットにあるベンチマーク結果見ると1.1～1.3倍ぐらいの性能差。
1.3 倍と聞くと小さい差に感じますが、体感的には速度が変わってくる気もします。
> まさにそのパターンでです。具体的には
> (『[^『]+』|“[^“]+?”|〝[^〝]+?〟)
> ^「.+?」$
> のような感じです。強調表示の設定は25パターンほど。なるほど、そんな重そうな正規表現を 25 パターンも使用しているのに、動作がそれほど重くならないのは驚きですし、嬉しい情報です。
> 青空文庫形式のタグやセリフ部分の色分けに使ってます。カッコの閉じ忘れとかを見やすくするために設定しているのですが、3行目以降に色が付かなかったので少し困ってました。解決してよかったです。ありがとうございます。
そう言っていただけると嬉しいです。もし実用上問題なさそうなら、この設定をデフォルトにするのもアリかもですね。
| Kuro | 返信 -
村人さんも仰っているように、動作速度に特に不便が無く、今日一日使い込んでみましたが、特に違和感ありませんでした。
折角なので、今回作った構文テーマもアップ。結局40列まで拡張して使っています。
https://www.haijin-boys.com/wiki/CSV/TSVCSVの場合、1行の方が見やすいのは見やすいのですが、でもMeryは小さな窓で折り返し表示がデフォな私には、折り返しでもちゃんとこのカラーリングが維持されるの、本当に助かります😊
これで気兼ねなくCSV構文テーマが使えるなと使っていて気付いたのですが、分割表示をうまく使うとまるで「ヘッダ固定表示」な雰囲気があって良いですねｗ
https://imgur.com/a/FvP1pRE| yuko | 返信 -
検証にご協力いただき、ありがとうございます。
> 村人さんも仰っているように、動作速度に特に不便が無く、今日一日使い込んでみましたが、特に違和感ありませんでした。
私もアップしていただいた構文ファイルを試させていただきました。
普段使いでは特に問題なく動いていますが、1 行が 10 万文字くらいになると、さすがにちょっとカクカクしちゃいますね😅
デフォルトで
RegExMode=2にするのは、少し不安かなぁという感じです。> これで気兼ねなくCSV構文テーマが使えるなと使っていて気付いたのですが、分割表示をうまく使うとまるで「ヘッダ固定表示」な雰囲気があって良いですねｗ
おお、これ面白いですね！ルーラーを非表示にしてみると、さらに「ヘッダ固定表示」っぽくなって、イイ感じですよw (サブ窓だけルーラー非表示にできたら最高なんですけど、ちょっと無理ですね)
ただ、動作速度については別窓分の負荷がかかるせいで、2 倍くらい遅くなる気がするので、そのあたりだけちょっと気を付けたほうがいいかもしれません。
| Kuro | 返信 -
> デフォルトで
RegExMode=2にするのは、少し不安かなぁという感じです。そうですね、速度重視ならやはり
RegExMode=0かRegExMode=1という感じですね。とはいえそこまで長～～～い行のCSVって、DBダンプとかしたものとかでもないと見ることも無い気がしますし (そこまでいくと専用のCSVエディターを使った方が楽になってきそう)、日常的な利用上の問題はなさそうです。まだ様子見でしょうが、表のオプション提供も視野に入る完成度な気はします。
ちなみに
RegExMode=0RegExMode=1RegExMode=2それぞれで、「1行あたり10万文字、100列のCSV」を「折り返しなし」で表示した感じ、速度感は以下の順でした。RegExMode=1(最速)RegExMode=0RegExMode=2(最遅)
折り返しありだと
RegExMode=0RegExMode=1も遅延感なく、速度も差を感じませんが、折り返しなしだと遅延感が出てきますね。
一方、RegExMode=2は、折り返しの有無に関わらず検索量が一定なんだと想像しており、折り返しの有無で速度感に変わりはありませんでした。> おお、これ面白いですね！ルーラーを非表示にしてみると、さらに「ヘッダ固定表示」っぽくなって、イイ感じですよw (サブ窓だけルーラー非表示にできたら最高なんですけど、ちょっと無理ですね)
おお、たしかに、たしかにｗ
ヘッダ部分とボディ部分とで行長が大きく違っていて「ここのカラム名はなんだったかな？」ってなることも多いですが、「ヘッダだけ横スクロールができるのでボディ部のスクロール位置は維持する」というのが簡単にできるのも、なかなか良いかもです。
| yuko | 返信 -
MeryでCSVの使い勝手がなったことに嬉しくなって、CSVの列選択マクロも用意してみました😊
これで、列単位の選択、切り出し (選択してからコピー) も簡単にできるようになりました。
たぶん検索条件が重くて、検索結果を解除するまで横スクロールが鈍重になってしまうのが玉に瑕ですが…😅
| yuko | 返信 -
> CSVでアクティブ列選択 - MeryWiki
どうせならCSV/TSV両対応に、ということでページタイトルを変えてしまい、URLが変わってしまいました…😅 (親切に転送されるようですが)
| yuko | 返信 -
CSV/TSVでアクティブ列選択
良いですね
昔Kuroさんが作られたCSVのカーソル位置の列を削除.js
は削除のみだったので選択なら色々使えますね
これも構文ファイルcsv-tsvと共に使わせていただきます| kiyohiro | 返信 -
ご返信ありがとうございます。
> まだ様子見でしょうが、表のオプション提供も視野に入る完成度な気はします。
そうですね。ただ、このオプション、ちょっとマニアックすぎる気もするので、できれば初心者の方の目には触れないようにしたいと思っています。
それに、制限事項や使い方の説明も必要になりそうですし、そこまでして使ってもらう必要があるのか、正直悩むところです。
やっぱり、動作速度がさらに改善されて実用レベルに達すれば、オプションではなく標準仕様として取り込むのが理想的ですね。
> 一方、RegExMode=2 は、折り返しの有無に関わらず検索量が一定なんだと想像しており、折り返しの有無で速度感に変わりはありませんでした。
おっしゃるとおりです。
RegExMode=2は論理行全体を鬼車に丸投げしているので、折り返しがあってもなくても速度にはほとんど影響しないと思います。ただ、折り返しが増えると、論理行の先頭を探しに行く処理で若干影響を受ける可能性はありますね。
> CSV/TSVでアクティブ列選択 - MeryWiki
> たぶん検索条件が重くて、検索結果を解除するまで横スクロールが鈍重になってしまうのが玉に瑕ですが…😅試させていただきました！確かに、重くなりますね…😅
同じ正規表現をサクラエディタさんや EmEditor さんで試してみたのですが、動かなくて「あれ？」と思ったら、鬼雲では対応していない感じですね。
Mery でも [鬼車を使用する] をオフ (鬼雲モード) にすると動きませんでした。
それと、Mery は基本的に画面に表示されている行だけを処理しているはずなのですが、カーソルを下に移動するとどんどん重くなるんですよね…。これ、鬼車が行頭じゃなくてテキスト全体の先頭から検索してるっぽい気がします。
正規表現に詳しくないので、
(?<=^([^,]*,|"[^",]*",){10})([^,]*|"[^",]*")の意味はサッパリですが…鬼車の中で何が起きているのか、謎が深いです🤔| Kuro | 返信 -
>> Kuroさん
> そうですね。ただ、このオプション、ちょっとマニアックすぎる気もするので、できれば初心者の方の目には触れないようにしたいと思っています。
> それに、制限事項や使い方の説明も必要になりそうですし、そこまでして使ってもらう必要があるのか、正直悩むところです。
> やっぱり、動作速度がさらに改善されて実用レベルに達すれば、オプションではなく標準仕様として取り込むのが理想的ですね。うーむ、なるほど確かに…🤔
> 同じ正規表現をサクラエディタさんや EmEditor さんで試してみたのですが、動かなくて「あれ？」と思ったら、鬼雲では対応していない感じですね。
>
> Mery でも [鬼車を使用する] をオフ (鬼雲モード) にすると動きませんでした。なんと！鬼車のみの記法を使ってしまっていましたか。
今日一日使ってみたのですが、CSVって思えば「ダブルクォーテーション括り」があったり、そこに括られているとカンマが文字列として使えたりと、割とフリーダムだったよなと思い至り、正規表現ではなく「パースして必要な位置を割り出し、マルチカーソルを必要数追加する方法」じゃないとダメなんだろうなぁと思い知らされたところです。鬼車の話もありますし、やっぱりその方向ですね…。
CSV、奥が (闇が) 深い……😑> それと、Mery は基本的に画面に表示されている行だけを処理しているはずなのですが、カーソルを下に移動するとどんどん重くなるんですよね…。これ、鬼車が行頭じゃなくてテキスト全体の先頭から検索してるっぽい気がします。
> 正規表現に詳しくないので、(?<=^([^,]*,|"[^",]*",){10})([^,]*|"[^",]*")の意味はサッパリですが…鬼車の中で何が起きているのか、謎が深いです🤔どうやら
[^,]*あたりが、改行まで検索ヒットしてしまっているようなんですよね。なのでやっぱり、selection.Find();を使わない方式で再考してみないと、どこかで予期せぬ挙動をしてしまいそうです。>> kiyohiro さん
「CSV/TSVでアクティブ列選択」、折角使っていただいたのに、微妙な挙動をしていて申し訳ないです。
修正版公開に向け、ちょっと頑張ってみますので、完成したらまたこちらのスレッドでお知らせしますね。また、構文ファイル「CSV」ですが、ダブルクォーテーションで囲まれた列内にカンマ記号が含まれていた場合にデリミター判定にならないように微修正しておきました。よければ更新してみてください。
| yuko | 返信 -
>> Kuroさん
kiyohiroさんが「CSVのカーソル位置の列を削除」マクロについて触れられていたので、1つ許可してほしいことがあります。
それは、昔Kuroさんが作られた下記のCSV関連のマクロがあります。
それで、上記2つをマクロライブラリに再掲載して良いでしょうか？
| MSY-07 | 返信 -
>> yuko さん
> うーむ、なるほど確かに…🤔
まだまだ諦めませんよ！w さらなる高速化、がんばりますー👍
> なんと！鬼車のみの記法を使ってしまっていましたか。
kiyohiro さんの環境でもちゃんと動いていたみたいなので、もしかしてみなさん意外と鬼車を使ってたりするんですかね。
> 正規表現ではなく「パースして必要な位置を割り出し、マルチカーソルを必要数追加する方法」じゃないとダメなんだろうなぁと思い知らされたところです。
なるほど。そう言われてからソースコードを眺めてみたら、確かに…。[すべて検索] であの仕組みを実現してたのは、もうすごすぎます😅
> どうやら [^,]* あたりが、改行まで検索ヒットしてしまっているようなんですよね。
ほんとですね。試しに
[^,]*で普通に検索してみたら、改行文字にもヒットしてました…。Mery の正規表現は、他のエディターと違って改行をいくらでもまたげちゃうので、便利だけど、特定のケースでは激重になったり、最悪フリーズも…😅。強力すぎるのも困りものですね。
一応、
[^,\n]*みたいに改行を除外するかたちにするとちょっとだけ速くなるみたいですが、それでもどこかで改行をまたいでそうな気配…。難しいですね。> なのでやっぱり、 selection.Find(); を使わない方式で再考してみないと、どこかで予期せぬ挙動をしてしまいそうです。
正規表現だけで実現するのはやっぱりハードル高そうですね。でも、発想が面白くてすごく興味深いです🤔
>> MSY-07 さん
> それは、昔Kuroさんが作られた下記のCSV関連のマクロがあります。
> CSV のカーソル位置の列を削除
> 可変長を固定長に変換
> それで、上記2つをマクロライブラリに再掲載して良いでしょうか？あ〜、懐かしいですね！でも、最近の Mery で動くかわからないですし、今後メンテナンスする予定もないので、それはちょっと難しいかなと思います。
とはいえ、すでに破棄したものなので、著作権は放棄します。
私の名前やコピーライトを削除していただければ、動作確認やメンテナンスを MSY-07 さんの名義でやっていただく分には全然 OK です。
| Kuro | 返信 -
>> Kuroさん
> あ〜、懐かしいですね！でも、最近の Mery で動くかわからないですし、今後メンテナンスする予定もないので、それはちょっと難しいかなと思います。
>
> とはいえ、すでに破棄したものなので、著作権は放棄します。
>
> 私の名前やコピーライトを削除していただければ、動作確認やメンテナンスを MSY-07 さんの名義でやっていただく分には全然 OK です。Ver 3.7.9でマクロの動作確認をしましたが、2つとも動作しました。
それで、これは眠らせておくのはもったいないので、言われた通りKuroさんの名前とコピーライトを削除して、私の名義でマクロライブラリに掲載しました。
| MSY-07 | 返信 -
>> Kuroさん
>なんと！鬼車のみの記法を使ってしまっていましたか。
>kiyohiro さんの環境でもちゃんと動いていたみたいなので、もしかしてみなさん意外と鬼車を使ってたりするんですかね。
正規表現、自分ではよく分かってないので例丸パクリで使かったのが
鬼車だったのでチェックしてました
確かにアンチェックだと動きませんね>> yuko さん
>微修正しておきました。よければ更新してみてください。
ありがとうございます。差し替えます>> MSY-07 さん
>Ver 3.7.9でマクロの動作確認をしましたが、2つとも動作しました。
CSV のカーソル位置の列を削除は
こちらでも普段から使ってるので問題ないと思います| kiyohiro | 返信 -
>> MSY-07 さん
> それで、これは眠らせておくのはもったいないので、言われた通りKuroさんの名前とコピーライトを削除して、私の名義でマクロライブラリに掲載しました。
確認しました。特に問題ありませんでした。
ただ、昔の私が書いた JavaScript を見ると、
withを多用していて……今となってはちょっと怒られそうな書き方してるなぁって思いますね😅| Kuro | 返信 -
>> kiyohiroさん
お待たせしました。
あーじゃない、こーじゃないと試行錯誤していたら、なかなかの文量のマクロになってしまいました…。Excelからコピーして貼り付けたTSV形式や、一部のCSVでは「ダブルクォーテーションで囲まれた範囲内では区切り文字や改行文字の入力を許容する」という仕様が見られることから、そのあたりになんとか対応してみました。
もし何か不具合が見られたらご指摘ください。こんな感じで、ダブルクォーテーション内の改行文字を考慮して選択できます:
https://imgur.com/a/varDeUE>> Kuroさん
> まだまだ諦めませんよ！w さらなる高速化、がんばりますー👍
おおっ、期待を込めて楽しみ & 応援しておきます😉
デフォルトの編集モード「Text」に、引用文でよく使う「> 」から始まる行を色付けする簡単な正規表現を入れていたりするのですが、このStrictモード搭載により折り返し3行目以降もちゃんと色がつくようになり、やっぱり使い勝手いいなぁと良さをしみじみ感じています。
> 正規表現だけで実現するのはやっぱりハードル高そうですね。でも、発想が面白くてすごく興味深いです🤔
「すべて検索」、マルチカーソルが爆速で設定されるので気に入っているんですよね😊
前述のとおり、実装を大改造して (初期の面影はマクロ起動時のコンテキストメニューくらい…) マルチカーソルの個別追加でなんとか対応してみましたが、
selection.AddPos()を何回も実行するのでそこで処理時間がかかってしまいますね…😅数千箇所の選択ともなると、なかなかの実行時間です。| yuko | 返信 -
>> yuko さん
> おおっ、期待を込めて楽しみ & 応援しておきます😉
> デフォルトの編集モード「Text」に、引用文でよく使う「> 」から始まる行を色付けする簡単な正規表現を入れていたりするのですが、このStrictモード搭載により折り返し3行目以降もちゃんと色がつくようになり、やっぱり使い勝手いいなぁと良さをしみじみ感じています。ありがとうございます！まだ試行錯誤中ですが、ちょっとした手応えを感じているので、もう少し調整を続けてみます。
また後日になりますが、このスレッドで Ver 3.7.9.1 (検証用) をこっそりリリースさせていただけたらと考えています。その際は、ぜひ検証にご協力いただけると助かります😊
> selection.AddPos() を何回も実行するのでそこで処理時間がかかってしまいますね…😅数千箇所の選択ともなると、なかなかの実行時間です。
新しいマクロ、早速試させていただきました。ダブルクォーテーション内の改行を考慮されているのはすごすぎます😱
なるほど、確かに
selection.AddPos()が処理のボトルネックになっているようですね。マクロから大量のカーソル追加は想定していなかったのですが、こちらについても高速化の余地がないか調べてみますね。
| Kuro | 返信 -
>> Kuroさん
> ただ、昔の私が書いた JavaScript を見ると、
withを多用していて……今となってはちょっと怒られそうな書き方してるなぁって思いますね😅とりあえず2つとも
withを使用しないソースコードに修正しておきました。| MSY-07 | 返信 -
>> yuko さん
構文ファイルcsv-tsvに質問お願いします
改行した""の色ですが
途中にあるのは色が付きますが
最終行だと付かないのは仕様ですか?
https://imgur.com/ihUzkQW
> お待たせしました。
> あーじゃない、こーじゃないと試行錯誤していたら、なかなかの文量のマクロになってしまいました…。
CSV/TSVでアクティブ列選択、更新しましたありがとうございます
こちらは最終行も選択されてますねあと黒ベース(RGB( 42, 42, 36) #2A2A24)だと色の反転でabc辺りが似た色になり若干見にくいし
h辺り文字背景に色がつくのでプロパティから自身で調整するとして
文字背景に色がつくのを避けると黒だと7色白だと6色なんですね
どれが見やすいか配色(1435276、1234567)悩みます
yukoさんの参考画像黒かったような気がして覗くと
> https://imgur.com/a/YKwU1wT
8色
> https://imgur.com/a/FvP1pRE
6色
でこちらと同じ色では無いし難しい| kiyohiro | 返信 -
>> yuko さん
> また、構文ファイル「CSV」ですが、ダブルクォーテーションで囲まれた列内にカンマ記号が含まれていた場合にデリミター判定にならないように微修正しておきました。よければ更新してみてください。
遅ればせながら使ってみました。
こういうのがあると、限界に挑戦したくなるもので....
CSVは44列
TSVは39列
で限界のようで、それ以降は着色されなくなりますね。
鬼車丸投げとのことなので、そっちで限界なのかもしれません。| pizz | 返信 -
>> Kuroさん
> また後日になりますが、このスレッドで Ver 3.7.9.1 (検証用) をこっそりリリースさせていただけたらと考えています。その際は、ぜひ検証にご協力いただけると助かります😊
おおっ、是非是非。楽しみにしています。
> マクロから大量のカーソル追加は想定していなかったのですが、こちらについても高速化の余地がないか調べてみますね。
ありがとうございます！大量マルチカーソル追加、意外と応用の幅が広いのではと思っており (今のところ、このマクロ以外にアイデアはまだ無いのですが)、改善されたら嬉しいです😊
>> kiyohiroさん
> 改行した""の色ですが
> 途中にあるのは色が付きますが
> 最終行だと付かないのは仕様ですか?編集モード「CSV/TSV」では、残念ながら改行込みのフィールドは非対応な仕様になっています。(正規表現だけでは行をまたぐようなフィールドを完全に判定するのが難しく…😓)
また文中か文末かで「llll"」の着色具合が変わってくる点は、ダブルクォーテーションの有無というより、強調文字列の検索仕様における挙動に見えますね。
> テキストエディター「Mery」ベータ版 Ver 3.7.9 を公開
> 強調文字列やマーカーの正規表現で、論理行単位の色分けに対応する隠しオプションを追加
> [正規表現モード] オプションは、Mery.iniでDisplayセクションのRegExMode項目で設定できます。Meryデフォルトだと上記の
RegExMode=0: Legacy モード (デフォルト)というモードで動きますが、このモードでは前方後方を一部含んで色が着きますので、そのあたりの仕様が関係していそうです。
色が着いたり着かなかったり、というのも気持ち悪いので、このへんの動作が一定になるように編集モード「CSV/TSV」を修正しますね (修正内容は後述)。どうしても正規表現でできる領域での対応なので、「改行込みフィールドには非対応。改行を挟んでしまうと意図せぬカラーリングになってしまう」という仕様だとご理解いただければと思います。
ただし、マクロ「CSV/TSVでアクティブ列選択」については正規表現に頼らずにプログラムで構文解析をしてますので、この制限は克服できているつもりです。
> どれが見やすいか配色(1435276、1234567)悩みます
配色テーマといえば、Kuroさんが面白い特集ページを作ってくださっているので、ここからダウンロード & インポートして試してみるのもいいかもですよ。
ページ上部のメニューから「人気」順にしてみますとダウンロード順表示となり、他のテキストエディターにも搭載されているような定番テーマが上位に並んで来きます。定番なものほど判読性が良かったり目に優しい色使いになっており、定番化するものにはやっぱり理由があるってことなんだなぁと楽しく見ています。ちなみに私は OceanicNext, Materia あたりを気に入って使っています。
>> pizzさん
試していただいてありがとうございます！
> CSVは44列
> TSVは39列仕様上は、いずれも「40列まで対応」としています。これは通常扱われるCSVで十分っぽい列数と、強調表示での検索量を鑑みてざっくりと決めています。
なので、41列目以降は標準文字色になる想定です。ちゃんと公開ページにも仕様として記載した方がよかったですね😅なので、pizzさん環境の表示で列数に上記のようなズレがあるのは、もしかすると前述の
RegExMode=0: Legacy モード (デフォルト)の影響かもしれません…。
対処として、仕様に厳密になるように改行文字をまたがないように修正を加えようと思います。
上記の頂いた状況を鑑みて、編集モード「CSV/TSV」を修正してみました。
- CSV/TSV 両方:
RegExModeの設定値によって動作が (できるだけ) ブレないように、1フィールドとして扱う範囲に改行文字を許容しないように調整しました - TSV のみ: CSVと同様にダブルクォーテーション囲み内のデリミター記号 (タブ記号) を許容するようにしました
| yuko | 返信 - CSV/TSV 両方:
-
>> Kuroさん
編集モードのエクスポート機能で、エクスポート後のファイルではハイライトの挙動が変わってしまう事象を発見してしまったので、こちらでご報告です。
再現手順:
- 編集モード「CSV/TSV」いずれかをインポート
- インポート直後、エクスポートする
- エクスポートしたファイルでインポートする
エクスポート機能では構文毎のチェックボックス状態が同じものを一括りにして設定ファイルの容量を減らしてくれるようですが、この機能と「CSV/TSV」の相性が悪いようです。これは、一括りになることによって構文の順序が元と変わってしまうことに起因しています。
「CSV/TSV」では「Meryの強調表示ではCSSのようにファーストマッチが優先される仕様」を利用しており、下図のように「ハイライト範囲を重複させつつ、構文の有効順序によって適用範囲を調整」という力技をしているので、構文の順序が変わってしまうとこれが崩れてしまうのですよね…😅
https://imgur.com/a/KEJfXyR| yuko | 返信 -
>> yuko さん
>編集モード「CSV/TSV」では、残念ながら改行込みのフィールドは非対応な仕様になっています。(正規表現だけでは行をまたぐようなフィールドを完全に判定するのが難しく…😓)
>また文中か文末かで「llll"」の着色具合が変わってくる点は、ダブルクォーテーションの有無というより、強調文字列の検索仕様における挙動に見えますね。
>どうしても正規表現でできる領域での対応なので、「改行込みフィールドには非対応。改行を挟んでしまうと意図せぬカラーリングになってしまう」という仕様だとご理解いただければと思います。
>ただし、マクロ「CSV/TSVでアクティブ列選択」については正規表現に頼らずにプログラムで構文解析をしてますので、この制限は克服できているつもりです。なるほど分かりました
ダブルクォーテーションの改行がCSVの作法で正しいかわからないのですが
テストで試した
年賀状ソフトの住所録のエクスポートしたCSVがこうなってまして
あれ、CSV44列オーバーでもないのに一番下が白いので他に何かあるのかと質問でした>上記の頂いた状況を鑑みて、編集モード「CSV/TSV」を修正してみました。
ありがとうございます
途中も最後も色がつかず
これなら白が新しい色として見分けが付き良いですね
https://imgur.com/bFO0nCx
文字の配色はこれから考えます>配色テーマといえば、Kuroさんが面白い特集ページを作ってくださっているので、ここからダウンロード & インポートして試してみるのもいいかもですよ。
>ちなみに私は OceanicNext, Materia あたりを気に入って使っています。
提案ありがとうございます
こちらはプロ生ちゃんエディション v2.8.2からのバージョンアップしてるので
Monokai(変更)ですね、ずっとこれなので代えがたいです| kiyohiro | 返信 -
>> kiyohiroさん
> 途中も最後も色がつかず
> これなら白が新しい色として見分けが付き良いですね念のため追記ですが…
白文字になっているのは「その行にカンマが無く、CSVと判定されていないから」という状況のためです。なので、最終列で改行が含まれているケースでは白くなって分かりやすいかもしれませんが (下図 (2))、途中列で改行が含まれているケースでは改行後の行が通常のCSV行として判定されるため (下図 (3)) 、注意が必要です。
https://imgur.com/a/Cynddei| yuko | 返信 -
>> yuko さん
> なので、41列目以降は標準文字色になる想定です。ちゃんと公開ページにも仕様として記載した方がよかったですね😅
> なので、pizzさん環境の表示で列数に上記のようなズレがあるのは、もしかすると前述の `RegExMode=0: Legacy モード (デフォルト)` の影響かもしれません…。わかりづらくてすみません、構文定義を編集して列数を増やして、どこまで行けるのかを試した結果のご報告でした。
列数をもっと行きたい人もいるだろーなーって感じでした。
RegExModeは速攻変更済みですw>> kiyohiroさん
yukoさんもテーマの紹介をしていますが、強調表示1～8は「オプション」「表示」で変更できます。
ただ、ここを変更すると他の構文定義にも影響するので、他の定義が思わずカラフルになってしまうのでご注意ください。| pizz | 返信 -
>> pizzさん
> RegExModeは速攻変更済みですw
これは失礼しました。このオプションを利用する方ということで、「あ、これはそういうの好きな人だ」と察しましたｗ
> わかりづらくてすみません、構文定義を編集して列数を増やして、どこまで行けるのかを試した結果のご報告でした。
ありがとうございます。
環境差があるのか分かりませんが、手元で「tsv.msy」を1000列目まで拡張してみたところ、ちゃんと色が付きましたね。流石にカーソル移動がガクガクになってしまい、実用には耐えませんが…
https://imgur.com/a/zdVDl1w| yuko | 返信 -
>> yukoさん
>> kiyohiroさん> ダブルクォーテーションの改行がCSVの作法で正しいかわからないのですが
CSVの書式については、一応RFCで規定されています(推奨扱いですが...)
CSVファイルの一般的書式 (RFC4180 日本語訳)
https://www.kasai.fm/wiki/rfc4180jp・禁止文字(カンマ、ダブルクォーテーション、改行)を扱うときはダブルクォーテーションでくくる
(括られた範囲内では禁止文字としての効果を失う)
・文字列にダブルクォーテーションが含まれる場合は二重にしてエスケープする| pizz | 返信 -
>> yuko さん
ありがとうございます。
おや、できるんですね。
ちょっと自分の環境から見直して、出直してきます。| pizz | 返信 -
>> yuko さん
>念のため追記ですが…
>白文字になっているのは「その行にカンマが無く、CSVと判定されていないから」という状況のためです。
>なので、最終列で改行が含まれているケースでは白くなって分かりやすいかもしれませんが (下図 (2))、途中列で改行が含まれているケースでは改行後の行が通常のCSV行として判定されるため (下図 (3)) 、注意が必要です。
分かりました
説明ありがとうございます。気をつけます。>> pizzさん
>yukoさんもテーマの紹介をしていますが、強調表示1～8は「オプション」「表示」で変更できます。
>ただ、ここを変更すると他の構文定義にも影響するので、他の定義が思わずカラフルになってしまうのでご注意ください。
ここって他の構文定義全体でしたか
知りませんでした、まだテスト環境のMeryで事なきを得ました
ありがとうございました| kiyohiro | 返信 -
> >> yuko さん
すみません、鬼車ONになっていませんでした。
まぁ逆に鬼雲でもここまで行けるって検証できたかな...| pizz | 返信 -
>> pizzさん
> すみません、鬼車ONになっていませんでした。
おや、私も鬼車OFF (鬼雲利用) でさきほどの1000列キャプチャは取っていたんですよね.
ちなみに鬼車ONでも同様に、1000列までハイライトされていました。なにが原因なんでしょうね…🤔
| yuko | 返信 -
>> yuko さん
なんか手作業で編集しているときにおかしくしてしまったようです。
めんどくさくなったので、プログラムでがーっと書き出したmsyファイルを取り込んだらうまく動くようになりました。
おさわがせしてすみません💦前にも出ていますが、msyファイルの仕様が色優先なので、いろいろありそうですね
| pizz | 返信 -
>> MSY-07 さん
> とりあえず2つともwithを使用しないソースコードに修正しておきました。
ありがとうございます。私のほうでも「バイト数」マクロで
withを使用しないように修正しておきました。>> yuko さん、pizz さん
ご報告ありがとうございます。
> 編集モードのエクスポート機能で、エクスポート後のファイルではハイライトの挙動が変わってしまう事象を発見してしまったので、こちらでご報告です。
現象、確認しました。
これ、昔は動作を速くするために、強調文字列のリストを内部でソートし直してたんですよね。だから順番は関係ない仕様だったんです。
Ver 3.3.2 以降で強調文字列の優先順位をサポートしたのですが、エクスポート時の順番はそのときの仕様のまま、うっかり見逃してました😅
次のバージョンでは対応しておきますね。
ちなみに、エクスポート/インポート時にファイル形式で CSV を選べば、この問題は起きないみたいです。
> なんか手作業で編集しているときにおかしくしてしまったようです。
手作業で編集したいときは、強調文字列リストをすべて選択 (Ctrl + A) → コピー (Ctrl + C) すると、TSV 形式でクリップボードに保存されます。
それをテキストエディターにペタッと貼り付けて編集すると簡単です。
編集が終わったらもう一回コピーして、強調文字列リストに貼り付け (Ctrl + V) すれば一発で反映できますよ。
もし前の内容がいらないなら、Ctrl + A ですべて選択、Del キーで削除してから貼り付けてください😊
| Kuro | 返信 -
>> pizzさん
対処できたようで、何よりです😀
>> Kuroさん
> 次のバージョンでは対応しておきますね。
ありがとうございます！
> ちなみに、エクスポート/インポート時にファイル形式で CSV を選べば、この問題は起きないみたいです。
な、なんと… CSVで出力できるの、知りませんでした…😮
> 手作業で編集したいときは、強調文字列リストをすべて選択 (Ctrl + A) → コピー (Ctrl + C) すると、TSV 形式でクリップボードに保存されます。
こ、これまた知りませんでした…😮
TSVでコピーできるとなると、横にExcelを開いてペタペタとインスタントに編集できてしまうわけですね。なんと便利な。
CSV/TSV 編集モード、作る際の検証素材が実は近くに転がっていたというわけですねｗ
実際、これでダブルクォーテーション内のダブルクォーテーション (2つ繋ぎ) が色分けで考慮できていないことが分かりました。なんとか対処したいですね…。| yuko | 返信 -
> 実際、これでダブルクォーテーション内のダブルクォーテーション (2つ繋ぎ) が色分けで考慮できていないことが分かりました。なんとか対処したいですね…。
編集モード「CSV/TSV」にて、ダブルクォーテーション内のエスケープされたダブルクォーテーション (2つ繋ぎ) を許容する対応ができましたので更新。
CSV/TSV - MeryWiki合わせて、「CSV/TSVでアクティブ列選択」マクロでもダブルクォーテーション内でのエスケープされたダブルクォーテーションを考慮するように修正しました。
CSV/TSVでアクティブ列選択 - MeryWiki都度都度修正な感じで申し訳ないです…😅
| yuko | 返信 -
>> Kuroさん
> ちなみに、エクスポート/インポート時にファイル形式で CSV を選べば、この問題は起きないみたいです。
初めてCSVでの編集モード エクスポート/インポートを扱ったがゆえなのですが、インポート時のファイル選択画面でCSVファイルが表示されず、「あれれ？もしかして *.csv は利用できない？」ってなりまして。でもそれは単に、ファイル種別が選択制だったことで見えなかっただけなのでした…😅
一度分かってしまえば特段大きな問題はないものの、もし不都合がないのでしたら、インポート時のファイル選択画面で
*.msy*.csv両方が一覧に表示される状態にしておくと分かりやすいかと思ったのですが、いかがでしょう？
https://imgur.com/a/gsCDWpm| yuko | 返信 -
>> Kuroさん
> ありがとうございます。私のほうでも「バイト数」マクロで
withを使用しないように修正しておきました。ご対応ありがとうございます。
あと、私のほうでも追加で「文書から検索」マクロも
withを使用しないように修正しておきました。| MSY-07 | 返信 -
>> yuko さん
色々更新いただき、ありがとうございます！お疲れ様です。
> 一度分かってしまえば特段大きな問題はないものの、もし不都合がないのでしたら、インポート時のファイル選択画面で *.msy *.csv 両方が一覧に表示される状態にしておくと分かりやすいかと思ったのですが、いかがでしょう？
確かにそのほうが分かりやすいって方もいるかもしれませんね。
ただ、
*.msy形式と違って、*.csv形式は Mery 専用の形式ではなくて、どちらかというと汎用的なものじゃないですか。たとえば、
住所録.csvとかが一覧に混じっちゃうと、「なんでこれが出てくるの？」って思われそうな気もするんですよね。なので、普段は
*.msyだけ表示されてる方がスッキリしてて良いかなと…。(今は*.msy形式に問題があってご不便おかけしていますが😅)>> MSY-07 さん
> あと、私のほうでも追加で「文書から検索」マクロもwithを使用しないように修正しておきました。
修正ありがとうございます。
自分の投稿したマクロは一通りチェックしたつもりだったのですが、見落としていたようで…助かりました！😊
| Kuro | 返信 -
>> Kuroさん
> なので、普段は`*.msy`だけ表示されてる方がスッキリしてて良いかなと…。(今は`*.msy`形式に問題があってご不便おかけしていますが😅)
なるほど、エクスポート/インポートは基本的には *.msy 利用が操作もスムーズで推奨される雰囲気ですね。了解しました。
もう、あっという間に今年も最終日ですね〜。今年もMeryには、公私ともにお世話になりまくりでした。あと数時間で年越しですが、良いお年をお過ごしください🙂
| yuko | 返信
