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.