"CHANGED outside Customize" in frames customization group

"CHANGED outside Customize" in frames customization group

[martin rudalics]

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?

RE: "CHANGED outside Customize" in frames customization group

[Drew Adams]

> 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. ;-)

Re: "CHANGED outside Customize" in frames customization group

[Luc Teirlinck]

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.

Re: "CHANGED outside Customize" in frames customization group

[martin rudalics]

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

Re: "CHANGED outside Customize" in frames customization group

[Richard Stallman]

    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.)

RE: "CHANGED outside Customize" in frames customization group

[Drew Adams]

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

Re: "CHANGED outside Customize" in frames customization group

[Richard Stallman]

    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.

Re: "CHANGED outside Customize" in frames customization group

[martin rudalics]

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

Re: "CHANGED outside Customize" in frames customization group

[Richard Stallman]

    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.

Re: "CHANGED outside Customize" in frames customization group

[martin rudalics]

 >     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'?

Re: "CHANGED outside Customize" in frames customization group

[Richard Stallman]

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

Re: "CHANGED outside Customize" in frames customization group

[martin rudalics]

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

Re: "CHANGED outside Customize" in frames customization group

[Richard Stallman]

    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?

Re: "CHANGED outside Customize" in frames customization group

[martin rudalics]

 >     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?

Re: "CHANGED outside Customize" in frames customization group

[Richard Stallman]

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.

Re: "CHANGED outside Customize" in frames customization group

[martin rudalics]

[-- 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

Re: "CHANGED outside Customize" in frames customization group

[Richard Stallman]

    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.

Re: "CHANGED outside Customize" in frames customization group

[martin rudalics]

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

Re: "CHANGED outside Customize" in frames customization group

[Richard Stallman]

      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?

Re: "CHANGED outside Customize" in frames customization group

[martin rudalics]

> Should the fringe code get the same handling as the scroll bar code?

That's what I tried in my previous patch.

Re: "CHANGED outside Customize" in frames customization group

[Richard Stallman]

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