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

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

[Drew Adams]

This is a regression wrt Emacs 20, 21, and 22.
 
1. Put this code in a file named `bug-tool-bar.el':
 
(tool-bar-mode -1)
(defvar my-minibuffer-frame nil "")
(defun foo () ""
  (interactive)
  (setq default-frame-alist
        (append (list (cons 'tool-bar-lines 1))
                default-frame-alist))
  (setq pop-up-frames      t
        pop-up-frame-alist (append default-frame-alist
                                   pop-up-frame-alist))
  (setq minibuffer-frame-alist
        (append (list (cons 'minibuffer 'only))
                minibuffer-frame-alist))
  (if my-minibuffer-frame
      (modify-frame-parameters my-minibuffer-frame
                               (list (cons 'minibuffer 'only)))
    (setq my-minibuffer-frame
          (let ((after-make-frame-functions nil))
            (make-frame (list (cons 'minibuffer 'only)))))))
 
It doesn't matter where the (tool-bar-mode -1) is, and you could
alternatively leave it out altogether and then do `M-x tool-bar-mode'
to turn it off (step 3).
 
2. Start Emacs this way:
 
runemacs.exe -Q --debug-init -l "bug-tool-bar.el" -f "foo"
 
You get one frame with buffer *scratch* and a standalone minibuffer
frame. Neither frame has a tool bar. However, `tool-bar-mode' is t -
it should be nil. You can see this by typing `tool-bar-mode' in buffer
*scratch* and using `C-x C-e'.
 
3. Optional step: `M-x tool-bar-mode'. This turns off tool-bar mode,
though it should already have been off because of the code in
`bug-tool-bar.el'.
 
4. Do `C-x 4 f some-file.el'. The file is visited in a new frame, and
the frame has a tool bar. And tool-bar mode is now on. And this is so
regardless of whether you skip step 3.

The mode should remain off, and no tool bar should be shown.
 

In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-12-30 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include
-fno-crossjumping'
 

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

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]

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

That said, the behavior of Emacs _is_ wrong because it should not say
that `tool-bar-mode' is on when there are no toolbars.  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.  Since the `display-graphic-p' test is not useful anyway, I
propose the attached patch.

Yours truly, martin.

[-- Attachment #2: tool-bar.diff --]
[-- Type: text/plain, Size: 796 bytes --]

*** tool-bar.el.~1.22.~	2008-11-27 07:43:19.062500000 +0100
--- tool-bar.el	2009-01-01 16:20:25.968750000 +0100
***************
*** 54,62 ****
    :group 'frames
    (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)))))
