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

[Drew Adams]

> > Huh? Why is that the right thing?
> 
> Because your function `foo' tells Emacs to add a tool-bar to 
> new frames.
> Here is a much, much simpler version of your "bug":
> 
>  In foo.el;
>   (tool-bar-mode -1)
>   (defun foo ()
>     (interactive)
>     (setq default-frame-alist
>           (append (list (cons 'tool-bar-lines 1))
>                   default-frame-alist)))
> 
>  emacs -Q -l "foo.el" -f "foo"
> 
> When foo.el is loaded, that turns off tool-bar-mode (internally, this
> works by modifying default-frame-alist and changing the frame 
> parameter `tool-bar-lines' to 0).
> 
> Next, the function `foo' is run.  That modifies default-frame-alist by
> adding (tool-bar-lines . 1).  So, all new frames get a tool-bar.

No, you missed the point. I wasn't clear enough.

Use your code above, plus (setq pop-up-frames t). After starting Emacs, turn off
tool-bar mode: M-x tool-bar-mode. Thereafter, new frames do not have tool bars.
This is correct behavior - no bug.

Now do the same thing with the code I sent - with the standalone minibuffer
frame and `pop-up-frames-alist'. After you turn off tool-bar mode, new frames
have tool bars. That is the bug.

I already said that there is no bug without the three things I mentioned:
standalone minibuffer, non-nil `pop-up-frames', and `pop-up-frames-alist'.
Without those conditions, `tool-bar-mode' acts normally; it acts just like
`menu-bar-mode': it affects subsequent new frames.

I am now getting the impression that `pop-up-frames-alist' is being used for
opening new normal frames, not just for popup frames. If so, that is at least a
partial cause of the bug. I think that what Martin found is the other cause.

IOW, I think what is needed is both:

1. Martin's patch: turning off the mode should update `default-frame-alist'
also.

2. There is likely code somewhere that is now using `pop-up-frame-alist' for the
creation of ordinary frames, not popup frames. That needs to be fixed.