Re: [PATCH] left-fringe for speedbar

[Kim F. Storm]

Nick Roberts <address@hidden> writes:

>  > Would it work to test explicitly for speedbar mode?
>  > 
>  > ([break]   menu-item "Set Breakpoint" gud-break
>  >                 :enable (not gud-running)
>  >                 :visible (not (or (eq major-mode 'speedbar-mode) 
>  >                              (and (memq gud-minor-mode '(gdbmi gdba))
>  >                                   (> (car (window-fringes)) 0)))))
>
> No I don't think so.  When there is more than one frame the tool-bar of the
> frame without focus is not determined by the buffer local values of the
> selected window but by those of the window that becomes selected if that frame
> is given focus (the function frame-selected-window hints at this concept as
> it can have frame as an argument).
>
> Try this: 
>
> 1) Put the GUD buffer in full frame (with fringes).
> 2) Do C-x 5 2 to generate an identical frame.
> 3) M-x set-fringe-style RET none so that one frame has no fringes.
> 4) Click alternately on each frame.
> 5) The extra icons disappear and appear _simultaneously_ on both frames
>    depending on whether the fringes are present on the frame with focus or 
> not.
>
> Ideally the extra icons should be present in the frame with fringes and not
> in the frame without them.

The problem seems to be that update_tool_bar only sets the current buffer
to the buffer of the selected window of the frame being updated, but
keeps the selected window (and selected frame) unchanged, so any functions
used by the tool-bar menu-items will refer to the wrong info.

We could fix this (by changing frame/window temporarily while updating
the tool bar [and menu bar?], or we could make new variables
tool-bar-updating-frame and tool-bar-updating-window which are
exported from C to Lisp to be used explicitly in such cases where a
tool-bar item should reflect the hosting frame/window rather than the
selected frame/window.

WDYT?

-- 
Kim F. Storm <address@hidden> http://www.cua.dk