おちゃめくらぶ掲示板 - 1659321896

1395：御茶目菜子：2012/11/23(金) 23:28:42: テキストエディタを作ってみた
プチコンの1画面プログラムでテキストエディタ「PETIT EDITOR」を作ったにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/2page.htm#edit
http://www.youtube.com/watch?v=cLzTmpmXwAI
プチコンですでに発表済みのテキストエディタというと私が知る限りではえいださんの
「簡易テキストエディタ」しかないにょ。
この簡易テキストエディタは「簡易」の名前の通り最大256文字までのテキストが編集できる
のだけどこれはプチコンで標準で用意されているMEMリソース（読み書きができるシステム
変数MEM$）の最大文字数が256文字となっているためにょ。
この簡易テキストエディタは汎用性重視のプログラムであるため4.5KBもあるというのは
問題ないのだけど個人的に気になった部分といえばカーソルと削除の挙動にょ。
カーソルの移動はWAIT 5で固定となっているためやや遅く逆にゆっくりボタン操作をした
場合にはWAIT 5では速すぎる（一度に2文字削除される場合がある）というのに加えて
削除がカーソルの右の文字が消されてしまうからにょ。（一般的には文字間ではなく
文字上にカーソルがある場合にはカーソルのある場所の文字を削除するはず）
改造して使ってもいいのだけどせっかくならば1画面で作ってみようと思ってできたのが
今回のプログラムにょ。

このPETIT EDITORを作るにあたって注意した点は下記の3つにょ。

　(1)ストレスない動作を可能にする
　(2)ファイルサイズを分かりやすくする
　(3)データの活用を可能にする

(1)これが今回最も重視した点にょ。（どんなに高機能、多機能なもツールであっても
動作にストレスを感じさせるようなものでは使いたくなくなるため）
一般的にはカーソルの移動は初回とキーリピートがかかってからでは異なるにょ。
だからこそ素早いカーソル移動も可能だし、1文字単位で正確に移動も可能になるにょ。
これは押してからのフレーム数をカウントすれば簡単に実現ができるにょ。
しかし、それではリストを1画面に収めるのは難しくなるにょ。
そこで考えたのが WAIT 3+!A*!!B*9 という式にょ。
これによって基本的には3フレーム単位で動作しているけど前のフレームでボタンを押して
おらずこのフレームでボタンを押した場合には3+9＝12フレームのウェイト（WAIT 12）と
なるためゆっくりボタンを押した際に誤って2文字削除するということはほとんどなくなる
と思われるにょ。
そして、連続してボタンを押した（もしくはボタンを押していない）時にはWAIT 3になる
ため素早い動作が可能になるにょ。（WAIT 2だと速すぎで思った場所で止まらないことも
あったためWAIT 3にした）

カーソルの動き（点滅）においてはさすがにWAITのみで管理するのは無理があるため別途
カウンタを用いて管理しているにょ。
この点滅だけど点滅サイクルは1秒では遅いので48フレーム分（＝0.8秒）にしたにょ。
それとカーソルの移動中は点滅をしないようにしたにょ。
問題となるのは削除中のカーソルにょ。
反転表示や重ね合わせ表示で下の文字が見える状態ならば常時表示でも問題ないのだけど
それは1画面で実現するのは極めて困難である（BGFではなくSPUやGRPでカーソル表示を行う
必要がある）ため1文字ずつゆっくり削除しているときは点滅を速くして、連続削除している
ときは点滅そのものを無くしたにょ。（カーソルは非表示）
別にこれらはわざわざ書いているようなすごいことではなく普段PCで使っているテキス
トエディタの挙動に（できるだけ短いリストサイズで）近づけるようにしただけのものにょ。
要するに1画面プログラムで無ければできているのが当たり前のことだけどこれを1画面で
実現しているからこそ高い価値があるというだけの話にょ。

あと問題となるのはPCでは[DEL]と[BS]の2つの削除ボタンがあり「文字削除」という観点
だけを見てもそれぞれにメリットがあるため両方の搭載が望ましいのだけど1つ実装する
だけで（1行あたり29文字制限のため）2～3行必要になるということで両方を搭載はできない
ためにどちらか一方のみの選択を迫られたにょ。（SUBST$によって大幅なリスト短縮が
可能になるかと思われたけど削除では思ったような動作が得られず通常の文字入力にのみ
使用可能だったため[DEL]と[BS]の両方を1画面で実装するのは無理だった）
両方を実際に実装して試したのだけど結局選択したのは[DEL]の方にょ。
これは通常の文字入力や[INS]の仕様上の問題と照らし合わせた結果にょ。

