[Top][All Lists]

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

bug#10382: 24.0.92; gratuituous `file-supersession' error for `menu-bar-

From: Drew Adams
Subject: bug#10382: 24.0.92; gratuituous `file-supersession' error for `menu-bar-update-hook'
Date: Sun, 15 Jan 2012 16:03:48 -0800

> Error in menu-bar-update-hook (imenu-update-menubar): 
> (file-supersession File
> changed on disk c:/drews-lisp-20/bookmark+-1.el)
> [Note, that is all on one line - a very long error message!]
> I look in buffer `*Messages*' and see this:
> bookmark+-bmu.el changed on disk; really edit the buffer? (y, 
> n, r or C-h)  [2 times]
> Error in menu-bar-update-hook (imenu-update-menubar): 
> (file-supersession File
> changed on disk c:/drews-lisp-20/bookmark+-bmu.el)
> Apparently I should have seen the question about editing.  Emacs
> was apparently waiting for a response from me.  But I could see
> nothing at all, anywhere (all buffers blanked out).
> Seems like maybe there is a redisplay problem here?
> 9. Also, I did NOT try to edit the buffer (e.g. type a character).  I
> simply hit a key that dethumbifies the frame.  Of course, that changes
> frame parameters, but it does not in any way try to change 
> ("edit") the buffer.  So I don't see why I should get the question
> at all at that point.

More info.  This just happened to me again.  And this time I can confirm that it
had nothing to do with thumbified frames (something I mentioned last time, as a
supposition).  The buffer in question was in a normal frame, and all I did was
hit my usual `f5' key which is bound to this:

(defun revert-buffer-no-confirm () ; bound to `<f5>'
  "Revert buffer without confirmation."
  (interactive) (revert-buffer t t))

I believe that's what I did the last time also, though I might not have
mentioned that.

My impression now is that `f5' works seemlessly nearly all of the time, but
rarely this bug manifests itself.  I'm thinking that something in Emacs does not
appreciate (revert-buffer t t) sometimes?

I do have my own version of `imenu-update-menubar', but the only difference is
that it sorts each submenu before splitting the submenus, instead of sorting
among submenus after splitting.  And I don't see anything in that function that
Emacs should interpret as trying to modify the buffer.

But that seems to be what is happening: When I hit `f5' (rarely) Emacs thinks
there is an attempt to modify the buffer, so it asks for confirmation
(apparently, from what I find afterward in *Messages*, but I cannot see this
message display at the time).

Since no such message is visible, the effect is that Emacs seems to hang
(waiting for input to confirm) - i.e., it blanks out, until I hit C-g, at which
time I can finally see the message.

FWIW, that message itself, besides being way too long, is not terribly


reply via email to

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