Mercurial > hg > xemacs-beta
diff lisp/menubar.el @ 707:a307f9a2021d
[xemacs-hg @ 2001-12-20 05:49:28 by andyp]
sync with 21-4-6-windows
author | andyp |
---|---|
date | Thu, 20 Dec 2001 05:49:48 +0000 |
parents | 7039e6323819 |
children | 9caf26dd924f |
line wrap: on
line diff
--- a/lisp/menubar.el Wed Dec 19 00:40:26 2001 +0000 +++ b/lisp/menubar.el Thu Dec 20 05:49:48 2001 +0000 @@ -671,6 +671,10 @@ MENU-DESC and EVENT are as in the call to `popup-menu'." ;; partially stolen from w3 + + ;; This function is way gross and assumes to much about menu + ;; processing that is X specific. Under mswindows popup menus behave + ;; in reasonable ways that you can't obstruct. (let ((echo-keystrokes 0) new-event) (popup-menu menu-desc event) @@ -679,14 +683,22 @@ (setq new-event (next-command-event new-event)) (cond ((misc-user-event-p new-event) (throw 'popup-done new-event)) - ((not (popup-up-p)) + ((button-release-event-p new-event);; don't beep twice + nil) + ;; It shows how bogus this function is that the event + ;; arg could be missing and no-one noticed ... + ((event-matches-key-specifier-p new-event (quit-char)) + (signal 'quit nil)) + ;; mswindows has no pop-down processing (selection is + ;; atomic) so doing anything more makes no sense. Since + ;; popup-up-p is always false under mswindows, this + ;; function has been ordered to do essentially X-specifc + ;; processing after this check. + ((not (popup-up-p)) (setq unread-command-events (cons new-event unread-command-events)) (throw 'popup-done nil)) - ((button-release-event-p new-event);; don't beep twice - nil) - ((event-matches-key-specifier-p (quit-char)) - (signal 'quit nil)) + ;; mswindows never gets here (t (beep) (message "please make a choice from the menu.")))))))