From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: tool-bars - broken again Date: Mon, 5 Jul 2010 10:29:57 -0700 Message-ID: <5155443AC1FD4EF28DFB1F1BFFF412F1@us.oracle.com> References: <17A106BDF5AA40A9B41416AE7E8F13CB@us.oracle.com> <871vbk6w0m.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1278351029 26068 80.91.229.12 (5 Jul 2010 17:30:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 5 Jul 2010 17:30:29 +0000 (UTC) Cc: 'Emacs-Devel devel' To: "'Chong Yidong'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 05 19:30:27 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OVpUt-0006da-Rt for ged-emacs-devel@m.gmane.org; Mon, 05 Jul 2010 19:30:24 +0200 Original-Received: from localhost ([127.0.0.1]:44416 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OVpUt-0003kx-5b for ged-emacs-devel@m.gmane.org; Mon, 05 Jul 2010 13:30:23 -0400 Original-Received: from [140.186.70.92] (port=41121 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OVpUk-0003k3-QE for emacs-devel@gnu.org; Mon, 05 Jul 2010 13:30:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OVpUj-0004cy-9Q for emacs-devel@gnu.org; Mon, 05 Jul 2010 13:30:14 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:18319) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OVpUi-0004ck-Rk for emacs-devel@gnu.org; Mon, 05 Jul 2010 13:30:13 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o65HUA2c023407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Jul 2010 17:30:11 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o65HPjL8004649; Mon, 5 Jul 2010 17:30:09 GMT Original-Received: from abhmt010.oracle.com by acsmt354.oracle.com with ESMTP id 398767181278350994; Mon, 05 Jul 2010 10:29:54 -0700 Original-Received: from dradamslap1 (/10.175.252.105) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Jul 2010 10:29:54 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <871vbk6w0m.fsf@stupidchicken.com> Thread-Index: Acsa/v0R247y5ondRpSsZx+hMv5m/QAkC18g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Message-Flag: Follow up X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4C3216A1.013A:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:126789 Archived-At: > 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.