2005/10/21 (金) 15:56:35 miau  
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
[4059] 「\r」が「\r\n」にマッチする件
http://sakura-editor.sourceforge.net/cgi-bin/cyclamen/cyclamen.cgi?log=data&tree=r4540
このスレッドで「\r」が「\r\n」にマッチするという問題が指摘されてますが、ちょっと処理を追ってみました。

sakura_2005-10-09 の CEditView_Command.cpp 7518 行目、7957 行目で、

// 置換後文字列への書き換え(行末から検索文字列末尾までの文字を除く)
Command_INSTEXT( FALSE, cRegexp.GetString(), cRegexp.GetStringLen() - colDiff, TRUE );

という処理を行い、選択部分の文字列を置換後のものに置き換えているようです。
ここで検索マッチ部分に「\r」が含まれる場合、直後で「\n」にマッチしていない状態であっても
「\r\n」までが選択されているのが原因のようです。

# どのように直せばいいのかわからないので大雑把な調査だけです。
# 間違っていたらすみません。

2005/10/21 (金) 21:47:56 かろと  
INCM1.23a
[4060] RE: 「\r」が「\r\n」にマッチする件
>タイトル: RE: 「\r」が「\r\n」にマッチする件
>発言者: miau
>http://sakura-editor.sourceforge.net/cgi-bin/cyclamen/cyclamen.cgi?log=data&tree=r4540
>このスレッドで「\r」が「\r\n」にマッチするという問題が指摘されてますが、ちょっと処理を追ってみました。
>
># どのように直せばいいのかわからないので大雑把な調査だけです。
># 間違っていたらすみません。


ありがとうございます。
最近、ほとんど掲示板見てなかったので気が付きませんでした。

バグを混入した張本人なので、修正します。m(__)m

2005/10/22 (土) 09:39:38 かろと  
INCM1.23a
[4061] RE: 「\r」が「\r\n」にマッチする件
>タイトル: RE: 「\r」が「\r\n」にマッチする件
>発言者: miau
>sakura_2005-10-09 の CEditView_Command.cpp 7518 行目、7957 行目で、
>
>// 置換後文字列への書き換え(行末から検索文字列末尾までの文字を除く)
>Command_INSTEXT( FALSE, cRegexp.GetString(), cRegexp.GetStringLen() - colDiff, TRUE );
>
>という処理を行い、選択部分の文字列を置換後のものに置き換えているようです。
>ここで検索マッチ部分に「\r」が含まれる場合、直後で「\n」にマッチしていない状態であっても
>「\r\n」までが選択されているのが原因のようです。


\rを、INSTEXTで置き換えようと思っても(というより、改行の途中を表現できない)、
\r\nを置き換えてしまうので、結果的に \n が欠けてしまっていたようです。

改行の途中なら、行末まで(\nも含めて) INSTEXTで置き換えてしまうように修正しました。


diff --dos -ur -x CVS -x tags -x sakura_rc.aps -x *.obj -x *.RES -x *.rc sakura_core_old/CEditView_Command.cpp sakura_core/CEditView_Command.cpp
--- sakura_core_old/CEditView_Command.cpp        Sun Oct 02 14:38:05 2005
+++ sakura_core/CEditView_Command.cpp        Sat Oct 22 09:32:58 2005
@@ -7514,6 +7514,10 @@
                                 }
                                 // 行末から検索文字列末尾までの文字数
                                 int colDiff = nLen - nIdxTo;
+                                if (colDiff < pcLayout->m_pCDocLine->m_cEol.GetLen()) {
+                                        // 改行にかかっていたら、行全体をINSTEXTする。
+                                        colDiff = 0;
+                                }
                                 // 置換後文字列への書き換え(行末から検索文字列末尾までの文字を除く)
                                 Command_INSTEXT( FALSE, cRegexp.GetString(), cRegexp.GetStringLen() - colDiff, TRUE );
                                 // To Here Jun. 6, 2005 かろと
@@ -7953,6 +7957,10 @@
                                 }
                                 // 行末から検索文字列末尾までの文字数
                                 int colDiff =  nLen - nIdxTo;
