最終更新: 2012-07-01T14:27+0900
というわけで、CEditView::IsSearchStringからコピペコードを廃すると CColor_Foundが知りたがっている何番目の単語がマッチしたのかを知るためにさらなる検索が必要になるにもかかわらず、CEditView::IsSearchStringという変態のために仕様を決める必要は全然ない気がしてきた。仕様ってのはこれの→「sakura-unicode:1830」「複数単語検索のブックマーク・Grep対応 - ID: 3539115」。CEditView::IsSearchStringには消えてもらって CColor_Foundと CSearchAgent::SearchWordの組み合わせで何とかすべき問題ではないかと。SearchWordだと検索結果が改行をまたぐようになってもそのままで適応する利点もある(CColor_Foundと CColorStrategyの方には対処が必要だが)。
最終更新: 2012-12-05T05:04+0900
前に自分が引っかかったのと同根。「タブやタイトルバーに変更フラグが表示されるように修正した。フラグ自体は立ってたけど描画が行われていなかったというミス。(20100620p01)」
変更フラグを管理してるのは CDocEditor。ドキュメントを変更した関数が SetModified(bool modified, bool redraw)メソッドでこれに通知するが、更新フラグが立ったとき(落ちたとき)に描画が抑制されていると、以後ドキュメントの変更をトリガにしたキャプションの変更機会を失う。キャプションの内容は変数展開、条件分岐を利用して高度にカスタマイズが可能で、キャプションの更新を必要最低限にケチるのは理に適ってる。ではどうするか。描画の抑制を描画の遅延ととらえて、抑制中に加えられた描画に影響する変更を記録して、後でまとめて描画する？ Webブラウザが JavaScriptに対して行ってるように？ それは大変。マクロ由来のコマンドを描画を抑制して実行してるのは CMacro。かといって CMacroがコマンド呼び出しの前後で描画を適切に維持するのは出過ぎた行為。さっき「キャプションの更新を必要最低限にケチるのは理に適ってる」と書いたけど、描画の抑制をやめるのが一番簡単。だって Charマクロで InsTextのような問題が起きないのは、Charマクロの実体関数が redrawフラグを受け取らないで常に描画を行ってるせいだから。
<2012-06-25> ReDrawマクロの存在を教えてもらったのでちょっと修正。なんでこんな(描画に問題があるときに実行して下さい)コマンドがあるんだか。
現在の編集ウィンドウを再描画します。何らかの原因で画面表示を最新状態に更新したい場合に使います。
【例】 ステータスバーを非表示にしたとき、メニューバーの左側にステータス情報が表示されますが、ファイル名のチップ等で消されてしまうことがあります。そういう場合に使います。
なんで手動でやらそうとしたんだ……。
</2012-06-25>
<2012-07-04>
……って、その、メニューバーの左側右端に表示されるステータス情報は、もう消えなくなってるアレだ。「SourceForge.net Repository - [sakura-editor] Revision 1594」
</2012-07-04>
/** OneTouchIndent.js
* サクラエディタのマクロ。
* Tabキーに割り付けて使う。
* 前の行にならって同じインデント(Tab,Spaceなど空白文字全般)を挿入する。
* Enterをトリガーにしたオートインデントってイマイチじゃない？
一段深すぎたり、空行を挿入したかったりするときに削除の手間が必要で。
このマクロは、Tabキーを押す手間は必要だが、望まないインデントは行わない。
*/
if (OneTouchIndent()) {
Editor.ReDraw();
} else {
Editor.IndentTab();
}
function OneTouchIndent() // returns true(done) or false(undone)
{
// 文字列選択中はインデント文字の挿入ではなく、インデントを行いたい。
if (Editor.IsTextSelected) {
return false;
}
var caret = eval(Editor.ExpandParameter("({y:$y-1, x:$x-1})"));
// 前の行にならってインデントの文字と量を決定するので、先頭行では(デフォルトの)インデントを行いたい。
if (caret.y < 1) {
return false;
}
var thisline = Editor.GetLineStr(caret.y+1);
var prevline = Editor.GetLineStr(caret.y);
var previdnt = prevline.match(/^(?:(?![\r\n])\s)*/)[0]; // 行頭の、改行を除く空白文字
// prevline[0...previdnt.length]
// thisline[0...caret.x]
if (previdnt.length <= caret.x) {
return false;
}
if (previdnt.substring(0, caret.x) !== thisline.substring(0, caret.x)) {
return false;
}
Editor.InsText(previdnt.substr(caret.x));
return true;
}
気付くのが遅すぎるけど、インデントを深くしたいときには意識的にタブキーとスペースキーを使い分けないといけなかった。そういうのを気にせずワンボタンで済ませられたらなお良かった。
最終更新: 2014-10-23T14:06+0900
X:file.extというファイルと XX:alt.strmというファイル。Y:\My\Desktop>echo aaa > C:a.txt
C:\a.txtを作成しようとしてアクセス拒否される。(C:a.txtは C:\a.txtと同じ？)
Y:\My\Desktop>cd /d C: C:\>echo aaa > Y:a.txt
Y:\My\Desktop\a.txtが作成される。(Y:a.txtは必ずしも Y:\a.txtではない！)
C:\>cd /d Y:\My\Documents Y:\My\Documents>cd /d C: C:\>echo aaa > Y:a.txt
Y:\My\Documents\a.txtが作成される。(Y:a.txtがさっきの Y:\My\Desktop\a.txtと違う！)
C:\>echo aaa > T:a.txt
T:\a.txtが作成される。(初登場の Tドライブに関しては T:a.txtと T:\a.txtは同じ)
C:\>echo aaa > Z:a.txt
「指定されたパスが見つかりません。」(Zドライブが存在しなくても、Zがファイル名だという扱いは受けません)
X:a.txtは必ずしも Xドライブのルート直下の a.txtにアクセスするわけではなく、ワーキングディレクトリの履歴が影響してる雰囲気。コマンドプロンプトだけでなく irbでも同じ場所に作成された。ドライブごとにワーキングディレクトリがあるとか？カレントドライブという概念。X:foo\barはカレントドライブを上書きする相対パス？
ちなみに、Cや Tや Yが CCや TTや YYだったりすると、それは(ドライブレターではありえないため)カレントディレクトリの CC(TT,YY)というファイルの a.txtという代替ストリームへの書き込みになるみたい。(代替ストリームの内容を確認する簡単な方法は moreコマンドだって)
/ というパスと \ というパス。大体どちらもカレントドライブの直下を指すみたい。直接 Windows APIを叩いてみてはいないけど。
=C: =D: など ドライブ毎のカレントディレクトリを保持（移動したことのあるドライブのみ）