On Fri, 28 Apr 2000 at 10:33:10 +1000, "Peter B. West" <pbwest(a)netscape.net&gt; wrote: > I understand your situation. The problem is not urgent for me, as the > menus will still usefully inform me of the valid options, and problems > that you cannot reproduce you are unlikely to be able to fix. I can reproduce it with XEmacs 21.2.32. It has all the earmarks of a timing or synchronization error. If I slow the process down at all (e.g., by making some of the functions involved interpreted, rather than byte-compiled), it works properly. When the process is "fast" (i.e., everything is byte-compiled and there are no delay loops), the bad behavior appears. I've got it narrowed down to this: when sgml-popup-menu (in psgml-xemacs.el) calls get-popup-menu-response, instead of waiting for the user to select something, the function returns immediately with an object of this form: #<misc-user-event (eval (update-widget-instances #<x-frame "emacs" 0x1fef>))> It appears that this is generated by popup_selection_callback in gui-x.c, but that is probably irrelevant. The real question is why get-popup-menu-response is returning the first misc-user-event it sees without checking whether it corresponds to a selection on the popup menu. I know nothing about the XEmacs event code, so I will have to let more experienced hands debug this the rest of the way. And, hey, in spite of all the traffic about psgml, so far we have uncovered only 1 actual bug, and it had a 1-line fix. Not bad, eh? -- Jerry James, trying not to break his arm while patting himself on the back