脳log[SakuraEditor: 2012-02-27～]

2012年02月27日 (月) 変な茶々は入れるまい。リンクはなし。STDINと(省略された)$stdoutの組み合わせはちぐはぐだとか、Scripting.FileSystemObjectは最初に一回だけ作成して使い回すんだとか、WshScriptExecっていう入出力を扱うオブジェクトが Windows(WSH5.6から)に用意されていて JScriptで利用できるんだとか、コメントアウトされた echoバージョンのコマンドでもウチでは動いた(※だけどところどころ lineの内容によって指定されたファイルが見つからないというメッセージが出た)とか、言いたい。

最終更新: 2012-02-29T12:47+0900

♪ [SakuraEditor] なんで ActiveScriptRuby(旧称？)を直接使わないの？

と思わないでもないけど、Rubyマクロにはエディタ側に色々と問題があるのがわかってるので、大枠に沿ったまま書き直してみた。WshScriptExecを使ってみたかっただけ。WshScriptExecを得る方法は WScript.Shell.Execだけなんだけど、これを実行すると必ずコンソールが表示されるのがうまくない。こっそり実行して処理結果だけ欲しいのに。

script.rb

# coding: windows-31j
$/ = "\r\n"
$stdout.sync = true # putsした内容をすぐ flushして .jsが受け取れるように。
puts("[size = % 4d]" % $_.chomp.size) while gets

call_ruby.js

var RubyBin = "ruby";
var RubyScr = "script.rb";

var RubyExec = new ActiveXObject("WScript.Shell").Exec("\""+ RubyBin +"\" \""+ RubyScr +"\"");
RubyExec.StdErr.Close();

/*
  (折り返し行でない)改行単位でのカーソル移動が「GoLineTop」しかなさそうなので、これを基にしてカーソル移動を行う。
  ExpandParameterで $yの変化を監視する手もあるにはある。
*/

// 開始地点(最終行)へ移動。
Editor.GoFileEnd();
Editor.GoLineTop(9);
if (! Editor.GetLineStr(0)) {
  Editor.Up(); // skip [EOF] only line.
}

// 下から上へ一行ずつ処理する。
for (var linenum = Editor.GetLineCount(0); 1 <= linenum; --linenum) {
  if (RubyExec.Status != 0) { // if not running
    break; // 継続は無意味。
  }

  RubyExec.StdIn.WriteLine(Editor.GetLineStr(0).replace(/(?:\r\n?|\n)$/, "")); // カーソル行の文字列をRubyに送る
  Editor.InsText(RubyExec.StdOut.ReadLine());

  //カーソルを上の行の先頭へ移動
  Editor.GoLineTop(9);
  Editor.Up();
}

RubyExec.StdIn.Close();
RubyExec.StdOut.Close();
RubyExec.Terminate();

ツッコミを入れる

2011年12月09日 (金) リファクタリングとパッチ。パッチはそう易々と構造変革を乗り越えられない。自分専用のスペシャルパッチがたまればたまるほどリファクタリングが悪に見える。347KBの差分を前に途方に暮れています。

最終更新: 2011-12-14T19:35+0900

♪ [SakuraEditor] これに関する戦略。

(下拵え1) 色分けに行をまたぐ機能を追加。
(下拵え2) 個々の色分けユニットの移植。(結果が変わらないこととパフォーマンスへの影響が焦点)
(下拵え3) レイアウトと絡んだ古い色分け機能の削除。
(餌1) 正規表現キーワードのキャプチャグループ*別色分け対応(設定の画面とiniへの入出力が面倒だから最初は隠し機能として)。
(餌2) K2Editorっぽい(※勝手な想像です)ヒアドキュメント対応色分け規則追加(正規表現で開始・終了を指定する複数行コメントみたいなもの。終了パターンは開始パターンのマッチを使って $N, $$を置き換えてからコンパイルする。${N}もいる？)。
(本命) SHJSっぽい色分け規則追加(GUIで設定するのは無理だから隠し機能として)。
(できれば)色と色分けと CEditViewの分離・凝集。
(できれば)機能に着目した色名の追加。「正規表現キーワード(定数)」とか。

ヒアドキュメントといえば前にも書いて(そんで忘れて)たが、

print <<HEAD, <<BODY
HEAD
BODY

