top > かいはつにっき 2005 Q1
2005/01/13
まだ外面だけで全然動きません。
2005/01/12
フォント周りのバグを直した。。。つもり。
今のところ印刷は萌ディタに組み込んで開発しているわけではないので、並行作業です。というわけで、行番号をクリックしたら行全体を選択する、という機能を作ってみます。
作ってみました。
微妙に変なところもあるのですが、めんどいのでばれたら直します。
次は「段落先頭の空白文字列の長さ分、折り返し 2 行め以降（の表示）がインデントする」という、作ると言ったままほっぽいた機能。
まず仕様を詰めるのですが、
- この機能って一言で言うと、なに？
- 大いにインデントした段落でも、素直にインデントするの？
- 箇条書きのような書式にどう対応するの？
1。WZ では「行頭のタブを字下げとみなす」、秀丸だと「行頭のタブ文字で段落全体をインデントする」、サクラエディタだと「折り返し行インデント」です。なるほど。
2 はつまり、折り返し幅のほとんどを空白文字列にした場合、素直にインデントすると見難いんじゃないのかなということです。折り返し幅の最大半分まで有効、みたいな限界値がいるのかどうか。
3 は、「・」や「○」のように箇条書きの冒頭に記号を置いたような書式の場合、それも空白文字列に含めるかどうかです。
・箇条書きのような書式に
どう対応するの？
となるか
・箇条書きのような書式に
どう対応するの？
となるか。
2005/01/11
と思ったらいろいろバグが出たので修正しました。最近細かいバグが多くてすみません。。。
WinSpool な API（DocumentProperties()）でプリンタの設定ダイアログを出してみると、ダイアログを閉じたところで必ず例外が発生するのにハマった。なんか、IDE から実行させてるとそうなるようです。exe 単体だと普通に動く。んーデバッグしにくいな。。。
2005/01/10
印刷する際にプリンタの設定を行うとして、萌ディタ上から最低限設定したい項目というのがあると思います。とりあえず挙げてみると、
- 用紙サイズ
- 給紙
- 用紙方向
- カラーかモノクロか
- 行番号を印刷するか
- 上下左右のマージン
- 段組
- ヘッダとフッタ
- 印刷部数/部単位で印刷するかどうか
とか。この中には、プリンタドライバが提供するプロパティシートで設定できるのも当然あるのですが、プリンタドライバというのは千差万別で、なんでも設定できるのもあればそうでないのもあるので、萌ディタ自身でプリンタのプロパティに頼らず設定できる仕組みが結局必要そう。
2005/01/09
印刷。
印刷ということで、最終的な出力結果は紙です。当たり前です。いままで画面に対して描画していたものが、紙を相手にすることになります。で、描画自体は描画先のデバイスコンテキストが変わる程度しか違わないのですが、プリンタの情報（紙のサイズとか、カラーかどうか、とか）を同時に扱わなければならないのがめんどいです。
それから、印刷プレビューの機能が必須なのですが、これがむずかしい。というのは、紙に印刷したときの状態を正確に反映できないとプレビューとして役に立たないからです。プレビューで A4 用紙 1 枚にぴったり収まってたのに印刷したら 1 文字だけあふれて 2 枚出てきたとか困るっしょ。だからプレビューと印刷は一致する。話のわかるヤツだ。
で、それはどうするのかというと、プリンタ用に描画したものを、画面用に変換してやればよさそうです。ただ、プリンタは解像度が 300dpi とか 700dpi とかざらなので（画面は 96dpi やそこら）、変換のために大量のメモリを消費することになってしまう。
ということで印刷プレビューの実装は、メタファイルを経由するのが定石なんだそうです。メタファイルというのは描画の手順を記録したファイルのことですが、これを 1 つ作れば印刷用にも表示用にも使えるし、ファイルサイズも高が知れてるし、倍率も自由自在で、変倍して描画が崩れることもない。。。といいこと尽くめです。
なんて書いてると、たいてい致命的な問題が出てきたりするわけですが。。。
2005/01/08
今日は妄想が暴走する日なので、まったく新しい実装について。以下はまったくの妄想なので、いずれ実装するともしないとも保証できません。
まず印刷。個人的には、印刷できないエディタは実用度が 3 割減くらいに思うので、これは実装します。Illustrator CS の印刷が使いやすかったのであんな感じにしようかなー。つまり、印刷のための設定（マージンとか、フォントとか）画面とプレビューが統合されてるようなの。
アウトライン。アウトラインって、エディタで何を書くかによって微妙に役割が違ってくると思うのですがどうなんでしょうか。プログラムなんかで関数単位にわけるか、階層つきメモやブレインストーミング用のツールみたいな使い方か、とか。前者だとテキストが主で、その構造を俯瞰するアウトラインは従のような気もするし、後者だとアウトラインの項目間の関係性が主だったりする気がします。勘ですけど。とりあえずいろいろ調査が必要そう。
縦書き。素朴な疑問ですが、単に描画の方向を縦にしただけでいいんでしょうか。Windows の UI 自体が横書き前提で、左→右、上→下という流れが自然になっているところに縦書きのビューを置いただけだと中途半端な気がしないでもありません。横書きだと、だいたいウィンドウの上部を横方向に注視するような感じで操作すると思いますが、縦書きだとウィンドウの右部分を縦方向に注視するようになる。ビュー以外の UI も縦書きに即したものにしないといけないのではないか。
シェルバッファみたいなもの。あればあったで便利そうですけど、純粋なシェルの使い勝手に及ばなさそうというのが気になるところ。標準出力だけなら簡単そうですが、標準入力もハンドリングしないと使い物にはならないんだろうなあ。
あとはなんだろー。grep とか diff とかかな。これらもシェルバッファ上で動けばいいのかも。シェルとは違いますが、端末エミュレータの機能があるとうれしいときがある気がしないでもないです。
今日も雪かきしたら疲れた。。。
ビューがアクティブになったとき、ファイルが更新されていたかのチェックを行うようにしてみました。プロパティ 'compare-time-stamp' が true のときチェックします。
ちょっと印刷周りをもう少しつめてみようかなー。
2005/01/07
あ、やばい。
1 行入力バッファにフォーカスがあるときもアクションのショートカットが有効なままでした。
Buffer.Save() に引数を足すのを忘れてました。ついでに Buffer.Encoding、Buffer.NewlineKind を代入可能に修正。
というわけで、昨日の今日でごめんなさい。つ[nightly build]
2005/01/06
2005/01/05
dfm の無駄な部分を削ぎ落として実行ファイルを 1K 小さくしてみました。。。
字句解析器が切り替わる境界へキャレットを移動させることができればわりと便利そうです。html を編集しているときなんかはタグとタグ外との境界に一発で移動できたり、その他のプログラミング言語なんかだとコメントの内外に一発で移動するとか。
ということで、作ってみようかな〜と思ってふと気付いたのですが、カーソルキーに割り当てるとして、どの修飾キーを使えばいいんだろ。shift は範囲選択に使ってるし、ctrl は単語単位の移動に使ってるし。。。
となると alt くらいしか残ってないのですが、alt は Windows が半分予約しているような微妙な修飾キーなので（メニューのアクセラレータだったり、特定のキーボードレイアウトで特定の文字を打つときに使用したり。。。）なので微妙です。
思いつきですが、shift と ctrl については「ダブルプレス（ダブルクリックのようなもの？）」とか「長押し」とかできるようにしたらどうなんでしょうか。そうするとモード指向が強くなってしまうので修飾キーとはちょっと違くなってしまうけど。
2005/01/04
プロパティ 'restriction-color' を追加。config.txt にも記述を追加。色名 '@restriction' を追加。
アクション 'ReplaceNext'、'ReplacePrev' の実行時、範囲選択されていれば範囲内置換を行うようにした。
ウィンドウの 1 行入力バッファでから置換を実行したとき、範囲選択されていれば範囲内置換を行うようにした。
home と end を押したときの動作を微妙に変えてみましたが、使いにくいかもしれません。とりあえず様子見。
文章で書くととても判りにくいのですが、たとえば home の場合、
- キャレットが段落の先頭にいれば、直前の段落の先頭へ
- キャレットが行の先頭にいれば、段落の先頭へ
- どれでもなければ、行の先頭へ
な感じです。
あ、真魚 2 ができてたんですねー。
去年は丸 1 年エディタを作っていたこともあって、エディタの新規公開や更新の動向にはけっこうアンテナを張ってたつもりなんですが（手持ちのエディタも、52 種類になってしまった。。。）、テキストエディタ業界（？）というのは、変化の激しいようなまったく変化してないような、なかなか不思議な世界だと思います。
個人的には cannia editor がどうなってしまったのか気になる。。。
2005/01/03
というわけで、できてきました。
ええとですね、のんびりやってたので何を作ってたか忘れそうですが。。。「選択範囲内に限定して置換をする」という機能を作ってみました。
こんなふうに、範囲選択した状態で置換をしようとします。
置換のダイアログのオプションに「選択範囲内のみ」というのが増えているので、それをチェックします。で、実行。
ちなみにこのダイアログ、Enter を押すと「次を検索」ボタンを押したことになりますが、Shift+Enter を押すと「前を検索」ボタンを押したことになります。
置換を開始すると、検索の範囲が選択範囲内のみに制限されます。図でグレーになっている文字はアクセス禁止領域ということで、検索対象になりません。
図でいう meta や meta のように、検索文字列がアクセス禁止領域との端点をまたいでいる場合も、検索にヒットしません。
置換が終了すると、アクセス可能領域が選択範囲に戻ります。この辺の動作は WZEditor に似てます。
こういう機能（置換の機能が、置換範囲が選択範囲内か否かに影響されない）は、手持ちのエディタだと WZEditor と秀丸エディタが持っています。で、萌ディタのそれは WZEditor に近い動きになっていると思います。
ただ WZEditor 4.00Fe の場合、置換を終えると置換前のキャレット位置を復元してくれるのですが、このときカーソルキーを押すと意味のないスクロールをするのです。これでキャレットを見失うことが（わたしは）よくあるので地味に使いにくいです。。。
ということで、そこは合わせないようにしてみました。
2005/01/02
ところで、emacs/xyzzy のナローイングに相当する機能の基礎を作っているのですが、emacs/xyzzy のそれのような、ナローイングをしたままの編集、を実現しようとしているわけではありません。範囲内置換を実装するための手段という位置付けです。
仮にナローイングしたままの編集というのを実現するとなると、
- アクセス禁止領域へのキャレットの移動の制限
- ナローイング中にナローイングしたときの端点の退避/復帰
なんかを考えなければならないと思うので、めんどいのです。
というわけで、とりあえず置換に組み込んでみます。
検索のオプションとして、
- 正規表現
- 大文字と小文字を区別
- すべてのバッファを対象
- ループして検索
- 下方向へ検索/上方向へ検索
というのがあります。これらに加えて、「範囲内を置換」というのが増えることになります。既存のオプションとの兼ね合いはどうかというと、「すべてのバッファを対象」との関係が気になるところです。これらの同時指定を許すことはできますが、あらかじめ各バッファで置換したいところを選択してから置換。。。という使い方になるなあ。まあそれはそれで、いいのかも。
あとは検索方向との相性が悪いかも。選択を開始して、下方に選択範囲を伸ばしていった状態で範囲内置換（下方向へ検索）をしたら、当然何もヒットしないです。
なので、範囲内の置換を実行したときはキャレットは選択範囲の端点に強制的に移動させる必要があるのかも。そうすると、「ループして検索」というオプションを無視することになります。
2005/01/01
あけましておめでとうございます。
去年は 6 回のメジャーリリース、29 回の nightly build リリースを行うことができました（我ながら、ヒマなひとだ）。
この調子が続くといいなあ。
とりあえず部分的に表示を変えるようにしてみました。
