C言語でエディタを作成！誰か助けて ください
守屋幸江
こんなことをお願いするのは失礼かと思いましたが、他に方法がないので
お尋ねします。
実は今、卒業研究で「エディタプログラムのソースを書け！」という、
授業をあまり聞いてなかった私には無茶な難題を出されました。
提出期限はあさってです。
どなたか、何処が間違っているのか教えてください。
完成した場合、もちろんお礼をさせていただきます。
初心者の私を助けてください。
lintをかけても警告多すぎて、どこがいけないのかもわかりません。
最後に、途中まで進んだバグだらけのソースとエラーの警告文を書いてお
きます。
よろしくお願い致します。
ちなみに学校のNEC製のSystem-Vでccにて開発しました。
本当のエディタは行数が多くなるとスクロールしますが、スクロール機能
の作り
方がわからないのでやめました。（情けない）
つまり、スクロールなし、検索なし、置換なしという使えないエディタで
す。
入力した文字を表示できて保存できればいいと思っています。
BSキーの変わりに[F1]+xで文字を削除します.
MAEDA Atusi
> 実は今、卒業研究で「エディタプログラムのソースを書け！」という、
> 授業をあまり聞いてなかった私には無茶な難題を出されました。
> 提出期限はあさってです。
カンニングはいけませんね。
自分でできないなら、残念ながら卒業できるだけの実力がないということでは。
＃ 「無茶な難題」ってあなた^^;)
前田敦司
Yutaka OIWA
>> On Fri, 12 Feb 1999 02:05:18 +0900, 守屋幸江 <usa...@geocities.co.jp> said:
usamogu> はじめまして、守屋と申します。
usamogu> こんなことをお願いするのは失礼かと思いましたが、他に方法がないので
usamogu> お尋ねします。
別の記事でも指摘されてますが、カンニングは論外ですね。課題なんて
自分で考えなきゃ意味ないです。基本的に、ネットニュースの
参加者の皆さんは、私も含めて宿題には厳しいですよ :)
まず答が帰ってくることは期待しない方がいいでしょう。
usamogu> 実は今、卒業研究で「エディタプログラムのソースを書け！」という、
usamogu> 授業をあまり聞いてなかった私には無茶な難題を出されました。
usamogu> 提出期限はあさってです。
usamogu> どなたか、何処が間違っているのか教えてください。
# まして授業聞いてないんじゃ救いようないよな～。
# エディタ作れって課題出せるくらいなら、まぁそこそこは
# 授業で教えてるんでしょうねぇ。
で、まぁ一応ソースファイル見てみました。
……はっきりいって、手遅れのような気がします。
本当にどれくらい授業聞いてたんでしょうか？
まぁとりあえず、1箇所間違っている中括弧の対応を直してから、
文字と文字列の扱い方をもう一度ちゃんと理解し直して下さい。
> if(load != "nothing")
なんて冗談にもなりません。
あと、局所変数と大域変数の宣言の効果についても。
テキスト見ればそれくらい書いてあるはずです。
あとは、まぁどの関数がそもそもどのデータを処理するのか、
自分でちゃんと把握して下さい。必要な引数がそもそも
渡されてない関数があります。
まぁ最低限最初にファイル読み込んで画面に表示するくらいは
なんとかあがいてくださいね。
# 正直、2日で添削しろっていわれても困るようなソースです。
# 0から書けといわれれば多分書けますが。
## でも今 卒論発表直前だから書けっていわないでね (笑)
--
大岩 寛 Yutaka Oiwa 東京大学理学部 情報科学科 米澤研究室
Email: <oi...@is.s.u-tokyo.ac.jp>, <yut...@oiwa.shibuya.tokyo.jp>
PGP fingerprint = C9 8D 5C B8 86 ED D8 07 EA 59 34 D8 F4 65 53 61
Hideo Sir MaNMOS Morishita
=?iso-2022-jp?B?GyRCPGkyMDksOT4bKEI=?= <usa...@geocities.co.jp> writes:
> はじめまして、守屋と申します。
> こんなことをお願いするのは失礼かと思いましたが、他に方法がないので
>
> お尋ねします。
他に方法はあります。
あきらめましょう。
＃何を卒業するのか知らないけど、お願いだからソフト業界に就職するのは止
＃めてね。
--
___ わしは、山吹色のかすてーらが大好きでのぅ
[[o o]] ふぉっふぉっふぉ
'J' 森下 お代官様 ＭａＮＭＯＳ 英夫＠ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D 02 74 87 52 7C B7 39 37
Seiji Suzuki
usa...@geocities.co.jp writes:
>> 実は今、卒業研究で「エディタプログラムのソースを書け！」という、
:
>> 最後に、途中まで進んだバグだらけのソースとエラーの警告文を書いてお
>> きます。
何でこんなになるまでほっておいたんですか。ソースを見ました。
きついようですが、まともな方法でちゃんと通る卒業研究を書くのは
無理です。
まず、ぱっと見では、
1. どうやら変数のスコープが理解できていない。
2. C で文字列を扱う方法が理解できていない。
ほかにも、構造化の仕方とか、何とも言いようの無い欠陥がいっぱいです。
ですから、まず、さらに機能を削ってしまいましょう。ロゴなんか表示
しなくてもいいでしょ。それでできなければ、スクリーンエディターを
作るのをあきらめて、ラインエディターにするか(カーソルの移動が単純に
なる)、ストリームエディターにする(画面表示もしなくてよくなる)。
なんかいい加減な助言をしてるな～。でも、まっとうな方法じゃあ
通りそうにありませんよ。
ku...@gssm.otsuka.tsukuba.ac.jp
se...@sunday.rsl.crl.fujixerox.co.jpさん:
> ですから、まず、さらに機能を削ってしまいましょう。ロゴなんか表
> 示しなくてもいいでしょ。それでできなければ、スクリーンエディター
> を作るのをあきらめて、ラインエディターにするか(カーソルの移動
> が単純になる)、ストリームエディターにする(画面表示もしなくてよ
> くなる)。
「最小限、どういう機能があればエディタと言えるか」って興味があ
りますよね。たとえば
・ファイルを読み書きする機能はない、
でもいいかも知れない。で、
・編集できる文字数が1文字(0文字や2文字以上はナシ)
でもいいかもしれない。すると、コマンドっていうのは「文字を置き換
える」ことと「終わる」ことだけですよね。すると次のプログラムはエ
ディタでしょうか?
#include <stdio.h>
main() {
int ch;
char buf = ' ';
while((ch = getchar()) != EOF) buf = ch;
putchar(buf);
}
うーむ… 久野
Junji Uehara
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> #include <stdio.h>
> main() {
> int ch;
> char buf = ' ';
> while((ch = getchar()) != EOF) buf = ch;
> putchar(buf);
> }
1ウィンドウに1つこれを動かして、
80x25個ぐらいのウィンドウを碁盤目上に
ならべれば立派なスクリーンエディタに…。
--
§NTTS○FT 技術開発部エレクトロニックコマース技術センター 上原 潤二 §
§今週の福本語録「金なんかいらない…40才まで借金でもいい…ただ生きたいっ」§
Seiji Suzuki
>> 「最小限、どういう機能があればエディタと言えるか」って興味があ
>> りますよね。たとえば
まあ、彼女たちも卒論の解答ズバリを教えてくれと言っているわけでは
ないので、何らかのサゼスチョンをしても良いのではないかと思います。
遅きにしっしている感はありますが。
大体、問題の仕様がひどすぎますね。エディッターってなんだ?
なにも、スクリーンエディッターでなくても、sed でもいいし、
「行頭に"X "があればそれを削って標準出力に出す」というものでも
良いような気がする。(しかも結構使えそう。)さらに、なにも
テキストを扱わなくても、バイナリーでも、ネットワーク上の
パケットでもなんでも編集できれば良いんですよね。そこで、
「彼女らの教授に文句を言わせない最小限のエディッターと
呼べる仕様を作成せよ」という要求にならどう答えましょうか。
私なら最小限界を究めた sed を作ります。そもそも、気圧計を使って
ビルの高さを測れとしかいってないんですから。守屋さんにお聞き
しますが、先生は正確に何と言ったんですか? (ちなみに、エディッターの
定義を訊くようなそんな薮蛇な事をしないように。)それによって
対応が違います。
---- ここからちゃちゃ ----
ちなみに、彼女らの教授を満足させられなくても「エディッター」と
呼べる物なら何でも良いと言うのなら、久野さんの例でもまだ大き
すぎるんじゃないですか。この例では編集に人間が介在していますが、
グラフィックエディッターの「編集」というプルダウンメニューには
人間が介在しない「画面にあわせる」などの機能が沢山あります。
そこで、こんなんどうでしょう。
#include <stdio.h>
int main( int argc, char *argv[] ){
int i;
for( i = 0; argv[1][i] != '\0'; i++ ){ putchar( argv[1][i]+1 ); }
return 0;
}
% gcc -Wall -O2 -o med editor.c
% med HAL
とかしてあそべるかも。
Kusakabe Youichi
: 大体、問題の仕様がひどすぎますね。エディッターってなんだ?
: なにも、スクリーンエディッターでなくても、sed でもいいし、
ふつうビットマップエディターやアイコンエディターや
Waveサウンドエディターや MIDIシーケンスエディターのことでは?
ヘ_ヘ ________________________
ミ・・ ミ vo...@merope.opus.or.jp
( ° )～ 日下部陽一
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ku...@gssm.otsuka.tsukuba.ac.jp
vo...@merope.opus.or.jpさん:
> ふつうビットマップエディターやアイコンエディターや
> Waveサウンドエディターや MIDIシーケンスエディターのことでは?
fj.editor.miscではテキストエディタの話が多いようですが。 久野
Masaya Ohtsuki
私のＣ言語を担当した教官は・・・
「総ての人が、コンピュータのプログラムを飯の糧にする
必要はないから、出来ないひとは出来なかった（やらな
かった)理由を、書いて提出すればよい。」っと、いって
ました。
ごもっともな意見であります。
どうしても判らないのならば、貴方もそうすればいいでしょう。
また、「コンピュータは道具であるから、作った人の気持ち
になって使えば、よく動いてくれるものである」ともいってま
した。
文法的に簡単な間違いをしている個所は、lintが教えて
くれてます。
lintはＣコンパイラでは見つけにくい記述の作法的問題に
近い誤りを指摘するために作られたと某文献から聞いて
おります。
道具は生まれてきた理由がありますから、作った人の気
持ちを考えましょう。
そうすれば、きっとうまくいきます。
実習の時間は、「専門家が相手にしなくてもコンピュータは、
ちゃんという事を聞いてくれるんだ」が口癖でした。
なんでも先生は、マイコンなんて入社するまで存在すらしな
かったが、辞令から三月だかなんかでリエントラントに動く
プログラムを機械語で書いたそうです。（マイコンが4ビッ
トだの5ビットとかの時代）
--
おおつき まさや http://www.asahi-net.or.jp/~JC5M-OOTK/
守屋幸江 wrote in message <36C30DCC...@geocities.co.jp>...
> はじめまして、守屋と申します。
> こんなことをお願いするのは失礼かと思いましたが、他に方法がないので
>
> お尋ねします。
>
> 実は今、卒業研究で「エディタプログラムのソースを書け！」という、
> 授業をあまり聞いてなかった私には無茶な難題を出されました。
> 提出期限はあさってです。
Shinji Kono
In article <7a0ql0$1of$1...@atlas.fen.crl.fujixerox.co.jp> ,
se...@sunday.rsl.crl.fujixerox.co.jp (Seiji Suzuki) writes
> 大体、問題の仕様がひどすぎますね。エディッターってなんだ?
さぁ? 理解できた仕様がそうだってことなんでしょう。
僕だったら Perl/Tk で書くかも。5行でできますね。
use Tk;
$m = MainWindow->new;
$t = $m->Text;
$t->pack;
$m->MainLoop;
C でないぞといわれれば、そうなんだけど。
昔、Sicstus Prolog を Dynabook SS001 に載せた時に、task 切替できない
ので、しょうがないので、その場で line editor を書きました。
---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科
ku...@gssm.otsuka.tsukuba.ac.jp
ko...@ie.u-ryukyu.ac.jpさん:
> 僕だったら Perl/Tk で書くかも。5行でできますね。
> C でないぞといわれれば、そうなんだけど。
そうきたか。だったら私はCで
main() { execl("/usr/local/bin/mule", "mule", 0); } 久野
ku...@gssm.otsuka.tsukuba.ac.jp
ja...@james.jp9.orgさん:
> James君です。久野さん，お久しぶりです。
...でしたっけ ^_^; 見る方はよく拝見してますもんで。
> あのエディタでは，コマンドラインで開くファイルの指定が出来ます
> よ，到底機能はしませんが。
そうマジになっちゃうと面白くないですよね。たとえば発想として、
main() { }
なんていうのはどうでしょうか? (打ち込んで動かすのにエディタを使
うでしょう?)
ワルノリだったか。 久野
James君
あはは，これは素晴らしい。
あのエディタでは，コマンドラインで開くファイルの指定が出来ますよ，到底
機能はしませんが。
久野さんバージョンをちょろちょろと直すと，
void main(int argc,char *argv[])
{
if(argc > 2) printf("ERROR!\n");
else execl("/usr/local/bin/mule", "mule"
, argc == 2 ? argv[1] : 0,0);
}
ですが，あまり面白くないですね。久野さんオリジナルの方がずっと面白いや。
James君
Masaya Ohtsuki
> main(){}
みたいに短いテキストを入力するなら、エディタなんか起動しなくても
$ echo 'main(){}' >main.c
とか
$cat >main.c
で、なんかいれて終るだけ。
でも十分いけてると思うよ。
--
おおつき まさや http://www.asahi-net.or.jp/~JC5M-OOTK/
ku...@gssm.otsuka.tsukuba.ac.jp wrote in message
<7a7mh3$r...@utogw.gssm.otsuka.tsukuba.ac.jp>...
>久野です。
ku...@gssm.otsuka.tsukuba.ac.jp
> みたいに短いテキストを入力するなら、エディタなんか起動しなくても
> $ echo 'main(){}' >main.c
> とか
> $cat >main.c
> で、なんかいれて終るだけ。でも十分いけてると思うよ。
絶対そう言われるからイマイチなギャグなわけで。しかしそう来るなら
$ echo 'main() {}' | gcc -
ではないでしょうか。
大嘘でした :-P 久野
P.S. しかしどっかにこれができるコンパイラがあるかも…
IKEDA Kenji
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> P.S. しかしどっかにこれができるコンパイラがあるかも…
リロケータブルオブジュクトの出力まででいいのであれば、
echo 'main () {}' | /usr/libexec/cc1 | as
P.S. しかしどっかに標準入力が処理できるロードリンカがあるかも…
--
池田研二 調布市多摩川在住
James君
や，これはご無礼仕りました。クロスコンパイラ/クロス開発システムの話は
一年も前の事でしたから，覚えておられないのも無理からぬ事です。
ku...@gssm.otsuka.tsukuba.ac.jp wrote:
> > あのエディタでは，コマンドラインで開くファイルの指定が出来ます
> > よ，到底機能はしませんが。
>
> そうマジになっちゃうと面白くないですよね。
「受け」を狙うんだったら，真面目にやっちゃダメ。それで，
>ですが，あまり面白くないですね。久野さんオリジナルの方がずっと面白いや。
という訳で。
ところで，この話の元々は，自分で作ったエディタがダメ，って話でしたよ
ね。それでアウトソーシングしようと。
アウトソーシングを指向するのであれば，コストとの兼ね合いがやはり大事だ
と思います。さすれば人に直して貰うもコスト的に合わないでしょう。
やっぱりここは，シンプルに完成品導入だと思いますね。viとか。
James君
Chijihiro Sakata
echo '#include "/dev/tty"' >hoge.c; gcc hoge.c
では、いかがでしょうか？
# hoge.c が残るのがイマイチですが....。
Kazuo Fox Dohzono
In article <86lnhzw...@kamui.mob.or.jp>
no...@mob.or.jp (IKEDA Kenji) writes:
> リロケータブルオブジュクトの出力まででいいのであれば、
>
> echo 'main () {}' | /usr/libexec/cc1 | as
この手のネタは何度か目にしますが, ちょっと昔の IOCCC ではファイル名に
プログラムを書いて, ファイルの中でプリディファインマクロ __FILE__ を巧
妙に使うという技が披露されていました.
プログラムではなくその技自体が IOCCC の評価対象だったのですが, UNIX ファ
イルシステムなら本体をハードリンクしておけば一つで済む, ファイル名長の
制限から強制的にモジュール化を強いられるなどの利点が挙げられていました.
まともにコンパイルできる環境が少なかったこと, それにまともに動作するデ
バッガが＊皆無＊であったことが惜しまれます :-)
--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp
[12],(6,9),0,0,2
(436/14269/27435)
Masaya Ohtsuki
>no...@mob.or.jp (IKEDA Kenji) writes:
>
>> In article <7a960c$8...@utogw.gssm.otsuka.tsukuba.ac.jp>,
>> ku...@gssm.otsuka.tsukuba.ac.jp writes:
>>
>> > P.S. しかしどっかにこれができるコンパイラがあるかも…
>>
>>
>> echo 'main () {}' | /usr/libexec/cc1 | as
>>
>
> echo '#include "/dev/tty"' >hoge.c; gcc hoge.c
>
>では、いかがでしょうか？
>
># hoge.c が残るのがイマイチですが....。
hoge.cをパイプの名前にしておけば、
読み終ったら消えてしまいます。
って、いったところで、あたしはＰＯＳＩＸ系OSでもって、
ネーム・ド・パイプを使ったことがないから、コマンド
ラインが書けないや。（うう。ちょっぴり悔しい）
Hideki Sakurada
おおつきさん:
> ネーム・ド・パイプを使ったことがないから、コマンド
> ラインが書けないや。（うう。ちょっぴり悔しい）
コマン・ド・ラインじゃないのか...
--
櫻田英樹 <saku...@kuis.kyoto-u.ac.jp>
Hideo Sir MaNMOS Morishita
Kazuo Fox Dohzono
In article <7adbt0$skb$1...@news2.na.rim.or.jp>
doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes:
> この手のネタは何度か目にしますが, ちょっと昔の IOCCC ではファイル名に
> プログラムを書いて, ファイルの中でプリディファインマクロ __FILE__ を巧
> 妙に使うという技が披露されていました.
'93 の IOCCC でした. プログラムは
char*_=__FILE__;
これだけで全然 Obfuscated ではないのですが, ファイル名を
";main(){puts("Hello World!");}char*C=".c
のようにすると先の一行が
char*_="";main(){puts("Hello World!");}char*C=".c";
のように展開されるというオチ.
あ, minimum editor じゃないや (^^;; editor なら IOCCC '91 にありました.
ant: ant.c
${CC} ${CFLAGS} -DMODE=0600 -DBUF=32767 ant.c -o ant -lcurses -ltermcap
のようにコンパイルしてください.
Best Utility: <a...@mks.com> Anthony C Howe
COMMANDS
h j k l left, down, up, right cursor movement
H J K L word left, page down, page up, word right
[ ] beginning and end of line
t b top and bottom of file
i enter insert mode, formfeed to quit
x delete character under the cursor
W write buffer to file
R refresh the screen
Q quit
EXIT STATUS
0 success
2 missing edit filename
#include <ctype.h>
#include <curses.h>
#define T isspace(*(t=Z(p)))&&
#define V return
#define _ while
int d,i,j,m,n,p,q,x,y;char*c,b[BUF],*f,*g=b,*h,k[]="hjklHJKL[]tbixWRQ",*t;
char*Z(a){if(a<0)V b;V b+a+(b+a<g?0:h-g);}P(a)char*a;{V
a-b-(a<h?0:h-g);}S(){p=0;}bf(){n=p=P(c);}Q(){q=1;}C(){clear();Y();}
G(){t=Z(p);_(t<g)*--h= *--g;_(h<t)*g++= *h++;p=P(h);}B(){_(!T b<t)--p;_(T
b<t)--p;}M(a){_(b<(t=Z(--a))&&*t-'\n');V
b<t?++a:0;}N(a){_((t=Z(a++))<c&&*t-'\n');V
t<c?a:P(c);}A(a,j){i=0;_((t=Z(a))<c&&*t-'\n'&&i<j){i+= *t-'\t'?1:8-(i&7);++a;}V
a;}L(){0<p&&--p;}R(){p<P(c)&&++p;}U(){p=A(M(M(p)-1),x);}
D(){p=A(N(p),x);}H(){p=M(p);}E(){p=N(p);L();}
J(){m=p=M(n-1);_(0<y--)D();n=P(c);}K(){j=d;_(0<--j)m=M(m-1),U();}
I(){G();_((j=getch())-'\f'){if(j-'\b')g-h&&(*g++=j-'\r'?j:'\n');else
b<g&&--g;p=P(h);Y();}}X(){G();p=h<c?P(++h):p;}
F(){j=p;p=0;G();write(i=creat(f,MODE),h,(int)(c-h));close(i);p=j;}W(){_(!T
t<c)++p;_(T
t<c)++p;}int(*z[])()={L,D,U,R,B,J,K,W,H,E,S,bf,I,X,F,C,Q,G};
Y(){m=p<m?M(p):m;if(n<=p){m=N(p);i=m-P(c)?d:d-2;_(0<i--)m=M(m-1);}
move(0,0);i=j=0;n=m;_(1){p-n||(y=i,x=j);t=Z(n);if(d<=i||c<=t)break;
if(*t-'\r')addch(*t),j+= *t-'\t'?1:8-(j&7);if(*t=='\n'||COLS<=j)
++i,j=0;++n;}clrtobot();++i<d&&mvaddstr(i,0,"<< EOF >>");move(y,x);
refresh();}main(u,v)char**v;{h=c=b+BUF;if(u<2)V
2;initscr();d=LINES;raw();noecho();idlok(stdscr,1);if(0<(i=open(f= *++v,0))){
g+=read(i,b,BUF);g=g<b?b:g;close(i);}S();_(!q){Y();i=0;j=getch();
_(k[i]&&j-k[i])++i;(*z[i])();}endwin();V 0;}
--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp
[12],(6,9),0,0,2
(452/14987/28884)
KATAYAMA Yoshio
doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes:
>'93 の IOCCC でした. プログラムは
>char*_=__FILE__;
>これだけで全然 Obfuscated ではないのですが, ファイル名を
> ";main(){puts("Hello World!");}char*C=".c
>のようにすると先の一行が
>char*_="";main(){puts("Hello World!");}char*C=".c";
>のように展開されるというオチ.
ANSI C では、__FILE__ は一つの文字列リテラルに展開されることになっ
ていますから、この方法は使えません。
--
片山＠ＰＦＵ
isioka hirosi
usa...@geocities.co.jpさんは書きました。
>> 実は今、卒業研究で「エディタプログラムのソースを書け！」という、
>> 授業をあまり聞いてなかった私には無茶な難題を出されました。
>> 提出期限はあさってです。
いろいろ言われてしまった上に追い打ちをかけるようでナンなんですが、
結局どうされたのですか?
# 授業を聞いてなかった為に卒業研究まで辿りつけなかった身としては
# 羨ましいというかなんというか、とにかく
# ひじょーに興味があるのですが(^^;
---
ishioka
Junn Ohta
yssk...@mbox.kyoto-inet.or.jpさんは書きました。
> これと、（テキスト）エディタって普通、リンクドリストを使いませんか？
最近はgap bufferでは?
--
太田純(Junn Ohta) (株)リコー 販事本S計画C NWS計画室DMSG
oh...@src.ricoh.co.jp/JCF0...@nifty.ne.jp
近藤妥
守屋幸江 wrote in message <36C30DCC...@geocities.co.jp>...
（本文省略）
これとまったく同じ投稿が、
http://www.intacc.ne.jp/HP/yosinori/c/index.htm
の掲示板に書いてあった。
守屋君、ねっ。みんな同じ事を言うでしょ。（＾＾）
これと、（テキスト）エディタって普通、リンクドリストを使いませんか？
ku...@gssm.otsuka.tsukuba.ac.jp
oh...@src.ricoh.co.jpさん:
> 最近はgap bufferでは?
この「最近」がいつかについて興味があります。少なくとも1980年こ
ろには和田英一先生が授業か何かでgap buffer(という名前をおっしゃっ
たかどうかは記憶してません)について説明されたのを拝見したような
気がするのですが…
和田先生は読んでないのかな… 久野
Junn Ohta
ku...@gssm.otsuka.tsukuba.ac.jpさんは書きました。
> この「最近」がいつかについて興味があります。
ここ15年くらい、という認識でした。:-)
自分で実装したのはUNIX USER誌の連載で書いたtinyが
初めてですが、それ以前からたびたび目にしていました。
Emacsにしても何にしても、行長の制約の少ないものを
効率よく書こうとするとgap bufferしかないのかな、と
いう気がします。
# magic fileというのもありましたが、あれはどこかが
# 特許を持っていたような。
一般書籍としては5年くらい前にビレッジセンター出版
局から「Craft of Text Editing」というのが出ていま
したね。この中でもgap bufferについての解説があった
と思います。レイアウトの汚い本で、内容に興味がなけ
ればとうてい読みたくないようなものでしたが...。
Shugo Maeda
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> > 最近はgap bufferでは?
>
> この「最近」がいつかについて興味があります。少なくとも1980年こ
> ろには和田英一先生が授業か何かでgap buffer(という名前をおっしゃっ
> たかどうかは記憶してません)について説明されたのを拝見したような
> 気がするのですが…
"The Craft of Text Editing"によると最初にバッファギャップ方
式を採用したエディタはTECOだそうです。
# まだわたしが生まれていない頃の話かな(^_^;
--
前田 修吾
MAEDA Atusi
> 一般書籍としては5年くらい前にビレッジセンター出版
> 局から「Craft of Text Editing」というのが出ていま
> したね。この中でもgap bufferについての解説があった
> と思います。レイアウトの汚い本で、内容に興味がなけ
> ればとうてい読みたくないようなものでしたが...。
一般書籍と言って良いかどうか分かりませんが、
湯浅太一・萩谷昌己「CommonLispプログラミング」岩波書店(1986)
にgap bufferを使ったテキストエディタの例題がありました。
前田敦司
sai...@ex.ecip.osaka-u.ac.jp
> Emacsにしても何にしても、行長の制約の少ないものを
> 効率よく書こうとするとgap bufferしかないのかな、と
> いう気がします。
> 太田純(Junn Ohta) (株)リコー 販事本S計画C NWS計画室DMSG
> oh...@src.ricoh.co.jp/JCF0...@nifty.ne.jp
gap bufferって、「書く効率」がよいだけで、実行効率は
よくないですよね。
もう15年ほど昔ですがメインフレームでgap buffer式の
スクリーンエディタを使ってあっと言うまに課金が予算に
達してしまって泣いた事があります。
齊藤
ku...@gssm.otsuka.tsukuba.ac.jp
sai...@ex.ecip.osaka-u.ac.jpさん:
> gap bufferって、「書く効率」がよいだけで、実行効率はよくないで
> すよね。
書く効率、大事じゃないですか?
> もう15年ほど昔ですがメインフレームでgap buffer式のスクリーンエ
> ディタを使ってあっと言うまに課金が予算に達してしまって泣いた事
> があります。
なるほど… ;_;
私も改良の方法はいろいろ考えたのですが…
(1)実際に挿入/削除が起きるまでは「仮想的な」ギャップを動かすだ
けで本物のギャップは動かさない。
(2)動かすときはmove命令などできるだけ速い命令でがんばる。
(でもここでワードアラインメントが合ってないと… ;_;)
(3)文字のギャップバッファと並行してその中の各行の切れ目を指す
行のギャップバッファを持っておく(行単位のスキャンや操作が速
くなる)。
未だにプログラミングにそれを使ってます。 久野
P.S. あと、Unixになってからの最大の強みは「どんな巨大なファイル
でもあっという間に編集開始できる」read1発かmmap1発ですもん
ね。これでviには楽勝。というか、今は行の連結リストが速いと
いう気は全然しません。
Junn Ohta
sai...@ex.ecip.osaka-u.ac.jpさんは書きました。
> gap bufferって、「書く効率」がよいだけで、実行効率は
着目点の更新(文字挿入とか削除とか)が安価にできるか
わりに着目点の移動(カーソル移動とかスクロールとか)
にコストがかかる方式ですが、後者は画面更新などを伴
うことが多くコストがかかっても他のコストに埋没する
という、合理的な面があると思います。
まあトータルコストはlinked list of linesのほうが安
くあがるのかな? でも行長の制約を軽減しようとすると
こっちはえらくたいへんですよね。
> もう15年ほど昔ですがメインフレームでgap buffer式の
> スクリーンエディタを使ってあっと言うまに課金が予算に
> 達してしまって泣いた事があります。
そもそもそんな環境でスクリーンエディターを使うこと
のほうが間違っているのでは? :-)
メインフレームだと固定長レコード(=行)データセット
がきわめて効率よく利用できるようになっていたでしょ
う。レコードの挿入や移動も簡単ですよね。それとgap
bufferを比較するのはかわいそうな気もします。
--
NAKAGAWA
yssk...@mbox.kyoto-inet.or.jpさんは
1999年02月25日(木)05時23分発信の
<7b1nd2$g3$1...@news.kyoto-inet.or.jp>すなわち
"Re: Minimum Editor (Re: C言語で...)" と題した記事にて
こう書かれました。
# fj.editor.misc へのクロスポストは、再度外しました。
> > int ch;
> > char buf = ' ';
ここを引用されている以上自明ではないでしょうか
> なんで、putchar(ch);ではいけないのでしょうか？
> buf=ch;
> って無駄な処理におもえるのですが、、、、
キャストしても同じ処理が発生するから、"無駄" では
ないと思うのですが... コンパイラの実装としてはこの
理解で正しいんでしょうかね。
------------------------------------------------------------
NAKAGAWA Tsuneo ( 中川 恒雄 )
---- 自分がギャンブルをしていることに気がつかない
ギャンブラくらい怖いものはない ---
mailto:yae...@alles.or.jp
MAEDA Atusi
> ma...@is.uec.ac.jpさん:
> > 私も、最近の環境ではgap bufferの方が良いだろうと(漠然と)思って
> > いるのですが、いくつか良く分からない点があるのです。(私は
> > PDP-11のアセンブラで原始的なgap bufferのエディタを書いた事があ
> > るだけです。)
>
> おやそれは奇遇な。私なんかPDP-11のマシン語直接打ち込みでgap
> bufferのスクリーンエディタを書きました。ちなみに簡単なローダも書
> きました。つまりメモリ上のgap bufferにローダ語のテキストを作って、
> それをロードする(っていうんだろうか?)と指定した番地にマシン語の
> プログラムができる、という最低限の開発環境なわけです。ファイルと
> いう概念はなかった(メモリの若い番地を1シリンダどさっとディスクに
> 保存したりそこから復元するというプログラムを木村先生が用意してた)。
ひょえー統合開発環境(笑)。(「ローダ語」って?)
私が書いたエディタはただのテキストエディタでした。ただ、実習する学部生
が皆使うものだったのでそれなりに気合いが入りましたが。
> > (1) ファイルとのI/Oが簡単だという利点は、muleのように文字コー
> > ド変換を行なうエディタでは薄れてしまったのではないか?
>
> ですよねえ。ただ自動セーブがありますね。
む? 自動セーブ時も文字コード変換しながら書くんですよねえ?
(あれ、内部コードで書くのかな?)。
> > (2) linked listを使ったエディタで、たいてい行の長さに制限があ
> > るのはなぜ? ([1]によれば、Multics Emacsではそんな制限はな
> > かったみたいです。)行の長さを記録するかわりに'\n'を終の印
> > とするのではダメなの? あるいは行の長さを4バイトで表すとか?
>
> 長さを1バイトに詰めるというケチな人が多かったから? 久野
'\n'だって1バイトなんですが...
前田敦司
MAEDA Atusi
> gap bufferって、「書く効率」がよいだけで、実行効率は
> よくないですよね。
gap bufferだと、
* I/Oの効率がとても良い(ただし文字コードの変換をしない時)。
* 検索の実装が簡単(特に複数行にマッチするようなパターンを許す時)。
* 削除は定数時間(バッファを縮小しない時)。
* 挿入は... gapのサイズとファイルサイズの比を一定に保てば、平均的には定数
時間(これは冗談)。
前田敦司
近藤妥
Junn Ohta wrote in message <7aupa2$i...@ns.src.ricoh.co.jp>...
>fj.comp.lang.cの記事<7aun0s$mig$1...@news.kyoto-inet.or.jp>で
> yssk...@mbox.kyoto-inet.or.jpさんは書きました。
>> これと、（テキスト）エディタって普通、リンクドリストを使いませんか？
>
>最近はgap bufferでは?
ってなんですか（恥）？
近藤妥
ku...@gssm.otsuka.tsukuba.ac.jp wrote in message
<7a0hvm$m...@utogw.gssm.otsuka.tsukuba.ac.jp>...
>久野です。
> #include <stdio.h>
> main() {
> int ch;
> char buf = ' ';
> while((ch = getchar()) != EOF) buf = ch;
> putchar(buf);
近藤妥
NAKAGAWA wrote in message <7b22p0$hf7$1...@news.alles.or.jp>...
>パイプ喫いの中川と申します。
すみません、ソースを読み間違えていました。
今日の未明の投稿そのものが間違いです。
すみませんでした。
TANAKA Yoshitomo
<ku...@gssm.otsuka.tsukuba.ac.jp> wrote:
>
>oh...@src.ricoh.co.jpさん:
>> 最近はgap bufferでは?
>
> この「最近」がいつかについて興味があります。少なくとも1980年こ
>ろには和田英一先生が授業か何かでgap buffer(という名前をおっしゃっ
gap buffer方式、というものが私の理解しているものであるなら、
CP/Mに付いて来たEDがそうでしたね。
逆アセンブルしてソースを起こして眺めてましたが、
うまいやり方だなぁと妙に感動した覚えが:-)
----_--__---_-_-_-__--_-__-__---_-_----_--_-_---_---_----
_/ TANAKA Yoshitomo _//
/ Suginami-ku Tokyo, Japan _// se...@silkwood.rim.or.jp
Junn Ohta
fj.comp.lang.cの記事<7b2g6b$2h3$1...@silkwood.rim.or.jp>で
se...@silkwood.rim.or.jpさんは書きました。
> gap buffer方式、というものが私の理解しているものであるなら、
> CP/Mに付いて来たEDがそうでしたね。
これは知りませんでした。実際のところgap bufferって
いつごろから使われていたのでしょうか。どなたかご存
じの方はいらっしゃいませんか?
ku...@gssm.otsuka.tsukuba.ac.jp
ma...@src.ricoh.co.jpさん:
> 仮想メモリのページテーブルだけ変更して、ページサイズを超えるコ
> ピーは発生しないのが当然……と思っていたのですが、mule-2.3はそ
> うなっていませんね。あれれ?
ページテーブルの変更だけで済むのは移動するモノがページ境界に合っ
てる場合だけでしょ? ということは、途中にすき間を設けても必要なつ
どページ境界に合わせてマップを変更する?
なるほど、その方式だとgap bufferというよりバッファをちぎちぎの
ブロックで表現して、必要なところをギャップとして使うという感じに
なるのかも。
あんまり作りたくならないな… 久野
ku...@gssm.otsuka.tsukuba.ac.jp
yssk...@mbox.kyoto-inet.or.jpさん:
> ってなんですか（恥）？
はいはい。
まず、「文字カーソルが常に文字と文字の間にある」というバッファ
のモデルであるとします。そこでabc...xyzの「cとdの間」にカーソル
があるなら
abc defghijklmnopqrstuvwxyz
のように表します。カーソルを1文字右に移動すると
abcd efghijklmnopqrstuvwxyz
となるわけです。ここで大文字のABCをカーソルの直前に挿入すると
abcdABC efghijklmnopqrstuvwxyz
となり、カーソルの右側を4文字削除すると
abcdABC ijklmnopqrstuvwxyz
となるわけです。つまりバッファ内容の先頭や末尾はバッファ領域の先
頭や末尾にくっついていて、カーソルのある位置がギャップになってる
わけです。文字カーソルの前後でのみ挿入/削除を行うというのは自然
なモデルですから、それとの対応関係がとても自然。
まあこういう方法ですね。 久野
ku...@gssm.otsuka.tsukuba.ac.jp
yssk...@mbox.kyoto-inet.or.jpさん:
> なんで、putchar(ch);ではいけないのでしょうか？
> buf=ch;
> って無駄な処理におもえるのですが、、、、
それは「バッファ」がないとエディタぽくないから :-) 久野
MAEDA Atusi
> fj.comp.lang.cの記事<7b2g6b$2h3$1...@silkwood.rim.or.jp>で
> se...@silkwood.rim.or.jpさんは書きました。
> > gap buffer方式、というものが私の理解しているものであるなら、
> > CP/Mに付いて来たEDがそうでしたね。
>
> これは知りませんでした。実際のところgap bufferって
> いつごろから使われていたのでしょうか。どなたかご存
> じの方はいらっしゃいませんか?
どうやら、gap bufferの方がdoubly-linked listよりだいぶ古いようです。
[1]によれば、Multics上のエディタqedx, edmはいずれもgap bufferだそうで
す。TECOが最初からgap bufferだったとすると、1962年という事になるようで
す。
[2]には、「最初のEmacsはgapのあるbufferを使っていたが、後にもっと良い
方法であるdoubly-linked listを使った実装が出て来た」(!)という趣旨の事
が書いてあります。
＃ そういえば、太古はリスト構造なんて一般的じゃなかったかも...
[1] Multics Emacs: The History, Design and Implementation,
Bernard S. Greenberg, http://www.lilli.com/mepap.html
[2] EMACS: The Extensible, Customizable Display Editor,
Richard M. Stallman, http://www.gnu.org/software/emacs/emacs-paper.html
前田敦司
Kaoru MAEDA
> ページテーブルの変更だけで済むのは移動するモノがページ境界に合っ
> てる場合だけでしょ? ということは、途中にすき間を設けても必要なつ
> どページ境界に合わせてマップを変更する?
ああそうか。ギャップの長さを調節すれば移動する距離はページ単位に
できるかと思いましたが、できませんね。私のカン違いだったようです。
===1===|===2===|===3===|===4===|-5-| g |===6===|……
↓ギャップの左移動
-1-| g |-1|===2===|===3===|===4===|-5-|-6-|-6--|……
これだと2、3、4の代わりに6以降をコピーしてるだけだし。
------------------------------- Vulture LRM20 .□||□. LRM20
前田 薫 ma...@src.ricoh.co.jp 75t 175km/h Md+ o'□||□`o Md+
(株)リコー ソフトウェア研究所 HeatSink 18 LG Sm+ .=X~~X=. Sm+ LG
------------------------------- Armor 2195 _|_ _|_
Junn Ohta
ma...@is.uec.ac.jpさんは書きました。
> どうやら、gap bufferの方がdoubly-linked listよりだいぶ古いようです。
(@_@;) (_ _;) (_ _;) (_ _;)
だとすると、私の最初の発言は少なからず的外れだった
ことになりそうです。失礼しました。
とはいえ、
> [2]には、「最初のEmacsはgapのあるbufferを使っていたが、後にもっと良い
> 方法であるdoubly-linked listを使った実装が出て来た」(!)という趣旨の
という評価はさすがに現在でもそのまま通用するわけで
はないですよね?
Shugo Maeda
MAEDA Atusi <ma...@is.uec.ac.jp> writes:
> [2]には、「最初のEmacsはgapのあるbufferを使っていたが、後にもっと良い
> 方法であるdoubly-linked listを使った実装が出て来た」(!)という趣旨の事
> が書いてあります。
Lispマシン上とかの話なのではないでしょうか。
--
前田 修吾
じゃあ何でJEDはlinked line方式なんだろう。
MAEDA Atusi
うグループってないんでしたっけ?)
oh...@src.ricoh.co.jp (Junn Ohta) writes:
> fj.comp.lang.cの記事<pyplnhn...@tp560e.sowa.is.uec.ac.jp>で
> ma...@is.uec.ac.jpさんは書きました。
> > どうやら、gap bufferの方がdoubly-linked listよりだいぶ古いようです。
> だとすると、私の最初の発言は少なからず的外れだった
> ことになりそうです。失礼しました。
いえいえ、太古はgap buffer -> linked list 登場 -> 最近はgap bufferなら
別に外れてないのでは。
> > [2]には、「最初のEmacsはgapのあるbufferを使っていたが、後にもっと良い
> > 方法であるdoubly-linked listを使った実装が出て来た」(!)という趣旨の
>
> という評価はさすがに現在でもそのまま通用するわけで
> はないですよね?
[2] でdoubly-linked listの方が良いといっているのは、画面のredisplayの
最適化に便利だというのが主な理由のようです。(時代を感じますね。) その
他、
* 編集コマンドが何を変更したか(画面のどの範囲を再描画する可能性がある
か)をプログラマが気にしなくて良い。
* マークの実装が楽。
を利点として挙げています。低レベルルーチン(挿入/削除/検索)だけは複雑に
なるが、後はずっと楽だと。
私が挙げた文書は、主としてEmacs系のエディタの歴史を扱ったものでした。
それ以前の(主としてラインオリエンテッドな)エディタについても述べていま
したが。その他に以下の文書を見つけました。
[3] comp.editors FAQ, maintained by Ove Ruben R Olsen,
ftp://alf.uib.no/pub/vi/docs/comp.editors.FAQ
[4.1～4.5] ftp://alf.uib.no/pub/vi/docs/editech.[1-5].Z
[5] Data Structures for Text Sequences, Charles Crowley,
http://www.cs.unm.edu/~crowley/papers/sds/node1.html
[1][2]とは書かれた時代も違うし、[4.1～4.5]では(まとまった文書ではない
ので)内容もやや錯綜していますが、[4.1]によればgap bufferは、
* メモリ管理機能がないマシンか、本当に良いメモリ管理機能を持つマシンに
向いている。
* 時おり長いdelayを引き起こしてしまうが、CPU消費時間ではlinked-listに
比べてはるかに優っている(約20倍)。メモリ効率でも優っている(約2倍)。
との事です。たしかに、仮想記憶どころかmallocもない原始的な環境ではgap
bufferの方がきっと簡単ですよね。
＃ その他[4.1～4.5]では、両者の技法のバリエーション(pointを動かしてもgap
＃ を動かさない/複数のgap bufferのリストを使う等)や、大きなファイルを扱う
＃ ためのソフト的な仮想記憶についても書いてあります。
私も、最近の環境ではgap bufferの方が良いだろうと(漠然と)思っているので
すが、いくつか良く分からない点があるのです。(私はPDP-11のアセンブラで
原始的なgap bufferのエディタを書いた事があるだけです。)
(1) ファイルとのI/Oが簡単だという利点は、muleのように文字コード変換を
行なうエディタでは薄れてしまったのではないか?
(2) linked listを使ったエディタで、たいてい行の長さに制限があるのはな
ぜ? ([1]によれば、Multics Emacsではそんな制限はなかったみたいです。)
行の長さを記録するかわりに'\n'を終の印とするのではダメなの? あるい
は行の長さを4バイトで表すとか?
前田敦司
MAEDA Atusi
> MAEDA Atusi <ma...@is.uec.ac.jp> writes:
>
> > [2]には、「最初のEmacsはgapのあるbufferを使っていたが、後にもっと良い
> > 方法であるdoubly-linked listを使った実装が出て来た」(!)という趣旨の事
> > が書いてあります。
>
> Lispマシン上とかの話なのではないでしょうか。
PDP-10ですね、主に。Multics Emacsも(MacLispで書かれてはいますが)PDP-10
上です。その後のZWEI(linked list式)はMIT Lisp Machineです。
> --
> 前田 修吾
> じゃあ何でJEDはlinked line方式なんだろう。
ていうか、じゃあ何でGNU Emacsはgap bufferなんだろう? ([2]の著者は
Stallman自身です。)
前田敦司
ku...@gssm.otsuka.tsukuba.ac.jp
ma...@is.uec.ac.jpさん:
> 私も、最近の環境ではgap bufferの方が良いだろうと(漠然と)思って
> いるのですが、いくつか良く分からない点があるのです。(私は
> PDP-11のアセンブラで原始的なgap bufferのエディタを書いた事があ
> るだけです。)
おやそれは奇遇な。私なんかPDP-11のマシン語直接打ち込みでgap
bufferのスクリーンエディタを書きました。ちなみに簡単なローダも書
きました。つまりメモリ上のgap bufferにローダ語のテキストを作って、
それをロードする(っていうんだろうか?)と指定した番地にマシン語の
プログラムができる、という最低限の開発環境なわけです。ファイルと
いう概念はなかった(メモリの若い番地を1シリンダどさっとディスクに
保存したりそこから復元するというプログラムを木村先生が用意してた)。
> (1) ファイルとのI/Oが簡単だという利点は、muleのように文字コー
> ド変換を行なうエディタでは薄れてしまったのではないか?
ですよねえ。ただ自動セーブがありますね。
> (2) linked listを使ったエディタで、たいてい行の長さに制限があ
ku...@gssm.otsuka.tsukuba.ac.jp
ma...@is.uec.ac.jpさん:
> ひょえー統合開発環境(笑)。(「ローダ語」って?)
なんというか、名前じゃなく数字だけの、つまりニモニックの代りに
命令コードを書くアセンブラ。ラベルも(「$」をつけるけど)数字だか
らFORTRANみたい(ただし変数も数字)。
$100: 012737; 100; $1;
なんて感じだったかな。2パスで番地計算するの(やっぱりマシン語直接
だと1命令ずらしたときの修正とかがつらいから)。もう細かいとこは忘
れてしまったなー。
> 私が書いたエディタはただのテキストエディタでした。ただ、実習す
> る学部生が皆使うものだったのでそれなりに気合いが入りましたが。
ほーらおんなじ :-)
> む? 自動セーブ時も文字コード変換しながら書くんですよねえ?
> (あれ、内部コードで書くのかな?)。
自動セーブは内部コードでしょ?
> '\n'だって1バイトなんですが...
長さ表現の方がmove命令が使えるとかさ… 久野
Junn Ohta
ku...@gssm.otsuka.tsukuba.ac.jpさんは書きました。
> おやそれは奇遇な。私なんかPDP-11のマシン語直接打ち込みでgap
> bufferのスクリーンエディタを書きました。ちなみに簡単なローダも書
> ...
> 保存したりそこから復元するというプログラムを木村先生が用意してた)。
うーん、部族の古老の昔話を焚火のまわりで聞いている
若者、という心地がいたしますです。私がおじいちゃん
になったら、やっぱりこういう話を孫たちに聞かせてや
りたい...。
# 同じ久野さんなのに某所とはだいぶ趣が違う。:-)
James君
NAKAGAWA wrote <7b22p0$hf7$1...@news.alles.or.jp>:
> > なんで、putchar(ch);ではいけないのでしょうか？
> > buf=ch;
> > って無駄な処理におもえるのですが、、、、
>
> キャストしても同じ処理が発生するから、"無駄" では
> ないと思うのですが... コンパイラの実装としてはこの
> 理解で正しいんでしょうかね。
chはint，bufはcharですよね。charを関数に引数として渡す場合，char->int
のキャストがされませんか，暗黙の？
putchar()を関数と仮定して，愚直に考えれば，buf=ch;putchar(buf);は
int->char->intのキャストも起こるはずですね，charを関数引数にするのですか
ら。
putchar()，これは実際にはマクロですから(普通はね)，関数呼び出しが起こ
る場合も，バッファ操作に終始するだけの場合もあるでしょうね。後者の場合
は，どちらにしても，int->charのキャストが起こるはずですね。前者の場合は
int->char->intのキャストですね。
ま，しかし，x86に関して言えば，int->charのキャストは，レジスタロード時
にBYTEで取る，レジスタセーブ時にBYTEで置く，ですね。char->intのキャスト
はレジスタロード時にビット拡張する，ですね。alfaとPPCも多分同じ，どうい
う命令セットがあったかを覚えていないので「多分」です。
; 9 : buf = ch;
000c8 8a 45 f8 mov al, BYTE PTR _ch$[ebp]
000cb 88 45 fc mov BYTE PTR _buf$[ebp], al
; 10 : ch = buf;
000ce 0f be 45 fc movsx eax, BYTE PTR _buf$[ebp]
000d2 89 45 f8 mov DWORD PTR _ch$[ebp], eax
という事で，暗黙のキャストはあろうが無かろうが速度やコード量的にはあま
り問題じゃない，という事ですね。
それより問題なのは，(不用意に？)charにintを代入するという事の方でしょ
う。lintやコンパイルでワーニングが発生しますね，８か24ビット分を吹っ飛ば
したという事で。
James君
ken-1
>
>となるわけです。ここで大文字のABCをカーソルの直前に挿入すると
>
> abcdABC efghijklmnopqrstuvwxyz
>
>となり、カーソルの右側を4文字削除すると
>
> abcdABC ijklmnopqrstuvwxyz
>
>となるわけです。つまりバッファ内容の先頭や末尾はバッファ領域の先
>頭や末尾にくっついていて、カーソルのある位置がギャップになってる
>わけです。文字カーソルの前後でのみ挿入/削除を行うというのは自然
>なモデルですから、それとの対応関係がとても自然。
間島ともうします。
こんな面白い方法があるとは、夢にも思いませんでした。
でも、たしかにこれでは画面表示の際にはギャップの部分の処理が必要な分
だけ手間がかかりそうですね。カーソルエディタには向いているのでしょうが。
で、どうしてこの方法が最近になって復活したのかも、よろしかったらお教
え願えないでしょうか。
/*********************************************************************
ｋｅｎ－１＠どうやったらこんなこと思いつけるんだろう。
*********************************************************************/
MAEDA Atusi
> $100: 012737; 100; $1;
あ、なんか読み書きできそう(笑)。 mov #100, @#xxx かあふむふむ、なんちゃっ
て。しかしブランチを8進で書くのはかなり嫌だぞ(笑)
> > む? 自動セーブ時も文字コード変換しながら書くんですよねえ?
> > (あれ、内部コードで書くのかな?)。
>
> 自動セーブは内部コードでしょ?
のようです(M-x do-auto-saveしてみました)。
> > '\n'だって1バイトなんですが...
>
> 長さ表現の方がmove命令が使えるとかさ… 久野
'\n'だとstring move命令が...(遅そう)。
前田敦司
ku...@gssm.otsuka.tsukuba.ac.jp
> あ、なんか読み書きできそう(笑)。 mov #100, @#xxx かあふむふむ、
> なんちゃって。しかしブランチを8進で書くのはかなり嫌だぞ(笑)
でしょ? だから
xxxx/$yyyy;
と書くとxxxxがブランチの命令コード、$yyyyは相対番地に変換して、
両者をはぎ合わせるようになってました。そのための「8進ローダ」
なんですよー。
ブランチの命令コード忘れちゃった 久野
ku...@gssm.otsuka.tsukuba.ac.jp
ke...@pp.iij4u.or.jpさん:
> でも、たしかにこれでは画面表示の際にはギャップの部分の処理が必要な分
> だけ手間がかかりそうですね。カーソルエディタには向いているのでしょうが。
表示するときはギャップは動かさないでもいいですよね。参照するだ
けならたいして面倒じゃないと思うのですが…
> で、どうしてこの方法が最近になって復活したのかも、よろしかったらお教
> え願えないでしょうか。
そう言われると困るな…CPUが速くなったから? 久野
P.S. 元ネタの太田さんが答えてくれるかも。
P.P.S. 別に最近復活ってわけじゃない、という話だったのかな。
ku...@gssm.otsuka.tsukuba.ac.jp
oh...@src.ricoh.co.jpさん:
> うーん、部族の古老の昔話を焚火のまわりで聞いている
古老はないでしょ ;_;
> # 同じ久野さんなのに某所とはだいぶ趣が違う。:-)
某所といってもいろいろ… 久野
MAEDA Atusi
> 昔のシリアル接続端末では、現在画面に表示されている内容と次に表
> 示されてほしいと思う内容との差分をできるだけ少ないバイト数で(端
> 末のスクロール機能等を駆使して)反映することが重要でした。
私がエディタを書いた時(gap bufferでテキストVRAMでした)に考えたのは、
(1) 「現在画面に表示されている内容」「次に表示されて欲しい内容」を読み
取る手間は(ハッシュ等で削減できるとはいえ)テキストVRAMに書く手間
とさして変わらないのでは。
(2) 『行スクロール』はエスケープシーケンスでは簡単だったりしますが、テ
キストVRAMではブロック転送になる。同じように、『行末まで消す』は
VRAMの右端までクリアしなきゃなんない。(つまり、あんまり最適化の余
地はない。)
(3) 画面イメージを別に覚えておくRAMがもったいない(48KBしかないから:-)。
(4) 最適書き換えはめんどくさい(おいおい:-)。
(5) 全部書き換えたってどうせ高々2000回だ(あーあ:-)。
と言う事で、
(a) 行末まで書き換え
(b) 現在のポイント位置から画面の終りまで書き換え
(c) 全画面を書きなおす
という3種類のルーチンを作って、編集ルーチン側が呼び分けるという事をし
ていました。
例えばポイントの右の1文字を削除したら、削除した文字が'\n'なら画面の終
りまで、そうでなければ行末まで書き換えます。いずれにせよ見る文字列は
gapより後だけです。
ポイントを移動して、画面からはみ出してしまったら、height/2 行前から画
面全体を描画します。(つまりジャンプスクロール)。特に遅いという文句は出
なかったと思います(あのマシン、クロックどのくらいだっけ?)。
> 現在のXなどの画面出力では全部再描画しても大したことはないのですが、
ビットマップフォントだと、テキストVRAMよりはかなりコストが高くなります
よね。ただ、どうせブロック転送は多発しますし、ビデオチップがやってくれ
るなら問題ないわけで(ほんとか?)最適化のコスト計算はシリアルラインの場
合と変わって来るんでしょうね。
> (1)カーソルの前と後の2回に分けて描画する。
> (2)ギャップを一時的に行頭に移動してからその行を描画する。
今プログラム見直したら、そんな賢い事はしてなくて、
if (ptr == beginningOfGap) ptr = endOfGap;
という感じのコードが最内ループの中に入ってました(やれやれ)。
前田敦司
ken-1
>> でも、たしかにこれでは画面表示の際にはギャップの部分の処理が必要な分
>> だけ手間がかかりそうですね。カーソルエディタには向いているのでしょうが。
> 表示するときはギャップは動かさないでもいいですよね。参照するだ
>けならたいして面倒じゃないと思うのですが…
間島ともうします。
よくわからないのですが、素人考えでは、単純に文字列とその長さを保持し
ているデータ形式ならば画面に収まる文字分の文字列を持ってきて VRAM に貼
り付ければよいだけなのに対して、gap buffer 方式だと、どこにギャップが
あるかを見つけて、ギャップの前にある文字列と後にある文字列を合成してか
ら貼り付けなければならないので面倒だろうな、と思ったわけです。
多バイト文字などのことを考えなければ、十数行程度（<-本当か？）で書け
る処理なのかもしれませんが、わたくしはこのことを「手間」と考えました。
見当違いのことを書いていたらすみません。
/*********************************************************************
ｋｅｎ－１＠元記事の方は結局どうなったのだろう。
*********************************************************************/
ku...@gssm.otsuka.tsukuba.ac.jp
ke...@pp.iij4u.or.jpさん:
> よくわからないのですが、素人考えでは、単純に文字列とその長さを
> 保持しているデータ形式ならば画面に収まる文字分の文字列を持って
> きて VRAM に貼り付ければよいだけなのに対して、
ははあ、なるほど。実は私はパソコンのテキストVRAMには暗いので
その判断はよくわかりません。
昔のシリアル接続端末では、現在画面に表示されている内容と次に表
示されてほしいと思う内容との差分をできるだけ少ないバイト数で(端
末のスクロール機能等を駆使して)反映することが重要でした。
現在のXなどの画面出力では全部再描画しても大したことはないので
すが、画面のフリッカなどを考えると必要ない部分は再描画しない方が
まだいいと思うのですが。そうなると「全部貼り付ければ」ではなくな
りますよね、どっちみち。
> gap buffer 方式だと、どこにギャップがあるかを見つけて、ギャッ
> プの前にある文字列と後にある文字列を合成してから貼り付けなけれ
> ばならないので面倒だろうな、と思ったわけです。
それが問題なのはカーソルのある行だけですよね。それに対しては
(1)カーソルの前と後の2回に分けて描画する。
(2)ギャップを一時的に行頭に移動してからその行を描画する。
という2つの方法があると思います。
> 多バイト文字などのことを考えなければ、十数行程度（<-本当か？）で書け
> る処理なのかもしれませんが、わたくしはこのことを「手間」と考えました。
テキストVRAMに詳しい方の解説を待ちます。 久野
Yasuki Arasaki
In article <pypaexz...@tp560e.sowa.is.uec.ac.jp>
MAEDA Atusi <ma...@is.uec.ac.jp> さんwrote:
>> (5) 全部書き換えたってどうせ高々2000回だ(あーあ:-)。
いつだったか、「MSX-DOSスーパーハンドブック」(MSXのXに注意)だったか
そういう本についてたテキストエディタ(のダンプリストを見ながら数キロ
バイト打ち込んでみて)でどうなってるか見てみたところ、1/60秒タイマ
割り込みを利用して、割り込みごとに、画面のどこを書き換えたかに無関係に
1/6ずつ、4行を再描画してました。その結果0.1秒ごとに画面全書き換えを
していたということです。1文字ごとに1バイトの出力が必要で、VRAMは
とびとびよりも連続にアクセスする方が速いハードウェアだったので、
一回当たりだと40文字x4行=160バイトだけ連続出力すればいいというのは
当時わりと感心しました。
編集用のバッファがどういう仕組みになっていたかまでは調べませんでした
が、編集用バッファ→表示用バッファ(VRAMの通常RAMにおけるコピー)は
随時非同期で更新、表示用バッファ→VRAMの更新が1/60秒タイマと同期して
いるということだったと思います。1/60秒タイマというのがモニタの
垂直帰線(っていうのか?)に同期してるのでこのタイミングにVRAMを更新
すればフリッカがない…。
もともとシングルタスクなOSで、キー入力を待ってる間は他にすることが
なかったので画面を何回再描画しようがパフォーマンスには影響しなかった
というのもありますが。
--
新崎@東大院総合
ara...@mns2.c.u-tokyo.ac.jp