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

[martin rudalics <rudalics@gmx.at>]

 >>  > (tool-bar-mode -1)
 >> [...]
 >>  >   (setq default-frame-alist
 >>  >         (append (list (cons 'tool-bar-lines 1))
 >>  >                 default-frame-alist))
 >>
 >> Inherently, you're painting yourself into a corner by simultaneously
 >> demanding and rejecting toolbars.  Moreover, that last assignment gets
 >> you a second entry for `tool-bar-lines' in
 >> `default-frame-alist' (and we have received _lots_ of mails
 >> from you complaining about such duplicate entries before).
 >
 > No, as a result of those "_lots_ of mails" I sent, that bug was finally fixed.
 > No duplicate entries are created by Emacs since 2008-12-31.
 >
 > However, you are correct that the code above creates a second entry for
 > `tool-bar-lines'. That should not be a problem - the first entry is used (it is
 > an alist, after all).

You mean what's good for you is not good for Emacs?

 > That is, there is no corner.

There is.  You want toolbars and eat them too.

 > The latest change to the
 > parameter `tool-bar-lines' should _always_ prevail - regardless of whether you
 > use `modify-frame-parameters' or (setq default-frame-alist...) or you call
 > `tool-bar-mode'.

What makes you think it doesn't?

 > The problem is, I'm thinking now, that the entry (tool-bar-lines . 1) in
 > `pop-up-frames-alist' is being used for the creation of new frames when
 > `pop-up-frames' is non-nil. If that is happening, it is incorrect behavior, on
 > two counts:
 >
 > 1. `tool-bar-mode' should be modal and affect all existing and subsequent
 > frames, regardless of their default alist (`special-display-frame-alist',
 > `pop-up-frame-alist', or `default-frame-alist').
 >
 > 2. `pop-up-frame-alist' should not be used for creating normal new frames.

As Drew uses to say "the Elisp manual is your friend":

  -- User Option: pop-up-frame-alist
      This variable holds an alist specifying frame parameters used when
      `display-buffer' makes a new frame.  *Note Frame Parameters::, for
      more information about frame parameters.

 >> However, you do _not_ set `initial-frame-alist' simultaneously,
 >> so you won't get a toolbar for the first frame which is the
 >> correct behavior since you have toggled tool-bar-mode off
 >> before and only that counts for the initial frame (unless you
 >> explicitly override it).  Since `default-frame-alist' contains
 >> a tool-bar-lines entry you will get a toolbar for future frames
 >> which is correct as well.
 >
 > Sorry, all of that text is irrelevant to my bug report. I am not concerned about
 > the initial frame.

You should be.  Unfortunately, you are not concerned about reading what
I write either.  So here we go again:

When you do

(tool-bar-mode -1)

you also create a (tool-bar-lines . 0) entry for _both_
`initial-frame-alist' and `default-frame-alist'.  When you do

   (setq default-frame-alist
         (append (list (cons 'tool-bar-lines 1))
                 default-frame-alist))

you override the (tool-bar-lines . 0) by a (tool-bar-lines . 1) entry
_for the default frame only_.  However, the initial frame will continue
to have the (tool-bar-lines . 0) entry you created earlier.  So the
initial frame won't have a toolbar, subsequently created frames will.

 > More importantly, if you turn the mode off, new frames should also not have tool
 > bars. That is the point here.

When you set tool-bar-lines to 1 in `default-frame-alist' the way you
do, new frames will have a toolbar.

 > I tried your patch (by just redefining tool-bar-mode after running my test
 > case), but it unfortunately does not seem to fix the problem. I suspect the
 > remaining problem is as I indicated above: `pop-up-frame-alist' is being used
 > when it shouldn't be used - to open normal frames (not popup frames).

Even if you were right about this one, the (tool-bar-lines . 1) entry in
`default-frame-alist' would continue to produce toolbars for new frames.

martin