« 2013年9月 | トップページ | 2013年11月 »

2013年10月

2013年10月28日 (月)

モードのある(modalな)テキストエディタvi/vim

モードのある(modalな)テキストエディタvi/vim

Time-stamp: "Sat Jan 12 19:24:56 JST 2013"

操作モードをもったテキストエディタvimで、同じくモードのあるかな漢字 変換skkを使って日本語の文章を書いている。vimはモードを持っている使い にくいエディタであるというのが、viを少しだけさわったことのある人とか 必要にかられて止むなくviを使う大方の人の感想だろう。私は毎日のように vimを使っているが、やっぱり使いにくいと思う。それでもvimを使い続けて いる理由は「vimに慣れたから」の一言につきる。

vi/vimには、大きく分けてインサートモードとコマンドモードの二つがあ る。二つの違いは、キーボードから英字や記号キーを押したときエディタの 編集画面にキートップに刻まれた文字そのものが現われる(インサートモー ド)か、または編集コマンドになる(コマンドモード)かにある。

vi/vimではない普通のモダンなテキストエディタの、例えば秀丸を使うとす る。秀丸エディタの起動直後で編集画面にカーソルがあるときに、キーボー ドから「i」キー(キートップには大文字の「I」と「に」が刻まれている)を 押すと画面に小文字の「i」が現われる。もし、かな漢字変換がオンになっ ていてローマ字入力に設定してあれば「い」が現れ、あるいはかな入力設定 なら「に」が現われる。

普通でないエディタのvi/vimではどうなるであろうか。起動直後のvi/vimの 画面の左上隅にカーソルがあることは普通のエディタと変わらない。キー ボードから「i」キーを押しても画面に文字(「i」、「い」、「に」など)は 現われない。

キー押しに何も反応しないように見えるけれども、細かいところが変化す る。豆腐形のカーソルが縦棒形になるとか、最下行のミニバッファと呼ばれ るところに「Insert」や「挿入」の文字が現われる。エディタの設定次第で 編集画面(メインバッファ)と最下行のミニバッファを仕切るモード行と呼ば れるところにかな漢字変換の状態を表すツールバーに似た文字表示が現われ る。

もう一度「i」キーを押したら編集画面に「i」、「い」、「に」などの文字 が現われる。二度の「i」キー押しでようやく編集画面に文字が現われる理 由は、起動直後のvi/vimがコマンドモードにあるからである。

コマンドモードにおけるコマンドとは編集画面への文字入力とはならない 編集操作を指示する命令(コマンド)である。

起動直後のvi/vimはコマンドモードにある。そこで文字キーの「i」を押す ことは、「i」にキーバインドされた編集コマンドの実行をvi/vimに指示す る。その「i」キーには、現在のカーソルがある文字とその直前の文字との 間に文字(列)を挿入(insert)するコマンドが割り当てられている。次に押さ れた文字(英数字や記号)キーは、その文字をカーソルのある文字の前に割り 込ませて表示する。

コマンドモードにあるvi/vimにおいてキーボードから文字(英字・記号)キー を押すことは編集コマンドを発したことになる。「i」キーを押すことは、 以後の文字キー押しは編集画面への文字入力する(インサート)モードへ入る コマンドである。コマンドモードから出すコマンドであって、その落ち着く 先がインサートモードになる。コマンドモードの下請け先となるのがイン サートモードである。コマンドモードの下にインサートモードがあるけれ ど、通常これら二つは同列・同格に扱われている。

vi/vimのコマンドモードでは文字キーにコマンドを割り付ける。直接に文字 と結び付いていない修飾キーと呼ばれるesc, meta, alt, ctrl, shiftとか ファンクションキーそしてカーソルを移動させる矢印キーなどのうちescだ けを使い、他のキーにはコマンドを割り当てない。それは、viが開発された 当時、修飾キーの多くはどの機械も備えているものではなかったという事情 による。

