/ 最近 .rdf 追記 設定 本棚

log[2010-06-16]



20100616() グランツーリスモ511月に発売GT5PS3を一緒に買うと決めてたのに待ちきれなくて今じゃリーンベル専用機ですよはやくはやく


20100615() いくつかのサトでテキトを選択すると選択肢(googleで検索とか)を表示されることがある邪魔無意識のうちに視線を追いかけるように既読範囲が見えるようにマウスドラッグしていることがよくあるからだ携帯電話で表示しているときであれば便利に思うかもしれないが PCでお仕着せは御免だ


20100614() ッカW杯日本戦の結果第一報()> SourceForge.net: tDiary:


20100613() うしおととらを再読していたらつい最近みた覚えのあるネタが……。これとある漫画はうしとらでしたとさ


20100612() [Songbird] Songbird-1.7.2前バージョン(1.4.3)で下から上に移動した再生コトロールが上にも下にも表示できるようになって満足ァイルに touchする方はどうなっただろう20100201p01


20100610() iPadがインターネトごしに DLNAクライアトになれたら迷わず買う(これって買わない宣言) 読書端末の本命 Sony Readerの年内発売を待っている

最終更: 2012-10-27T00:23+0900

[SakuraEditor] サクラエタの正規表現キーワドを SHJS相当にしたい(その)

その一(20090808p03)がだらだら長くなったのでいったん切ってここに続ける

 @2010-06-10 バグ発見

ひどい/*を入力して後ろの行がコメト色一色になったとするつづけ*/を入力しても後ろの行がコメト色のままたぶんこれが関係する

行をまたぐ色分けに問題があってたとえば一画面に収まらない長大な複数行文字列があったとして何度も上下にスクロールしたり改行を入力したりするだけで色分けが変わってしまっていた

log[2009-08-08-p03] サクラエタの正規表現キーワドを SHJS相当にしたい @2010-04-14 バグ修正

本当にそうなら泥縄式バグ潰し無間地獄へ突入ですな消火行為が点火に直結した効率のいいマッチポンプだもん


まさしく > たぶんこれが関係する

そのときの変更にこんなコメトが添えられているのを発見したIsInsideKeyword()から呼ばれたときは精算したらダメっぽいのでコメトアトして様子を見る様子見の結果はダメでしたさあどうしよう


別の場所で不必要にキッシュを無効化している部分を厳密に処理したら直ったっぽいッシュの有無で結果が変わるはずないんだけど……(さらなる追求が必要でもそれは問題が見つかってからにす)


 @2010-06-13「キッシュの有無で結果が変わるはずないんだけど……

変わりうる一行の色分けは一時(いちどき)他の行の色分けを挟んだりせずに終わらせなければいけない正規表現キーワドは各行の行頭がどういう状態か(コメトの中か?とか)を覚えているキッシュの他にある行を中間まで処理したマッチング結果を持っており先ほどはこれをキッシュと呼んでいたそいつは次の IsStartOfKeyword()呼び出しを待っている宙ぶらりんな状態期待していた呼び出しがくる前にクリアされたら結果がおかしくなるッチングを中間で止めざるをえないのは他の色分けに先食いされた文字をマッチに利用してしまわないように


20100609() メインメニーを整理しているとき「移動履: 次へ「移動履: 前へを見つけたこれまでってきたい場所へはブックマークをセトしていたがっと行って戻るだけなら移動履歴の方が解除の手間がないぶんいいAlt+(戻る)Alt+(進む)(矩形選択)ーソル左移動などに使われていたので Ctrl+Shift+ZCtrl+Shift+Yに割り当てた

最終更: 2011-01-02T16:45+0900

[SakuraEditor] サクラエ温故知新

SAKURA Development BBS (ANSI)のログが 10ージ分しか閲覧できなくて残念な思いをしていた検索対象のリトに古い年月が存在していたり個別リンクが機能していたりするんだから古いログが保存されているのは間違いないんだけどCyclamen(掲示板CGI)に関して言えば記法のヘルプを見つけることもソースを見て記法を確認することもできないそれはおいといて

