« 2013年6月 | トップページ | 2013年8月 »

2013年7月

2013年7月30日 (火)

vi/vimはwriterではなくて、editorである

vi/vimはwriterではなくて、editorである

Time-stamp: "Fri Oct 26 14:23:18 JST 2012"

日本ではプログラマー専用と思われているvi/vimが英語圏では普通の文章を 書く人達にも結構多く使われているらしい。日本人が小説を書くのにvi/vim を 使うというと、たちの悪い冗談と笑い飛ばされるけれども、手動式タイプライ ターの英語圏では、十分に有り得る話しらしい。vi/vimのインサートモードを 打ち直しの効かない手動式英文タイプライターと思えばよいのである。本物の 手動式タイプライターと違ってvi/vimをコマンドモードにすれば直しは自由自 在である。こんな便利なタイプライターは今迄に無かったと案外スンナリ受け 入れられたのではなかろうか。英語圏の人達がvi/vimにそれほどの違和感を持 たないのは、この辺りの事情のためという気がする。

ところでeditには「外(ex-)に与える(L.dare=give)→発行する」の意味があ る。writeは「ひっかく(scratch)」とか「裂く(tear)」から「掻き(書き)付 ける」になったようだ。writeは新しく書き付けることであり、editは既に 書かれたものを仕上げるイメージとなる。

vi/vimは、すでに書かれた文章やプログラムを仕上げる(edit)ことに重きを 置いている。普通の現代的なエディターは、新たに白紙へ文書を書き (write)込むことを重視した使い心地になっているように思える。

vi/vimを起動した直後に文字キーを押しても編集画面にその文字が表示され ることにはならない。例えば、「a」キーを押すとカーソルが豆腐形から縦 棒に代わるのを見る。もう一度「a」キーを押すとカーソル位置に「a」が表 示される。「ナンダ、コレハ!」のカルチャーショックになる。vi/vim以外 のほぼ100パーセントのテキストエディタはモードレス(mode less)である が、vi/vimはモーダル(modal、モードあり)なエディタである。

起動直後のvi/vimはコマンドモードにあり、最初の「a」キーは、現在の カーソルがある文字の後ろに文字を付け加える(add, append)ことを開始す るコマンド(指示、命令)になる。編集画面は、カーソルの形の変化でモード が変わったことを知らせる。「a」コマンドによってvi/vimはコマンドモー ドからインサートモードに代わったのである。インサートモードにおける文 字キーは編集画面のカーソル位置へその文字を付け加える。二回目の「a」 キーでようやく編集画面に文字「a」が現われたのは、エディタがモーダル なためにモードを替えるキー操作後に挿入文字指定のキーを押すからであ る。

インサートモードでの入力が終わったらエスケープ(esc)キーでコマンド モードに戻る。既にコマンドモードに居るときにescを押すとベルが「ピン (あるいはポン)」と鳴る。どちらのモードに居るのか分からないときはとに かくescを押してみる。

実は、インサートモードはコマンドモードにおける編集コマンドの一つとし て装備されているにすぎない。vi/vimは編集コマンドを受け付けるモードに いるのが通常状態なのである。起動直後はコマンドモードにある。既存の ファイルを読み込んで作業を開始するから、vimの起動直後がコマンドモードであ ることは理にかなっている。

極端な言い方をすると、編集画面に文字を挿入すること(インサートモード に入ること)はオマケ機能(コマンド)として備えている。インサートモード において文字入力になる英数字・記号のほとんどすべてのキーが、コマンド モードでは編集コマンドに割り付けられる。コマンドモードにおけるキー ボードは、あたかも編集メニューの一覧表のようになっている。

コマンドモード(編集受け付けモード)にいるのが定常状態であるという特徴 が、vi/vimは、新たな文章を書くwriterではなくて、むしろすでに書かれた 文章の仕上げ(編集)を担当するeditorと呼ぶのが相応しいとする理由にな る。

(注)キーボード図解にvimのワンキーコマンドを付記したチャートは次にあ る。記憶を整理するのに便利である。コマンドをアルファベット順に並べた 一覧表は多いが、これをキーボードの形に並べると一段と身近に感じられるよ うになる。ちょっとした手間で効果絶大になる。

