不可解なバッファと、フレーム分 割。
Atsushi Shinmura
Linux RedHat7.0J based MLD-5 + XEmacs21.4.6 です。XEmacs 起動時に、奇
妙なバッファがついて来ます。勿論、そんなもの立ち上げていません。
*Compile-Log* と、*Compile-Log-Show* の２つです。*scrach* と違って、
何も記載はありません。
この、不可解なバッファの起動を抑制したいのですが、どうにも方法が分かり
ません。使用に支障は全くなく、バッファも消せますけど...
また、アイコンから GDB を立ち上げると、フレームが分割され、上は GDB シェ
ル、下は *scrach* です。これも、フレームを消せば良いだけですけど。メニュー
から GDB を起動すると、分割されません。
尚、XEmacs21.4.6 は、lesstif-0.92.6-2.i386.rpm (SRPM よりリビルド Vine
Seed より i18n 対応パッチ済み）で、--with-dialog=motif とし、Wnn6 仕様
でパッケージしています。(lesstif-devel-0.92.6-2.i386.rpm はコンパイル
時のみで、ランタイムライブラリだけ残してビルド後消しています。)
上記２点、不躾ながら、アドバイス頂けませんでしょうか。よろしくお願い致
します。
---
Atsushi Shinmura 新村篤史
Katsumi Yamaoka
>>>>> Atsushi Shinmura <GGB0...@nifty.ne.jp> wrote:
新村さん> Linux RedHat7.0J based MLD-5 + XEmacs21.4.6 です。XEmacs 起
新村さん> 動時に、奇妙なバッファがついて来ます。勿論、そんなもの立ち上
新村さん> げていません。
新村さんじゃないかもしれませんが、立ち上げています。:-p
新村さん> *Compile-Log* と、*Compile-Log-Show* の２つです。*scrach* と
新村さん> 違って、何も記載はありません。
中身が空なのはとっても幸せなことです。これらのバッファは elisp
のソースコードを byte-compile したときに、もしエラーや警告すべき
情報があったら報告するための場所として確保されています。
じゃあ誰が新村さんのコンピュータ資源を勝手に使って byte-compile
しているのか? それはもしかしたら新村さんご自身かもしれませんが、
普通は何かのプログラムが、オリジナルの関数機能を少し変えるために
advice ということを行なっているからです。これには byte-compile
が伴います。あるいは、文字通り byte-compile している場合もあるで
しょう。
新村さん> この、不可解なバッファの起動を抑制したいのですが、どうにも方
新村さん> 法が分かりません。
compiler にそれらのバッファを生成しないようにさせるためには、た
ぶん compiler を改造する必要があります。逆に advice が compile
を行なわないようにするには、新村さんの個人設定ファイルの先頭に
(setq ad-default-compilation-action 'never)
と書いておくと、運良く advice を行なうプログラムが compile する
ことを強制していなければ、それらのバッファは現れません。しかし、
たぶん不運なことに、compile が行なわれない結果、新村さんが使う何
かのプログラムの動作が遅くなってしまうでしょう。
すみませんが、もう一件ともう一通は別の方にお任せします。
新村さん> 使用に支障は全くなく、バッファも消せますけど...
あまり深刻ではない問題は、ある特定の個人にとっては障害かもしれま
せんが、それを作った人の常識では useful なのかもしれません。気に
しないというのが一つの解なのではないでしょうか? 基本的な動作と
は関係無いところで仕様変更または仕様を個人の好みによって切り替え
られるようにすることを要求するのは、する方もされる方もお互いに時
間の無駄です。その時間をもっと有益な、端的に言えば lisp プログラ
ミングを習得して自分で改造すること、に当てましょう。:-)
--
Katsumi Yamaoka <yam...@jpl.org>
Atsushi Shinmura
ご説明の趣旨、良くわかりました。ありがとうございます。ただ、この
場にそぐわないかもしれませんけど、あえてポリシーの問題も入ってき
ましたので、個人的な信条として申し述べます。
予め、断っておきますが、たまたま気にかかっていたことを記事にする
機会があっただけで、決して山岡さん個人への誹謗ではありません。そ
の点、くどいようですが念を押しておきます。
見ただけで不愉快、関わりたく無いと言うことでしたら、どうぞ皆様、
即座に削除して下さい。
Katsumi Yamaokaさんの<yosubsdq...@jpl.org>から
>新村さん> *Compile-Log* と、*Compile-Log-Show* の２つです。
---snip
>普通は何かのプログラムが、オリジナルの関数機能を少し変えるため
>advice ということを行なっているからです。これには byte-compie
>が伴います。
釈迦に説法で、はなはだ申し訳ないのですが、山岡さんのページでバッ
クトレースの取り方の説明を読んでいても考えさせられたのですけど、
オープンソースだからこそ、（誰が使うかわからない。ソフト製作とは
無縁の方も多いだろうし、そもそも、言語習得の時間があるのなら、や
らねばならないことが山積している、官民の諸氏も多いでしょう）、些
細なことでも、（基本機能ではないとしても）困惑することのないよう
に、デベロッパー的な情報収集機能は、取り外すことも可能であって欲
しいと思います。
gcc なんかが、デバッグ情報を埋めこめることと、ワーニングのレベ
ルも設定できることを考えると、elisp の advice は、バッファではな
く core のように外部のファイルに出しておくべきではと思います。
自分で直すなどと言うことは、規模が大きいものならば、とてつもなく
大変なスキルを要求するはずですから。
本旨とは違いますが、C++ で書かれた CJK-LyX という、TeX のフロン
トエンドでも、コンパイルが通らない。見ると、ローカライズに必須の
はずのメンバ関数が抜けている。g++ では、コンパイルさえ通らない、
string クラスを使っていて、独自のクラスに切り替えてやらねばなら
ない。只使いたい人間には、大変な時間と労力を強いる結果になりかね
ません。（なりました）
基本的に、開発するということは、ユーザーに負担を強いる、あるいは
使わないことを前提としているはずでは無いと思います。
無論、コンパイラに問題があることもあるでしょう。(gcc 2.96.X
は、カーネルのコンパイルが安定するのに、２年近くかかっていたと記
憶しています。）複合した、ハードルがいくつもあるので、ユーザーか
らの要望通りに、なるものでも無いとは、当然承知しています。
例の「伽藍とバザール」にも目を通してますが、気に入らないなら自分
で作れとは、書いていなかったと記憶しています。オープンソースのコ
ミュニティーであっても、開発に参加してから注文をつけろとは、逆に
閉鎖的ではないでしょうか。
オープンソースだから、無料だとは、絶対言えないはずです。機材が
揃っていたにしても、個人であろうと、どこかの研究者であろうと、通
信費を含め、お互いに、貴重な時間と労力をかけるわけですから。
開発者だけが、奉仕していると言うならば、実際に費用をかけて運用し
てみるユーザーは、利便を供与してもらうだけの信奉者というような位
置付けになるのでしょうか。それならば、不毛な関係だと思います。
商用の保証された高価な商品と別物であり、それ故各ディストリビュー
ションを含めて、格安で提供しているではないかと言う意見もあるで
しょう。以前、linuxconf について、GUI の設定ツールでも、同様の話
しになりました。私は、日本語化も含め、機能の充実を望みましたが、
他人様には、コマンドで処理できるものを、わざわざ使う必要もない
し、第一機能面で「危険」だと。こういったシステムツールの ＧＵＩ
化を否定するわけでは無いし、「作成してみたいぐらいだ」とのことで
したが、その方が言葉に見合うツールの作成をしたのを見たことがあり
ません。ローカライズも、機能の修正、新しい実装もです。
勿論、間違いのないように、これは、多大な貢献をされている、山岡さ
んに対しての話しではありません。誤解のありませんように。
提供されているものを、我慢して使うというのは、かえってオープン
ソースの趣旨に反するし、些細なこと（基本機能じゃないから、ギミッ
クをメンテする気は無いよ。各個、不具合だと思うのなら、自前で修正
しなさいなら）ならば、一般に、黙って使用を中止する方も沢山いらっ
しゃるのではないでしょうか。折角多大な労力を注いで作成されたもの
であっても、進化の相乗効果がなければ、いつかは、より配慮あるもの
に移行していくでしょう。これも、不毛な話しだと思います。
>(setq ad-default-compilation-action 'never)
>
>と書いておくと、運良く advice を行なうプログラムが compile する
>ことを強制していなければ、それらのバッファは現れません。しかし、
>たぶん不運なことに、compile が行なわれない結果、新村さんが使う何
>かのプログラムの動作が遅くなってしまうでしょう。
この件、ご教示のとおりということでしょうから、絶句しました。バイ
トコンパイルだからと言って、例え何かのベータ版を使うにしても、煩
わされるということですか。
個人的には、 UNIXであろうが、Windowsであろうが、Macであろうが、
コンパイル時には、gcc なら -Wall をつけて、ワーニングが全部消え
てから、 -O2 ぐらいで最適化します。その時に、デバッグオプション
もはずします。異論はあるでしょうけど、ワーニング＝エラー である
と、長らく言われ続けて来ましたから。周りから見て、機能に関係ない
ことに、無駄な労力と時間を使ってと笑われるかもしれませんけど。
でも、何か問題の発生するプログラムは、ほとんどコンパイル時に警告
の出ていたものばかりというのは、あながち偶然では無いでしょう。
C,C++, inline asm はともかく、 Pascal,Fortran,Cobol ... 等は型
チェックも厳しいですから、古い歴史を持つ言語ほど、バグなどの潜在
率は低いように思います。
>あまり深刻ではない問題は、ある特定の個人にとっては障害かもしれま
>せんが、それを作った人の常識では useful なのかもしれません。気に
>しないというのが一つの解なのではないでしょうか? 基本的な動作と
>は関係無いところで仕様変更または仕様を個人の好みによって切り替え
>られるようにすることを要求するのは、する方もされる方もお互いに時
>間の無駄です。その時間をもっと有益な、端的に言えば lisp プログラ
>ミングを習得して自分で改造すること、に当てましょう。:-)
lisp は、亀のように遅くても、ゆっくり、あせらず、慣れていこうと
は思います。私の概ねの主張、ポリシーは上記の通りです。
また、仕様変更を強要しているわけでもありません。山岡さんが、どの
ように取られたかは判りませんが。
更に、個人の好みなどと取られると、大変残念です。それ故、「抑制」
方法が無いかどうかお聞きしたわけです。XEmacs ほど大規模で複雑な
アプリケーションだと、本体の C ソースは勿論、elisp package もと
ても高度ですから、手出し、改造ができるには、個人の資質もあって、
出来なくても不思議ではないと思いますけど、いかがでしょう。自分が
出来るから他人も出来て当然だというのは、ある意味、傲慢さが表に出
ていることに他ならないと感じます。
それならば、オープンコミュニティーではなく、クローズドに実質近い
ものだと思います。正規のプログラマ経験者であって、lisp にも造詣
が深く、英語も堪能である。一体、そんな方は、PCを使うユーザーの中
に、どの程度いるものなのでしょう。
記事として、山岡さんへのリプライになってしまいましたが、今までの
お話しは、全て私の抱く疑義。これについて、「瑣末」な論争をするつ
もりも、そんな時間もありませんので、今回限り。
最後屁と取られるのなら、それで結構です。個人メールでも、応答は致
しません。
---
Atsushi Shinmura
mail-to:GGB0...@nifty.ne.jp
Katsumi Yamaoka
新村さんがお気を悪くするのも当然な書き方でした。また揶揄する気持
ちが働いたことは否定しません。ぼくはたまたま新村さんより elisp
の知識がありますが、それが新村さんよりも人間として優位にある理由
にはまったくなりません。その点に関して心よりお詫び申し上げます。
ただ、*Compile-Log* という文字列から、それが compile という事象
に関するものであること、XEmacs が byte-compile という作業をする
ための道具であることはご存知でしょうから、それが何に使われるもの
かも想像できるであろうと推測しました。今日では多くのプログラムが
その機能性能を維持するために、例えば XEmacs の組み込み関数に (他
に害を及ぼさない範囲で) 手を加えることは普通に行なわれており、そ
のとき byte-compile が行なわれます。それらは新村さんがご自身の意
志で M-x byte-compile したり個人設定ファイルに書かれた advice と
同列に扱われ、報告すべきエラーや警告があれば、そのとき目の届く範
囲にいる人間を対象にメッセージを発します。そういうものを新村さん
が一度もご覧になったことが無いとは到底考えられなかったので、邪魔
者扱いしないで欲しいという気持ちを持つと同時に、それをあえて発言
なさる態度に少し反感を持ちました。
>>>>> In <3c9167d5.2571%GGB0...@nifty.ne.jp>
>>>>> Atsushi Shinmura <GGB0...@nifty.ne.jp> wrote:
新村さん> 釈迦に説法で、はなはだ申し訳ないのですが、山岡さんのページで
新村さん> バックトレースの取り方の説明を読んでいても考えさせられたので
新村さん> すけど、オープンソースだからこそ、
新村さん> （誰が使うかわからない。ソフト製作とは無縁の方も多いだろうし、
新村さん> そもそも、言語習得の時間があるのなら、やらねばならないことが
新村さん> 山積している、官民の諸氏も多いでしょう）、
ご自分のことをおっしゃって下さい。ソフト製作とは無縁の方にきつい
言い方はしません。時間が無いならば、些細なことに労力をかけて記事
を投稿なさらないはずです。
新村さん> 些細なことでも、（基本機能ではないとしても）困惑することのな
新村さん> いように、デベロッパー的な情報収集機能は、取り外すことも可能
新村さん> であって欲しいと思います。
XEmacs はそれを使う人をデベロッパーだと思っているのでしょう。先
に書いたように、あれらのバッファの生成を抑制するには XEmacs 本体
の改造が必要です。それと、わざわざ手間をかけて backtrace を採取
するまでもなく問題が検出される場合が少なくありません。バグがまっ
たく無いプログラムを書く人とそれを使う人には不要なものですが、そ
んなことがありえないことはご理解いただけると思います。
新村さん> 自分で直すなどと言うことは、規模が大きいものならば、とてつも
新村さん> なく大変なスキルを要求するはずですから。
要はやる気の問題だけだと思うのですが。
新村さん> 基本的に、開発するということは、ユーザーに負担を強いる、ある
新村さん> いは使わないことを前提としているはずでは無いと思います。
負担を強いません。でもデバッグや改善のための情報提供を拒みません。
ただしぼくはあまり一般的でないわがままはご遠慮願いたいです。
[...]
新村さん> また、仕様変更を強要しているわけでもありません。山岡さんが、
新村さん> どのように取られたかは判りませんが。
新村さん> 更に、個人の好みなどと取られると、大変残念です。それ故、「抑
新村さん> 制」方法が無いかどうかお聞きしたわけです。XEmacs ほど大規模
新村さん> で複雑なアプリケーションだと、本体の C ソースは勿論、elisp
新村さん> package もとても高度ですから、手出し、改造ができるには、個人
新村さん> の資質もあって、出来なくても不思議ではないと思いますけど、い
新村さん> かがでしょう。
新村さんはご自分で何か調べられた後で記事を書かれましたか? おそ
らく目的物は grep などで簡単に見つかるはずで、記事の文章に
bytecomp あるいはそれに類する語が出てこないのは、ぼくの常識から
はおかしいのです。
新村さん> 自分が出来るから他人も出来て当然だというのは、ある意味、
新村さん> 傲慢さが表に出ていることに他ならないと感じます。
認めます。二度お詫びは書きませんが、では新村さんには非が無いので
しょうか?
新村さん> それならば、オープンコミュニティーではなく、クローズドに実質
新村さん> 近いものだと思います。正規のプログラマ経験者であって、lisp
新村さん> にも造詣が深く、英語も堪能である。一体、そんな方は、PCを使う
新村さん> ユーザーの中に、どの程度いるものなのでしょう。
ここは営利目的の企業などではありません。ぼくは人が努力して成長し
ていくのを高く評価しますが、新村さんの記事や態度にそれが感じられ
ません。ぼくの本職はプログラマではありません。学生とときは (必要
が無かったので) 英語は完璧に落ちこぼれていました。
新村さん> 記事として、山岡さんへのリプライになってしまいましたが、今ま
新村さん> でのお話しは、全て私の抱く疑義。これについて、「瑣末」な論争
新村さん> をするつもりも、そんな時間もありませんので、今回限り。
新村さん> 最後屁と取られるのなら、それで結構です。個人メールでも、応答
新村さん> は致しません。
ううむ、そういう言い方は無いと思うのですが。
--
Katsumi Yamaoka <yam...@jpl.org>
Kataoka Michiaki
> XEmacs 起動時に、奇
> 妙なバッファがついて来ます。勿論、そんなもの立ち上げていません。
> *Compile-Log* と、*Compile-Log-Show* の２つです。
...
> この、不可解なバッファの起動を抑制したいのですが、...
(kill-buffer "*Compile-Log*")
(kill-buffer "*Compile-Log-Show*")
ていうのを .emacs ファイルの末尾にでも書いておく
というのはだめですか。 （生成を抑制するのではなく、
あとから消すことを試みる。）
作られるタイミングや理由がわからないので、効果が
なかったり、おかしな副作用がでたりする可能性はあるかも
しれません。（お使いの環境でためしたわけではない。）
おわり。
Kataoka Michiaki
ったら、あっというまにできますよ。 (下記、my-kill-all-buffer を呼ぶ。）
（ちょっと気分転換にemacs で遊んで見たくなった。
結果は、保障しません。）
(defun my-kill-all-buffer-aux (a)
(cond ((eq a nil))
((equal (buffer-name (car a)) "*scratch*")
(my-kill-all-buffer-aux (cdr a)))
(t (kill-buffer (car a))
(my-kill-all-buffer-aux (cdr a)))))
(defun my-kill-all-buffer ()
(my-kill-all-buffer-aux (buffer-list))
(delete-other-windows))
カレントバッファ以外を消すように、仕様変更し、何かのキーに
バインドする方法は、宿題に残してあげます。（笑い。）
すでに、論じられているように、
バイトコンパイルのメッセージをだすのが
いやなら、あらかじめバイトコンパイルしておくか、
バイトコンパイル自体を抑止するのが、正攻法なのでしょうね。
（個人的には邪道ｊも結構好き。）
# さっき、Meadow をインストールして、何年ぶりかに、Emacs lispのを
# 使ってみた。結構楽しい。
おわり。
Atsushi Shinmura
Kataoka Michiakiさんの
<a75jgf$rnn$1...@news01bi.so-net.ne.jp>
から
>*scratch* バッファ以外をすべて消すプログラムぐらいだ
>ったら、あっというまにできますよ。 (下記、my-kill-all-buffer を呼ぶ。）
>（ちょっと気分転換にemacs で遊んで見たくなった。
これ頂きます。他にも転用できそうですね。発想の転換が凄いですね。
なるほど、解は一つではないということですね。
> カレントバッファ以外を消すように、仕様変更し、何かのキーに
>バインドする方法は、宿題に残してあげます。（笑い。）
キーバインドは、やめておきます。あくまで、初期処理ということでな
ければ、困る事情もありますので。
>バイトコンパイル自体を抑止するのが、正攻法なのでしょうね。
>（個人的には邪道ｊも結構好き。）
^^; それは、やはり特殊な用途でしょう。何らか自分で手を打たねば
ならないかと思います。
># さっき、Meadow をインストールして、何年ぶりかに、Emacs lispのを
># 使ってみた。結構楽しい。
使いこなせれば、とっても面白いでしょうね。遠い昔の、Mac のハイ
パーカードを思い出しました。あれも楽しかったですけど。
どうも有難うございました。