最短一致タグ付き正規表現の不具合 - 秀丸エディタβ版 - スレッド03106, 2003/09/26

最短一致タグ付き正規表現の不具合

あべのり さん　03/09/26 22:38

初めまして。

秀丸4.0βを使わせて頂いております。

\label{ab}{cd}{ef}
に対して、
検索 : \\label{\f.*?\f}{.*}
置換 : \\label{\1}
を正規表現ONで行うと置換結果が
\\labe{ab}{cd}
となります。(秀丸4.00β19,HMJRE.DLL V0.18)

.*?が最短一致であることから、
\label{ab}
に置換されるのが適当であると思われます。

ご確認のほどよろしくお願いします。

RE:03106 最短一致タグ付き正規表現の不具

秀まるお さん　03/09/26 23:14

　バグの症状確認しました。実は、ここの会議室の02973番発言にて報告いただ
いたバグを直す課程で、バグ対処したら逆にバグるケースが出るんじゃないかと
少々検討しつつも、そういうケースが想像できませんでいました。

　今回はまさにバグのケースを見つけていただきました。

　前回のバグ修正をしつつ、今回のバグにも対処する方法もわかりました。とい
うことで、次のバージョンにて修正させていただきます。

RE:03106 最短一致タグ付き正規表現の不具

アルビレオ さん　03/09/26 23:34

秀丸ユーザーのアルビレオです。

>\label{ab}{cd}{ef}
>に対して、
>検索 : \\label{\f.*?\f}{.*}
>置換 : \\label{\1}
>を正規表現ONで行うと置換結果が
>\\labe{ab}{cd}
>となります。(秀丸4.00β19,HMJRE.DLL V0.18)
>
>.*?が最短一致であることから、
>\label{ab}
>に置換されるのが適当であると思われます。

本題とは関係のないことですが、置換文字列では\が特別な意味を持つのは直後
に数字がくるときだけです。それ以外は\\と書く必要はありません。
だから
検索 : \\label{\f.*?\f}{.*}
置換 : \label{\1}
と書く必要があります。

RE:03109 最短一致タグ付き正規表現の不具

IKKI さん　03/09/27 14:15

IKKI です。さらに脇道に逸れますが…

> 本題とは関係のないことですが、置換文字列では\が特別な意味を持つのは直後
> に数字がくるときだけです。それ以外は\\と書く必要はありません。

\n, \t, \xnn は必要ですね。

ところで、エスケープシーケンスとして解釈されない余計な「\」を書いた場合は単
に無視されるようですが（たとえば「\A」→「A」など）、この動作は仕様として明
文化されているものでしょうか？
# 正規表現の検索文字列で余計な「\」を書くと「あいまい検索の文字単位での無効
化」として働くのかな？（使ったことないけど）

それと、話を脇道から戻しますが、

> 　前回のバグ修正をしつつ、今回のバグにも対処する方法もわかりました。とい
> うことで、次のバージョンにて修正させていただきます。

どのような方法で対処されたのか技術的に興味があります。よろしければ前回同様、
実装方法を簡単にご説明いただけると嬉しいです。 m(_ _)m

RE:03109 最短一致タグ付き正規表現の不具

あべのり さん　03/09/27 21:54

こんばんわ。あべのりです。

>本題とは関係のないことですが、置換文字列では\が特別な意味を持つのは直後
>に数字がくるときだけです。それ以外は\\と書く必要はありません。
>だから
>検索 : \\label{\f.*?\f}{.*}
>置換 : \label{\1}
>と書く必要があります。

実際にやってみると、
label{ab}{cd}
と置換され、意図したものと違ってしまいます。

RE:03113 最短一致タグ付き正規表現の不具

秀まるお さん　03/09/27 22:49

　区切り位置を確定させるには、とにかく可能性のある位置を全部洗い出す形に
なります。そのために、検索をしまくります。

　例えば(patternA)\f(patternB)となっていて、それに対してヒットした文字列
が1234と４文字だとすると、

　""についてpatternAをマッチング +"1234"についてpatternBをマッチング
　"1"についてpatternAをマッチング +"234"についてpatternBをマッチング
　"12"についてpatternAをマッチング +"34"についてpatternBをマッチング
　"123"についてpatternAをマッチング +"4"についてpatternBをマッチング
　"1234"についてpatternAをマッチング +""についてpatternBをマッチング

　のような処理をします。それで両方が全体にマッチする物を探し出します。

