検索結果

キーワード: ‘文字’

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

やる気がないときは一切やらないのに、いったんハマると抜けられないな。 折り返しやEUC関連の修正と変更は、手作業でばかりやっていたわけではない。 数万の文字についてそれが何語だとか記号だとか、変換先がどこだとか、 人間様が手作業で分類してたら気が遠くなるわけで、 既に他人によって分類されたデータを利用しやすいように編集するという作業は、 それ専用にプログラムを書いてやらせたりとかしているわけだ。 プログラムをプログラムに書かせるみたいな…続きを読む

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

折り返しに関してアレコレとやってたら、深みにはまりつつある。 まず、動作確認中にバグを一つ見つけた。 小さい「っ」とか「ゃ」を行頭におけないっていう禁則が動いてなかった。 コレは単に内部で間違って逆の処理をしてただけなので、修正は1秒で終わった。 それは別に良い。 今悩んでいるのは、アポストロフィだ。 そもそも、一つの文字につき、決めなきゃいけないことがどれだけあるかと言うと、 ○色分けで何扱いするか ○折り返すときに切れる場所か ○単…続きを読む

偽パッドはエディタエンジン自体を自作したわけではなく、 OSについてくるリッチエディットをプレーンテキストモードで使い、 OS任せで描画したあとに、マークなどを加筆する形で動作している。 よって、偽パッドが折り返しでどんな処理をしているかは一切わからない。 メモ帳とかなり近い動作をしているわけだが、違う動作もいろいろあるわけで、 メモ帳ではロシア語のワードラップはしないが、リッチエディットはするらしい。 で、真魚は出来ればメモ帳準拠で行…続きを読む

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

1708 letters | 608 views | コメントする

TEditorを使っていた真魚1.xxでの仕様は、元のテキストがどの改行を使っていても、 読み込んだ時点でCRLFにしてしまって、EUCで保存するときのみLF統一で、 それ以外の文字コードではCRLFで保存しちゃうということで、 WindowsのエディタなんだからWindows風の処理をするのは当たり前で、 唯一Windows以外で使うことがはっきりしているEUCでのみ、ケアしてあげる方法にしてた。 バージョン2.xxでは、どの改行コー…続きを読む

>ツールバーに検索バー これやんなきゃ良かったな、失敗。 せっかくここにツールバー置いて、そこからでも検索できるようにしてみたけど、 全然使わねーやこれ。 と言うのも、小窓へジャンプするショートカットがないせいなんだけども、 たとえ小窓にジャンプするショートカットがあったとしても、Ctrl+Fで検索窓だしても一緒だ。 既に作り終えた邪魔なものをもう一度取り除くのが惜しいようなそうでもないような。 そこで、これをインクリメンタルサーチ専用…続きを読む

検索用ツールバーを作ろうっていうのは萌ディタのパクリだが、 萌ディタって、あのバーがあそこにあることが前提で動作するわけで、 真魚は検索用のバーを使う人と使わない人がいることを考慮したい。 Ctrl+Fでバーにフォーカス移動ではなく、やはりダイアログを開き、 コレまで通りの操作でコレまで通りの動作をしたい。 ツールバーが必要な人はマウス派だと断定できるんじゃなかろうか。 マウスでそこをクリックして語句を入れ、マウスで下へとかクリックする…続きを読む

これもSJISのエディタでは特に考えなくてもいい話だ。 アルファベットが連続していたら、その途中で折り返したらいけないってだけ。 その際、どれがアルファベットの文字なのかってのは単純なんだよね。 SJISには半角と全角のアルファベットがあり、 半角のアルファベットは途中で折り返しちゃいけなくて、全角は折り返し出来る。 そもそも全角のアルファベットはSJISの文書では使えるけど、ASCIIでは使えない。 だから、全角の文字は日本語流の折り…続きを読む

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

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

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

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

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