[Top][All Lists]

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

Re: Strange error caused by post-command-hook.

From: martin rudalics
Subject: Re: Strange error caused by post-command-hook.
Date: Thu, 12 Jul 2007 10:54:42 +0200
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

> I am now trying to figure out where minibuffer-setup-hook is set.
> Things get quite interesting. It seems that there are certainly more
> references to minibuffer-setup-hook than to post-command-hook, etc..
> I need to refresh my knowledge of edebug now.

Just to elaborate on this: One of the packages you call adds a
buffer-local post-command-hook when setting up the minibuffer like:

(add-hook 'post-command-hook 'foo ... t)

This means you cannot see "foo" when you investigate `post-command-hook'
_before_ executing a command because it's set up by the command itself.
If the function chokes because it wants to select a deleted buffer it's
automatically removed from `post-command-hook'.  Hence, you can't see it
_after_ executing the command when Emacs is still prompting you for a
file-name.  All you see is the error message which still obscures the
prompt.  Now consider:

(defun find-file-read-args (prompt mustmatch)
  (list (let ((find-file-default
               (and buffer-file-name
                    (abbreviate-file-name buffer-file-name))))
              (lambda () (setq minibuffer-default find-file-default))
            (read-file-name prompt nil default-directory mustmatch)))

First `read-file-name' puts the prompt in the minibuffer.  Then foo
triggers the bug and the prompt is overwritten because minibuffer and
echo area share the same screen area.  According to the Emacs manual the
error message should go away after a "few seconds".  I don't know
whether it does so with a `post-command-hook' error.

Anyway you have to find the function that wants to resurrect the deleted
buffer in the first place.

reply via email to

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