　ちなみに、patternA側の最後に最短一致指定があると大変まずいことになりま
すので、patternAの末尾の最短一致指定は取り去りさって処理します。

　今回のケースでは、最短一致を除去した関係で、条件に合う位置が２箇所出て
きます。普通は複数箇所にマッチした場合は一番後ろを採用しますが、patternA
の末尾が最短一致指定だった場合は一番前を採用するようにしました。それで直
ったと思います。

　ヒットする位置が見つからなかった場合は、patternAが"\n"にヒットするかど
うかという例外的処理も入っているようです。（詳細不明）

RE:03116 最短一致タグ付き正規表現の不具

アルビレオ さん　03/09/28 00:36

アルビレオです。

>>検索 : \\label{\f.*?\f}{.*}
>>置換 : \label{\1}
>>と書く必要があります。
>
>実際にやってみると、
>label{ab}{cd}
>と置換され、意図したものと違ってしまいます。

ほんとだ…実際に確認してから#03109を書いたんですが…
具体的にどういう文字列でテストしたのか覚えていません。
きっと勘違いがあったのでしょう。すみませんでした。

RE:03118 最短一致タグ付き正規表現の不具

IKKI さん　03/09/29 06:19

IKKI です。

これはどうも、ご丁寧な解説をいただき恐縮です。 \f の数が多いと大変なことにな
りそうですね。ややこしい正規表現を書くときは留意したいと思います。ありがとう
ございました。

別件ですが、強調表示で前方(一致|不一致)を多用すると描画が目に見えて遅くなる
ようです。(hidesoft.4:03883 / HmJre v0.18)
これは改善の見込みのあるものでしょうか、それとも本質的に不可避なものでしょう
か？

RE:03122 最短一致タグ付き正規表現の不具

秀まるお さん　03/09/29 13:47

> 別件ですが、強調表示で前方(一致|不一致)を多用すると描画が目に見えて遅くなる
> ようです。(hidesoft.4:03883 / HmJre v0.18)

　たぶん改善できます。試行錯誤してみます。

RE:03124 強調表示定義ファイルの1行の長

IKKI さん　03/09/29 14:47

IKKI です。

> > 別件ですが、強調表示で前方(一致|不一致)を多用すると描画が目に見えて遅くなる
> > ようです。(hidesoft.4:03883 / HmJre v0.18)
>
> 　たぶん改善できます。試行錯誤してみます。

わかりました。よろしくお願いいたします。

強調表示関連でもうひとつ、 .hilight ファイルには
「1行の長さ ≦ 202バイト」という物理的な制限があるようですね。

113,%r\[([^[\]]|\\[[\]])*(\[([^[\]]|\\[[\]])*\]([^[\]]|\\[[\]])*)*(\[([^[\]]
|\\[[\]])*(\[([^[\]]|\\[[\]])*\]([^[\]]|\\[[\]])*)*\]([^[\]]|\\[[\]])*(\[([^
[\]]|\\[[\]])*\]([^[\]]|\\[[\]])*)*)*\][iomxnesu]*

この行は正常に読み込めますが、パターンを1文字でも増やしたり
先頭に「//」を付けてコメント化しようとしたりすると、読み込み時に
「ファイルの中身が正しい形式になっていません」と言われます。

実用上さほど重大な問題ではないかもしれませんが、この制限に
引っかかってしまった者がいるということをご報告しておきます。

（秀丸V4β18）

RE:03125 強調表示定義ファイルの1行の長

秀まるお さん　03/09/29 15:55

　前方一致／前方不一致指定時の高速化に成功しました。元々の処理が手抜きだ
った訳ですけど。

　一応こちらでデバッガー配下でトレースして動作確認などしましたが、念のた
めテストして欲しいということで、早めにアップロードしました。

http://www.hidemaru.interlink.or.jp/software/bin/hmjre019.lzh

> 「1行の長さ ≦ 202バイト」という物理的な制限があるようですね。

　秀丸側でやってるようですが、たぶん、内部的なデータが256バイト以内に収
まるように、適当な所で制限をかけるのが、安全を見込んでたまたま200バイト
程度になってるんだと思います。240バイト程度には出来ると思うので、せめて
その程度にまで拡張してみます。（って、秀丸担当の範疇ですが、勝手にいじる
し）

RE:03126 最短一致タグ付き正規表現の不具

Iranoan さん　03/09/29 17:19

