That would be nice. :-)
In any case, sorry for the wild goose chase....and thanks for your
help!!=20
Javier
-----Original Message-----
From: Eric M. Ludlam [mailto:eric@...
Sent: Wednesday, April 06, 2005 2:57 PM
To: Oviedo, Javier
Cc: cedet-devel@...; klaus.berndl@...
Subject: Re[11]: [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.
Eric
>>> "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.
>(newline-and-indent)
>
>
> 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? ;-)
>
>Thanks!
>
>
>Javier
>
>
>
>-----Original Message-----
>From: Eric M. Ludlam [mailto:eric@...]
>Sent: Wednesday, April 06, 2005 11:55 AM
>To: Oviedo, Javier
>Cc: cedet-devel@...; klaus.berndl@...
>Subject: Re[9]: [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
>mouse event?
>
>I wonder if some other event is being generated in between that is=20
>confusing things for you.
>
>Eric
>
>>>> "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
>>INCREDIBLY CRUDE...
>>
>>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
>>relative
>
>>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
>>call
>
>>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
>unchanged.
>>
>>(dframe-maybee-jump-to-attached-frame) is definitely doing something!!
>>
>>Thoughts?
>>
>>Javier
>>
>>
>>
>>-----Original Message-----
>>From: Eric M. Ludlam [mailto:eric@...]
>>Sent: Tuesday, April 05, 2005 8:53 PM
>>To: Oviedo, Javier
>>Cc: cedet-devel@...; klaus.berndl@...
>>Subject: Re[7]: [CEDET-devel] Speedbar issue/question
>>
>>Hi,
>>
>> 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
>>same.
>>
>>ERic
>>
>>>>> "Oviedo, Javier" <joviedo@...> seems to think that:
>>>Hello Eric,
>>>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
>>>this
>>
>>>email.=3D20
>>>
>>>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
>>>0x178ea00>
>>>219 0)
>>>
>>>
>>>And my frame width is 220. When I step through I see the mouse move=20
>>>to
>
>>>the upper right corner of my emacs frame. According to the comments=20
>>>of
>
>>>"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
>>>window.
>>>
>>>I would like to disable this behavior as it is driving me nuts. ;-)=20
>>>=3D20
>>>
>>>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))
>>> dframe-activity-change-focus-flag)
>>> (progn
>>> ;(select-frame dframe-attached-frame)
>>> (other-frame 0))))
>>>
>>>
>>>Javier
>> [ ... ]
>>
>>
>>-------------------------------------------------------
>>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.
>>http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
>>_______________________________________________
>>Cedet-devel mailing list
>>Cedet-devel@...
>>https://lists.sourceforge.net/lists/listinfo/cedet-devel
>>
>
--=20
Eric Ludlam: zappo@...,
eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org
|