最終更新: 2012-10-27T00:23+0900
その一(20090808p03)がだらだら長くなったのでいったん切って、ここに続ける。
ひどい。「/*」を入力して後ろの行がコメント色一色になったとする。つづけて「*/」を入力しても後ろの行がコメント色のまま。たぶんこれが関係する。
行をまたぐ色分けに問題があって、たとえば一画面に収まらない長大な複数行文字列があったとして、何度も上下にスクロールしたり改行を入力したりするだけで色分けが変わってしまっていた
本当にそうなら、泥縄式バグ潰し無間地獄へ突入ですな。消火行為が点火に直結した効率のいいマッチポンプだもん。
まさしく > たぶんこれが関係する。
そのときの変更にこんなコメントが添えられているのを発見した。「IsInsideKeyword()から呼ばれたときは精算したらダメっぽいのでコメントアウトして様子を見る。」様子見の結果はダメでした。さあ、どうしよう。
別の場所で不必要にキャッシュを無効化している部分を厳密に処理したら直ったっぽい。キャッシュの有無で結果が変わるはずないんだけど……。(さらなる追求が必要。でもそれは問題が見つかってからにする)
変わりうる。一行の色分けは一時(いちどき)に、他の行の色分けを挟んだりせずに終わらせなければいけない。正規表現キーワードは各行の行頭がどういう状態か(コメントの中か？とか)を覚えているキャッシュの他に、ある行を中間まで処理したマッチング結果を持っており、先ほどはこれをキャッシュと呼んでいた。そいつは、次の IsStartOfKeyword()呼び出しを待っている宙ぶらりんな状態。期待していた呼び出しがくる前にクリアされたら結果がおかしくなる。マッチングを中間で止めざるをえないのは、他の色分けに先食いされた文字をマッチに利用してしまわないように。
最終更新: 2011-01-02T16:45+0900
SAKURA Development BBS (ANSI)のログが 10ページ分しか閲覧できなくて、残念な思いをしていた。検索対象のリストに古い年月が存在していたり個別リンクが機能していたりするんだから、古いログが保存されているのは間違いないんだけど。Cyclamen(掲示板CGI)に関して言えば、記法のヘルプを見つけることもソースを見て記法を確認することもできない。ま、それはおいといて、
過去ログを見つけた。>http://groups.yahoo.co.jp/group/sakura-editor/files/User/bbs-log/
Subversionが最初からあった世代には考えられない開発スタイルがそこに！差分や変更したファイルを共有エリアに置いて掲示板で報告。大きな変更をした人が他の人の小さな変更をマージして最新版を管理したり。ともあれ、お宝ざくざくなので日曜日から喜々として読み進めている次第。(ログが 2007年9月で切れてるのが残念)
S:27,*,01/02/11,10:49,, T:横スクロール時の動作 N:げんた M: 現在のこのエディタはWM_HSCROLLが来たら横スクロール量を決定して画面全体を書き直す動作を行います。もし、画面全体を書き直す代わりに新規部分のみを書き直せば高速化すると思われるかも知れませんがそうはいきません。 なぜなら、このエディタは色分け情報をメモリ上に保持していないため、描画の都度行の先頭から調べて色を決定しているからです。その際キーワードの検索も行います。たぶん、これがかなりの処理を必要としているのだと思います。 横スクロール速度を劇的に改善しようと思ったら色分けを予め行ってその情報をメモリに保持するようにしないと難しいのではないでしょうか。
gdippを使っていると無視できないほどに強調されるので横スクロールが遅いことには気付いていた。これが書かれた当時のサクラエディタ(という名前ではまだないが)の遅さは今の PCスペックでは再現できないかもしれないけど、根は昔から存在していたよう。
S:114,*,01/03/02, 2:32,, T:コントロールプロセスの起動方法 N:げんた E:genta@i.am M: 外部エディタを監視するプログラムからテキストエディタを使うとき、エディタが常駐していないと起動したプロセスは管理プロセスとなってエディタ画面は別プロセスで動作するため、編集終了の検出が正しく行えない場合があります。 自分が管理プロセスになるのではなく管理プロセスを別に起動して起動完了まで待機するような作りにできればこの問題が解決できるなぁと思いました。
タブモード(実装者は別の人)であっても 1ドキュメント 1プロセスだから Subversionのコミットメッセージをサクラエディタで編集できるんだけど、そもそもこういうことが考慮されていたからこそできるのだと確認。
S:1446,1440,02/02/01,22:27,, T:Re2:正規表現置換の振舞い N:げんた M: >..*\n$ でやってみたら削除できましたけど…？？？ よく見たら自分で何気なく変えたところだった． 本当に申し訳ない． 今は普通に動いています． ただ，BREGEXPのせいなのか，^.*$ には先頭から改行コード \r\n の\rの部分までがヒットして\nが残ります． ^.*\n$ だと行全体にヒット．
「改行(.と$の動作に影響する)」= LF(0x0A)の指摘がこのとき既に。セルフリンク>20090922p01
S:1475,1474,02/02/05, 0:47,, T:Re4: タイプ別設定に外部ヘルプと外部HTMLヘルプ新設パッチ N:げんた M: ちょっと考え直してみました． ▼初期の私のアイディア ・CShareDataの役割＝単にDLL Sharedを得るためのクラス． ・タイプ別設定を共有メモリから追い出す． そのために，タイプ別設定のアクセスをCEditDoc::GetDocumentAttributeに集約． 追い出した後の実装はCEditDoc，またはCEditDocに含まれる新規クラスで行うつもりだった． 共有メモリからタイプ別設定を追い出したい理由は以下の通り． * タイプ別設定が足りなくなり，既に2回最大値を拡張している． * タイプ別設定の領域を予め共有メモリに確保しなくてはならないので，上限の撤廃ができない． * 初回起動時に使うかわからない領域全てを初期化するのは無駄ではないか． 追い出しのアイディア * タイプ別設定はそれぞれ外部ファイルに用意する． * 設定ファイルは必要に応じて読み込まれる． * 変更は現状通りダイアログボックスで行う． * 変更されたらすぐにファイルに保存し，設定変更Broadcastメッセージを投げる． * Broadcastを受け取ったら該当タイプを使用しているか確認． * 使用していたらファイルから再読込し，設定を更新する． >各種設定が共通設定だろうが、タイプ別設定だろうが、気にせずとりあえずCSettingMediatorに問い合わせたり、設定を依頼するだけでよくなったら便利だなぁと思っています。 なるほど．これは良いと思います．最終的には設定情報がどこに格納されているのかも意識する必要が無くなるので，これは私のアイディアと矛盾しません．CEditDoc::GetDocumentAttributeで取得するのをDLLSHAREからCSettingMediator経由に変更すればタイプ別設定のカプセル化の場所が移動します． 私の初期アイディアと組み合わせると，追い出した後の実装というのをCSettingMediatorに依頼することになるでしょう．タイプ一覧の設定，指定タイプの取得，更新などファイルへの書き出し・読み込みタイミングもCSettingMediatorが管理すれば良いような気がします． 上記内容を納得した上で私が確認した限りでは特に問題はないように思います． --- 実装に入る前に設計に対する議論を行うことは有意義だと思います．これまでは議論する相手がいなかったので...(;_;)
タイプ別設定を共有メモリから追い出すアイディアが既に出ていた。
設定の場所を隠蔽するクラスも構想されている。それのメリットとして自分が考えているのは、
の 3を、2との差分とすることで基本的な設定の共通化(基本設定による)を図りつつ、設定の読み出しを一本化できること。
S:1606,*,02/02/16, 2:26,,
T:ssrc_2002-02-11_p1
N:hor
M:
ssrc_2002-02-11 からの変更箇所です。ご参考まで。
(省略)
□その他のその他
・[Ctrl+Home]or[Ctrl+End]後に[Down]or[Up]したときの挙動を見直し・・・以下変更個所
１.矩形選択中に[Ctrl+Home]or[Ctrl+End]して[Down]or[Up]したとき以外は普通にカーソル移動
２.選択を解除したあとは普通にカーソル移動
(省略)
ファイルの先頭へ移動するコマンド(Ctrl+Home)が「通常は、(0, 0)へ移動。ボックス選択中は、(GetCaret().GetCaretLayoutPos().GetX2(), 0)へ移動」というコメント付きで故意におかしな動作をするのはこのへんが理由だったのか。(細かいことを言うと、このときの実装は Ctrl+Homeで 0行0桁に移動した後、↓で 1行(Ctrl+Home前の)X桁に移動する、というもので、いまの実装はすこし後にでてくる)。ファイルの先頭に移動という一つの名前に異なる機能を実装するのはやめて欲しい。利用者視点の「使える」動作なんだろうけど、自分なら Alt+Ctrl+Homeを「(矩形選択)ファイルの先頭行に移動(※未実装)」に割り当てるなどして対処する。
S:1759,*,02/03/23,11:01,, T:バックアップごみ箱問題 N:みく M: ネットワークドライブまたはリムーバブルドライブのファイルを ごみ箱に放り込むとOSの仕様により消滅してしまいます。 バックアップしたつもりがされてないという現象を避けるため、 これらのドライブの場合はごみ箱に放り込まないようにしました。 次回版にでも取り込んでください。 どうしてもごみ箱に放り込みたい場合は、 「指定のフォルダに作成する」でフォルダにローカルドライブのフォルダを 指定し、さらに「バックアップをごみ箱に放り込む」を指定してください。 （指定のフォルダにごみ箱を直接指定することはできません）
最近見かけたリムーバブルメディア上のファイルのバックアップをゴミ箱に放り込めない問題が 2002年に指摘されている。
自分はバックアップは Ctrl+Sに割り当てた JScriptマクロで Subversionに保存してる。差分バックアップでありながら過去の版を ViewVCで簡単に見られるのが利点。マクロでやってることのエッセンスは以下の通り。
>Editor.FileSave(); >svn up "working copy" >copy /Y /B "filepath" "working copy/filename" ); >svn add "working copy/filename" >svn commit "working copy/filename" -m "filepath" --force-log --non-interactive'
たかだかテキストファイルなので動画より小さく、ワーキングコピーもリポジトリも数百MiBにおさまってる。NTFSの圧縮属性を付けたらさらに三分の一にもなるし。
S:1980,*,02/04/30, 1:41,, T:半角スペース表示 N:KK M: KKです。 一般掲示板の方で要望のあった 「半角スペースの表示を追加する」 パッチを書いてみました。04-27版へのパッチです。 DispSpc04-27.zip (省略)S:1982,1980,02/04/30, 2:12,, T:Re:半角スペース表示 N:げんた M: 小文字のoの下半分だけを使うという発想が何とも独創的 (^^)
いまの Unicode版も同じ実装。気付かなかった (^^) ちなみに、デフォルトの色は灰色だけど、これをテキストと同じ色にすると周りと同じ色で描画されます(コメント中の空白とかが)。
空白記号類は特に明示指定した部分以外はなるべく周辺の指定に合わせるようにしてみた // 2009.05.30 ryoji
ソースを見てないと気づかなかった。
S:2237,*,02/07/03,12:22,, T:クラス、インターフェイスの整理 N:ボロぞうきん M: (省略) 1&2 1行の文字数が3万文字を超えてくると極端に遅くなるので、 行バッファを簡易gapped buffer方式に変更したかったけど、 内部のポインタを書き換え目的に使っている場所があり、 単純にconst化出来なかった。 (省略)
でました。gapped buffer
S:2278,*,02/08/23,20:29,, T:正規表現ライブラリ N:みく M: 比較的新しそうな正規表現ライブラリとして、 こんなのもあるみたいです。 http://www.fides.dti.ne.jp/~oka-t/libraries.html
S:2959,*,03/07/21, 3:35,, T:正規表現ライブラリの不具合 N:げんた M: http://www.fides.dti.ne.jp/~oka-t/history-2001.html でPerlの正規表現の不具合について触れられていた． 試してみると確かに ::1234::5678901234567890::::1234567890:: 888: に対して ^([0-9]+|::)*$ で検索するとフリーズする．（よい子は真似をしないでください） Perl 5.8ではフリーズしなかった．
リンク先が同じ。なんちゃってではなく真っ当な雰囲気がするなあ、と思いながらそのサイトをうろうろしていたら、未訪問のはずのリンクが何カ所も閲覧済みの色になっていることに気付いた。良いものは埋もれてしまわないのだ(忘れられるのは読み手(俺)の問題)。
S:2562,2559,03/02/11, 1:19,, T:Re: マルチユーザモード（案） N:もか M: ▼ みくさん >実行ファイル名を sakuram.exe とかに改名するとマルチユーザモードになり、 実行ファイル名を 任意の文字列1.exe などにすると文字コードがその数字の文字コード(この場合EUC-JPに)固定されるという機能があるから (省略)
なんぞそれ>「実行ファイル名を 任意の文字列1.exe などにすると」
S:3140,*,03/09/15,11:53,, T:色分けHTML出力 N:wmlhq M: 強調キーワードなどを使って色分けしたソースコードをsakuraでもHTML/XMLで出力できたら、便利だろうな。「形式を指定してコピー(special copy)」で実装するとか。 <font size=10><pre>//<nobr>comment</nobr> <font color="#576447">int</font> func(); </pre></font>
これは面白そう。もちろんフォーマットは
<style>
/*<![CDATA[*/
.comment { color: green; background-color: white; font-style: oblique; }
/*]]>*/
</style>
<span class="comment">//コメント</span>
にするけど。HTML直打ちに近いブログに投稿する以外に、正規表現キーワードによる色分けのデバッグにも使える。(思い通りの結果にならないときに、見た目では判断できない違いが classによって区別できる)
それにしてもこの wmlhq(自称)という人は……。掲示板の閲覧者はする～かが試されている(笑) 関わりたくはないけど知識とエネルギーは無視できないものがある。うまく操縦できる人がいればいいのかな。上から目線で仕切屋でイラッとする年寄り言葉を使ったりでこの人に指導される新人に同情するものの、悔しいかな、メッセージの国際化の手段に STRINGTABLE, MESSAGETABLE, gettextの三つを挙げたり、入力補完の高速化に bsearch, ハッシュ, dartsの三つを挙げたり、できないもんねえ。ちょっと前に WEB+DB PRESSで dartsっぽいのは見かけてたけども、わからなくて検索したし。
S:3300,3299,03/11/07,21:31,, T:BREGEXP.DLL N:かろと E:karoto@infoseek.jp M: ▼ もかさん > Perl Artistic License > "Freely Available" 内の 2.「バグ修正」か「移植」のための修正 > に該当しそうですが、どうでしょうか？ オリジナルのPerlの関数には、行頭から文字列を渡せるようになっていて、 BMatchEx()で、その引数にも値を渡せるようにしただけなので、 変更そのものは簡単なことで、「移植」なんて言うのもおこがましい程度です。 > 微妙に気になるのは、V1.0(VB未対応)で、Exportしてる関数が少ないのと、for SAKURA になってる... V1.0とV1.1の違いって、VB対応だったんですね・・知りませんでした。 Linux版のソースをもってきた関係上、VB対応部分は入ってませんでした。 というわけで、ExportしているVB用関数もありません。 Linuxソースなので、リソース関連のファイルは同梱されてなかったので、適当に作り、 本家のBREGEXPと異なることがわかりやすいように、「for SAKURA」ってのを入れました。（笑） まずいでしょうか？ > #いい感じだと欲が出てくるもので、 > #ついでに改行コード周りもDLL側でやってくれないかなぁ（実はやってる？) 実は、同じ事を考えて、内部の以前Perlの関数眺めたのですが、改行は１文字(\n)だと 決めて処理している箇所があり、難しそうだなぁと思いました。 > #UTF-16にも対応してくれないかなぁ ははは・・・さすがに対応済みのDLLを持ってきた方が早いかと・・
「改行は１文字(\n)」が「改行は１文字(\rの後ろではない\n, \r)」になるだけでも十分ではないのかなあ。
$ が行文字列末尾にマッチしたのは無視すべきだが、空パターン (?:) が改行文字の後ろにマッチしたのは無視すべきでない。果たして両者を区別できるのか？)調子に乗って hitEnd()に相当する機能を付けたら、複数行検索も
みたいにしてできるかも。複数行検索モードの実装が面倒くさい上に BREGEXP for SAKURA限定機能なので C/Pは悪い。
BREGEXP for SAKURAのマッチ仕様変更はこんなんで検出できる。
bool dot_matches_cr() // falseになっていることを確認する。テストは sフラグOFFで行われる。
{
BREGEXP* rxp = NULL;
const char* const szCR = "\r";
char szErrorMsg[80] = "";
const bool retval = 0 < BMatch("/./", szCR, szCR + 1, &rxp, szErrorMsg);
if(rxp != NULL) {
BRegfree(rxp);
}
return retval;
}
bool dollar_matches_before_cr() // trueになっていることを確認する。テストは mフラグONで行われる。
{
BREGEXP* rxp = NULL;
const char* const szCR = "\r";
char szErrorMsg[80] = "";
const bool retval = 0 < BMatch("/$/m", szCR, szCR + 1, &rxp, szErrorMsg) && rxp->startp[0] == szCR;
if(rxp != NULL) {
BRegfree(rxp);
}
return retval;
}
正規表現に関連して、ログからこんな URLも見つけ出してきた。
「COOLなURLは変わらない」ということを、リンク切れを発見するたびに思い出す。この二つの URLはもちろん今も有効。
S:3521,*,04/04/03, 0:28,, T:有効なカーソル位置の謎 N:もか M: あと、有効なカーソル位置ってどの範囲なのか、いまいちわかりません。 私が認識している動作は、フリーカーソルモードか、矩形選択中・終了後の位置としてEOFにまつわる位置だけに絞っても、 1. [EOF]だけの行(データの終端は改行)は行頭以外却下。 2. [EOF]だけのレイアウト行(データの終端は普通の文字)は行頭以外却下。 不思議なのは、レイアウト折り返し時はインデントされないし、カーソル座標表示も変かも。。 3. 普通の文字の後ろについた[EOF]より後ろ（正確には右側かつウィンドウ折り返し線より左側）は有効。 で次の行（EOFマークの次の行だから存在していない行）は不正。 あと、矩形選択で、折り返し位置にカーソルを移動しようとしても、行頭に飛ばされてしまって、最後の1文字が選択できません。 ただし、EOFの表示のみ折り返される場合は、選択できてしまいます。 選択できるようにすると、今度は、論理座標との双方向変換の1対1対応が保証されなくなるので、たぶんこまります。
後半はこれ(20091026p01)関連。なんかもう、ほとんどの問題は既出だという気がしてきた。その都度解決できていれば出てこないはずなのに……。
S:3752,*,04/09/27,17:34,, T:改行コードが食い違う N:もか M: 上書き保存したファイルとエディタが保持しているデータで、改行コードが異なることがあります。 1. 名前をつけて保存で、改行コードを変換する指定で保存 2. リロードされた後、入力改行コード指定により、1.で指定した改行コード以外を選択 3. 改行を入力 4. 上書き保存。このとき、2.で指定された改行コードで保存される この時点でリロードされないので、保存したファイルと、エディタ上のデータで食い違いが発生します。 同様に、Shift_JIS以外では、ファイルとエディタ上のデータで、実際には異なる(=リロードするとデータが変わる)ことがありますが、 こちらは下手にリロードすると、保存時に文字化けした場合は修正するチャンスを失うことになります。S:3753,3752,04/10/02,12:21,, T:Re: 改行コードが食い違う N:げんた M: 現象を確認しました． 要するに名前を付けて保存で指定したコード指定がその後の上書き保存でも生きているのが問題というわけですよね．そもそも保存時のコード指定がメンバ変数としてずっと保持されているのが不思議な気がします． でも改行コードなんか気にしないで，他の文書からコピーしたものを保存したときに常にコードが統一されて欲しいという人もいるかもしれない．かといって保存の都度reloadするのは無駄ですし． ・保存時のコード指定は保存しない ・毎回コードを指定して上書きしたい人はマクロで対応してもらう というのでいいように思います．
これなんかも、すでに自分で遭遇してる現象なんだけど、ずっと前に確認されていたってわけだ。
他にも、「アウトライン解析のプラグイン化」という語がログのごく初期に登場していたり、正規表現ライブラリが最初は jre32.dllであって、BREGEXP.DLLへは GPL化を目指したときに移行した*のだとか、sakura_core.dll(なにそれ？)だとか、正規表現のパターン区切りとして //k が入力必須で面倒だったり、//k を自動付加するようにしてみたけどまだ \ にエスケープが必要だから @ や % などパターン中に使われていない文字をセパレータにしてみたらどうか、とか(いつ 0xFFに決まったんだろう？)、意外な発見(とどこかで見たような問題が)がざっくざく。
* BREGEXPの Bは BASP21の Bと同じ BABAの Bのはずで、BASP21は WSHから利用できるオートメーションオブジェクトとして、JScript(最初に出会った記念すべきコンピュータ言語)をいじり始めた当時から有名だった(「それ、BASP21でできるよ」)から、BREGEXP"以前"が存在するとは思ってもいなかった。
最終更新: 2010-07-10T01:01+0900
hitEnd
public boolean hitEnd()
このマッチャーが行なった最前のマッチング操作によって、入力シーケンスの終わりに達していたら、trueを返します。
このメソッドがtrueを返したときは、さらに新たな入力を加えると最後のマッチの結果が変わる可能性があります。
requireEnd
public boolean requireEnd()
入力を新たに増やすことによって、それまでのマッチが不成功に変わるならtrueを返します。
マッチが見つかっていたときにこのメソッドがtrueを返したら、さら入力を増やすとそのマッチがなくなることを意味します。マッチが見つかっていたときにこのメソッドがfalseを返したら、さらに入力を増やすとマッチが変わるかもしれないが、マッチがなくなることはないことを意味します。マッチが見つかっていないときにrequireEndを呼ぶことは、無意味です。
まず 1.5 で導入された hitEnd メソッドと requireEnd メソッドですが、 hitEnd メソッドはドキュメントでは入力の末尾がヒットした場合にtrueを返すとありますが、入力というのは領域を指しているようなのですが、末尾というのが最後の文字なのか末尾の位置なのかよく分かりませんでした。例えば aa をマッチング対象の入力シーケンスとして正規表現 aa でマッチングを行った場合、入力シーケンス全体にマッチしますが、この場合に hitEnd は false を返します。つまり最後の文字がマッチしていても true にはならないようです。ところが正規表現 a+ や a* でマッチングを行うと aa と同様に入力シーケンス全体にマッチしますが、この場合は hitEnd は true となります。つまりマッチした部分だけでなく正規表現パターン自体も hitEnd の返す値に影響するようです。
どちらも入力が一つの文字列におさまっていないときに役に立つメソッド。
hitEnd()について想像するなら、
search engineが遷移先を残したまま入力を消費し尽くしたときに hitEnd()が trueになる。それの意味することは、直前のマッチが成功していたのなら、さらなる入力によりマッチの範囲が延長される可能性があるということ。直前のマッチが失敗していたのなら、さらなる入力によりマッチが成功するかもしれないということ。
ところで、hitEnd()が trueかつ requireEnd()が trueの場合って存在するだろうか。あるとして、どんな入力とパターンになるだろう。
requireEnd()はなくても困りはしない。マッチの範囲が入力の末尾まで続いていれば無条件に入力を増やしてリトライすることで requireEnd()が trueだったのか falseだったのかは確かめられる。
hitEnd()も、マッチが成功していたときは重要ではない。真価は、マッチが不成功だったときに hitEnd()が falseを返した場合は、さらなる入力をつなげてもマッチが成功に変わることがないと確かにいえること。hitEnd()がなければすべての入力を連結せずにはマッチが存在しないことを断定できない。
そうそうこれこれ。>http://www.mail-archive.com/classpath-patches@gnu.org/msg08501.html
さらに、こっちのドキュメントは詳細だしバグにも触れてある。上のスレッドで報告されてるのとは別のバグみたいだけど。
boolean hitEnd()
(This method is unreliable in Java 1.5; a workaround is presented on page 392.)
This method indicates whether the regex engine tried to inspect beyond the trailing end of the input during the previous match attempt (regardless of whether that attempt was ultimately successful). This includes the inspection done by boundaries such as \b and $.
If hitEnd returns true, more input could have changed the result (changed failure to success, changed success to failure, or changed the span of text matched). On the other hand, false means that the results from the previous attempt were derived solely from the input the regex engine had to work with, and, as such, appending additional text could not have changed the result.
The common application is that if you have a successful match after which hitEnd is true, you need to wait for more input before committing to a decision. If you have a failed match attempt and hitEnd is true, you'll want to allow more input to come in, rather than aborting with a syntax error.
♭ FILEここにもありますよ。 http://sakura.qp.land.to/?OtherDoc%2FIncmLogsto..
♭ ds14050おおっ、2008年4月まである。楽しみが増えました。情報ありがとうございます。