hns - 日記自動生成システム - Version 2.19.9

先月 2003年05月 来月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Namazu for hns による簡易全文検索
詳しくは 詳細指定/ヘルプを参照して下さい
検索式:

2003年05月24日() 旧暦 [n年日記]

#1 [Emacs] selecting deleted buffer

wl-2.10.0 で、例えば、namazu で検索して次のような時に、上から見ていって 8 のところで出た。
    1 N02/02(日)04:36 [ burt             ] ipnat.conf for darwin streaming serv
    2 N12/08(日)10:17 [ Masahiro Yamagis ] #08272 Re: question ipf             
   10  08/09(金)17:20 [ MOCHIDA Shuji    ] #07938 mssclamp on PPPoE network
    6  08/10(土)00:01 ┣[ FUKAUMI Naoki    ]                               
    4  08/11(日)23:54 ┃┣[ MOCHIDA Shuji    ]                             
    5  08/10(土)07:45 ┃┗[ 藤原 誠 / Makoto ]                             
    3  08/12(月)00:02 ┃ ┗[ MOCHIDA Shuji    ]                           
    8 N08/09(金)18:15 ┣[ Masaru OKI       ]                               
    7 N08/09(金)18:48 ┃┗[ MOCHIDA Shuji    ]               
    ....
これは、この状態で何度でも言うので、 (setq debug-on-error t) してからもう一度 8 を見ると、次のような字がある。
byte-code("......" [err wl-message-buffer-cache-delete signal] 3)
wl-message-buffer-display([elmo-nmz-folder [0 0 0 0 0 0 0] nmz "[mssclamp]" "[" "/home/makoto/.elmo/nmz/[mssclamp]"

wl-message.el:

158 (defun wl-message-buffer-cache-delete (&optional key)
159   "Delete the most recent cache entry"
160   (if key
161       (setq wl-message-buffer-cache
162             (delq (assoc key wl-message-buffer-cache)
163                   wl-message-buffer-cache))
164     (let ((buf (wl-message-buffer-cache-buffer-get
165                 (car wl-message-buffer-cache))))
166       (setq wl-message-buffer-cache
167             (nconc (cdr wl-message-buffer-cache)
168                    (list (wl-message-buffer-cache-entry-make nil buf)))))))
これは原因でなくて結果かなぁ。

wl-message-buffer-cache-size:

10

wl-message-buffer-cache:

((("[mssclamp]" 3 "<20020812.000222.125128237.mochid at netside.co.jp>") . #<buffer  *WL:Message*<5>>) 
 (("[mssclamp]" 5 "<yfmvg6jwt1u.wl at u.ki.nu>") . #<buffer  *WL:Message*<4>>) 
 (("[mssclamp]" 4 "<20020811.235400.65654786.mochid at netside.co.jp>") . #<buffer  *WL:Message*<3>>) 
 (("[mssclamp]" 6 "<874re4oz3n.wl at dns1.fukaumi.org>") . #<buffer  *WL:Message*<2>>) 
 (("[mssclamp]" 10 "<20020809.172010.65657653.mochid at netside.co.jp>") . #<buffer  *WL:Message*>) 
 (("[mssclamp]" 2 "<20021208100442.9858.NIGHT at pluto.dti.ne.jp>") . #<buffer  *WL:Message*<9>>) 
 (("[mssclamp]" 1 "<6F7FA4D8-361C-11D7-8F55-0030654D9470 at wanadoo.fr>") . #<buffer  *WL:Message*<8>>) 
 (("+ml/netbsd" 6560 "<20030518.182817.68562309.toshi at odd.minolta.co.jp>") . #<buffer  *WL:Message*<7>>) 
 (("+ml/netbsd" 6567 "<20030523.234324.87582895.taca at back-street.net>") . #<buffer  *WL:Message*<6>>) 
(nil . #<killed buffer>))
8 はまだ見ていないのに、あるはずと(いう人がいるので)見に行くと、「それはもう消したやつだよ」と言われている のかな。

そうではなくて、「buffer-cache が一杯になったので、 古いやつを消そうとした時に、以前に消したやつをまた消そうとしている」 かな

上のは単に結果のようだ。:

465 ;; Use message buffer cache.
466 (defun wl-message-buffer-display (folder number flag
....
489     (if (or force-reload read)
490         (condition-case err
...
501           (error
502            (wl-message-buffer-cache-delete)
503            (signal (car err) (cdr err))
504            nil))) ;; will not be used
505     (cons hit cache-used)))
そもそも 501 行目に来てしまうことが良くないらしい。

condition-case って何 ? appropos によれば:

Function: Regain control when an error is signaled.
Plist: lisp-indent-function byte-compile

wl-message.el:

 486       ;; delete tail and add new to the top.
 487       (setq hit (wl-message-buffer-cache-add (list fname number msg-id)))
 488       (setq read t))
ここで err になっている気がする。次のような message 行を付けておくと
486 ;; delete tail and add new to the top.
487 (message "hit false, cache adding fname(%s) number(%s) msg-id(%s)" fname number msg-id) ;; XXXX
488 (setq hit (wl-message-buffer-cache-add (list fname number msg-id)))
489 (message "hit(%s)" hit)
490 (setq read t))
hit false, cache adding fname([mssclamp]) number(8) msg-id(<20020809180839.26CA.OKI at netbsd.org>)
hit(#<killed buffer>)
と言っている。ここまで書けばよういちさんが何とかしてくれないかな。

(setq wl-message-buffer-cache nil):

すれば、Emacs を立上げ直さなくても大丈夫。

お手紙:

「Message-buffer を kill してしまったのに、それがあると思っているのがいけない」 ですよと御指名の方からお手紙をもらってしまいました。ありがたいことです。
  1. 自分で kill-buffer (C-x k) してしまった。(僕のことね)
  2. wl が何かの原因で kill-buffer してしまったのに、まだあると思って参照する
のどちらか。という切分けが必要とのこと。しかし上で書いた 8 のメールは とても古いやつで、きょうはまだ見ていないもの。 (検索で出て来た一覧だから、それは間違いない)。つまり二番目に当るはず。

「実は HTML を見るのに w3 を使っている」:

ことが重要かも知れないので、そうしています。とお知らせしておきます。

wl-message-buffer-cache:

の内容を見ると、確かにこの順に見た覚えがあるが、それの一つ前に見たメール を、自分で kill-buffer してしまったのかも知れない。 それは 上の 8 のものとは関係ない訳で、二つ上に書いた、 「とても古いやつで、きょうはまだ見ていないもの」というのは的外れだった。

つまり

「自分で kill-buffer (C-x k) してしまった。(僕のことね)」:

というのがありそうな話だ。 が、「(僕が)メールを見て、それを kill-buffer する」ことってあるかな、 と思ったりもする。記憶自信無。

(と書いたら)

「とりあえず trunk では対処しておきました。」という有難いお告げ:

試そうと思って、まずは wl-2.10.0 のままで:

再現法は簡単で、message buffer で C-x k して、あとは buffer cache がぐるぐる回ってバッファが存在しないとこに 足そうとするまで新しいメッセージを見るだけです。
しようとしたが、うまく行かない。(再現しない)。しかも 「message-buffer で C-x k 」するのって、ちょっと面倒で、 これはやっていないなぁ、という気が....

そうか、途中で cache の中を見ればいいのか。

どうも、単に kill しただけでは、上の方に書いた

 (nil . #<killed buffer>))
のように nill という字は入らない気がする。 (で、その時には再現しない ?)



最近の日記
2024年05月08日
comparison on ./buildsh tools
2024年05月06日
py-setuptools (python 3.11.9)
make release took 1 hours and 10 min
qemu invocation for 10.99.10
2024年05月05日
Windows 10 version
serial connection
bc bench
2024年05月04日
Trial on 10.99.10
another version (later trial) to succeed
2024年04月29日
dkim
以上、1 日分です。
タイトル一覧
カテゴリ分類
Powered by hns-2.19.9, HyperNikkiSystem Project

Count.cgi (since 2000/02/05)