GNU bug report logs - #1754
23.0.60; tool-bar is shown with tool-bar-mode off

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: <1754 <at> debbugs.gnu.org>
Subject: bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off
Date: Thu, 1 Jan 2009 13:28:17 -0800

>  > (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). That is, there is no corner. 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'.

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.

The "pop-up" in each of the names `pop-up-frames' and `pop-up-frames-alist'
means very different things. `pop-up-frames-alist' is not about creating normal
new frames - `default-frame-alist' should be used for that. And `pop-up-frames'
simply changes things like `C-x 4 f' to act like `C-x 5 f' - it has nothing to
do with popup frames.

`pop-up-frames-alist' is about special, "popup" frames (which is why it is a
separate alist, like `special-display-frame-alist'):

"Alist of frame parameters used when creating pop-up frames.
Pop-up frames are used for completions, help, and the like.
This variable can be set in your init file, like this:
  (setq pop-up-frame-alist '((width . 80) (height . 20)))
These supersede the values given in `default-frame-alist',
for pop-up frames."

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

> That said, the behavior of Emacs _is_ wrong because it should not say
> that `tool-bar-mode' is on when there are no toolbars.

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

> The reason is that `tool-bar-mode' does
> 
>    (if tool-bar-mode
>        (progn
>    	    (dolist (frame (frame-list))
>    	     (if (display-graphic-p frame)
>    	         (set-frame-parameter frame 'tool-bar-lines 1)))
> 	(if (= 1 (length (default-value 'tool-bar-map))) ; not yet setup
> 	    (tool-bar-setup)))
>      (modify-all-frames-parameters (list (cons 'tool-bar-lines 0)))))
> 
> so you can easily see that for turning `tool-bar-mode' off, 
> default and initial frame parameters are set. For turning it on, only the
> parameters of the existing frames are set and _no_ default or initial
> parameters.

That might be at least partly responsible for the bug.

Again, the current bugged behavior:

1. is a regression - the behavior was correct in Emacs 22

2. does not correspond to the behavior of `menu-bar-mode', which is correct in
Emacs 23, like 22

> Since the `display-graphic-p' test is not useful 
> anyway, I propose the attached patch.

I think the logic of your patch is needed, but it is not sufficient.

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).

The Emacs 22.3 code works fine in all regards.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.