強調表示定義ファイルの一行長さについてNo.08814
たまがわ さん 03/05/14 11:21
 
 いつもお世話になっています。
 強調表示定義ファイルをエディタで編集し、鶴亀メールの設定から読み込ませたの
ですが、一見正しく読み込めたように見えつつも、OKボタンを押したらエラー表示
が出て、そのエラー表示の内容が文字化けして読めないという状況が見られました。
その後、鶴亀を起動したり、メールエディタを起動したりするたびに、同じ文字化け
エラーが出、ときにはアプリケーションエラーで落ちるようになりました。(強調表
示をやめれば直ります)

 エラー自体は、調べてみたところ、どうやら定義ファイルの一行が長すぎたため
(正規表現で書いてあります)、鶴亀メールに取り込まれる際に半角200字ぐらい
のところでちぎられた結果、解釈不能に陥ったということのようです。

 試しに、秀丸エディタに同じ定義ファイルを設定しようとしてみたところ、「ファ
イルの形式が正しくない」というエラー表示とともに読み込みが阻止されたので、同
じような処理を鶴亀にも入れれば安全かと思います。(文字数制限を少し緩くして欲
しいという気もしてますが、秀丸との互換上難しいかもしれませんね)

 あと、これは要望ですが、鶴亀メールの設定で、強調表示の設定画面を開くたびに、
設定項目の表示順序が入れ替わってしまい、わかりにくいです。できれば、強調1、
強調2というように、ソートして表示してくれるとありがたいですが、ソートが無理
でも、表示順序は一定の方が望ましいように思います。

(windows xp pro sp1, TuruKame 2.78)

[ ]
RE:08814 強調表示定義ファイルの一行長さNo.08815
秀まるお さん 03/05/14 12:40
 
 まいどどうも。強調表示ファイルの読み込み処理は、たしかに秀丸と鶴亀とで
全然別でして、鶴亀側はほとんどチェックのような処理は入ってませんでした。

 いろいろ事情があって秀丸と共通には出来ませんが、とにかく修正させていた
だきます。

>  あと、これは要望ですが、鶴亀メールの設定で、強調表示の設定画面を開くたび
> に、
> 設定項目の表示順序が入れ替わってしまい、わかりにくいです。

 特に並べ替えしてるつもりは無いのでバグの可能性が高いです。もしかして並
べ替えしてるようなら修正させていただきます。

[ ]
RE:08815 強調表示定義ファイルの一行長さNo.08816
きいろいまふらあ さん 03/05/14 15:01
 
横からすみません。

>>  あと、これは要望ですが、鶴亀メールの設定で、強調表示の設定画面を開くたび
>> に、
>> 設定項目の表示順序が入れ替わってしまい、わかりにくいです。
>
> 特に並べ替えしてるつもりは無いのでバグの可能性が高いです。もしかして並
>べ替えしてるようなら修正させていただきます。

開くたびに昇順降順が逆になっているようです。
#記憶する順番と読み出す順番が逆なのかも。

ちなみに、秀丸の場合は「文字列」の項目でリアルタイムに(新規項目を追加し
た時点で)ソート?されているようですね。鶴亀の場合は、どんどん先頭に追加
されていくようです。

処理の優先順位は強調の種類で決まっていくはずですから、ここはもっぱら視認
性の問題だけだと思いますが……ちょっと気になりました。

自分は強調表示をそれほど多用していない(鶴亀では現状2項目のみ)のですが、
たくさん登録している人は「文字列」や「表示方法」でソートしたいことがある
かもしれませんね(要望してるわけではありません)。

項目を選択して[Delete]キーで削除されるのは仕様ですよね(念のため)。

[ ]
RE:08816 強調表示定義ファイルの一行長さNo.08817
秀まるお さん 03/05/14 16:46
 
> 開くたびに昇順降順が逆になっているようです。

 ソースコードを調べたら、つまり、秀丸ではリストビューのウィンドウスタイ
ルが「ソート」になっていて、鶴亀では「ソート無し」になっていて、C言語の
ソースコード上で同じ処理を動かしたら、たまたま逆順に並んでしまうようでし
た。

 なので、秀丸と同じ方式に修正させていただきます。

> 項目を選択して[Delete]キーで削除されるのは仕様ですよね(念のため)。

 問い合わせメッセージも無くさっくり削除されるようですが、秀丸も同じなの
で、仕様ってことにします。

[ ]
RE:08817 強調表示定義ファイルの一行長さNo.08831
たまがわ さん 03/05/19 16:52
 