過去ログを見つけた>http://groups.yahoo.co.jp/group/sakura-editor/files/User/bbs-log/

Subversionが最初からあった世代には考えられない開発スタイルがそこに!差分や変更したファイルを共有エリアに置いて掲示板で報告大きな変更をした人が他の人の小さな変更をマージして最新版を管理したりともあれお宝ざくざくなので日曜日から喜々として読み進めている次第(ログが 20079月で切れてるのが残)

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が管理すれば良いような気がします.

上記内容を納得した上で私が確認した限りでは特に問題はないように思います.

---
実装に入る前に設計に対する議論を行うことは有意義だと思います.これまでは議論する相手がいなかったので...(;_;)

タイプ別設定を共有メモリから追い出すアイアが既に出ていた

設定の場所を隠蔽するクラスも構想されているそれのメリトとして自分が考えているのは

  1. 実行ファイルに埋め込まれたデフトのタイプ別設定
  2. 基本設定
  3. 拡張子に応じたタイプ別設定

32との差分とすることで基本的な設定の共通化(基本設定による)を図りつつ設定の読み出しを一本化できること

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]したときの挙動を見直し・・・以下変更個所
       1.矩形選択中に[Ctrl+Home]or[Ctrl+End]して[Down]or[Up]したとき以外は普通にカーソル移動
       2.選択を解除したあとは普通にカーソル移動
(省略)

ァイルの先頭へ移動するコマ(Ctrl+Home)「通常は(0, 0)へ移動ックス選択中は(GetCaret().GetCaretLayoutPos().GetX2(), 0)へ移動というコメト付きで故意におかしな動作をするのはこのへんが理由だったの(細かいことを言うとこのときの実装は Ctrl+Home00桁に移動した後↓で 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

sakura/trunk2/view/figures/CFigureStrategy.cpp

ースを見てないと気づかなかった

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 PRESSdartsっぽいのは見かけてたけどもわからなくて検索したし

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の関数眺めたのですが、改行は1文字(\n)だと
決めて処理している箇所があり、難しそうだなぁと思いました。

> #UTF-16にも対応してくれないかなぁ

ははは・・・さすがに対応済みのDLLを持ってきた方が早いかと・・

「改行は1文字(\n)」が「改行は1文字(\rの後ろではない\n, \r)になるだけでも十分ではないのかなあ

  • lf_and_cr_as_eol.rev2.patch(2.4KiB)
  • sakura(r1764_without_bregexp_trick).zip(497KiB, dllの違いをテトするために、検索パターンの置き換トリックを行わないように変更したも)
  • $が行文字列末尾にもマッチする関係ですべて置換が置換しすぎる(上の zipァイル内の sakrua.exeに限った話)BREGEXPは正しい処理をしているのでsakura.exeでの対処はやはり必要になる($ が行文字列末尾にマッチしたのは無視すべきだが空パターン (?:) が改行文字の後ろにマッチしたのは無視すべきでない果たして両者を区別できるのか)
  • 調子に乗って hitEnd()に相当する機能を付けたら複数行検索も

    1. 基本的に一行検索
    2. 改行文字の後ろまでマッチが続いていたり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も見つけ出してきた

COOLURLは変わらないということをリンク切れを発見するたびに思い出す。この二つの 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に決まったんだろう?)意外な発見(とどこかで見たような問題が)がざっくざく

* BREGEXPBBASP21Bと同じ BABABのはずでBASP21WSHから利用できるオトメーションオブジトとしてJScript(最初に出会った記念すべきコンピータ言語)をいじり始めた当時から有名だった(「それBASP21でできるよ)からBREGEXP"以前"が存在するとは思ってもいなかった

本日のツッコミ(2) ッコミを入れる

FILEここにもありますよ http://sakura.qp.land.to/?OtherDoc%2FIncmLogsto..

ds14050おお20084月まである楽しみが増えました情報ありがとうございます。