+                                if (colDiff < pcLayout->m_pCDocLine->m_cEol.GetLen()) {
+                                        // 改行にかかっていたら、行全体をINSTEXTする。
+                                        colDiff = 0;
+                                }
                                 // 置換後文字列への書き換え(行末から検索文字列末尾までの文字を除く)
                                 Command_INSTEXT( FALSE, cRegexp.GetString(), cRegexp.GetStringLen() - colDiff, TRUE );
                                 // To Here Jun. 6, 2005 かろと

2005/10/22 (土) 12:01:00 ryoji  
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50215)
[4062] Re2: 「\r」が「\r\n」にマッチする件
\r\n改行の行に対する、\n単独での置換がまだちょっと変ですかね?
・置換後の文字を空にすると何も置換されない
・空以外だと一行おきに処理される(処理される箇所も\nは残ったまま)

みたいです...

2005/10/22 (土) 17:20:40 かろと  
INCM1.23a
[4063] Re3: 「\r」が「\r\n」にマッチする件
>タイトル: Re3: 「\r」が「\r\n」にマッチする件
>発言者: ryoji
>\r\n改行の行に対する、\n単独での置換がまだちょっと変ですかね?
>・置換後の文字を空にすると何も置換されない
>・空以外だと一行おきに処理される(処理される箇所も\nは残ったまま)
>みたいです...


なんだか、過去のバージョンでも似たような感じですね・・
こいつは手強い感が漂います・・・

2005/10/23 (日) 23:05:36 かろと  
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
[4064] Re3: 「\n」の置換が動作不良
▼ ryojiさん
> \r\n改行の行に対する、\n単独での置換がまだちょっと変ですかね?
> ・置換後の文字を空にすると何も置換されない
> ・空以外だと一行おきに処理される(処理される箇所も\nは残ったまま)
> みたいです...


レイアウト行が改行文字を常に1文字で扱うので、
\r\n 改行で、\nだけにマッチすると、改行レイアウト位置での0文字マッチ?のような扱いとなり
Command_INSTEXTに失敗するようです。
レイアウト行の動作を変えるのは危険なので、
\nだけにマッチした場合に、改行文字全体(\r\n)にマッチしたように、
マッチ開始位置を調整してみました。
#ついでにコードの整理も

\n 置換はできるようになってますが、副作用もあるかもしれないので、
とりあえずテスト版とします。

実行形式:(1.5.7.2)
http://karoto.hp.infoseek.co.jp/Archive/sakura_20051023.lzh

差分(1.5.3.0):
http://karoto.hp.infoseek.co.jp/Archive/sakura_R1572_sabun.lzh


2005/10/24 (月) 01:58:16 ryoji  
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.12) Gecko/20050919 Firefox/1.0.7
[4065] Re4: 「\n」の置換が動作不良
▼ かろとさん
> \n 置換はできるようになってますが、副作用もあるかもしれないので、
> とりあえずテスト版とします。