秀まるおさん、こんにちは。

 強調表示設定の順番の件は、「入れ替わり」がなくなったことを確認しまし
た(鶴亀2.81で確認)。ありがとうございました。

 一方、一行が長い定義ファイルを読み込ませると、文字化けエラーが出る件
は引き続き発生します。レアケースということで、現状維持としたのかなとも
思いますが、一応ご報告しておきます。

[ ]
RE:08831 強調表示定義ファイルの一行長さNo.08832
秀まるお さん 03/05/19 17:04
 
>  一方、一行が長い定義ファイルを読み込ませると、文字化けエラーが出る件
> は引き続き発生します。

 一応、1行が長い場合は、「強調表示ファイルが壊れているようです。読み込
みを中止します」と出るはずでして、今テストした限りもそう出たんですけど…。

 もしかして、以前間違って読み込んだ状態を再現させて、それで死ぬというこ
となら、それは仕方がないです。読み込み処理しか直してませんので。例えば以
前おかしくなった時のレジストリをバックアップしてあって、それを復元してお
かしいってことなら仕方がないです。

[ ]
RE:08832 強調表示定義ファイルの一行長さNo.08833
たまがわ さん 03/05/19 20:07
 
秀まるおさん、こんばんは。

> >  一方、一行が長い定義ファイルを読み込ませると、文字化けエラーが出る件
> > は引き続き発生します。
>
>  一応、1行が長い場合は、「強調表示ファイルが壊れているようです。読み込
> みを中止します」と出るはずでして、今テストした限りもそう出たんですけど…。
>
>  もしかして、以前間違って読み込んだ状態を再現させて、それで死ぬというこ
> となら、それは仕方がないです。読み込み処理しか直してませんので。例えば以
> 前おかしくなった時のレジストリをバックアップしてあって、それを復元してお
> かしいってことなら仕方がないです。

 お手数をおかけして申し訳ありません。

 設定しようとしているのは、以下のような強調ファイルでして、「pochi> tama> m
ike>」みたいな形にも対応するように作った引用行色分け設定です。
 以前より、基本機能の着色を含めて3段階で常用していたんですが、今回5段階に
するため以下のようにしたところ、最後の一番長い行が読み込み時に途中でちぎられ
てしまうようです(設定画面で読み込み結果を確認した限りですので、違う理由かも
しれません)。
 他のパソコンで試しても残念ながら状況は変わりませんでした。
 ということで、現在はその行を消して4段階で使用しています。

81,^([0-9A-Za-zぁ-んァ-ヶ亜-K−ー]*| *)[>|>》|] *[0-9A-Za-zぁ-んァ-ヶ亜-
K−ー]*[>|>》|] *[0-9A-Za-zぁ-んァ-ヶ亜-K−ー]*[>|>》|].*
17,^([0-9A-Za-zぁ-んァ-ヶ亜-K−ー]*| *)[>|>》|] *[0-9A-Za-zぁ-んァ-ヶ亜-
K−ー]*[>|>》|].*
145,^([0-9A-Za-zぁ-んァ-ヶ亜-K−ー]*| *)[>|>》|] *[0-9A-Za-zぁ-んァ-ヶ亜-
K−ー]*[>|>》|] *[0-9A-Za-zぁ-んァ-ヶ亜-K−ー]*[>|>》|] *[0-9A-Za-zぁ-
んァ-ヶ亜-K−ー]*[>|>》|].*
209,^([0-9A-Za-zぁ-んァ-ヶ亜-K−ー]*| *)[>|>》|] *[0-9A-Za-zぁ-んァ-ヶ亜-
K−ー]*[>|>》|] *[0-9A-Za-zぁ-んァ-ヶ亜-K−ー]*[>|>》|] *[0-9A-Za-zぁ-
んァ-ヶ亜-K−ー]*[>|>》|] *[0-9A-Za-zぁ-んァ-ヶ亜-K−ー]*[>|>》|].*


(windows xp pro sp1, TuruKame 2.81)

[ ]
RE:08833 強調表示定義ファイルの一行長さNo.08834
アルビレオ さん 03/05/19 21:08
 
アルビレオです。

