OSTRACISM CO.
■ 日本語エディタ「褌・エディット」−作文職人−の開発日記 巻之七
この日記は一部Nifty-Serveのプライベートフォーラム”Αγορα”（GO AGORA）での書込と重複しています。ま、これを読む大部分の人には関係ないことですね。
さて、特に大きな問題の報告もないので、褌・エディット1.0は暫くこのままで、固定しよう。少なくとも３ヵ月はこのままだな。
ではアップから１０日間の褌関連の話題を記録する。
PoPoさんからウィンドウサイズ変更時の文書位置の件で質問があった。チャンと取説を読むように。読みやすいドキュメントじゃないけどね。
小林英樹さんからのレポートは文面からしてFMACPROからのダウンロードではない。BNNのDATA-ROMだろうか。ダイアログでのキースクリプトコントロールの話であった。そんなにあの取説は読みにくいのかなあ。読みやすくするにはどうしたらいいんだろう。気にすることもないかなぁ。
ひろぽんさんから1.0おめでとう祝電（お祝い電子メールも略せば祝電だ）がきた。マックライフ３月号に「簡単に」紹介するそうだ。連絡さんきゅ。
のんきさんからのレポートは、0.9b4でInline++TSMが使えなかったことを示している。ただし1.0では使えるそうだ。表示周りに手が入っているが、そんなに影響あっただろうか。まあ、今は動くんだからいいか。
小林 栄さんから彼のプラグインのバグの報告があった。まあ、たいした問題ではない。どのみちあのプラグインでエラーになったらメモリサイズを調整するため褌を一旦終らなくちゃいけないからね。
奥山さんから、宮武さんの運営するBBSに褌を転載して「さりげなく」私のWith Youへの要望を伝えるが、どうか、ときた。是非にお願いしますだな、これは。ふふふ。
ソフトバンクの奥村さんから、マックユーザ誌の付録のCD-ROMへの転載を希望するメールがきた。明らかに差込み機能を使った定型文章だった。「転載するのはかまわないが、とりあえずこのメールは気分悪いよ」と返事をしたら、「すみませんでした」とのメールがきた。日本のマック雑誌は９誌も乱立していて、かつ最後発のためか、どこかに余裕がなくなっているのだろう。まあ、編集頑張ってくださいな。
しかしまあ同じような雑誌が９誌もあってよく成り立つねえ。２年後には３誌に戻ると踏んでいるのは私だけだろうか。マック・プログラマ向けの雑誌が発刊されれば、コンスタンスに部数はでると思うんだが、いかがであろう。甘いか？ でも、プログラマ支援もパソコン関係雑誌社の重要な使命だってことを忘れないでほしいな。う〜ん、マックジャパンの方向転換を考えると、商売として成り立たないのかもしれない。
褌1.0 / 1994.02.08
さて、三日坊主の状態がまた始まった。
TEXTjack時代に励ましのメールを何度かもらったライターの伊藤さんからのメールが何通かきた。だいたい１年ぶりくらいだ。月刊パソコン通信に掲載するそうだ。褌は彼の励ましがあってこそ開発が始まったといえる。で、彼のシステムで「Hun Plugフォルダが認識されないことがある」という障害があがっている。当然1.0でのことだ。必ず認識されないのではなく「されないことがある」という厄介な現象だ。私の環境では再現しない。もう少し詳しくソースを眺める必要があるかもしれない。でも、システムフォルダにHun Plugを作るという回避方法があるからいいんだけどね。
５年ぶりくらいにヘッドホンステレオ（俗にいうウォークマン）を買った。アイワの鉛電池で７時間動作するというヤツだ。いやあ、最近のって音が格段にいいのね。走行も非常に安定している。ま、いつまでもつかは非常に疑問ではあるけど。
最近周りでマックを買う友人が軒並み増えてきた。もうそろそろマックもおしまいかなあ。次はどんなマシンを買おう。いまさらWindowsじゃないしな。
マックライフに連載している吉田さんにクイズの答えをメールしたら「正解です」との返事が来た。結構たくさんメールされたんじゃないかと思うが、たいへんだ。「別な方法」は私にはわかりません。そもそも探したのではなく、偶然見つかったわけだからね。裏技探しって得意じゃないのよ。コードを逆アセンブルしてパッチを当てる方がまだラクだな。
さあさあ、今週末はライブだ。
褌1.0 / 1994.02.22
ようやく３年半ぶりのステージ「軽音楽研究会同窓会ライブ」通称「ＯＢライブ」が終った。まあ、OSTRACISM CO.のステージは観客にウケるってことはありえない上に、演奏がうまいわけではないので反応は「ボチボチ」程度であったのはしかたないが、１０年間の歴史上最も完成度が高かったことも確かだ。練習の中で最も出来が良かった演奏が本番だったといえる。
OSTRACISM CO.（オストラシズム・カンパニー）は1984年に結成された「ヨネキ・タケシの作品」を演奏するバンドで、通称オストラだ。私のハンドル名のOSTRAはここからきている。以下オストラと書いたばあいはバンドとしてのOSTRACISM CO.を意味する。
バンドブームは去ったとはいえ、今回のオストラのようなテンポラリのバンドを含めたら、アマチュアロックバンドはとんでもない数にのぼる。ただしその多くはコピーバンドだ。今回のステージでは６つのバンドが出演したが、そのうちオリジナル作品を演奏したのは２バンドにとどまる。
オリジナル作品を演奏するバンドの難しさは「完成すべき目標」が存在しないことだ。自分たちの耳で作品に合う演奏を作り出さねばならない。多大なる試行錯誤を経て作品が作られる。そういった意味ではメンバー全員に「作る側としての音楽的素養」が要求される。「既に存在する音を正確にトレースする能力」よりは「臨機応変に音の場を構成する能力」が必要となる。どちらの能力も重要だが、後者のほうが優先される。当然コピーバンドでは前者の能力が優先される。私はコンピュータの助けを得て作った作品を、バンドという共同作業にもちこむ。演奏能力はまったくゼロでかつ、けして旨いボーカルとはいえないが、作曲者が責任上リードボーカルをとる形態はビートルズの頃からの伝統だろうか。
今回のオストラはメンバー６人中５人までがオリジナル作品を作る人間だった。ドラム担当者がオリジナル作品を作るかどうかは聞かなかったが、「作品に合った音」をかなり追及してくれた。サイドギター担当者は「デモテープ」にまったく存在しない音を要求され、それに応えてくれた。私の作品を「人間が演奏する形」にアレンジしてくれたのはキーボード担当者だ。彼がいなかったら今回のステージはまったく存在しなかったはずだ。
ほとんどの音楽生活を機械相手に過ごす私だが、共同作業としてのバンドは大好きだ。ただし、バンドは所詮人間の集まりなので、「音楽性」なんてことより「人間関係」のほうが重要だ。それが理由の全てではないが、OSTRACISM CO.は全パートまったく同じメンバーでの２度目のステージの経験がない（笑）。
ステージのラストに１０年前の結成当初から演奏していた作品を１曲だけ用意した。昔のオストラを知っている友人へのプレゼントだ。こういった配慮はしかたがないことなんだろうね。ほとんどの観客は「聞き慣れた歌」にしか反応を示さないわけだから。
打ち上げの席で、昔のメンバーが「ＪＲの時差通勤のＣＭの曲、オストラみたいだね。パクられたんじゃないの」といっていた。残念ながらまだそのＣＭを見たことはないが、私がどういう作品を書くのかはそのＣＭで伝わるということだ（爆笑）。そうです、そういう作品「も」結構作りました。あ、当然そのＣＭとオストラには何の関係もないよ。
褌1.0 / 1994.02.27
三日坊主もいいところだなあ。ま、褌のプログラミングは完全に休止状態だからしかたがないか。ソフトバンクからマックユーザ４月号、エーアイ出版から月刊パソコン通信４月号がそれぞれ送られてきた。マックユーザの付録のCD-ROMを使おうとして、またまたCD-ROMドライブが不調を訴えていると判明した。なんでこうなんだろう。このまえ修理したばかりなのに、すぐダメになっちゃう。困ったなあ。ドライブの根本的な欠陥でもあるんだろうか？
褌1.0 / 1994.04.03
困ったな。デヂタルサンプラーが壊れていると判明した。昨年の１２月に買ってからまだまともに使ってないというのに。使ってないからこそ今まで壊れていると判明しなかったわけだけどね。
システムフロッピーを入れても「フォーマットされてないよ」とおっしゃる。てめー昔のアップルIIじゃねーんだから読めよ、と言ってみたところで効くわけがない。やはりここは右斜め４５度からの空手チョップがモノをいう。
むりやり起動してみたところで、今度はデータフロッピーを読むときに「フォーマットされてないよ」とおっしゃる。明らかにフロッピーディスクドライブの故障または不良だ。
おもむろに本体のネジをはずして中身を覗くことにした。１１本のネジをはずす必要があった。マックなんか１本のネジで開けられるのに遅れた設計だ。
Rolandとロゴの入ったカスタムチップが並んでいる。ボードが広いせいか、閑散とした印象を受けた。１本ジャンパー線がある。２つあるSIMMソケットのひとつに８MByteのSIMMが装着してある。買ったショップのオリジナルSIMMで、韓国製のメモリを使っている。普通の７２ピンのSIMMに見えるが、ウチには他に７２ピンのSIMMはないため確認できない。
デヂタルI/Oボード用の空間が余っていて、ハードディスクを内蔵できそうな雰囲気だが、ファンもなく通気性も悪そうだし、だいいち固定できそうもない。危ないことはやめよう。
ROMに張ってあるシールからバージョンが1.0.1と読める。これを我々は「バグだらけ」と読む。そもそもシステムフロッピーが1.0ってのは「まだバグフィックスしてない」としか読めない。
SCSI端子にマック用のCD-ROMドライブのLogitec LCD-M500を接続するとCD-ROMソフトがちゃんと読めた。ここいらへんは親切な設計だ。独自のドライブや９８用でなくマック用だってところが輸出を前提に作られた機械の特色だ。
で、チェックのため宅配便（ヤマトだから宅急便か）でショップに送り返した。
あくまでこれは楽器の話である。今どきの楽器にはシステムフロッピーやSCSI端子があるのだ。
褌1.0 / 1994.04.27
マックファンに褌が紹介されたらしいということで、立ち読みにいった。まあ、紹介するのはいいんだが、正式名称の「褌」という文字がまったくない。まいったな、褌という字を避ける人には使ってほしくないんだけどなあ。ま、いいか。
褌1.0 / 1994.05.04
♪ギガは広いな大きいな．．．1000MByte（1Gにちょっと足りない）のハードディスクを秋葉に行って買ってきた。意外に思われるヒトもいるだろうが、ラジオデパートに足を踏み入れたのは今回初めてだ。でもラジオデパートの店で買ったわけじゃないのでご安心を（何を？）。値段は１１万８千円（税込み）。
フォーマッタで見ると日立の1004MByteとでた。日立のドライブは初めてだ。アセンブリメーカのコンピュータ・リサーチは、昔会社で９８用のハードディスクを使ってた。マックにも販途を広げたんだね。
初めて漢字Talk7.1の付属TrueTypeフォントを全部インストールした。よくもまあ似たような明朝体が幾つもあるもんだ。ポップ体みたいなヤツがあれば完璧なのにね。
で、
♪ギガは広いな大きいな．．．と喜んだのも束の間。どうも様子がおかしい。Startup Deviceで選択してもシステムが起動しない。仮想記憶でディスクを指定しても仮想記憶にならない。しまった、相性の悪いディスクだ！
多分IIcxに取り付けたDayStar PowerCache 50との関連ではないかと思われる。SCSIのタイミングがズレてしまってるのではないか。ClassicIIでは問題はないようだ。取説を読むと、対応機種にPlusがない。詳しくどういう意味かは知らないが、PlusはSCSI機器認識のタイミングが速くて、対応できないドライブが多い、というハナシがある。アクセラレータを入れたIIcxも似たようなことになってしまったのだろうか。困ったな。
最近は買う機材の２台に１台は何らかの不調を訴える。もともと機械を壊すのは得意なのだが（酷使するため）、こうもつづくとイヤになっちゃうね。
はやくローランドからサンプラー返ってこないかなぁ。
褌1.0 / 1994.05.07
1000MByteディスク自体はSCSI ID=0では安定して動いているが、不安があることは間違いない。しかし、むしろ問題は販売店「シスペック」とメーカー「コンピュータ・リサーチ」の対応だ。
シスペックの助言により、コンピュータ・リサーチのサポートに電話すると、「シスペックからの連絡はありません」とのことだった。ま、どのみちメーカーに電話は入れなくてはならないので、システムと動作状況を話すと、「そのような事例はありません」ときて、「アップルの方に問い合わせてください」ときた。いままでメーカーに電話して「アップルに聞け」といってきたのは始めてだ。「サードパーティのビデオボードやアクセラレータを入れたマシンの話をアップルが聞くとでも思っているのか」と聞くと、「アクセラレータメーカーのほうにも問い合わせてください」とのことだ。
コンピュータ・リサーチ側はサポートをするつもりは全くないらしい。SCSI ID=0でのみ安定する理由を知りたいだけなのだが、所詮アセンブリ・メーカーにソノ手の知識を求めるのが間違いだった。
「アップルに聞け」ってのは論外だよなあ。完全に失望した。もう２度と「コンピュータ・リサーチ」の製品を買うことはないだろう。
シスペックに「アップルに聞け」だそうだと電話を入れると、もうひたすら「製品そのものの問題ではないから、返品はききません」の一点張りだった。誰も返品の話なんぞしてないってば。問題の解決方法を知りたいだけだ。そのうち、「漢字Talk7はデリケートなシステムだからまっさらなディスクにインストールしないと起動しないことがあります」なんていってきた。SCSI ID=0で安定する、また、Classic IIで安定するというハナシを無視しているらしい。ヲイヲイ、私はアンタがこの業界に入る随分前からマックを使ってるんだよ、とは云わなかったけどね。「一見さんお断り」の貼紙でもしてろつーの。
シスペック側もサポートをするつもりは全くないらしい。
SCSIの相性の問題に「システムの再インストール」ってのは論外だよなあ。完全に失望した。もう２度と「シスペック」から製品を買うことはないだろう。
動作させる方法が発見されたからいいものの、完全に泣き寝入り状態になった。複数ベンダー問題は、自力で解決せざるを得ないわけだ。ああ疲れた。
近所の「マイルストーン」から１６万円で1GByteを買えば良かったのかねえ。
結論：「シスペック」と「コンピュータ・リサーチ」はダメ。
褌1.0 / 1994.05.11
会社（正しく言えば出向先のSONY）にくだんの「日立ディスク」を持ち込んで（ヨネキさん、これが例のギガですか、ほほう、という会話があったのはいうまでもない）、純正のみで構成されたIIcxでの接続をしてみた。結果は「起動ディスクにならなかった」とでた。
私の購入した日立ディスクはIIcxでは正常な動作がしないと確証した。
「コンピュータリサーチ」（メーカ）に電話すると、前回対応した人はいなかった。そこで別の人物に現象を話すと「ああ、初期不良ですね。新品交換しますから、販売店を通して送り返してください」ときた。イキナリ素直なもんだ。サポートでどういう人物にあたるかは賭みたいなもんだからな。
「シスペック」に電話すると「今日は担当が休みなので、明日電話させるようにします」とのことだった。
翌日、すなわち土曜日、いっこうに電話が来ない。で、こっちから電話した。
「コンピュータリサーチと話して、初期不良だろうから新品交換をするとのことだ」
「わかりました、ではこちらに送りください。検査後に交換いたします」
「そこで調べるのか？ IIcxはあるのか？」
「メーカに送りまして、検査いたします」
「時間がかかるな。代価品はないのか」
「そういったことはいたしかねます」
「１週間無駄にしてるんだ。これ以上待つ気はない」
「そうおっしゃられても、まだ不良確認はお客様しかなさってないので」
「いいか、私は怒ってるんだ、あんた前回の電話で『わたしどもに落度はございません』といったな」
「はい」
「購入の判断のため私はどこのディスクを使っているか聞いたはずだ」
「ええ、マクスターのディスクです」
「この製品は日立なんだよ。マクスターなら動いただろうよ」
「．．．」
「もういい。私は全額返済を希望する」
「．．．わかりました」
「今日は何時までやってる」
「７時までです」
「今日持って行く」
お金は銀行振り込みでしか払えないということだが、とりあえずコトは済んだ。誰が悪いといえば、クセ（バグ）のあるSCSIの実装をしたアップルか、IIcx（を含む以前の機種）のクセを知ってか知らないでかマクスターから日立に使用ディスクを変えたコンピュータリサーチか、ダーティーROMマシンの問題を掌握していないシスペックの販売員か。
帰りに近所の「マイルストーン」に行って「マイクロネット」のディスク（１４万円）を注文してきた。「マシンは３０でしたっけ」「IIcxです」私のマシンがダーティーROMだということは覚えていてくれたらしい。「来週２５６のＭＯが出ますよ」「ＭＯは次だなぁ」「では月曜に納期の方を連絡いたします」
さて、「マイクロネット」のディスクはIIcx問題をクリアできるか？
褌1.0 / 1994.05.14
プライベートフォーラム”Αγορα”（GO AGORA）にてBergさんから「マイクロネット」なら大丈夫という指摘を受けた。これで一安心だ。IIcxにはSCSIのUnit Attention関連の有名な問題があるそうだ。う〜ん、疑ってはいたが知らなかったな。さんきゅ。
SCSI ProbeをはずしてからCD-ROMの調子が良い。コンフリクトだとはおもわなんだ。褌1.0はすでに発表から３カ月を超えた。最近はバグの報告もまったくない。また、私自身も全くバグを見つけてない。なかなか安定したバージョンになったものだ。
MILANO ☆彡さんから高知県の『NEWよさこいネット』と『りね具楽部』に転載すると報告がきた。連絡のない転載を含めると、そうとう増殖してるな。
褌1.0 / 1994.05.15
巨大なVJEの辞書原稿で検索をしていたら無限ループにハマった。久しぶりのバグ発見だ。再現性もある。デバッグぢゃ、デバッグぢゃ。う〜ん、Pascalソースを読むのは久しぶりだ（大丈夫かよヲイ）。
さほどの苦労もなく問題点は発見された。非常に下層のルーチンと、検索ルーチンの整合性がなかった。下方検索はこれでもうフィックスされたかな。上方検索でこんなバグは出るんだろうか。
ソフトバンクから「Macわくわくフリーウエア Part2」が送られてきた。これといった特徴のないソフト紹介本だ。
褌1.1a / 1994.05.26
褌のTSMインライン化計画で問題だったのは、そもそもTextServices.pというＣでのヘッダファイルに相当する、ToolBoxトラップ（DOSでのシステムコールみたいなもんです）を呼ぶために必要なPascalファイルがなかったからであった。そのうえSymantec社はTHINK Pascalのバージョンアップを無期延期（中止だな）したとの噂が、日本での代理店であるSystemSoft社からながれた。現実にバージョンアップがない以上、この噂はいまのところ事実だ。まあ、たぶんバージョンアップ可能な人材がもう他社にながれているのであろう。この業界は結果的に優秀なひとにぎりのプログラマが動向を支配してしまう傾向がある。でかい企業なら安心！みたいなことは米Microsoft社を除いて、ありえない。なぜ米Microsoft社が除かれるかといえば、あそこは「優秀なひとにぎりのプログラマ」ってのがいないからだ。優秀な人はいるが、けしてひとにぎりではない。
で、THINK Pascalのバージョンアップが褌のTSMインライン化計画となぜ関係するかといえば、THINK Pascalの最終バージョン4.0はSystem 7.0対応なのであった。System 7.1対応ではないのだ。7.0と7.1ならたいした違いはないではないかと思われるであろうが、ところがどっこいすってんてん、7.0にはTSMはないのであった。よってTHINK Pascalを使う限りTSMのヘッダであるTextServices.pは手に入らない。
昨年だったか今年の初めだったか、ENDERさんというひとから思いがけずMPW（Macintoshの正式な開発環境：値段が高い）向けのTextServices.pを手に入れた。喜んでさっそくコンパイルにかけてみると通らない。Component Managerを使うためのComponents.pがないのだ。うぎゃ〜。これはQuickTime関連で開発されたToolBoxだ。当然THINK Pascal 4.0にはQuickTime.pなんてものもない。なんとも出鼻をくじかれた思いで「インラインや〜めた！」となったのであった。
もうPascalの時代じゃないんだなぁと諦めてSymantec C++6.0を購入したが、仕事が忙しくなって完全にDISKの肥し状態にしてしまった。全然つかってないうちに7.0にVersion Upしてしまった。購入をはやまったか！グスン。はやく登録しなくちゃ。バージョンアップ案内も来きやしない。
ある日ふと思い立ってＣのヘッダファイルを見てみるとComponents.hがあった。あ〜〜〜これだ。念願のComponents.hだ。こんなところにあったのか。これを自力でPascal化すればコンパイルは通るぞ！ でなわけでComponents.hを調べはじめた。特に知りたかったのはComponentという名前の型であった。あったあった。
typedef struct privateComponentRecord *Component;
typedef struct privateComponentInstanceRecord *ComponentInstance;
そうかprivateComponentRecordが関係するんだな。よしよし。で、privateComponentRecordをgrepしてみたが、そんなものはまったく見つからなかった。あれ〜〜〜。なんでぇ？
またしばらく放っておいたのだが、C++のDebuggerで型が見れるはずだと思い付いた。main()しか持たないProjectを作って、Runさせてみた。"Unknown struct"。え！？ もしかして不定型かぁ！ あ、そうか名前にprivateとつくということは各Componentに依存する型なのか！ しまった、ComponentはただのPtrで良かったんだ。く〜〜。悔し〜。Ｃってのは存在しない型のポインタ型を規定することができるのかぁ。長いことＣプログラマやってきたがそんなの知らなかったぞ。でもコンパイルは通るんだよなあ。よしVC++でもやってみよう。
というわけでTextServices.pに
Component = Ptr;
ComponentInstance = Ptr;
ComponentResult = longint;
を加えて、さらにTHINK Pascal向けにいろいろ手を加えて無理やりコンパイルを通した。やったね。
ようやくTSMの実験を始める足掛りができた。技評のMacintosh DEVELOPER'S JOURNALの創刊号を便りに下準備をすると、VJEからのApple Eventがちゃんとやってきた。とりあえず仮に確定文字だけをInsertするようにコードを書くとと、Floating Windowなしで入力できることが確認された。へ〜〜、なんとかなるもんだねぇ。
さて、またしばらく放っておくことになるであろう。もはやこっから先はNew Inside Macintosh "Text"がなければどうにもならない。買う予定もない。以上！
褌1.1a / 1994.06.27
さて、翔泳社から「Macの宝箱 ビジネスアプリケーションコレクション」が送られてきた。２冊送ってきたが、今まで複数冊送ってきた出版社はない。送ってこない出版社もあるなかでは、なかなかの姿勢だ（偉そうなことかいちまった）。
読んでみると、Edit 7の扱いが不当に小さいと気付く。何か編集部と揉めたんであろうか？ ま、いいか。本で説明する必要のない、親切な説明書があるからだろう。
褌のアバウトが大きく印刷されているのは恥ずかしいな。やはりネーミングはもっと真面目に考えるべきであった。
HUNDOSHI-EDITにふり仮名でフンドシエディットと書いてあるのも恥ずかしい。
まず誤植だが、タイプがSharewareで代価が無償という矛盾が発見された。当然褌はFreewareである。また、解説によると、褌の作者はエディタのことをエディッタと呼ぶそうだが、私はそんなこといった覚えも書いた覚えもないぞ。褌の作者って誰だ？ 多分これはエディットの誤植なのであろうが、別に私はエディタをエディットと呼ぶわけではない。HUNDOSHI-EDITORでは長いから、意味の通じるレベルでソフトの固有名称をHUNDOSHI-EDITに縮小しただけなんだがなぁ。Edit 7もEditor 7ぢゃないもんねぇ。
付属のフロッピーにはすでに国粋版パッチの当てられた褌が入っているが、こんなの聞いてないぞ。正規版→国粋版へのパッチは存在するが、その逆はない。「褌・取扱説明書」は正規版のメニューやダイアログに添って記述されているので、わかんないときに参照するには高度な想像力が要求される。冗談で作った国粋版を正規に配布するとはなぁ。まいった。
アーカイブファイルを解凍（いつのまに解凍って表現がひろまったんだ？）すると全てのファイルがフォルダによる構造もなくフラットに現れる。これは不親切だぞ。これでは何が必要なファイルかわかるわけないぢゃん。「褌・添付一覧」での記載が嘘になっちまう。
”褌の綴れモジュール”なんて言葉が印刷されると、あたしが悪うござんしたってな気分になっちまう。ネーミングの問題だぁ。
「インライン入力でないと我慢できない人はバージョンがあがってその機能がサポートされるまでもう少し待った方がいいだろう」あっかんべ〜〜〜だ。
解説は大抵は「褌・取扱説明書」をですます調からである調に換えただけのようだ。ま、嘘を書くよりはマシか。
褌1.1a / 1994.06.30
たいへんなこと始めちゃったな。試験的なインラインの実装を始めてみて、褌の最下位レベルのルーチンに手を加えなければならないとわかった。
１．未変換文字列や注目文字列を表現するため、画面表示ルーチンに手を入れる必要があること。昔、タブ表示をイヤがっていたのは、ここの実装が画面表示のスピードのボトルネックになっているからだ。
２．現在最下位レベルには文字の置き換えが実装されていない。置き換えの必要なところは削除と挿入でまかなってきた。TSMインラインを現実的なスピードで実装するには、明らかに最下位レベルに置き換えルーチンが必要である。データ構造の問題もあるが、これは相当にでかいルーチンになる。最下位レベルの削除と挿入のルーチンは非常に複雑で、長い間バグの温床になったものだ。
３．インラインにからんで、キャレットの制御も変更しなければならない。マックのキャレットはDOSとは違って、全てアプリプログラムで書いている。キャレットのためのToolBoxなんてものはないのだ。だからこそ飯森さんのInlineTSM++は非常に苦労したソフトなのである。そう、キャレットの何気ない点滅も自分でDrawしているのだ。
TSMインラインの実装は、褌の上位レベルに被せるのではなく、下位レベルに食い込む形にならざるを得ない。これはもはや自分で書いたソースを忘れかけている今となっては、かなりの苦痛だ。
また、kPos2OffsetとkOffset2PosのApple Eventに対応する方法がMacintosh DEVELOPER'S JOURNAL創刊号には全く掲載されていない。これはNIM "Text"を読む以外に方法はなさそうだ。まあ、これは初期の実装では無視してもかまわないだろうが。
この文章は試験的なインライン実装を施した褌で書いている。未変換文字列や注目文字列が判別できないので、いきおい短い文節で変換してばかりだが、なかなかインラインそのものは安定している。と書いていたらアプリケーションエラーだ。しまった、エラー番号を控えるのを忘れていた。アプリケーションエラーは内部的な矛盾がでたという意味だ。だが、その時点の文書を別名で保存できるので安心できる。たいがいのソフトはただコケるだけだけど、あたしゃそこまで考えて作ってるんだよ。しかしなんでコケたんだろう。う〜ん。あ、またコケた。そうかエラー番号8012か。追っ掛けるのはあとだ。
褌1.1a / 1994.07.01
アプリケーションエラー8012でコケる問題は解決した。Apple Eventで、貰えるはずの値が貰えないことがありうるということが判明した。エラーチェックを完全にしないと、予測できない動作をするハメになる。
それにしても、TSM関連でコケると、一旦リセットしないと再テストできなくなるってのはつらいなぁ。起動にめっぽう時間をくうんだよなあ。
インラインの実装で、未変換文字列や注目文字列の表示対応が終わった。これで見た目はもはやインライン化が終了しているかのごとくである。しかし、本当の苦労はこれからだ。置き換えルーチンの実装なしでインラインの完成とはとうてい言えないのである。完全なインライン化はもうしばらく先だ。
しかし、不可解な動きをいろいろとするようになってきた。インラインのApple Event処理は、値のチェックを含めて頑丈にしなければなるまい。たとえ必須情報といえども、エラーチェックくらいはしないと問題があろう。
ウインドウが小さいときに、ウインドウサイズを超えるくらいの未確定文字列を、（ESCキー等で）入力しない状態に戻すと、画面表示が完全には復帰しない。まだ削除関連の下位ルーチンに問題がありそうだ。ここいらへんはしつこいなぁ。
ウインドウを切り替えるとキースクリプトが日本語入力の状態のまま、英文字入力になってしまうことがときどきある。これはなんだろうなぁ。あ、StayHear!か。ＩＭはTSMDocument単位でキースクリプトを記憶している。メニューでのキースクリプトとＩＭが記憶しているキースクリプトで矛盾が発生しているんだ。そうだなあ。文書単位でTSMDocumentを用意すべきかどうかの問題もある。いまのところ素直にウインドウ単位でTSMDocumentを用意しているが、最終的にはどうしたもんか。
また、インライン状態から強制的に抜けるポイントは厳密に調べ上げなければなるまい。
ああ、そうか。インラインに合わせて、文字入力のUNDOの問題があったんだ。これも解決しなければならない。まいったな。
キャレット制御は特に新たに考える必要はないと判明。ともかく最大の問題はテキスト置き換えにある。
資料が全然ないせいで、強力に想像力を必要とする実装作業だ。
褌1.1a / 1994.07.02
キー入力時のUndoを改行単位に変更した。どうも今までのUndoロジックではキー入力に関して現実的な動作をしないことに気がついた。とはいえ行単位でもUndoはあまり有効ではない。有効なUndoはHIDEMARUのごとくに何度も可能なものであろう。とてもじゃないがあれを実装する気力はないな。
入力の単位でのUndoが一番有効的ではないか？ 試しにそれを実装してみよう。
最大の難関であった下位レベル置き換えルーチンをなんとかごまかした。複数行ある段落での先頭での入力はかなり重いが、これをスピードアップするには、本当に最下位レベル置き換えルーチンを必要とする。重さの原因はテキストの再整形と再表示である。シリアルにテキストを入力するときにもっとも場合が多い、改行で終わっている行での入力のスピードアップが再優先であった。これはテキストの再整形にはあまり負荷を必要としない。この場合だけを例外として、特別の速い処理に分岐しているからだ。問題は再表示である。
再表示を特別視しないように実装したら、とてつもなく重くなってしまった。最下位レベル置き換えルーチンが必要か！と考えていたが、従来の再表示に弱冠手を加えてどうにかごまかしたのであった。
通常の入力の大部分が、表示画面に大きな変更を持たないというのが高速化の秘訣。ただし、それを判定するのはいくらかテクニックを要する。
複数行先頭での入力のスピードアップは、もし実装したとしても、３割程度の改善でないかとの感触だ。そもそもテキストの再整形のスピードアップしかできないからだ。とにかく再表示が高負荷なのである。難しさと効果を天秤にかけて、やるほどのモノでないと一応の結論だ。
さて、だいたいの細かい部分の調整も済んだ。もともと持っていたバグも何カ所か潰した。この状態でしばらく使ってみよう。
褌1.1a / 1994.07.03
さらに強烈な問題がでてきた。VJEの動作をもとに実装していたが、ことえりでのチェックを始めた途端、コケまくりなのだ。なぜ！
しかたがないので、TSMイベントを全部ファイルに記録することにした。
でるわでるわ、う〜ん。ここまで違うとはなあ。ことえりでは、存在しない文字列を置き換え元にしなければならないらしい。こりゃコケるはずだ。文字列のハイライトもなんでかしらないが負の数がある。こんなの知らないぞ！
しょうがないのでことえり対応にチェックを追加した。
ことえりをインラインで使っていると、サイズ０のメモリハンドルをハントできなくなるようだ。これは重大な問題だ。サイズ０でハントして、後で拡張するというテクニックが使えなくなる。ソースの多くの部分に手を加えなくてはならない。く〜〜〜！こんなはずでは！
VJEってのはことえりに比べて上品なTSMイベントを送ってくる。VJEとの軟弱な付き合いでは俗世間の荒波には対応できないのか。
かなりソースに手を加えて、やっとことえりで安定して動き出した。でもまだぜんぜん安心できない。
Katana4の動作は更に不可解だ。ことえりと同様の問題に加え、文字列確定のイベントで次の文字が入ってくるのだ。少しでも速度を向上しようという乞食根性か。これが仕様上許されるとしたら、対応せねばなるまい。非常に例外的な動作だと思うんだが、Katana4では日常的に発生する。確定の替わりに次の入力を始めると、確定のイベントに次の文字が必ず入る。確定のイベントが確定だけではないということだ。アルゴリズムを考えなくては。トホホ。
FEPを３つもインストールすると、システムが不安定でしょうがない。誰のせいだ！
褌1.1a / 1994.07.05
結局Katana4の最大の問題は、確定を指示するための次の入力のときに、置き換え場所とハイライトの位置の原点が違うということだ。置き換え場所の指定は確定文字分を含んでいるが、ハイライトの指定は確定文字後の位置になっている。これはどう考えてもおかしい。それともこれが正しい実装なのであろうか。
思い余って、New Inside Macintosh "Text"を買ってしまった。ハイライトの負の数は仕様に明記されてました。まいったな。Katana4の問題はactive input areaとの表記があった。しかしこれを確定文字後と解釈して良いもんだろうか。悩むところだ。確定のイベントが確定だけでない点は仕様らしい。
問題点を整理してみよう。
１．存在しない文字列の置き換えと解釈できるデータ
ことえりとKatana4で発生する。これの対応はしたが、正しい方法かどうかの確信が持てない。
２．確定だけでない確定イベントでのハイライト
Katana4で発生する。ハイライト位置を確定文字後からの相対と考えてよいかの確信が持てない。active input areaという表現がこの実装を意味するかどうかだ。別の解釈をするFEPでは確実におかしな動作をする。
いまのところ上記の問題だけがオモテにでている。もはやこれは実地の試験で確認するしかなかろう。WX2、ATOK8、EGBridgeが安定して動作して、やっと安心できる。マック用のFEPってこんなもんだっけ？
さて、あとはマウス関連のイベントに対処だ。
あ、なにげなくことえりでControl-Kを使ったらちゃんとカタカナに変換してくれた。へぇ、VJEライクなキーもいくらかはサポートしてるんだ。なあんだ。Control-L、Control-Jもきくな。Control-Oだけはだめのようだ。
褌を終了したらコケてしまった。複数FEPを切り替えて使うのはやっぱり危険だ。できたらそういったことはやめてね。
褌1.1a / 1994.07.06
変換ウィンドウの位置はVJEに特有の問題がある。素直な位置データを返すと、左端にあるときにとんでもない場所に変換ウィンドウがでる。まいったな。VJEが一番安心だと思っていたのに、ことこの件に関してはVJEの動作が一番怪しい。しかたがないからVJEがあさっての位置に変換ウィンドウを出さない程度にはデータを変改しよう。あ〜あ。
テクニカルノートTE-27の記述に合わせて、TSMをDisposeする前にDeactiveするようにした。また、NewDocumentのパラメタの間違いも正した。これで少しは不可解な動作も減るのであろうな、アップル君。
褌1.1a / 1994.07.08
マウスによる変換をサポートするためのルーチンを実装した。マウスで変換を使う人間がいるとはあまり思えないが、インタフェースが規定されている以上、実装しないわけにもいくまい。それにしてもここでもことえりの問題がでてきた。文字列の引き延ばしで表示がどんどんズレるのである。VJEではそれはない。ことえりの実装、たぶんEventの順番の問題であろう。こんなところの対処はナシ。TeachTextでも同じ動作をするから褌だけの問題ではない。
どうやらKatana4はマウスでの文字列の引き延ばしの方法がないようだ。ある種賢明な方法ではあろうが、お座なりなFEPである印象は拭えない。
これでやるべきことは終わった。あとはひたすらテストだ。
ＣＯＣＯさんから指摘された「DISKがかたずけられなくなることがある。フォルダを開きっぱなしにしてないか」という問題は、私の環境では再現しない。OpenWDを何度かしてCloseWDをしていない点が気にかかってはいるが、再現しないということは無関係であろうと考えられる。さて何が影響しているのやら。
さて、公開（航海？後悔？）は近い。
褌1.1b / 1994.07.09
「ホーム」へ戻る
「読まなくてもいいよ８」
OSTRACISM CO.
OSTRA / Takeshi Yoneki