みたいなのをどうするのかってことだ。<<HEAD...HEADの中に BODYだけの行が来ないことを期待しつつ、一番後ろの <<BODY...BODYだけを対象にするとか？でも <<HEADが来た時点でコメントモードが始まってしまうな。終了パターンで $+ (最後のキャプチャ内容)が使えたらいいのか？そもそもこの姑息な手でいくのか？それに開始パターンで <<HEADから、<<BODYをキャプチャしつつ、改行までを食うとしても、こういうスクリプトを想定してしまうわけだ。正規表現を使った簡易ハイライトだというのに。

p "" << <<"HEAD" <<"NECK" << <<"BODY"
<head>
HEAD
<body>
BODY
#=> "<head>\nNECK<body>\n"

* 繰り返し付きグループの色分けはたぶん最後のマッチだけが対象になると思う。

ツッコミを入れる

2011年08月17日 (水) な、なんだってー。構文木がコウブンボクじゃないとか……。もしやと赤黒木を Wikipediaでみると、こちらもセキコクボクではなかった。赤黒黄とかどんな冗談。もうひとつ、B木もビーボクじゃなかった。ぎゃー。もういい。red-black treeと B treeで十分だ。(こういうデータ構造を本で読んだのって Windows PCを触り始めた翌年の、オブジェクト指向やらオートマトンの本を図書館で借りたのと同じ頃(だけ)だ。県立図書館++。それにくらべて今の自分は……)

最終更新: 2011-08-21T01:48+0900

♪ [SakuraEditor] 正規表現検索。トリック。不完全。

 (?imx-imx)        孤立オプション
                     i: 大文字小文字照合
                     m: 複数行
                     x: 拡張形式
 (?imx-imx:式)     式オプション

 補記 1. 文法依存オプション
  + ONIG_SYNTAX_RUBY
    (?m): 終止符記号(.)は改行と照合成功
  + ONIG_SYNTAX_PERL と ONIG_SYNTAX_JAVA
    (?s): 終止符記号(.)は改行と照合成功
    (?m): ^ は改行の直後に照合する、$ は改行の直前に照合する

サクラエディタが自動で mフラグをくっつけて m/pattern/km みたいなのを正規表現ライブラリに渡すので油断していた。インラインでフラグを変更する方法がある。

ところで、mフラグは実装間で意味に一貫性が無く、また鬼車のフラグも間違いを誘うような名前をしているので注意が必要。みんな ECMAScriptに倣え！

 + 孤立オプションの有効範囲は、その孤立オプションを含んでいる式集合の終わりまでである
   例. (?:(?i)a|b) は (?:(?i:a|b)) と解釈される、(?:(?i:a)|b)ではない

フラグの意味に加えて、その有効範囲の面倒くさいことよ。これに対処するくらいなら他の方法を考えるレベル。Onigmoは PCREみたいに、パターンのコンパイル時オプションとして「改行」を意味する文字を指定することに対応してくれないのかな。>NEWLINE CONVENTIONS(pcre.txt)

mフラグを OFFにする目的は何かといえば、JavaScriptと bregonigにおいては $ と ^ が改行前後にマッチしないように、Rubyにおいては . が改行にマッチしないように、ということだ。

「$ と ^ が改行前後にマッチしないように」は言い換えると「^ と $ が文書の頭と末尾にだけマッチするように」ということだが、サクラエディタにおいては従来、文書の先頭・末尾と各行文字列の先頭・末尾は区別できず、各行文字列末尾と改行直前の区別は曖昧だった。であれば、この問題は複数行検索が実現するときまで先送りしても差し支えないだろう。(ないよね？)

ツッコミを入れる

2011年06月26日 (日) アニメ(※順不同ではない)。シュタゲは毎回 30分が短い。世界線が切り替わる度のあの喪失感と絶望。変わらないまゆしぃの安心感。ぬるぽに即答できる助手から重度の厨二病のおかりんまで、その他のキャラもみんな愛おしい。あの花は良いアニメ(それでもめんまのかわいさが肝)。ロッテはあの世界とそれにマッチした「真夏のフォトグラフ」が好きだ。A-channelはユー子の関西弁が目当て。

最終更新: 2017-09-20T01:01+0900

♪ [SakuraEditor] >> 脳log[2010-06-10-p01] サクラエディタの正規表現キーワードを SHJS相当にしたい。(その二)

