tool-bars - broken again

tool-bars - broken again

[Drew Adams]

The latest Windows binary I have, from 6/28, breaks tool bars again.

GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-06-28 on 3249CTO

I see no problem with the previous Windows binary, from 6/21 (or prior).

I must say, and I am trying to be polite, that I am really getting tired of the
fiddling with the tool bars that has been going on for years now.  I try to have
code that works across versions.  You just won't leave it alone, it seems.

I'm sorry, but I cannot narrow this down better - I do not have a simple recipe.
In my startup code, I set `default-frame-alist' and I also turn off
`tool-bar-mode'.  Prior to the 6/28 build, the value of `tool-bar-lines' in
`default-frame-alist' was correctly set to 0 when my code turned off
`tool-bar-mode'; now it is not.

I don't know whether it was Yidong's recent change for bug #2249 that broke
things or whether it was changes to `tool-bar.el' during the same week
(6/21-6/28) that broke things - or whether those are in fact the same thing.

(BZR by HTTP is down, as usual ("Please try again..."), so I cannot track the
changes further.  I do not have the time for that anyway.
http://bazaar.launchpad.net/~vcs-imports/emacs/trunk/files/head%3A/lisp/)

This is the diff I see in tool-bar.el, that I think might be relevant.

6/28 build
----------

  :init-value t

  (let ((val (if tool-bar-mode 1 0)))
    (dolist (frame (frame-list))
      (set-frame-parameter frame 'tool-bar-lines val)))
  (when tool-bar-mode
    (if (= 1 (length (default-value 'tool-bar-map))) ; not yet setup
	(tool-bar-setup))))

6/21 build and prior
--------------------

  :init-value nil

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

(put 'tool-bar-mode 'standard-value '(t))


The big difference I see (but I'm no expert on this and I will not try to dig
deeper) is that previously we called `modify-all-frames-parameters', which sets
the `tool-bar-lines' setting also in `default-frames-alist' (and in
`initial-frame-alist').  Now we apparently set `tool-bar-lines' only for the
existing frames.

That alone might explain the breakage.  I have no idea whether changing the
:init-value and removing the `standard-value' setting might have something to do
with the breakage. 

Whatever the cause, the result is that although my startup code calls
`tool-bar-mode' to turn off the tool bar, all new frames (including the first
frame) are created with a tool bar.

Please, please fix this.  I spent hours today trying to figure out what's going
on (in my code), to no avail.  Please do not ask me to try to narrow things
further - I just don't have the time for this.  Thanks.

Re: tool-bars - broken again

[Chong Yidong]

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

> I must say, and I am trying to be polite, that I am really getting
> tired of the fiddling with the tool bars that has been going on for
> years now.  I try to have code that works across versions.  You just
> won't leave it alone, it seems.

No, we can't maintain cruft indefinitely.  The complicated interaction
between default-frame-alist and tool/menu bar mode needed simplifying.

The default value of `default-frame-alist' is now nil, unless you
explicitly set the value to something else.  It is a properly-behaved
defcustom (and so is `initial-frame-alist'); Emacs does not muck with
the value when starting up, nor when you run the `*-bar-mode' commands.

Conceptually, adding any element to `default-frame-alist' is like
implicitly supplying an argument to `make-frame'.  (Any actual argument
you supply to `make-frame' takes precedence over `default-frame-alist'.)

If no `tool-bar-lines' or `menu-bar-lines' parameter is supplied in the
`make-frame' arguments or `default-frame-alist', Emacs sets the value
from the value of `menu-bar-mode' and `tool-bar-mode'.


> In my startup code, I set `default-frame-alist' and I also turn off
> `tool-bar-mode'.  Prior to the 6/28 build, the value of
> `tool-bar-lines' in `default-frame-alist' was correctly set to 0 when
> my code turned off `tool-bar-mode'; now it is not.

You are likely setting a non-zero `tool-bar-lines' in
`default-frame-alist'.  I don't know why you would want to do this, if
your intention is to disable the tool bar.  As far as I can see, there
is no bug here.

RE: tool-bars - broken again

[Drew Adams]

> No, we can't maintain cruft indefinitely.  The complicated interaction
> between default-frame-alist and tool/menu bar mode needed simplifying.

That's a good idea; I applaud it, as a general (and vague) idea.

But the devil is in the details.  This tool-bar stuff has been "simplified" in
various ways over the years.  It seems it's always inviting further
simplification (I called it fiddling).  Today's simplification is tomorrow's
cruft.

> The default value of `default-frame-alist' is now nil, unless you
> explicitly set the value to something else.

