customize-rouge output with emacs -q --no-site-file

customize-rouge output with emacs -q --no-site-file

[Lennart Borgman]

Below is a list of the variables that customize-rouge shows when emacs is
started with emacs -q --no-site-file. It contains on my pc 32 variables.

Many of them are maybe easy to fix?  Perhaps could Customize in some cases
just be told that everything is ok? Perhaps should the "standard value" in
some cases be set to do that? Could such fixes be done before starting
`site-run-file'? At this point the values should be set. Should the current
values at this point not be the standard values?

For some options (like blink-cursor) this seems to be the way to do it.
There is a comment in startup.el saying it can not be done in the defcustom.
The same seems to be the case for tooltip-mode. For other options it should
perhaps be done differently.


*** customize-rouge options with emacs -q --no-site-file:
baud-rate
blink-cursor
completion-ignored-extensions
current-language-environment
custom-unlispify-tag-names
debug-ignored-errors
default-frame-alist
default-input-method
encoded-kbd-mode
eol-mnemonic-mac
eol-mnemonic-unix
exec-path
file-coding-system-alist
find-file-hook
find-file-visit-truename
help-event-list
keyboard-coding-system
menu-bar-mode
minibuffer-history-case-insensitive-variables
minibuffer-prompt-properties
mode-line-format
mouse-wheel-mode
normal-erase-is-backspace
pop-up-frame-function
same-window-buffer-names
same-window-regexps
selection-coding-system
shell-file-name
site-run-file
special-display-function
text-mode-hook
tooltip-mode

Re: customize-rouge output with emacs -q --no-site-file

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

> Below is a list of the variables that customize-rouge shows when emacs is
> started with emacs -q --no-site-file. It contains on my pc 32 variables.
>
> Many of them are maybe easy to fix?  Perhaps could Customize in some cases
> just be told that everything is ok? Perhaps should the "standard value" in
> some cases be set to do that? Could such fixes be done before starting
> `site-run-file'? At this point the values should be set. Should the
current
> values at this point not be the standard values?

At the moment I can not see any reason not to do this. Should not the values
just before loading `site-run-file' be the "standard values" for those
variables?

As it works now if you "Erase Customization" for those variables Emacs might
get into trouble. Therefore I attach some simple code for setting the
"standard-values" that I think should go into startup.el to avoid this
trouble.

[-- Attachment #2: startup-fix.el --]
[-- Type: application/octet-stream, Size: 1908 bytes --]

;;; Set standard values for defcustom that are missing this here.
;;
;; This code should go into startup.el just before executing loading
;; site-run-file.

(defun startup-set-standard-value (symbol)
  "Set the current value of SYMBOL as the standard value for Customize."
  (put symbol 'standard-value (list symbol)))

(startup-set-standard-value baud-rate)
(startup-set-standard-value blink-cursor)
(startup-set-standard-value completion-ignored-extensions)
(startup-set-standard-value current-language-environment)
(startup-set-standard-value custom-unlispify-tag-names)
(startup-set-standard-value debug-ignored-errors)
(startup-set-standard-value default-frame-alist)
(startup-set-standard-value default-input-method)
(startup-set-standard-value encoded-kbd-mode)
(startup-set-standard-value eol-mnemonic-mac)
(startup-set-standard-value eol-mnemonic-unix)
(startup-set-standard-value exec-path)
(startup-set-standard-value file-coding-system-alist)
(startup-set-standard-value find-file-hook)
(startup-set-standard-value find-file-visit-truename)
(startup-set-standard-value help-event-list)
(startup-set-standard-value keyboard-coding-system)
(startup-set-standard-value menu-bar-mode)
(startup-set-standard-value minibuffer-history-case-insensitive-variables)
(startup-set-standard-value minibuffer-prompt-properties)
(startup-set-standard-value mode-line-format)
(startup-set-standard-value mouse-wheel-mode)
(startup-set-standard-value normal-erase-is-backspace)
(startup-set-standard-value pop-up-frame-function)
(startup-set-standard-value same-window-buffer-names)
(startup-set-standard-value same-window-regexps)
(startup-set-standard-value selection-coding-system)
(startup-set-standard-value shell-file-name)
(startup-set-standard-value site-run-file)
(startup-set-standard-value special-display-function)
(startup-set-standard-value text-mode-hook)
(startup-set-standard-value tooltip-mode)

[-- 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: customize-rouge output with emacs -q --no-site-file

[Lennart Borgman]

> As it works now if you "Erase Customization" for those variables Emacs
might
> get into trouble. Therefore I attach some simple code for setting the
> "standard-values" that I think should go into startup.el to avoid this
> trouble.

And of course even simple code should be tested ;-)

Just in case someone is testing - it does not work - I will send new code.

Re: customize-rouge output with emacs -q --no-site-file

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

> At the moment I can not see any reason not to do this. Should not the
values
> just before loading `site-run-file' be the "standard values" for those
> variables?
>
> As it works now if you "Erase Customization" for those variables Emacs
might
> get into trouble. Therefore I attach some simple code for setting the
> "standard-values" that I think should go into startup.el to avoid this
> trouble.