新たなバグもなく、すっかり終わってしまったプロジェクト。やり残しは、従来の、状態を持たない正規表現キーワードを色分けストラテジの一つとして移植すること。コメントや URLの色分けなんかと同じで、従来の正規表現キーワードも SHJS相当の正規表現キーワードと共存できる。そのために、協働するために余計な面倒を抱え込んだんだし。

あと、rkw2フォルダやファイルに隠し属性がついてたら読み込まない、とか。

@2017-09-19

スペース(0x20)が C_SPACEである一方、HT(0x9)/CR(0xD)/LF(0xA)が C_WHITE(その他の空白)であるせいで、タブが改行と同じ分類なせいで、一行コメントがタブインデントで終了してしまっていた。

@2017-09-19

HTML.rkw2を自作しようとしてすごく面倒くさいというか、色分け方式の能力不足を感じた。

"move" して "exit" したときに、move元の Stateに戻るだけではなくその中の moveした Patternそのものに戻り、その次のパターンから色分けを再開しなければいけないのではないか。

それはちょっと面倒だったので、"move" と "exit" が同時に指定されていたときは "move"先から exitしてきたときに "exit" が発動するようにした。サブルーチン的に使える。20170919.patch

そんなこんなで HTMLと CSSと JavaScriptの色分けを同時にするどころではなかった。HTML.rkw2。HTMLと CSSと JavaScriptが混在するときでも通用する色指定とは。

ツッコミを入れる

2011年06月12日 (日) 「ユニコード戦記─文字符号の国際標準化バトル」(小林龍生) なんだウニコードじゃないのか(せめて UNICODEにしてよね)。

最終更新: 2013-11-24T02:49+0900

♪ [SakuraEditor] 選択範囲の復元。

GreenPad, Alphaは復元されない。復元する派にもいろいろある。

メモ帳「UNDOで挿入された文字が選択状態になる」「キャレットは常に選択範囲末尾」

選択状態の復元ではない。キャレットの直前/直後の文字の削除を UNDOしても選択状態になる。

Mery「UNDOで(入力や削除時点での)選択範囲が復元される」「キャレットの位置も復元される」

これ理想。(@2013-11-23 2.1.6から 2.2現在まで、矩形選択後文字入力をアンドゥすると矩形で再現すべき選択が線形の選択になってる。これは理想ではない)

Firefox4のテキストエリア「UNDOで(入力や削除時点での)選択範囲が復元される」「キャレットの位置は常に選択範囲末尾」

惜しい。キャレットの位置が復元されないということは、選択範囲を延長できる方向が問答無用に決まってしまうということ。

SakuraEditorと TeraPad「選択範囲は復元されない」「キャレットの位置は復元される」

最初はメモ帳の動作をまねて CDeleteOpeの UNDOと CInsertOpeの REDOに文字列選択処理を付け加えたらいいかと思ったが、メモ帳と違い挿入や削除の連続した操作がひとまとめにされないのと UNDOバッファが無制限なせいで、連続する一文字削除(入力)操作の UNDO(REDO)がすごくくどい。CDeleteOpeと CInsertOpeの直前に CSelectOpe(新設するクラス)を挿入するのが Meryと同じ挙動になって使いやすそう。(前にも Meryが選択範囲を復元してくれるのが良いと書いた>20091117)

とりあえずこんな感じ。>undo_selectarea.rev1.patch(4.5KiB, 2011-06-11, trunk2@1923ベース)

view/CEditViewへの依存を COpe.cppから view/CEditView_Command_New.cppへ移した。>undo_selectarea.rev2.patch(4.2KiB, 2011-06-12, trunk2@1923ベース)

COpe派生クラスの実装と再生は同じ場所で行ったほうがいいような気がするが確たる考えはない*。view/CEditViewと COpeは COpeの機能から考えたら必然的に仲良しさんだから依存関係なんて気にする必要ないぜ、というなごみんの声も聞こえたが現状はそうでもないのでためらう。今 COpe属はただの構造体として扱われてるので、それに従ってロジックをコンストラクタの中から呼び出し側に移した。呼び出しごとにコピペしてね。

