From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off Date: Mon, 12 Jan 2009 13:59:18 -0800 Message-ID: <001301c97501$05f10b30$0ab32382@us.oracle.com> References: <005301c96b95$547ae890$c2b22382@us.oracle.com><495CE033.70808@gmx.at> <008801c96c57$dcbd5540$0200a8c0@us.oracle.com><495DC7A2.6000106@gmx.at><495F3A4B.2070802@gmx.at><4961BD57.9020202@gmx.at><4967A764.2070809@gmx.at><496872A2.2040404@gmx.at><4969D690.5090004@gmx.at><496A28FD.6090909@gmx.at><496B145C.2070104@gmx.at><496B690C.7070506@gmx.at> Reply-To: Drew Adams , 1754@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1231799316 9771 80.91.229.12 (12 Jan 2009 22:28:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Jan 2009 22:28:36 +0000 (UTC) To: "'Stefan Monnier'" , <1754@emacsbugs.donarmstrong.com>, "'martin rudalics'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 12 23:29:47 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LMVHw-0006vJ-3U for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Jan 2009 23:29:40 +0100 Original-Received: from localhost ([127.0.0.1]:45358 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LMVGe-00023E-QA for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Jan 2009 17:28:21 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LMVC1-0000wE-Fo for bug-gnu-emacs@gnu.org; Mon, 12 Jan 2009 17:23:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LMVBz-0000v0-2y for bug-gnu-emacs@gnu.org; Mon, 12 Jan 2009 17:23:31 -0500 Original-Received: from [199.232.76.173] (port=44640 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LMVBw-0000uV-Ox for bug-gnu-emacs@gnu.org; Mon, 12 Jan 2009 17:23:29 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:55828) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LMVBw-0000K8-0T for bug-gnu-emacs@gnu.org; Mon, 12 Jan 2009 17:23:28 -0500 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0CMNP7a032366; Mon, 12 Jan 2009 14:23:26 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n0CM55WE027516; Mon, 12 Jan 2009 14:05:05 -0800 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 12 Jan 2009 22:05:05 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 1754 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 1754-submit@emacsbugs.donarmstrong.com id=B1754.123179757525421 (code B ref 1754); Mon, 12 Jan 2009 22:05:05 +0000 Original-Received: (at 1754) by emacsbugs.donarmstrong.com; 12 Jan 2009 21:59:35 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0CLxVhV025413 for <1754@emacsbugs.donarmstrong.com>; Mon, 12 Jan 2009 13:59:32 -0800 Original-Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n0CLx4Hj000330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Jan 2009 21:59:05 GMT Original-Received: from acsmt706.oracle.com (acsmt706.oracle.com [141.146.40.84]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n0CLxxUn023080; Mon, 12 Jan 2009 22:00:02 GMT Original-Received: from dradamslap1 (/130.35.179.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Jan 2009 21:59:19 +0000 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acl05eEeHb8PlOWFTl+YfG5dFkQVDgAAXuiA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt706.oracle.com [141.146.40.84] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.496BBD3A.02F4:SCFSTAT928724,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Mon, 12 Jan 2009 17:23:31 -0500 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:24050 Archived-At: > >> 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).