vi/vimの基本的なコマンドは文字のワンキーに割り当ててある。そのうち数 字はコマンドの繰り返し回数を指定するために除かれる。ただ、単独の 「0」(ゼロ)はカーソルを行の先頭に移動させるコマンドになる。二桁以上 の数字であって最高位が「0」でないものは繰り返し回数である。

キーボードを見るとvi/vimのコマンドを割り当てられるキーは84文字であ る。これら84文字に割り当てられたコマンドを覚えればよいことになる。 vi/vimを間に合せ的(vi/vimしか使えるエディタがないような非常事態のと き)に使うのであれば、それらのうち10個くらいのコマンドで済む。

Viがいい、とか、覚えるべき、っていってる人は自分の頭で考えていってい るというより人がいってるからなんだろう。俺からすると、毎日、緊急用 ブートディスクで仕事しているようなものだ。「なんかあったらViが頼り」 ということは認めるが、その「なんかあったら」は年に何回起きるんだよ? そのために使いづらいエディターを自分はともかく、他人に勧める神経がわ からん。Viなんて生産性の低いエディターはトラブった時だけ使えばいいと 思う。しかも、覚えておかなきゃいけないのは、(i, escキー, :, w, q, ! だけでなんとかなる。というより、俺がそれ以外知らないでなんとかなって る)なんで、こんな当たり前のことを雑誌すら書かないんだろうか?Linux のユーザーが増えないじゃないか。(引用終わり)
英字26×2=52文字(大文字と小文字、A~Z, a~z)
記号0x20番台:15文字(!"#$%&'()*+,-./)
 0x30番台:6文字(:;<=>?)
 0x40番台:1文字(@)
 0x50番台:5文字([\]^_)
 0x60番台:1文字(`)
 0x70番台:4文字({|}~)
 英字と記号の合計84文字(viのコマンドに使える文字キー)
-------------------------------------------------
数字0x30番台:10文字(1234567890)(0はコマンドにもなる)
空白(space):0x20
DEL(制御文字):0x7f
-------------------------------------------------
図形文字領域:96文字(制御文字DEL(0x7f)を含む)
-------------------------------------------------
制御文字領域:32文字(0x00~0x1f)
-------------------------------------------------
7bit文字合計:128文字(0x00~0x7f)
-------------------------------------------------
(注)「0x」を前置した数字は16(十六)進数である。

繰り返しの多い冗長な編集作業をいとわないのであれば覚えるべきコマンド は少ない。単純・単調な作業の繰り返しでウンザリしたならスピーディーに こなせるコマンドを探すようにする。何事も必要最小限から始めることであ る。

84個くらいあるワンキーコマンドのうち、とりあえず10個くらいは覚えなけ ればならない。憶えるための鍵となるニーモニック(mnemonici、記憶を助け る工夫)を知れば丸暗記の苦労がない。コマンドの内容を連想させる英単語 の頭文字などを見つけることである。例えば、「i」コマンドの働きを連想 させるのはinsertという具合である。

vi/vimのコマンドをワンキーへ割り付けするには、その前身であるラインエ ディタedをそのまま真似している。前例があるならそれに倣うのが最も無難 である。今までedを使っていた人達に、新しいviをスンナリと受け入れても らうには似通った名前にしておくほうがよい。旧製品であるedを作った人達 はコマンドをワンキーにどのように割り付けただろうか。やはりコマンドの 内容を連想させる英単語の頭文字などを意識したに違いない。ユーザーに覚 えてもらう以前の問題として、作者自身にとって覚えやい割り付けにするは ずである。

vi/vimの発祥は米国であるし、キーボードにはアルファベットが並んでいる 。ニーモニックは英語式になる。日本ならローマ字で挿入コマンド(insert) を「s」とでもすれば少しは通りがよくなったかもしれない。しかし日本人 はそんなことをしなかった。たぶん、その当時の機械では日本語が扱えない 。英語を知らなければマニュアルも読めない。そのまま受け入れるのがいち ばん賢いやり方であった。

日本語で書かれたvi/vimの解説書では、一文字コマンドにその文字を当ては めた関連付け(コジツケ)の理由を明かしてない。edやviにおける一文字コマ ンドのアルファベット割り当てを決めた開発者も、edやviを使うユーザーも 「i」はたぶんinsertでコマンドの働きとコマンド名を結びつけたのだろう との暗黙の了解で済んでいる。英語の解説なら「i」コマンドについて書か れた説明のなかに必ずinsertという単語が現われる。説明しないでも「i」 はinsertに由来するのだと分かる。日本語への翻訳ではそうならない。 「i」コマンドの説明には「挿入」という表現しかない。英語が得意な人な らピンとくるだろうが、英語が不得手なら首をかしげる。コマンドを覚える ためのヒントがなければvi/vimそのものを避けることになりかねない。

英文解説でもニーモニックを明記したものは滅多にないが、次にはその説明 がある。いよいよ分からなくなったら藁にもすがる思いで英語解説をのぞい てみるのもよい。ますます分からなくなることがほとんであるが、時にはま ぐれ当たりで氷解したりする。駄目元(破れかぶれ)で何でも試してみること である。モードのあるvi/vimが使いにくいことは間違いない。日本人にとっ ては、それに加えてコマンド名が英語由来なために覚えにくいという言葉の 壁もある。

A very basic introduction. Good if you're new. Also contains an incomplete, but clear reference manual.
introduction to vi(vi.intro.txt)にコマンドのニーモニック (mnemonics)の説明がある(貴重!)。

viと同じ頃につくられたエディタにemacsがある。こちらはviと違ってモー ドを持たない。起動直後にキーボードから「i」キーを押すと編集画面に 「i」の文字が表示される。文字に結びついたキーを単独で押すことは、そ の文字を編集画面に表示させる。編集コマンドは組み合せキーで指示する。 shiftキーを押しながら「i」キーを押すと大文字の「I」が編集画面に表示 される方式である。直接に文字とは結びついていない修飾キーと呼ばれる esc, meta, alt, ctrl, shiftを押しながら文字キーを押すと文字を入力す ることから離れた別の意味(編集コマンド)に解釈される。

viやemacsはマウスを使うことを想定していない。これらのエディタが開発さ れた当時にマウスはあったかもしれないが実用品ではなかった。マウスを使 えるだけの機械性能がなかったのかもしれない。メニューバーはないから必 要なコマンドを覚えてなければ何もできない。エディタを起動しても終了す ることができないようになったりする。

電源スイッチ(のような押しボタン)を入れればパソコンが起動するけれど、 パソコンを終了させるには決められた手順を踏まなければならない。コンセ ントから電源プラグから引っこ抜くわけにはいかない。起動させるボタンは あっても終了させるための専用ボタンはない。

vi/vimエディタを起動させる手順を実行する際にはエディタを終了させるコ マンドを知っていなければならない。メニュー表示がないエディタを使うに あたって最も重要な最初に覚えるべきコマンドは終了コマンドである。何か のアプリを最初に起動するときは、起動できたら何もすることなくすぐに終 了コマンドを発行して、アプリが機嫌よく引き上げれくれることを確認する 慎重さが必要である。メニューが表示される現代のアプリのつもりでvi/vim を起動したけれど思うような作業ができない。エディタを終わらせることさ えできないという困ったことになりかねない。

vi/vimを終了するにはコマンドモードから「:q」を入力してエンターキーを 押す。コロンを前置するコマンドはExコマンドと呼ばれる。いきなり文字 キーを押すコマンドとちがい、Exコマンドはコロンのあとに文字を打ち終っ たらエンターキーを押さなければならない。

vimのコマンドモードでラージキュー「Q」を打つとExモードに入る。vimエ ディタの中でラインエディタexを実行(体験、シミュレート)できる。そのと きミニバッファに次が表示される。

「Exモードに入ります.ノーマルモードに戻るには"visual"と入力してくだ さい.」

Exモードからvimのノーマルモード(コマンドモード)に戻るには、表示され ているコロンの後ろにvisual(viに省略できる)を入力してエンターキーを押 す。vimを終了させるqをコロンの後ろに入力してエンターするとvimもろと も終了してしまいvimのノーマルモードに帰ることにならない。

vimをExモードにしてラインエディタexを体験するときには、もっと深刻な ことが起こる。「i」コマンドを実行した際にそのことが起きる。vimでの 「i」コマンドは現在のカーソルがある文字の前に文字入力する。vimのEx モードはラインエディタexをシミュレートするので「i」コマンドは現在行 の前に行を新設(挿入)するコマンドになる。文字列を入力しエンターキーを 押してもカーソルが次の行に移る(改行する。つまり何行でも入力できる)だ けで「i」コマンドの実行が終わるのではない。仕方なく新しい文字列を入 力してエンターキーを押す。やはりカーソルが次の行に移る。「i」コマン ドから抜け出せなくなる。

「i」コマンドから抜けるには「行頭にピリオドを打ってすぐにエンター」 である。「i」コマンドを実行したなら、すぐに行頭でピリオド打ってエン ターを押すと、Exモードに居ることのシンボルであるコロンが表示される。 ラインエディタedの解説なら「i」コマンドを終わらせる「行頭、ピリオ ド、エンター」の掟(おきて)はしっかり書かれているがvimの本には書かれ てないかもしれない。

vi/vimやemacsを使うには編集コマンドのキーバインド(コマンドを呼び出す ためのキーやその組み合わせ)を10個くらいは憶える必要がある。これはエ ディタを初めて使う人にはとても重荷になる。viやemacsをクラシックとす るならそれよりは新しい(モダン)な秀丸などではファンクションキーに主な 編集コマンドを割り付けている。そして編集画面の最下行にファンクショ キーの並び順にその機能をメニューとして常に表示するようにしている。 ファンクションキーは文字と結びついてないので予期せぬ文字を入力する失 敗は起こらない。

マウスが使える現在ではメニューバーからマウスで編集コマンドを指定する ことができる。キーボードは文字入力専用として編集コマンドはマウスに任 せるという分業にできる。編集コマンドとキーの関係(キーバインド)を憶え る必要がなくなる。マウスでアッチコッチをさわっても編集画面にヘンな文 字を入力するおそれはない。マウスを動かしているときは文字入力が終わっ て、考えをめぐらせているときになる。マウスこそがパソコンを誰でも使え るようにする一大功労者だったと思う。キーボードを文字入力専用にして、 編集コマンドをマウスに押し付けてしまうと使いにくさは半減どころか解消 してしまう。

ドン・ノーマン(Donald Arthur Norman)はvi/vimをデザインの面からコキお ろしている。とくにvi/vimがモードを持っていること(mode errors)を問題 にしている。ドン・ノーマンは電気工学・コンピュータ工学と心理学を修め た認知心理学の第一人者と聞く。アップルでデザインを担当したこともある という。

vimを使って、これ書いている私もvi/vimは使いにくいと思う。モードを間 違えることはしょっちゅうある。たぶん一分間に一回以上はモードを間違え をおこす。しかし、エディタのモードを取り違えても大した問題ではない。 飛行機が落ちるでないし船がチンするわけでもない。やり直しが手遅れにな ることはない。モードを間違えるデメリットをはるかに超え、あふれかえっ て大洪水になるほどのメリットがあるからこそ使い続けられているのではな かろうか。

vi/vimの習い始めは度々のモード誤りにゲンナリする。しかし、慣れたから といってもモードを取り違えることが無くなることはない。エディタで書い ている内容(文案とかコンピュータのプログラムなど)に注意が向かえばモー ドに対する注意力が鈍る。人間の注意力の総量は決まっている。あることに 意識を集中させれば他のことがおろそかになるのは当たり前である。モード を間違えることは、書くことに集中している証拠といえる。

The most common examples in my collection come from the use of computer text editors, where users try to issue commands while in text mode or to type text while in command mode. Similar errors occur in pushing the buttons on complex digital watches. The autopilots of commercial aircraft provide numerous possibilities for modeerrors; a recent incident in which an Aero Mexico DC-10 stalled, was badly buffeted, and lost the tips of both elevators appears to have occurred because of a mode error in using the autopilot on the part of the crew[6]. The clear implication of mode errors is that they result from inadequate feedback and indication of the state of the system. Many mode errors occur in text editors, with confusions between ``insert'' mode and ``command'' mode. In any event, there are obvious ways to minimize mode errors.
(1)Do not have modes.
(2)Make sure that the modes are distinctively marked.
(3)Make the commands required by different modes different, so that a command in the wrong mode will not lead to difficulty.(unquoted)

モードに関するエラーにエディタの例を挙げてあるが、viを名指しにしてな い。この後ろにあるdescription error(記述エラー)のところにviの名前が 出る。

One class of description errors occurs in the use of computer text editor which have multiple commands, usually based upon one or two keystrokes. Thus, in the text editor ``vi'' (the screen editor supplied with the Berkeley Distribution on the UNIX operating system), each of the letters d, f, g, and u has a different meaning when typed in lower case (``d''), upper case (``shift-d'' or ``D''), or as a control key (``control-d''). Many other keys also have these multiple uses. It should come as no surprise to discover that description errors occur frequently in this editor. (unquoted)

(注)雑誌「情報処理」に文献紹介として取り上げられている。原文とちがい 具体例が省かれているので分かりにくい。

デザインをボロクソに言われてもvi/vimは使われ続けている。どうしてだろ うと考えているときに次の記事を読む。

viの前身であるラインエディタの頃の出力はタイプライター端末であった。 ブラウン管とか液晶パネルのディスプレイ装置ではない。電気仕掛けで動く けれど紙にハンコを押しつけて文字情報を出力するタイプライター方式であ る。ラインエディタが行単位で打ち込み、表示そして編集すると聞くと不自 由と感じる。書き終わったものが見えない。行間に新たな行を挿入するとき 前後の行が見えない。とても見通しが悪いように思える。

かつての安価なワープロ専用機には数十行を表示するのではなくて十二文字 二行くらいしか表示できない機種があった。当時のまともなワープロ専用機 は十万円を超えていた。表示のショボいものは五万円くらいであった。今で は子供の玩具として生き延びている。普通に書く日本語文の一行は20字(原 稿用紙)から40字(電子メールなら35文字くらい)である。覗き窓方式な表示 では一行を一度に見ることができない。一ページ分のレイアウト表示(一行 を一本の線であらわす)が別窓で付いており、今の覗き窓の位置が分かるよ うになっていた。ラインエディタと聞くと覗き窓方式を思い出してしまう。

押されたキー情報がコンピュータに伝わると、コンピュータは受け取った キー情報をタイプライター端末に打ち出す。キーボードとタイプライタ端末 はコンピュータを間にはさむようにつなげられる。手動式タイプライターは いったん印字すると後戻りはできない。タイプライター端末もそうである。 現在のように画面上でカーソルを前に戻して文字を打ち直したり、文字の間 に新しい文字を挿入することはできない。

行の途中で打ち誤りに気付いたとしても構わずに行末まで打ち込むかキャン セルするしかない。後戻りはできない。その行を終わりまで入力したなら置 換コマンドで直す。そうすると何処の行を入力していたのか分からなくなり そうである。キーボードから打ち込んだ文字はすべて紙に印字される。コン ピュータの記憶領域に収められたものを打ち出すのも同じ紙になる。印字済 みの用紙(ロール紙)をたぐりよせれば打ち間違いを含めて全部を振り返るこ とができる。

エディタがタイプライター端末に出力したらタイプライター端末は出力した 内容を忘れてよい。打ち出した内容はコンピュータの記憶領域に残ってい る。しかし、ディスプレイはスクロールアウトするまで画面に表示し続けな ければならない。ディスプレイは記憶しないからエディタを動かしている機 械(コンピュータ)がそれを担当する。

タイプライター端末なら信号を垂れ流すだけでよいのに比べて、記憶のない ディスプレイ装置へは信号を送り続けなければならない。そのぶんコン ピュータの負担は大きくなる。そのために機械性能が殺がれてエディタの動 きが遅くなるようでは困る。ラインエディタをスクリーンエディタに変身さ せるには高性能な機械が必要になる。ラインエディタedやexからスクリーン エディタviに至る道は果てしなく遠い。

「ここで私は、「悪い方がよい」原則の方がよりよい原則であると主張した い。 CはUnixを書くためにデザインされたものであり、New Jerseyアプロー チに従ってデザインされている。従ってCは良いコンパイラが書きやすい言 語だが、同時にそれはプログラマがコンパイラに読みやすいようにコードを 書くことを要求する。Cのことを高機能なアセンブラだと呼んだ人もいるほ どである。初期のUnixとCコンパイラはどちらも単純な構造を持っており、 移植は簡単で、ハード資源の少ないマシンでも動作し、OSとプログラミング 言語に対して人が望むものの50%―80%程度を提供することができた。
ある時点で存在するコンピュータの半分はコンピュータの中央値より遅いか メモリが少ないが、UnixとCはそういう機械でも問題なく動く。「悪い方が よい」という原則は実装の単純さに何よりの重きを置くものであるから、そ れはUnixとCがそういう機械にも容易に移植できることを保証するわけであ る。従って、望まれることの50%の機能を持つ Unix と C で充分なのであれ ば、それらは至るところに広まることになる。そして実際そうなってきた。
Unix と C は究極のコンピュータウイルスである。
「悪い方がよい」アプローチのさらなる利点は、プログラマが安全性や便利 さを多少犠牲にしてでも、速く、システム資源をあまり消費しないプログラ ムを書くように条件付けられることである。New Jersey アプローチを使っ て書かれたプログラムは小さいコンピュータでも大きなコンピュータでも同 様に動き、プログラムは容易に移植が可能なものとなる─なぜならそれはウ イルスの上に書かれているのだから!。
ただし、最初の「ウイルス」が十分によいものでなければならないことは覚 えておかなければならない。もしそうであれば、移植できるかぎりそのウイ ルスが広まっていくことは保証される。一度ウイルスが広まってしまえば、 それをよりよいものにする圧力が生まれ、完全なものの 90%に近い機能が 実現するかもしれない。しかしユーザは完全ではないものを受け入れるよう にすでに条件付けられている。従って,「悪い方がよい」原則によるソフト ウェアは最初に多くの人に受け入れられ、次にユーザをあまり多くを望まな いように条件付け、最後にほとんど「正しい」所まで改善が続けられること になるのである。具体例を挙げるなら、1987年の時点ではまだLispコンパイ ラはCコンパイラと同等の性能を持っていたが,その後では C コンパイラを 改善しようとする人々の方が Lispコンパイラを改善しようとする人々より ずっと多かったのだ。
このことから学ぶべき教訓は、最初に「正しい」方法をとることはしばしば 望ましくないということである。とりあえず「正しい」ことの半分はできる ものを作 り、ウイルスのように広める方がよい。いったん人々がそれに騙 されれば、「正しい」ことの90%までできるように改善が行われるだろ う。」(引用終わり)

(注)デザインの「悪い方がよい」原則の原文は次にある。

| | コメント (0) | トラックバック (0)

« 2013年9月 | トップページ | 2013年11月 »