ラインエディタedの進化したものがvi/vimになる。vi/vimに比べてはるかに シンプルなラインエディタedまで遡ると、それが、既に入力済みのテキスト ファイルを直す向きに設計されていると分かる。そう思わないことには、ラ インエディタedの取り扱いの面倒を忍ぶ気にならない。それほどにラインエ ディタedは焦れったくなる使い心地のエディタである。

4.1.5.3 HOW TO DELETE IN TEXT INPUT MODE
While in text input mode, the current line of input cannot be corrected with the same keys used to correct a shell command line. There are two keys available to correct text. @ kills the current line and # backs up over one character at a time on the current line so they can be retyped.
As mentioned in Chapter 2, Basics, the line kill and character erase functions can be reassigned to other keys. (See Section 3.1.3 for instructions.) If these functions were reassigned, the chosen keys must be used while working in ed; the @ and # default keys no longer work.(引用終わり)
(注)テキストインプットモードでの打ち間違えを修整する方法のようだ。 unixではdelで入力末尾の文字を消し、ctrl+uで入力済み(未だリターン押し てない状態)の行を消すことができるとする設定が多い(らしい)。

edのコマンドプロンプトからaコマンドを実行すると直下の行頭にカーソル が移動して入力待ち受け状態(テキストインプットモード)になる。aコマン ドは現在行の次(下)に行を書き込む。一行を入力して末尾でエンターを押す とカーソルが次の行頭に移る。エンターキーを押すことは一行を書き込む作 業を終わる合図ではない。改行して次の行の入力に移行する。つまり、現在 行の後ろに複数の行を書き込むことができる。

ならば入力を終わってコマンドモードに戻るにはどうすればよいのだろう か。テキストインプットモードにいるかぎり文字キーは文字そのものを入力 する。他のedのコマンドを実行できない。ed自体も終了できないバンザイ (お手上げ)状態になる。テキストインプットモードから脱出するには、行頭 にピリオド一個を打ち直ちにエンターを押す。私は、最初にedを使ったとき テキストインプットモードから抜けられなくて大変に困ったおもいをした。

たいていのedの解説には打ち間違えの訂正法が書かれてない。一行を入力中 であって改行のエンターを押す前に既に入力した文字列の中にあるタイプミ スを見つけたとする。これをどうやって直すかである。タイプミスには目を つぶって確定してしまい後から訂正するよりは見つけた時点で直したい。

ところでラインエディタedはコマンドラインから使うツールである。入力は コマンドラインへの入力方式が使われる(ようである)。最悪なケースでは、 backspaceで入力済みの文字列を末尾から順番に消してタイプミスの箇所以 降を打ち直すしかない。

ここでいうコマンドラインとは、例えばwindowsでは、真っ黒な画面にポツ ンと「C:\Windows>_」が表示されるだけの「コマンドプロンプト」のことで ある。表示された文字列の末尾にあるアンダーラインは点滅している。キー ボードから文字キーを打つとアンダーラインの位置にその文字が表示され、 その後ろにアンダーラインは移動する。アンダーラインは次にキーボードか ら打ち込む文字が入る位置を指している。コンピュータに対する命令(コマ ンド)を文字列で入力する場所がコマンドラインである。そして、コマンド を受け付けて表示する場所がコマンドプロンプトになる。プロンプト (prompt)には「to bring forward」という意味がある。コンピュータの鼻先 にコマンドをぶら下げに行くというイメージである。なお、アンダーライン より前にある文字列「C:\Windows>」をプロンプト記号と呼んでいる。

プロンプト記号に続くアンダーラインをカーソル(cursor)と呼ぶのが普通で ある。しかし、このアンダーラインを、既に入力した文字を飛び越えて前の ほうに動かせるとは限らない。古いシステムではカーソルを既入力文字上を 左右に自由に動かせないものがある。その場合は入力文字位置を指すアン ダーラインをカーソルと呼ばずにプロンプトと呼びたい(カーソルには、左 右(上下)方へ自由に動かせるイメージがある)。

プロンプト記号の後ろにコマンド文字列を入力してリターンキーを押すとコ マンドが実行される。もし、コマンドにスペルミスとかオプション(補足事 項)指定に間違いがあったりして実行できない場合はエラーメッセージが表 示されて再び「C:\Windows>_」が表示される。コンピュータは次のコマンド 待ち状態になる。

