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

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

[Drew Adams]

1. I visit a file.  I thumbify its (one-window) frame, which means that
I shrink the frame and remove its menu bar.  (Menu-bar mode is on,
globally.)
 
2. I change the file contents on disk (e.g. with another Emacs session).
 
3. I dethumbify the frame visiting the file, which means that I restore
its original size and add back the menu bar. I do this by hitting a key.
 
4. The screen goes blank: all frames are blank.  I see the hourglass
prompt (IIRC), but nothing else indicates that Emacs is doing anything.
 
5. I hit C-g.  I hit C-g again (the first does nothing, apparently).
 
6. The content of all frames reappears, and I see now this message in
the echo area (could not see anything there before, because all
frames were blank):
 
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!]
 
7. 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)
 
8. 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.
 
In GNU Emacs 24.0.92.1 (i386-mingw-nt5.1.2600) of 2011-12-06 on MARVIN
 Windowing system distributor `Microsoft Corp.', version 5.1.2600
 configured using `configure --with-gcc (4.6) --no-opt --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-2.10.1/include --ldflags
 -LD:/devel/emacs/libs/gnutls-2.10.1/lib'
 

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

[Drew Adams]

Not sure it's pertinent, but the file on disk is writable and I might have
toggled the buffer visiting it to read-only.  (I modified the file outside that
Emacs session, in any case.)

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

[Drew Adams]

> 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
comprehensible.

HTH.

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

[Stefan Monnier]

>> 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)

I think we'll need a backtrace at the time of the "really edit
the buffer?" prompt in order to debug this.  Tho, I suspect it won't be
easy to get one since this is in the middle of menu-bar-update-hook, so
redisplay might be inhibited.


        Stefan

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

[Drew Adams]

> I think we'll need a backtrace at the time of the "really edit
> the buffer?" prompt in order to debug this.  Tho, I suspect 
> it won't be easy to get one since this is in the middle of 
> menu-bar-update-hook, so redisplay might be inhibited.

Right.  I don't know how to obtain that.  And as I said, this does not seem to
happen all the time.

Perhaps it would be more helpful to take a look at recent changes to the code.
Perhaps the code which issues this "file supersession" prompt (I've never seen
that before) or the revert code.  Dunno.

Or perhaps the display code?  One question is why I do not see the message, and
Emacs seems to hang, until I hit C-g.  It is only after canceling out of the
(presumed) revert-confirmation dialog that I can see the prompt for that
confirmation.

And why I would be prompted at all when I use this no-confirmation command is
another question.  (revert-buffer t t) should not be asking for confirmation.

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

[Stefan Monnier]

>> I think we'll need a backtrace at the time of the "really edit
>> the buffer?" prompt in order to debug this.  Tho, I suspect 
>> it won't be easy to get one since this is in the middle of 
>> menu-bar-update-hook, so redisplay might be inhibited.
> Right.  I don't know how to obtain that.

Under POSIX, you could "kill -USR2 <emacspid>".
But maybe instead of C-g you could do (blindly) M-x debug RET.  Not if
that would work, but it's worth a try.

> Perhaps it would be more helpful to take a look at recent changes to
> the code.  Perhaps the code which issues this "file supersession"
> prompt (I've never seen that before) or the revert code.  Dunno.

Too many possible sources, and none of the "recent" changes jumps to mind.

> And why I would be prompted at all when I use this no-confirmation command is
> another question.  (revert-buffer t t) should not be asking for confirmation.

The prompt is not from revert-buffer but from some low-level code
triggered by imenu code itself triggered by the menu-bar-update-hook.
revert-buffer is only involved indirectly (it probably happens to put
the buffer temporarily in a slightly different state that in turn
triggers the problem).


        Stefan

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

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

>> I think we'll need a backtrace at the time of the "really edit
>> the buffer?" prompt in order to debug this.  Tho, I suspect 
>> it won't be easy to get one since this is in the middle of 
>> menu-bar-update-hook, so redisplay might be inhibited.
>
> Right.  I don't know how to obtain that.  And as I said, this does not seem to
> happen all the time.

`debug-on-message' might help here.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>>> I think we'll need a backtrace at the time of the "really edit
>>> the buffer?" prompt in order to debug this.  Tho, I suspect 
>>> it won't be easy to get one since this is in the middle of 
>>> menu-bar-update-hook, so redisplay might be inhibited.
>>
>> Right.  I don't know how to obtain that.  And as I said, this does not seem to
>> happen all the time.
>
> `debug-on-message' might help here.

More information was requested, but no response was given within a few
months, so I'm closing this bug report.  If the problem still exists,
please reopen this bug report.
-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no