GNU bug report logs - #4562
23.1; Customize State button problems

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 4562 in the body.
You can then email your comments to 4562 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 23.1; Customize State button problems
Date: Sat, 26 Sep 2009 11:37:07 -0700

emacs -Q
 
1. M-x customize-option default-frame-alist
 
The State text says "CHANGED outside Customize; operating on it here
may be unreliable.", which is untrue. This is immediately after using
`emacs -Q'.
 
2. Not only that, but the State menu shows `Undo Edits', even though
nothing has ever been edited.
 
3. If you in fact choose `Undo Edits', nothing happens, and `Undo
Edits' remains active in the State menu.
 
4. If you edit, e.g. click a DEL button, and then Set for Current
Session, and then you click `Reset to Backup', then the message says
"CHANGED outside Customize; operating on it here may be unreliable."
Again, this is incorrect - nothing was changed outside Customize.
 
In general, the State menu and its messages are pretty messed up.  It
is quite confusing and error prone.  Customize is supposed to be,
among other things, intended for non-Lisper novice users.  It's no
wonder that so many hate it or give up in disbelief or
incomprehension.
 

In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600)
 of 2009-07-29 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4)'
 

Message #10 received at 4562 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 4562 <at> debbugs.gnu.org
Subject: Re: bug#4562: 23.1; Customize State button problems
Date: Mon, 28 Sep 2009 01:41:05 -0400

> The State text says "CHANGED outside Customize; operating on it here
> may be unreliable.", which is untrue. This is immediately after using
> `emacs -Q'.

You misunderstand: "CHANGED outside Customize" doesn't mean "You changed
it", but instead it means "some Lisp code somewhere changed it without
telling Customize".  That Lisp code could be in your .emacs, but
not necesarily.  I hope this makes the rest of the behavior a bit more
understable (tho probably not completely clear since it seems some part
are indeed odd).

So what you have here is simply a bug where Emacs's startup code
modifies default-frame-alist without telling Customize about it.
IIUC it's not easy to fix it, because some of those changes are things
which shoujldn't be saved in the Custom version of default-frame-alist
(they are dynamically set at startup depending on your window-system
and/or command-line args).  I guess basically what it means is that
default-frame-alist shouldn't be a defcustom becaude we don't know how
to let Custom handle it correctly.


        Stefan

Message #15 received at 4562 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: <4562 <at> debbugs.gnu.org>
Subject: RE: bug#4562: 23.1; Customize State button problems
Date: Mon, 28 Sep 2009 01:54:14 -0700

> > The State text says "CHANGED outside Customize; operating on it here
> > may be unreliable.", which is untrue. This is immediately 
> > after using `emacs -Q'.
> 
> You misunderstand: "CHANGED outside Customize" doesn't mean 
> "You changed it", but instead it means "some Lisp code somewhere
> changed it without telling Customize".

I do understand that.

Perhaps I shouldn't have said "which is untrue". The point is that the message
is not helpful to users. It shouldn't be the case that a virgin session, without
loading anything else, starts out by saying that something changed the Customize
initial settings, that is, what Customize expects its virgin state to be isn't.

Unless you're saying that it is normal for the initial Customize state to be
that. In which case I don't know whether I would agree, but I would in any case
say it's not normal to state things in those terms to users at the outset.

> That Lisp code could be in your .emacs, but
> not necesarily.  I hope this makes the rest of the behavior a bit more
> understable (tho probably not completely clear since it seems 
> some part are indeed odd).
> 
> So what you have here is simply a bug where Emacs's startup code
> modifies default-frame-alist without telling Customize about it.

That's what I'm talking about (though I don't know the details).

> IIUC it's not easy to fix it, because some of those changes are things
> which shoujldn't be saved in the Custom version of default-frame-alist
> (they are dynamically set at startup depending on your window-system
> and/or command-line args).  I guess basically what it means is that
> default-frame-alist shouldn't be a defcustom becaude we don't know how
> to let Custom handle it correctly.

I won't pronounce on any of that.

I will say that seeing that message at the outset is not a good thing. What the
right remedy is, I can't say. Maybe it _is_ normal to start out the way we do
(dunno), but in that case, we should at least suppress (fudge) the scary
message.

Message #20 received at 4562 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 4562 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#4562: 23.1; Customize State button problems
Date: Wed, 13 Jul 2011 15:57:46 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> So what you have here is simply a bug where Emacs's startup code
> modifies default-frame-alist without telling Customize about it.
> IIUC it's not easy to fix it, because some of those changes are things
> which shoujldn't be saved in the Custom version of default-frame-alist
> (they are dynamically set at startup depending on your window-system
> and/or command-line args).  I guess basically what it means is that
> default-frame-alist shouldn't be a defcustom becaude we don't know how
> to let Custom handle it correctly.

So should we just change `default-frame-alist' to a `defvar'?

I can't even find the custom definition of this variable.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #23 received at 4562 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Lars Magne Ingebrigtsen'" <larsi <at> gnus.org>,
	"'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 4562 <at> debbugs.gnu.org
Subject: RE: bug#4562: 23.1; Customize State button problems
Date: Wed, 13 Jul 2011 08:25:37 -0700

> So should we just change `default-frame-alist' to a `defvar'?

Certainly not.  This is an important user option.

Likewise all the other `*-frame-alist' options.

Message #26 received at 4562 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 4562 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
	Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#4562: 23.1; Customize State button problems
Date: Wed, 13 Jul 2011 11:59:03 -0400

Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:

> So should we just change `default-frame-alist' to a `defvar'?
>
> I can't even find the custom definition of this variable.

The custom definition is in cus-start.el; that's where we put custom
definitions for built-in variables.

But the original bug no longer exists:

> 1. M-x customize-option default-frame-alist
>
> The State text says "CHANGED outside Customize; operating on it here
> may be unreliable.", which is untrue. This is immediately after using
> `emacs -Q'.

Several moons ago, I changed the frame code so that default-frame-alist
interacts properly with customize.  In particular, the default value is
now nil.  So this is a zombie bug; I'm closing it.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.