>81,^([0-9A-Za-zぁ-んァ-ヶ亜-K−ー]*| *)[>|>》|] *[0-9A-Za-zぁ-んァ-ヶ亜-
>K−ー]*[>|>》|] *[0-9A-Za-zぁ-んァ-ヶ亜-K−ー]*[>|>》|].*
>17,^([0-9A-Za-zぁ-んァ-ヶ亜-K−ー]*| *)[>|>》|] *[0-9A-Za-zぁ-んァ-ヶ亜-
>K−ー]*[>|>》|].*
>145,^([0-9A-Za-zぁ-んァ-ヶ亜-K−ー]*| *)[>|>》|] *[0-9A-Za-zぁ-んァ-ヶ亜-
>K−ー]*[>|>》|] *[0-9A-Za-zぁ-んァ-ヶ亜-K−ー]*[>|>》|] *[0-9A-Za-zぁ-
>んァ-ヶ亜-K−ー]*[>|>》|].*
>209,^([0-9A-Za-zぁ-んァ-ヶ亜-K−ー]*| *)[>|>》|] *[0-9A-Za-zぁ-んァ-ヶ亜-
>K−ー]*[>|>》|] *[0-9A-Za-zぁ-んァ-ヶ亜-K−ー]*[>|>》|] *[0-9A-Za-zぁ-
>んァ-ヶ亜-K−ー]*[>|>》|] *[0-9A-Za-zぁ-んァ-ヶ亜-K−ー]*[>|>》|].*

本題とは外れますが
[0-9A-Za-zぁ-んァ-ヶ亜-K−ー]
の部分は確かにこの記述が正しいわけですが、
[0-9A-zぁ-ヶ亜-K−ー]
という書き方なら実用上それほどは問題はないし、最後の行も185桁となるので
現状での回避策としては有効だと思うのですがいかがでしょうか?

[ ]
RE:08834 強調表示定義ファイルの一行長さNo.08835
たまがわ さん 03/05/19 21:36
 
アルビレオさん、こんばんは。まいど、ありがとうございます。

>本題とは外れますが
>[0-9A-Za-zぁ-んァ-ヶ亜-K−ー]
>の部分は確かにこの記述が正しいわけですが、
>[0-9A-zぁ-ヶ亜-K−ー]
>という書き方なら実用上それほどは問題はないし、最後の行も185桁となるので
>現状での回避策としては有効だと思うのですがいかがでしょうか?

 縮める手はいろいろ考えられますし、ご提案はなかなか結構なアイデアだと思いま
す。
 冗長だと感じられるかもしれませんが、ここでは、行が長いと文字化けエラーがで
たり落ちたりしますという話の具体例を示すことが目的ですので、そのようなトラブ
ルにいたる一つの例示と見てください。どの程度長いとおかしくなるのか(あるいは
どういう処理を含ませるとおかしくなるのか)といった視点でご検証いただければあ
りがたいです。

[ ]
RE:08835 強調表示定義ファイルの一行長さNo.08836
秀まるお さん 03/05/20 08:31
 
 これは、いわゆるJRE32.DLLのバグによって鶴亀メールおよび秀丸エディタの
動作がおかしくなる症状だと思います。

 具体的に以前報告があったのは以下のような強調表示定義です。この場合、1
行の長さが非常に長い行を作成しただけで鶴亀メールや秀丸エディタがおかしく
なります。

--> 動作不安定になった強調定義の内容 <-----------------------------
49,「+[^「|『|(|【|<|≪|≫|>|】|)|』|」]*
49,[^「|『|(|【|<|≪|≫|>|】|)|』|」]*」+
49,『+[^「|『|(|【|<|≪|≫|>|】|)|』|」]*
49,[^「|『|(|【|<|≪|≫|>|】|)|』|」]*』+
113,(+[^「|『|(|【|<|≪|≫|>|】|)|』|」]*
113,[^「|『|(|【|<|≪|≫|>|】|)|』|」]*)+
241,<+[^「|『|(|【|<|≪|≫|>|】|)|』|」]*
241,[^「|『|(|【|<|≪|≫|>|】|)|』|」]*>+
241,≪+[^「|『|(|【|<|≪|≫|>|】|)|』|」]*
241,[「|『|(|【|<|≪|≫|>|】|)|』|」]*≫+
177,【+[^「|『|(|【|<|≪|≫|>|】|)|』|」]*
177,[^「|『|(|【|<|≪|≫|>|】|)|』|」]*】+
-----------------------------------------------------------------

 実は今僕が秀丸エディタの過去のバグ修正もやっているんですが、このバグに
ついてはJRE32.DLL側がヒープを壊してしまうために、どうにも対応できないで
います。JRE32.DLLの作者の山田さんとも連絡が取れない状況だそうで、しいて
対応するならJRE32.DLL相当の物をサイトー企画で作り直すしか無いです。

 ということで、複雑な正規表現を強調表示に使うのは現状あきらめてもらうし
か無いです。

