bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Strange error caused by post-command-hook.


From: ishikawa
Subject: Strange error caused by post-command-hook.
Date: Tue, 10 Jul 2007 21:35:39 +0900
User-agent: Thunderbird 1.5.0.12 (X11/20070509)

Strange error caused by post-command-hook.

I have a problem caused by apparently an incorrect hook installed
in post-command-hook and am at a loss about how to track it down.
Any helpful tips are appreciated.

(I have not seen this in pre-22.1 emacs version all the way back
to 18.5x).

Version:
emacs-version is a variable defined in 
`/u2/ishikawa/emacs-22.1/lisp/version.el'.
Its value is "22.1.1"

OS:
Linux dell-w2k-note 2.6.20-1.2320.fc5 #1 Tue Jun 12 18:50:38 EDT 2007 i686 i686
i386 GNU/Linux
(Fedora Core 5)


Symptom:

For some reason which I have not figured out completely (but I suspect
trying to run M-x man for non-existing command utility such as M-x man
foobar tends to cause the following symptom very likely, but not
always :-( ), once the following message begins to appear in the
minibuffer whenever a minibuffer interaction is attemped,

  Error in post-command-hook: (error Selecting deleted buffer)

this message seems to re-appear (almost) always in the mini-buffer.

This message obscures the prompt message which should have been shown
in the first place.  For example, if I type C-c C-f, the default
directory usually shown is obscured with overlapping message (above).
(Funny if I type C-c C-v, the error message doesn't show up.)

A good news about this bad news is once I insert a key into the minibuffer,
the message disappears and the intended prompt message, which has been
obsucred, as well as the key I type is now shown in its complete form.

So it is not a fatal bug, but very irritating and as far as user
interface is concerned, emacs is very difficult to use after this
happens. The first time I notice this problem, I had to exit emacs and
start again.

Now, from reading the "C-H v" help message for 'post-command-hook', if
an error occurs when the hook is run from post-command-hook,
the hook is set to nil.  But if this is set to "nil" permanently, I
should not see this repetition of the same error message over and over
again. (Correct?)

Does this mean that whatever is causing the incorrect hook to be installed
is trying to install this invalid hook again and again?

========================================
>From C-H help message:
----------------------
post-command-hook is a variable defined in `C source code'.
Its value is nil


Documentation:
Normal hook run after each command is executed.
If an unhandled error happens in running this hook,
the hook value is set to nil, since otherwise the error
might happen repeatedly and make Emacs nonfunctional.

[back]
========================================

Now I have an additional observation, which seems to suggest
that something (but I don't know which library) is trying
to install this invalid hook again and again.

Very strange observation:

I just noticed that a very strange sequence of events.  Now I am using
an emacs session when the described error message appears.

When I hit "C-c C-f" the first time, I get the error message as
described above.  But if I hit "C-g" to stop the interaction, and hit
"C-c c-f" again, the second "C-c C-f" is followed by the correct
prompt, i.e., the default directory (for "find-file" that is.). The
error message is not shown.  However, if I hit "c-g" to stop this
correct interaction, and hit "C-c c-f" again, I get the error message
described above. And the process repeats forever.

========================================
>From *Messages* buffer
----------------------------------------
     ...
Error in post-command-hook: (error Selecting deleted buffer)
Mark set [2 times]
(New file)
Error in post-command-hook: (error Selecting deleted buffer)
Mark set
<<< Press Return to bury the buffer list >>>
    ...
========================================


I am using "electric-buffer-list" and it seems that the combination
of electric-buffer-list and man against non-existing command name
seems to trigger the bug/feature, but not always.

Any helpful tips to track down this problem are appreciated.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]