削除し忘れたけど「CSelectOpeがあれば CMoveCaretOpeはいらないかもね。」というコメントは正しくない。CSelectOpeは今のところキャレット位置を保存せず、その場所には適当に選択終点を代入してる。Ctrl+Aで全選択したときにキャレットが動かないので、選択始点・終点とは別にキャレット位置を覚えておかなければいけないが、今はそうしてないので CMoveCaretOpeが必要。

不要にした。>undo_selectarea.rev3.patch(4.9KiB, 2011-06-12, trunk2@1923ベース)

@2011-06-15 矩形選択範囲の削除をアンドゥしたとき

復元された選択範囲が正しくない。文字がない部分に選択範囲を広げられないためだ。それは、COpe属がすべてロジック単位(wchar_t列に対するインデックス)で情報を保存してるからで、その理由はたぶん、折り返し方法が変わっても対応できるようにだろう。TeraPadの readmeか何かで折り返しを変更するとアンドゥ情報がリセットされると読んだことからの類推。どうしようか。選択範囲なんてクリティカルな情報じゃないから、矩形選択時はレイアウト座標で情報を持っておくことにすれば大体はうまくいく、ってことで済ませていいんじゃないだろうか。

CLogicRangeや CLayoutRangeはコピーコンストラクタがあるから共用体のメンバになれない(C++98では)。CLogicRangeを CLayoutRangeに置き換えただけのコピペクラスを作るのか……。上のパラグラフで書いたことだけど、どっちを選んでも一長一短なのだし、矩形選択だからっていつでも選択終点がフリーカーソル状態ってわけでもない。できるだけ余計なことはしない方向で(やめとこ)。でもでも。

@2011-06-15 あれ？「常時選択範囲」って何だ？

選択始点の型がどうして CLayoutPointでなく CLayoutRangeなのか。答えがここにある。

@2013-10-18 矩形選択文字入力のUNDO

矩形選択して選択した全ての行に文字を挿入するということをよくする。ABDと入力・挿入していって、間違えた、Ctrl+Z、Cと操作したいのだけど、Ctrl+Zした時点で矩形選択が解除されてるのでその後の Cはキャレットのある行にしか挿入されない。残念だ。

「残念だ」と他人事(ひとごと)のような気のない素振りを見せることでやる気をひねり出す天の邪鬼メソッド。似たようなものに「要望を書いて次の日になんとかするセルフサービス」メソッド。

矩形選択挿入/インデントを UNDO/REDOしたときにも選択状態を復元する>undo_selectarea.rev5.patch(13.1KiB, 2013-10-18, trunk2@1923ベース)

