bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off

["Drew Adams" <drew.adams@oracle.com>]

> Arguably, Emacs 23 is now doing the right thing.  Your
> default-frame-alist specifies a tool-bar-lines frame parameter of 1,
> which means the tool-bar should be enabled in new frames.  If 
> you remove that frame parameter from your default-frame-alist, or set it 
> to 0, new frames will not show a tool-bar.
> 
> I am not 100% sure why previous version of Emacs did not show the
> tool-bar, but they probably ought to have.  Possibly it's 
> because we now set up the contents of the tool-bar at startup even if the 
> initial frame cannot or does not display it (a change required by
> the new multi-tty functionality).

Huh? Why is that the right thing? The default-frame-alist is set before turning
off tool-bar-mode. Turning off the mode should turn off the mode everywhere,
until you turn it back on - and it should change the value of
default-frame-alist - which it does, except in the scenario I gave. 

The default-frame-alist doesn't override the current setting of any modes. It
must not. It is simply a default setting. On the contrary - changing a mode such
as tool-bar-mode or menu-bar-mode should (and generally does) change the value
of default-frame-alist.

Tool-bar-mode is global and applies to all frames and future frames. That has
always been the case and should continue to be the case. What would be the point
of having such a mode if the original default frame alist overrode it?

Look at menu-bar-mode. It's exactly the same type of thing. But menu-bar-mode
acts normally, as it always has acted and as tool-bar-mode should also act.

And tool-bar-mode DOES act correctly, except in the scenario I gave, with
pop-up-frames non-nil, pop-up-frame-alist as I gave it, and a standalone
minibuffer frame. If you don't have all three of those, then turning off (or on)
tool-bar-mode, just like turning off (or on) menu-bar-mode, changes the value of
default-frame-alist to reflect the mode change, as it should.