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

[martin rudalics]

>>  > (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