* "CHANGED outside Customize" in frames customization group @ 2007-12-29 9:44 martin rudalics 2007-12-29 15:51 ` Drew Adams 2007-12-29 17:48 ` Richard Stallman 0 siblings, 2 replies; 21+ messages in thread From: martin rudalics @ 2007-12-29 9:44 UTC (permalink / raw) To: emacs-devel Users who want to customize one of the variables listed below are currently told: default-frame-alist: Hide Value State: CHANGED outside Customize; operating on it here may be unreliable. initial-frame-alist: Hide Value State: CHANGED outside Customize; operating on it here may be unreliable. menu-bar-mode: Hide Value Toggle on (non-nil) State: CHANGED outside Customize; operating on it here may be unreliable. tool-bar-mode: Hide Value Toggle off (nil) State: CHANGED outside Customize; operating on it here may be unreliable. These are probably due to the attempts to make `default-frame-alist' and `initial-frame-alist' reflect the actual states of `menu-bar-mode' and `tool-bar-mode' and vice-versa. pop-up-frame-function: Hide Value (lambda nil (make-frame pop-up-frame-alist)) State: CHANGED outside Customize; operating on it here may be unreliable. due to (setq pop-up-frame-function ;; Using `function' here caused some sort of problem. '(lambda () (make-frame pop-up-frame-alist))) in frame.el and special-display-function: Hide Value special-display-popup-frame State: CHANGED outside Customize; operating on it here may be unreliable. due to (setq special-display-function 'special-display-popup-frame) in frame.el. Maybe these variables shouldn't be customizable in the first place. Else we should try to improve the user interface. Any suggestions? ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: "CHANGED outside Customize" in frames customization group 2007-12-29 9:44 "CHANGED outside Customize" in frames customization group martin rudalics @ 2007-12-29 15:51 ` Drew Adams 2007-12-29 16:14 ` Luc Teirlinck 2007-12-29 17:33 ` martin rudalics 2007-12-29 17:48 ` Richard Stallman 1 sibling, 2 replies; 21+ messages in thread From: Drew Adams @ 2007-12-29 15:51 UTC (permalink / raw) To: martin rudalics, emacs-devel > default-frame-alist > initial-frame-alist > menu-bar-mode > tool-bar-mode > pop-up-frame-function > special-display-function > > Maybe these variables shouldn't be customizable in the first place. > Else we should try to improve the user interface. I do hope that first suggestion is an early April Fool's joke. ;-) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "CHANGED outside Customize" in frames customization group 2007-12-29 15:51 ` Drew Adams @ 2007-12-29 16:14 ` Luc Teirlinck 2007-12-29 17:33 ` martin rudalics 1 sibling, 0 replies; 21+ messages in thread From: Luc Teirlinck @ 2007-12-29 16:14 UTC (permalink / raw) To: drew.adams; +Cc: rudalics, emacs-devel Drew Adams wrote: I do hope that first suggestion is an early April Fool's joke. There also is Innocent's Day. But I believe that was yesterday, December 28. So it is just a few hours late. Sincerely, Luc. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "CHANGED outside Customize" in frames customization group 2007-12-29 15:51 ` Drew Adams 2007-12-29 16:14 ` Luc Teirlinck @ 2007-12-29 17:33 ` martin rudalics 2007-12-29 18:14 ` Drew Adams 2007-12-30 1:36 ` Richard Stallman 1 sibling, 2 replies; 21+ messages in thread From: martin rudalics @ 2007-12-29 17:33 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel >>Maybe these variables shouldn't be customizable in the first place. >>Else we should try to improve the user interface. > > > I do hope that first suggestion is an early April Fool's joke. ;-) Why do you think so? The doc-string of `default-frame-alist' states: These may be set in your init file, like this: (setq default-frame-alist '((width . 80) (height . 55) (menu-bar-lines . 1))) In my book suggesting the use of `setq' to set a variable contradicts the very idea of customizing that variable. ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: "CHANGED outside Customize" in frames customization group 2007-12-29 17:33 ` martin rudalics @ 2007-12-29 18:14 ` Drew Adams 2007-12-30 1:36 ` Richard Stallman 1 sibling, 0 replies; 21+ messages in thread From: Drew Adams @ 2007-12-29 18:14 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel > >>Maybe these variables shouldn't be customizable in the first place. > >>Else we should try to improve the user interface. > > > > I do hope that first suggestion is an early April Fool's joke. ;-) > > Why do you think so? The doc-string of `default-frame-alist' states: > > These may be set in your init file, like this: > (setq default-frame-alist '((width . 80) (height . 55) > (menu-bar-lines . 1))) > > In my book suggesting the use of `setq' to set a variable contradicts > the very idea of customizing that variable. 1. Not in my book. 2. If there is a contradiction (in your book), then it is a doc problem, not a product design problem. Customizing is possible today, and it should remain so. There is no reason that users shouldn't be able to use Customize for this. Now, it is true that if you count on Customize settings for this in your init file or `custom-file', then those settings need to be loaded at an appropriate time. If you load `custom-file' at the end of your .emacs, and you have other code in your .emacs that depends on the customization of `default-frame-alist', then you've done the wrong thing. Please don't think about making things such as `default-frame-alist' non-custom variables just to fix a product problem. Please find another way around the difficulties you ran into. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "CHANGED outside Customize" in frames customization group 2007-12-29 17:33 ` martin rudalics 2007-12-29 18:14 ` Drew Adams @ 2007-12-30 1:36 ` Richard Stallman 1 sibling, 0 replies; 21+ messages in thread From: Richard Stallman @ 2007-12-30 1:36 UTC (permalink / raw) To: martin rudalics; +Cc: drew.adams, emacs-devel In my book suggesting the use of `setq' to set a variable contradicts the very idea of customizing that variable. There is no contradiction. Both methods can be used for any customizable variable, and both methods are normal. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "CHANGED outside Customize" in frames customization group 2007-12-29 9:44 "CHANGED outside Customize" in frames customization group martin rudalics 2007-12-29 15:51 ` Drew Adams @ 2007-12-29 17:48 ` Richard Stallman 2007-12-30 14:07 ` martin rudalics 1 sibling, 1 reply; 21+ messages in thread From: Richard Stallman @ 2007-12-29 17:48 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel default-frame-alist: Hide Value State: CHANGED outside Customize; operating on it here may be unreliable. Can you fix this by calling custom-reevaluate-setting in the appropriate place in startup.el? (With the other calls to it.) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "CHANGED outside Customize" in frames customization group 2007-12-29 17:48 ` Richard Stallman @ 2007-12-30 14:07 ` martin rudalics 2007-12-30 15:42 ` Richard Stallman 0 siblings, 1 reply; 21+ messages in thread From: martin rudalics @ 2007-12-30 14:07 UTC (permalink / raw) To: rms; +Cc: emacs-devel > default-frame-alist: Hide Value > State: CHANGED outside Customize; operating on it here may be unreliable. > > Can you fix this by calling custom-reevaluate-setting > in the appropriate place in startup.el? > (With the other calls to it.) IIUC `custom-reevaluate-setting' can be used to set a variable after some environment value has been established as for `blink-cursor-mode'. The situation seems completely different for `default-frame-alist'. I know people object, but as it's currently used this variable is simply not suited for customization. The first reason is immediately visible when starting Emacs without your .emacs. The value is here: ((left-fringe) (right-fringe) (menu-bar-lines . 1) (tool-bar-lines . 1)) I know how to get rid of the -fringe entries. But I don't know what to do with the -line entries (which are BTW already there in Emacs 21). Delete them in the customization buffer, save your settings, restart Emacs, and here they are again. A second reason is the function `modify-all-frames-parameters'. This function may set `default-frame-alist'. Customize `tool-bar-mode' or `fringe-mode' and you will change your `default-frame-alist' settings. These issues are hardly noticeable for most of us. Whatever approach we've chosen to set up this variable, we're hardly going to change its value often. A novice user, however, will be confronted with a not very motivating advice when starting to customize the appearance of frames. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "CHANGED outside Customize" in frames customization group 2007-12-30 14:07 ` martin rudalics @ 2007-12-30 15:42 ` Richard Stallman 2007-12-30 18:18 ` martin rudalics 0 siblings, 1 reply; 21+ messages in thread From: Richard Stallman @ 2007-12-30 15:42 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel IIUC `custom-reevaluate-setting' can be used to set a variable after some environment value has been established as for `blink-cursor-mode'. The situation seems completely different for `default-frame-alist'. In what way is it different? The first reason is immediately visible when starting Emacs without your .emacs. The value is here: ((left-fringe) (right-fringe) (menu-bar-lines . 1) (tool-bar-lines . 1)) I know how to get rid of the -fringe entries. ISTR someone recently posted a patch that would affect the handling of fringes in `default-frame-alist'. Would they get rid of those? But I don't know what to do with the -line entries (which are BTW already there in Emacs 21). Why does anything need to be done with them? Could you just leave them alone? Or else change the numbers? Delete them in the customization buffer, save your settings, restart Emacs, and here they are again. That is arguably a bug, and maybe we should fix it. However, I do not see that this bug is so grave that we should conclude that `default-frame-alist' is unsuitable for use with Custom. A second reason is the function `modify-all-frames-parameters'. This function may set `default-frame-alist'. Customize `tool-bar-mode' or `fringe-mode' and you will change your `default-frame-alist' settings. I don't see a problem in that. Why do you think it is a problem? What aspect of it is the problem? If the problem is in some detail of the behavior of Custom when it is used on `default-frame-alist', maybe we can fix that detail. For instance, maybe those other commands should do somethingto inform Custom of the changes, so that it looks like `default-frame-alist' was set using Custom. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "CHANGED outside Customize" in frames customization group 2007-12-30 15:42 ` Richard Stallman @ 2007-12-30 18:18 ` martin rudalics 2007-12-30 22:58 ` Richard Stallman 0 siblings, 1 reply; 21+ messages in thread From: martin rudalics @ 2007-12-30 18:18 UTC (permalink / raw) To: rms; +Cc: emacs-devel > IIUC `custom-reevaluate-setting' can be used to set a variable after > some environment value has been established as for `blink-cursor-mode'. > The situation seems completely different for `default-frame-alist'. > > In what way is it different? `frame-notice-user-settings' may set the value of `default-frame-alist' overriding a saved or standard value. The value of `blink-cursor-mode' is not reset by Emacs. > The first reason is immediately visible > when starting Emacs without your .emacs. The value is here: > > ((left-fringe) (right-fringe) (menu-bar-lines . 1) (tool-bar-lines . 1)) > > I know how to get rid of the -fringe entries. > > ISTR someone recently posted a patch that would affect the handling > of fringes in `default-frame-alist'. Would they get rid of those? I hope so. > But I don't know what to > do with the -line entries (which are BTW already there in Emacs 21). > > Why does anything need to be done with them? > Could you just leave them alone? > Or else change the numbers? > > Delete them in the customization buffer, save your settings, restart > Emacs, and here they are again. > > That is arguably a bug, and maybe we should fix it. > However, I do not see that this bug is so grave > that we should conclude that `default-frame-alist' is > unsuitable for use with Custom. The bug causes the "CHANGED outside Customize ..." state. > A second reason is the function `modify-all-frames-parameters'. This > function may set `default-frame-alist'. Customize `tool-bar-mode' or > `fringe-mode' and you will change your `default-frame-alist' settings. > > I don't see a problem in that. Why do you think it is a problem? > What aspect of it is the problem? Customizing `fringe-mode' calls `modify-all-frames-parameters' which sets `default-frame-alist'. I'm now told that `default-frame-alist' was CHANGED outside Customize although all I actually did was _customizing_ some option. > If the problem is in some detail of the behavior of Custom when it is > used on `default-frame-alist', maybe we can fix that detail. > For instance, maybe those other commands should do somethingto inform > Custom of the changes, so that it looks like `default-frame-alist' > was set using Custom. Suppose I set and save a new value for `fringe-mode'. Should Emacs automatically set and save the new value for `default-frame-alist'? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "CHANGED outside Customize" in frames customization group 2007-12-30 18:18 ` martin rudalics @ 2007-12-30 22:58 ` Richard Stallman 2007-12-31 11:04 ` martin rudalics 0 siblings, 1 reply; 21+ messages in thread From: Richard Stallman @ 2007-12-30 22:58 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel `frame-notice-user-settings' may set the value of `default-frame-alist' overriding a saved or standard value. The value of `blink-cursor-mode' is not reset by Emacs. Ok, but why does that matter for this issue? > Delete them in the customization buffer, save your settings, restart > Emacs, and here they are again. > > That is arguably a bug, and maybe we should fix it. > However, I do not see that this bug is so grave > that we should conclude that `default-frame-alist' is > unsuitable for use with Custom. The bug causes the "CHANGED outside Customize ..." state. Here's an idea. We can create a new variable `command-args-frame-alist', and make the functions which obey `default-frame-alist' use `command-args-frame-alist' too. Settings such as `menu-bar-lines', which are set by arguments and X resources can go in `command-args-frame-alist', and would not affect `default-frame-alist'. One consequence would be that the values specified by command line options and X resources would override your customizations. That seems correct. Customizing `fringe-mode' calls `modify-all-frames-parameters' which sets `default-frame-alist'. I'm now told that `default-frame-alist' was CHANGED outside Customize although all I actually did was _customizing_ some option. The solution to that is just to inform Custom about the change, so it will realize that the change to `default-frame-alist' was made within Custom. It's just a bug, it just needs to be fixed. > If the problem is in some detail of the behavior of Custom when it is > used on `default-frame-alist', maybe we can fix that detail. > For instance, maybe those other commands should do somethingto inform > Custom of the changes, so that it looks like `default-frame-alist' > was set using Custom. Suppose I set and save a new value for `fringe-mode'. Should Emacs automatically set and save the new value for `default-frame-alist'? Maybe it should, but that would require a new Custom feature: dependencies, "If you save `foo', always save `bar' too". ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "CHANGED outside Customize" in frames customization group 2007-12-30 22:58 ` Richard Stallman @ 2007-12-31 11:04 ` martin rudalics 2008-01-01 3:18 ` Richard Stallman 0 siblings, 1 reply; 21+ messages in thread From: martin rudalics @ 2007-12-31 11:04 UTC (permalink / raw) To: rms; +Cc: emacs-devel > `frame-notice-user-settings' may set the value of `default-frame-alist' > overriding a saved or standard value. The value of `blink-cursor-mode' > is not reset by Emacs. > > Ok, but why does that matter for this issue? Because the "CHANGED outside Customize ..." state is (also) caused by that resetting operation in `frame-notice-user-settings'. Probably because actual and saved/standard value differ but I don't understand the customization code very well. > > Delete them in the customization buffer, save your settings, restart > > Emacs, and here they are again. > > > > That is arguably a bug, and maybe we should fix it. > > However, I do not see that this bug is so grave > > that we should conclude that `default-frame-alist' is > > unsuitable for use with Custom. > > The bug causes the "CHANGED outside Customize ..." state. > > Here's an idea. We can create a new variable > `command-args-frame-alist', and make the functions which obey > `default-frame-alist' use `command-args-frame-alist' too. > > Settings such as `menu-bar-lines', which are set by arguments and X > resources can go in `command-args-frame-alist', and would not affect > `default-frame-alist'. One consequence would be that the values > specified by command line options and X resources would override your > customizations. That seems correct. Do I understand you correctly that `frame-notice-user-settings' and `modify-all-frames-parameters' should set the `command-args-...' values (one for the initial and one for the default frame)? This would require a non-trivial reorganization of frame.el. Note that I was not looking into the command-line arguments and X resources issues yet. All I was concerned about so far were the implications of customizing tool-bar-mode, fringe-mode, ... > Customizing `fringe-mode' calls `modify-all-frames-parameters' which > sets `default-frame-alist'. I'm now told that `default-frame-alist' was > CHANGED outside Customize although all I actually did was _customizing_ > some option. > > The solution to that is just to inform Custom about the change, so it > will realize that the change to `default-frame-alist' was made within > Custom. > > It's just a bug, it just needs to be fixed. I wouldn't know how. If I simply set `default-frame-alist' in some "Custom" way I'll be told that there are unsaved changes. > > If the problem is in some detail of the behavior of Custom when it is > > used on `default-frame-alist', maybe we can fix that detail. > > For instance, maybe those other commands should do somethingto inform > > Custom of the changes, so that it looks like `default-frame-alist' > > was set using Custom. > > Suppose I set and save a new value for `fringe-mode'. Should Emacs > automatically set and save the new value for `default-frame-alist'? > > Maybe it should, but that would require a new Custom feature: > dependencies, "If you save `foo', always save `bar' too". And something similar for erasing customizations ... hardly feasible. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "CHANGED outside Customize" in frames customization group 2007-12-31 11:04 ` martin rudalics @ 2008-01-01 3:18 ` Richard Stallman 2008-01-01 10:24 ` martin rudalics 0 siblings, 1 reply; 21+ messages in thread From: Richard Stallman @ 2008-01-01 3:18 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel Do I understand you correctly that `frame-notice-user-settings' and `modify-all-frames-parameters' should set the `command-args-...' values (one for the initial and one for the default frame)? Yes, that's what I've proposed. Do you see any flaws in the idea? This would require a non-trivial reorganization of frame.el. I think it should be pretty simple. Only 4 functions in frame.el seem to refer to default-frame-alist or initial-frame-alist. So I think that not much change would be needed. Note that I was not looking into the command-line arguments and X resources issues yet. Yes, but I think this same approach would work for x-win.el and would be simple there too. > Customizing `fringe-mode' calls `modify-all-frames-parameters' which > sets `default-frame-alist'. I'm now told that `default-frame-alist' was > CHANGED outside Customize although all I actually did was _customizing_ > some option. > > The solution to that is just to inform Custom about the change, so it > will realize that the change to `default-frame-alist' was made within > Custom. > > It's just a bug, it just needs to be fixed. I wouldn't know how. If I simply set `default-frame-alist' in some "Custom" way I'll be told that there are unsaved changes. It looks like `customize-set-variable' does the right job. So I think this won't be very hard. Want to give it a try? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "CHANGED outside Customize" in frames customization group 2008-01-01 3:18 ` Richard Stallman @ 2008-01-01 10:24 ` martin rudalics 2008-01-03 9:50 ` Richard Stallman 0 siblings, 1 reply; 21+ messages in thread From: martin rudalics @ 2008-01-01 10:24 UTC (permalink / raw) To: rms; +Cc: emacs-devel > Do I understand you correctly that `frame-notice-user-settings' and > `modify-all-frames-parameters' should set the `command-args-...' values > (one for the initial and one for the default frame)? > > Yes, that's what I've proposed. Do you see any flaws in the idea? > This would require > a non-trivial reorganization of frame.el. > > I think it should be pretty simple. Only 4 functions in frame.el > seem to refer to default-frame-alist or initial-frame-alist. > So I think that not much change would be needed. In addition I would have to change x-win.el, mac-win.el, pc-win.el, and w32-win.el for the x-handle-... stuff. > > Note that I was not looking into the command-line arguments and X > resources issues yet. > > Yes, but I think this same approach would work for x-win.el > and would be simple there too. So I would reflect any attempts to set `default-frame-alist' and `initial-frame-alist' via (1) command-line arguments, (2) x-resources, and (3) settings of `fringe-mode', `tool-bar-mode', `menu-bar-mode', and possibly `scroll-bar-mode' (I don't understand the latter yet) in the initial file, in two variables say `overriding-default-frame-alist' and `overriding-initial-frame-alist'. (I think the "command-" prefix is somewhat misleading for .emacs related settings, but I don't have a strong point here.) The final merging of parameters would then happen in `frame-initialize' for the initial and in `x-handle-named-frame-geometry' for additional frames where the "overriding-" parameters would be appropriately prepended. > > Customizing `fringe-mode' calls `modify-all-frames-parameters' which > > sets `default-frame-alist'. I'm now told that `default-frame-alist' was > > CHANGED outside Customize although all I actually did was _customizing_ > > some option. > > > > The solution to that is just to inform Custom about the change, so it > > will realize that the change to `default-frame-alist' was made within > > Custom. > > > > It's just a bug, it just needs to be fixed. > > I wouldn't know how. If I simply set `default-frame-alist' in some > "Custom" way I'll be told that there are unsaved changes. > > It looks like `customize-set-variable' does the right job. > > So I think this won't be very hard. Want to give it a try? I have to avoid an "Attempt to autoload customize-set-variable while preparing to dump" error here. Hence setting `default-frame-alist' via `customize-set-variable' would have to be forked by an optional argument to `modify-all-frames-parameters'. Such an optional argument would then have to be passed down by `set-fringe-mode-1' to `set-fringe-mode', for example, and similarly for the others. Correct? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "CHANGED outside Customize" in frames customization group 2008-01-01 10:24 ` martin rudalics @ 2008-01-03 9:50 ` Richard Stallman 2008-01-03 19:32 ` martin rudalics 0 siblings, 1 reply; 21+ messages in thread From: Richard Stallman @ 2008-01-03 9:50 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel That is true. It's somewhat of an annoyance. Do you see any other solution? So I would reflect any attempts to set `default-frame-alist' and `initial-frame-alist' via (1) command-line arguments, (2) x-resources, and (3) settings of `fringe-mode', `tool-bar-mode', `menu-bar-mode', and possibly `scroll-bar-mode' (I don't understand the latter yet) in the initial file, in two variables say `overriding-default-frame-alist' and `overriding-initial-frame-alist'. Yes, that is the solution I am proposing. (I think the "command-" prefix is somewhat misleading for .emacs related settings, but I don't have a strong point here.) I agree. I have to avoid an "Attempt to autoload customize-set-variable while preparing to dump" error here. Yes, but why would that error happen? Hence setting `default-frame-alist' via `customize-set-variable' would have to be forked by an optional argument to `modify-all-frames-parameters'. I don't follow you there. Does `modify-all-frames-parameters' get called during building Emacs? If so, maybe that is itself the bug. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "CHANGED outside Customize" in frames customization group 2008-01-03 9:50 ` Richard Stallman @ 2008-01-03 19:32 ` martin rudalics 2008-01-05 5:54 ` Richard Stallman 0 siblings, 1 reply; 21+ messages in thread From: martin rudalics @ 2008-01-03 19:32 UTC (permalink / raw) To: rms; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1573 bytes --] > That is true. It's somewhat of an annoyance. > Do you see any other solution? Not really. setqing and customizing are not compatible. > > So I would reflect any attempts to set `default-frame-alist' and > `initial-frame-alist' via (1) command-line arguments, (2) x-resources, > and (3) settings of `fringe-mode', `tool-bar-mode', `menu-bar-mode', and > possibly `scroll-bar-mode' (I don't understand the latter yet) in the > initial file, in two variables say `overriding-default-frame-alist' and > `overriding-initial-frame-alist'. > > Yes, that is the solution I am proposing. The problem is then that anyone who wants to know the current default settings can't tell them by just consulting `default-frame-alist' alone. Within Emacs currently just faces, fringe, cua-base, and erc do so, but there may exist packages beyond Emacs ... > I have to avoid an > > "Attempt to autoload customize-set-variable while preparing to dump" > > error here. > > Yes, but why would that error happen? It gets called by fringe.el. > > Hence setting `default-frame-alist' via > `customize-set-variable' would have to be forked by an optional argument > to `modify-all-frames-parameters'. > > I don't follow you there. Does `modify-all-frames-parameters' get called > during building Emacs? If so, maybe that is itself the bug. I suppose because there's no `fringe-mode-explicit' like there's a `scroll-bar-mode-explicit'. The attached patch (naively copied from scroll-bar) would handle this facet. [-- Attachment #2: fringe.patch --] [-- Type: text/plain, Size: 1847 bytes --] *** fringe.el.~1.30.~ Wed Aug 29 08:28:06 2007 --- fringe.el Thu Jan 3 20:21:32 2008 *************** *** 93,98 **** --- 93,102 ---- (defvar fringe-mode) + (defvar fringe-mode-explicit nil + "Non-nil means `set-fringe-mode' should really do something. + This is nil while loading `fringe.el', and t afterward.") + (defun set-fringe-mode-1 (ignore value) "Call `set-fringe-mode' with VALUE. See `fringe-mode' for valid values and their effect. *************** *** 104,116 **** See `fringe-mode' for possible values and their effect." (setq fringe-mode value) ! (modify-all-frames-parameters ! (list (cons 'left-fringe (if (consp fringe-mode) ! (car fringe-mode) ! fringe-mode)) ! (cons 'right-fringe (if (consp fringe-mode) ! (cdr fringe-mode) ! fringe-mode))))) ;; For initialization of fringe-mode, take account of changes ;; made explicitly to default-frame-alist. --- 108,121 ---- See `fringe-mode' for possible values and their effect." (setq fringe-mode value) ! (when fringe-mode-explicit ! (modify-all-frames-parameters ! (list (cons 'left-fringe (if (consp fringe-mode) ! (car fringe-mode) ! fringe-mode)) ! (cons 'right-fringe (if (consp fringe-mode) ! (cdr fringe-mode) ! fringe-mode)))))) ;; For initialization of fringe-mode, take account of changes ;; made explicitly to default-frame-alist. *************** *** 159,164 **** --- 164,173 ---- :initialize 'fringe-mode-initialize :set 'set-fringe-mode-1) + ;; We just set fringe-mode, but that was the default. + ;; If it is set again, that is for real. + (setq fringe-mode-explicit t) + (defun fringe-query-style (&optional all-frames) "Query user for fringe style. Returns values suitable for left-fringe and right-fringe frame parameters. [-- Attachment #3: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "CHANGED outside Customize" in frames customization group 2008-01-03 19:32 ` martin rudalics @ 2008-01-05 5:54 ` Richard Stallman 2008-01-05 10:14 ` martin rudalics 0 siblings, 1 reply; 21+ messages in thread From: Richard Stallman @ 2008-01-05 5:54 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel The problem is then that anyone who wants to know the current default settings can't tell them by just consulting `default-frame-alist' alone. Within Emacs currently just faces, fringe, cua-base, and erc do so, but there may exist packages beyond Emacs ... That is a drawback, but not a disaster. It's better than the current situation. If someone suggests a better alternative, we can use it. Otherwise let's use this one. > I have to avoid an > > "Attempt to autoload customize-set-variable while preparing to dump" > > error here. > > Yes, but why would that error happen? It gets called by fringe.el. Sorry, I do not understand what that would imply. Can you give a complete explanation? I suppose because there's no `fringe-mode-explicit' like there's a `scroll-bar-mode-explicit'. The attached patch (naively copied from scroll-bar) would handle this facet. That looks good. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "CHANGED outside Customize" in frames customization group 2008-01-05 5:54 ` Richard Stallman @ 2008-01-05 10:14 ` martin rudalics 2008-01-06 18:10 ` Richard Stallman 0 siblings, 1 reply; 21+ messages in thread From: martin rudalics @ 2008-01-05 10:14 UTC (permalink / raw) To: rms; +Cc: emacs-devel > The problem is then that anyone who wants to know the current default > settings can't tell them by just consulting `default-frame-alist' alone. > Within Emacs currently just faces, fringe, cua-base, and erc do so, but > there may exist packages beyond Emacs ... > > That is a drawback, but not a disaster. It's better than the current > situation. Agreed. BTW, we now also have `window-system-default-frame-alist' which is not consulted by these either. > > I have to avoid an > > > > "Attempt to autoload customize-set-variable while preparing to dump" > > > > error here. > > > > Yes, but why would that error happen? > > It gets called by fringe.el. > > Sorry, I do not understand what that would imply. > Can you give a complete explanation? You can test this if you replace, in `modify-all-frames-parameters', `setq' by `customize-set-variable' as you suggested earlier and then remake Emacs. On my system making aborts with the "Attempt to ..." bug mentioned above. IIUC, someone noticed that this could constitute a problem for the scroll-bar case and handled this by introducing `scroll-bar-mode-explicit' but didn't care about doing the same thing for fringes. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "CHANGED outside Customize" in frames customization group 2008-01-05 10:14 ` martin rudalics @ 2008-01-06 18:10 ` Richard Stallman 2008-01-06 19:00 ` martin rudalics 0 siblings, 1 reply; 21+ messages in thread From: Richard Stallman @ 2008-01-06 18:10 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel IIUC, someone noticed that this could constitute a problem for the scroll-bar case and handled this by introducing `scroll-bar-mode-explicit' but didn't care about doing the same thing for fringes. Should the fringe code get the same handling as the scroll bar code? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "CHANGED outside Customize" in frames customization group 2008-01-06 18:10 ` Richard Stallman @ 2008-01-06 19:00 ` martin rudalics 2008-01-07 11:31 ` Richard Stallman 0 siblings, 1 reply; 21+ messages in thread From: martin rudalics @ 2008-01-06 19:00 UTC (permalink / raw) To: rms; +Cc: emacs-devel > Should the fringe code get the same handling as the scroll bar code? That's what I tried in my previous patch. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "CHANGED outside Customize" in frames customization group 2008-01-06 19:00 ` martin rudalics @ 2008-01-07 11:31 ` Richard Stallman 0 siblings, 0 replies; 21+ messages in thread From: Richard Stallman @ 2008-01-07 11:31 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel > Should the fringe code get the same handling as the scroll bar code? That's what I tried in my previous patch. If it works, and people don't find a problem, please install it. ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2008-01-07 11:31 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-12-29 9:44 "CHANGED outside Customize" in frames customization group martin rudalics 2007-12-29 15:51 ` Drew Adams 2007-12-29 16:14 ` Luc Teirlinck 2007-12-29 17:33 ` martin rudalics 2007-12-29 18:14 ` Drew Adams 2007-12-30 1:36 ` Richard Stallman 2007-12-29 17:48 ` Richard Stallman 2007-12-30 14:07 ` martin rudalics 2007-12-30 15:42 ` Richard Stallman 2007-12-30 18:18 ` martin rudalics 2007-12-30 22:58 ` Richard Stallman 2007-12-31 11:04 ` martin rudalics 2008-01-01 3:18 ` Richard Stallman 2008-01-01 10:24 ` martin rudalics 2008-01-03 9:50 ` Richard Stallman 2008-01-03 19:32 ` martin rudalics 2008-01-05 5:54 ` Richard Stallman 2008-01-05 10:14 ` martin rudalics 2008-01-06 18:10 ` Richard Stallman 2008-01-06 19:00 ` martin rudalics 2008-01-07 11:31 ` Richard Stallman
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.