このPETIT EDITORでは基本的に文字は上書きで入力していくけどPCのテキストエディタ
ではデフォで挿入モードになっており、文字入力をした場合には自動的に挿入が行われる
というものが大半にょ。
まぁこれはテキストエディタの仕様ではなく日本語入力システム（要するにIME）の仕様と
なっているにょ。
これは文章を書くのにはデフォで挿入モードがベターだからにょ。
その際に間違えた場合には[BS]を使えば1文字戻りつつ削除可能であるため普通に文字入力を
する場合には[BS]の使用頻度は[DEL]と比べて極めて高いのではないかと思われるにょ。

PETIT EDITORが基本的に上書きで文字入力をしているのはMEM$の編集にはその方が都合が
良いからにょ。
何文字目に何のデータがあるかということが重要であるため挿入によってその場所が移動
してしまうようなことがあると逆に問題となるにょ。
あと文字の挿入は挿入モードへの切り替えではなく1文字スペースを挿入するという仕様に
なっているにょ。
これは上記の簡易テキストエディタでも採用されている方法だけど昔ながらの方法であり
シンプルで分かりやすいにょ。
その挿入の仕様とベストマッチなのが[BS]ではなく[DEL]ということにょ。（余分に挿入
した場合にカーソルを動かさなくても削除できる）

(3)このPETIT EDITORはMEM$の編集や小さなプログラムを書いたりするのを想定しているの
だけどその際に欲しくなるのがファイルサイズ（テキストサイズ）の表示にょ。
これは単純に文字数をカウントするだけなので別に特筆するようなことではないのだけど
これがあるのと無いのとでは文字数に制限があるものを入力する場合の使い勝手が大きく
変わってくるにょ。（上記の簡易テキストエディタではそれが無かった）

このPETIT EDITORではエディタの性質上1行256文字のテキストの編集となっているにょ。
改行を書いてもテキストエディタでは反映されないにょ。（別途活用する場合には改行は
有効になる）
そのため文字入力はカーソルのある場所に自由に行えるような形になっているにょ。
この際に問題となるのはそれによって発生するスペースにょ。
これが文字と文字の間のスペースならばいいのだけど文字の後にあるスペースにおいては
どうするかということが重要なポイントになるにょ。
簡易テキストエディタではデータの末のスペースはセーブ時に自動的に削除となっているけど
MEM$がセーブデータとして活用されるとなるとスペースがデータに含まれる可能性は十分に
あるにょ。
そうなると本来は必要だったデータの末のスペースが削除されるのは好ましくないにょ。

ところがスペースがあるかないかというのは見た目では分からないにょ。（スペースを
示すキャラコード32のキャラをCHRSETで別のものに書き換えるしかない）
しかし、一般的なテキストエディタには[EOF]マークがあるのでそれを付ければいいにょ。
これはリスト短縮によって何とか付けられ他の文字と異なっているのを明確にするため
何とか色を変えることもできたにょ。
これが1画面プログラムでなかったら単に画面にCOLOR 5:PRINT"[EOF]"とするだけで
いい（色を元に戻すためにCOLOR命令はメインルーチン内に2つ必要になる）のだけど
数文字削るのにプログラムの大幅な書き直しが必要になる1画面プログラムでここまで
できたのはリスト短縮の賜だと思われるにょ。

(3)さて、MEM$の編集だけならば簡単だけど最低でもセーブとロードの機能を付けないと
ツールとしては事実上使いものにはならないにょ。（MEM$の内容はCLEARでは消えない
とはいえホームメニューから実行時にはMEM$は初期化されるため）
これは行数制限が無ければサブルーチンで簡単に作れてしまうのだけど1画面ではそんなに
簡単にサブルーチン化はできないにょ。（ラベルを使えばそれだけで1行分が無駄になる）
そこで考えたのがポケコンの2LINE（2行）プログラムでは良く使っていたセーブとロードの
一体化にょ。
メニューからではなく一方通行的にセーブとロード機能を実装するということにょ。
ここでメイン→セーブ→ロードとしても良かったのだけどやはり編集作業がメインになると
ロードを最初に行う可能性が極めて高いためロード→メイン→セーブと実装したにょ。

