#multipost test @chaton_chaton
#前にどっかで言ったことあったけど、Lispの前置構文が読みにくいっていうのは、日本語話者が英語を学び始めた時に語順が違うから読みにくいって言っているようなものではなかろうか。そりゃ後ろから読んでたら読みにくいわな。でも慣れたら前から読めるんよ。
#func(x, y, z) と書くか (func x y z) と書くかの違いだから、開き括弧の位置しか違わないと思うんですけどねぇ。
#ああそうか、演算子の中置記法の存在を忘れてました。
#あと、メソッド呼び出しの順序とか。
#誰にも看取られずに死んで行くことを言い表す英単語ってあったっけ。
#予期せぬexceptionで死んだスレッドが、joinもされずにgcされちゃう際に警告を出そうと思うんだけど、うまい言い方はないかなと思って。
#なんかあったような気がするんだけどなあ…
#lonely deathくらいか。"the thread died a lonely death with exception ..." みたいな感じ。
#kodoku-shi という言葉を広めましょう(ぉぃ
#あんまり考えすぎても寂しいのでlonely deathで決め。
#とりあえず、死ぬ可能性があるスレッドはjoinしましょう、joinしないならスレッド内部できっちりguardしましょう、という気にはさせられる。
#加藤和彦自殺って...
#絶句
#ちょっと質問なんですが、match のパターンで「文字」って使えないんでしょうか?
#gosh> (macroexpand '(match a ((\#cr \#lf rest ...) 'a)))
(if (and (pair? a) (pair? (cdr a)) (list? (cddr a))) ((lambda (|\\#cr| |\\#lf| rest) 'a) (car a) (cadr a) (cddr a)) (#<identifier util.match#match:error> a))
#ドキュメントだと使えそうなんですが、実際に試すとうまくいかない。
#すみません、文字の指定の仕方、間違えました。
#ちゃんと動きました。
#なんでエディタ上で見ていて気がつかなかったんだろう?
#いろんな言語使ってるとわかんなくなることはあるよね。Gaucheで0x20とか書いてunbound variableになったり。こういうのはlexerのチェックが厳しい処理系の方が早めに発見できるのでいいのかな?
#こういったことって処理系よりも、エディタに任すのでもいいかな。色とかフォントとかで示してくれれば、書いている最中に気がつくので。
#koguroさん何使ってます? 私は最近はquackなのですが、リテラルは色がついてくれるのでわりとわかりよいですよ。
#ただ、inferior Scheme windowの方で、Gaucheのエラーメッセージの表示が文字列の閉じクオートを省略してると、それ以降がみんな文字列内扱いになっちゃうのがちと問題ですが。
#Emacs付属のscheme-modeをそのまま使っています。
#自作のelispをいろいろ作ってしまっているので、乗り換えるの面倒かなとおもってquackは使ってないです。
#Emacsっていったん環境作り上げてしまうと、局所最適解に落ち着いてしまうので、いろいろ試すの面倒になってしまう。
#あるある。乗り換えコストが高いですな。
#生態系と同じで、環境が激変すると新しいの試してみようか、となるんですが。それでもメインの環境を FreeBSD から Mac に移行したときに .emacs とか大幅に書き直しているんですが、昔作った関数が結構生き残っていて、
#なんか秘伝のタレ状態になっている。
#anythingも使い始めたのは結構最近だし。
#自分の.emacsもそうだなあ。XEmacsからEmacsに乗り換え直した時に結構整理したんだけれども。あ、anythingは手を出してない。どうですか?
#私はバッファ切り替えメインで使っていますが、まあ便利かな、という感じです。
#私はanythingに何もかも入れてしまう(describe-*とか)とかえって混乱してしまったので、バッファ切り替え+recent filesの読み込みに特化させてしまっています。
#自分は emacs のdebugをしている期間が長かったので、あんまりカスタマイズしてないですね。emacs -q で使うことも多かったので、あまり乖離していると却ってつらい。
#あと、色付きのソースコードは嫌いなので、global-font-lock-modeとか切ってます。
#「色付きのソースコードは嫌い」そう思っていた時が自分にもありました。スポイルされちゃったかなあ。
#個人的には、Lispのコードは色とかフォントが適度についていた方が読みやすいかなと思います。
#S式で統一されてしまっているので、悪くいえば特徴が薄く「のぺっ」とした感じに見えてしまうので。ただけばけばしいのも目がつらいので、適度さって難しいんですが。
#ktermでデフォルトの色だとすごく見づらいのがあるというのもあるかな。それを見やすくするより黒一色にするほうを選んでしまう。
#確かに色の指定って、色調を統一するとか考え始めるとはまってしまうことがある。
#emacs を今でも--with-x=no で buile するのも古いのかもしれない。
#あと、Macに移行したときにEmacsをなるべくプレーンな環境で使おうと決心したけど、いつの間にか元の木阿弥になっていた。
#色付きのソースコードが嫌な理由の一つに、書きかけのコードに色を付けようとされると鬱陶しいというのもあるかな。確か昔gosling emacsにはelectric c-mode と elec c-mode ? のおせっかいさの違う c-mode があったのだけど、おせっかいな方は全く使う気が起こらなかった。forと入力したとたんに(;;){}を勝手にinsertする類いの。
#@chaton_cljp Shibuya.lispTT#4 21:00より参加申し込み開始です! 詳しくはこちらで http://shibuya.lisp-users.org #ぼくも以前は学生のときから育てていた .emacs と .tcshrc があったんですが、最近は .emacs は新しい環境ができるたびにスクラッチから書くことにしてます。訓練みたいな感じ。まぁ、キーバインドの変更が数行と、lua-mode とか actionscript-mode とか、用途によってちょこちょこ変えるだけですけど。色は font-lock-mode のデフォルトの色ですねぇ。まえは -rw をつけて起動してたけど、最近はそれもやってないですねぇ。
#私もそれほど大きなカスタマイズはしてないんだけど、ちょこまかしたのがいろいろ積もってるなあ。持ち歩かないと不便なのはmewの設定くらいかな。popやsmtpをover sshで使ったりしてるから。
#ああ、mew とかもバイトコンパイルしないで使ってます。
#しかし今度のShibuya.lispは面子がえらく豪華だなあ。近山先生のがすごくおもしろそうだ。
#mew で Gmail の IMAP につないでる設定は空では書けないですねぇ。
#Shibuya.lisp いちどはいってみたいなぁ。
#最近のemacsのdefault 動作の変更で一番面食らったのはc-beginning-of-defunkaな。
#c-m-a c-m-f というコンビネーションが身に付いてるので。
#え、変わったの?
#以前の c-mode で c-m-a すると
#{ のところにカーソル我きていましたが、最近のだと戻り値の型定義の頭にくるとおもいます。
#変わったというか、昔は cc-mode でも c-m-a は beginning-of-defun だったのが、 cc-mode 用のが作られたのかな。
#あ、ほんとだ。なんか微妙に違和感があったと思ったらそのせいかあ。
#自分は、いざとなったら素の vi を使うつもりなので、 vi っぽくするためのカスタマイズ以外の、 anything とかの便利ライブラリは使ってないですね。ただ、最近はずっと Emacs なので Inferior Scheme と font-lock のない環境に本当に戻れるのかは謎ですが
#素のvi (vimとかでなく) が入ってる環境って今あるのかなあ。
#リモートで作業する時は私もviが多いですね。Schemeコードの編集効率は異様に落ちるので(lispモードを使いこなしてない)、それはtrampを使ったりローカルで編集してミラーしたりしてますが。ちょっとしたシェルスクリプトやらCコードやらはviでもいける。
##昔 Solaris を使ったときは素の vi だった気がします。 BSD 系は nvi ですね。 MacOSX は昔は nvi だったみたいですけど、今は vim だという
Gauche > Archives > 2009/10/17