ちょっと動かしてみました。
うまくいっている感じですね。(^^)
しかし...、今回のケースとはまた別のパターンで妙なところを見つけてしまいました。(--;
\rや\nを置換前文字として、[選択始点挿入]や[選択終点追加]を選択実行した場合の置換結果が...

以下、この辺りの扱いについて、1ユーザーとしての素朴な所感です。
実を言うと、私自身は元ファイルの\rとか\nを個別に意識して部分的に改変できる必要性はあまり感じていません。
ファイル内の改行コードが CRLF/CR/LF の何れであっても、内部的には全部\nとして保持するようにしてしまってもいいんじゃないか?って思います。(ファイルの文字コードが何であれ内部的にはSJISで扱うのと同じように)
出力するときは全部同じ改行コードになっても構わない、というか、そのほうがむしろ嬉しいくらいです。
改行コードの混在って、何か御利益があるのかなぁ?
上書き保存で、触ってもいない箇所が勝手に変わるのが気持ち悪いと思う人はいるかもしれないけれど...
改行コードの内部表現が\nに統一されていれば、
正規表現で .(ピリオド)が\rに一致して???とかいう話も無くなるだろうし、
マクロを書くときも(従来互換は別として)改行コードの区別は必要なくなるし、
開発側もプログラムがシンプルになって楽な気がするんだけどな...
他のテキストエディタはどうなのかな。

いや、まぁ、これまでの経緯をよく知らないので、たわごとのようなものかもしれませんが。(^^;

2005/10/24 (月) 06:19:28 miau  
Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
[4066] Re5: 「\n」の置換が動作不良
かろとさん、ご対応ありがとうございます。\r も \n も動作してます。
ryoji さんの仰るとおり

> \rや\nを置換前文字として、[選択始点挿入]や[選択終点追加]を選択実行した場合の置換結果が...

という問題はあるようですが・・・。

▼ ryojiさん
> 出力するときは全部同じ改行コードになっても構わない、というか、そのほうがむしろ嬉しいくらいです。

基本的に同意見です。Unix 用のコードを Windows に流用するときに、改行コードが混在してしまって面倒な思いをすることも多いので。
ただ、

> 改行コードの混在って、何か御利益があるのかなぁ?

ご利益を思いついてしまいました・・・。
他のアプリケーションからテキストを貼り付ける場合、

> 正規表現で .(ピリオド)が\rに一致して???とかいう話も無くなるだろうし、

これを実現するためには、貼り付けのタイミングで内部コードに置換してやる必要があると思います。
しかし、そうするとサクラエディタからテキストをコピーする際の改行コードが問題になりそうです。

○改行コードを \r\n にした場合
「Excel の内容をコピー→サクラエディタで編集→再度 Excel にペースト」という作業を結構行うのですが、
Excel で 1 セルに複数行を入れた場合、その区切り文字は \n である必要があります。
(\r\n になってしまうと、余計なゴミがついてしまいます)

○改行コードを \n にした場合
notepad への貼り付けの際に、変なことになってしまいます。

ということで、内部コードを \n にすると、困ることも多そうです。
保存のタイミングで置換されるのであれば、それほど問題はないとは思いますが・・・
個人的には「保存の際、改行コード混在時は処理を選べる」というのがベストです。

2005/10/24 (月) 22:36:42 かろと  
INCM1.23a
[4067] Re5: 「\n」の置換が動作不良
>タイトル: Re5: 「\n」の置換が動作不良
>発言者: ryoji
>しかし...、今回のケースとはまた別のパターンで妙なところを見つけてしまいました。(--;
>\rや\nを置換前文字として、[選択始点挿入]や[選択終点追加]を選択実行した場合の置換結果が...


あ〜、ここに副作用が出ますか・・
(正規表現が使えるのに、[選択始点挿入]や[選択終点追加]ってのも、要るの?と思ったりする)
(あ、1ユーザとしての素朴な疑問ですよ。これも。(笑))

>以下、この辺りの扱いについて、1ユーザーとしての素朴な所感です。
>実を言うと、私自身は元ファイルの\rとか\nを個別に意識して部分的に改変できる必要性はあまり感じていません。
>ファイル内の改行コードが CRLF/CR/LF の何れであっても、内部的には全部\nとして保持するようにしてしまってもいいんじゃないか?って思います。(ファイルの文字コードが何であれ内部的にはSJISで扱うのと同じように)


1ユーザとして同感です。いや、1開発者としても、そっちの方が簡単です。(笑)

ただ、サクラ以外は、恐らく改行コードを内部的には1つにしていると思われところを、
あえて、そうしない仕様を選んでいるのを、簡単に変えることは、私には出来ません。

>いや、まぁ、これまでの経緯をよく知らないので、たわごとのようなものかもしれませんが。(^^;

私も、ここ1〜2年しか知らないので、そこまで踏み込めません・・・

2005/10/25 (火) 00:07:02 maru  
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
[4068] Re6: 「\n」の置換が動作不良
'ここ1〜2年'をさかのぼると
http://sakura-editor.sourceforge.net/cgi-bin/cyclamen/cyclamen.cgi?ol=200504&tree=s4431#4431
http://sakura-editor.sourceforge.net/cgi-bin/cyclamen/cyclamen.cgi?ol=200412&tree=s4014#4014
な感じでした。

ところで、>>data:4014ってツリー構造が壊れているように見える。

2005/11/6 (日) 01:12:15 かろと  
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
[4091] Re6: 「\n」の置換が動作不良
▼ かろとさん
> >タイトル: Re5: 「\n」の置換が動作不良
> >発言者: ryoji
> >しかし...、今回のケースとはまた別のパターンで妙なところを見つけてしまいました。(--;
> >\rや\nを置換前文字として、[選択始点挿入]や[選択終点追加]を選択実行した場合の置換結果が...

>
> あ〜、ここに副作用が出ますか・・


副作用というより、前にも話題になったことある
dev:3942
の影響ですね。。。
というわけで、思いきって、そのあたりも見直してみました。

実行形式:(1.5.7.2)
http://karoto.hp.infoseek.co.jp/Archive/sakura_20051105.lzh

差分(1.5.7.2):
http://karoto.hp.infoseek.co.jp/Archive/sakura_R1572_1105.lzh

2005/11/6 (日) 10:34:28 ryoji  
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50215)
[4092] Re7: 「\n」の置換が動作不良
> というわけで、思いきって、そのあたりも見直してみました。

ご苦労さまでっす。(^^;;;
改行関連は改善されている感じですね。
でも、以前よりおかしくなっているところもあるみたいです。
-----------------
1998-2001
2000-2001
2001
2002
2003
2004-2005
-----------------
のようなテキストを全行選択し、
置換前:2
置換後:a
正規表現にチェック
置換対象:選択始点挿入
範囲:選択範囲
で全置換した場合に、9箇所置換されるはずが4箇所しか置換されませんでした。
#この例では正規表現を使う意味は無いですが、簡単な誤動作例ということで

2005/11/6 (日) 11:25:27 ryoji  
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.12) Gecko/20050919 Firefox/1.0.7
[4093] Re8: 「\n」の置換が動作不良
同じデータで、条件を一部変えた場合もおかしくなっています。
正規表現OFF
置換対象:選択終点追加
だと無限に置換が繰り返されるようです。

2005/11/6 (日) 22:53:37 かろと  
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
[4094] Re8: 「\n」の置換が動作不良
▼ ryojiさん
> でも、以前よりおかしくなっているところもあるみたいです。

チェックありがとうございます。

不要と思ったところ、削除しすぎてました・・・(^^;

実行形式:(1.5.7.2)
http://karoto.hp.infoseek.co.jp/Archive/sakura_20051106.lzh

差分(1.5.7.2):
http://karoto.hp.infoseek.co.jp/Archive/sakura_R1572_1106.lzh

2005/11/10 (木) 03:25:40 ryoji  
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.12) Gecko/20050919 Firefox/1.0.7
[4099] Re9: 「\n」の置換が動作不良
対応ありがとうございます。m(__)m
おかしくなっていたところも今回ので無くなっているようですね。
問題箇所を中心に、思いつきのパターンでいろいろ試した範囲ではうまくいってます。

最後に?、これはたぶん以前からだろうと思うのですが、どうやら選択範囲置換のときに選択が一部解除されてしまうことがあるんですね。
具体例で言うと、行選択状態で\r\nを空に変換して行を繋げると選択状態が解除されます。
これも何とかなると嬉しいんですが...

2005/11/10 (木) 07:13:56 かろと  
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
[4100] Re10: 「\n」の置換が動作不良
▼ ryojiさん
> 問題箇所を中心に、思いつきのパターンでいろいろ試した範囲ではうまくいってます。

毎度、確認ありがとうございます。m(__)m

差分を更新しておきました。
差分(1.5.8.0):
http://karoto.hp.infoseek.co.jp/Archive/sakura_R1580_1109.lzh

> 最後に?、これはたぶん以前からだろうと思うのですが、どうやら選択範囲置換のときに選択が一部解除されてしまうことがあるんですね。
> 具体例で言うと、行選択状態で\r\nを空に変換して行を繋げると選択状態が解除されます。
> これも何とかなると嬉しいんですが...


本当ですね。あまり選択範囲置換しないので全然知りませんでした。
乗りかかった舟?なので、時間あるときに見てみますね。(後は別スレで)

INCM/CMT
Cyclamen v3.81
[ut:0.020][st:0.010]