そこで問題になるのはボタン入力の煩雑化にょ。
セーブをするだびに再びロード画面となるわけだからね。
そこで有効活用できるのがmkIIでは[A]ボタンに[ENTER]キーが割り当てられているという
ことにょ。
これを使えば[A]ボタンを押すだけでロード画面をスキップできる・・・と思いきや
INPUTでは空入力ができないのでLINPUTにしたにょ。
これによって、セーブをして再び編集画面に戻るためには[A]ボタンを2回押すだけで
済むにょ。
これがメニューシステムだと少なくともセーブを選択・確定の操作があるためボタン操作が
2回以上必要となるためメニューシステムと比べて煩雑になってないにょ。（これも機能が
セーブとロードしかないため）

編集したものはセーブ画面を通過することでMEM$として確定されるにょ。
これはうっかり間違えて編集してしまっても確定されないようにするためにょ。（もしも
間違えて編集してもBREAKしてからRUNし直せば編集前のMEM$がそのまま残っている）
それとこのPETIT EDITORでプログラムを作ってもMEM$はあくまで変数でありプログラムに
実際に活用するためにはリテラル型（定数）にする必要があるにょ。
プチコンにおいてそれを唯一実現可能にできるのはファンクションキー経由にょ。
これはKEY 1,MEM$とすれば[F1]にMEM$の内容が入っているからそれをプチコンの編集モード
において[F1]を押すだけでそのリストが入力できるにょ。（実行動画を見てのように改行
マークが含まれるデータならば自動的に改行も行われる）
つまり、256文字以内のプログラムであればこのエディタで書いたプログラムは実際の
プログラムで簡単に活用が可能になるということにょ。
短いけどよく使うルーチンを記述しておけば利便性は極めて高くなるにょ。

さて、このようにこのPETIT EDITORをどのような意図で作ったのかが分かってもらえたと
思うけど私は1画面だからといっても使えないツールでは意味がないと考えているため
自分で十分に実用になるものを作ったつもりにょ。
実行動画の中に出ている1行プログラム「100m走」もこのPETIT EDITORの途中バージョンで
作られたものにょ。

◎1行ゲーム「100m走」
ACLS:T=0WAIT 99BGMPLAY 3FOR X=6TO 174T=T+1X=X-!BTRIG()LOCATE X/6,9?"　人":?T/50,:WAIT 1NEXT:BGMPLAY 5
　　（※「人」は人型のキャラを示す）

様々な実証テストを重ねて作ったので1画面で出来る範囲内としてはこれ以上ないくらいの
できになっていると思うにょ。（今回はMEM$の編集をメインと考えて作ってきたたため
上書き入力＋[DEL]による削除となったのだけど機会があれば挿入モードでの入力＋[BS]の
派生バージョンでも作ってみようかと思う）
ツールの場合は行数（リストサイズ）さえ増やせばいくらでも多機能にできるため1画面
プログラムでは10月28日にも書いたようにどれだけの機能を詰め込めるかということを重視
しているにょ。
もちろん、それらの機能を含有した高性能なツールがあればいくら1画面で作ったといっても
実際に出番はないだろうけどPETIT EDITORで求めていた機能を実装しているプログラムは
プチコンでは無いためその存在価値は十分にあると思うにょ。

ちなみに1画面プログラムコーナーの量が増えすぎて重くなったのでプチコンを購入して
2年目を区切りに今回から別ページにしたにょ。（1画面プログラム2ページ目となる）
このレベルのクオリティの作品を頻発するのは難しい（普通に作れば1～2時間で出来るような
ものでも限界に挑戦した1画面プログラムならば10時間や20時間は平気でかかってしまう）
けど1ヶ月に1本くらいは作っていきたいと思うにょ。
今のところ9月にPETIT RUN mkII、10月にPETIT KEYBOARD mkII、11月にPETIT EDITORを
発表しているので何とか1ヶ月に1本ペースは維持できているけど一体どこまで続くこと
やら・・・。