プロンプト記号の後ろに入力したコマンド文字列に間違いがあることを、コ マンドを実行させるリターンキーを押す前(コマンド実行前)に気付いたとき はどうするか。windows95あたりのコマンドプロンプト(MS-DOSプロンプト) では矢印キーが効かない。使えるのはbackspaceキーだけであった。プロン プト記号の後ろへ打ち込んだ文字列の末尾からタイプミスした文字までを backspaceで消して後半全部を再打ち込みするしかない。

windows95ではdoskeyを起動すると矢印キーが使えるようになる。プロンプ トのアンダーラインがカーソルに進化して文字列の上を左右に動かせるよう になる。後半の文字列を全部消すのではなくてカーソルのある文字を消して 書き直せる。その便利を実体験してなければdoskeyの有り難さは分からな い。また、doskeyが起動していると以前に実行したコマンドの履歴をコマン ドラインに表示できたりする。つまり、コマンドラインに入力した文字列を 編集できるようになる(これをコマンドライン編集と呼んでいる)。

ラインエディタedを使っていた大昔のコマンドラインではコマンドライン編 集が出来なかったであろう。そのためラインエディタedで新規行を入力する ことは一発勝負的な、とっても集中力を必要とする気の重い作業である。間 違いを直す手段は、コマンドライン上でbackspaceを使って修整する。また は、スペルミスをそのままにして書き込みを終えた後で検索置換で正しいも のに置き換える。どちらにしてもスイスイスラスラといくようなものではな い。検索置換とは。一行の中にある間違い文字列を探し出して正しい文字列 に置き換えるという遠回りな方法である。

一行が80字くらいなら途中から直すより全部を初めから打ち直したほうが速 い。ラインエディタのもともとがコンピュータのプログラムを入力するため のエディタである。何百文字もで一文となるような長い文章を書くためのエ ディタではない。貧弱な編集手段でも間に合ったのだろう。

便利な手段を用意すればするほどに、それを処理する機械の動作が遅くなる ようでは困る。当時の機械性能と人間が要求する性能を秤(はかり)にかけて 釣り合いの取れる妥協点を探したということではなかろうか。ラインエディ タedで出来ることはvi/vimに比べて極端に少ない。

ラインエディタedが使われいた古い時代のunixではコマンドライン編集が効 かなかった。eraseキーでプロンプト(カーソル)の直前の文字を消すか、あ るいはkillキーで入力した文字列の行を消してしまう方法でコマンドライン への打ち込みミスを修整するしかなかった。それが当たり前であったため に、その不便さを嘆くような記述は古いunixの解説書に見当らない。

昔のunixの解説本を見ると、eraseかkillキーでコマンドラインへの入力ミ スを直すとしか書いてない。それが当時の当たり前だからである。どっぷり と当たり前に浸かっている人はそのことをわざわざ強調しない。それを初耳 だと驚くのは当たり前な世界の外からやってきた初心者(門外漢)である。ま たは、古き良き時代から現代への激変に立ち合った老人の昔話である。現在 のコマンドラインの解説本は、入力ミスがカーソルを動かして行なえること が便利とは書かない。コマンドライン編集が出来て当たり前の時代だからで ある。現在では当たり前なことも、大昔には意外な(想定外な、思い付かな い)ことだったことに気付かない。

結局のところ新旧の両方をかじったことのある人がその違いを指摘するしか ない。そんなことは誰かが既に書いているのではないかとネット検索したけ れども見つからない。見当違いや的外れかもしれないが、うろ覚えな自分の 経験を書くことにする。年取るとずうずしくなる。多少の間違いがあっても ソレラシキ(曖昧模糊)があればヒントになる。まったく情報が無いというの が一番困るのだと開き直る。

コマンドラインの不便にはバックスクロールできないということもある。た とえば100行のテキストファイルを表示しようとしてwindowsならtypeコマン ドを、unixならcatコマンドを実行したとする。コマンドプロンプトに表示 できる行数には制限がある。例えば25行しか表示できないとすると最終行に プロンプト記号「C:\Windows>_」を表示するからテキストファイルの末尾の 24行までしか表示できない。それ以前のテキストは画面上方向に流れ去って しまう。ラインエディタedを使えば行番号で指定範囲を表示できる。typeや catコマンドよりは、はるかに便利と言える。

