> Hi Martin, I do get this problem with the default 0.5s delay. At least, I > do see a problem of occasional switching window during menu use. I found > this particular problem when I upped the delay to 3s to try to make it > easier to reproduce/understand what I was seeing in normal use. What's > special about 1s?
You're right, there's nothing special about 1s. But you shouldn't get a selection with a negative value (unless you are very insistent). > I'm not sure what you mean by it being "the intended behavior". After all, > from the user's perspective, this particular gotcha is equivalent to the > problem this autoselect delay feature was meant to address (ie, window > selection occurs as you move across a window to the menu-bar to perform an > action you intended for the original window), but with a nasty twist - the > twist being that you can't see that window selection had occurred until > after you perform the menu action. Double ouch. You should be able to see that the selected window changed since the modeline changed to `modeline-inactive' face. I don't think that this problem is equivalent to the initial problem. The patch was meant to cure a no-way-out situation for the user. The new problem is merely the result of a slip with the mouse. Anyway, the problem occurs in practice, hence it should be addressed. > Sorry, I didn't express it very well. Not "reschedule the delay", but > "allow the delay to repeat" or "allow the timer to be rescheduled". What I > meant would be for mouse-autoselect-window-select to not perform selection > if the menu-bar or a popup-menu was active. Since this function is run from > a timer with a repeat time, and we would not cancel the timer in this case, > this function will just run again. In principle, would this DTRT? I think so. > Looking at CVS just now, it seems there is no way of knowing from Lisp if > the menu-bar or a popup-menu is active. However, popup_activated_flag > appears to represent this situation. If so, assuming it is available on all > windowing platforms, it could be exposed to Lisp. FWIW, `popup_activated_flag' is not really supported by w32menu.c and it's been removed from macmenu.c recently. Hence, this would have to be fixed first. Otherwise, someone else would have to take care of this since I couldn't reliably test xmenu.c. _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
