Changes in the arg list for custom-set-variables - how should it be handled

Changes in the arg list for custom-set-variables - how should it be handled

[Lennart Borgman]

I have seen that there are some changes in the arg list for
custom-set-variables from the current Emacs to CVS Emacs. For example for
global-font-lock-mode:

    '(global-font-lock-mode t nil (font-lock))

should be changed too

    '(global-font-lock-mode t nil (font-core))

Are the users supposed to take care of this or will Emacs be distributed
with some code to take care of this? I have sketched some code to take care
of this and if this is of interest I will finish it.

- Lennart

Re: Changes in the arg list for custom-set-variables - how should it behandled

[Stephan Stahl]

Hi Lennart.

Lennart Borgman said:

> I have seen that there are some changes in the arg list for
> custom-set-variables from the current Emacs to CVS Emacs. For example for
> global-font-lock-mode:
>
>     '(global-font-lock-mode t nil (font-lock))
>
> should be changed too
>
>     '(global-font-lock-mode t nil (font-core))
>
> Are the users supposed to take care of this or will Emacs be distributed
> with some code to take care of this? I have sketched some code to take care
> of this and if this is of interest I will finish it.

Cvs emacs does still work with '(global-font-lock-mode t nil (font-lock)) in
.emacs.  I have read something about it not being recommended (i think it was
some docstring) but i have seen nothing wrong with it.

An other thing is that when custom-set-variables fails to load the required
file the evaluation of .emacs stops.  I regularily use emacs 21.3 and cvs
emacs.  When cvs emacs changes (font-lock) to (font-core) emacs 21.3 will fail
to load .emacs.  Because of this i have ripped every line that requires a file
from custom-set-variable and use something like this instead:

...
(if (require 'rfn-eshadow "rfn-eshadow" t)
    (customize-set-variable 'file-name-shadow-mode t))

(if (or (require 'font-core "font-core" t)
	(require 'font-lock "font-lock" t))
    (customize-set-variable 'global-font-lock-mode t))
...

I think if some extra code is added to cvs emacs to handle those changed
requires this code should try not to break older emacsen :)
-- 
Stephan Stahl

Re: Changes in the arg list for custom-set-variables - how should it be handled

[Richard Stallman]

    I have seen that there are some changes in the arg list for
    custom-set-variables from the current Emacs to CVS Emacs. For example for
    global-font-lock-mode:

	'(global-font-lock-mode t nil (font-lock))

    should be changed too

	'(global-font-lock-mode t nil (font-core))

Stephan Stahl <stahl@eos.franken.de> pointed out that the user does
not need to make this change, but that the new form, when written by
Emacs, could make the init file fail to load in older Emacs versions.

This kind of thing occurs when :require is used in the defcustom
macro.  In this case it results from the following code in
define-minor-mode:

	       ,@(cond
		  ((not (and curfile require)) nil)
		  ((not (eq require t)) `(:require ,require))
		  (t `(:require
		       ',(intern (file-name-nondirectory
				  (file-name-sans-extension curfile))))))

This puts a :require into the defcustom generated for the minor mode.
The result is that loading the setting of the variable forces loading
of the file the variable is defined in.  I suppose the reason for this
is so that the :set function can work right, but in the case
of global-font-lock-mode it is unnecessary since font-core.el is
preloaded.

In cases where such a definition is autoloaded instead, autoload.el
could set up something to record the necessary information elsewhere,
so that setting the variable will load the right files.  That way, it
won't have to be recorded in the custom-set-variables call, and this
problem will not happen.

Would someone like to work on this?  Please respond if you want
to do it.

Re: Changes in the arg list for custom-set-variables - how should it be handled

[Richard Stallman]

I sent this message a few weeks ago, but nobody spoke up
to work on this.  Who would like to do this change?

    I have seen that there are some changes in the arg list for
    custom-set-variables from the current Emacs to CVS Emacs. For example for
    global-font-lock-mode:

	'(global-font-lock-mode t nil (font-lock))

    should be changed too

	'(global-font-lock-mode t nil (font-core))

Stephan Stahl <stahl@eos.franken.de> pointed out that the user does
not need to make this change, but that the new form, when written by
Emacs, could make the init file fail to load in older Emacs versions.

This kind of thing occurs when :require is used in the defcustom
macro.  In this case it results from the following code in
define-minor-mode:

	       ,@(cond
		  ((not (and curfile require)) nil)
		  ((not (eq require t)) `(:require ,require))
		  (t `(:require
		       ',(intern (file-name-nondirectory
				  (file-name-sans-extension curfile))))))

This puts a :require into the defcustom generated for the minor mode.
The result is that loading the setting of the variable forces loading
of the file the variable is defined in.  I suppose the reason for this
is so that the :set function can work right, but in the case
of global-font-lock-mode it is unnecessary since font-core.el is
preloaded.

In cases where such a definition is autoloaded instead, autoload.el
could set up something to record the necessary information elsewhere,
so that setting the variable will load the right files.  That way, it
won't have to be recorded in the custom-set-variables call, and this
problem will not happen.

Would someone like to work on this?  Please respond if you want
to do it.

Re: Changes in the arg list for custom-set-variables - how should it be handled

[Richard Stallman]

I sent this message a few weeks ago, but nobody spoke up
to work on this.  Who would like to do this change?

    I have seen that there are some changes in the arg list for
    custom-set-variables from the current Emacs to CVS Emacs. For example for
    global-font-lock-mode:

	'(global-font-lock-mode t nil (font-lock))

    should be changed too

	'(global-font-lock-mode t nil (font-core))

Stephan Stahl <stahl@eos.franken.de> pointed out that the user does
not need to make this change, but that the new form, when written by
Emacs, could make the init file fail to load in older Emacs versions.

This kind of thing occurs when :require is used in the defcustom
macro.  In this case it results from the following code in
define-minor-mode:

	       ,@(cond
		  ((not (and curfile require)) nil)
		  ((not (eq require t)) `(:require ,require))
		  (t `(:require
		       ',(intern (file-name-nondirectory
				  (file-name-sans-extension curfile))))))

This puts a :require into the defcustom generated for the minor mode.
The result is that loading the setting of the variable forces loading
of the file the variable is defined in.  I suppose the reason for this
is so that the :set function can work right, but in the case
of global-font-lock-mode it is unnecessary since font-core.el is
preloaded.

In cases where such a definition is autoloaded instead, autoload.el
could set up something to record the necessary information elsewhere,
so that setting the variable will load the right files.  That way, it
won't have to be recorded in the custom-set-variables call, and this
problem will not happen.

Would someone like to work on this?  Please respond if you want
to do it.