ラインエディタedを使うということは隔靴掻痒(かくかそうよう、靴くつを 隔へだてて痒かゆきを掻かく)というか背中を掻く孫の手が見つからないよ うなイライラするものであった。能率が悪すぎる。代りのものがないから止 むなく使うしかなかった。ラインエディタを「書く」機械と思うからその使 い勝手の悪さを嘆くのである。書かれたものを「直す」機械と思えば腹はた たない。ラインエディタの進化形がvi/vimである。ラインエディタより大進 化しているが、その面倒の名残りはある。ラインエディタedの不快(面倒)を 体験すればvi/vimを快適と感じる。

(注)viもラインエディタedと同じようにコマンドラインから使うツールであ る。ラインエディタは行単位で編集するだけだが、viは文字単位でも編集で きるように進化する。そのために自前でカーソルを動かすことができる仕組 みを備える。当時のキーボードには現在のような矢印キー(カーソルキー)が ないのでh, j, k, lキーにカーソルの移動が割り当てられた。
(注)「a」(add, append)コマンドと「i」(insert)コマンドはラインエディ タedとvi/vimのどちらにも現われる。これらは、vi/vimでは現在カーソル位 置の後ろや前に文字を挿入するコマンドである。同じコマンドがラインエ ディタedでは現在行の後ろや前に新しい行を付け加えるコマンドになる。な お、ラインエディタedでは「a」や「i」コマンド実行で入ったインサート モードから抜け出るには行頭にピリオド一個を入れてリターンキーを押す (escキーは使えない)。「行頭ピリオド+リターン」の掟を知らなければ、 ラインエディタのインサートモードから脱出できなくなる。

