●この本で述べようとしていること
エディタ --- 正確には、テキスト・エディタ(Text Editor) --- は、
コンピュータ・ユーザ(特にプログラマ)が、最も長時間使用する
ツールだろう。
テキスト・エディタは、テキスト(文章、ソース・プログラム等)を
作成するための道具である。紙に鉛筆で字を書くように、コンピュータを
使用するときにはエディタを使ってテキスト・ファイルを作成する。
ちょうど、原稿用紙の升目に文字を埋めてゆくように。
絵等は描けないが、文字を書き込んでゆくことができる。
タイピングがある程度までいけば、エディタを使用することで
紙に書いているとき以上の速度でテキスト作成ができる。
エディタの機能を利用すれば、更に作業量を減らすこともできる。
一旦、エディタの機能／利用法について熟知すれば、それ以前とは
比べられない位作業効率の向上を図れる。
紙と鉛筆で行っている作業の殆どは、エディタでファイルを作成することに
置き換え可能である。その作業が紙と鉛筆の時よりも際立って
高速化されたならば、今迄と違った別の可能性が生まれてくるだろう。
それが何かは、分からないが。少なくとも時間が浮く以上、何かが起こる。
筆者は、作業量を減らして快適にコンピュータが利用できるような
エディタの機能／利用法を知って貰いたいと考え、この本を著すことにした。
エディタには、筆者がUnix上に現存する最強のエディタと信じる
GNU Emacsを選んだ。
この本では、スクリーン・エディタ GNU Emacsの基本的な概念／編集操作に始まり、
実際のプログラム開発での応用法に至るまでを解説する。C コンパイラでの
開発環境の構築法(カスタマイズ)も述べる積りだ。
この本を参考に環境を構築して貰えば、従来よりも少ない労力で
同等以上の作業が行える筈である。そうすることで余った時間があれば、
プログラムの質を向上させることに費やして貰いたいと考えている。
これについては、後でもう少し詳しく述べる。
●独断的エディタ進化論
筆者の独断によるエディタ進化論を述べる。
ライン・エディタ以前は、実は知らない。バッチ・エディタだったに違いな
い。尤も、パンチ・カードでのプログラム／データ入力ならば、学生時代の実
習で散々やらされた。2度とあんなものは使いたくないとだけ、思っている。
ライン・エディタは、Unixのed、MS-DOSのedlinのようなものを言う。
編集をしたい場合、次のような手順を踏む。
0. 編集したい行付近を、行番号で指定して表示する
1. 対象の行を選ぶ(行番号入力)
2. その行内で目的の位置に、キャラクタ・ポインタを移動する
3. 文字挿入、文字削除等のコマンドを行うと、
キャラクタ・ポインタがある場所に文字が挿入／削除される。
こんな感じのものである。或いは、文字単位の処理ではなく、行単位での修
正しかできないかもしれない。それでも、所謂置換コマンドがあれば、なんと
かなる。なんとかなるだけであって、決して使い易いとは言えない。何しろ常
に、現在編集対象としている1行しか注目できない。現在編集済みのテキスト
がどのような状態にあるかを確かめたければ、「何行から何行まで表示」とい
うコマンドを実行する。試しにいじってみれば分かるが、非常に使いにくい。
「どこ」というのを指定するには行番号を使うという、編集が進めばコロコロ
変わるようなものを相手にしなければならなかった。非常に機械よりの設計だっ
たといえよう。
また、エディタの感覚が、「一括処理(バッチ)に対話機能を付けた」という
域を出ていない。こういうものは、予め何をやるか、その結果がどうなるかを
見極めた上で操作しないと、何をやっているのか分からなくなる。エディタ上
での試行錯誤が困難なのである。この場合、編集作業にはプログラム作成と同
じようなセンスが必要とされる。自分の頭の中で前もって、どのような順でど
んな作業をやれば良いかを整理した後に、コマンドを入力する必要があるとい
う点で。誤操作をした時に、「今の取消」と言えないところも辛い。Undoがな
いのである。
最も、当時の計算機の端末は、表示機能も貧弱だったに違いない。表示して
改行すると、もう2度と前の行に戻れないというテレタイプ端末だったに違い
ない。また、作るプログラムの大きさもそれ程でもなかったに違いない。リス
トは殆どの場合、紙に出して眺めるというのが常識だったに違いない。従って、
エディタはこれで十分だったかも知れない。
Unixでは、このedに幾つかの機能を追加したexというものがある
(cf. 文献0006, 0007)。コマンドが随分使い易くなり機能拡張はされたが、
相変わらずライン・エディタである。これはどうも、先のテレタイプ端末のような
低機能端末向けに設計されたようである。exは後に、行内編集だけは
簡単になるように、オープン・モードというものが追加された。
更に、exにスクリーン・モードをつけた、viという名前のエディタができた。
これは、現在のUnixが標準で装備しているエディタである。スクリーン・エディ
タと呼ばれている。
viには、まあいわばviモードとexモードがある。このviモードは、オープン・
モードを画面全体を使えるように拡張したものと言えるのだろう。viモードで
もexコマンドは、':'を前置きすれば殆どそのままに使用である。テキスト全
体のうちカーソル付近の行を、画面の大きさ分だけ表示している。カーソルを
動かせば、それに応じて表示範囲も変わる。巻物を送るように「スクロール
(scroll)」するのである。
このviモードだが、テキスト挿入モードとコマンド実行モードに分かれる。
そして、必ずこのどちらかの状態(モード)にある。
テキスト挿入モードでは、タイプした文字が挿入されるか、[DEL]キーによ
るカーソル直前の文字の削除のどちらか。そして、この文字削除は、現在カー
ソルがある行しか通用しない。前の行にタイプ・ミスがあったから直したい、
という場合に、テキスト挿入モードのままそれを行うことはできない。但し、
改行して新しい行を作ることはできる。それでも、既にある現在の次の行へは
移動できない。
コマンド実行モードでは、カーソル移動か、コマンド実行モードに入ること
ができる。然し、基本的に文字入力は不可能と言える。
従って、全ての行について、テキストをちょこまかと直すような作業は、非
常にやりにくい。
カーソル移動
モード切り替え
文字入力／削除
モード切り替え
カーソル移動
モード切り替え
文字入力／削除
モード切り替えというのを、延々繰り返すことになる。実際にやって
みれば、大変だということが分かる。
更に、コマンド実行モードでは、使えるコマンドの種類が少ない。例えば、
文字列置換を行うようなコマンドは存在しない。では、どうするか？ コマン
ド実行モードから、exのコマンドを呼び出すのである。これは、一応違和感な
く行える。exのコマンド実行後は、自動的にコマンド実行モードに戻る。
つまり、このviモードは「エディタ」としての機能は殆どなく、「可視化
(visualize)」機能の方に重点が置かれている。あくまで、exの拡張部という
認識しかできないと思う。テキストを眺めてみたい場合は、だからこのviモー
ドで十分だろう。だが、編集作業を行うには役不足である。特に、カット&ペー
ストと言われる種類の編集能力は非常に弱い。と言えるだろう。
このため私個人の独断では、viはスクリーン・モードの付いた、ライン・エ
ディタに過ぎない。
また、viは同時には1本のファイルしか扱うことができない。同時に複数の
ファイルを見比べるというようなことはできない。
viで「複数のファイルを1本に統合し、重複した記述があれば、そこを削除
する」という作業(極ありふれた、作業だと思う)を行おうと思えば、プリンタ
のお世話にならざるを得ないだろう。異なる箇所を見比べるときに、どうして
もプリントが欲しくなってしまう筈だ。
文献0004によれば、viの作者であるBill Joyは、「こんなにviが普及すると
分かっていたなら、絶対に作りはしなかった」と何度も言っているらしい。
彼はviをプログラマブル(カスタマイズ可能の意味)でマルチ・ウィンドウ対
応に拡張しようとしたらしい。文献0004には、次のような話が載っている。
彼がマルチ・ウィンドウのサポートを追加していると、
テープ・ドライブが壊れた。バックアップは無かった。
彼は、とにかく作業を続けたが、ついにある日ディスクがブッ壊れた。
バックアップもなかったし、完全なリスト(プリント)もなかったので、
彼は諦めるしかなかった。結局、彼は以前のバージョンに戻り、
マニュアルを完成させ、それでviに決着をつけた。
そして、次のプロジェクトに取りかかった……
文献0004の記述に「viはcurses(端末画面操作用ライブラリ)の最初のアプリ
ケーションであった」とあるところを見ると、筆者は、viは元々はcursesのテ
スト・プログラムだったのではないかと邪推したくなる。
とにかく、viは、Unixの標準エディタということになっているが、それは
「Unixをインストールした時に初めから入っている」という事実以上のことは
意味しない。私の感覚では、「ラジカセ買ったときについてくる試聴用の音楽
テープ」と同じ位の意味しかないと思う。
同じ論理でいえば、MS-DOSの標準エディタは、edlinである。然し、MS-DOS
のユーザであれを使っているという人はどの位いるのだろうか？一歩譲って、
「使える」だけという質問に替えたら、どうだろうか？
MS-DOSでは、別に自分好みのエディタを用意するのが現在の常識だと思うが。
○スクリーン・エディタ Emacs
…… マルチ・ファイル／マルチ・ウィンドウエディタ
スクリーン・エディタとしてのEmacsは、次のような特性を備えている。
ファイルを画面という窓を使って覗いている感覚となる。窓を上下に移動す
ることで、ファイル全体を見渡すことができる。窓を上下することを、スクロー
ルという。
画面で見た通りに操作ができる。
「表示のここからここまでを××する」という操作が可能である。こ
の時、常に行や桁(行番号や桁位置)を意識する必要はない。「表示の正にここ」
といった形で位置を指定できる。カーソルで位置を指定すれば良い。
画面を分割して、複数の窓(window)を開くことができる。
それぞれの窓には、異なるファイルを表示できる。
同じファイルを表示することもできる。
1つの窓に、ファイルの先頭の方、もう1つの窓にファイル末端の方、といっ
た具合に。
複数のファイルを扱えることをマルチ・ファイル機能といい、複数のウィン
ドウを扱えることを扱えることをマルチ・ウィンドウ機能という。図0201
いわゆるカット&ペーストと呼ばれる機能が豊富で、「ウィンドウのここか
らここまで」のテキストを切りとり(cut)、別ウィンドウの任意箇所に張り付
ける(paste)ことが簡単にできる。
つまり、これによって複数のファイルの内容を適当に編集して1本の新しい
ファイルにまとめることもできる。逆に、1本のファイルを適当に編集して、
内容毎に別ファイルに編成し直すことも簡単にできる。
マルチ・ファイル／マルチ・ウィンドウの由縁である。
1つのEmacsの上で、ファイルの異なる部分を同時に並べて見比べることが可
能であるため、こういうことが簡単にできる。
Emacsのこのような特性を理解し、自在に使えるようになれば、ファイルを
プリント・アウトする頻度は激減し、相当部分の作業を端末のみで行うように
なるだろう。
また、過去に作成した文章やプログラム断片を再利用する率も高まり、再利
用時の手間も削減できるだろう。1度タイプしたテキストは、2度とタイプする
必要はない。その部分をカットしてきて、ペーストするだけでいいのである。
スクリーン・エディタEmacsは、あなたの習慣を変える。
紙源保護にも役立つ。
○使用端末の能力とエディタ
Emacsの場合、カーソル・アドレッシング(プログラムによって、画面上の任
意の位置にカーソルを移動できる機能)の不可能な端末では、起動すらできな
い。
viでは、そのような場合(テレタイプ端末……プリンタのように、画面の表
示がどんどん流れて行ってしまう)でも使用できる(それをオープン・モードと
いう)。
しかし、今日そんな低機能端末を使う機会は希である。殆どが高機能端末で、
回線速度も高速である。端末は高度な操作を処理できるだけの十分な能力を持っ
ている。それならば、端末の持つ能力をなるべく引き出すような高機能エディ
タを使った方がよいのではないか?
数年前までは、Emacsはその高機能さ故に、巨大で重いと思われていた。
GNU Emacsの場合なら、使い方にもよるが1つ当たり、大体CPUパワーにして
1〜3MIPS、記憶容量として実メモリ0.5〜2MBを必要とする。仮想メモリは実メ
モリの2倍程度必要だろうか。1980年代後半のワークステーションはCPUパワー
にして2〜3MIPS、実メモリ4MBとというのが標準的な構成だっただろう。この
状況では、ワークステーション1台当たり2つか3つEmacsを立ち上げると、もう
そのワークステーションの資源を使い切ってしまう。しかし、2〜3人で1台の
ワークステーションを占有できる状況でもなかっただろう。このため、ユーザ
の方が機械に妥協して使い易いEmacsを諦め、もっと低機能だが資源を余り使
わないツールを使う等して、使い難い環境に甘んじなければならなかったかも
しれない。
元々Unix自体が、Multicsを諦めたときにこういう方向をとったのだから仕
方ないが……私は、Unix環境は次の思想で作られていると理解している。
(文献0008等から、次のように読み取れる)
「システムをなるべく軽く、軽くするために、エラー・チェックすらも必要最
小限に抑えて、巨大な何でもできる1つのツールよりは、1つ1つのツールの機
能は弱く使いにくいが細かいツールを一杯用意する。それらを使うときにはま
るで、プログラミングするかのごとくどのツールをどの順で組み合わせたら目
的の動作を実行できるか、ということを考え、必要ならばゴミのような、シェ
ル・スクリプトという名の使い捨てのプログラムを作成することで対応する。」
優秀なプログラマであれば、これ位簡単にできる筈だという論理。然し、
「できる」ということと「快適」ということとは違う。
90年代になり、ワークステーションの性能は飛躍的に向上した。CPUパワー
は10MIPS〜20MIPS或いはそれ以上、メモリも16MBは確実と言えるだろう。恵ま
れたところでは、この倍以上の数値が保証されている。そうなれば、もう、資
源不足を理由にEmacsを諦める必要はない筈である。
となれば、ユーザにとって快適な環境である方を選べば良いではないか。そ
の方が作業性も生産性も向上する筈。快適な環境というのは大事である。人間
の精神状態は少なからず環境に左右されるのだから。
Unix上の細かいツールは、「このOSの上では、こういう風に作るときっとマ
シンの負担やOSの負荷が少なくなるし、実現し易い。」と考えて作られたのだ
と思う。viにもこの思想が流れている。然し、ハードウェアの性能がこれだけ
上がった現在なら、むしろ、「エディタというのは、かくあるべきである。そ
れを、このUnixコンパチのOSの上で動かすためには、こういう実現方法をとっ
て……」と考える方が良いのではないだろうか? Emacsは、こちらの立場を取っ
ていると思う。
勿論、エディタというものは最終的には好みの問題である。だから、viの方
が好みに合うというのなら、そちらを使えばいい(そういう人は、この本を手
にしてはいないと思う)。しかし、私はEmacsを薦める。タッチ・タイプのでき
る人間は、viよりもEmacsを選ぶだろうと私個人は信じている。viには両手を
フルに使うという感覚がない。
●GNU Emacs
Emacsとは、Editor MACroS の略だという。Editing MACroSだという説もあ
るが、どっちなのだろう? いづれにせよ、「マクロによりカスタマイズ可能
なエディタ」という意味らしい。カスタマイズ(customize)というのは、使う
人間の好みに応じて設定等を変更することをいう。例えば、キーの働き等が変
更できる。
マクロというのは、カスタマイズ用の一種のプログラム言語である。Emacs
は、このマクロを使って自分自身の機能を追加／変更できるようになっている。
特に、GNU Emacsの場合は、このマクロにはEmacs-Lispと言われるLisp言語を
使っている。GNU Emacs自身は、殆どLispインタープリタであり、エディタの
機能の相当部分がLispで記述されている。つまり、拡張性が非常に高い。気に
入らなければ、自分自身をLispで書き換えてしまうことさえ可能である。この
自由度の高さ故、Lispで書かれたEmacs上で動くアプリケーションも多い。様々
な拡張機能を実現する、Emacs-Lispのアプリケーションが存在し、フリーソフ
トとして出回っている。が、これらアプリケーションについては、本書では述
べない。別の機会に譲る。
さて、Emacsには開発者／配布元の違いによって、幾つかの種類がある。
CCA Emacs, Unipress Emacs, Gosling Emacs等である。
(これらは、操作性や見かけに相当の類似性がある)但し、現在 Emacs と言
えば、殆どGNU Emacsのことを指すと考えて良い。少なくとも、本書において
単に「Emacs」と表記した場合は、GNU Emacsを指すものとする。
GNU Emacsは、FSFのRichard Stallmanによって開発された Emacsである。
再び文献0004になるが、Emacsは元々はUnixではないシステム上のTECOとい
うエディタのマクロで作成されたものだったらしい。後に、CMUのJames
Goslingという人物が、Unix用にC言語でEmacsを書き直した。これが、Gosling
Emacsだった。このGosling Emacsでは、カスタマイズ用の言語としてMock
Lispという、Lispもどきを使っていた。
文献0001によれば、
RMSがGNUプロジェクトを始めるにあたって
UnixにEmacsがあると知って喜んで使い始めたら、憤慨した。
マクロ言語はLisp風だが、名前もMock LispでまがいものLispだし、
画面の再表示アルゴリズムが気に食わないなどなど、結局、
全部書き直してGNU Emacsになったという。
と、書いてある。RMSは、Richard Stallmanのイニシャルである
(ログイン名、メール・アドレスでもある)。然し、この話は本当だろうか？
いかにも有り得そうな話ではある。
(文献0001の続編文献0009は、エディタの内部処理について述べたもので
仲々面白い。ここにある手法の幾つかは、実際にGNU Emacsで使われている)
●GNUプロジェクトとFSF
GNUは、コンピュータ・プログラムのソースに関する制限をなくすことを目
的とするプロジェクトの名前である。フリーソフトというのは、この自由のあ
るソフトのことである。
以下の話は、主に次の講演から題材を得た。このセミナーには、技術評論社
の好意で参加させて頂いた。
東京 GNU テクニカル・セミナー
1992年12月2日(水)
東京 六本木 国際文化会館
Stallmanの講演題目: プロジェクトGNU --- 過去、現在、そして将来 ---
Stallmanがかつて勤めていたMITのAIラボに、1977年頃Xeroxからプリンタの
寄付があったという。そのプリンタは、フリー・ソフトのプログラム、つまり
ソース付きのプログラムで駆動するようになっていたので、AIラボでは幾つも
の便利な機能をつけ加えたという。例えば、プリントが終了すると直ちにユー
ザに通知するとか、紙詰りや紙切れが起こったら、プリントしようとした全て
のユーザに通知する等の。こうやって、便利に使っていたそうだ。
後に、Xeroxは新しい高速のプリンタを寄付したそうだ。しかし、このプリ
ンタは最早フリー・ソフトではない、独占的(proprietary)ソフトで駆動する
ようになっていた。そして、それはソースの代わりにバイナリで配布されたそ
うである。AIラボでは、サービスを開始したが、その独占的ソフトでは以前の
ような(AIラボで追加された)便利な機能は持ってなかった。そのため、以前よ
りサービスは低下することになった。
AIラボにいた人間は、そのソフトのオリジナルの作者と同じ位優秀で、ソー
スさえあれば、そういった問題を解決できた筈。にも関わらず、バイナリしか
なかったので、プログラムを修正することができなかった。Xeroxにその旨を
伝えたが、Xeroxは、ソースも渡してくれなかったし、代わりに直してくれる
ということもしなかった。
CMUにそのソースを持っている人がいると聞いたので、Stallmanはソースを
くれるように頼みに行った。然し、'nondisclosure agreement'
(非情報開示同意条項)
の下でソースを入手したので、渡すことはできない、と断られた
という。非常に不親切だと思ったが、契約がある以上相手を責める訳にはいか
ない。
この経験から、Stallmanは「プログラムはソース付きでないと意味がない」
と思うようになったらしい。それ以前のプログラムのソースが自由に見れた時
代には、みんなで自分の苦労したところや人の改良点のいいところ等を自由に
交換できて、仲良くやっていたのだ。それが、独占的ソフトでバイナリ配布に
なってから、こういう嫌な思いをすることになったと。
「ハッカーズ」という本に書かれているらしいが、
Symbolics社に対する戦いの中で、Stallmanは、自分一人でもかなり大き
なプログラムが書けるだろうという自信を持ったという。この能力で、この数
年に社会が被ったであろう、損害を取り戻せるのではないか？
そう考えて、行動を開始したという。
1983年、殆どフリーソフト無し、計算機の基礎ともいうべきOSはメーカの独
占的なものばかり。この状況からStallmanは、行動を開始した。
第1に、OSが必要と考えた。何故なら、どんなソフトウェアもOSの上のアプ
リケーションに過ぎず、OSがない限り、プログラムは動作しないようになって
いるから。まず、OSを作らないことには、フリーソフトだけで動作している計
算機というものを作るできない。
第2に、どういうOSにするか？ 候補は2つ。
1. MIT Lisp System
2. Unix
1.は、高速実行のためには特定のハードウェア依存にしなければならないが、
そうすると、特定のハードウェア・メーカに支配される可能性があるので、ダメ。
2.は、ちょうど流行しだしたところ。比較的、ハードウェア依存性が小さく、
移植性が高いと考えた。そういうOSとしては、唯一と言って良かった。
当時の他のOSは、全てハードウェア・メーカの独占的OSであったから。
もう一つの理由として、ユーザに別のシステムに切り替えるように強制すると、
使って貰えないかもしれないと思った。「××と同じ」と言えば、
使って貰える可能性が高くなる。
こういった理由で、Unixを置き換えるようなフリーソフトを作ろうと考えた
という。
次に、そのシステムの名前をどうつけるか？ハッカーには、ユーモアの精神
が必要なので、伝統に従って、何かの文章の頭文字を並べたもので、なるべく
妙な単語で、意味が循環しているようなものがいいと考えた。そこで、
GNU's Not Unix
の頭文字という、GNUという名前を付けることにしたらしい。
「GNUは(Unixコンパチだが)、Unixではない」という意味である。
従って、GNUは、プロジェクトの名前であり、そのプロジェクトが最終目標
とするUnixを置き換えるようなフリー・ソフトウェア・システム全体の名称で
もある。GNUは、Stallmanの「プログラマにとって、いいプログラムをコピー
する、或いは再利用する、自分好みに改変することは極々自然なことだ。従っ
て、ソフトウェアはみんなが共有できるようにフリー(自由)でなければならな
い。プログラムのソースは、誰もが自由に見て修正再配布できるように、フリー
でなければならない」という考えを実現するプロジェクトだということになる。
因みに、GNUは「グニュー」と読む。'G'を発音する。Emacsは、「イーマッ
クス」と読む。GNUによく似た名前に、Emacs上で動作するEmacs-Lispで書かれ
たアプリケーションでGNUSという名前のニュース・リーダがある。然し、こち
らは「ニューズ」と読んで、'G'は発音しない。
このGNUプロジェクトを始めるに当たって、Stallmanは、MITのAIラボを辞職
したという。理由は、StallmanのGNU活動を妨げるための法律的根拠を、MITに
全く与えないようにするためである。
Stallmanはまず初めに独りで作業を開始したという。そうして出来上がった
最初のGNUの製品が、GNU Emacsであった。1985年の春から配布を開始したという。
フリー・ソフトのフリーは、ソース・コード利用に関する自由を意味するの
であって、無料という意味ではない。プログラムを複写／再配布する自由と、
ソースを読み、改変する自由である。この自由の重要性に比べたら、値段の問
題は大したことはない。ソフトが有償であること自体は、悪いことじゃない。
GNU Emacsは、テープ1本$150で、配布を開始した。
配布を開始すると、非常に大きな反響があったという。バグ修正の報告や感
謝の声等が絶えなかったと言う。配布を受けた人全員に、ソース改変の自由を
与えたので、皆が様々な便利な機能を追加してくれたという。Stallmanはそれ
を見ているだけで良くなった。他の人が行った改良も、Stallman自身が利用で
きるので。
Emacsのテープ本数が非常に増えて大変になり、また、売上も随分溜まった
ので、会社を設立した方がいいと考えた。そして、Stallmanは、FSF(Free
Software Foundation)という団体を組織した。FSFは、「コンピュータ・プロ
グラムの複写や再配布の制限、理解と修正の制限をなくす」、こういったソフ
トウェアを配布するための団体である。Emacsの売上は、全てFSFに費やしたと
いう。その後、Emacsを始めとするGNUの製品は全てFSFが開発し、配布するこ
とになる。
筆者もこの話を聞いて大変驚いたのだが、Stallmanは、FSFからお金を貰っ
たことは一度もない(never)という。自分に費やすような無駄な使い方をする
よりも、その金で誰か他の人をFSFに雇った方がいい、と考えるのだそうだ。
筆者のような凡人は、ただ、ただ、恐れ入るばかりである。
Stallmanは、GNUプロジェクトを開始してからは、プログラミングのコンサ
ルトやカスタマイズ作業等を行って、そのサービス料を貰う、ということで、
生計を立ててきたと言う。最近、Hoppers Fellowshipを貰ったので、
やっとそういうことをしないでいいようになった、と言っていた。
さて、FSFから配布されているGNUの成果物だが、
GCC GNU C Compiler
GDB GNU Debugger
GAWK GNU AWK
等々、様々な製品がある。詳細は、文献0005を取り寄せるといいだろう。
但し、GNUカーネルの完成は、残念ながらまだ先らしい。
GNUの製品はいづれも、ほぼ無償で入手できる(郵送料等の手数料は必要)が、
Unix上の有料／標準の同じ種類のツールと比較して、遜色はない。むしろ、機
能追加されて使い易くなっているものが多い。詳細はこの本では述べないので、
興味のある方は、文献0002等を参照して欲しい。
ただ、FSFがGNUの活動を維持してゆくための資金が欲しいので、是非FSFか
ら直接注文して、買って欲しい。そうしてFSFに貢献して欲しいとのこと。テー
プ150本の売上で、プログラマ1人を1年間雇えるそうだ。
今後は、CD-ROMによる配布も行うそうである。このGNUテクニカル・セミナー
でFSF配布のCD-ROM第1版というのを貰ってきた。筆者が欲しかった様々なGNU
の成果物が入っていたので、喜んでしまった。
○Copyleft
GNUプロジェクトにおける成果物を、GNUの精神に従って配布するために、
FSFではCopyleftという概念を考えだした。勿論これは、Copyrightをもじった
ものである。right(保守的)に対するleft(革新的)というものも意味している。
GNUソフトウェアは、その複写と再配布の自由を保証している。つまり、GNUの
ソフトウェアを入手した人は自由にそれを複写して他人に分け与えることがで
きる。また、ソースは公開されており(通常配布時にはソース付きで、配布さ
れる)、移植・変更も自由だ。こういった権利を全てのGNUのユーザに保証する
ために考え出されたものがCopyleftである。このCopyleftによって、何人もこ
れら権利を制限できないことをも明言している。
Copyleftは、通常の著作権告知とGNU一般公有使用許諾書(GNU GPL; GNU
General Public License)の2つからなる。著作権告知(Copyright表示)を行う
ことで、GNUの成果物の著作権は、FSF(或いは著作者)に存在することを明言し
ている。つまり、GNUの成果物は著作権が放棄されたPDS (Public Domain
Software)とは違う。ではなぜ、著作権を保留する必要があったのだろうか？
仮にPDSの様にソフトウェアの著作権を放棄すれば、全ての人がそれを只で
入手し、自由に変更することが可能になる。著作権が放棄されているのだから、
誰に気兼ねすることなく、そういう真似ができる。然し同時に、PDSでは著作
権を放棄している訳だから、それを入手した不心得ものが、ソースの再配布を
制限したり、独占的使用許諾を行うことも可能だということである。こういっ
た人々は、ソースを抑え込んで、バイナリだけを有償で配布するかもしれない。
こうなると、自由が守れない。独占的ライセンシングは、不当に価格を釣り上
げる原因ともなり得る。FSFはこれを防ぐために、著作権を留保した。
更に、利用者の権利を保証するために、GNU一般公有使用許諾書を備えた。
これによって、前に述べたような使用と再配布の自由がうたわれている。同時
に、その自由を一切制限してはならないという義務も負わせている。GNU GPL
についての詳細は、Emacsの配布キット中に含まれるファイルを参照して欲しい
(3章 C-h C-c及びC-h C-wの説明を参照のこと)。
GNUの成果物は全て、このCopyleftによって保護されている。
勿論Emacsもこれに従っている。
最近(1991年半ば以来)では、GNU ライブラリ一般公有使用許諾書
(LGPL; Library General Public License)というものも決められたようである。
新しいGNUのライブラリを入手すれば、きっとそのコピーが入っているに違いない。
GNU LGPLが定められたのには理由がある。その前に、GNU GPLで
宣言されている制限について簡単に触れよう。GNU GPLでは、
GNUのプロダクトから導かれたソフトウェアもGNUと同じくCopyleftに
しなければいけないと言っている。簡単に言えば、
「GNUのソースを少しでも利用したプログラムを作成したら、
そのプログラム全体をフリー・ソフトにしなさい」、
ということである。
ここの「フリー」は再び、ソース・コードの閲覧／再配布／変更の自由を指す。
この制限を守る限り、GNUの成果物を利用できる。
つまり、GNUを助けるものだけをGNUは助けるのである。
この条項は、厳密にはコンパイラのライブラリのようなものにも適用される。
例えば、GCCというGNUのCコンパイラがあるが、これでコンパイル&リンクした
プログラムのバイナリ・ファイルは、GNUの成果物(ライブラリ)を含むことになるので、
GNU GPLに従えば、このバイナリ・ファイルだけを配布することは許されない。
元のプログラム自体もGNUと同様にCopyleftで保護されるフリー・ソフトとして
配布する必要がある。それが嫌なら、GNUのソースを利用しないことである。
GNUのコンパイラ／ライブラリを利用しないことである。
元々のGNU GPLが宣言していたのは、こういう非常に厳しい制限であった。
これでは、逆に制限がきつ過ぎて、却ってGNUの成果物を使って貰えない
のではないか？ と、FSFは考えるようになった。そこで、GPLを若干緩めた
LGPLというものが考え出された。これに従えば、独占的ソフトウェアを
開発しているような企業等も、自分のところで開発したプログラムのソースを
公開せずにGNUのライブラリを利用できるようになる。同時にユーザが
プログラムの「独占的でないフリーな部分」を変更し、再配布する自由は守られる。
そうすることでGNUのライブラリが普及し易くなるのではないかと考えたらしい。
LGPLは、GNUのある種のライブラリを使ったプログラムを配布するとき、
「GNUのライブラリにリンクする独占的ソフトは、ソースの代わりに、
完全なオブジェクト・ファイルを共に配布」すれば良い、
とするものである。こうしておけば、たとえ独占的ソフトの部分のソースがなくとも
それを入手した人間が、フリーのソースの部分を修正して、
再度リンクするということが可能になる。
以下は、LGPL Ver.2.0(GNU sed-1.11付属)の大雑把な筆者訳の一部である。
これは参考以外の目的に使用しないで貰いたい。勿論正確か否かも保証しない。
1. LGPLに従うライブラリは、そのままの形でソース・コード配布できる
2. LGPLに従うライブラリの派生物もそれがライブラリである限り、
LGPLに従うライブラリになる。
3. LGPLをGPLにすることはできる。
然し一旦そう変更したら、LGPLに戻すことはできない。
4. LGPLのライブラリ・派生物を、1., 2.の条件を守るなら、
便宜上バイナリ配布できる。ソースの入手法は教えること。
5. LGPLのライブラリを単にリンクするだけ、というようなプログラムは、
それ単体ではLGPLライブラリの派生物ではないので、
ここにあるような問題の範囲外。
けれども、リンクしてしまったバイナリは、派生物扱いなので、
このライセンスの範囲内。6.を見ること。
6. 5.に示したようなプログラム配布時の扱い。
ユーザが自分自身の使用のために修正すること、
そういった修正をデバッグする目的でバイナリを解析すること、
は許可すること。
更に、次のうちのいづれかを行う。
a) 5.の部分のオブジェクト且つ／もしくはソースを共に配布。
それをユーザが使用して、LGPLライブラリの修正版と再リンク
可能にするため。
b) 最低3年は、a)の記述にあるものを
配布料のみで提供する旨の添え書き。
c) 指定場所におくことで、配布を行ったのなら、
a)の記述のものを同じ場所にも置く。
d) 相手が既にa)の記述のものを持っていることを確認するか、
相手に送付したことの念を押すこと。
以下略。
GPLもLGPLも、正確なところは、原文に当たって、読者自身で解釈して貰いたい。
筆者は、プロの翻訳家でもないし、法律の専門家でもないのだから。
勿論ここに書いたのは、GPLやLGPLの内容の極一部である。GPLの全文は、
第5章で説明する$EMACS/etcディレクトリ下に、完全なドキュメントの形で
存在するだろう。LGPLの全文は、LGPLが適用されるある種のGNUの製品に
附属している。実際にどの部分がLGPLに従うかは、GNUのソースの
冒頭部に必ず書かれているCopyleft表示の部分を見れば分かるだろう。
Copyleftが目指すものを、もう少し分かり易く説明しよう。
筆者なりの理解であるため、誤解している部分があるかもしれない。
このGNU GPLでは、GNUのソフトウェアには、何の保証もないということも
明記されている。つまり、GNUのソフトウェアに何か問題があって
それによって損失を被るようなことがあっても、FSFは何も保証しない。
また、バグが見つかったからといって、必ずそれを修正するとも限らない。
そういったGNUソフトウェアを利用する際の責任やリスクは、
全てユーザが背負うことになる。但し、ユーザはそのソフトウェアの
ソースを持っているのだから、不都合があるなら自分の好きなように
書き換える自由もある。つまり、GNUのソフトウェアを利用する際は、
何に使うのも、どう変更するのも自由だが、その責任は自分でとること
また、
他人のその自由を制限してはいけないこと
という約束があるということだ。
では、保証のないソフトウェアは、信頼性が低いだろうか？
FSFは、GNUソフトウェアにバグが見つかったら、是非それを報告して欲しいと
言っている。報告すれば、可能な限りFSFは対応するだろう。但し、
必ず対応するという＊＊＊保証はない＊＊＊。然し、簡単なものなら
すぐに直すだろうし、誰か他の人間(同じGNUソフトウェアのユーザ)が
直してくれるかも知れない。金をかけることができるのならば、
誰か人を雇って直させることも可能である。あなたは、そのソフトウェアの
ソースを持っているのだから。
現実には、GNUのソフトウェアは、世界中で多数の人間が使用して
問題点をつぶしているので、十分テストされた、非常に信頼性の高い
ソフトウェアになっていると言えるだろう。
どうしてもサポートが欲しいというユーザは、
GNUのソフトウェア・サポートを生業とするFSFと組織的には無関係の企業が
存在するので、こういう会社と契約を結べばいいだろう。
日本でも、SRAが中心となってWingnutというプロジェクトが
進められている。
GNUには、ボランティアの精神も要求される。尤も強制はできない。
Copyleftに従ったソフトウェアを出せば、GNUに貢献することになるだろう。
○League for Programming Freedom
LPF(League for Programming Freedom)という団体について、少し説明しよう。
FSFとは独立した組織である。プログラムを書く自由というものを
守るための団体である。端的に言えば、著作権問題やソフトウェア特許等の
知的所有権というもので、他人のプログラミングの自由を奪おうとする
組織に対抗して、そういった自由を取り戻そうという団体である。
どういうことか？
例えば、最近ユーザ・インタフェースのLook&Feel(見た目と操作感)と
いうものが知的所有権の保護対象になるのではないか？ という
懸念がある。これが認められると、漠然としたアプリケーションの振る舞いが、
法的に保護されるため、後発のプログラマが別の努力を払って新しくプログラムを
作成しても、出来上がったプログラムの振る舞いが、その特許／著作権によって
保護されたものと同じような振る舞いをすれば、特許侵害として扱われる。
特許侵害となれば、そのプログラムの「振る舞い」を別のものに変えるか、
莫大な特許料を支払うか、しなければならないだろう。
このようにして、プログラミングの自由が侵害されることになる。
こういったものから、プログラミングの自由を守ろうという団体である。
具体例は、文献0005か、$EMACS/etc/APPLEというファイル(cf. 5章)を
参照して頂きたい。
○Think GNU
この本の原稿があらかた書き上がった1993年2月、日本におけるGNU活動の
本家本元とも言える引地ご夫妻の書籍が発行された。文献0010である。
この節に書いたような話が、同書にはより正確に記されていると思う。
GNU GPL, LGPLの全文やGNUの年表FSFやLPF、及びその目的について書かれている。
一読に値すると思う。
酷いなぁ。こんな本がでるんだったら、この節は書くんじゃなかった。
削除するには忍びないから、拙い出来だが残して置こう。
○この本
文献0010同様、この本もCopyleftの精神に則り、コピー・フリーにしようと思う。
以前から漠然とそうできれば良いと考えていたのだが、先述の「GNU テクニカル・
セミナー」の際に、Richard Stallmanにサインをして貰った。この時に、
「Emacsの本を書いているのだが……」と言ったところ、非常に厳しい口調で
「是非Copyleftにすべきだ」と言われた。それで、筆者はそのように決心した。
但し、筆者は約1年間、祝祭日や長期休暇、平日の夜等の殆ど全てを、
この本を書くために費やした。だから、この本である程度の収入を期待している。
コピー・フリーにはするが、この労力に見合うだけのものは
貰いたいという意味である。
但し、それだけのものを貰えたら、後はこの原稿をFSFに寄付しようかとも考えている。
FSFが「いらない」、と言ったら別だけど。ま、1年とか2年先になるだろうけど。
●私の目指すものとこの本の位置づけ……というか、何というか
筆者が目指すものは、よりよい計算機利用環境の提供である。
計算機について詳しい人間しかまともに使えないような現状のような
システムではなく、極普通の人間にも簡単に使えるような、
そういう利用環境が欲しいと考えている。
エンド・ユーザが利用する計算機環境は、物理的なハードウェアの装置を除けば、
殆どソフトウェアに左右される。その意味で、ソフトウェアは大事である。
このソフトウェアは、所謂アプリケーション・プログラムであるだろう。
従って、アプリケーション・プログラムがそういう環境をエンド・ユーザに対して
提供できれば、筆者の目指す環境が提供できたことになる。
アプリケーション・プログラムのプログラマがエンド・ユーザにとって
使い易いプログラムを作ろうと考えたとする。さて、この時プログラマが
作業する環境が貧弱だったら、どういうことになるだろうか？
意志に反して、貧弱な環境では意図したよりも程度の低いプログラムしか
作れないだろう。ここで私は、生産性ということを話している。
生産性とは、投入した労力に対して得られる成果物の質及び量を指す。
ここでいう環境というものの要素には、様々なものがあるだろう。
ハードウェア、OSが提供する機能、選択したプログラム言語のコンパイラが
提供する機能、利用可能なライブラリ、開発時に利用可能な各種ツール、
こういったものが、プログラマにとっての環境と言えるだろう。
こういったものがプログラマにとっての生産性を向上させるだろう、
と筆者は考える。
こういう話は長年語られてきたに違いないし、こういったことを研究してきた、
そして研究している人もいるに違いない。そして、プログラマにとって
使い易いツールのようなものも様々に作られてきた。にもかかわらず、
現状を見ると、仲々それが有機的に活用されてないのではないか？
と、思われる。何故だろう？
ソフトウェアの生産性ということを論じると、ソフトウェア工学という
ようなものもあり、そちらの方でも別の形の生産性を向上させるための
研究といったものがなされている。どうやらこちらは、主に
ある程度の規模のソフトウェア・システムを開発する際の
分析／設計段階に適用されるべきものらしい。勿論、
プログラミング・レベルで適用されるようなものもある。
こういうものの例には、古くは構造化設計／プログラミングがあり、
最近ではオブジェクト指向設計／プログラミングがある。
構造化プログラミングに至っては、今から20年以上も前に出てきた概念である。
少なくとも筆者は、この概念の有効性を認識できていると思う。
また、これは殆どのプログラムにおいて有効な考え方だと思う。
にも関わらず、こういうものが完全に普及し、常識となっているとは
思い難い現状がある。オブジェクト指向というものは、1980年代後半になり
有名になり騒がれてきていると思うが、騒がれている割には正しく理解されていないと
思う。つまり、正しく普及していない。何故だろう？
知識が正しく伝達されていないのではないか？ その知識の形は、
例えばソースかも知れない。ソースの再利用が簡単にできれば、
ノウハウの再利用が簡単になり、これが生産性を上げるかも知れない。
或いは、ツールがうまく流通していないのかも知れない。
どんなに生産性を向上させることが分かっているツールであっても、
価格が異常に高ければ仲々普及はしない。ハードウェアには
金をかけてくれても、ソフトウェアには仲々金をかけてくれないという
現状もある。一方に、異常と言えるほど高いソフトウェアのライセンス料と
いうものもある。どちらも是正しないといけないのだろうと思う。
OSやライブラリが使いにくかったり、バグが存在していることもある。
これらは大抵某ベンダの独占的ソフトで、ソースはそのベンダ内にしか存在しない。
そのため、不備な点があっても直して貰えなかったり、
直すために膨大な金を取られたりするかも知れない。
そういう部分をかわしてプログラムを開発することもできる。
然し、そういった労力は、本来払わなくていいものである筈。
大局的にみて、悪い方が対応しなければならないことなのに、
実際には立場的に弱い方が何とかしなければならない、この現実。
筆者は一般的な話をしているのであって、具体的なベンダについて
言及しているのではない。
些か話が飛躍していて申し訳ないが、筆者はこういった状況を
何とかしたいと考えている。ずっと、もう何年もそう考えている。
とりあえず、今の私は一介のプログラマでしかないので、何の力もない。
GNUが目指すものは、あるマシンを完全にフリーソフトだけで動作させるに足る
フリーなソフトウェア・システム一式の構築である。筆者が目指すものとは違うが、
GNUの目標が達成されれば、それを利用することで筆者の目標が近くなるのでは
ないか？ とも考える。この意味で、GNUを応援したいと思っている。
この意味で、GNUの成果物を利用したいと考えている。
本当は、GNU等のフリーソフトを組み合わせて利用した、プログラマ向けの
統合された開発環境というものを考え、本にまとめたかったのだが、
筆者自身の非力さ故、それが困難であると悟った。
また、軸になるエディタについてのいい解説書もなかった。
そこで、まずエディタEmacsに関するこの本を著そうと考えた次第である。
繰り返すが、筆者は、プログラマにとってエディタは非常に重要な
ツールだと考えている。
この本は、コンピュータ・システムについての本当の初心者は
考慮に入れていない。勿論、基本編を設けることである程度対応した積もりだが、
それでも本書は難しいかも知れない。多くは筆者の説明がうまくないせいだろう。
然しこの本は、ある程度プログラミングやコンピュータについての知識があり、
エディタも何かしら使ったことがある、という人を対象に書いた積もりである。
気分的には、文献0702や文献0703を見終えた人が、もう少しEmacsについて
知りたいと考えた時に、便利に活用して貰えるようにと考えて、
この本を構成した積もりである。そこのところは、ご理解願いたい。
この本は、Emacsの完璧なマニュアルでもない。上に述べたような筆者の
信念に基づいて、Emacsの利用／活用法の1つの指針を解説したものに過ぎない。
敢えて省略した部分もあるし、説明の都合上不正確な解説を行った部分もある。
完璧なマニュアルを望む方は、本書第3章に述べるInfoシステムのマニュアルや
それを翻訳した文献0303、或いは文献0502, 0503, 0504を参照して頂きたい。
●Emacsの姉妹品／類似品
Emacsは非常にメジャーなエディタで、これに類する操作感を持つ様々なエディタが
作られている。また、GNU Emacsを何らかの目的で改造したというものもある。
幾つかここで、紹介したいと思う。
○MS-DOSでの使用
i8086以上のマシンでのEmacsのDOS版には幾つか種類があるので、
簡単に紹介しておく。
MicroEMACS 3.10J
MicroEMACS 3.10(by Danniel M. Lawlence)を、
苫小牧高専の川口 雄一氏、北海道大学工学部の多田 剛氏
が、日本語化したもの。
C言語で書かれた、カスタマイズ可能なEmacs。
但し、操作性とコマンド名が大体Emacs同じというだけで、
マクロ言語は独自のものが使われている。
筆者は1989年末頃にNgに乗り換えた。
Ng 1.3.1
Micro NEmacs。
PDSのMg(Micro GNU Emacs)を、東大生産技術研究所の吉田 茂樹氏が
日本語化、拡張したもの。操作性やコマンド名、漢字コードの扱いが
NEmacsと殆ど同じであった。Ng自体は、拡張の過程で一部にGNUの
ソースを含むことになったため、GNU GPLに従うCopyleftで保護される。
Ngは、DOSに限らず、SystemV Unix(SVR4以前), BSD Unix,
X68000等でも動作する。
残念な点は、カスタマイズ用のマクロ言語が存在しないということだろう。
それでも、見かけがEmacs-Lispとそっくりの初期化ファイルを書くことが
できる。使えるのは、global-set-key等と幾つかの変数の設定に限るが。
Freemacs
カスタマイズ可能なMS-DOS用のエディタで、i8086なら動作する。
サイズが非常に小さく、Emacsと互換があるそうである。
いづれも一長一短と言ったところなので、目的や好み、それに環境に応じて
使い分けるといいだろう。私個人は、Ngを愛用している。実際、この本の原稿も
殆どの部分をJ-3100SS001上でNgを使用して書いた。CPUが8086では、
後述するDemacsが動作しないので。
GNU Emacsは、DOSのような資源の限られがちな環境では若干辛い。
特に軽量のノート・パソコンではそうである。
そのため、こういった軽い、操作性の良いマルチファイル／マルチウィンドウの
エディタがあると非常に助かる。そういった意味で、こういうエディタも
好きなのだが……
どうも、Demacs以来人気がないようである。
実際最近(1993年4月のこと)筆者自身もDemacsに乗り換えた。
A4サイズ3Kg、CPUも486相当以上メモリ10MB、VGAカラー、80MBハード・ディスクという
Demacsのインストール／使用に全く支障がないというハードウェアが
400K円未満で買えたので。欲を言えば、もう少し軽くなって欲しいが。
こういうハードウェアが入手できても、Demacsをインストールする作業の間、
こういうNgのような手頃なエディタは便利に使用できると思う。
また、様々なOS上で同じように動作する点も素晴らしいと思う。
残念ながら、最早吉田さんはNgをサポートしていない。
○NEmacsについて
NEmacsは、「日本語Emacs」のことで、「GNU Emacsを、オリジナルの機能を
できるだけ損なうことなく、日本語も扱えるように修正したもの」だそうである。
この修正を行った電子技術総合研究所の半田 剣一、小方 一郎両氏
によるEmacsをNEmacs化した際の作業内容についての解説記事が文献0003に出ている。
NEmacsは、「エヌ・イーマックス」と読む。
NEmacsはこういうものであるから、日本語の機能以外の部分については
GNU Emacsそのものである。従って、日本でEmacsと言った時には、実際は
NEmacsであることが多い。
NEmacsは実際、GNU Emacsのソースの一部を書換え、
更に一部を追加したものになっている。
本書では、主にNEmacsを使って動作確認等を行なっているが、
オリジナルのGNU Emacsと異なる点については極力触れるように努力した。
残念な点は、本書は、「プログラマのためのEmacs」という観点で
記したものなので、NEmacsの日本語入力機能(EGG+Wnn)等には全く触れなかった。
また、その他の日本語関係の拡張機能の解説も、一部を除き割愛せざるを得なかった。
これらも、また別の機会に譲りたい。その時にはおそらく、Muleの話になると思うが。
○Mule
NEmacsの最新バージョンは、3.3.2である。半田氏によれば、NEmacsはこれが
最終バージョンで、打ち止めだそうである。以後は、この'Mule'が、
NEmacsの系譜を継ぐ。
'Mule' は、
'MULtilingual Enhancement to GNU Emacs'
のことだそうである。簡単に言えば、多国語対応Emacsである。
「ミュール」と発音する。
Muleでサポートする文字種は、
英語 ASCII
日本語 JISX0201(右側のカタカナ), JISX0208(漢字第1、第2水準)
中国語 GB2312, CNS11643
韓国語 KSC5601
ヨーロッパ系 ISO8859-1,2,3,4,5,7,9
プライベート ISO2022(ユーザ定義文字)
等である。これらの文字種を、同一ファイル／同一ウィンドウに混在させることが
可能である。図0001が、Muleのそのデモだが、ちょっと圧倒される。
多国語の文字は、X11R5のウィンドウ上で、Xのフォントを使用して表示している。
文字コード系は、ISO2022に従うことを仮定しているそうである。
とりあえず、Unicodeはサポートしていない。
各国語用の変換入力方式も提供されている。
実際に試用した感じとしては、NEmacsで提供されていた日本語処理用の機能が、
そのまま多国語対応になったという優れものである。
この他にも様々な拡張がなされている。が、ここでは詳細は省略する。
1993年7月現在は、Ver.0.9.8 PL05で、βテスト中である。
現在、GNU Emacs 18.59に対するパッチとして提供されている。
Muleは、次のDemacsも統合したものになるようである。
正式リリースは、1993年8月が見込まれている。
等という文章を書きながら、なかなかこの原稿が本にならずにいる内に、
とうとうMuleは正式リリースされてしまった。
1993年8月2日21時過ぎ、Mule 1.0(桐壺バージョン)が正式にリリースされた。
本書本文中で、MuleのNEmacsと異なる動作に触れた部分もある。
○Demacs
そう、最近では、80386のプロテクト・モードを利用するDOS-extender上で動作する、
Demacsというのも出てきた。もしかしたら、この本を手にしているあなたも、
Demacsユーザだったりするのだろうか？
Demacsは、386/486のDOSマシンで動作する。
一部の機能(UnixカーネルにあってDOSでサポートできない機能)が使えない
という制限があるが、これはもうGNU Emacsそのままである。
CPUが80386以上で、ディスクに余裕があり、実メモリも十分であるなら
これを使用するのも悪くないだろう。
この項も、J-3100SX001(DynaBook386)上のDemacs 1.2.0で書いている。
他の部分でも、J-3100SGT101上のDemacsで書いたところもある。
このバージョンのDemacsは、Emacs 18.55である。
Muleがリリースされる時には、このDemacsも含まれているだろう。
文献0505によれば、Demacsは「デマックス」と発音するらしい。
○Epoch
これも、GNU Emacs Ver.18に対するパッチである。
簡単に言えば、EmacsをXウィンドウ対応に拡張したものである。
Emacs 18は、1つの画面(screen)しか使用できなかった(cf. 第2章)。
Epochは、これをXウィンドウ対応にした。そして、複数の画面を扱えるようにした。
つまり、Epoch上で画面を分割／作成すると、それはXウィンドウの1ウィンドウとして
Xのディスプレイ上に現れる。勿論それぞれの画面は、Emacsと同様に複数の
テキスト・ウィンドウに分割することもできる。
その他に、細かいところでXに対応している。
これを日本語化した、NEpochというものも存在する。
Epochは、「エポック」或いは、「イーポック」と読むと思われる。
NEpochの読み方は、筆者は知らない。素直に「エヌ・イーポック」と
読めばいいのだろうか?
このEpochも、どうやらEmacs Ver.19に統合されるようである。
○Emacs
さて、本家本元のGNU Emacsである。
Ver.18は、Ver.18.59が最新である。おそらく、Ver.18はこれが最後だろう。
Ver.18は、単純なバグ修正等の保守のみを行う、保守モードに入るという。
Emacsは、Ver.19が最近リリースされた。1993年10月現在、Ver.19.19が最新。
Ver.19での新機能は、
変更前後のフック
Emacs-Lispのソース・レベル・デッバッグ機能
ヨーロッパ系文字セット(ISO8859のことと思われる)
浮動小数点サポート
不要になったメモリの、OSへの返却
(Emacs Ver.18では、再利用はしても、決して解放しなかった)
Xウィンドウ対応
(Epochの画面のことらしいが、'frame'と言っている)
等々あるようだが、この辺で省略する。
Ver.18同様、様々なUnix互換のOS上で動作するだろう。
Ver.19は試用した経験が筆者にはないので、良く分からない。
一応、Emacs 18.59のInfoには、Version 19では何が変わるか、の記述がある。
●動作確認環境
本書で紹介した機能は、全て筆者が動作を確認した。
また、本書の記述内容については、極力誤りをなくした積もりである。
が、如何せん何分至らぬ筆者であるため、誤り等もあるかもしれない。
その場合は、編集部気付けでお知らせ願いたい。
本文は、第1章は舘野が書き下ろしたものに筆者が一部加筆修正を加えた。
それ以外は全て、筆者単独で書いた。
最後に、動作確認環境を紹介しておく。
筆者の使用した環境は、
Emacs: NEmacs(NEmacs 3.3.2, Emacs 18.55)
ハード: AS4370, AS4260, AS4060, AS4075, AS4330
OS: SunOS Rel.4.0.3 JLE 1.0.3
SunOS Rel.4.1.1 JLE 1.1.1RevB
SunOS Rel.4.1.2 JLE 1.1.2
である。
AS4370等というのは、東芝で出しているSunのOEMマシンである。
AS4370をSunのモデル名に換算すれば、Sun-4/370という表記になる。
他も同様である。
一部にDemacsも利用した。
Emacs: Demacs 1.2.0(NEmacs 3.3.2, Emacs 18.55)
ハード: J-3100SX001, J-3100SGT101
MS-DOS: Ver.3.10
Muleについては、リリース前のものから、リリース直後のものまでを利用した。
Emacs: Mule 0.9.7.1 (Emacs 18.59) 〜 Mule 1.0 桐壷 (Emacs 18.59)
ハード: AS4075
OS: SunOS Rel.4.1.2 JLE 1.1.2
を試した。
さて、それではいよいよGNU Emacs使用法の具体的な解説に入る。
●本書中で使用した用語／訳語
本書中ではEmacs, NEmacs, Muleの各種概念を説明するために、
筆者独自の感覚に基づく用語を採用した。また、Emacsの各種英語マニュアルの
用語の翻訳も、筆者独自の訳である。従来一般的であった用語／訳語もあれば、
従来のものとは全く異なる用語／訳語もあるだろう。訳語の方に関しては、
なるべく原語を示すようにしたので、他のEmacs関連書籍と対応づける場合は
原語で参照して頂いた方がいいかもしれない。
これについては、賛否両論あるだろうと考えるが、この本に筆者独自の
用語／訳語を用いたのは、理解し易くなるだろうと判断してのことである。
一部には不適切なものもあるかもしれないが、筆者なりの一貫性を持たせた
積もりである。ご理解頂きたい。
但し、明らかに誤り／不適切と思われる用語／訳語については、
機会があれば訂正したいと考えているので、お気付き方は筆者宛或は
編集部気付け筆者宛でご指摘頂けると有り難い。
●謝辞
出版してくれる技術評論社、完成を辛抱強く待ってくれた金沢 修氏に感謝する。
こういうことがなければ、
筆者がこの原稿を完成させることはおそらくなかったであろうから。
東芝CAEシステムズの杉山 真一君には、Emacs-Lispでのプログラミングについて、
色々と助言を貰った。杉山 君にも感謝する。