20100607() Unlha32.dll等開発停止LHA書庫の使用中止呼びかけ - Claybird の日記PCが初めて家に来た頃の情報源が ASCII付録CDLHMelting(LHMelt?っち?)が入っていて以来いまも使い続けている更新が途絶えていたのを気にしていたらこういうことだったっともLHMeltは使っても LZH書庫を作成したことはなかったけどZIP系ばっかり


20100606() google検索結果でサトの URLを示す緑の文字部分がパンくずリトになってる場合があることに気がついたいつからだろうどういう仕組みだろう


20100605() デザインパターンの本を読みたい!<今更今だったらそのギコ猫とデザインパターン(www.hyuki.com)を読んだときとは違ってーんで済んでしまわずにあああれがそうだったのかと実例を頭に思い浮かべながら漠然としたイメージだったものに輪郭を与えて将来の利用に備えることができると思う


20100602() 『プログラミングの魔導書株式会社ロングゲ明らかに長門(有希)C++界隈にそういう人がいるって噂も聞いたことがあるまあ買うけどAmazonで売ってね


20100531()

最終更: 2010-07-10T01:01+0900

[正規表現] requireEnd(), hitEnd()

hitEnd

public boolean hitEnd()

このマッチーが行なった最前のマッチング操作によって入力シーケスの終わりに達していたらtrueを返します。

このメソドがtrueを返したときはさらに新たな入力を加えると最後のマッチの結果が変わる可能性があります。

requireEnd

public boolean requireEnd()

入力を新たに増やすことによってそれまでのマッチが不成功に変わるならtrueを返します。

ッチが見つかっていたときにこのメソドがtrueを返したらさら入力を増やすとそのマッチがなくなることを意味します。ッチが見つかっていたときにこのメソドがfalseを返したらさらに入力を増やすとマッチが変わるかもしれないがッチがなくなることはないことを意味します。ッチが見つかっていないときにrequireEndを呼ぶことは無意味です。

java.util.regex クラス Matcher

まず 1.5 で導入された hitEnd メソドと requireEnd メソドですが hitEnd メソドキュメトでは入力の末尾がヒトした場合にtrueを返すとありますが入力というのは領域を指しているようなのですが末尾というのが最後の文字なのか末尾の位置なのかよく分かりませんでした例えば aa をマッチング対象の入力シーケスとして正規表現 aa でマッチングを行った場合入力シーケス全体にマッチしますがこの場合に hitEndfalse を返します。つまり最後の文字がマッチしていても true にはならないようです。ところが正規表現 a+a* でマッチングを行うと aa と同様に入力シーケス全体にマッチしますがこの場合は hitEndtrue となります。つまりマッチした部分だけでなく正規表現パターン自体も hitEnd の返す値に影響するようです。

Java 正規表現アプリケーション

どちらも入力が一つの文字列におさまっていないときに役に立つメソ

  1. 二番目の引用内容と
  2. requireEnd()trueを返した場合と hitEnd()trueを返した場合の対比と
  3. 自分が行文字列のリトを対象に鬼車でマッチングを行うときに欲しい機能から

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.

Section 8.4.  The Matcher Object
本日のツッコミ(4) ッコミを入れる

ds14050>ところでhitEnd()trueかつ requireEnd()trueの場合って存在するだろう a..

ds14050なぜだか上のコメトがスパム扱い@data_path/log/debug.logを見た >I, [2012-0..

ds14050>[\/url] ではなく \[\/url] が正しい 正真正銘正しいのは \[\/url\]った しか..

ds14050>requireEnd()はなくても困りはしないッチの範囲が入力の末尾まで続いていれば無条件に入力を増やして..


20100530() [ーンベ] 二周目終了ージするとグレネドの投擲モーションがスパイクになったりボウリングになったりすることに大聖堂(トダンジョン)で気がついたプレイ時間は一周目が 140時間くらいで二周目が 40時間くらいグレネドひと筋のリーンベルのレベルは 30グレネドは常に供給に不安があるのと一度に一カ所しか攻撃できないのとチージ速度とチージ加速度が固定なのがつらい(だからモーションが変化することを最後になるまで気付かなかった)ドガンで有名なゲージクラックを利用したハメはグレネドの専売特許にしてもよかった