* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off @ 2008-12-31 22:15 ` Drew Adams 2009-01-01 15:24 ` martin rudalics ` (2 more replies) 0 siblings, 3 replies; 52+ messages in thread From: Drew Adams @ 2008-12-31 22:15 UTC (permalink / raw) To: emacs-pretest-bug This is a regression wrt Emacs 20, 21, and 22. 1. Put this code in a file named `bug-tool-bar.el': (tool-bar-mode -1) (defvar my-minibuffer-frame nil "") (defun foo () "" (interactive) (setq default-frame-alist (append (list (cons 'tool-bar-lines 1)) default-frame-alist)) (setq pop-up-frames t pop-up-frame-alist (append default-frame-alist pop-up-frame-alist)) (setq minibuffer-frame-alist (append (list (cons 'minibuffer 'only)) minibuffer-frame-alist)) (if my-minibuffer-frame (modify-frame-parameters my-minibuffer-frame (list (cons 'minibuffer 'only))) (setq my-minibuffer-frame (let ((after-make-frame-functions nil)) (make-frame (list (cons 'minibuffer 'only))))))) It doesn't matter where the (tool-bar-mode -1) is, and you could alternatively leave it out altogether and then do `M-x tool-bar-mode' to turn it off (step 3). 2. Start Emacs this way: runemacs.exe -Q --debug-init -l "bug-tool-bar.el" -f "foo" You get one frame with buffer *scratch* and a standalone minibuffer frame. Neither frame has a tool bar. However, `tool-bar-mode' is t - it should be nil. You can see this by typing `tool-bar-mode' in buffer *scratch* and using `C-x C-e'. 3. Optional step: `M-x tool-bar-mode'. This turns off tool-bar mode, though it should already have been off because of the code in `bug-tool-bar.el'. 4. Do `C-x 4 f some-file.el'. The file is visited in a new frame, and the frame has a tool bar. And tool-bar mode is now on. And this is so regardless of whether you skip step 3. The mode should remain off, and no tool bar should be shown. In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-12-30 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2008-12-31 22:15 ` bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off Drew Adams @ 2009-01-01 15:24 ` martin rudalics 2009-01-01 15:53 ` Jason Rumney 2009-01-01 21:28 ` Drew Adams 2009-01-09 19:37 ` martin rudalics 2009-01-10 10:20 ` bug#1754: marked as done (23.0.60; tool-bar is shown with tool-bar-mode off) Emacs bug Tracking System 2 siblings, 2 replies; 52+ messages in thread From: martin rudalics @ 2009-01-01 15:24 UTC (permalink / raw) To: Drew Adams; +Cc: 1754 [-- Attachment #1: Type: text/plain, Size: 1670 bytes --] > (tool-bar-mode -1) [...] > (setq default-frame-alist > (append (list (cons 'tool-bar-lines 1)) > default-frame-alist)) Inherently, you're painting yourself into a corner by simultaneously demanding and rejecting toolbars. Moreover, that last assignment gets you a second entry for `tool-bar-lines' in `default-frame-alist' (and we have received _lots_ of mails from you complaining about such duplicate entries before). However, you do _not_ set `initial-frame-alist' simultaneously, so you won't get a toolbar for the first frame which is the correct behavior since you have toggled tool-bar-mode off before and only that counts for the initial frame (unless you explicitly override it). Since `default-frame-alist' contains a tool-bar-lines entry you will get a toolbar for future frames which is correct as well. That said, the behavior of Emacs _is_ wrong because it should not say that `tool-bar-mode' is on when there are no toolbars. The reason is that `tool-bar-mode' does (if tool-bar-mode (progn (dolist (frame (frame-list)) (if (display-graphic-p frame) (set-frame-parameter frame '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))))) so you can easily see that for turning `tool-bar-mode' off, default and initial frame parameters are set. For turning it on, only the parameters of the existing frames are set and _no_ default or initial parameters. Since the `display-graphic-p' test is not useful anyway, I propose the attached patch. Yours truly, martin. [-- Attachment #2: tool-bar.diff --] [-- Type: text/plain, Size: 796 bytes --] *** tool-bar.el.~1.22.~ 2008-11-27 07:43:19.062500000 +0100 --- tool-bar.el 2009-01-01 16:20:25.968750000 +0100 *************** *** 54,62 **** :group 'frames (if tool-bar-mode (progn ! (dolist (frame (frame-list)) ! (if (display-graphic-p frame) ! (set-frame-parameter frame '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))))) --- 54,60 ---- :group 'frames (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))))) ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-01 15:24 ` martin rudalics @ 2009-01-01 15:53 ` Jason Rumney 2009-01-01 16:09 ` martin rudalics 2009-01-01 21:28 ` Drew Adams 1 sibling, 1 reply; 52+ messages in thread From: Jason Rumney @ 2009-01-01 15:53 UTC (permalink / raw) To: martin rudalics, 1754 martin rudalics wrote: > Since the `display-graphic-p' test is not useful anyway What makes you say that? Is it already tested before we get to this point? ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-01 15:53 ` Jason Rumney @ 2009-01-01 16:09 ` martin rudalics 0 siblings, 0 replies; 52+ messages in thread From: martin rudalics @ 2009-01-01 16:09 UTC (permalink / raw) To: Jason Rumney; +Cc: 1754 >> Since the `display-graphic-p' test is not useful anyway > > What makes you say that? Is it already tested before we get to this point? No one hinders people to call `modify-all-frames-parameters' with tool-bar-lines 1. So if we really have to check this, we have to do it in `modify-frame-parameters'. Doing it just in `tool-bar-mode' is not sufficient. martin ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-01 15:24 ` martin rudalics 2009-01-01 15:53 ` Jason Rumney @ 2009-01-01 21:28 ` Drew Adams 2009-01-01 21:51 ` Drew Adams 2009-01-02 7:52 ` martin rudalics 1 sibling, 2 replies; 52+ messages in thread From: Drew Adams @ 2009-01-01 21:28 UTC (permalink / raw) To: 'martin rudalics'; +Cc: 1754 > > (tool-bar-mode -1) > [...] > > (setq default-frame-alist > > (append (list (cons 'tool-bar-lines 1)) > > default-frame-alist)) > > Inherently, you're painting yourself into a corner by simultaneously > demanding and rejecting toolbars. Moreover, that last assignment gets > you a second entry for `tool-bar-lines' in > `default-frame-alist' (and we have received _lots_ of mails > from you complaining about such duplicate entries before). No, as a result of those "_lots_ of mails" I sent, that bug was finally fixed. No duplicate entries are created by Emacs since 2008-12-31. However, you are correct that the code above creates a second entry for `tool-bar-lines'. That should not be a problem - the first entry is used (it is an alist, after all). That is, there is no corner. The latest change to the parameter `tool-bar-lines' should _always_ prevail - regardless of whether you use `modify-frame-parameters' or (setq default-frame-alist...) or you call `tool-bar-mode'. The problem is, I'm thinking now, that the entry (tool-bar-lines . 1) in `pop-up-frames-alist' is being used for the creation of new frames when `pop-up-frames' is non-nil. If that is happening, it is incorrect behavior, on two counts: 1. `tool-bar-mode' should be modal and affect all existing and subsequent frames, regardless of their default alist (`special-display-frame-alist', `pop-up-frame-alist', or `default-frame-alist'). 2. `pop-up-frame-alist' should not be used for creating normal new frames. The "pop-up" in each of the names `pop-up-frames' and `pop-up-frames-alist' means very different things. `pop-up-frames-alist' is not about creating normal new frames - `default-frame-alist' should be used for that. And `pop-up-frames' simply changes things like `C-x 4 f' to act like `C-x 5 f' - it has nothing to do with popup frames. `pop-up-frames-alist' is about special, "popup" frames (which is why it is a separate alist, like `special-display-frame-alist'): "Alist of frame parameters used when creating pop-up frames. Pop-up frames are used for completions, help, and the like. This variable can be set in your init file, like this: (setq pop-up-frame-alist '((width . 80) (height . 20))) These supersede the values given in `default-frame-alist', for pop-up frames." > However, you do _not_ set `initial-frame-alist' simultaneously, > so you won't get a toolbar for the first frame which is the > correct behavior since you have toggled tool-bar-mode off > before and only that counts for the initial frame (unless you > explicitly override it). Since `default-frame-alist' contains > a tool-bar-lines entry you will get a toolbar for future frames > which is correct as well. Sorry, all of that text is irrelevant to my bug report. I am not concerned about the initial frame. > That said, the behavior of Emacs _is_ wrong because it should not say > that `tool-bar-mode' is on when there are no toolbars. More importantly, if you turn the mode off, new frames should also not have tool bars. That is the point here. > The reason is that `tool-bar-mode' does > > (if tool-bar-mode > (progn > (dolist (frame (frame-list)) > (if (display-graphic-p frame) > (set-frame-parameter frame '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))))) > > so you can easily see that for turning `tool-bar-mode' off, > default and initial frame parameters are set. For turning it on, only the > parameters of the existing frames are set and _no_ default or initial > parameters. That might be at least partly responsible for the bug. Again, the current bugged behavior: 1. is a regression - the behavior was correct in Emacs 22 2. does not correspond to the behavior of `menu-bar-mode', which is correct in Emacs 23, like 22 > Since the `display-graphic-p' test is not useful > anyway, I propose the attached patch. I think the logic of your patch is needed, but it is not sufficient. I tried your patch (by just redefining tool-bar-mode after running my test case), but it unfortunately does not seem to fix the problem. I suspect the remaining problem is as I indicated above: `pop-up-frame-alist' is being used when it shouldn't be used - to open normal frames (not popup frames). The Emacs 22.3 code works fine in all regards. ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-01 21:28 ` Drew Adams @ 2009-01-01 21:51 ` Drew Adams 2009-01-02 7:52 ` martin rudalics 2009-01-02 7:52 ` martin rudalics 1 sibling, 1 reply; 52+ messages in thread From: Drew Adams @ 2009-01-01 21:51 UTC (permalink / raw) To: 1754, 'martin rudalics' > The problem is, I'm thinking now, that the entry > (tool-bar-lines . 1) in > `pop-up-frames-alist' is being used for the creation of new > frames when > `pop-up-frames' is non-nil. If that is happening, it is > incorrect behavior, on > two counts: > > 1. `tool-bar-mode' should be modal and affect all existing > and subsequent frames, regardless of their default alist > (`special-display-frame-alist', `pop-up-frame-alist', or > `default-frame-alist'). > > 2. `pop-up-frame-alist' should not be used for creating > normal new frames. > > The "pop-up" in each of the names `pop-up-frames' and > `pop-up-frames-alist' means very different things. > `pop-up-frames-alist' is not about creating normal > new frames - `default-frame-alist' should be used for that. > And `pop-up-frames' simply changes things like `C-x 4 f' > to act like `C-x 5 f' - it has nothing to do with popup frames. > > `pop-up-frames-alist' is about special, "popup" frames (which > is why it is a separate alist, like `special-display-frame-alist'): > > "Alist of frame parameters used when creating pop-up frames. > Pop-up frames are used for completions, help, and the like. > This variable can be set in your init file, like this: > (setq pop-up-frame-alist '((width . 80) (height . 20))) > These supersede the values given in `default-frame-alist', > for pop-up frames." I think the bug was introduced when someone translated the C code definition of `display-buffer' to Lisp. This code was added gratuitously, and it causes `pop-up-frames' to use `pop-up-frame-alist': (let... ;; On text-only terminals do not pop up a new frame when ;; `pop-up-frames' equals graphic-only. (use-pop-up-frames (if (eq pop-up-frames 'graphic-only) (display-graphic-p) pop-up-frames)) `pop-up-frames' being non-nil should in no way cause `C-x 5 b' etc. to use `pop-up-frame-alist' for the new frame creation. ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-01 21:51 ` Drew Adams @ 2009-01-02 7:52 ` martin rudalics 0 siblings, 0 replies; 52+ messages in thread From: martin rudalics @ 2009-01-02 7:52 UTC (permalink / raw) To: Drew Adams; +Cc: 1754 >> 1. `tool-bar-mode' should be modal and affect all existing >> and subsequent frames, regardless of their default alist >> (`special-display-frame-alist', `pop-up-frame-alist', or >> `default-frame-alist'). Then why do you specify such alist entries in the first place? >> 2. `pop-up-frame-alist' should not be used for creating >> normal new frames. [...] >> "Alist of frame parameters used when creating pop-up frames. >> Pop-up frames are used for completions, help, and the like. >> This variable can be set in your init file, like this: >> (setq pop-up-frame-alist '((width . 80) (height . 20))) >> These supersede the values given in `default-frame-alist', >> for pop-up frames." I shall clean up the docstring of `pop-up-frame-alist' to make clear that it _is_ used for creating normal new frames. > I think the bug was introduced when someone translated the C code definition of > `display-buffer' to Lisp. That someone was me and the bugs I introduced caused continuous crashes of Emacs and many finance markets all over the world. Let's hope for a change then ... martin ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-01 21:28 ` Drew Adams 2009-01-01 21:51 ` Drew Adams @ 2009-01-02 7:52 ` martin rudalics 2009-01-03 3:12 ` Stefan Monnier 1 sibling, 1 reply; 52+ messages in thread From: martin rudalics @ 2009-01-02 7:52 UTC (permalink / raw) To: Drew Adams; +Cc: 1754 >> > (tool-bar-mode -1) >> [...] >> > (setq default-frame-alist >> > (append (list (cons 'tool-bar-lines 1)) >> > default-frame-alist)) >> >> Inherently, you're painting yourself into a corner by simultaneously >> demanding and rejecting toolbars. Moreover, that last assignment gets >> you a second entry for `tool-bar-lines' in >> `default-frame-alist' (and we have received _lots_ of mails >> from you complaining about such duplicate entries before). > > No, as a result of those "_lots_ of mails" I sent, that bug was finally fixed. > No duplicate entries are created by Emacs since 2008-12-31. > > However, you are correct that the code above creates a second entry for > `tool-bar-lines'. That should not be a problem - the first entry is used (it is > an alist, after all). You mean what's good for you is not good for Emacs? > That is, there is no corner. There is. You want toolbars and eat them too. > The latest change to the > parameter `tool-bar-lines' should _always_ prevail - regardless of whether you > use `modify-frame-parameters' or (setq default-frame-alist...) or you call > `tool-bar-mode'. What makes you think it doesn't? > The problem is, I'm thinking now, that the entry (tool-bar-lines . 1) in > `pop-up-frames-alist' is being used for the creation of new frames when > `pop-up-frames' is non-nil. If that is happening, it is incorrect behavior, on > two counts: > > 1. `tool-bar-mode' should be modal and affect all existing and subsequent > frames, regardless of their default alist (`special-display-frame-alist', > `pop-up-frame-alist', or `default-frame-alist'). > > 2. `pop-up-frame-alist' should not be used for creating normal new frames. As Drew uses to say "the Elisp manual is your friend": -- User Option: pop-up-frame-alist This variable holds an alist specifying frame parameters used when `display-buffer' makes a new frame. *Note Frame Parameters::, for more information about frame parameters. >> However, you do _not_ set `initial-frame-alist' simultaneously, >> so you won't get a toolbar for the first frame which is the >> correct behavior since you have toggled tool-bar-mode off >> before and only that counts for the initial frame (unless you >> explicitly override it). Since `default-frame-alist' contains >> a tool-bar-lines entry you will get a toolbar for future frames >> which is correct as well. > > Sorry, all of that text is irrelevant to my bug report. I am not concerned about > the initial frame. You should be. Unfortunately, you are not concerned about reading what I write either. So here we go again: When you do (tool-bar-mode -1) you also create a (tool-bar-lines . 0) entry for _both_ `initial-frame-alist' and `default-frame-alist'. When you do (setq default-frame-alist (append (list (cons 'tool-bar-lines 1)) default-frame-alist)) you override the (tool-bar-lines . 0) by a (tool-bar-lines . 1) entry _for the default frame only_. However, the initial frame will continue to have the (tool-bar-lines . 0) entry you created earlier. So the initial frame won't have a toolbar, subsequently created frames will. > More importantly, if you turn the mode off, new frames should also not have tool > bars. That is the point here. When you set tool-bar-lines to 1 in `default-frame-alist' the way you do, new frames will have a toolbar. > I tried your patch (by just redefining tool-bar-mode after running my test > case), but it unfortunately does not seem to fix the problem. I suspect the > remaining problem is as I indicated above: `pop-up-frame-alist' is being used > when it shouldn't be used - to open normal frames (not popup frames). Even if you were right about this one, the (tool-bar-lines . 1) entry in `default-frame-alist' would continue to produce toolbars for new frames. martin ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-02 7:52 ` martin rudalics @ 2009-01-03 3:12 ` Stefan Monnier 2009-01-03 10:13 ` martin rudalics 0 siblings, 1 reply; 52+ messages in thread From: Stefan Monnier @ 2009-01-03 3:12 UTC (permalink / raw) To: martin rudalics; +Cc: 1754 > When you do > (tool-bar-mode -1) > you also create a (tool-bar-lines . 0) entry for _both_ > `initial-frame-alist' and `default-frame-alist'. When you do Makes me wonder: why does it set it in initial-frame-alist since that alist is always combined with default-frame-alist? Stefan ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-03 3:12 ` Stefan Monnier @ 2009-01-03 10:13 ` martin rudalics 2009-01-05 4:10 ` Stefan Monnier 2009-01-17 18:33 ` Drew Adams 0 siblings, 2 replies; 52+ messages in thread From: martin rudalics @ 2009-01-03 10:13 UTC (permalink / raw) To: Stefan Monnier; +Cc: 1754 >> you also create a (tool-bar-lines . 0) entry for _both_ >> `initial-frame-alist' and `default-frame-alist'. When you do > > Makes me wonder: why does it set it in initial-frame-alist since that > alist is always combined with default-frame-alist? If you mean that `modify-all-frames-parameters' should not change `initial-frame-alist' because the "right" value will be eventually found when scanning `default-frame-alist', you're maybe right. OTOH a user may have set `initial-frame-alist' to contain a tool-bar-lines entry and wants to explicitly turn off `tool-bar-mode' for the initial frame. Consider Drew's example with "initial" replacing "default". `default-frame-alist' and `initial-frame-alist' are a mess because these are customizable variables that should not be affected by toggling minor modes on and off. I think it's only confusing to have (at least) three .emacs ways to specify whether an initial frame should show a toolbar. martin ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-03 10:13 ` martin rudalics @ 2009-01-05 4:10 ` Stefan Monnier 2009-01-05 7:57 ` martin rudalics 2009-01-17 18:33 ` Drew Adams 1 sibling, 1 reply; 52+ messages in thread From: Stefan Monnier @ 2009-01-05 4:10 UTC (permalink / raw) To: martin rudalics; +Cc: 1754 >>> you also create a (tool-bar-lines . 0) entry for _both_ >>> `initial-frame-alist' and `default-frame-alist'. When you do >> Makes me wonder: why does it set it in initial-frame-alist since that >> alist is always combined with default-frame-alist? > If you mean that `modify-all-frames-parameters' should not change > `initial-frame-alist' because the "right" value will be eventually found > when scanning `default-frame-alist', you're maybe right. Yes, I think that's what I mean. > OTOH a user may have set `initial-frame-alist' to contain > a tool-bar-lines entry and wants to explicitly turn off > `tool-bar-mode' for the initial frame. Consider Drew's example with > "initial" replacing "default". But modify-all-frames-parameters beings by removing any such setting in initial-frame-alist anyway, so it seems this case still doesn't justify adding the setting to initial-frame-alist. Stefan ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-05 4:10 ` Stefan Monnier @ 2009-01-05 7:57 ` martin rudalics 2009-01-05 22:20 ` Stefan Monnier 0 siblings, 1 reply; 52+ messages in thread From: martin rudalics @ 2009-01-05 7:57 UTC (permalink / raw) To: Stefan Monnier; +Cc: 1754 >> If you mean that `modify-all-frames-parameters' should not change >> `initial-frame-alist' because the "right" value will be eventually found >> when scanning `default-frame-alist', you're maybe right. > > Yes, I think that's what I mean. > >> OTOH a user may have set `initial-frame-alist' to contain >> a tool-bar-lines entry and wants to explicitly turn off >> `tool-bar-mode' for the initial frame. Consider Drew's example with >> "initial" replacing "default". > > But modify-all-frames-parameters beings by removing any such setting in > initial-frame-alist anyway, so it seems this case still doesn't justify > adding the setting to initial-frame-alist. On the one hand you mean that `modify-all-frames-parameters' should not change `initial-frame-alist' on the other you mean it should remove such setting in `initial-frame-alist' anyway? You leave me confused. martin ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-05 7:57 ` martin rudalics @ 2009-01-05 22:20 ` Stefan Monnier 2009-01-06 13:37 ` martin rudalics 2009-01-09 19:37 ` martin rudalics 0 siblings, 2 replies; 52+ messages in thread From: Stefan Monnier @ 2009-01-05 22:20 UTC (permalink / raw) To: martin rudalics; +Cc: 1754 >>> If you mean that `modify-all-frames-parameters' should not change >>> `initial-frame-alist' because the "right" value will be eventually found >>> when scanning `default-frame-alist', you're maybe right. >> >> Yes, I think that's what I mean. >> >>> OTOH a user may have set `initial-frame-alist' to contain >>> a tool-bar-lines entry and wants to explicitly turn off >>> `tool-bar-mode' for the initial frame. Consider Drew's example with >>> "initial" replacing "default". >> >> But modify-all-frames-parameters beings by removing any such setting in >> initial-frame-alist anyway, so it seems this case still doesn't justify >> adding the setting to initial-frame-alist. > On the one hand you mean that `modify-all-frames-parameters' should not > change `initial-frame-alist' on the other you mean it should remove such > setting in `initial-frame-alist' anyway? You leave me confused. No, I only said that it shouldn't *set* the value in initial-frame-alist. Of course, it needs to remove any previous setting in order for the setting in default-frame-alist not to be overridden. Stefan ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-05 22:20 ` Stefan Monnier @ 2009-01-06 13:37 ` martin rudalics 2009-01-09 19:37 ` martin rudalics 1 sibling, 0 replies; 52+ messages in thread From: martin rudalics @ 2009-01-06 13:37 UTC (permalink / raw) To: Stefan Monnier; +Cc: 1754 > No, I only said that it shouldn't *set* the value in > initial-frame-alist. Of course, it needs to remove any previous setting > in order for the setting in default-frame-alist not to be overridden. To summarize, assigning parameters for the initial frame takes values in increasing order of priority from (1) `frame-initial-frame-alist' which has all the resource and command line settings incorporated as well as everything that has been done via (modify-frame-parameters nil ...) while reading .emacs, (2) `default-frame-alist' which merges all implicit `tool-bar-mode', `scroll-bar-mode', ... with explicit (setq default-frame-alist ...), `modify-all-frames-parameters', ... assignments, and (3) `initial-frame-alist' which may contain only entries obtained via (setq initial-frame-alist ...) since `modify-all-frames-parameters' does not operate on that list. or am I missing something? martin ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-05 22:20 ` Stefan Monnier 2009-01-06 13:37 ` martin rudalics @ 2009-01-09 19:37 ` martin rudalics 2009-01-10 2:29 ` Stefan Monnier 1 sibling, 1 reply; 52+ messages in thread From: martin rudalics @ 2009-01-09 19:37 UTC (permalink / raw) To: Stefan Monnier; +Cc: 1754 [-- Attachment #1: Type: text/plain, Size: 251 bytes --] > No, I only said that it shouldn't *set* the value in > initial-frame-alist. Of course, it needs to remove any previous setting > in order for the setting in default-frame-alist not to be overridden. So shall I apply the attached patch? martin [-- Attachment #2: frame.el.diff --] [-- Type: text/plain, Size: 942 bytes --] *** frame.el.~1.291.~ 2009-01-05 09:58:26.812500000 +0100 --- frame.el 2009-01-09 20:09:15.750000000 +0100 *************** *** 593,600 **** (dolist (w window-system-default-frame-alist) (setcdr w (assq-delete-all (car pair) (cdr w))))) ! (and frame-notice-user-settings ! (setq initial-frame-alist (append initial-frame-alist alist))) (setq default-frame-alist (append default-frame-alist alist))) (defun get-other-frame () --- 593,602 ---- (dolist (w window-system-default-frame-alist) (setcdr w (assq-delete-all (car pair) (cdr w))))) ! ;; There's no need to set the value in initial-frame-alist since ! ;; frame-notice-user-settings will take it from default-frame-alist. ! ;; (and frame-notice-user-settings ! ;; (setq initial-frame-alist (append initial-frame-alist alist))) (setq default-frame-alist (append default-frame-alist alist))) (defun get-other-frame () ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-09 19:37 ` martin rudalics @ 2009-01-10 2:29 ` Stefan Monnier 2009-01-10 10:04 ` martin rudalics 0 siblings, 1 reply; 52+ messages in thread From: Stefan Monnier @ 2009-01-10 2:29 UTC (permalink / raw) To: martin rudalics; +Cc: 1754 >> No, I only said that it shouldn't *set* the value in >> initial-frame-alist. Of course, it needs to remove any previous setting >> in order for the setting in default-frame-alist not to be overridden. > So shall I apply the attached patch? I don't know: that was basically my question. Stefan > *** frame.el.~1.291.~ 2009-01-05 09:58:26.812500000 +0100 > --- frame.el 2009-01-09 20:09:15.750000000 +0100 > *************** > *** 593,600 **** > (dolist (w window-system-default-frame-alist) > (setcdr w (assq-delete-all (car pair) (cdr w))))) > ! (and frame-notice-user-settings > ! (setq initial-frame-alist (append initial-frame-alist alist))) > (setq default-frame-alist (append default-frame-alist alist))) > (defun get-other-frame () > --- 593,602 ---- > (dolist (w window-system-default-frame-alist) > (setcdr w (assq-delete-all (car pair) (cdr w))))) > ! ;; There's no need to set the value in initial-frame-alist since > ! ;; frame-notice-user-settings will take it from default-frame-alist. > ! ;; (and frame-notice-user-settings > ! ;; (setq initial-frame-alist (append initial-frame-alist alist))) > (setq default-frame-alist (append default-frame-alist alist))) > (defun get-other-frame () ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-10 2:29 ` Stefan Monnier @ 2009-01-10 10:04 ` martin rudalics 2009-01-10 22:38 ` Stefan Monnier 0 siblings, 1 reply; 52+ messages in thread From: martin rudalics @ 2009-01-10 10:04 UTC (permalink / raw) To: Stefan Monnier; +Cc: 1754 >> So shall I apply the attached patch? > > I don't know: that was basically my question. Then I won't. It's not that much of an optimization. martin ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-10 10:04 ` martin rudalics @ 2009-01-10 22:38 ` Stefan Monnier 2009-01-11 11:22 ` martin rudalics 0 siblings, 1 reply; 52+ messages in thread From: Stefan Monnier @ 2009-01-10 22:38 UTC (permalink / raw) To: martin rudalics; +Cc: 1754 >>> So shall I apply the attached patch? >> I don't know: that was basically my question. > Then I won't. It's not that much of an optimization. It's not a question of optimization but of semantics. It seems cleaner to only add the setting to default-frame-alist if that's possible. Which is why I asked for a reason wy it's also added to initial-frame-alist even tho it doesn't seem necessary. Stefan ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-10 22:38 ` Stefan Monnier @ 2009-01-11 11:22 ` martin rudalics 2009-01-11 14:56 ` Stefan Monnier 0 siblings, 1 reply; 52+ messages in thread From: martin rudalics @ 2009-01-11 11:22 UTC (permalink / raw) To: Stefan Monnier; +Cc: 1754 > It's not a question of optimization but of semantics. > It seems cleaner to only add the setting to default-frame-alist if > that's possible. Which is why I asked for a reason wy it's also added > to initial-frame-alist even tho it doesn't seem necessary. When the .emacs reader encounters the form (modify-all-frames-parameters (list (cons 'tool-bar-lines 1))) it will map both initial-frame-alist and default-frame-alist to an alist containing a (tool-bar-lines . 1) entry. If it then encounters the form (setq default-frame-alist (append (list (cons 'tool-bar-lines 0)) default-frame-alist)) it adds to default-frame-alist a (tool-bar-lines . 0) entry shadowing the (tool-bar-lines . 1) entry. With current Emacs, the initial frame will probably have a tool bar. If we "only add the setting to default-frame-alist", the initial frame likely will not have a tool bar. Hence, applying the change we're talking about can change the meaning of a valid .emacs file for some value of validity. But I suppose you know that. Alas, I don't know what kind of semantics you have in mind :-( martin ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-11 11:22 ` martin rudalics @ 2009-01-11 14:56 ` Stefan Monnier 2009-01-11 17:14 ` martin rudalics 0 siblings, 1 reply; 52+ messages in thread From: Stefan Monnier @ 2009-01-11 14:56 UTC (permalink / raw) To: martin rudalics; +Cc: 1754 >>>>> "martin" == martin rudalics <rudalics@gmx.at> writes: >> It's not a question of optimization but of semantics. >> It seems cleaner to only add the setting to default-frame-alist if >> that's possible. Which is why I asked for a reason wy it's also added >> to initial-frame-alist even tho it doesn't seem necessary. > When the .emacs reader encounters the form > (modify-all-frames-parameters (list (cons 'tool-bar-lines 1))) > (setq default-frame-alist > (append (list (cons 'tool-bar-lines 0)) > default-frame-alist)) The above two forms don't mention anything special about the initial-frame, so I think that it's a bug if Emacs treats the initial frame differently in this case. Stefan ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-11 14:56 ` Stefan Monnier @ 2009-01-11 17:14 ` martin rudalics 2009-01-11 23:12 ` Stefan Monnier 0 siblings, 1 reply; 52+ messages in thread From: martin rudalics @ 2009-01-11 17:14 UTC (permalink / raw) To: Stefan Monnier; +Cc: 1754 >> When the .emacs reader encounters the form > >> (modify-all-frames-parameters (list (cons 'tool-bar-lines 1))) > >> (setq default-frame-alist >> (append (list (cons 'tool-bar-lines 0)) >> default-frame-alist)) > > The above two forms don't mention anything special about the > initial-frame, so I think that it's a bug if Emacs treats the initial > frame differently in this case. Maybe. We'd also have to cater for `window-system-default-frame-alist' which currently overrides values from `default-frame-alist' but not those of `initial-frame-alist'. That is, `modify-all-frames-parameters' currently overrides a setting in `window-system-default-frame-alist'. martin ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-11 17:14 ` martin rudalics @ 2009-01-11 23:12 ` Stefan Monnier 2009-01-12 9:58 ` martin rudalics 0 siblings, 1 reply; 52+ messages in thread From: Stefan Monnier @ 2009-01-11 23:12 UTC (permalink / raw) To: martin rudalics; +Cc: 1754 >>> When the .emacs reader encounters the form >>> (modify-all-frames-parameters (list (cons 'tool-bar-lines 1))) >>> (setq default-frame-alist >>> (append (list (cons 'tool-bar-lines 0)) >>> default-frame-alist)) >> >> The above two forms don't mention anything special about the >> initial-frame, so I think that it's a bug if Emacs treats the initial >> frame differently in this case. > Maybe. We'd also have to cater for `window-system-default-frame-alist' > which currently overrides values from `default-frame-alist' but not > those of `initial-frame-alist'. That is, `modify-all-frames-parameters' > currently overrides a setting in `window-system-default-frame-alist'. Very good point. I think it makes it even more correct to apply the change I suggest. Stefan ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-11 23:12 ` Stefan Monnier @ 2009-01-12 9:58 ` martin rudalics 2009-01-12 15:23 ` Stefan Monnier 0 siblings, 1 reply; 52+ messages in thread From: martin rudalics @ 2009-01-12 9:58 UTC (permalink / raw) To: Stefan Monnier; +Cc: 1754 >> Maybe. We'd also have to cater for `window-system-default-frame-alist' >> which currently overrides values from `default-frame-alist' but not >> those of `initial-frame-alist'. That is, `modify-all-frames-parameters' >> currently overrides a setting in `window-system-default-frame-alist'. > > Very good point. I think it makes it even more correct to apply the > change I suggest. Agreed. But then why should `modify-all-frames-parameters' modify `window-system-default-frame-alist'? martin ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-12 9:58 ` martin rudalics @ 2009-01-12 15:23 ` Stefan Monnier 2009-01-12 16:00 ` martin rudalics 0 siblings, 1 reply; 52+ messages in thread From: Stefan Monnier @ 2009-01-12 15:23 UTC (permalink / raw) To: martin rudalics; +Cc: 1754 >>> Maybe. We'd also have to cater for `window-system-default-frame-alist' >>> which currently overrides values from `default-frame-alist' but not >>> those of `initial-frame-alist'. That is, `modify-all-frames-parameters' >>> currently overrides a setting in `window-system-default-frame-alist'. >> Very good point. I think it makes it even more correct to apply the >> change I suggest. > Agreed. But then why should `modify-all-frames-parameters' modify > `window-system-default-frame-alist'? 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. Stefan ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-12 15:23 ` Stefan Monnier @ 2009-01-12 16:00 ` martin rudalics 2009-01-12 18:29 ` Stefan Monnier 0 siblings, 1 reply; 52+ messages in thread From: martin rudalics @ 2009-01-12 16:00 UTC (permalink / raw) To: Stefan Monnier; +Cc: 1754 > 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. martin ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-12 16:00 ` martin rudalics @ 2009-01-12 18:29 ` Stefan Monnier 2009-01-12 19:33 ` Lennart Borgman ` (2 more replies) 0 siblings, 3 replies; 52+ messages in thread From: Stefan Monnier @ 2009-01-12 18:29 UTC (permalink / raw) To: martin rudalics; +Cc: 1754 >> 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. Stefan ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-12 18:29 ` Stefan Monnier @ 2009-01-12 19:33 ` Lennart Borgman 2009-01-12 20:57 ` Stefan Monnier 2009-01-12 21:59 ` Drew Adams 2009-01-14 14:20 ` martin rudalics 2 siblings, 1 reply; 52+ messages in thread From: Lennart Borgman @ 2009-01-12 19:33 UTC (permalink / raw) To: Stefan Monnier, 1754 On Mon, Jan 12, 2009 at 7:29 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > 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. Isn't that a good general structure for all kinds of local/global settings? ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-12 19:33 ` Lennart Borgman @ 2009-01-12 20:57 ` Stefan Monnier 0 siblings, 0 replies; 52+ messages in thread From: Stefan Monnier @ 2009-01-12 20:57 UTC (permalink / raw) To: Lennart Borgman; +Cc: 1754 >> 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. > Isn't that a good general structure for all kinds of local/global settings? Yes, I think so. Not that it's easy to do, tho. Stefan ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-12 18:29 ` Stefan Monnier 2009-01-12 19:33 ` Lennart Borgman @ 2009-01-12 21:59 ` Drew Adams 2009-01-14 14:20 ` martin rudalics 2 siblings, 0 replies; 52+ messages in thread From: Drew Adams @ 2009-01-12 21:59 UTC (permalink / raw) To: 'Stefan Monnier', 1754, 'martin rudalics' > >> 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). ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-12 18:29 ` Stefan Monnier 2009-01-12 19:33 ` Lennart Borgman 2009-01-12 21:59 ` Drew Adams @ 2009-01-14 14:20 ` martin rudalics 2 siblings, 0 replies; 52+ messages in thread From: martin rudalics @ 2009-01-14 14:20 UTC (permalink / raw) To: Stefan Monnier; +Cc: 1754 > 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, ... I was only talking about `window-system-default-frame-alist', a variable which apparently has no provenience and not very clear semantics. If I ever used it, I'd not expect a mode toggling function reset it. Note also that things like `pop-up-frame-alist' (and - if we implement your suggestion - `initial-frame-alist') are not affected by mode toggling. martin ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-03 10:13 ` martin rudalics 2009-01-05 4:10 ` Stefan Monnier @ 2009-01-17 18:33 ` Drew Adams 1 sibling, 0 replies; 52+ messages in thread From: Drew Adams @ 2009-01-17 18:33 UTC (permalink / raw) To: 'martin rudalics'; +Cc: 1754 > From: martin rudalics Sent: Saturday, January 03, 2009 2:14 AM > `default-frame-alist' and `initial-frame-alist' are a mess > because these are customizable variables that should not be > affected by toggling minor modes on and off. Sorry for the late reply. I wanted to comment on this part, speaking more generally and not just about these two variables. And I realize that Martin was saying something particular - I'm not contradicting that. I just want to say that it can be appropriate for a command, including a minor-mode command, to change the value of a user option (customizable variable) - e.g. toggle it. Obviously that happens for the mode variable itself, but that is not the only case where this can be useful. There is nothing wrong, in general, with a command or other code changing the value of a user option, as long as the _documentation mentions_ this behavior. There is even nothing wrong necessarily with a command saving the new option value - provided the command's doc calls this out as part of the behavior. Customize is not the only way to change or save option values, and it shouldn't be regarded as such. The Customize UI is limited; other commands can offer alternative, even improved, user interaction in some cases. ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2008-12-31 22:15 ` bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off Drew Adams 2009-01-01 15:24 ` martin rudalics @ 2009-01-09 19:37 ` martin rudalics 2009-01-09 20:21 ` Chong Yidong 2009-01-10 10:20 ` bug#1754: marked as done (23.0.60; tool-bar is shown with tool-bar-mode off) Emacs bug Tracking System 2 siblings, 1 reply; 52+ messages in thread From: martin rudalics @ 2009-01-09 19:37 UTC (permalink / raw) To: 1754; +Cc: Chong Yidong [-- Attachment #1: Type: text/plain, Size: 508 bytes --] Chong, your 2008-10-09 Chong Yidong <cyd@stupidchicken.com> * tool-bar.el (tool-bar-mode): Only change tool-bar-lines on graphical terminals. change is inherently asymmetric with respect to future frames: Turning `tool-bar-mode' off now adds an entry to `default-frame-alist' as before. Turning it on now no more adds an entry. IMHO, we should either not call `modify-all-frames-parameters' in either case or call them in both cases as in the (attached) tool-bar.el patch I proposed earlier. martin [-- Attachment #2: tool-bar.el.diff --] [-- Type: text/plain, Size: 796 bytes --] *** tool-bar.el.~1.23.~ 2009-01-05 10:00:20.515625000 +0100 --- tool-bar.el 2009-01-09 20:09:59.421875000 +0100 *************** *** 54,62 **** :group 'frames (if tool-bar-mode (progn ! (dolist (frame (frame-list)) ! (if (display-graphic-p frame) ! (set-frame-parameter frame '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))))) --- 54,60 ---- :group 'frames (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))))) ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-09 19:37 ` martin rudalics @ 2009-01-09 20:21 ` Chong Yidong 0 siblings, 0 replies; 52+ messages in thread From: Chong Yidong @ 2009-01-09 20:21 UTC (permalink / raw) To: martin rudalics; +Cc: 1754 martin rudalics <rudalics@gmx.at> writes: > IMHO, we should either not call `modify-all-frames-parameters' in > either case or call them in both cases as in the (attached) > tool-bar.el patch I proposed earlier. Patch looks OK; go ahead and install if you like. ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: marked as done (23.0.60; tool-bar is shown with tool-bar-mode off) 2008-12-31 22:15 ` bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off Drew Adams 2009-01-01 15:24 ` martin rudalics 2009-01-09 19:37 ` martin rudalics @ 2009-01-10 10:20 ` Emacs bug Tracking System 2 siblings, 0 replies; 52+ messages in thread From: Emacs bug Tracking System @ 2009-01-10 10:20 UTC (permalink / raw) To: martin rudalics [-- Attachment #1: Type: text/plain, Size: 891 bytes --] Your message dated Sat, 10 Jan 2009 11:09:41 +0100 with message-id <496873E5.9080601@gmx.at> and subject line Re: bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off has caused the Emacs bug report #1754, regarding 23.0.60; tool-bar is shown with tool-bar-mode off to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com immediately.) -- 1754: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1754 Emacs Bug Tracking System Contact owner@emacsbugs.donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 4691 bytes --] From: "Drew Adams" <drew.adams@oracle.com> To: <emacs-pretest-bug@gnu.org> Subject: 23.0.60; tool-bar is shown with tool-bar-mode off Date: Wed, 31 Dec 2008 14:15:46 -0800 Message-ID: <005301c96b95$547ae890$c2b22382@us.oracle.com> This is a regression wrt Emacs 20, 21, and 22. 1. Put this code in a file named `bug-tool-bar.el': (tool-bar-mode -1) (defvar my-minibuffer-frame nil "") (defun foo () "" (interactive) (setq default-frame-alist (append (list (cons 'tool-bar-lines 1)) default-frame-alist)) (setq pop-up-frames t pop-up-frame-alist (append default-frame-alist pop-up-frame-alist)) (setq minibuffer-frame-alist (append (list (cons 'minibuffer 'only)) minibuffer-frame-alist)) (if my-minibuffer-frame (modify-frame-parameters my-minibuffer-frame (list (cons 'minibuffer 'only))) (setq my-minibuffer-frame (let ((after-make-frame-functions nil)) (make-frame (list (cons 'minibuffer 'only))))))) It doesn't matter where the (tool-bar-mode -1) is, and you could alternatively leave it out altogether and then do `M-x tool-bar-mode' to turn it off (step 3). 2. Start Emacs this way: runemacs.exe -Q --debug-init -l "bug-tool-bar.el" -f "foo" You get one frame with buffer *scratch* and a standalone minibuffer frame. Neither frame has a tool bar. However, `tool-bar-mode' is t - it should be nil. You can see this by typing `tool-bar-mode' in buffer *scratch* and using `C-x C-e'. 3. Optional step: `M-x tool-bar-mode'. This turns off tool-bar mode, though it should already have been off because of the code in `bug-tool-bar.el'. 4. Do `C-x 4 f some-file.el'. The file is visited in a new frame, and the frame has a tool bar. And tool-bar mode is now on. And this is so regardless of whether you skip step 3. The mode should remain off, and no tool bar should be shown. In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-12-30 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' [-- Attachment #3: Type: message/rfc822, Size: 1990 bytes --] From: martin rudalics <rudalics@gmx.at> To: 1754-done@emacsbugs.donarmstrong.com Cc: Chong Yidong <cyd@stupidchicken.com> Subject: Re: bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off Date: Sat, 10 Jan 2009 11:09:41 +0100 Message-ID: <496873E5.9080601@gmx.at> >> IMHO, we should either not call `modify-all-frames-parameters' in >> either case or call them in both cases as in the (attached) >> tool-bar.el patch I proposed earlier. > > Patch looks OK; go ahead and install if you like. Done. Not that I liked it, but I'd rather find out now whether asking for non-zero tool-bar-lines may cause problems on text-only terminals. martin ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off @ 2009-01-01 3:05 Chong Yidong 2009-01-01 5:17 ` Drew Adams 0 siblings, 1 reply; 52+ messages in thread From: Chong Yidong @ 2009-01-01 3:05 UTC (permalink / raw) To: Drew Adams; +Cc: 1754 Arguably, Emacs 23 is now doing the right thing. Your default-frame-alist specifies a tool-bar-lines frame parameter of 1, which means the tool-bar should be enabled in new frames. If you remove that frame parameter from your default-frame-alist, or set it to 0, new frames will not show a tool-bar. I am not 100% sure why previous version of Emacs did not show the tool-bar, but they probably ought to have. Possibly it's because we now set up the contents of the tool-bar at startup even if the initial frame cannot or does not display it (a change required by the new multi-tty functionality). ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-01 3:05 bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off Chong Yidong @ 2009-01-01 5:17 ` Drew Adams 2009-01-01 7:03 ` Chong Yidong 2009-01-01 7:36 ` Jason Rumney 0 siblings, 2 replies; 52+ messages in thread From: Drew Adams @ 2009-01-01 5:17 UTC (permalink / raw) To: 'Chong Yidong'; +Cc: 1754 > Arguably, Emacs 23 is now doing the right thing. Your > default-frame-alist specifies a tool-bar-lines frame parameter of 1, > which means the tool-bar should be enabled in new frames. If > you remove that frame parameter from your default-frame-alist, or set it > to 0, new frames will not show a tool-bar. > > I am not 100% sure why previous version of Emacs did not show the > tool-bar, but they probably ought to have. Possibly it's > because we now set up the contents of the tool-bar at startup even if the > initial frame cannot or does not display it (a change required by > the new multi-tty functionality). Huh? Why is that the right thing? The default-frame-alist is set before turning off tool-bar-mode. Turning off the mode should turn off the mode everywhere, until you turn it back on - and it should change the value of default-frame-alist - which it does, except in the scenario I gave. The default-frame-alist doesn't override the current setting of any modes. It must not. It is simply a default setting. On the contrary - changing a mode such as tool-bar-mode or menu-bar-mode should (and generally does) change the value of default-frame-alist. Tool-bar-mode is global and applies to all frames and future frames. That has always been the case and should continue to be the case. What would be the point of having such a mode if the original default frame alist overrode it? Look at menu-bar-mode. It's exactly the same type of thing. But menu-bar-mode acts normally, as it always has acted and as tool-bar-mode should also act. And tool-bar-mode DOES act correctly, except in the scenario I gave, with pop-up-frames non-nil, pop-up-frame-alist as I gave it, and a standalone minibuffer frame. If you don't have all three of those, then turning off (or on) tool-bar-mode, just like turning off (or on) menu-bar-mode, changes the value of default-frame-alist to reflect the mode change, as it should. ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-01 5:17 ` Drew Adams @ 2009-01-01 7:03 ` Chong Yidong 2009-01-01 21:28 ` Drew Adams 2009-01-01 7:36 ` Jason Rumney 1 sibling, 1 reply; 52+ messages in thread From: Chong Yidong @ 2009-01-01 7:03 UTC (permalink / raw) To: Drew Adams; +Cc: 1754 "Drew Adams" <drew.adams@oracle.com> writes: > Huh? Why is that the right thing? Because your function `foo' tells Emacs to add a tool-bar to new frames. Here is a much, much simpler version of your "bug": In foo.el; (tool-bar-mode -1) (defun foo () (interactive) (setq default-frame-alist (append (list (cons 'tool-bar-lines 1)) default-frame-alist))) emacs -Q -l "foo.el" -f "foo" When foo.el is loaded, that turns off tool-bar-mode (internally, this works by modifying default-frame-alist and changing the frame parameter `tool-bar-lines' to 0). Next, the function `foo' is run. That modifies default-frame-alist by adding (tool-bar-lines . 1). So, all new frames get a tool-bar. ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-01 7:03 ` Chong Yidong @ 2009-01-01 21:28 ` Drew Adams 2009-01-01 21:51 ` Drew Adams 2009-01-02 0:01 ` Jason Rumney 0 siblings, 2 replies; 52+ messages in thread From: Drew Adams @ 2009-01-01 21:28 UTC (permalink / raw) To: 'Chong Yidong'; +Cc: 1754 > > Huh? Why is that the right thing? > > Because your function `foo' tells Emacs to add a tool-bar to > new frames. > Here is a much, much simpler version of your "bug": > > In foo.el; > (tool-bar-mode -1) > (defun foo () > (interactive) > (setq default-frame-alist > (append (list (cons 'tool-bar-lines 1)) > default-frame-alist))) > > emacs -Q -l "foo.el" -f "foo" > > When foo.el is loaded, that turns off tool-bar-mode (internally, this > works by modifying default-frame-alist and changing the frame > parameter `tool-bar-lines' to 0). > > Next, the function `foo' is run. That modifies default-frame-alist by > adding (tool-bar-lines . 1). So, all new frames get a tool-bar. No, you missed the point. I wasn't clear enough. Use your code above, plus (setq pop-up-frames t). After starting Emacs, turn off tool-bar mode: M-x tool-bar-mode. Thereafter, new frames do not have tool bars. This is correct behavior - no bug. Now do the same thing with the code I sent - with the standalone minibuffer frame and `pop-up-frames-alist'. After you turn off tool-bar mode, new frames have tool bars. That is the bug. I already said that there is no bug without the three things I mentioned: standalone minibuffer, non-nil `pop-up-frames', and `pop-up-frames-alist'. Without those conditions, `tool-bar-mode' acts normally; it acts just like `menu-bar-mode': it affects subsequent new frames. I am now getting the impression that `pop-up-frames-alist' is being used for opening new normal frames, not just for popup frames. If so, that is at least a partial cause of the bug. I think that what Martin found is the other cause. IOW, I think what is needed is both: 1. Martin's patch: turning off the mode should update `default-frame-alist' also. 2. There is likely code somewhere that is now using `pop-up-frame-alist' for the creation of ordinary frames, not popup frames. That needs to be fixed. ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-01 21:28 ` Drew Adams @ 2009-01-01 21:51 ` Drew Adams 2009-01-02 0:01 ` Jason Rumney 1 sibling, 0 replies; 52+ messages in thread From: Drew Adams @ 2009-01-01 21:51 UTC (permalink / raw) To: 1754, 'Chong Yidong' > I am now getting the impression that `pop-up-frames-alist' is > being used for opening new normal frames, not just for popup > frames. If so, that is at least a partial cause of the bug. Yes, the cause of this is a faulty translation of `display-buffer' from C code to Lisp - see my reply to Martin. > I think that what Martin found is the other cause. > > IOW, I think what is needed is both: > > 1. Martin's patch: turning off the mode should update > `default-frame-alist' > also. > > 2. There is likely code somewhere that is now using > `pop-up-frame-alist' for the > creation of ordinary frames, not popup frames. That needs to be fixed. That place is apparently the new code for `display-buffer'. ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-01 21:28 ` Drew Adams 2009-01-01 21:51 ` Drew Adams @ 2009-01-02 0:01 ` Jason Rumney 2009-01-02 1:14 ` Drew Adams 1 sibling, 1 reply; 52+ messages in thread From: Jason Rumney @ 2009-01-02 0:01 UTC (permalink / raw) To: Drew Adams, 1754; +Cc: 'Chong Yidong' Drew Adams wrote: > The "pop-up" in each of the names `pop-up-frames' and `pop-up-frames-alist' > means very different things. It seems you are asking us to change Emacs to match your confusion at the expense of other users'. ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-02 0:01 ` Jason Rumney @ 2009-01-02 1:14 ` Drew Adams 2009-01-02 2:27 ` Drew Adams 0 siblings, 1 reply; 52+ messages in thread From: Drew Adams @ 2009-01-02 1:14 UTC (permalink / raw) To: 'Jason Rumney', 1754; +Cc: 'Chong Yidong' > > The "pop-up" in each of the names `pop-up-frames' and > > `pop-up-frames-alist' means very different things. > > It seems you are asking us to change Emacs to match your confusion at > the expense of other users'. Not at all. Read the description of `pop-up-frame-alist'. It talks about special "pop-up" frames, and it gives examples of them. It is the analog of `special-display-frame-alist'. Both "supercede the values given in `default-frame-alist'. Read the description of `pop-up-frames'. It is completely general and refers to all frames. It is the analog of `pop-up-windows'. There is nothing new in this. Look at the C code for `display-buffer' in Emacs 22 (or 21 or 20). It does not refer to `pop-up-frame-alist' at all. It uses `pop-up-frames' the same way it uses `pop-up-windows': to know whether to use a separate frame (or window, in the latter case). `pop-up-windows': "Non-nil means `display-buffer' should make a new window." `pop-up-frames': "Whether `display-buffer' should make a separate frame." Those have nothing to do with superceding the values in `default-frame-alist'. I'm afraid you don't know what you're talking about on this question. Sad to say, the person who translated `display-buffer' from C to Lisp might have been in the same boat. ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-02 1:14 ` Drew Adams @ 2009-01-02 2:27 ` Drew Adams 2009-01-02 2:47 ` Drew Adams 2009-01-02 11:57 ` Jason Rumney 0 siblings, 2 replies; 52+ messages in thread From: Drew Adams @ 2009-01-02 2:27 UTC (permalink / raw) To: 1754, 'Jason Rumney'; +Cc: 'Chong Yidong' > Read the description of `pop-up-frame-alist'. It talks about > special "pop-up" frames, and it gives examples of them. It is the > analog of `special-display-frame-alist'. Both "supercede the > values given in `default-frame-alist'. > > Read the description of `pop-up-frames'. It is completely > general and refers to all frames. It is the analog of `pop-up-windows'. > > There is nothing new in this. Look at the C code for `display-buffer' > in Emacs 22 (or 21 or 20). It does not refer to `pop-up-frame-alist' > at all. It uses `pop-up-frames' the same way it uses `pop-up-windows': > to know whether to use a separate frame (or window, in the latter case). > > `pop-up-windows': > "Non-nil means `display-buffer' should make a new window." > > `pop-up-frames': > "Whether `display-buffer' should make a separate frame." > > Those have nothing to do with superceding the values in > `default-frame-alist'. I'm afraid it is I who was mistaken about this, not you. From the doc, I had the impression that `pop-up-frame-alist' did not apply to all new frames opened, that it applied only to special, "pop-up" frames. I've never used `pop-up-frame-alist'. But I see now that in Emacs 22 any frames opened by `display-buffer' (e.g. via `C-x 5 f' or because `pop-up-frames' is non-nil) use the properties of `pop-up-frame-alist', not `default-frame-alist'. My bad. It might be a good idea to mention in the doc of `pop-up-frame-alist' the connection with `pop-up-frames' and `display-buffer'. Instead of speaking of it being used when "creating pop-up frames" (undefined) and giving examples of frames that are quite particular (completions, help), it would be better to specifically mention `display-buffer' (and perhaps `pop-up-frames'). ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-02 2:27 ` Drew Adams @ 2009-01-02 2:47 ` Drew Adams 2009-01-02 11:57 ` Jason Rumney 1 sibling, 0 replies; 52+ messages in thread From: Drew Adams @ 2009-01-02 2:47 UTC (permalink / raw) To: 1754, 'Jason Rumney'; +Cc: 'Chong Yidong' I should have added that you can close this bug, and sorry for the noise. I see now that I have let-bound `pop-up-frame-alist' in a couple other places in code I wrote, so perhaps I knew the correct story at one time and forgot it. Dunno. ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-02 2:27 ` Drew Adams 2009-01-02 2:47 ` Drew Adams @ 2009-01-02 11:57 ` Jason Rumney 2009-01-02 14:50 ` martin rudalics 1 sibling, 1 reply; 52+ messages in thread From: Jason Rumney @ 2009-01-02 11:57 UTC (permalink / raw) To: Drew Adams; +Cc: 'Chong Yidong', 1754 Drew Adams wrote: > I'm afraid it is I who was mistaken about this, not you. From the doc, I had the > impression that `pop-up-frame-alist' did not apply to all new frames opened, > that it applied only to special, "pop-up" frames. I've never used > `pop-up-frame-alist'. > I can see why you get that impression from the doc string of pop-up-frame-alist. The second line is confusing - both in that the mentioned buffers are not pop-up-frames by default, and that if pop-up-frames is enabled, then there is no difference between the mentioned buffers and any other buffer that displays in a pop-up frame. The doc string should just say that pop-up-frame-alist applies to pop-up-frames, which should also be obvious from the name. Trying to explain pop-up-frames there (which I assume is what the intention of the second line is) just confuses things. ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-02 11:57 ` Jason Rumney @ 2009-01-02 14:50 ` martin rudalics 0 siblings, 0 replies; 52+ messages in thread From: martin rudalics @ 2009-01-02 14:50 UTC (permalink / raw) To: Jason Rumney, 1754; +Cc: 'Chong Yidong' > I can see why you get that impression from the doc string of > pop-up-frame-alist. The second line is confusing - both in that the > mentioned buffers are not pop-up-frames by default, and that if > pop-up-frames is enabled, then there is no difference between the > mentioned buffers and any other buffer that displays in a pop-up frame. > > The doc string should just say that pop-up-frame-alist applies to > pop-up-frames, which should also be obvious from the name. Trying to > explain pop-up-frames there (which I assume is what the intention of the > second line is) just confuses things. I've just rewritten some doc-strings in frame.el. Please have a look. martin ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-01 5:17 ` Drew Adams 2009-01-01 7:03 ` Chong Yidong @ 2009-01-01 7:36 ` Jason Rumney 2009-01-01 21:28 ` Drew Adams 1 sibling, 1 reply; 52+ messages in thread From: Jason Rumney @ 2009-01-01 7:36 UTC (permalink / raw) To: Drew Adams, 1754; +Cc: 'Chong Yidong' Drew Adams wrote: > Huh? Why is that the right thing? The default-frame-alist is set before turning > off tool-bar-mode. But you also set tool-bar-lines to 1 in popup-frame-alist, which overrides default-frame-alist for popup frames in any case. tool-bar-mode may override settings in default-frame-alist, but it doesn't go any further than that, as the more specialized -frame-alist settings are probably more important than the global setting of tool-bar-mode. ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-01 7:36 ` Jason Rumney @ 2009-01-01 21:28 ` Drew Adams 2009-01-01 23:53 ` Jason Rumney 0 siblings, 1 reply; 52+ messages in thread From: Drew Adams @ 2009-01-01 21:28 UTC (permalink / raw) To: 'Jason Rumney', 1754; +Cc: 'Chong Yidong' > > Huh? Why is that the right thing? The default-frame-alist > > is set before turning off tool-bar-mode. > > But you also set tool-bar-lines to 1 in popup-frame-alist, which > overrides default-frame-alist for popup frames in any case. > tool-bar-mode may override settings in default-frame-alist, but it > doesn't go any further than that, as the more specialized > -frame-alist settings are probably more important than the global > setting of tool-bar-mode. Absolutely not. The mode should affect all existing and future frames. That's always been the case, and it is how other, similar modes, such as `menu-bar-mode', work. It has never been the case that some frame alist overrides the current mode value. ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-01 21:28 ` Drew Adams @ 2009-01-01 23:53 ` Jason Rumney 2009-01-02 1:14 ` Drew Adams 0 siblings, 1 reply; 52+ messages in thread From: Jason Rumney @ 2009-01-01 23:53 UTC (permalink / raw) To: Drew Adams, 1754; +Cc: 'Chong Yidong' Drew Adams wrote: > Absolutely not. The mode should affect all existing and future frames. That's > always been the case, and it is how other, similar modes, such as > `menu-bar-mode', work. > If that was the case, you would not be able to have minibuffer, ediff and speedbar frames without menu or toolbar if you were displaying those in other frames. > It has never been the case that some frame alist overrides the current mode > value. > It always has been the case for me. ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-01 23:53 ` Jason Rumney @ 2009-01-02 1:14 ` Drew Adams 0 siblings, 0 replies; 52+ messages in thread From: Drew Adams @ 2009-01-02 1:14 UTC (permalink / raw) To: 'Jason Rumney', 1754; +Cc: 'Chong Yidong' > > Absolutely not. The mode should affect all existing and > > future frames. That's always been the case, and it is how other, > > similar modes, such as `menu-bar-mode', work. > > > > If that was the case, you would not be able to have minibuffer, ediff > and speedbar frames without menu or toolbar if you were > displaying those in other frames. Of course you would. I do that myself. You do that by changing the frame parameter for the given frame, not by using the global mode function `menu-bar-mode' or `tool-bar-mode'. There is nothing new here - this is the way it has always worked. > > It has never been the case that some frame alist overrides > > the current mode value. > > It always has been the case for me. No, it has not. Try Emacs 22 (or 21 or 20). `M-x tool-bar-mode' and `M-x menu-bar-mode' affect all existing and future frames. That doesn't mean you can't tweak an individual frame, by changing its parameters. But those are global commands. Always have been. ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off
@ 2009-01-01 13:47 grischka
2009-01-01 13:51 ` Jason Rumney
0 siblings, 1 reply; 52+ messages in thread
From: grischka @ 2009-01-01 13:47 UTC (permalink / raw)
To: jasonr; +Cc: 1754
Jason Rumney wrote:
> But you also set tool-bar-lines to 1 in popup-frame-alist, which overrides
> default-frame-alist for popup frames in any case. tool-bar-mode may override
> settings in default-frame-alist, but it doesn't go any further than that, as
> the more specialized -frame-alist settings are probably more important than
> the global setting of tool-bar-mode.
Sorry, but "probably" is not a category that matters with binary logic like
whether something is "on" or "off".
In this case: As long as it is possible to make a new frame and that frame
does not have a toolbar and at the same time typing "M-: tool-bar-mode" in
that frame returns t, there is something wrong with it. Not probably, but
definitely.
^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-01 13:47 grischka @ 2009-01-01 13:51 ` Jason Rumney 2009-01-01 14:30 ` grischka 0 siblings, 1 reply; 52+ messages in thread From: Jason Rumney @ 2009-01-01 13:51 UTC (permalink / raw) To: grischka; +Cc: 1754 grischka wrote: > Sorry, but "probably" is not a category that matters with binary logic > like > whether something is "on" or "off". Users' personal preferences and the various permutations of *-frame-alist are not binary logic. ^ permalink raw reply [flat|nested] 52+ messages in thread
* bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off 2009-01-01 13:51 ` Jason Rumney @ 2009-01-01 14:30 ` grischka 0 siblings, 0 replies; 52+ messages in thread From: grischka @ 2009-01-01 14:30 UTC (permalink / raw) To: Jason Rumney; +Cc: 1754 Jason Rumney wrote: > grischka wrote: >> Sorry, but "probably" is not a category that matters with binary logic >> like whether something is "on" or "off". > > Users' personal preferences and the various permutations of > *-frame-alist are not binary logic. > Maybe users' preferences aren't binary but the ways to express them towards the program are. And the permutations performed by the program are certainly binary too, that doesn't change by the fact that they are maybe not well understood. ^ permalink raw reply [flat|nested] 52+ messages in thread
end of thread, other threads:[~2009-01-17 18:33 UTC | newest] Thread overview: 52+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <496873E5.9080601@gmx.at> 2008-12-31 22:15 ` bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off Drew Adams 2009-01-01 15:24 ` martin rudalics 2009-01-01 15:53 ` Jason Rumney 2009-01-01 16:09 ` martin rudalics 2009-01-01 21:28 ` Drew Adams 2009-01-01 21:51 ` Drew Adams 2009-01-02 7:52 ` martin rudalics 2009-01-02 7:52 ` martin rudalics 2009-01-03 3:12 ` Stefan Monnier 2009-01-03 10:13 ` martin rudalics 2009-01-05 4:10 ` Stefan Monnier 2009-01-05 7:57 ` martin rudalics 2009-01-05 22:20 ` Stefan Monnier 2009-01-06 13:37 ` martin rudalics 2009-01-09 19:37 ` martin rudalics 2009-01-10 2:29 ` Stefan Monnier 2009-01-10 10:04 ` martin rudalics 2009-01-10 22:38 ` Stefan Monnier 2009-01-11 11:22 ` martin rudalics 2009-01-11 14:56 ` Stefan Monnier 2009-01-11 17:14 ` martin rudalics 2009-01-11 23:12 ` Stefan Monnier 2009-01-12 9:58 ` martin rudalics 2009-01-12 15:23 ` Stefan Monnier 2009-01-12 16:00 ` martin rudalics 2009-01-12 18:29 ` Stefan Monnier 2009-01-12 19:33 ` Lennart Borgman 2009-01-12 20:57 ` Stefan Monnier 2009-01-12 21:59 ` Drew Adams 2009-01-14 14:20 ` martin rudalics 2009-01-17 18:33 ` Drew Adams 2009-01-09 19:37 ` martin rudalics 2009-01-09 20:21 ` Chong Yidong 2009-01-10 10:20 ` bug#1754: marked as done (23.0.60; tool-bar is shown with tool-bar-mode off) Emacs bug Tracking System 2009-01-01 3:05 bug#1754: 23.0.60; tool-bar is shown with tool-bar-mode off Chong Yidong 2009-01-01 5:17 ` Drew Adams 2009-01-01 7:03 ` Chong Yidong 2009-01-01 21:28 ` Drew Adams 2009-01-01 21:51 ` Drew Adams 2009-01-02 0:01 ` Jason Rumney 2009-01-02 1:14 ` Drew Adams 2009-01-02 2:27 ` Drew Adams 2009-01-02 2:47 ` Drew Adams 2009-01-02 11:57 ` Jason Rumney 2009-01-02 14:50 ` martin rudalics 2009-01-01 7:36 ` Jason Rumney 2009-01-01 21:28 ` Drew Adams 2009-01-01 23:53 ` Jason Rumney 2009-01-02 1:14 ` Drew Adams -- strict thread matches above, loose matches on Subject: below -- 2009-01-01 13:47 grischka 2009-01-01 13:51 ` Jason Rumney 2009-01-01 14:30 ` grischka
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.