That sounds OK to me.  (But it needs to be documented.)

The question is about the interaction between its value and `tool-bar-mode'.

Your change introduces incompatible behavior that should, at the very least, be
documented.  Emacs has previously always made command `tool-bar-mode' affect the
behavior of all new (as well as existing) frames, by changing
`default-frame-alist'.

> It is a properly-behaved defcustom (and so is `initial-frame-alist');
> Emacs does not muck with the value when starting up, nor when
> you run the `*-bar-mode' commands.

That was part of the purpose (design) of those commands: to affect
`default-frame-alist'.  What you call "mucking" was the designed behavior, not
an implementation bug.

The design was to have `tool-bar-mode' affect future frames via
`default-frame-alist' (as well as existing frames).  The state of future frames
was predictable from `default-frame-alist' and from `tool-bar-mode'.  The two
were intentionally always in sync.  No longer.

> If no `tool-bar-lines' or `menu-bar-lines' parameter is 
> supplied in the `make-frame' arguments or `default-frame-alist',
> Emacs sets the value from the value of `menu-bar-mode' and
> `tool-bar-mode'.

The incompatible (and misguided? - yes, it's only a question) change is wrt what
happens when `default-frame-alist' _does_ have a `tool-bar-lines' entry.

That entry now overrides `tool-bar-mode' - forever.  Only the
`default-frame-alist' setting, not command `tool-bar-mode', affects new frames.
This is an incompatible behavior change that affects both users interactively
and Lisp code.

Is it a good change?  I won't argue strongly either way.  I will argue that
because it is an incompatible change it requires (1) extra justification and (2)
clear documentation - about the incompatible change itself (NEWS), as well as
about the current behavior - the interaction between command and Custom setting
(INFO). 

> You are likely setting a non-zero `tool-bar-lines' in
> `default-frame-alist'.

Yes, I already said that.

> I don't know why you would want to do this, if your intention is to
> disable the tool bar.  As far as I can see, there is no bug here.

That is the crux of the matter.

Why would someone set `tool-bar-lines' in `default-frame-alist' and yet also at
some point call `tool-bar-mode' to turn off tool bars?  That seems to be the
point you have missed in moving toward this change.

You seem to have a somewhat simplistic notion of a user's intention wrt tool
bars.  And the same thing presumably follows for other frame parameters.

`default-frame-alist' embodies a user's intention wrt future frame _defaults_.
`tool-bar-mode' reflects a user's intention, at some moment in time, wrt
existing and future frames.  Those are not the same thing.

The former is a user option, which implies using Customize to change it.  The
latter is a command.  The former is typically set once and for all, at least for
a given Emacs session.  (But there is nothing preventing code and commands from
changing it during a session.)  The latter is intended to be usable quickly as a
toggle, at any time.

`default-frame-alist' is about defining a default set of frame parameters -
nothing more.  It's value at any point in time determines the state of future
frames.  `tool-bar-mode' is about changing, at some given moment, whether
existing frames and future frames show the tool bar.

Those are different purposes - you can (at least you used to be able to) use
them together, with each producing its own intended effect.  But the two work
together seamlessly (or they used to), each predicting and reflecting the same
frame state.

A user might well want the default frame setting to have a tool bar.  Yet s?he
might also, at some point during a session (or in some particular context, via
code), want to turn off tool bars - and not just for the current frames but also
for future frames.  And then later, in a different context, s?he might want to
turn tool bars back on again.

That seems to be the point that you are missing.

The user used to have a command that toggled tool bars (for future as well as
existing frames).  Now s?he must muck with `default-frame-alist' each time s?he
wants to affect future frames.

And it might be that the decision to turn off tool bars is made during startup
(load time), in a conditional way, by code rather than interactively.  IOW, both
actions might occur when a user loads his startup files:

1. Setting `default-frame-alist', including a `tool-bar-lines' entry, via
`custom-file' or some other file, and

2. Turning off/on tool bars via a call to `tool-bar-mode'.


Consider this:

emacs -Q -l foo.el  ; where `foo.el' contains:

(setq default-frame-alist  (append `((tool-bar-lines . 5))
                                   default-frame-alist))

(tool-bar-mode -99)

