Hmm, i'm quite sure that this is not a good solution.
ecb-speedbar-dframe-select-attached-window is the function i added to
the dframe-after-select-attached-frame-hook and this is necessary so
if a user middle-clicks (or RET) a node in the speedbar (e.g. a =
name) the according source-buffer becomes the active/selected buffer and =
stays on the "jumped" location... If you set this hook to nil then this =
not work because the dframe is not prepared running just in another =
of the source-frame.....
Also i'm wondering what speedbar-update-flag does so that after 1 sec =
the minibuffer will be deselected and another buffer is activated as =
the "M-x problem" in the original posting of Javier?
Maybe the best solution could be: ECB sets speedbar-update-flag at least =
to nil during an active speedbar-integration into the ECB-frame because =
this flag seems
not necessary for an integrated speedbar...what do you think Eric, could =
this be a good
solution or what can be drawbacks?
Eric M. Ludlam wrote:
> I have discovered that doing this after starting an ECB/speedbar
> (setq dframe-after-select-attached-frame-hook nil)
> solves the problem. It also solves a problem where you cannot do
> any repetitive speedbar keyboard commands.=20
> The value that was there was an ECB function which would re-select
> the original working window.=20
>> Hello all. This is a revival of old thread I started in October
>> 2005. I have upgraded my ecb version to 2.33beta1 and was hoping
>> that this issue would magically go away. Unfortunately, it is still
>> I can defintely remove the (setq speedbar-update-flag t) from my init
>> function, but I think it would be good to understand why the behavior
>> changed from one version of cedet to the next.
>> I tried M-: (setq speedbar-dynamic-tags-function-list (cdr
>> speedbar-dynamic-tags-function-list)) and the problem still happened.
>> Any other thoughts or does everyone want to me to shut up about
>> this? ;-)=20