On Friday, November 07, "Jason Rumney" <[EMAIL PROTECTED]> wrote: >David Vanderschel wrote: >> On Friday, November 07, "Augusto Pedroza" <[EMAIL PROTECTED]> wrote:
>>> I can scroll down with the mouse "wheel" in the first >>> windows only even when I have selected the second >>> window. >> I am running an older version of emacs, but I, too, >> observe somewhat surprising behaviour with mouse-wheel >> scrolling in the presence of horizontally split >> windows. >What does C-h k [mouse-wheel] report? Actually, regarding the code that might cause a switch of windows affected by the scroll wheel, I had already mentioned: >>It is not reflected in the higher level code >>(w32-handle-scroll- bar-event) which ultimately >>handles a given scrolling event. which does provide the answer to Jason's question. >Some mouse drivers do not simply send mouse-wheel >events, but rather have their own (often buggy) code >to locate the scroll bar and simulate scroll-bar >events. Indeed. I have such a 'mouse' also - a GlidePoint touchpad on my keyboard. However, the behaviour I was reporting was for a Dell USB mouse which is using the standard Windows USB pointing device driver. With some effort, I was also able to get an apparently 'wrong' behaviour with the touchpad as well; but its behaviour is different with a difference more like I suppose that Jason was considering. >If you do not use any special features of your mouse >driver then you can try switching to one of the >generic mouse drivers which will send proper wheel >events. No. I like the way both drivers behave. What strangeness exists is not a problem for me. I said that. My point was that the symptom I was observing might well be the same as Augusto was observing and that he was possibly misinterpreting the symptom and its seriousness. (Indeed, his statement of the symptom was hardly clear to start with.) I was able to observe a (not very problematic) behaviour which could conceivably be described in the same manner as he described the behaviour which was concerning him. In particular, I tried to emphasize that which window is selected is not relevant with respect to which window scrolls and that this behaviour is clearly intentional based on looking at the code. (The routine I mentioned in the quote above saves the selected window and restores it after messing with the scroll position of whichever window is associated with the mouse event. Being time-delay dependent, it is that _association_ which behaves somewhat strangely, and the responsibility for the strangeness may well lie outside Emacs. However, I do see time-delay dependence with both drivers.) It is conceivable that Augusto has a mouse driver which is behaving completely wrongly with respect to guessing which scroll bar should be associated with the mouse wheel at a given point in time. If that is the case, then Jason's suggestion to try a simpler driver could potentially solve what may be a real problem for Augusto - but not for me. Indeed, it may be that Jason thought he was responding to Augusto when, in fact, he was replying to my response to Augusto. Regards, David V.
