bug#24472: - a workaround/fix for the menubar crashes on macOS

[Marc Herbert]

> This delay and sometimes missing menus happen only when the current
> buffer of the current frame is a tramp buffer. Switch the top frame to
> a local file and everything is fine again. So I fired up Wireshark and
> as expected I saw some ssh traffic when opening the 26.1 menus with a
> tramp buffer.
>
> Now this is where I find things get really interesting:
>
> On my system,
>  - with 26.1, the "Apple" and "Emacs" menus don't cause any network
> traffic or lag. All other menus do.
>  - with 26.2 and above, the "Apple" and "Emacs" menus don't cause any
> crash.     All other menus do.
>
> Coincidence? Mmmm....

Not.

I leveraged the milder symptoms in 26.1 to debug the issue and found a
workaround/fix. I then upgraded to 26.3 and ta-da: the crashes are
gone!

The root cause is in menu-bar.el which defines the revert-buffer item like this:

      '(menu-item "Revert Buffer" revert-buffer
                  :enable (or (blah) (blah)
                              (and buffer-file-number
                                   (or (buffer-modified-p)
                                       (not (verify-visited-file-modtime
                                             (current-buffer))))))

This greys out the "Revert Buffer" menu item when (among others) no
one modified the file outside Emacs.

verify-visited-file-modtime calls
tramp-sh-handle-verify-visited-file-modtime that temporarily hardcodes
remote-file-name-inhibit-cache to 't that causes the network accesses
that cause the delays and/or crashes.

After a few other attempts, my final workaround is dead simple: remove
the "Revert Buffer" item from the menu by adding this one line to your
.emacs file:

     (define-key global-map [menu-bar file revert-buffer] nil)

Enjoy. I think it's better than a "workaround" actually, it's almost a
"feature" that I'm going to keep that in my .emacs file permanently
because trying to use the network every time you click the menubar is
just... silly?

I also tried to hack menu-bar.el directly but any change I made to it
was completely ignored. Anyone knows why?

> [Bonus question: Apple cares about latency. Does macOS allow
> networking while merely trying to open a menu?]

Somewhat related: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32864
26.1; "menus don't work correctly in Mac OS Mojave"

> Elisp code doesn’t guarantee it will return, it can longjmp when you
> hit C-g, for example. This means you can end up with the application
> attempting to run the event loop while it is still INSIDE the previous
> event loop, and the toolkit really doesn’t like that. It will, in
> fact, kill Emacs on the spot.

Must also be why the debugger can't be used for this issue. This
didn't make my first Emacs bug any easier :-)