OSTRACISM CO.
■ 日本語エディタ「褌・エディット」−作文職人−の開発日記 巻之三
山西さんからJAM環境での不具合が報告された。わかっていたことだが、まだ実際にJAMを使っているひとがいるとは思わなかった。
相田さんからの報告で、単語移動での問題がありそうだ。ただ、システム６ではでない。確認作業はかなり延びそうだ。また、AutoDoublerでは褌の綴れが認識されないそうだが、ファインダ情報が変えられているとすればしかたがない。認識する術がなくなっているわけだから。
褌0.9b / 1993.08.06
今年の温泉旅行は、やはり雨にたたられてしまった。避暑の予定ではあったが、寒いというのはどんなもんか。今年の農作物は壊滅である。
ひろぽんさんの報告により、発行機能で問題があるらしい。ソースをPUBLISHjackと比べたら決定的な違いが存在したが、PUBLISHjackの方が強引な発行を行っている。できたら褌の方法のまま解決したいものだ。ただ、テスト環境がまったくない。しかたがないなあ、褌でPICTを発行する方法を考えよう。その前に、システム７をインストールかあ。クラ２に入れるつもりはなかったのに。
奥山さんからの要望は、開ける文書数を増やして欲しいとのことだ。確かに最大文書数は定数で決っているから、宣言を書き換えるだけではある。しかし、システムのバランスを考えるとそうはいかない。．．．かなあ。１００程度ならたいした負荷にはならないのかもしれない。でも、マックって１００もウインドウは開けるんだろうか。
現在の方法だと、必ず最初に扱える文書数×５１２バイトの領域を変数のためにNewPtrしている。１００×５１２バイト＝５０Ｋバイト．．．って、もはやたいした大きさではない。８ＭＢｙｔｅシステムが貧乏の時代なんだよなあ。実験してみよう。
尾崎さんからは、英語システム＋日本語キットでの動作報告を貰う。褌は「現在」の日本語システムに強く依存しているため、ちょっとの変更でダメになってしまう危険がある。今後、いつまでCharWidthで漢字ストライクサイズを得ることができるかは、保証されていない。最初の難関はQuickDrawGXである。もっとも、漢字がスケーラブルになったら、結構多くののワープロやＤＴＰソフトが死ぬのではないかと思われるが、どうであろう。甘いかな。
褌の綴れの自作、頑張ってください。
褌0.9b / 1993.08.10
発行のアップデートが引用先に通知されない問題を、やっと解決した。セクションレコードのモディファイ日付時刻を自分で設定しなくてはいけないとは、気づかなかった。こんなことIMにも「プログラマのためのSyetem 7」にも載っていない。NIMだとどうなんだろうなあ。PUBLISHjackもこの線に沿って改造を入れなければ。
発行の試験のため、褌で開いている文書がPICTだったばあい、PICTとして発行するようにした。この機能を消すこともなかろう。ただ、何に使うかは思い付けないが。
開ける最大文書数を、ヒープのサイズから計算するようにした。完全に安全な数値とはいえないが、通常の使用で問題がでることはまれだと思う。固定の文書数だって完全には安全ではないのだから、たいした話ではない。デフォルトのヒープサイズのまま、８００Ｋバイトの文書をいくつか開けば、当然落ちる。ただしこれは「正常に」落ちるのである。メモリが足りなくて落ちるばあいモディファイされた文書は保存動作を行う。保存動作は新たなメモリを要求しないように作られている。
さて、問題の９９文書オープンの実験を行った。というか行っている。この文章は９９個の文章の一つとしてオープンして書き込んでいる。根本的な問題はなさそうだ。さすがにこれだけオープンすると、ウインドウの反応が妙に重くなってしまう。これはしかたがないことだろう。それでも入力におけるレスポンスは変化がない。
たくさんの文書を開いて、一部の文書を閉じると、Windowsメニューのグレー表示になるはずのアイテムがグレー化されない。褌の問題なのだろうか？ 調査してみよう。
９９もの文書の終了作業はとんでもなく時間がかかる。可能だというだけで、こんな運用は推奨できない。
メニューの状態を制御できるのは３１アイテムまでであるとインサイドマック徹底ガイドにある。やはりそういう仕様が存在したか。システムがそうなんだから回避方法はないということだ。諦めよう。
ともかくマックは１００個のウインドウをオープン可能であるとわかった。
褌0.9c / 1993.08.11
Control-Aでの単語移動で、落ちるパターンが発見され、修正した。まあ、表示行数が６行以下のばあいなので問題が報告されることはないだろう。
日本語単語選択ONのとき、単語移動時の「無視すべき種別」判定をシステムに任せずに自力で行うように変更した。漢字のスペースや読点、句点も「無視すべき種別」に加えることにした。これで相沢さんのシステムでの問題の切り分けが可能になる。バージョン番号をbからcにしたが、ベータ版という意味がなくなってしまうので、b1と表現することにした。褌1.0までは試練が多そうだ。
まだ１２日なのにもう、パソコン雑誌が書店にならんでいた。マックデヴェジャを買うついでにマパも買った。マックデヴェジャのQuickDrawGXの話からは、褌の実装方法が安全かどうかはまったく読めない。
褌0.9b1 / 1993.08.12
褌の綴れ、予定４本中３本が終了。あとは最も難関のCR挿入である。
褌0.9b1 / 1993.08.14
最近まったくプログラムをする余裕がなくなった。はやいとこ褌の綴れをアップしたいもんだ。困った困った。
９９文書対応のアップ要求も来てるんだよなあ。休暇が始まるまでは身動きできん。しばらくはこのまま！
そうそう、アメリカからIIcxが帰ってきた。速くなっているのはいいんだが、実数演算の高速化を指定すると、やたらと「不当命令」エラーがでる。原因はなんだろう。漢字Talk7.1との相性があるんだろうか。
褌0.9b1 / 1993.08.24
いやはや、凄い台風であった。相変わらずアメリカ帰りのIIcxは不調を訴える。ノーマルなシステムで、何も起動していない状態で、コロっと落ちる。明日、マイルストーンに持っていって誠和システムズに送ってもらおう。
さてやっと夏の休暇が始まる。これで褌の綴れを完成させることができるはずだ。４本目の綴れは２本に分けることになる。合計５本の綴れだ。
深谷さんのメールが「熱烈なるファンレター」だとは思わなかったなあ。確かに、ダメだと判断したソフトに対して、あんな長大なメールを書くわけがないか。
最近は、SONYでMS-Windowsの仕事をやっているが、やればやるほどMS-Windowsが嫌いになる。マシンは486DX2 66MHzで、最高なのにね。
MS-Windowsのアプリはたいてい、デフォルトのウインドウ位置を持っていない。毎回起動するたびに位置やサイズの調整をしなければならない。たぶんこの点が実用時に最も気になるところだ。勝手に決めていいから固定して欲しい。できれば前回位置を覚えてくれるといいんだけどね。
MS-Windowsの良い点は、完全にウインドウに対するメッセージシステムである点だ。ウインドウのハンドルさえ手に入れば、アプリ間のメッセージ通信は自由に実装することができる。メモリの共有も可能となる。当然プロセスコントロールを自力でやるはめになるが、Waitさえ実装できれば（できるんだよね）排他制御や同期を実装できる。まるでマルチタスクじゃん。
マックはシステム７でやっとPPCやAppleEventが用意されて、アプリ間通信のベースが用意された。でも、時期的に見れば、同時なんだろうね。MS-Windowsのver2なんて使えなかったのだから。
マック： Edition - AppleEvent - PPC
MS-Windows： OLE - DDEML(DDE) - Message
と階層化していいだろう。マックでアプリ間通信の実験をしてみよう。マルチタスク的に動作してくれるかな？
ユーザとしてはMS-Windowsは嫌いだが、プログラマとしては面白いシステムだと思う。所詮マックのプログラムはシングルタスクのままなんだよね。楽なんだけど、マルチタスクプログラマをワクワクさせる部分がない。ま、PPCを調べてからにしよう。最近はスレッドもあるそうだから期待はしてるんだけど。
でも、偽物マルチタスクのテクニックなんて、Windows NTが主流になったら意味なくなっちまうんだよね。
褌0.9b1 / 1993.08.27
さてさて、改行挿入の綴れが完成した。問題なく動作しているようだ。あとはスペース挿入だ。
スクリーンセーバから回復したときに、キャレットの表示がおかしくなる件を対処。結局は全画面に対してアップデートがかかったときに、必ず画面消去をすべきだということだ。
ウインドウサイズを変更したときにキャレットが先頭に行かないオプションを実装。でも行の再評価には時間がかかる。どうにかならんもんかねえ。TeachTextの行再評価は結構速いもんなあ。TextEditToolBoxは優秀なんだよね。
褌0.9b1 / 1993.08.28
スペース挿入の褌の綴れが完成したので、これで予定の純正綴れは全部用意できた。やっといくらか肩の荷がおりた気分だ。自分自身も完全にTEXTjackから移行できる。ま、最近はまったくTEXTjackは使っていなかったけどね。
褌のバージョンを0.9b2としよう。
褌0.9b1 / 1993.08.29
「ホーム」へ戻る
「読まなくてもいいよ４」
OSTRACISM CO.
OSTRA / Takeshi Yoneki