私が公開しているスペル・チェック・マクロ (秀丸エディタ/メールに公式に連携アドインが公開されたので、このマクロ自体は 2018/03/31 現在は削除済みです) には、現在
\u???? によって Unicode 文字もスペル・チェック対象にする事が可能に (現在秀丸メールの β 版にしか同梱されていない HmJre.dll Ver.1.97 以上が必要)
の問題点がある。そして、更にこれと関係した問題を見つけてしまった。 (このマクロに関しては、何とか対処が出来そう→Ver.0.73)
現在新規のインストールの場合や、検索文字列を [全エンコード初期化] では、上記の拡張が働くものとして設定するようにしている。しかしこの設定だと、プロポーショナル・フォントを使っていると問題が発生する。
この原因については、別件も含めて秀丸エディタのサポート会議室に既に投稿済みだが、要点は「秀丸エディタのマクロの関数 strlen() 関数や message 文でユニコード文字を指定した場合、ウィンドウの表示フォントによって値/結果が異なることがある」というもの、現時点で私には、秀丸エディタの
バグと認められるのか?仕様なのか?
解らない。
現状では、
現時点では仕様ということになってしまうのですが、言われている通り、不都合 があることは理解でき、その通りだと思います。<中略>
互換性を考慮すると、いろいろ難しい問題がありそうです。
との事。「秀丸エディタは上位互換性を大切にする」というのが設計思想なので、致し方ない。またユーザが多いので、そうせざるえないだろう。
そうは言っても、ここで取り上げているマクロで問題がおきることには変わりが無いので、現状で可能な限りの対処をして、Ver.0.72 を公開した。しかし、行った対処方法では全ての環境・条件での動作は保証できない。(←2009/04/14 追記)
そこで、エラーが起きた場合の対処法を書いておく。
自分で検索文字列を設定しなおすプロポーショナル・フォントを使わない設定チェックが行われないけれど、aspell.mac 273 行目付近のstrlen( $$1 ) * 3 + 15 < 257 & //これは検索文字列が短いか? (←Ver.0.71 までの表記) ( strlen( $$1 ) - ##unichar_num * ( strlen( "\u100" ) == 2 ) ) * 3 + 15 < 257 & //これは検索文字列が短いか?をコメント・アウト (行頭に「//」を追加) して//strlen( $$1 ) * 3 + 15 < 257 & //これは検索文字列が短いか? (←Ver.0.71 までの表記例) //( strlen( $$1 ) - ##unichar_num * ( strlen( "\u100" ) == 2 ) // ) * 3 + 15 < 257 & //これは検索文字列が短いか?とするか、該当箇所を削除すれば、取り敢えず動く