vi/vimを毎日使うようになっても現在のモードを取り違えることはしょっ ちゅうある。インサートモードにいるのにもかかわらずカーソルを下に動か そうと「j」を押してしまい「jjjjj…」のリピート入力になってビックリす る。あるいはコマンドモードにいるというのにカーソル位置に「(」(開き括 弧)を挿入しようとしたらカーソルが文頭に吹っ飛ぶというようなミスは日 常茶飯で起きている。モードは面倒なものであるけれども、モードを持つエ ディタだからこそ簡単にできることもある。

vi/vimのコマンドモードで「xp」を実行するとカーソルのある文字とその直 後の文字が入れ替わる。二文字で指定するコマンド「xp」があるというので はなくて、一文字消去の「x」コマンドとカーソル位置の文字の直後に貼り 付け(ペースト)る「p」コマンドを連続実行するものである。滅多に使うこ とはないが、いわゆる「読めてしまうコピペ」を作るには便利である。

(読めてしまうコピペ始まり)
こんちには 皆元様気 ですか? 私は 元気 です。
イリギス の ケブンッリジ 大学 の 研結究果 に よると
人間 の 文認字識 の 仕組みは 語語頭尾 の 文字 が 合っいてれば
順番 は 滅苦茶茶 でも ちんゃと 解可読能 と いまいす。
わざと 文字の 順番 を 入かれえて あまりす。
(読めてしまうコピペ終わり)

モトネタは英語圏のもので、単語の最初と最後の文字さえ合っていれば中間 の文字が入れ替わってもなんとなく読めてしまうとコピペそのものに書かれ ている。単語の開始文字と終了文字が目立つように分かち書きしてあるのが ミソである。vi/vimなら「xp」コマンドで簡単に作れる。他のエディタでは ちょっとばかり、てこづりそうである。

なんとなくvimを毎日使い続けている。どうしてvimを使うのかと問われたら 結局のところ「慣れた道具がいちばん」に落ち着く。このままvimでよいの だろうか、最新の評判のよいエディタに乗り換えないと時代から取り残され てしまうのではないかと不安になる。そういうときはvi/vimの歴史や評判談 義をネット上で探しまわる。違う視点からの評価を見つけて「そういうこと だったのか、ヤハリおぬし(vi/vim)デキるナ!」と安心する。今後もvi/vim を使っておれば問題ないと確信する。今回は、エディタとは仕上げる機械で あるという切り口を見つけた。たしかにvi/vimは新規に何かを書き下ろすこ とよりは、既に書かれている下書きを手直しして仕上げることを得意として いるようだ。

vimを学ぶ事、それはあなたが学ぶ最後のテキストエディタになるでしょ う。私が知る限りより優れたテキストエディタはない。学ぶのは難しいが、 使うと素晴らしい。
しかし始める前に警告しておく。vimの学習は最初は苦痛となる。時間がか かり、沢山の楽器を演奏する様なものでもある。 3日程度で他のエディタよ りもvimが効率的に使える様になるなんて事は期待しないで下さい。現実的 に、3日間どころか2週間は確実にかかります。(引用終わり)
vi はそのコンセプトからして純粋で先鋭的な「エディタ」である。それは テキストを書く (write) のではなく、編集する (edit) 。
標準的なエディタは、通常ユーザの目の前にある巨大なキーボードのスペー スを、ただ次の空白に個々の文字を追加するためだけにしか解放していませ ん。けれども、実際のテキストファイルの編集作業において、新しく文字を 打つ、という操作は全体の操作の何%を占めているでしょうか?実際には操 作の少なくとも数割は、時間的にも操作量的にも、書き換える場所を探した り、体裁を整えるための微調整であったりするのではないでしょうか?
標準的なエディタが提供しているインターフェースは、この作業全体のうち で大きなウェイトを占めている、1. 移動すること、2. 検索すること、3. 置換すること、4. 微調整すること、等々の操作に対して、ひじょうに貧し く、また周辺的なインターフェースしか提供していません。それはまるで、 お前はただどんどん書きつぐだけであり、それだけしていればよく、お前が はじめから完璧に書いてさえいれば、削ることやつけ足すこと、あとから記 述を探すことなどは、しなくてもいいはずのことなのだ、と言わんばかりで す。
ですが、自然言語による一般的な文章ならばまだしも、プログラミングにお いては、新しい記述(==プログラム)を一から書き下ろすことはまずありま せん。普通は、すでにあるコードに、新しいものを書き足したり、構成を変 えたり、削除したりするわけです。極端なハナシ、ある作業中に新しい単語 をひとつも書き加えることなしに、すべて検索と置換、コピペで、作業が済 んでしまうこともあるでしょう。そして、それは作業の精度といった観点か らはむしろ望ましい作業法でさえあるのです。なぜなら、新しく書いたもの には必ずといっていいほど typo がありますからね。あるいは、まったく新 しい機能、新しいアプリケーションを新規に書き起こすときでさえ、自分ま たは他人の書いたモックアップや既存のアプリケーションのコードをベース にするのが普通ですし、今回お話しするリファクタリングにおいては、むし ろこの削ることこそが重要でさえあったりするわけです。
そうしたわけで、とりわけプログラミングにおいては、標準的なエディタを 使用していると、キーボードのホームポジションに手が置かれていることは まれで、多くの場合は、右下あたりにあるカーソルキーや、F キー、Ctrl や Shift を叩いていることのほうが多くなってしまいがちです。それどこ ろか、キーボードよりもマウスを握っている時間のほうが長いかも知れませ ん!
けれども、vi は違います。vi でテキストを編集しているかぎり、マウスは 触りません(もし vi を使っている最中にマウスに触ったら、それは何かに 敗北している瞬間です!)。また、よく比較される emacs のように Ctrl キーの位置がきわめて重要になるということもありません。ほとんどの操作 (「すべて」ではありません。UI の設計、それはバランスの問題です) は、ホームポジション上で完結します。新しい行をつけ加えるのも、テキス トの上のほうに戻って何を書いたか確認するのも、文字を削除することさ え、Delete キーや BackSpace キーにちょっと指が出張することなしに、 ホームポジションで触れる範囲内で操作可能なのです。
こうしたことがなぜ可能であるかといえば、vi のインターフェースはテキ ストを書くことではなく、テキストを編集するために設計されているためな のです。カーソルを移動する操作(有名なホームポジション時の右手を使う hjkl でありますが)ことは、新しい文を追加する(i や a それから o な ど)操作と、まったく同列の、同じだけ重要な操作だとみなされています。 検索(/)や、コピー(y)、削除 (d や x)、置換 (c) などの操作についても 同様です。テキストを新しく打ち込む必要があるのは、その必要のある操作 をしたときだけなのです。(引用終わり)

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

« 2013年6月 | トップページ | 2013年8月 »