--- 54,60 ----
    :group 'frames
    (if tool-bar-mode
        (progn
! 	(modify-all-frames-parameters (list (cons '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)))))

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

[Jason Rumney]

martin rudalics wrote:
> Since the `display-graphic-p' test is not useful anyway

What makes you say that? Is it already tested before we get to this point?

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

[martin rudalics]

 >> Since the `display-graphic-p' test is not useful anyway
 >
 > What makes you say that? Is it already tested before we get to this point?

No one hinders people to call `modify-all-frames-parameters' with
tool-bar-lines 1.  So if we really have to check this, we have to do it
in `modify-frame-parameters'.  Doing it just in `tool-bar-mode' is not
sufficient.

martin

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

[Drew Adams]

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

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

[Drew Adams]

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

I think the bug was introduced when someone translated the C code definition of
`display-buffer' to Lisp. This code was added gratuitously, and it causes
`pop-up-frames' to use `pop-up-frame-alist':

(let...
  ;; On text-only terminals do not pop up a new frame when
  ;; `pop-up-frames' equals graphic-only.
  (use-pop-up-frames (if (eq pop-up-frames 'graphic-only)
                         (display-graphic-p)
                       pop-up-frames))

`pop-up-frames' being non-nil should in no way cause `C-x 5 b' etc. to use
`pop-up-frame-alist' for the new frame creation.

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

[martin rudalics]

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

Then why do you specify such alist entries in the first place?

 >> 2. `pop-up-frame-alist' should not be used for creating
 >> normal new frames.
[...]
 >> "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."

I shall clean up the docstring of `pop-up-frame-alist' to make clear
that it _is_ used for creating normal new frames.

 > I think the bug was introduced when someone translated the C code definition of
 > `display-buffer' to Lisp.

That someone was me and the bugs I introduced caused continuous crashes
of Emacs and many finance markets all over the world.  Let's hope for a
change then ...

martin

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

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

[Stefan Monnier]

> 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

Makes me wonder: why does it set it in initial-frame-alist since that
alist is always combined with default-frame-alist?


        Stefan

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

[martin rudalics]

 >> you also create a (tool-bar-lines . 0) entry for _both_
 >> `initial-frame-alist' and `default-frame-alist'.  When you do
 >
 > Makes me wonder: why does it set it in initial-frame-alist since that
 > alist is always combined with default-frame-alist?

If you mean that `modify-all-frames-parameters' should not change
`initial-frame-alist' because the "right" value will be eventually found
when scanning `default-frame-alist', you're maybe right.  OTOH a user
may have set `initial-frame-alist' to contain a tool-bar-lines entry and
wants to explicitly turn off `tool-bar-mode' for the initial frame.
Consider Drew's example with "initial" replacing "default".

`default-frame-alist' and `initial-frame-alist' are a mess because these
are customizable variables that should not be affected by toggling minor
modes on and off.  I think it's only confusing to have (at least) three
.emacs ways to specify whether an initial frame should show a toolbar.

martin

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

[Stefan Monnier]

>>> you also create a (tool-bar-lines . 0) entry for _both_
>>> `initial-frame-alist' and `default-frame-alist'.  When you do
>> Makes me wonder: why does it set it in initial-frame-alist since that
>> alist is always combined with default-frame-alist?
> If you mean that `modify-all-frames-parameters' should not change
> `initial-frame-alist' because the "right" value will be eventually found
> when scanning `default-frame-alist', you're maybe right.

Yes, I think that's what I mean.

> OTOH a user may have set `initial-frame-alist' to contain
> a tool-bar-lines entry and wants to explicitly turn off
> `tool-bar-mode' for the initial frame.  Consider Drew's example with
> "initial" replacing "default".

But modify-all-frames-parameters beings by removing any such setting in
initial-frame-alist anyway, so it seems this case still doesn't justify
adding the setting to initial-frame-alist.


        Stefan

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

[martin rudalics]

 >> If you mean that `modify-all-frames-parameters' should not change
 >> `initial-frame-alist' because the "right" value will be eventually found
 >> when scanning `default-frame-alist', you're maybe right.
 >
 > Yes, I think that's what I mean.
 >
 >> OTOH a user may have set `initial-frame-alist' to contain
 >> a tool-bar-lines entry and wants to explicitly turn off
 >> `tool-bar-mode' for the initial frame.  Consider Drew's example with
 >> "initial" replacing "default".
 >
 > But modify-all-frames-parameters beings by removing any such setting in
 > initial-frame-alist anyway, so it seems this case still doesn't justify
 > adding the setting to initial-frame-alist.

On the one hand you mean that `modify-all-frames-parameters' should not
change `initial-frame-alist' on the other you mean it should remove such
setting in `initial-frame-alist' anyway?  You leave me confused.

martin

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

[Stefan Monnier]

>>> If you mean that `modify-all-frames-parameters' should not change
>>> `initial-frame-alist' because the "right" value will be eventually found
>>> when scanning `default-frame-alist', you're maybe right.
>> 
>> Yes, I think that's what I mean.
>> 
>>> OTOH a user may have set `initial-frame-alist' to contain
>>> a tool-bar-lines entry and wants to explicitly turn off
>>> `tool-bar-mode' for the initial frame.  Consider Drew's example with
>>> "initial" replacing "default".
>> 
>> But modify-all-frames-parameters beings by removing any such setting in
>> initial-frame-alist anyway, so it seems this case still doesn't justify
>> adding the setting to initial-frame-alist.

> On the one hand you mean that `modify-all-frames-parameters' should not
> change `initial-frame-alist' on the other you mean it should remove such
> setting in `initial-frame-alist' anyway?  You leave me confused.

No, I only said that it shouldn't *set* the value in
initial-frame-alist.  Of course, it needs to remove any previous setting
in order for the setting in default-frame-alist not to be overridden.


        Stefan

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

[martin rudalics]

 > No, I only said that it shouldn't *set* the value in
 > initial-frame-alist.  Of course, it needs to remove any previous setting
 > in order for the setting in default-frame-alist not to be overridden.

To summarize, assigning parameters for the initial frame takes values in
increasing order of priority from

(1) `frame-initial-frame-alist' which has all the resource and command
     line settings incorporated as well as everything that has been done
     via (modify-frame-parameters nil ...) while reading .emacs,

(2) `default-frame-alist' which merges all implicit `tool-bar-mode',
     `scroll-bar-mode', ... with explicit (setq default-frame-alist ...),
     `modify-all-frames-parameters', ... assignments, and

(3) `initial-frame-alist' which may contain only entries obtained via
     (setq initial-frame-alist ...) since `modify-all-frames-parameters'
     does not operate on that list.

or am I missing something?

martin

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

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 251 bytes --]

 > No, I only said that it shouldn't *set* the value in
 > initial-frame-alist.  Of course, it needs to remove any previous setting
 > in order for the setting in default-frame-alist not to be overridden.

So shall I apply the attached patch?

martin

[-- Attachment #2: frame.el.diff --]
[-- Type: text/plain, Size: 942 bytes --]

*** frame.el.~1.291.~	2009-01-05 09:58:26.812500000 +0100
--- frame.el	2009-01-09 20:09:15.750000000 +0100
***************
*** 593,600 ****
      (dolist (w window-system-default-frame-alist)
        (setcdr w (assq-delete-all (car pair) (cdr w)))))
  
!   (and frame-notice-user-settings
!        (setq initial-frame-alist (append initial-frame-alist alist)))
    (setq default-frame-alist (append default-frame-alist alist)))
  
  (defun get-other-frame ()
--- 593,602 ----
      (dolist (w window-system-default-frame-alist)
        (setcdr w (assq-delete-all (car pair) (cdr w)))))
  
!   ;; There's no need to set the value in initial-frame-alist since
!   ;; frame-notice-user-settings will take it from default-frame-alist.
!   ;; (and frame-notice-user-settings
!   ;;     (setq initial-frame-alist (append initial-frame-alist alist)))
    (setq default-frame-alist (append default-frame-alist alist)))
  
  (defun get-other-frame ()

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

[Stefan Monnier]

>> No, I only said that it shouldn't *set* the value in
>> initial-frame-alist.  Of course, it needs to remove any previous setting
>> in order for the setting in default-frame-alist not to be overridden.

> So shall I apply the attached patch?

I don't know: that was basically my question.


        Stefan


> *** frame.el.~1.291.~	2009-01-05 09:58:26.812500000 +0100
> --- frame.el	2009-01-09 20:09:15.750000000 +0100
> ***************
> *** 593,600 ****
>       (dolist (w window-system-default-frame-alist)
>         (setcdr w (assq-delete-all (car pair) (cdr w)))))
  
> !   (and frame-notice-user-settings
> !        (setq initial-frame-alist (append initial-frame-alist alist)))
>     (setq default-frame-alist (append default-frame-alist alist)))
  
>   (defun get-other-frame ()
> --- 593,602 ----
>       (dolist (w window-system-default-frame-alist)
>         (setcdr w (assq-delete-all (car pair) (cdr w)))))
  
> !   ;; There's no need to set the value in initial-frame-alist since
> !   ;; frame-notice-user-settings will take it from default-frame-alist.
> !   ;; (and frame-notice-user-settings
> !   ;;     (setq initial-frame-alist (append initial-frame-alist alist)))
>     (setq default-frame-alist (append default-frame-alist alist)))
  
>   (defun get-other-frame ()

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

[martin rudalics]

 >> So shall I apply the attached patch?
 >
 > I don't know: that was basically my question.

Then I won't.  It's not that much of an optimization.

martin

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

[Stefan Monnier]

>>> So shall I apply the attached patch?
>> I don't know: that was basically my question.
> Then I won't.  It's not that much of an optimization.

It's not a question of optimization but of semantics.
It seems cleaner to only add the setting to default-frame-alist if
that's possible.  Which is why I asked for a reason wy it's also added
to initial-frame-alist even tho it doesn't seem necessary.


        Stefan

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

[martin rudalics]

 > It's not a question of optimization but of semantics.
 > It seems cleaner to only add the setting to default-frame-alist if
 > that's possible.  Which is why I asked for a reason wy it's also added
 > to initial-frame-alist even tho it doesn't seem necessary.

When the .emacs reader encounters the form

(modify-all-frames-parameters (list (cons 'tool-bar-lines 1)))

it will map both initial-frame-alist and default-frame-alist to an alist
containing a (tool-bar-lines . 1) entry.  If it then encounters the form

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

it adds to default-frame-alist a (tool-bar-lines . 0) entry shadowing
the (tool-bar-lines . 1) entry.  With current Emacs, the initial frame
will probably have a tool bar.  If we "only add the setting to
default-frame-alist", the initial frame likely will not have a tool bar.

Hence, applying the change we're talking about can change the meaning of
a valid .emacs file for some value of validity.  But I suppose you know
that.  Alas, I don't know what kind of semantics you have in mind :-(

martin

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

[Stefan Monnier]

>>>>> "martin" == martin rudalics <rudalics@gmx.at> writes:

>> It's not a question of optimization but of semantics.
>> It seems cleaner to only add the setting to default-frame-alist if
>> that's possible.  Which is why I asked for a reason wy it's also added
>> to initial-frame-alist even tho it doesn't seem necessary.

> When the .emacs reader encounters the form

> (modify-all-frames-parameters (list (cons 'tool-bar-lines 1)))

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

The above two forms don't mention anything special about the
initial-frame, so I think that it's a bug if Emacs treats the initial
frame differently in this case.


        Stefan

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

[martin rudalics]

 >> When the .emacs reader encounters the form
 >
 >> (modify-all-frames-parameters (list (cons 'tool-bar-lines 1)))
 >
 >> (setq default-frame-alist
 >>       (append (list (cons 'tool-bar-lines 0))
 >>               default-frame-alist))
 >
 > The above two forms don't mention anything special about the
 > initial-frame, so I think that it's a bug if Emacs treats the initial
 > frame differently in this case.

Maybe.  We'd also have to cater for `window-system-default-frame-alist'
which currently overrides values from `default-frame-alist' but not
those of `initial-frame-alist'.  That is, `modify-all-frames-parameters'
currently overrides a setting in `window-system-default-frame-alist'.

martin

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

[Stefan Monnier]

>>> When the .emacs reader encounters the form
>>> (modify-all-frames-parameters (list (cons 'tool-bar-lines 1)))
>>> (setq default-frame-alist
>>> (append (list (cons 'tool-bar-lines 0))
>>> default-frame-alist))
>> 
>> The above two forms don't mention anything special about the
>> initial-frame, so I think that it's a bug if Emacs treats the initial
>> frame differently in this case.

> Maybe.  We'd also have to cater for `window-system-default-frame-alist'
> which currently overrides values from `default-frame-alist' but not
> those of `initial-frame-alist'.  That is, `modify-all-frames-parameters'
> currently overrides a setting in `window-system-default-frame-alist'.

Very good point.  I think it makes it even more correct to apply the
change I suggest.


        Stefan

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

[martin rudalics]

 >> Maybe.  We'd also have to cater for `window-system-default-frame-alist'
 >> which currently overrides values from `default-frame-alist' but not
 >> those of `initial-frame-alist'.  That is, `modify-all-frames-parameters'
 >> currently overrides a setting in `window-system-default-frame-alist'.
 >
 > Very good point.  I think it makes it even more correct to apply the
 > change I suggest.

Agreed.  But then why should `modify-all-frames-parameters' modify
`window-system-default-frame-alist'?

martin

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

[Stefan Monnier]

>>> Maybe.  We'd also have to cater for `window-system-default-frame-alist'
>>> which currently overrides values from `default-frame-alist' but not
>>> those of `initial-frame-alist'.  That is, `modify-all-frames-parameters'
>>> currently overrides a setting in `window-system-default-frame-alist'.
>> Very good point.  I think it makes it even more correct to apply the
>> change I suggest.
> Agreed.  But then why should `modify-all-frames-parameters' modify
> `window-system-default-frame-alist'?

I'm not sure I understand the question.  It doesn't add the setting to
window-system-default-frame-alist, does it?  So all it does is remove
any overriding setting from it, just like it does with
initial-frame-alist, which is necessary for the default-frame-alist
setting to be effective.


        Stefan

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

[martin rudalics]

 > I'm not sure I understand the question.  It doesn't add the setting to
 > window-system-default-frame-alist, does it?  So all it does is remove
 > any overriding setting from it, just like it does with
 > initial-frame-alist, which is necessary for the default-frame-alist
 > setting to be effective.

I'm not sure whether toggling tool-/menu-bar-mode should override
window-system specific settings.  When we set tool-bar-lines in
default-frame-alist we don't override window-system specific settings.
Is toggling tool-/menu-bar-mode conceptually "stronger" than setting
default-frame-alist WRT to future frames?  What's the purpose of setting
`window-system-default-frame-alist' in .emacs when a simple click on a
menu entry will annihilate its effect for the rest of the session?  Such
clicks are not window-system specific.

martin

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

[Stefan Monnier]

>> I'm not sure I understand the question.  It doesn't add the setting to
>> window-system-default-frame-alist, does it?  So all it does is remove
>> any overriding setting from it, just like it does with
>> initial-frame-alist, which is necessary for the default-frame-alist
>> setting to be effective.

> I'm not sure whether toggling tool-/menu-bar-mode should override
> window-system specific settings.  When we set tool-bar-lines in
> default-frame-alist we don't override window-system specific settings.
> Is toggling tool-/menu-bar-mode conceptually "stronger" than setting
> default-frame-alist WRT to future frames?  What's the purpose of setting
> `window-system-default-frame-alist' in .emacs when a simple click on a
> menu entry will annihilate its effect for the rest of the session?  Such
> clicks are not window-system specific.

That's a more general problem: I usually don't have a menu-bar in my
frames, except for a few exception where I give them a menu-bar via
special-display-buffer-names.
Whenever I use M-x menu-bar-mode, these details are lost.

The problem is that tool-bar-mode, and menu-bar-mode and too coarse:
they offer no way for the user to say whether he wants it to apply to
every single frame, or only to those currently displayed, or only the
current one, or only those on the current terminal, ...

Also, making them work right would probably require keeping track for
each and ever frame of where its parameters came from.  So tool-bar-mode
could just set default-frame-alist and then "refresh" every
frame's parameters.


        Stefan

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

[Lennart Borgman]

On Mon, Jan 12, 2009 at 7:29 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> The problem is that tool-bar-mode, and menu-bar-mode and too coarse:
> they offer no way for the user to say whether he wants it to apply to
> every single frame, or only to those currently displayed, or only the
> current one, or only those on the current terminal, ...
>
> Also, making them work right would probably require keeping track for
> each and ever frame of where its parameters came from.  So tool-bar-mode
> could just set default-frame-alist and then "refresh" every
> frame's parameters.

Isn't that a good general structure for all kinds of local/global settings?

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

[Stefan Monnier]

>> The problem is that tool-bar-mode, and menu-bar-mode and too coarse:
>> they offer no way for the user to say whether he wants it to apply to
>> every single frame, or only to those currently displayed, or only the
>> current one, or only those on the current terminal, ...
>> 
>> Also, making them work right would probably require keeping track for
>> each and ever frame of where its parameters came from.  So tool-bar-mode
>> could just set default-frame-alist and then "refresh" every
>> frame's parameters.

> Isn't that a good general structure for all kinds of local/global settings?

Yes, I think so.  Not that it's easy to do, tho.


        Stefan

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

[Drew Adams]

> >> I'm not sure I understand the question.  It doesn't add 
> >> the setting to window-system-default-frame-alist, does it?
> >> So all it does is remove any overriding setting from it,
> >> just like it does with initial-frame-alist, which is
> >> necessary for the default-frame-alist
> >> setting to be effective.
> 
> > I'm not sure whether toggling tool-/menu-bar-mode should override
> > window-system specific settings.  When we set tool-bar-lines in
> > default-frame-alist we don't override window-system 
> > specific settings. Is toggling tool-/menu-bar-mode conceptually 
> > "stronger" than setting default-frame-alist WRT to future frames?  
> > What's the purpose of setting `window-system-default-frame-alist'
> > in .emacs when a simple click on a menu entry will annihilate
> > its effect for the rest of the session?  Such
> > clicks are not window-system specific.
> 
> That's a more general problem: I usually don't have a menu-bar in my
> frames, except for a few exception where I give them a menu-bar via
> special-display-buffer-names. Whenever I use M-x menu-bar-mode,
> these details are lost.
> 
> The problem is that tool-bar-mode, and menu-bar-mode and too coarse:
> they offer no way for the user to say whether he wants it to apply to
> every single frame, or only to those currently displayed, or only the
> current one, or only those on the current terminal, ...
> 
> Also, making them work right would probably require keeping track for
> each and ever frame of where its parameters came from.  So 
> tool-bar-mode could just set default-frame-alist and then
> "refresh" every frame's parameters.

Not sure I want to jump in here again, but here goes nothing. I am no expert on
this, so feel free to set me straight. ;-)

I don't think that the problem is that `tool-bar-mode' and `menu-bar-mode' are
too coarse. The problem is that it is not simple to decide how to juggle the
various ways of changing frame parameters and, in particular, the possible
intentions of users. Which also means that it is not always simple for users or
code to achieve a desired behavior.

I think that a straightforward rule should govern this - chronological order.
The latest change to a frame parameter should win - always. And nothing should
affect future frames in a way that overrides later parameter settings - ever.  

In particular, no default definition for frames - whether `default-frame-alist'
or `pop-up-frame-alist' or special-display frame functions (or default values) -
should override explicitly setting a frame parameter.

Second, `tool-bar-mode' and `menu-bar-mode' should not be special in any way.
They should change all existing frames (yes, all), and they should use only
`after-make-frame-functions' to affect future frames.

[If it's _really_ important to prevent those two modes from interfering with
settings that might be made in other ways, we could special-case them by having
two additional frame parameters that stop those modes from changing a given
frame's parameter: `inhibit-tool-bar-mode' and `inhibit-menu-bar-mode'.]

If this principle is accepted, the question then becomes what the order should
be, in particular for actions that are intended to affect future frames (or
future frames of some type). Suggested order:

1. The frame alists that are applicable (init, default, popup, special-display,
whatever). And, in the case of special-display frames, that would include
whatever any pertinent special-display functions do. IOW, all such things would
provide only _default_ values for frame parameters.

2. Any frame-parameter modification done by `after-make-frame-functions'.

3. Explicit later calls that modify parameters of existing frames (e.g.
`modify-frame-paramters').

Because of chronological order, #3 overrides #2, which overrides #1. Always.
There is no need to save any special state or history to record intentions.

All functions or modes that intend to affect future frames would use a hook such
as `after-make-frame-functions' to do so. There would be no built-in treatment
for future frames (other than the default definitions). In this way,
`tool-bar-mode' and `menu-bar-mode' would not be treated specially.

Calls to `tool-bar-mode' and `menu-bar-mode' are covered in #3. But those modes
would also add (or remove) a function to `after-make-frame-functions' that would
add a tool bar or menu bar.

[If it's really important that `tool-bar-mode' and `menu-bar-mode' be
special-cased, then their role of affecting future frames could take effect
systematically between steps #1 and #2. That would still let you override their
effect using `after-make-frame-functions'. But I don't think special-casing them
is necessary or TRT.]

The advantage of such a scheme is simplicity: chronological order rules. That is
already the rule we use within a hook such as `after-make-frame-functions', and
it makes sense more generally also.

Someone (or some code) that wants, say, most frames to have a tool bar but not
certain frames (e.g. pop-up frames or those with a name that contains `foobar'),
would:

1. Turn on `tool-bar-mode' (which would in turn put a function on
`after-make-frame-functions' that creates a tool bar).

2. Append a function to `after-make-frame-functions' that tests the frame type
(checking any characteristics it wants) and, if appropriate, removes the tool
bar.

This approach might sound overly simplistic, but the alternative is, I think, a
nightmare (aka un merdier).

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

[martin rudalics]

> The problem is that tool-bar-mode, and menu-bar-mode and too coarse:
> they offer no way for the user to say whether he wants it to apply to
> every single frame, or only to those currently displayed, or only the
> current one, or only those on the current terminal, ...

I was only talking about `window-system-default-frame-alist', a variable
which apparently has no provenience and not very clear semantics.  If I
ever used it, I'd not expect a mode toggling function reset it.  Note
also that things like `pop-up-frame-alist' (and - if we implement your
suggestion - `initial-frame-alist') are not affected by mode toggling.

martin

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

[Drew Adams]

> From: martin rudalics Sent: Saturday, January 03, 2009 2:14 AM
> `default-frame-alist' and `initial-frame-alist' are a mess 
> because these are customizable variables that should not be
> affected by toggling minor modes on and off.

Sorry for the late reply. I wanted to comment on this part, speaking more
generally and not just about these two variables. And I realize that Martin was
saying something particular - I'm not contradicting that.

I just want to say that it can be appropriate for a command, including a
minor-mode command, to change the value of a user option (customizable variable)
- e.g. toggle it. Obviously that happens for the mode variable itself, but that
is not the only case where this can be useful.

There is nothing wrong, in general, with a command or other code changing the
value of a user option, as long as the _documentation mentions_ this behavior.

There is even nothing wrong necessarily with a command saving the new option
value - provided the command's doc calls this out as part of the behavior.

Customize is not the only way to change or save option values, and it shouldn't
be regarded as such. The Customize UI is limited; other commands can offer
alternative, even improved, user interaction in some cases.

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

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

Chong, your

2008-10-09  Chong Yidong  <cyd@stupidchicken.com>

	* tool-bar.el (tool-bar-mode): Only change tool-bar-lines on
	graphical terminals.

change is inherently asymmetric with respect to future frames: Turning
`tool-bar-mode' off now adds an entry to `default-frame-alist' as before.
Turning it on now no more adds an entry.  IMHO, we should either not
call `modify-all-frames-parameters' in either case or call them in both
cases as in the (attached) tool-bar.el patch I proposed earlier.

martin

[-- Attachment #2: tool-bar.el.diff --]
[-- Type: text/plain, Size: 796 bytes --]

*** tool-bar.el.~1.23.~	2009-01-05 10:00:20.515625000 +0100
--- tool-bar.el	2009-01-09 20:09:59.421875000 +0100
***************
*** 54,62 ****
    :group 'frames
    (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)))))
--- 54,60 ----
    :group 'frames
    (if tool-bar-mode
        (progn
! 	(modify-all-frames-parameters (list (cons '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)))))

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

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> IMHO, we should either not call `modify-all-frames-parameters' in
> either case or call them in both cases as in the (attached)
> tool-bar.el patch I proposed earlier.

Patch looks OK; go ahead and install if you like.

bug#1754: marked as done (23.0.60; tool-bar is shown with tool-bar-mode off)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]


Your message dated Sat, 10 Jan 2009 11:09:41 +0100
with message-id <496873E5.9080601@gmx.at>
and subject line Re: bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off
has caused the Emacs bug report #1754,
regarding 23.0.60; tool-bar is shown with tool-bar-mode off
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
1754: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1754
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 4691 bytes --]

From: "Drew Adams" <drew.adams@oracle.com>
To: <emacs-pretest-bug@gnu.org>
Subject: 23.0.60; tool-bar is shown with tool-bar-mode off
Date: Wed, 31 Dec 2008 14:15:46 -0800
Message-ID: <005301c96b95$547ae890$c2b22382@us.oracle.com>

This is a regression wrt Emacs 20, 21, and 22.
 
1. Put this code in a file named `bug-tool-bar.el':
 
(tool-bar-mode -1)
(defvar my-minibuffer-frame nil "")
(defun foo () ""
  (interactive)
  (setq default-frame-alist
        (append (list (cons 'tool-bar-lines 1))
                default-frame-alist))
  (setq pop-up-frames      t
        pop-up-frame-alist (append default-frame-alist
                                   pop-up-frame-alist))
  (setq minibuffer-frame-alist
        (append (list (cons 'minibuffer 'only))
                minibuffer-frame-alist))
  (if my-minibuffer-frame
      (modify-frame-parameters my-minibuffer-frame
                               (list (cons 'minibuffer 'only)))
    (setq my-minibuffer-frame
          (let ((after-make-frame-functions nil))
            (make-frame (list (cons 'minibuffer 'only)))))))
 
It doesn't matter where the (tool-bar-mode -1) is, and you could
alternatively leave it out altogether and then do `M-x tool-bar-mode'
to turn it off (step 3).
 
2. Start Emacs this way:
 
runemacs.exe -Q --debug-init -l "bug-tool-bar.el" -f "foo"
 
You get one frame with buffer *scratch* and a standalone minibuffer
frame. Neither frame has a tool bar. However, `tool-bar-mode' is t -
it should be nil. You can see this by typing `tool-bar-mode' in buffer
*scratch* and using `C-x C-e'.
 
3. Optional step: `M-x tool-bar-mode'. This turns off tool-bar mode,
though it should already have been off because of the code in
`bug-tool-bar.el'.
 
4. Do `C-x 4 f some-file.el'. The file is visited in a new frame, and
the frame has a tool bar. And tool-bar mode is now on. And this is so
regardless of whether you skip step 3.

The mode should remain off, and no tool bar should be shown.
 

In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-12-30 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include
-fno-crossjumping'
 




[-- Attachment #3: Type: message/rfc822, Size: 1990 bytes --]

From: martin rudalics <rudalics@gmx.at>
To: 1754-done@emacsbugs.donarmstrong.com
Cc: Chong Yidong <cyd@stupidchicken.com>
Subject: Re: bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off
Date: Sat, 10 Jan 2009 11:09:41 +0100
Message-ID: <496873E5.9080601@gmx.at>

 >> IMHO, we should either not call `modify-all-frames-parameters' in
 >> either case or call them in both cases as in the (attached)
 >> tool-bar.el patch I proposed earlier.
 >
 > Patch looks OK; go ahead and install if you like.

Done.  Not that I liked it, but I'd rather find out now whether asking
for non-zero tool-bar-lines may cause problems on text-only terminals.

martin

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

[Chong Yidong]

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

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

[Drew Adams]

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

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

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

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

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.

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

[Drew Adams]

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

Yes, the cause of this is a faulty translation of `display-buffer' from C code
to Lisp - see my reply to Martin.

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

That place is apparently the new code for `display-buffer'.

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

[Jason Rumney]

Drew Adams wrote:

> The "pop-up" in each of the names `pop-up-frames' and `pop-up-frames-alist'
> means very different things.

It seems you are asking us to change Emacs to match your confusion at 
the expense of other users'.

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

[Drew Adams]

> > The "pop-up" in each of the names `pop-up-frames' and 
> > `pop-up-frames-alist' means very different things.
> 
> It seems you are asking us to change Emacs to match your confusion at 
> the expense of other users'.

Not at all. 

Read the description of `pop-up-frame-alist'. It talks about special "pop-up"
frames, and it gives examples of them. It is the analog of
`special-display-frame-alist'. Both "supercede the values given in
`default-frame-alist'.

Read the description of `pop-up-frames'. It is completely general and refers to
all frames. It is the analog of `pop-up-windows'. 

There is nothing new in this. Look at the C code for `display-buffer' in Emacs
22 (or 21 or 20). It does not refer to `pop-up-frame-alist' at all. It uses
`pop-up-frames' the same way it uses `pop-up-windows': to know whether to use a
separate frame (or window, in the latter case).

`pop-up-windows':
"Non-nil means `display-buffer' should make a new window."

`pop-up-frames':
"Whether `display-buffer' should make a separate frame."

Those have nothing to do with superceding the values in `default-frame-alist'.

I'm afraid you don't know what you're talking about on this question. Sad to
say, the person who translated `display-buffer' from C to Lisp might have been
in the same boat.

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

[Drew Adams]

> Read the description of `pop-up-frame-alist'. It talks about 
> special "pop-up" frames, and it gives examples of them. It is the
> analog of `special-display-frame-alist'. Both "supercede the
> values given in `default-frame-alist'.
> 
> Read the description of `pop-up-frames'. It is completely 
> general and refers to all frames. It is the analog of `pop-up-windows'. 
> 
> There is nothing new in this. Look at the C code for `display-buffer'
> in Emacs 22 (or 21 or 20). It does not refer to `pop-up-frame-alist' 
> at all. It uses `pop-up-frames' the same way it uses `pop-up-windows':
> to know whether to use a separate frame (or window, in the latter case).
> 
> `pop-up-windows':
> "Non-nil means `display-buffer' should make a new window."
> 
> `pop-up-frames':
> "Whether `display-buffer' should make a separate frame."
> 
> Those have nothing to do with superceding the values in 
> `default-frame-alist'.

I'm afraid it is I who was mistaken about this, not you. From the doc, I had the
impression that `pop-up-frame-alist' did not apply to all new frames opened,
that it applied only to special, "pop-up" frames. I've never used
`pop-up-frame-alist'.

But I see now that in Emacs 22 any frames opened by `display-buffer' (e.g. via
`C-x 5 f' or because `pop-up-frames' is non-nil) use the properties of
`pop-up-frame-alist', not `default-frame-alist'. 

My bad. It might be a good idea to mention in the doc of `pop-up-frame-alist'
the connection with `pop-up-frames' and `display-buffer'. Instead of speaking of
it being used when "creating pop-up frames" (undefined) and giving examples of
frames that are quite particular (completions, help), it would be better to
specifically mention `display-buffer' (and perhaps `pop-up-frames').

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

[Drew Adams]

I should have added that you can close this bug, and sorry for the noise.

I see now that I have let-bound `pop-up-frame-alist' in a couple other places in
code I wrote, so perhaps I knew the correct story at one time and forgot it.
Dunno.

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

[Jason Rumney]

Drew Adams wrote:
> I'm afraid it is I who was mistaken about this, not you. From the doc, I had the
> impression that `pop-up-frame-alist' did not apply to all new frames opened,
> that it applied only to special, "pop-up" frames. I've never used
> `pop-up-frame-alist'.
>   

I can see why you get that impression from the doc string of
pop-up-frame-alist. The second line is confusing - both in that the
mentioned buffers are not pop-up-frames by default, and that if
pop-up-frames is enabled, then there is no difference between the
mentioned buffers and any other buffer that displays in a pop-up frame.

The doc string should just say that pop-up-frame-alist applies to
pop-up-frames, which should also be obvious from the name. Trying to
explain pop-up-frames there (which I assume is what the intention of the
second line is) just confuses things.

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

[martin rudalics]

 > I can see why you get that impression from the doc string of
 > pop-up-frame-alist. The second line is confusing - both in that the
 > mentioned buffers are not pop-up-frames by default, and that if
 > pop-up-frames is enabled, then there is no difference between the
 > mentioned buffers and any other buffer that displays in a pop-up frame.
 >
 > The doc string should just say that pop-up-frame-alist applies to
 > pop-up-frames, which should also be obvious from the name. Trying to
 > explain pop-up-frames there (which I assume is what the intention of the
 > second line is) just confuses things.

I've just rewritten some doc-strings in frame.el.  Please have a look.

martin

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

[Jason Rumney]

Drew Adams wrote:
> Huh? Why is that the right thing? The default-frame-alist is set before turning
> off tool-bar-mode.

But you also set tool-bar-lines to 1 in popup-frame-alist, which 
overrides default-frame-alist for popup frames in any case.
tool-bar-mode may override settings in default-frame-alist, but it 
doesn't go any further than that, as the more specialized -frame-alist 
settings are probably more important than the global setting of 
tool-bar-mode.

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

[Drew Adams]

> > Huh? Why is that the right thing? The default-frame-alist 
> > is set before turning off tool-bar-mode.
> 
> But you also set tool-bar-lines to 1 in popup-frame-alist, which 
> overrides default-frame-alist for popup frames in any case.
> tool-bar-mode may override settings in default-frame-alist, but it 
> doesn't go any further than that, as the more specialized 
> -frame-alist settings are probably more important than the global
> setting of tool-bar-mode.

Absolutely not. The mode should affect all existing and future frames. That's
always been the case, and it is how other, similar modes, such as
`menu-bar-mode', work.

It has never been the case that some frame alist overrides the current mode
value.

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

[Jason Rumney]

Drew Adams wrote:
> Absolutely not. The mode should affect all existing and future frames. That's
> always been the case, and it is how other, similar modes, such as
> `menu-bar-mode', work.
>   

If that was the case, you would not be able to have minibuffer, ediff 
and speedbar frames without menu or toolbar if you were displaying those 
in other frames.
> It has never been the case that some frame alist overrides the current mode
> value.
>   

It always has been the case for me.

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

[Drew Adams]

> > Absolutely not. The mode should affect all existing and 
> > future frames. That's always been the case, and it is how other,
> > similar modes, such as `menu-bar-mode', work.
> >   
> 
> If that was the case, you would not be able to have minibuffer, ediff 
> and speedbar frames without menu or toolbar if you were 
> displaying those in other frames.

Of course you would. I do that myself. You do that by changing the frame
parameter for the given frame, not by using the global mode function
`menu-bar-mode' or `tool-bar-mode'. There is nothing new here - this is the way
it has always worked.

> > It has never been the case that some frame alist overrides 
> > the current mode value.
> 
> It always has been the case for me.

No, it has not. Try Emacs 22 (or 21 or 20). `M-x tool-bar-mode' and `M-x
menu-bar-mode' affect all existing and future frames. That doesn't mean you
can't tweak an individual frame, by changing its parameters. But those are
global commands. Always have been.

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

[grischka]

Jason Rumney wrote:
> But you also set tool-bar-lines to 1 in popup-frame-alist, which overrides
> default-frame-alist for popup frames in any case. tool-bar-mode may override
> settings in default-frame-alist, but it doesn't go any further than that, as
> the more specialized -frame-alist settings are probably more important than
> the global setting of tool-bar-mode.

Sorry, but "probably" is not a category that matters with binary logic like
whether something is "on" or "off".

In this case: As long as it is possible to make a new frame and that frame
does not have a toolbar and at the same time typing "M-: tool-bar-mode" in
that frame returns t,  there is something wrong with it. Not probably, but
definitely.

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

[Jason Rumney]

grischka wrote:
> Sorry, but "probably" is not a category that matters with binary logic 
> like
> whether something is "on" or "off".

Users' personal preferences and the various permutations of 
*-frame-alist are not binary logic.

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

[grischka]

Jason Rumney wrote:
> grischka wrote:
>> Sorry, but "probably" is not a category that matters with binary logic 
>> like whether something is "on" or "off".
> 
> Users' personal preferences and the various permutations of 
> *-frame-alist are not binary logic.
> 

Maybe users' preferences aren't binary but the ways to express them
towards the program are.  And the permutations performed by the
program are certainly binary too, that doesn't change by the fact that
they are maybe not well understood.