[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "CHANGED outside Customize" in frames customization group

From: martin rudalics
Subject: Re: "CHANGED outside Customize" in frames customization group
Date: Mon, 31 Dec 2007 12:04:37 +0100
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

>     `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, 
>      >     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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]