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.