* Re: customize-rouge output with emacs -q --no-site-file
2005-02-04 22:17 ` Lennart Borgman
@ 2005-02-04 23:48 ` Luc Teirlinck
2005-02-05 0:47 ` Luc Teirlinck
2005-02-05 0:03 ` Luc Teirlinck
` (3 subsequent siblings)
4 siblings, 1 reply; 21+ messages in thread
From: Luc Teirlinck @ 2005-02-04 23:48 UTC (permalink / raw)
Cc: emacs-devel
The list of variables we are talking about may depend on the operating
system, the environment variables the user has set, the user's X
customization settings (usually in .Xdefaults) and of course, also
changes over time as Emacs' code changes. So you would need to use
mapatoms, as in the patch below.
I do _not_ believe that this patch is the right solution to the
problems. It solves the problem I described. But as I said, this was
just an example of the very large and very varied group of problems
that are involved.
Here is a second problem, which the patch does not solve. The warning
is now gone. So the user happily customizes one of these hook (or
alist or list) variables. He thereby hardwires environment and
.Xdefaults settings into his .emacs, which is bad, but not the worst
problem. If we now make changes to Emacs that require adding other
elements to these hooks, lists or alists, or removing elements, the
user does not get those values, because he hardwired the old value in
his .emacs.
One small example. I proposed calling vc-find-file-hook directly from
after-find-file. If we do that and if anybody made changes to
find-file-hook and saved them to .emacs, vc-find-file hook is
probably in the saved value and gets called twice, once from
after-find-file and once from the saved value of find-file-hook.
This double calling is probably just a slight inefficiency rather than
a disaster, but other things could make Emacs completely malfunction.
There is nothing we can do about that, we have to be able to make
changes in Emacs.
The "Changed outside Custom" warning for a variable should stay unless
we make _all aspects_ of customizing the variable completely safe.
It is _not_ safe, not even after the patch you proposed, to customize
any of the involved hooks, lists or alists using Custom. It is safe
to customize them in your .emacs as long as you use add-hook (for
hooks) or push (for lists) and do not use setq. If you use setq, you
get into exactly the same problem I described above for Custom, but
most people realize that you should normally not use setq for hooks
and something in the docstrings of the lists or alists should make it
clear that you should not use setq.
The second problem I described above is a second _example_ of the
problems involved. There is worse. I pointed out a third example
before. And that is not the last one either.
The patch below is intended _for experimentation purposes only_. It
is interesting to build a version of Emacs with it and experiment.
Why, after the patch `paragraph-ignore-fill-prefix' and
`parse-sexp-ignore-comments' are considered rogue variables in `emacs -q'
beats me. Their values are correct and nothing seems wrong with them.
===File ~/startup-diff======================================
*** startup.el 28 Dec 2004 09:50:38 -0600 1.337
--- startup.el 04 Feb 2005 15:47:50 -0600
***************
*** 785,790 ****
--- 785,796 ----
(cdr tool-bar-lines)
(not (eq 0 (cdr tool-bar-lines)))))))
+ (mapatoms
+ (lambda (symbol)
+ (and (boundp symbol)
+ (get symbol 'standard-value)
+ (put symbol 'standard-value (list symbol)))))
+
(let ((old-scalable-fonts-allowed scalable-fonts-allowed)
(old-font-list-limit font-list-limit)
(old-face-ignored-fonts face-ignored-fonts))
============================================================
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: customize-rouge output with emacs -q --no-site-file
2005-02-04 23:48 ` Luc Teirlinck
@ 2005-02-05 0:47 ` Luc Teirlinck
2005-02-05 17:39 ` Richard Stallman
0 siblings, 1 reply; 21+ messages in thread
From: Luc Teirlinck @ 2005-02-05 0:47 UTC (permalink / raw)
Cc: lennart.borgman.073, emacs-devel
>From my earlier message:
If we now make changes to Emacs that require adding other
elements to these hooks, lists or alists, or removing elements, the
user does not get those values, because he hardwired the old value in
his .emacs.
Actually, thinking about it, this particular problem can occur when
customizing _any_ hook, list or alist through Custom. Basically,
whenever you are not supposed to just setq an option, setting it
through Custom is dangerous, because you _are_ setq-ing it. For
instance, I have before-save-hook set through Custom. This is
currently not a rogue variable, no problem. But whenever somebody
would, say fix a bug or implement a new feature by adding a function
to before-save-hook, my Emacs will not see it. My .emacs will
override it. In other words, before-save-hook is not rogue now, but
anytime that I update my CVS, it could become rogue. Personally, I
will get rid of this entry in custom-set-variables and use add-hook in
my .emacs. Much safer.
Sincerely,
Luc.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: customize-rouge output with emacs -q --no-site-file
2005-02-05 0:47 ` Luc Teirlinck
@ 2005-02-05 17:39 ` Richard Stallman
0 siblings, 0 replies; 21+ messages in thread
From: Richard Stallman @ 2005-02-05 17:39 UTC (permalink / raw)
Cc: lennart.borgman.073, teirllm, emacs-devel
For
instance, I have before-save-hook set through Custom. This is
currently not a rogue variable, no problem. But whenever somebody
would, say fix a bug or implement a new feature by adding a function
to before-save-hook, my Emacs will not see it. My .emacs will
override it.
We could record customizations of such variables with instructions
of elements to add. (And perhaps, also, elements to remove.)
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: customize-rouge output with emacs -q --no-site-file
2005-02-04 22:17 ` Lennart Borgman
2005-02-04 23:48 ` Luc Teirlinck
@ 2005-02-05 0:03 ` Luc Teirlinck
2005-02-05 0:06 ` Luc Teirlinck
` (2 subsequent siblings)
4 siblings, 0 replies; 21+ messages in thread
From: Luc Teirlinck @ 2005-02-05 0:03 UTC (permalink / raw)
Cc: emacs-devel
Do not use the patch to startup.el I sent before. There is apparently
some bug in it. You could use customizations. Anyway, it would not
work anyway, even after figuring out what the bug is and fixing it, so
I am not going to try.
Sincerely,
Luc.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: customize-rouge output with emacs -q --no-site-file
2005-02-04 22:17 ` Lennart Borgman
2005-02-04 23:48 ` Luc Teirlinck
2005-02-05 0:03 ` Luc Teirlinck
@ 2005-02-05 0:06 ` Luc Teirlinck
2005-02-05 17:39 ` Richard Stallman
2005-02-05 1:56 ` Luc Teirlinck
2005-02-05 3:51 ` Luc Teirlinck
4 siblings, 1 reply; 21+ messages in thread
From: Luc Teirlinck @ 2005-02-05 0:06 UTC (permalink / raw)
Cc: emacs-devel
>From my previous message:
Do not use the patch to startup.el I sent before. There is apparently
some bug in it. You could use customizations.
I meant: You could loose customizations.
Sincerely,
Luc.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: customize-rouge output with emacs -q --no-site-file
2005-02-04 22:17 ` Lennart Borgman
` (2 preceding siblings ...)
2005-02-05 0:06 ` Luc Teirlinck
@ 2005-02-05 1:56 ` Luc Teirlinck
2005-02-05 3:51 ` Luc Teirlinck
4 siblings, 0 replies; 21+ messages in thread
From: Luc Teirlinck @ 2005-02-05 1:56 UTC (permalink / raw)
Cc: emacs-devel
Lennart Borgman wrote:
(defun startup-set-standard-value (symbol)
"Set the current value of SYMBOL as the standard value for Customize."
(when (boundp symbol)
(put symbol 'standard-value (list symbol))))
(startup-set-standard-value 'baud-rate)
Does that code not mean that the saved-value of baud-rate is always
going to be '(baud-rate), I mean the list containing the _symbol_
baud-rate, _not_ the value of baud-rate which you tried to record?
That is the bug I encountered when copying that code into a mapatoms
(and which I warned about earlier.)
Sincerely,
Luc.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: customize-rouge output with emacs -q --no-site-file
2005-02-04 22:17 ` Lennart Borgman
` (3 preceding siblings ...)
2005-02-05 1:56 ` Luc Teirlinck
@ 2005-02-05 3:51 ` Luc Teirlinck
2005-02-05 9:08 ` Lennart Borgman
4 siblings, 1 reply; 21+ messages in thread
From: Luc Teirlinck @ 2005-02-05 3:51 UTC (permalink / raw)
Cc: emacs-devel
I believe that the patch below is the correct way to do what you are
trying to do. It could at the very best be _part_ of a solution. It
does not solve the other problems I referred to, only the "Erase
Customization" one. As before, only provided _for experimentation
purposes_. _Not_ meant to be installed in CVS. When trying out code
experimenting with Custom, always make sure your .emacs, or whatever
your custom-file is, is properly backed up.
With this new code, I get 3 options after `emacs -q' and
`M-x customize-rogue":
debug-ignored-errors, default-frame-alist and user-mail-address.
I believe that I understand the last two as local peculiarities.
`debug-ignored-errors' is very special.
===File ~/startup-diff======================================
*** startup.el 28 Dec 2004 09:50:38 -0600 1.337
--- startup.el 04 Feb 2005 20:59:49 -0600
***************
*** 785,790 ****
--- 785,797 ----
(cdr tool-bar-lines)
(not (eq 0 (cdr tool-bar-lines)))))))
+ (mapatoms
+ (lambda (symbol)
+ (and (default-boundp symbol)
+ (get symbol 'standard-value)
+ (put symbol 'standard-value
+ (list (custom-quote (default-value symbol)))))))
+
(let ((old-scalable-fonts-allowed scalable-fonts-allowed)
(old-font-list-limit font-list-limit)
(old-face-ignored-fonts face-ignored-fonts))
============================================================
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: customize-rouge output with emacs -q --no-site-file
2005-02-05 3:51 ` Luc Teirlinck
@ 2005-02-05 9:08 ` Lennart Borgman
2005-02-05 14:51 ` Luc Teirlinck
2005-02-05 19:06 ` Luc Teirlinck
0 siblings, 2 replies; 21+ messages in thread
From: Lennart Borgman @ 2005-02-05 9:08 UTC (permalink / raw)
Cc: emacs-devel
----- Original Message -----
From: "Luc Teirlinck" <teirllm@dms.auburn.edu>
> I believe that the patch below is the correct way to do what you are
> trying to do. It could at the very best be _part_ of a solution. It
> does not solve the other problems I referred to, only the "Erase
> Customization" one. As before, only provided _for experimentation
> purposes_. _Not_ meant to be installed in CVS. When trying out code
> experimenting with Custom, always make sure your .emacs, or whatever
> your custom-file is, is properly backed up.
>
> With this new code, I get 3 options after `emacs -q' and
> `M-x customize-rogue":
>
> debug-ignored-errors, default-frame-alist and user-mail-address.
>
> I believe that I understand the last two as local peculiarities.
> `debug-ignored-errors' is very special.
Hi Luc,
Thanks for correcting my code. My suggestion was of course only for the
"Erase C" problem, but I do believe that this should be solved and I see no
big dangers with the solution.
I suppose you did not start with -q --no-site-file? I only get
debug-ignored-errors left over. I think this should be handled too (but
maybe you have more insight in this?).
I think we should use your code. However maybe we should keep track of the
variables we handle here? I suggest saving them in a list, say
startup-custom-rogue. This could be used for various purpose.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: customize-rouge output with emacs -q --no-site-file
2005-02-05 9:08 ` Lennart Borgman
@ 2005-02-05 14:51 ` Luc Teirlinck
2005-02-06 12:42 ` Richard Stallman
2005-02-05 19:06 ` Luc Teirlinck
1 sibling, 1 reply; 21+ messages in thread
From: Luc Teirlinck @ 2005-02-05 14:51 UTC (permalink / raw)
Cc: emacs-devel
Lennart Borgman wrote:
I suppose you did not start with -q --no-site-file? I only get
debug-ignored-errors left over. I think this should be handled too (but
maybe you have more insight in this?).
I did not use --no-site-file, because I do not have a site file. I
did _not_ use `emacs -Q', because I _wanted_ to include the effect of
environment variables, .Xdefaults and the like.
I only looked at `user-mail-address'. It is in the list because Emacs
sets it, outside Custom, _after_ reading the init files. The default
value depends on `mail-host-address' and the user could have
customized that one in .emacs, thereby changing the proper default for
`user-mail-address. I guess the other two are similar, but I did not
look at the details.
>From `(elisp)User Identification':
-- Variable: user-mail-address
This holds the nominal email address of the user who is using
Emacs. Emacs normally sets this variable to a default value after
reading your init files, but not if you have already set it. So
you can set the variable to some other value in your init file if
you do not want to use the default value.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: customize-rouge output with emacs -q --no-site-file
2005-02-05 14:51 ` Luc Teirlinck
@ 2005-02-06 12:42 ` Richard Stallman
2005-02-06 19:54 ` Luc Teirlinck
0 siblings, 1 reply; 21+ messages in thread
From: Richard Stallman @ 2005-02-06 12:42 UTC (permalink / raw)
Cc: lennart.borgman.073, emacs-devel
I only looked at `user-mail-address'. It is in the list because Emacs
sets it, outside Custom, _after_ reading the init files. The default
value depends on `mail-host-address' and the user could have
customized that one in .emacs, thereby changing the proper default for
`user-mail-address. I guess the other two are similar, but I did not
look at the details.
Perhaps we could set it up so that the "standard values" of these
variables are expressions that compute the proper default based on the
circumstances. Would these variables work right then?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: customize-rouge output with emacs -q --no-site-file
2005-02-06 12:42 ` Richard Stallman
@ 2005-02-06 19:54 ` Luc Teirlinck
0 siblings, 0 replies; 21+ messages in thread
From: Luc Teirlinck @ 2005-02-06 19:54 UTC (permalink / raw)
Cc: lennart.borgman.073, emacs-devel
Richard Stallman wrote:
Perhaps we could set it up so that the "standard values" of these
variables are expressions that compute the proper default based on the
circumstances. Would these variables work right then?
Actually user-mail-address _only_ becomes a rogue variable if you
apply the patch I sent for experimentation (but did not propose to
install in CVS), because it sets the standard value for this
particular option too early. If you do not apply that patch you get:
this option is unchanged from its standard setting.
for user-mail-address, but of course, plenty of _other_ options then
become rogue.
What it shows is that the patch I sent is too simplistic. (Something
I was actually afraid of.)
Sincerely,
Luc.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: customize-rouge output with emacs -q --no-site-file
2005-02-05 9:08 ` Lennart Borgman
2005-02-05 14:51 ` Luc Teirlinck
@ 2005-02-05 19:06 ` Luc Teirlinck
2005-02-05 19:52 ` Lennart Borgman
1 sibling, 1 reply; 21+ messages in thread
From: Luc Teirlinck @ 2005-02-05 19:06 UTC (permalink / raw)
Cc: emacs-devel
Lennart Borgman wrote:
My suggestion was of course only for the "Erase C" problem, but I
do believe that this should be solved and I see no big dangers with
the solution.
The danger is that it eliminates the "Changed outside Custom" warning.
At least the hooks, lists and alists among the variables are
absolutely _not_ safe to set through Custom (or with setq for that
matter), even after applying the patch I posted. You have to set them
in your .emacs using add-hook (for hooks) or add-to-list (for lists).
If you do not try to set the variables through Custom, you do not run
in the "Erase Customization" problem either.
Some proposed changes might make it safe to set them through Custom.
But it is not clear whether they are feasible and certainly not
whether they will be implemented for 21.4.
If they are not implemented for 21.4, then I believe that we should
make the "Changed outside Custom" warning much more explicit. Many
people do not even realize that "Changed outside Custom" is a warning
not to try to customize it through Custom.
Sincerely,
Luc.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: customize-rouge output with emacs -q --no-site-file
2005-02-05 19:06 ` Luc Teirlinck
@ 2005-02-05 19:52 ` Lennart Borgman
2005-02-05 21:16 ` Luc Teirlinck
0 siblings, 1 reply; 21+ messages in thread
From: Lennart Borgman @ 2005-02-05 19:52 UTC (permalink / raw)
Cc: emacs-devel
----- Original Message -----
From: "Luc Teirlinck" <teirllm@dms.auburn.edu>
> My suggestion was of course only for the "Erase C" problem, but I
> do believe that this should be solved and I see no big dangers with
> the solution.
>
> The danger is that it eliminates the "Changed outside Custom" warning.
But that is not really the problem here.
> At least the hooks, lists and alists among the variables are
> absolutely _not_ safe to set through Custom (or with setq for that
> matter), even after applying the patch I posted. You have to set them
> in your .emacs using add-hook (for hooks) or add-to-list (for lists).
> If you do not try to set the variables through Custom, you do not run
> in the "Erase Customization" problem either.
So there should perhaps be another warning?
^ permalink raw reply [flat|nested] 21+ messages in thread