From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: Re: Strange error caused by post-command-hook. Date: Thu, 12 Jul 2007 10:54:42 +0200 Message-ID: <4695EC52.8020704@gmx.at> References: <46937D1B.4000501@ubin.jp> <46938F1E.8000103@gmx.at> <4694A32D.3000907@ubin.jp> <4694C363.7070900@gmx.at> <4694C89C.5000402@ubin.jp> <4694CCB0.1040907@ubin.jp> <4695404B.8070706@gmx.at> <4695DFB8.5060202@ubin.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1184230433 8716 80.91.229.12 (12 Jul 2007 08:53:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 12 Jul 2007 08:53:53 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org To: ishikawa Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 12 10:53:51 2007 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1I8uQm-00073i-BJ for geb-bug-gnu-emacs@m.gmane.org; Thu, 12 Jul 2007 10:53:48 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I8uQl-0000JO-JB for geb-bug-gnu-emacs@m.gmane.org; Thu, 12 Jul 2007 04:53:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I8uQi-0000Gd-HT for bug-gnu-emacs@gnu.org; Thu, 12 Jul 2007 04:53:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I8uQg-0000Fg-Sn for bug-gnu-emacs@gnu.org; Thu, 12 Jul 2007 04:53:44 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I8uQg-0000Fc-Mk for bug-gnu-emacs@gnu.org; Thu, 12 Jul 2007 04:53:42 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1I8uQf-0002wf-4h for bug-gnu-emacs@gnu.org; Thu, 12 Jul 2007 04:53:41 -0400 Original-Received: (qmail invoked by alias); 12 Jul 2007 08:53:40 -0000 Original-Received: from N719P006.adsl.highway.telekom.at (EHLO [62.47.33.198]) [62.47.33.198] by mail.gmx.net (mp027) with SMTP; 12 Jul 2007 10:53:40 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18mFrBzA8Im7r30kodcnXwQOyn8+mQefo9ZyhxSVD +LCm3G6dSyPbHc User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en In-Reply-To: <4695DFB8.5060202@ubin.jp> X-Y-GMX-Trusted: 0 X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:16150 Archived-At: > 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)))) (minibuffer-with-setup-hook (lambda () (setq minibuffer-default find-file-default)) (read-file-name prompt nil default-directory mustmatch))) t)) 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.