[Mew-Win32 01270] Re: x-gzip64

Shun-ichi GOTO gotoh at example.com
1999年 3月 19日 (金) 14:10:50 JST


後藤@太陽計測です

>>>>> at Fri, 19 Mar 1999 13:37:11 +0900 (JST)
>>>>> ito <ito at example.com> said,

ito>  autoexec.batにc:/cygnus...を通したらv(^^になりました。
ito>  私の個人的な趣味ですが…基本的にDOSの方のpathに影響されるのがいやで、
ito>  Meadowで動かすものはexec-pathで設定していたのですが、この考え方が良く
ito>  ないのかもしれませんね(PerlはMewやIMのinstall時に怒られるので通す様に
ito>  してますが)

気持ちはよ〜〜くわかります。
#わたしも最初はそうしてました。
でもまぁ、Winはそんなものだ、と割り切ってしまった方がよいでしょう。(-_-)

この手のネタもFAQかな?


ito>  で、早速…っと言う事は…おっ、添付での"G"も出来る様になった^^;(当たり
ito>  前だって)
ito>  m(__)m	ありがとうございました。

おめでとうございます。


GOTO> あるいは(setq debug-on-error t) を行ない、件の操作をしてみてバッ
GOTO> クトレースを見ればおのずと想像できる内容が得られるかと思います。

ito>  既に今回の件に関しましては、お蔭様で解決したのですが…私は、こー言う
ito>  基本的(?)な部分を知らないため、自力で調査出来ていません。
ito>  よろしければ、このバックトレースの仕方を御教え頂けると助かります(すみ
ito>  ません、恥ずかしい素人質問で…)。


*scratch*バッファなどで (setq debug-on-error t)と入力し、C-jすれば準備
完了。あとは通常通りに使用して、elispでエラーが発生したときに自動的に
windowが割れてtraceバッファが出てくるはずです。そこにはエラーが発生し
たときの関数呼び出しのネストの履歴のようなものがあらわれます。呼び出し
の引き数なども見えることでしょう。そうすると、どういう操作でなにを行な
おうとして失敗したのかが想像できるだけの情報が得られる(ことが多い)わけ
です。

traceバッファが現われたときはエラーが発生した時点で一時停止して(再帰エ
ディット状態)います。通常のCのプログラミングしているときにデバッガでブ
レークポイントを設定するみたいなものと考えてください。なので、検証が済
んだらtraceバッファにて'q' とか打って脱出します。わけわかんなければ任
意のバッファでM-x top-levelでもいいでしょう。

件の変数を t にしたままだと、エラーやシグナルが発生するたびにtraceが出
てきてしまうのでうっとうしいですから、必要がなければ
(setq debug-on-error nil)と戻しておきましょう。

とはいえ、この操作はelispプログラマ向きなものでもあるので、最初は理解
しにくいかも知れませんし、混乱してしまうかもしれません。しかし、覚えて
おいて損はないです。elispプログラムを作成したり改造するときも役に立つ
ことでしょう。


--- Regards,
 Shun-ichi Goto  <gotoh at example.com>
   R&D Group, TAIYO Corp., Tokyo, JAPAN





Mew-win32 メーリングリストの案内