テストはしていない(ｷﾘｯでも自分用の sakuraW.exeには取り込んだので今日から使用中。

「呼び出しごとにコピペしてね」とは上の方で書いたが、CSelectOpe(ロジック単位の方)を作成するヘルパー関数をやっぱり用意した方がいいかもしれない。座標変換が煩雑なので。CEditViewに依存するので COpe.{h|cpp}に置くことはできないが、CViewCommander_New.cppと CEditView_Command_New.cppから利用したい。どこに置けるだろう。CViewCommander_New.cppには Command_INDENTがある。CEditView_Command_New.cppには CEditView::DeleteDataと CEditView::InsertData_CEditViewがある。Command_INDENTから呼び出される CEditView::InsertData_CEditViewで選択範囲の記録ができれば、ヘルパー関数の設置と利用は CEditView_Command_New.cppだけで完結する。それができないのは CEditView::InsertData_CEditViewがお節介にも選択範囲内のテキストを削除してくれるから、インデントを実現するために Command_INDENTが選択範囲をクリアしたり再設定したり小細工を弄する必要があって、Command_INDENT内でしか選択範囲を記録できないからだ。飛躍。エディタ(ドキュメント+ビュー)はプリミティブな操作と情報(検索、置換、選択、キャレット、ステータスバー、ダイアログなどなど)だけを提供して、各種コマンド(インデントとか検索とか)はそれらの操作を組み合わせるスクリプト(カスタマイズしやすい。オプションや好みを反映しやすい。依存されない(されにくい))であってほしかった。という感想は、CEditView::InsertData_CEditViewのようなフルスペックで融通の利かない大きな関数を、一部の機能を無理矢理引き算して利用するような状況から生まれてくる。

UNDO/REDOコマンド関数が Command_CANCEL_MODEを呼び出す部分に書いたコメント

Command_CANCEL_MODE()は主に範囲選択のクリアと選択ロックの解除を行う。
範囲選択のクリア(再描画あり)を行うと CSelect(L)Opeで範囲選択を復元したときにちらつく。
かといって、CSelect(L)Opeが含まれていないときは従来通りクリアを行いたい。
どうするか。再描画なしでクリアする。方法は Command_CANCEL_MODEに redrawフラグを渡すこともできるが
Command_CANCEL_MODEの中身をコピペしてフラグだけ書き換えることにする。

範囲選択を解除する必要があるのは挿入/削除操作(CInsertOpe/CDeleteOpe)の都合かも知れない。それらの Opeの再生部分に Command_CANCEL_MODEを移動するのが３番目の方法(選択のキャンセルに伴ってキャレットが移動させられないか注意)。そもそも(出た！)、Viewに挿入/削除を行う範囲を指示するパラメータが、独立した CViewSelectなり CLayoutRangeのインスタンスではなく、ユーザーから可視の選択範囲を意味する Viewのメンバ変数でもあるから、描画のフラグをオンオフしながら選択範囲をあれこれ操作しなければいけないってのが面倒の根本。Viewにはユーザーから呼ばれるものとしてそういうメンバ変数と結びついた関数があってもいいが(※)、その関数が利用するものとしてもう少し粒度の細かい汎用性のある関数が欲しい。※良くない。そういう、メンバと結びついたコンテクストフルな関数をコマンダーに置いて、汎用性のある関数を Viewに置こうという方向で分離が進んでいたのかもしれない。

COpeで一番に改善が必要なのはメモリ確保の戦略だという気もする。1単位の UNDO/REDOのためにひとつの COpeBlkとひとつ以上(４以下くらい。CSelect(L)Opeでサンドイッチすると＋２)の C*Opeのインスタンスが newされるという現実をなんとか。

COpe派生クラス(CInsertOpe/CDeleteOpeとか)の再生の前後でキャレット位置を復元するのは COpe共通のタスクとして実装されている。前後の選択範囲の復元も COpe共通のタスクにしてしまってよいかも。そうすると選択範囲のクリア、範囲の設定、テキストの挿入/削除、範囲のクリアという CInsertOpe/CDeleteOpeの手順と CSelect(L)Opeサンドイッチがひとまとめになって、空間効率も処理手順も無駄がなくなる。派生クラスの種類が減ってサイズが同じになるならメモリ戦略の実体も一本化できそう(まあ、やらないんだけど)。

@2013-10-20 選択モード(SelectingLock)も復元すべき？

そういうのはまとめて CViewSelectのコピーコンストラクタと代入演算子の仕事ではなかろうか。できるかな。そして、もしそういう操作が Viewの外に公開されてるなら CViewSelectのインスタンスを通して Viewの選択状態を変更できる setterの存在が期待されるわけだ(Viewのメンバの CViewSelectのメンバの m_sSelectを直接書き換えるとか主権侵害言語道断)。

* @2013-10-18 COpeに本物のポリモーフィズムを導入するとかいうこと。そうすると COpeの派生クラス(CSelectOpeとか)の新規導入が UNDO/REDOの実行者から不可知のまま行えるようになる。

ツッコミを入れる

2011年06月05日 (日) Cannondale BAD BOYを見つけたのって、たぶん中学生のときから使ってる財布のせいだ。それを何かの折にネットで検索した。2003年頃。

最終更新: 2011-06-05T22:03+0900

♪ [SakuraEditor] 固定長のタイプ別設定って

タイプ別設定一覧ダイアログの見せ方だけで、並べ替えたり可変長に見せかけて(実は上限は30で変わらない)削除・追加を受け付けたりできるよね。

それが行われるとファイルタイプを選択するツールバーボタン(リスト)のアイテムの並びも考えないといけなくなるけど。

ツッコミを入れる

2011年06月02日 (木) ATOK2009の補完はいまいち。一度入力した単語は二度と最後まで入力したくないのに、一度は候補に出てきた単語がどんどんどんどん忘れられていく。あと、最長の候補が最初から出てこない。同じ文章を再入力するときでも、末尾の一語だけしか補完できないなんてことがよくある。

最終更新: 2011-06-04T20:36+0900

♪ [SakuraEditor] 文字の幅。代替表示。色分け・強調。

画像の通りに、メイリオUIをインストールしてから日本語文字(Consolasにリンクされたメイリオ)が半角になる。メモ帳もそう。素のサクラエディタでは半角表示の日本語に全角のマス目を割り当てて字間に謎の空白が表示される。画像でそうなってないのは CNativeW::GetKetaOfCharを、文字コードの範囲によらず常にフォントを通して字幅を得るようにいじったから。性能に大いに悪影響を与えるだろう。気にならないけど。で、それだけだと Deleteキーを押したときにキャレットと離れた位置の文字が消えるようなことが起こる。そういうときはキャレットの左側に□で表示された全角空白があったりする。(半角で表示される)全角空白を(半角で表示される)□と表示する view/figures/CFigure_ZenSpaceが□を描画した後にカーソルを無条件で 2進めるために CNativeW::GetKetaOfCharの返す値との間に齟齬を生じていた。文字の幅や高さをコードポイントから決めることはできない。それは代替表示や部分強調も絡めてビューが決めること。

ツッコミを入れる

2011年06月01日 (水) あかん。r1921をマージするのは死ねる。ファイル構成(※)が違うし名前が違うし DoChangeColorとかもうないし。※SColorStrategyInfoは CColorStrategyのインターフェイスの一部(CColorStrategy.hの中に入れるもの)ではなく、その利用者 CEditViewに属するものだと思うんだよね。本来無関係な CEditViewの一部を取り込んでおいて #include "view/CEditView.h"(※2)とか、その引きずってるものの大きさを考えたら気違い沙汰ですよ。と思ったので色分けを SHJS方式にしたときに構成を変えたのだった。※2 #includeはコメントアウトされてるように見えるけどヘッダの中で Viewのメンバを呼んでるからむしろ何でそれでOKなの？ .cppに移動させてもリンクのコストが無駄に増えるのは変わりない。CColorStrategy.hをインクルードする他のファイルに無駄な依存を伝播させることはなくなるけど。### r1921のマージはアイディアを借りた再実装と同じだとわかった。だったら今はやらない。

最終更新: 2011-06-11T02:05+0900

♪ [SakuraEditor] BugReport/82 - SakuraEditorWiki 正規表現検索の不具合

ここに犯人がいます。言い訳すると、これは見逃してもしかたがないと思うの。(補記だし存在しない機能だし)

 補記 3. Perl 5.8.0と比較して存在しない機能

 + \N{name}
 + \l,\u,\L,\U, \X, \C
 + (?{code})
 + (??{code})
 + (?(condition)yes-pat|no-pat)

 * \Q...\E
   但しONIG_SYNTAX_PERLとONIG_SYNTAX_JAVAでは有効

bregonig.dllは ONIG_SYNTAX_PERL_NGを使ってるみたいだから \Q...\Eは有効。bregexp.dllは \Q...\Eをサポートしていない。

パッチはこれ。>regex_trick_coping_with_qeescape.patch(13.3KB, 2011-06-01)

テストケースはこれから整理する。(パターン内でのコンテクスト×エスケープシークェンス×正規表現ライブラリ)

@2011-06-02

テストマクロを書いた。>test_regex_trick.js(5.0KB, 2011-06-02)

そうすると、\c\\ みたいなパターンに対応できていないことが新たに判明した*。ちょっとだけ修正したパッチはこれ。>regex_trick_coping_with_qeescape.rev2.patch(13.3KB, 2011-06-02)

手もとでは bcc32で作成した sakura.exe(1.6.6.0 with bregonig-1.45)と VS2008EEで作成した sakura.exe(2.0.2.0 with bregonig-2.02)、ともに Revision 1922ベース、ですべてのテストに成功する。逆に、パッチなしだと期待した通りに失敗する。

@2011-06-10

掲示板>1571

コミット>r1923

* 違った。もうシラネっていってたやつだ。たぶん。

ツッコミを入れる

2011年05月09日 (月) 原文を見なくてもわかる日本語訳のミス。>「グーグル社員の間でも、黄の社員証の階級はほとんど知られていない。彼らのビルは3.1459~という棟で、」

最終更新: 2011-05-10T18:49+0900

♪ [SakuraEditor] Re: 正規表現による複数行検索対応（簡易版）

GetCountOfDividedStringW()はいけてない。

どういう関数？>「改行のエスケープシーケンス（'\\'+'n'）で区切られる文字列の個数を数える（WCHAR版）」

使われ方>「複数行指定方法の改善（正規表現パターンの行数とダイアログ設定値の大きい方を採用する）」

\rに対応していない。
LFの直書きに対応していない。(CRの貼り付けはできなかったのでとりあえず LFだけ)
量指定子に対応していない。
\x0D\x00\x0A\x00や \x{0D}\x{0A}に対応していない。
[\s\S] や \s, [\w\W] や \W, . (sフラグONのドット)に対応していない。

これだけ対応していないなら「正規表現による」というより、\nというエスケープシーケンスにだけ対応した普通の検索といったほうが当たってる。正規表現ライブラリに今以上の機能(hitEnd)を求めないのなら、これが最大限度の対応なのかもしれないが……。GetCountOfDividedStringWには期待せず、ダイアログで 100とか設定しておけば大体はうまくいくのかもしれない。

CMultiLineSearch::GetCompensationLengthには脱帽。

どういう関数？>「０文字マッチや改行文字の途中を考慮した置換文字数の補正値を取得する」

なぜ必要？>ドキュメントの操作がビュー経由でしか行えないため、ロジック単位で行った検索をレイアウト単位に変換してから置換を実行しなければいけない。置換関数の中ではレイアウト単位をロジック単位に変換して……といったことがもちろん行われるわけで……ムキー、ってなことを 20100907p01.03に書いた。

とりあえずロジック単位で置換範囲を指定できる置換関数をどこかに作ろうとして、20100709p01の複数行置換の実装は止まっている。CMultiLineSearch::GetCompensationLengthを使うアプローチはこれまでのやり方を踏襲するもので、置換範囲と置換文字列をレイアウト単位境界にそろえてから置換関数を呼び出す。計画倒れよりできあがってる方が偉い。

ツッコミを入れる

2011年04月20日 (水)

最終更新: 2011-04-21T03:20+0900

♪ [SakuraEditor] Regarding: Request/359(CSV編集モード) - SakuraEditorWiki

TSVだったら、タブ幅が可変になればよさそう。列ごとにフィールドの最大幅より1文字分だけ右側にタブストップがくるようにすると表形式に整列される。ファイルを最後の行まで読んで調べないとレイアウトを決定できなくなるのがデメリット。レイアウト↔論理座標変換も工夫しないと遅くなる。この変換は検索などでやたら無駄に呼び出されるから速度低下は増幅される。CSVなら、カンマの幅を半角文字○個分扱いするのかな。一文字編集するたびに画面全体の再描画が発生するケースもあるけど気にならない程度？列を指定してソートできる秀丸さんかっこいい。タブストップを自由に設定できるというから、タブストップの位置を配列で持ってんのかな。タブ幅だけを覚えておいてその倍数がタブストップ、という現状にくらべると記憶領域も検索コストも必要になるけど、せいぜい人間が管理できる程度の数にしかならないだろうし。桁位置(64bits)×タブストップの数(10000)=80KBで十分過ぎるくらいか。

ツッコミを入れる

2011年04月06日 (水) 「zenback を入れてみた」一点にだけ注目していた。期待は裏切られなかった。コメントの後に ZENBACKが表示されるのがイイ。そうでないと、読もうと思ったコメントが遅延ロードされた ZENBACKに押しやられて逃げていってしまうから。追記@2011-04-07:「zenbackをツッコミ欄の後ろに表示させた一件 - kayakaya日記(2011-03-28)」突如わいてきた(ように見えた)要望の目的は最初からそこにあったのね。スクリプトを埋め込むのに tDiary本体の修正が本当に必要？って思って、danなにがしさんの(コメントが逃げる)ブログを Firebugで覗いてみたりしてたのよ。この後者のエントリを発見したのが、前のエントリの関連リンク(powered by zenback)だってんだから有用性は疑いえないな。

最終更新: 2011-04-14T01:54+0900

♪ [SakuraEditor] BugReport/70 - SakuraEditorWiki

まったく、CViewCommander::Command_REPLACE_ALL ってのは人類の理解の範囲を超えている。

通常選択範囲を置換
矩形選択範囲を置換
ファイル全体を置換
対象範囲を行単位で置換
対象範囲をひとつのマッチごとに置換
正規表現ライブラリを使って置換
クリップボードのテキストに置換
クリップボードの矩形テキストに置換
置換ではなく前に挿入する
置換ではなく後ろに挿入する

これ、あえて異なる複数の分類を一括りのリストにしてるけど、実際のコードがそうなのだ。こんな処理が一つの関数の中に、変数を共有しながら―しかも型を偽って本来とは違う使い方が特定の処理ルートではなされていたりする―、一部の処理を共有しながら、インターリーブされてる。

BugReport70.patch (1.7KiB, 2011-04-07 02:50)

submit(<commit以前)はしない。怖すぎる。

「「すべて置換」は置換の繰返し」フラグが ONのときの対策がまだ。

コミットログも読まずに軽率な修正。>BugReport70.rev2.patch (2.7KiB, 2007-04-07 06:50)

これから読む。>「SourceForge.net Repository - [sakura-editor] Revision 1049」, 「SourceForge.net: Sakura Editor: Detail: 1636751 - 行置換のオプション化＆問題修正」

うむ。削除したコードがなぜあえて論理座標だったのかわからない。

@2011-04-11 「// 行単位で置換するので colDifは常に 0。」

って書いて削除したコードがパッチにあるけど、一つの行が複数のレイアウト行に分割されてることがある。一行処理して次の行……と思ったらまだ折り返された同じ行にいた、とか。前にも別件で書いてるけど、折り返しと矩形選択(+文字一括挿入／+置換)は本当にひどい組み合わせ。結果を予測できるものにするためには選択範囲の末尾の行から処理をしないといけない。そうすると文字の削除や挿入による折り返し位置の変化が後の処理に影響を与えないので。でもそうはなってない。だから、結果を維持する労力を割く必要もない「未定義」の動作だと考えてしまう。

ツッコミを入れる

2011年02月10日 (木) 「それは仕様です」ってそんなに嫌いではない。発言者にその宣言を遵守する意志があるのなら。言われた方はその宣言を以て、即座にその仕様(と手元の実装)に依存できる。言った方は修正の手間がないし、挙動を変えて周囲(期待と実際の違いに気付いていなかった方の集団)を騒がせるおそれもない。とはいえ一般には「仕様のわけねーだろ。バグだよ、バグ」って言いたくなるようなものに対して「これは仕様でしょうか？」ってのも嫌みったらしく聞こえそうなので控えたい。何回かやってるけど。

最終更新: 2011-02-11T00:59+0900

♪ [SakuraEditor] SourceForge.net Repository - [sakura-editor] Revision 1887

Fix: 検索(ツールバー)を使うとプラグインコマンドが実行される(2)

検索ボックスのコードをほとんどコピーした自作ツールバーボタンもやばい気がするものの、CBN_SELCHANGEはツールバーボタンで処理してるんだよね。処理しなかったメッセージが誤った取り扱いを受ける、ということなんだろうか。わからないよん。

>>脳log[2008-06-04-p01] 現在適用されているファイルタイプを表示/変更するツールバーボタン

ツッコミを入れる

2011年01月29日 (土)

最終更新: 2011-04-09T19:20+0900

♪ [SakuraEditor] サクラエディタに複数行検索を導入する際に考慮する必要がある正規表現パターンへの細工。

今のサクラエディタはユーザーが入力したパターンに細工を施している。>「正規表現を使った検索・置換で、改行の意味を LFのみから CRも含むように。」

サクラエディタでは改行をまたいだ検索ができないけど、将来できるようになると問題が生じる。(その根拠は20100709p01の実験による)

^(改行文字の直後にマッチ)が CR直後(かつLF直前でないことが望ましい)にマッチしないことが露見する。
$ を (?<![\r\n])(?=\r|$) に置き換える現在の細工では、連続する改行と改行の間にマッチできない。

^ は (?:(?<=^|\n)(?=[\s\S])|(?<=\r)(?=[^\n])) に、$ は (?=\r\n?|(?<!\r)\n|(?<![\r\n])$) に置き換えるのでいいかなあ。用意した入力が期待した結果になるのは確認したけど、予期しない入力が予期しない結果になる可能性はやっぱりある。

^ や $ を、先読みや戻り読みを使ったパターンに置き換えることの副作用

戻り読みの中に ^ や $ を置けなくなる。複数行検索ができるようになったときには、戻り読みの中で行末を検知したくなることもあるかもしれないね。でも、できないね。

ツッコミを入れる