どうするかどうするかと、考えるだけ考えて発動してなかったが、 ようやく着手し、まあまあ矛盾の少ない状態で動き始めた。 もうこれって出来ても出来なくても、試しに作ってみるしか納得出来なくなっちゃったし。 ダメなら隠し機能と言うことで封印しちゃえば良いんだし。 ウィンドウの実装は、萌ディタの開発日記を参考にして作った。 パクりではなく参考と表現したのは、 パクりたいけど意味わからなくて、完全にはパクれなかったから、 理解できるところまでの実…続きを読む

あれば便利でぜひ実装したいような理想の補完は、開発環境レベルでないと無理。 出来そうな程度の補完では、その機能が付いていてもあまり便利に使えない。 みたいな感じなので、補完やるべきかやらないべきか、って思ってるけど、 やれるかどうかもわからないけどさ。 Alphaって、テキスト内に出てきた単語を拾って補完するのね。 スクリプト編集向けって書いてあるけど、補完は日本語もやるんだね。 テキスト内で一度使った単語をもう一度使うって、 関数名と…続きを読む

こんなのが作りたいってわがまま言えるのは作り始める前だけだから、自由に書いてみる。 例えば小泉って入力したら、次に何を書きたいかを予想して、 総理大臣とか首相とか純一郎とか、あるいは今日子って候補が出てきて、 みなまで打たなくても選ぶだけで済むようにするのが入力補完。 さて、小泉の後に総理大臣や今日子を補完するために、 真魚は人名辞典とか広辞苑とかを添付して連動しなきゃいけないのか？ いや、そりゃ無理だから辞書なしでどうやって候補を探す…続きを読む

さて、8000文字テストで落ちないエディタを三つあげたわけだが、 その三つとも、80000文字テストを乗り切ることは出来なかった。 EmEditorの限界は74483文字で、それ以上だと「見つかりませんでした」が出るか、 条件は不明だが「Too Big」とかなんとかっていうダイアログが出るかする。 落ちるよりはヒットしない方が全然マシ。 萌ディタは、80000文字の貼り付けが出来なかくて「がっかり」ダイアログ。 仕方ないので8000文字…続きを読む

最初は、ヘルプに遅いと書いてあるから速くできるんじゃないかとか、 まだ対応してない物を自前で対応できないかとか、 そういうつもりで正規表現ライブラリの中身を検証していたはずだったが、 途中からはアプリが落ちるか落ちないかの話題に変ってしまったな。 で、一応解決したよ。現在は、8000どころか80000文字でも落ちないようになった。 もちろん、32bitを超える数字のケアはしてないので、そこであふれるだろうが。 32bit以上のケアしない…続きを読む

ショック。 やっぱり自分で使うライブラリは、ソースコード全部把握してから使わなきゃダメね。 正規表現では+や*とかを使って、ものすごく長い範囲にヒットさせる事が出来るわけだが、 TRegExpで、ものすごく長い文字列にヒットさせようとすると、 オーバーフローが起こって何の警告も出さずにアプリが落ちる事がわかった。 たぶんさ、足し算とか引き算とかで桁があふれた場合は警告出るんだろうね。 今回のオーバーフローは、正規表現ライブラリ内のとある…続きを読む

本当に、見えないところの変更はいっぱいやってるんだが、 それを変更したからって全然ありがたくないようなことばかりなんだよね。 バグは結構あって、気がつき次第直しているんだが、 そのほとんどは、作者だからこそ意図してない動作に気がついているが、 よその人が使う分には仕様かと思ってしまうようなくだらないことで、 だからこそ指摘されて直すのではなく、自分で気がついてばかりいる。 いくら真魚なんて使っている人がほとんどいないっていっても、 わか…続きを読む

以前も書いたように、より多くのテキストエディタと同じ仕様にすればスタンダードなのではなく、 よりユーザー数の多いソフトと同じ仕様にすればスタンダードである。 たとえWindowsの仕様が間違っていたり使いにくかったりしても、 Windows風にあわせてやればより多くの人が迷わずに使えるようになるわけで、 テキストエディタにおける動作のお手本は、まぎれもなくメモ帳である。 でも、メモ帳と同じにするわけにはいかない部分もあるよと言う話。 ま…続きを読む

メモ帳での画面表示色って、Windows全体の色設定にしたがうようになっている。 黒地に白で書くようなテーマにすると、メモ帳でもそれに従うようになる。 範囲選択された文字の色と背景も同様だ。 真魚の場合は、Windowsの設定がどうであっても、真魚の設定で動くようにしている。 でも、色設定の項目に範囲選択された文字色と背景色の設定がなく、 範囲選択部分はネガポジ反転で対応している。 白地に黒の文字なら範囲選択で黒地に白になるっていう感じ…続きを読む

JIS/EUC変換読み書き部分を作り直し、今まで対応してなかった文字に対応したので、 文字コード自動判定部分も、新たに対応した領域を使いたい。 jconvert.pasは結構古いものなので、 JIS、EUCを検出することは出来ても、UTF-8やUTF-7を自動判定することは出来ず、 真魚では、まずjconvert.pasの判定もして、 しかも自前で書いたUTF-7とUTF-8の判定をもするという形をとっているわけだが、 全部まとめて1p…続きを読む

なんか文字コードに躍起になっているが、もともと萌ディタの開発日記が発端である。 http://www.geocities.co.jp/SiliconValley-Oakland/3617/progress_2004Q2.html EUCはSJISにない文字も扱える仕様に変更済み。 次にJISなんだが、そこに書いてあるようにいろいろあるわけだが、 読み込みについてはどんな実装をするか悩まずに出来た。 EUC変換のために作ったテーブルを使っ…続きを読む

EUCへの対応については、補助漢字領域の拡張を目的に進めてきた。 すなわち、旧来のSJIS変換を行うとEUCにしかない文字が失われてしまうので、 SJISを介さずにEUC＜-＞ユニコード変換を行うように仕様変更だ。 それはもうできあがったからそれで良い。 次にJISへの対応をどうするかという話だ。 JISは多くの拡張がなされているため、全てに対応すれば中韓国語も扱えるはずだ。 だが、中韓国語拡張したJIS文字コードはどこで利用されるのか…続きを読む

ようやく満足のいくEUC対応ができあがったようだ。 が、乗りかかった船なのでもうちょっと調べている。 http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/kanjibukuro/japan.html これのEUC-JPとShift_JISのところに、ちょっと納得いくことが書いてあった。 ＞いずれを使うかは、使う人の自由にまかされます。 なるほどな。 DelphiアプリでのEUC変換は、jconvert.…続きを読む

自体はどんどん複雑化する。 ユニコードの私用領域であるU+E000辺り以降が、SJISやJISへ変換出来ると言うことを、 ATOKの文字パレットで確認したが、JISの規格では使われていない、 0x7F21から0x927Eまでが割り当てられているようだ。 EUCでは、JISでの0x2121～0x7E7Eに0x8080を加えた、0xA1A1～0xFEFEを使っているので、 規格をはみ出して私用領域を割り当てようとすると桁があふれてしまうのだ…続きを読む

JISX0212の補助漢字領域の資料が正しいかどうかはわからないが、 JISX0208の第一水準、第二水準漢字領域については、 資料には不備が多すぎて使い物にならなかったと言うことで、 CP50220を使って、OSにJISX0208領域を実際に変換させてテーブルを作成させた。 そしたら、CP20932を使ったときと同様、それと同じ文字で問題があった。 これも、SJIS経由での変換とは多少違った物を作ってしまった。 いや、多少かどうかは知…続きを読む