　秀まるおさん今日は、Iranoan です。
> 　前方一致／前方不一致指定時の高速化に成功しました。元々の処理が手抜きだ
> った訳ですけど。
　高速化の方はよく分かりませんが、
http://www.maruo.co.jp/turukame/3/x03106_.html#3106
に付いては変化がなかったことをお知らせしておきます。

RE:03130 最短一致タグ付き正規表現の不具

秀まるお さん　03/09/29 17:30

> http://www.maruo.co.jp/turukame/3/x03106_.html#3106
> に付いては変化がなかったことをお知らせしておきます。

　これはHmJreじゃなくて秀丸側の問題なので、秀丸が新しくならないと解決し
ないです。

RE:03131 最短一致タグ付き正規表現の不具

Iranoan さん　03/09/29 18:00

　秀まるおさん今日は、Iranoan です。
> 　これはHmJreじゃなくて秀丸側の問題なので、秀丸が新しくならないと解決し
> ないです。
　これは大変失礼しました。

RE:03126 前方一致／不一致の高速化

IKKI さん　03/09/29 20:52

IKKI です。

> 　前方一致／前方不一致指定時の高速化に成功しました。元々の処理が手抜きだ
> った訳ですけど。
>
> 　一応こちらでデバッガー配下でトレースして動作確認などしましたが、念のた
> めテストして欲しいということで、早めにアップロードしました。
>
> http://www.hidemaru.interlink.or.jp/software/bin/hmjre019.lzh

ありがとうございます。おかげさまで劇的に速くなりました。どのくらい劇的かとい
うと

　　　　　　　　　前方パターンが
　　　　　　　　　固定長の場合　　可変長の場合
　　HmJre v0.18　　　　1秒　　　　　60秒
　　HmJre v0.19　　　0.1秒　　　　　0.5秒

このくらいです。（下記のサンプルで1画面の描画にかかる時間の目安）
可変長の前方一致は Perl でも不可能だったと思います。これを実用的な速度で実現
できたのは素晴らしいです。恐れ入りました。 m(_ _)m

サンプルファイル：
　http://www18.big.or.jp/~fujiwara/ikki/temp/grep-regexp.rb
　http://www18.big.or.jp/~fujiwara/ikki/temp/lookbehind-fixed.hilight
　http://www18.big.or.jp/~fujiwara/ikki/temp/lookbehind-variable.hilight

RE:03126 強調表示定義ファイルの制限

IKKI さん　03/09/29 20:54

IKKI です。強調表示定義ファイルについて…

> > 「1行の長さ ≦ 202バイト」という物理的な制限があるようですね。
>
> 　秀丸側でやってるようですが、たぶん、内部的なデータが256バイト以内に収
> まるように、適当な所で制限をかけるのが、安全を見込んでたまたま200バイト
> 程度になってるんだと思います。240バイト程度には出来ると思うので、せめて
> その程度にまで拡張してみます。（って、秀丸担当の範疇ですが、勝手にいじる
> し）

わかりました。安全な範囲でお願いします。

ちなみに .hilight ファイルの1行目が空行だと「ファイルの中身が正しい形式にな
っていません」と言われるのは仕様だったでしょうか？

RE:03139 強調表示定義ファイルの制限

秀まるお さん　03/09/30 15:10

> ちなみに .hilight ファイルの1行目が空行だと「ファイルの中身が正しい形式にな
> っていません」と言われるのは仕様だったでしょうか？

　これはバグのようです。今直します。

RE:03149 強調表示定義ファイルの制限

IKKI さん　03/10/04 02:42

IKKI です。

すみません、強調表示ファイル関係でもうひとつ。
フラグに1桁の数値を指定するときは頭に0を付けないと読めないようです。
例えば「ugoo」を強調1に指定するには

1,ugoo

ではダメで

01,ugoo

と書く必要があります。これは仕様と理解してよろしいでしょうか？

> hilightファイルの先頭に空行があるとエラーが出るバグ修正
> 強調表示文字列の長さ制限を長くする
β20で確認しました。1行252バイトまで行けるようです。
ありがとうございました。

RE:03191 強調表示定義ファイルの制限

秀丸担当 さん　03/10/06 18:25

>すみません、強調表示ファイル関係でもうひとつ。
>フラグに1桁の数値を指定するときは頭に0を付けないと読めないようです。

２桁以上でないと認識しないようになっていました。
１桁でも認識できるように修正します。