I believe I have attached a working version now. When I test I see
customize-rogue sees no rogue variables. Though I have not tested actually
including this in startup.el.

(And I have learned the diff between rouge and rogue.)

[-- Attachment #2: startup-fix.el --]
[-- Type: application/octet-stream, Size: 1967 bytes --]

;;; Set standard values for defcustom that are missing this here.
;;
;; This code should go into startup.el just before executing loading
;; site-run-file.

(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)
(startup-set-standard-value 'blink-cursor)
(startup-set-standard-value 'completion-ignored-extensions)
(startup-set-standard-value 'current-language-environment)
(startup-set-standard-value 'custom-unlispify-tag-names)
(startup-set-standard-value 'debug-ignored-errors)
(startup-set-standard-value 'default-frame-alist)
(startup-set-standard-value 'default-input-method)
(startup-set-standard-value 'encoded-kbd-mode)
(startup-set-standard-value 'eol-mnemonic-mac)
(startup-set-standard-value 'eol-mnemonic-unix)
(startup-set-standard-value 'exec-path)
(startup-set-standard-value 'file-coding-system-alist)
(startup-set-standard-value 'find-file-hook)
(startup-set-standard-value 'find-file-visit-truename)
(startup-set-standard-value 'help-event-list)
(startup-set-standard-value 'keyboard-coding-system)
(startup-set-standard-value 'menu-bar-mode)
(startup-set-standard-value 'minibuffer-history-case-insensitive-variables)
(startup-set-standard-value 'minibuffer-prompt-properties)
(startup-set-standard-value 'mode-line-format)
(startup-set-standard-value 'mouse-wheel-mode)
(startup-set-standard-value 'normal-erase-is-backspace)
(startup-set-standard-value 'pop-up-frame-function)
(startup-set-standard-value 'same-window-buffer-names)
(startup-set-standard-value 'same-window-regexps)
(startup-set-standard-value 'selection-coding-system)
(startup-set-standard-value 'shell-file-name)
(startup-set-standard-value 'site-run-file)
(startup-set-standard-value 'special-display-function)
(startup-set-standard-value 'text-mode-hook)
(startup-set-standard-value 'tooltip-mode)

[-- 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: customize-rouge output with emacs -q --no-site-file

[Luc Teirlinck]

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

Re: customize-rouge output with emacs -q --no-site-file

[Luc Teirlinck]

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.

Re: customize-rouge output with emacs -q --no-site-file

[Luc Teirlinck]

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

Re: customize-rouge output with emacs -q --no-site-file

[Luc Teirlinck]

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

Re: customize-rouge output with emacs -q --no-site-file

[Luc Teirlinck]

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.

Re: customize-rouge output with emacs -q --no-site-file

[Luc Teirlinck]

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

Re: customize-rouge output with emacs -q --no-site-file

[Lennart Borgman]

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

Re: customize-rouge output with emacs -q --no-site-file

[Luc Teirlinck]

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.

Re: customize-rouge output with emacs -q --no-site-file

[Richard Stallman]

    I meant: You could loose customizations.

Didn't you mean "lose" rather than "loose"?

Re: customize-rouge output with emacs -q --no-site-file

[Richard Stallman]

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

Re: customize-rouge output with emacs -q --no-site-file

[Luc Teirlinck]

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.

Re: customize-rouge output with emacs -q --no-site-file

[Lennart Borgman]

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

Re: customize-rouge output with emacs -q --no-site-file

[Luc Teirlinck]

If anybody decides to still try to fix the
hook-and-similar-lists-and-alists problem for 21.4, then I am going to
let that person decide whether putting any such code in startup.el is
part of the solution he wants to propose.

Sincerely,

Luc.

Re: customize-rouge output with emacs -q --no-site-file

[Richard Stallman]

    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?

Re: customize-rouge output with emacs -q --no-site-file

[Luc Teirlinck]

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.

Re: customize-rouge output with emacs -q --no-site-file

[Richard Stallman]

    At the moment I can not see any reason not to do this. Should not the values
    just before loading `site-run-file' be the "standard values" for those
    variables?

The "standard value" is not just a value, it is an expression.  So I
think the right way to handle this is to set up the right expression,
one that will compute the value that now gets installed.

This would have to be done one variable at a time, but it is the
way that follows the design principles.

Re: customize-rouge output with emacs -q --no-site-file

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>

>     At the moment I can not see any reason not to do this. Should not the
values
>     just before loading `site-run-file' be the "standard values" for those
>     variables?
>
> The "standard value" is not just a value, it is an expression.  So I
> think the right way to handle this is to set up the right expression,
> one that will compute the value that now gets installed.
>
> This would have to be done one variable at a time, but it is the
> way that follows the design principles.

Yes, in principle, but I did not think of it here. It is a little bit
different situation. I would guess that the currently rogue symbols at a
"clean" startup just depends on some basic things that are not changed at
later points at execution. But it is just a guess.