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