[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8876: 24.0.50; making `menu-bar-update-buffers' use another frame
From: |
Drew Adams |
Subject: |
bug#8876: 24.0.50; making `menu-bar-update-buffers' use another frame |
Date: |
Wed, 15 Jun 2011 15:06:26 -0700 |
Starting with Emacs 23, you changed `menu-bar-update-buffers' so that it
no longer uses `menu-bar-select-buffer'. (That command is now used only
in msb.el.)
Instead of `menu-bar-select-buffer', `menu-bar-update-buffers' now uses
this:
`(lambda ()
(interactive)
(switch-to-buffer ,(cdr pair))
Before Emacs 23 it was trivial to make menu choice use a separate frame:
trivially redefine `menu-bar-select-buffer' (or advise it, I suppose).
Here, for instance, is a redefinition that covers all versions of Emacs:
(defun menu-bar-select-buffer ()
"Switch to `last-command-event' buffer in other frame."
(interactive)
(if (fboundp 'pop-to-buffer-other-frame) ; Emacs 24+
(pop-to-buffer-other-frame last-command-event)
(switch-to-buffer-other-frame last-command-event)))
But that is useless now, since `menu-bar-select-buffer' is no longer
called.
Dunno what the problem was with using `last-command-event', which caused
you to switch to the lambda code above. Wouldn't
`menu-bar-select-buffer' work just as well?
What to do now, to make menu selection use another frame? Copy and
modify trivially the long `menu-bar-update-buffers' definition, either
redefining it or (preferably) replacing it on `menu-bar-update-hook'?
Do you have another suggestion?
It was so simple and flexible before; it seems so complex and monolithic
now.
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
of 2011-06-13 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.5) --no-opt --cflags
-Ic:/build/include'
- bug#8876: 24.0.50; making `menu-bar-update-buffers' use another frame,
Drew Adams <=