最終更新: 2010-09-19T00:53+0900
Windowsに不具合続発。アンインストールしたら直った。もうインストールしないよ。
Vista x64向けの各国語版がなかったので英語版をインストールしてみてたんだけど、IE9betaを一回も起動する前から何かおかしい。
IEが OSのコンポーネントでなくただのブラウザだったら良かったのにね。「お気に入り」だってそう。IEのブックマークはスタートメニューに表示されるから「よく使うフォルダ」としての役割を与えられている。URLをクリップする余地はない。
最終更新: 2013-01-11T22:45+0900
どこかに書いた気がするのに見つからないのでもう一度。
サクラエディタは拡張子を見てファイルの種類を区別し、色分けルールやタブ幅、折り返しルールなどを使い分けるが、拡張子がない makefileや ChangeLogはみんな「基本」設定になってしまう。
ファイル名の末尾が .rb だったら Ruby。.js だったら JavaScriptという具合。ファイル名の末尾(といいつつ全体)が makefileだったら makefile、.htaccessだったら Apache HTTPD設定ファイル。
ところがサクラエディタが設定として持ってる、判別のための拡張子リストが
c,cpp,cxx,cc,cp,c++,h,hpp,hxx,hh,hp,h++,rc,hm
という具合に、「ドット省略必須」「スペースorカンマorセミコロン区切り(ヘルプによればカンマ区切りらしいが、「,」と「.」が紛らわしいのでスペース区切りにするのがいいよ)」のリストなもんで、この案は没。広まってしまったドット省略拡張子リストに対処することができないので。
makefileを .makefileだとみなしてファイルタイプを判別するということ。
パッチ> guess_filetype_of_extlessfile.rev2.patch (0.9KiB)
JSという名前のファイルが拡張子が .jsの JavaScriptファイルだとみなされることになるけど、気にしないよね。
>>SourceForge.net: Sakura Editor: Detail: 3581841 - タイプ別設定の拡張子を二重・なしにも対応
0 < _tcslen が使われてないところが好み。zero fill(""での初期化)するかしないかに強い意見はない。結局呼び出した関数が null-terminateするかギリギリまで書き込むかに依存するのだから。自分に影響がありそうな部分にコメントした(試してないので勘違いかも)。
杞憂だった。恥ずかし。GetDocumentTypeOfExtはパッチだけでは全体がわからないから元のファイルにあたってみて、その後でパッチの追加部分に戻ってくるのを忘れてた(という言い訳)。
GetDocumentTypeOfPathでごちゃごちゃせずに、引数として渡されたファイルパス(pszFilePath)をたどって最後のパスセパレータの次の位置を指すポインタを GetDocumentTypeOfExtに渡すだけにしたらすっきりするのに、と思った。a...............................................b.txtみたいなファイルでスタックオーバーフローを起こすだろうか。
@2012-11-06 ちょっと臆病になってここに書くけど、二重拡張子探索のためにファイル名からピリオドを探索するときに _tcschr を使ってるけど _tcsrchr ではないのかな。_tcschr を使ってるなら、すぐ上に書いたようにバッファの確保も _tsplitpathも省いて _tcsrchr(pszFilePath, TEXT('\\'))で得たポインタ+1を GetDocumentTypeOfExtに渡すのと似た結果になりそうだが。
_tcsrchrを使うには表(Shift_JISだと２バイト目が\と同じ)のような文字対策が必要で、_tsplitpathはそういうのも隠蔽してくれてるのかな。だとしたら似た結果にはならないか。
再度考え直し。_tcsrchr が _mbsrchr にマップされる可能性。_mbsrchr はうまくやってくれるのだろうか。
こんなんだからこそ JScriptでパスを扱うときは必ず
new ActiveXObject("Scripting.FileSystemObject").GetFileName
new ActiveXObject("Scripting.FileSystemObject").BuildPath
を使って、自分で文字列処理をしないのだけど昔、_tsplitpath が拡張子付きのファイル名を返してくれなかったりするから自前でやるはめに。Cだから固定長バッファが前提でその長さが問題になってくるからかもしれないが、ケチるんだったらポインタで返してくれたらいいのに。引数のここからここまでがファイル名ですって。正規化したいから無理だって？
..............................................................................................................................................................................................................................................t
というファイル名を、trunk2@2457 + skr_imp_ext_ex.patchで、試してみたけれどスタックオーバーフローは起こせませんでした。ピリオドの数よりちょっと少ないくらい GetDocumentTypeOfExtが呼ばれる(二重拡張子でなく多重拡張子をテストしてる)のは確認できたけれど。
http://sourceforge.net/p/sakura-editor/code/2565/
そういう機能が欲しいと思ったから自分でも改造してたんだし喜ばしいことなんだけど、自分でビルドするサクラエディタに反映するとコンフリクト必至なのが憂鬱。
昔 RUNESOFTのインストーラが、ユーザーがインストール先を変更したときに、レジストリに記録するインストールフォルダ末尾に \ を付け忘れてしまい、おそらくファイル名を連結するときに \ を補わなかったのだろう、ゲームの起動に失敗するというポカをやらかしていた。
最終更新: 2010-09-15T20:40+0900
Command_REPLACE(置換)や Command_REPLACE_ALL(すべて置換)が Command_SEARCH_NEXT(下検索)を呼ぶのをやめたい。連携手段がレイアウト座標を基にした選択範囲しかなく、一文字で表現される CRLFの LFだけがマッチしたときに情報が欠落するし、Command_SEARCH_NEXTが持つ検索以外の事前・事後処理が無駄になるし、正規表現検索が BMatch(検索), BSubst(検索&置換)の計二回行われるのも無駄。
wchar_t単位で検索を行う CSearchAgent::SearchWordが、検索結果をレイアウト座標に変換する際の誤差(前述)を考慮してマッチ範囲を拡大し、結果を不正確なものにするのは誤りだと思う。それより、上の層でこれを呼び出している CLayoutMgr::SearchWordがその配慮を行うべきでは。
m/pattern/flag も s/pattern/replace/flag も同じ一つのパターンとして扱うので、検索用のパターンと置換用のパターンに互換性がない。そうではなく、Search(Compile("pattern", flag), "target", startindex), Replace(Compile("pattern", flag), "target", startIndex, "replace") だったら良かった。(※ "pattern" と "target" と "replace" は実際は二つの引数で表す)bregonig.dllや bregexp.dllを使いながらパターンの共通化や Expandの不足に対処するにはどうするか。自分で Expandを実装し、dllが用意した置換機能(置換パターン)を使わないで済ませる。でもねえ、実装の数だけ仕様がある状態を避けたいから Expand機能をライブラリに用意して欲しいわけで。(置換文字列の $$ が $に展開されなかったり、\1 が展開されたり、$1が展開されなかったり、色々あるんよね)
クリップボードの形式が矩形テキストだったときに検索条件によっては無限ループ。
例えばクリップボードに
789 456 123
という 3行9文字(改行文字はない)がおさめられているとき、マッチと置き換えられるのは 789 であり、456 123 はそれぞれ次行、次々行に挿入される。つまり、456 123 はこれから検索対象になるということだ。検索条件が \d{3} だったり ^ だったり、矩形テキストの二行目以降にマッチするものだったら無限ループ。
置換操作が二階層潜らないとロジック単位にならないというのも悩みの種。検索はロジック単位で行えてるのに、それをレイアウト単位に変換してそれがさらにロジック単位に変換されて、一対一対応じゃないからごにょごにょしないと思い通りに置換されなくて。
どうして最上層のレイアウトを基準にして文字列処理を行わなければいけないか。文書(wchar_t列としておく)の変更を LayoutMgrに通知する仕組みを整備するのを怠って、LayoutMgrを通して文書の変更を行うことで通知を不要にしていることが背景にあるのでは？ GUIを通しての文字列操作に限ってはそれで十分だからそうなるのも仕方ないし、必要に迫られた人間(俺とか)がより汎用的な手段を整備せずにダーティハック*に頼る方が罪は重いかも。
* 挿入位置・置換範囲を文字レイアウト境界まで拡大して、挿入・置換文字列も同じだけ拡張する。
最終更新: 2010-09-07T00:02+0900
24型の液晶モニタもなにげに三大熱源のひとつ。
PS3はここ二か月電源を入れていない。こちらは主に本体の熱さが心配で。
10月は涼しい日が増えるも残暑は厳しく、調子に乗ってこぐと汗がふきだす。11月からが汗から解放されるチャリンコの季節。(去年の経験から)
にしたら、一曲リピートしてるあいだに曲が変わってる現象に改善が見られたんだけど、なにかのはずみで漏れる(やっぱり変わってる)。
(余談) Help > About Songbird... > Credits ボタンをクリックすると文字サイズがリセットされる。
(余談2) ネットワーク上のファイルを再生中に PCをスタンバイにして、再開したときに再生が中断しなかった。毎回こうなんだろうか。だと嬉しい。
最終更新: 2010-08-30T23:07+0900
規制で書き込めないのでここで。
583 ：名無しさん＠お腹いっぱい。：2010/08/25(水) 15:31:52 ID:wtW19SUb0
頭に**がある行はコメント行として緑色にする
という正規表現での色分けと
ABCという言葉は赤色にする
という正規表現の色分けを同時にする方法はありますか？
(省略)
587 ：名無しさん＠お腹いっぱい。：2010/08/30(月) 14:18:00 ID:yI6qoQsb0
>>584
正規表現キーワードって、設定の上下に優先度あるらしいけど（ヘルプ情報）、結局の所、先に検索で引っかかった方が優先されるらしいよ。
wiki でバグじゃないかと報告されて、誰かが仕様じゃボケぇ、なんもおかしなことないわ！ と切れてた。
個人的には、キーワードに優先順位があるならそれに準拠して欲しいと思うんだけどね。
なんていうか、二つの仕事を割り振られたA君が優先順位を決めて作業した結果、端から結果だけ見ると作業をひとつしか終えていないように見えるんだよね。
言葉の意味をはき違えているように思えて、そこが気持ち悪い。
言及されてるバグ報告ってのはこれ。>>BugReport/60 - SakuraEditorWiki
587の、自分の想定した動作モデル以外を認めない姿勢がなんだかなあ。いわく「優先順位があるならそれに準拠して欲しい」いわく「言葉の意味をはき違えているように思え(る)」。バグ報告者の方は単なる理解不足だし、あんなに噛みつかれたことに同情するけど。
優先順位は確かに存在してる。使われ方が 587の期待と違うだけで。たとえに沿って説明すると、仕事は最初から一つしかない。「正規表現キーワードの色分け」これひとつ。何をキーワードとみなすかの判断基準として複数の正規表現が存在してるだけ。複数の正規表現のマッチが重なったときに最も左から始まり最も上にあるパターンが優先される。最も左が優先されるのは正規表現キーワードを含む色分け要素(文字列、コメント、URLなど)間の順序付けにも利用されてる大原則なのでわざわざヘルプに書く必要を感じなかったんでしょうよ。上の方のパターンが優先されるというのは、コメントなど他の色分けより正規表現キーワードの色分けが優先される(これもヘルプに書いてある)と言うときと、全く同じ意味で使われている。不自然なことはない。
「先に検索で引っかかった方が優先されるらしいよ」というのは嘘。「先に」(時間的な前後)ではなく「前の方で」(空間的な前後)なら間違いではないが。
バグ報告した人(たぶん 587も)の希望する動作を強調キーワードに置き換えると、「『IN』『SELECT』『EXISTS』『JOIN』というのを強調キーワード1,2,3,4にしてそれぞれ別の色に色分けするようにしている。強調キーワード1は強調キーワード4より優先されるはずだから JOINの中の INが色分けされないのはおかしい。」という内容になる。Keywordの中に別の Keywordがあるなんて想定はない方が普通でしょう。
7195の System_UPJさんのように動作を理解した上で使いこなしてる人もいる。ヘルプには改善の余地があるとしても今の動作はバグではないし変更されると困る人が(正規表現キーワードの利用者の中では、たぶん)大多数。存在しない別の機能を要望していることに気付くべき。
583へのレスとして用意した、んで規制された、文章ものせとく。
Wikiでも似たような要望がバグとして報告されてたけど、よくある要望なんかね。 手持ちの案はこげな感じ。 1.キャブチャ部分に別の色を指定できるようにする。 2.従属的な正規表現キーワードを指定できるようにしてキーワード内キーワードを 色分けできるようにする。 3.萌ディタのように色分けに状態を持たせる。 実装の難易度 1=2<3 設定の面倒さ 1=2<3 色分けの自由度 1<2<3
最終更新: 2010-08-28T23:16+0900
近所のスーパーにとまとラーメンを置いてるところがあって、これににんにくが入ってるので冬はたいそう体が温まる。でも夏は置いてないんよね。その場所はとんこつラーメン三種類とつけめん四種類に占拠されてる(ばっかじゃねーの。おれは塩野菜ラーメンが好きなんだっ)。エアコンや扇風機や冷たいシャワーで体の表面はよく冷えてるし、夜の間にお腹をこわすことも割とある。体の中ぐらいは温めたいと思ってるのに。