emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

shouldn't customize-save-variable raise an error if var is not an option


From: Drew Adams
Subject: shouldn't customize-save-variable raise an error if var is not an option?
Date: Tue, 26 Dec 2006 15:40:19 -0800

I don't know the answer, because I don't know if
`customize-save-variable' is intended to "work" by program on
variables that have not yet been declared using defcustom.
I can't find any doc that speaks to this.

It might be argued that some of what `customize-save-variable' does
makes sense, even to a (possibly existing) variable that is not yet
declared via defcustom (but might be in the future), but I think that
at least some of what `customize-save-variable' does should not be
done to a non-option variable.

The effect seems to be, in fact, to create an option, just as if
defcustom had been used. I am not sure if everything needed is done,
however. If not, isn't it misleading for a non-option variable to have
values for the properties `saved-value', `variable-comment', and
`saved-variable-comment'?  Might some programs that examine such
properties not be misled by this? Similarly, does it make sense for
the variable to be saved with the value to the user's custom file?
Maybe, maybe not, depending on what the design intends, and whether
the result of calling `customize-save-variable' is an option in all
aspects.

So, is it a bug for `customize-save-variable' not to first ensure that
its variable arg is an option, and raise an error otherwise?
Interactively, a non-option cannot be input, but a Lisp program can
call `customize-save-variable' on a non-option name and thus
effectively create an option, which thereafter can be customized
interactively. And `customize-save-variable' can also be used
interactively on such an option that was, in effect, created by a
Lisp call to `customize-save-variable'.

This all seems a bit fuzzy to me. If the design is thought to be
clear, then please at least document this in some way (the intention,
the behavior).


In GNU Emacs 22.0.91.1 (i386-mingw-nt5.1.2600)
 of 2006-12-11 on LENNART-69DE564
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Id:/g/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Dired by name

Minor modes in effect:
  encoded-kbd-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<menu-bar> <help-menu> <report-emacs-bug>

Recent messages:
(C:\Emacs-22-2006-12-11-Lennart\bin\emacs.exe -q --no-site-file --debug-init
C:\drews-lisp-20)
Loading encoded-kb...done
For information about the GNU Project and its goals, type C-h C-p.
Loading dired...
Loading regexp-opt...done
Loading dired...done
For information about the GNU Project and its goals, type C-h C-p.
Loading emacsbug...done





reply via email to

[Prev in Thread] Current Thread [Next in Thread]