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

Previous Next

Full log

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.

Previous Next

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