Do not ask why such code would or should be loaded.  It is not user error or
idiocy to invoke such code, including during startup.  Consider that the two
sexps are in separate libraries, in code that is invoked conditionally, during
loading of the user's startup files.  Use your imagination.

**Result**: the tool bar is showing (in all frames), in spite of the
`tool-bar-mode' invocation that turned off `tool-bar-mode'.  Tool bars have been
turned off, but they are in fact on.

Already, the user is confused.  S?he does not see this bizarre effect when s?he
loads the same code in other Emacs versions.  What else does s?he see?

(assq 'tool-bar-lines (frame-parameters))
 ; => (tool-bar-lines . 3)

(assq 'tool-bar-lines default-frame-alist)
 ; => (tool-bar-lines . 5)

Hmm...

C-h v tool-bar-mode ; => nil

C-x 5 2 ; => new frame has a tool bar, as do all new frames

M-x tool-bar-mode ; => enabled, even though already showing
M-x tool-bar-mode ; => disabled - removed from existing frames

C-x 5 2 ; => new frame has a tool bar, as do all new frames

IOW, Emacs considers `tool-bar-mode' to be disabled, but a tool bar is created
for each new frame.  In effect, command `tool-bar-mode' no longer affects future
frames but only existing frames.  Variable `tool-bar-mode' no longer reflects
the state of all frames.

The user is doubly confused now.  S?he now needs to toggle `tool-bar-mode'
_twice_ after each new frame is created if s?he wants no tool bar.

To turn off showing tool bars in future frames, s?he needs to change
`default-frame-alist'.  In previous Emacs versions, `tool-bar-mode' did that for
her; now, s?he must do it herself.  And if, later in the session, s?he wants to
show the tool bar again for new frames, s?he needs to change
`default-frame-alist' again.

There is now no command governing new frames; there is only user-mucking with
`default-frame-alist'.

Thanks for thinking this over.

---

FWIW, I myself have no problem adapting to this change:

1. I _never_ use a tool bar.  I encountered this problem because of code that I
provide for others, who might use a tool bar.

2. The fix needed for my code to accommodate your change is trivial - I just
added the guard `(< emacs-major-version 24)'.

IOW, this is not about me complaining that your change makes me jump through
hoops.  You've made a significant design change (not just a bug fix), and I
question the new design.

At the very least, this needs to be documented: both the new behavior and the
fact that there has been an (incompatible) design change.

Re: tool-bars - broken again

[Chong Yidong]

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

> A user might well want the default frame setting to have a tool bar.
> Yet s?he might also, at some point during a session (or in some
> particular context, via code), want to turn off tool bars - and not
> just for the current frames but also for future frames.  And then
> later, in a different context, s?he might want to turn tool bars back
> on again.

A convincing argument.  The solution is for `tool-bar-mode' and
`menu-bar-mode' to change `default-fame-alist' if, and only if, there is
an existing `tool-bar-lines' or `menu-bar-lines' entry.  I've checked in
such a change.

RE: tool-bars - broken again

[Drew Adams]

> > A user might well want the default frame setting to have a tool bar.
> > Yet s?he might also, at some point during a session (or in some
> > particular context, via code), want to turn off tool bars - and not
> > just for the current frames but also for future frames.  And then
> > later, in a different context, s?he might want to turn tool 
> > bars back on again.
> 
> A convincing argument.  The solution is for `tool-bar-mode' and
> `menu-bar-mode' to change `default-fame-alist' if, and only 
> if, there is an existing `tool-bar-lines' or `menu-bar-lines'
> entry.  I've checked in such a change.

Thank you.  That will definitely help.

But (without looking at your change) that does not handle the case where code or
a user command removes the entry from `default-frame-alist'.  Dunno how
important that use case is, but I can imagine it.

For that use case this would still be an incompatible change and should probably
be documented.  But your change sounds OK to me (haven't tried it).

In general (other things being equal etc.), it is good to keep the property that
a missing `default-frame-alist' entry acts the same as an entry that holds the
default value or a neutral value (for some sense of "neutral").

In this case, an entry of `(tool-bar-lines . 0)' would not be equivalent to a
missing entry.  Sometimes the behavior would be the same, and sometimes it would
be different.  That in itself is not a good thing, but other considerations
might override the value of retaining this equivalence property in this case.

Again, what you describe sounds OK by me.  But please document the design
intention with comments in the code (e.g. the bug #, if the bug thread discusses
the design change) and wrt Info and doc strings etc.