Re: [CVS] f7, f8 bound..

[Alex Schroeder <alex@emacswiki.org>]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> You confuse me:  Suppose I set something with a setq and then, either
> earlier or later in my .emacs file, a customize statement sets a
> symbol property that has the same effect as my setq -- this means I
> have to think both about binding variables and symbol properties.
> Why?
>
> What mental model is leading you to think that two different kinds of
> expression are a good idea?  Or am I misunderstanding you.

The mental model I use is that custom and setq both change the values
of variables.  This leads to confusion if you use either more than
once -- because now order of evaluation is important.  This is true
for two setq, too.

The mental model does not say that the actual lisp expressions, must
be similar.  Often they are; sometimes they are not.  Custom is very
powerful.  When custom sets variables, it can do all kinds of funky
stuff:  The simplest example is perhaps this:

(defcustom whitespace-global-mode nil
  "Toggle global Whitespace mode.

Setting this variable directly does not take effect;
use either \\[customize] or the function `whitespace-global-mode'
\(which see)."
  :set (lambda (sym val)
	 (whitespace-global-mode (or val 0)))
  :initialize 'custom-initialize-default
  :type 'boolean
  :group 'whitespace
  :require 'whitespace)

Setting this variable via custom (such as when loading the
customizations at startup) will call the function
whitespace-global-mode.

Obviously a mental model that tries to understand custom on the basis
of setq is too limited to capture this.

My code does something else:

When you call defkeymap with a default value, the variable is set to
the default value.  Custom, however, saves only the *additions* to the
file.  This, because we don't want to save the entire global-map to
.emacs if the user adds a single keybinding, for example.

From this stance, having a variable with the standard value and
another variable with the additions for custom continues to fit the
mental model.

Hope that helps.

As to pretty printing and sharing -- that would indeed be nice, and
would not involve fancy tricks.  You could, for example, split the one
call to custom-set-variables into one call per variable.  The
simplicity of the current approach is saving:  You only need to search
for the one and only sexp that starts with custom-set-variables, and
replace it.  Finding all individual new custom-set-variable
statements, deleting them, and writing another set, opens the door to
lots of bugs.  Example (schematically):

Currently we use one sexp:

(custom-set-variables ((a 1) (b 2)))

If we explicitly allow (from a tech point of view!) the pasting and
copying, we'd have something like this:

(custom-set-variable a 1)
(custom-set-variable b 2)

But what do we do in this case:

(custom-set-variable a 1)
(when foo
  (custom-set-variable b 2))

We can easily find all the sexps and delete them.  But where do we
write the new customizations:  At the point of the first or the last
sexp we deleted?

Furthermore, assume when we save variables that -- when set -- should
enable a global minor mode.  We *could* save these commands as
required ("the Customize GUI that generates a readable .emacs file
that people can study, modify, and share, if they wish" -- perhaps
that translates to "lisp code similar to what i would write by hand").
Well, in that case we get into the kinds of problems lots of code
wizards get into:  We cannot eat the dogfood we write to files.

So discouraging people from manually fiddling with the save-file helps
us reduce the number of potential bugs.  We could now improve this
saving, or provide functions to import and export settings -- but I
for one do not care too much for it.

> Or are you thinking that people who use Customize are too ignorant
> to ever want to share or learn about Emacs?  Are you figuring that
> these people should be given a low grade, not for hackers, way to
> set values?  Are you thinking that hackers will never want to use
> Customize, even for setting things for which they think Customize is
> useful?

I do not understand the questions.  Is this sarcasm?  Sorry, English
is my third language.  Yes, sometimes custom is the right thing for
people that want to customize Emacs without learning lisp.  Sometimes
custom is the right thing for hackers that do not want to spend too
much time thinking about the complex datastructures they want to
modify (as one might see in Gnus, for example).  So all the options
you offer seem to be pretty narrow.

Personally, I do not use custom anymore at home, but I still use it
regularly at work.

Alex.