That would be nice. :-)
In any case, sorry for the wild goose chase....and thanks for your
From: Eric M. Ludlam [mailto:eric@...
Sent: Wednesday, April 06, 2005 2:57 PM
To: Oviedo, Javier
Cc: cedet-devel@...; klaus.berndl@...
Subject: Re: [CEDET-devel] Speedbar issue/question
Well, theoretically the mayee-jump function could see if the attacked
frame is also the selected frame, and then avoid doing the jump. That
would fix the speedbar in ECB only case.
>>> "Oviedo, Javier" <joviedo@...> seems to think that:
>Here you go. This seems to be the issue.
>last-input-event's value is: return
>I just did a "C-h k mouse-2" and I see the following:
>RET (translated from <return>) runs the command newline-and-indent
> which is an interactive compiled Lisp function in `simple'.
>It is bound to RET.
> In my Windows XP mouse setup, I have specified mouse-2 to be RET.=20
>Also, I have the following in my .emacs file:
> (define-key c-mode-map "\C-m" 'newline-and-indent)
>The combination of those two things explains what I see for "C-h k=20
>mouse-2" and the speedbar behavior. Also, when I tried emacs without=20
>any configuration I see that mouse-2 is bound to "newline", again due=20
>to the windows mouse setup....so this explains why I also see it there.
>It therefore seems that my problem is completely of my own making. :-)=20
>This is rather unfortunate.
>I'd prefer not to change my windows mouse setting and would also not=20
>like to manually comment out the call to=20
>dframe-maybee-jump-to-attached-frame. Is there any other "clean"
>solution you can think of, or am I asking too much? ;-)
>From: Eric M. Ludlam [mailto:eric@...]
>Sent: Wednesday, April 06, 2005 11:55 AM
>To: Oviedo, Javier
>Cc: cedet-devel@...; klaus.berndl@...
>Subject: Re: [CEDET-devel] Speedbar issue/question
>Could you find out what the value of last-input-event is inside=20
>dframe-maybee-jump-to-attached-frame, and if it somehow qualifies as a=20
>I wonder if some other event is being generated in between that is=20
>confusing things for you.
>>>> "Oviedo, Javier" <joviedo@...> seems to think that:
>>I understand your point about the debugger, however I only used it at=20
>>the very end of my debugging to give you output in the form of a=20
>>backtrace. What I actually did to prove this was the problem was=20
>>I used a serious of print statements through out the sequence of the=20
>>functions I listed below. Each print would tell me where I was=20
>>to the call path and also the current mouse position. This finally=20
>>narrowed the problem to the (dframe-maybee-jump-to-attached-frame)=20
>>in (speedbar-find-file). Before the call the mouse position is one=20
>>value(constant from the very beginning), but after the return of the=20
>>call the mouse position has changed to 219 0 (upper right corner).
>>My current work around, once I revert to the original version of the=20
>>speedbar.el, is to simple comment out the call to
>>(dframe-maybee-jump-to-attached-frame) inside of speedbar-find-file.=20
>>The problem no longer happens! All other behavior seems to remain
>>(dframe-maybee-jump-to-attached-frame) is definitely doing something!!
>>From: Eric M. Ludlam [mailto:eric@...]
>>Sent: Tuesday, April 05, 2005 8:53 PM
>>To: Oviedo, Javier
>>Cc: cedet-devel@...; klaus.berndl@...
>>Subject: Re: [CEDET-devel] Speedbar issue/question
>> Since I last sent email about my solution, I have not been able to=20
>>replicate the problem.
>> Unfortunately, you cannot step through the below function with the=20
>>debugger. As soon as you press a key for debugging purposes,=20
>>"last-input-event" will now not be a mouse event, so naturally it will
>>make the mouse jump.
>> When I was first tracking things down, I used `debug-on-enter' for=20
>>`other-frame' and was able to find the event. You may need to do the=20
>>>>> "Oviedo, Javier" <joviedo@...> seems to think that:
>>>I have tracked down the cause of this pointer moving....and it is not
>>>the function you mentioned below. I have attached the backtrace to=20
>>>Essentially the call flow is:
>>>speedbar-find-file -> dframe-maybee-jump-to-attached-frame ->=20
>>>select-frame-set-input-focus -> set-mouse-position(#<frame =20
>>>And my frame width is 220. When I step through I see the mouse move=20
>>>the upper right corner of my emacs frame. According to the comments=20
>>>"dframe-maybee-jump-to-attached-frame", shouldn't the call to=20
>>>"other-frame" not happen?? I am doing a mouse-2 click in the speedbar
>>>I would like to disable this behavior as it is driving me nuts. ;-)=20
>>>Please let me know what you think. Thanks!
>>>(defun dframe-maybee-jump-to-attached-frame ()
>>> "Jump to the attached frame ONLY if this was not a mouse event."
>>> (if (or (not (dframe-mouse-event-p last-input-event))
>>> ;(select-frame dframe-attached-frame)
>>> (other-frame 0))))
>> [ ... ]
>>SF email is sponsored by - The IT Product Guide Read honest & candid=20
>>reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>Cedet-devel mailing list
Eric Ludlam: zappo@...,
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org