-----------
 誰か適当な正規表現ソースコードの所在が分かれば教えてください。

[ ]
RE:08836 強調表示定義ファイルの一行長さNo.08837
秀まるお さん 03/05/20 08:38
 
 ちなみに「*」が非常に長い行にヒットするとどうもダメらしいので、せめて、
正規表現最終部分にある「*」だけ鶴亀メール/秀丸側で例外的に処理させる手
もあるにはありますが…。

[ ]
RE:08837 強調表示定義ファイルの一行長さNo.08838
秀まるお さん 03/05/20 08:58
 
 っとコメントした矢先なんですが、「*」全般を秀丸側で処理するのは困難で
した。「.*」ならなんとか対応できますが、それだけではJRE32.DLLの誤動作を
防ぐことは出来なさそうです。

[ ]
RE:08836 強調表示定義ファイルの一行長さNo.08839
でるもんた さん 03/05/20 09:12
 
でるもんたです。

> 誰か適当な正規表現ソースコードの所在が分かれば教えてください。

1.
http://www.boost.org/ から regex で検索してください。
C++ 専用ですが、DLL 化して DLL を C アプリから呼び出すのは不可能では
なさそう。wchar_t を受け付けますが生のシフト JIS は絶望的。
ライセンスは BSD ライセンス風。

2.
http://www.pcre.org/
Perl 互換として名高いライブラリ。UTF-8 を受け付けますので、頑張って手を
入れればシフト JIS も通るようになるかも。

3.
http://www.gnu.org
ここに regex、Rx というライブラリがありますが、いずれも GPL です。
Lesser GPL(旧 Library GPL)ではないので、使用すると秀丸・鶴亀のソース
コードの全部公開を求められる可能性があり、お勧めできません。

こんなところでどうでしょう。

[ ]
RE:08839 強調表示定義ファイルの一行長さNo.08840
でるもんた さん 03/05/20 09:22
 
でるもんたです。

私の要望としては、UNICODE を通さずにシフト JIS での検索にも対応してほしいで
す。「JIS第二水準は強調表示」とか、シフト JIS で複数のコード位置が割り当てら
れているため一旦 UNICODE にしてしまうと区別できなくなる文字(0x87NN の一部と、
0xED40-EDFC、0xFA50-FA4C)の検索もしたいので…。

[ ]
RE:08837 強調表示定義ファイルの一行長さNo.08841
たまがわ さん 03/05/20 09:53
 
秀まるおさん、こんにちは。

>  実は今僕が秀丸エディタの過去のバグ修正もやっているんですが、このバグに
> ついてはJRE32.DLL側がヒープを壊してしまうために、どうにも対応できないで
> います。JRE32.DLLの作者の山田さんとも連絡が取れない状況だそうで、しいて
> 対応するならJRE32.DLL相当の物をサイトー企画で作り直すしか無いです。
>
>  ということで、複雑な正規表現を強調表示に使うのは現状あきらめてもらうし
> か無いです。

 JRE32.DLL側の問題でしたか……。分かりました。調査いただき、ありがと
うございました。

[ ]
RE:08840 強調表示定義ファイルの一行長さNo.08842
秀まるお さん 03/05/20 10:14
 
 情報ありがとうございます。やるとしたら当然ShiftJISで検索させるつもりで
す。

 どっちにしても大仕事になるには違いないので、ソースコードを拾いつつ勉強
しようかなぁと思います。

[ ]
RE:08841 強調表示定義ファイルの一行長さNo.08843
たまがわ さん 03/05/20 10:39
 
 あの…、念のためですが、「途中で切られてしまうぐらい長い行を持つ定義
ファイルが、エラーメッセージを出さずに読み込めてしまう」という状況は、
私の環境で引き続き見られます。

(あの定義ファイルを読み込ませ、設定の「文字列」を確認すると途中までし
  か表示されないので、読み込めつつ、切られているのかなと。また、これは
  鶴亀の保証外ですが、さっそくJRE32.DLLを他のものに置き換えるDLLを導入
  してあの定義ファイルを試したところ、「[]の対応がとれない」というエ
  ラーが出たので、内部的にも途中で切られているのかな、と想像しました。
  あくまで想像ですけど。)

[ ]
RE:08843 強調表示定義ファイルの一行長さNo.08847
秀まるお さん 03/05/20 16:58
 
 毎度お手数かけてすみません。強調表示の1行の制限を勘違いしてました。秀
丸では199文字で切ってるようです。

 てっきり255文字かと思って、それ以上の場合にエラーを出してました。

[ ]