Customization problem

Customization problem

[Herbert Euler]

My customizations was cleared when I put some code into my ~/.emacs
and got error when loading this file.  This is because one of my
prefered package (Icicles mode by Drew Adams --
http://www.emacswiki.org/cgi-bin/wiki/Icicles_-_Libraries) tries to
save a customized variable when Emacs is killed.  It adds an entry to
`kill-emacs-hook', and `customize-save-variable' is invoked in this
entry.

`customize-save-variable' will invoke `custom-save-all', which will
flush all the customizations.  If some of the customizations (or
worse, all of the customizations) are not loaded when invoking
`custom-save-all', they will be wiped out.  This can happen when the
user loads a package that will save customizations, but Emacs is not
initialized successfully, and the user tries to quit Emacs when she/he
sees the error message.  That is why my customizations were cleared.

It seems Emacs loads customizations after it executes rests in the
init file.  Can the possiblility of clearing customizations be avoided
by loading them before taking any other actions specified in the init
file?

Regards,
Guanpeng Xu

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

Re: Customization problem

[Richard Stallman]

    `customize-save-variable' will invoke `custom-save-all', which will
    flush all the customizations.  If some of the customizations (or
    worse, all of the customizations) are not loaded when invoking
    `custom-save-all', they will be wiped out.

We could prevent this if we could detect whether all customizations
(if any) have been loaded, and set a flag.  Then we could make
`customize-save-variable' give an error if the flag is not set.

The question is what criterion to use.  Loading of the init file
with no errors?

Re: Customization problem

[Herbert Euler]

>The question is what criterion to use.  Loading of the init file
>with no errors?

Take `custom-save-variables' as example.  It searches in `obarray'
for all symbols that should be saved:

<lisp/cus-edit.el, in the body of `custom-save-variables'>
      (mapatoms
       (lambda (symbol)
         (if (and (get symbol 'saved-value)
                  ;; ignore theme values
                  (or (null (get symbol 'theme-value))
                      (eq 'user (caar (get symbol 'theme-value)))))
             (nconc saved-list (list symbol)))))

The criterion could be a symbol in `obarray'.  Before
`custom-save-variables' searching in it, it first insure the symbol
is interned.

We can apply this for the other similar functions, such as
`custom-save-faces'.

My question is, if `custom-save-variables' signals an error, what
can the user do?  The user wants to kill Emacs at that moment.
Can the user load all customizations when she/he sees the
error?

Regards,
Guanpeng Xu

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Customization problem

[Richard Stallman]

    The criterion could be a symbol in `obarray'.  Before
    `custom-save-variables' searching in it, it first insure the symbol
    is interned.

I don't understand this at all.

    My question is, if `custom-save-variables' signals an error, what
    can the user do?

The user will realize that the command he issued (the one that tries
to set a customization) cannot be used because of the previous error
(in loading the init file).

    Can the user load all customizations when she/he sees the
    error?

Who knows?  But I think often the answer will be no,
because Emacs tried that at startup and failed.

Re: Customization problem

[Herbert Euler]

>     The criterion could be a symbol in `obarray'.  Before
>     `custom-save-variables' searching in it, it first insure the symbol
>     is interned.
>
>I don't understand this at all.

For example, add a variable `custom-variables-loaded', which defaults
to nil, and add the expression

    (setq custom-variables-loaded t)

as the last expression of the function `custom-set-variables'.  Then,
`custom-save-variables' can test this variable to determine whether
to report an error.

Regards,
Guanpeng Xu

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Customization problem

[Richard Stallman]

    For example, add a variable `custom-variables-loaded', which defaults
    to nil, and add the expression

	(setq custom-variables-loaded t)

    as the last expression of the function `custom-set-variables'.  Then,
    `custom-save-variables' can test this variable to determine whether
    to report an error.

That will give the wrong result in the case where .emacs is successfully
loaded but there is no `custom-set-variables' in it.

Re: Customization problem

[Herbert Euler]

>     For example, add a variable `custom-variables-loaded', which defaults
>     to nil, and add the expression
>
>	(setq custom-variables-loaded t)
>
>     as the last expression of the function `custom-set-variables'.  Then,
>     `custom-save-variables' can test this variable to determine whether
>     to report an error.
>
>That will give the wrong result in the case where .emacs is successfully
>loaded but there is no `custom-set-variables' in it.

Currently, the user can save preferences and customizations into a
file, either ~/.emacs or a specified file.  More precisely, into the
file whose name is returned by `(custom-file)'.

The function `custom-file' works in this way: If the variable
`custom-file' is not nil, it returns the name of the file
`custom-file' points to.  Otherwise, it returns the name of
`user-init-file' (~/.emacs), if saving settings is permitted.

If we decide to protect the customizations from being cleared
accidentally, we must prevent the situation that a file which contains
the application of `custom-set-variables' is to be loaded but the
application of `custom-set-variables' in the file is not evaluated
(because of errors, for example) happening.

To achieve this, one of the following conditions must be satisfied:

[1] The application of `custom-set-variables' is evaluated before any
    other forms in a file.

[2] If a file contains the application of `custom-set-variables', the
    file is identified.  If the application of `custom-set-variables'
    in the file is not loaded, let `custom-save-variables' signal
    errors.  Otherwise, `custom-save-variables' just behaves as usual.

[3] If a file contains the application of `custom-set-variables', any
    error in the evaluation of the forms before the application is
    ignored so that the application of `custom-set-variables' is
    guaranteed to be evaluated.

[4] The mechanism of customizations saving is changed so that the
    application of `custom-set-variables' is guaranteed to be
    evaluated.

For [1] and [2], searching every file for the application of
`custom-set-variables' is a waste.  [3] is not acceptable.  For [4],
the current feature of user defined customization file has to be
disabled.  We could load a file `user-customizations.el' in
`loadup.el' or `startup.el', so the evaluation of the application of
`custom-set-variables' is separated from the user defined forms and
can be always evaluated successfully.

Regards,
Guanpeng Xu

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

Re: Customization problem

[Richard Stallman]

    If we decide to protect the customizations from being cleared
    accidentally, we must prevent the situation that a file which contains
    the application of `custom-set-variables' is to be loaded but the
    application of `custom-set-variables' in the file is not evaluated
    (because of errors, for example) happening.

That is mostly right.  We can't to prevent that from happening,
but it is enough to record that it happened, so we can disallow
saving if it happened.

(I think that's what you actually mean.)

    [1] The application of `custom-set-variables' is evaluated before any
	other forms in a file.

It would be both difficult and incorrect to evaluate them out of order.

    [2] If a file contains the application of `custom-set-variables', the
	file is identified.  If the application of `custom-set-variables'
	in the file is not loaded, let `custom-save-variables' signal
	errors.  Otherwise, `custom-save-variables' just behaves as usual.

That kind of approach is what I have in mind.

    [3] If a file contains the application of `custom-set-variables', any
	error in the evaluation of the forms before the application is
	ignored so that the application of `custom-set-variables' is
	guaranteed to be evaluated.

That would be incorrect and give strange results.

    [4] The mechanism of customizations saving is changed so that the
	application of `custom-set-variables' is guaranteed to be
	evaluated.

I can't see how that could possibly be coherent, though.

    For [1] and [2], searching every file for the application of
    `custom-set-variables' is a waste.

What do you mean by "every file"?  We know which file is supposed
to have the custom-set-variables call.  It is the one speciifed
by custom-file.

Do you want to work on [2]?

RE: Customization problem

[Drew Adams]

> What do you mean by "every file"?  We know which file is supposed
> to have the custom-set-variables call.  It is the one speciifed
> by custom-file.

I haven't followed everything written about this, but there is no guarantee
that only the user's custom-file will use `custom-set-variable'.

In this case, a third-party library uses `custom-set-variable'. This is done
via `kill-emacs-hook' using this function:

(defun icicle-control-reminder-prompt ()
  "If `icicle-reminder-prompt-flag' > 0, then decrement it and save it.
Used in `kill-emacs-hook'."
  (when (and (wholenump icicle-reminder-prompt-flag)
        (> icicle-reminder-prompt-flag 0))
    (condition-case nil
        (customize-save-variable
          'icicle-reminder-prompt-flag
          (1- icicle-reminder-prompt-flag))
      (error nil))))

FYI, option `icicle-reminder-prompt-flag' is defined as follows:

(defcustom icicle-reminder-prompt-flag 20
  "*Whether to use `icicle-prompt-suffix' reminder in minibuffer prompt.
Nil means never use the reminder.
Non-nil means use the reminder, if space permits:
 An integer value means use only for that many Emacs sessions.
 t means always use it."
  :type
  '(choice
    (const
     :tag "Never use a reminder in the prompt" nil)
    (const
     :tag "Always use a reminder in the prompt" t)
    (integer
     :tag "Use a reminder in the prompt for this many sessions"
     :value 20))
  :group 'icicles)

The effect is that the value of this option is decremented each time you
quit Emacs, until it is zero. The purpose is to provide a learning aid for
the first N Emacs sessions (unless the option is customized to nil or t).

Re: Customization problem

[Richard Stallman]

    In this case, a third-party library uses `custom-set-variable'. This is done
    via `kill-emacs-hook' using this function:

    (defun icicle-control-reminder-prompt ()
      "If `icicle-reminder-prompt-flag' > 0, then decrement it and save it.
    Used in `kill-emacs-hook'."
      (when (and (wholenump icicle-reminder-prompt-flag)
	    (> icicle-reminder-prompt-flag 0))
	(condition-case nil
	    (customize-save-variable
	      'icicle-reminder-prompt-flag
	      (1- icicle-reminder-prompt-flag))
	  (error nil))))

It uses customize-save-variable.  It does not (that I can see)
use custom-set-variable.  custom-set-variable is only supposed
to be used in the user's custom file.

RE: Customization problem

[Drew Adams]

>     In this case, a third-party library uses 
>     `custom-set-variable'. This is done
>     via `kill-emacs-hook' using this function:
> 
>     (defun icicle-control-reminder-prompt ()
>       "If `icicle-reminder-prompt-flag' > 0, then decrement it 
>     and save it. Used in `kill-emacs-hook'."
>       (when (and (wholenump icicle-reminder-prompt-flag)
> 	    (> icicle-reminder-prompt-flag 0))
> 	(condition-case nil
> 	    (customize-save-variable
> 	      'icicle-reminder-prompt-flag
> 	      (1- icicle-reminder-prompt-flag))
> 	  (error nil))))
> 
> It uses customize-save-variable.  It does not (that I can see)
> use custom-set-variable.

You're right about that. 

Re: Customization problem

[Richard Stallman]

I fixed this problem, more or less.  Now it refuses to save
customizations in your init file if there was an error reading it.

However, if custom-file is set, it assumes there is no problem.  If
you use a separate custom file and you use it only for customizations,
I think there is no case where this goes wrong.