Re: defcustom: changing from defvar - order of execution

Re: defcustom: changing from defvar - order of execution

[Stefan Monnier]

> I see things like this fairly commonly, at the top level of the standard
> Emacs libraries:

All these examples don't seem relevant since nowhere is it suggested to the
user to load the library in her .emacs.

> To me, it makes sense to generally avoid using user options at the top level
> of the library that defines them, but I'm not sure such avoidance is always
> feasible. In any case, as the above examples show, the standard libraries
> are themselves full of counter examples.

What makes more sense is to discourage loading of packages in .emacs.
Instead users should only set vars, setup autoloads, ...

> No doubt I'm still missing something - please help me understand. I want to
> fix the "bug in the elisp library" in question, but I don't know how to
> proceed. I want a user to be able to just load the library and go

Why would she need to load the library?


        Stefan

RE: defcustom: changing from defvar - order of execution

[Drew Adams]

    > I see things like this fairly commonly, at the top level of
    the standard
    > Emacs libraries:

    All these examples don't seem relevant since nowhere is it
    suggested to the user to load the library in her .emacs.

Fair enough. But if a user does end up loading such a library during startup
(i.e. via .emacs) - whether by autoload or explicit load, the problem
arises, no?

    > To me, it makes sense to generally avoid using user options
    at the top level
    > of the library that defines them, but I'm not sure such
    avoidance is always
    > feasible.

    What makes more sense is to discourage loading of packages in .emacs.
    Instead users should only set vars, setup autoloads, ...

Granted, but what if a user wants to systematically do something at startup
that is provided by a library? Autoload etc. are fine, but what if the user
wants to call a library-defined function at each startup? Whether it's a
command to show daily appointments or whatever...

Users do sometimes call functions at top level in their .emacs; those
functions are sometimes defined by libraries that are loaded by the .emacs
(whether via autoload, require, or load-library); and the called functions
sometimes depend on user options defined in those same libraries. Is this
just "bad practice" on the part of users?

Re: defcustom: changing from defvar - order of execution

[Per Abrahamsen]

"Drew Adams" <drew.adams@oracle.com> writes:

>   (defcustom align-load-hook nil
>     "*Hook that gets run after the aligner has been loaded."
>     :type 'hook
>     :group 'align)
>
>   (run-hooks 'align-load-hook)

Load hooks are rather special, and shouldn't be declared with
defcustom.  Anyone using a load hook should be comfortable with Emacs
Lisp.

> Here's another example:
>
>   (defcustom apropos-symbol-face 'bold
>     "*Face for symbol name in Apropos output, or nil for none."
>     :group 'apropos
>     :type 'face)
>
>   (define-button-type 'apropos-symbol
>     'face apropos-symbol-face
>     'help-echo "mouse-2, RET: Display more help on this symbol"
>     'follow-link t
>     'action #'apropos-symbol-button-display-help
>     'skip t)

Problematic in any case, since changing apropos-symbol-face from
customize will have no immidiate effect.  It would be better to have
apropos-symbol-face being an actual face, inheriting from bold.  But
because face inheritance wasn't in Emacs 19.0, Emacs is very
incosistent about when to use faces, and when to use variables
containing faces.  Also in new code, since bad habbits don't die
easily. 

>   (defcustom mouse-avoidance-mode nil...)
>   (if mouse-avoidance-mode
>       (mouse-avoidance-mode mouse-avoidance-mode))

Is there a :set in the defcustom?  Global minor mode variables should
have one, so changing the variable from customize will turn the minor
mode on or off.  This will also solve the initialization order problem
(with the risk of doing some unnecessary work).

> Here's another example:
>
>   (defcustom calculator-use-menu t ...)
>   (or calculator-mode-map
>       ...
>       (if (and calculator-use-menu ...

calculator-use-menu should be a global minor mode, see above.

> These examples are taken from just the first few standard Elisp libraries,
> sorted alphabetically. I could go on, but you get the idea.

As you see, the answer depends on the example.  But a common answer is
that if you need to depend on a user variable in the initialization,
the user variable should have a :set that undo the effect if the user
change it.

> How is the user's customization (via Customize) taken into account in such
> cases, if the custom-set-variables form is inserted at the _end_ of his
> .emacs or custom-file? It looks to me like the _library_ (default) values of
> such variables, not the user's customized values, will be used in the
> library.

The location in the .emacs file is just exposing the problem to more,
in all cases the problem would show up if the library was loaded from
the site initialization file, or even dumped with Emacs.

RE: defcustom: changing from defvar - order of execution

[Drew Adams]

Per Abrahamsen said:

    Load hooks ... shouldn't be declared with defcustom.
    ...
    Emacs is very incosistent about when to use faces [vs variables]
    ...
    calculator-use-menu should be a global minor mode

OK, I guess the standard libraries need a bit of cleanup in this regard.
These samples came from just the first few files. I know that Luc Teirlinck
already pointed out in emacs-devel that defcustoms for hooks were
problematic, and that there will perhaps be an effort to clean up such stuff
after release 23.

    As you see, the answer depends on the example.  But a common
    answer is that if you need to depend on a user variable in the
    initialization, the user variable should have a :set that undo
    the effect if the user change it.

Thanks; that guideline makes things a bit clearer. However, such use of :set
seems complex to me (perhaps just because I'm not yet used to it). I need to
look more at how it's used.

    The location in the .emacs file is just exposing the problem to
    more, in all cases the problem would show up if the library was
    loaded from the site initialization file, or even dumped

Yes. That's part of what I meant.

To come back to my original example, I guess the thing to do is this:

 - Ensure that libraries make no use of user options at the top level. IOW,
always encapsulate such use inside defun's (e.g. `foo-fn').

 - Tell the user (e.g. in library comments) that to use `foo-fn' at startup
it must be called *after* `custom-set-variables', not before:

     (load-library "foo")
     ...
     (custom-set-variables '(foovar t)...)
     ...
     (foo-fn)

-----------------------

The rest of this email is about the first of these guidelines, and it might
be somewhat off-topic for help-gnu-emacs.

I noticed that RMS said this recently in emacs-devel:

    Just loading appt.el probably should not activate the feature.
    In the 90s it was not unusual for packages to work that way,
    but when Custom was added it became common for a package to be
    loaded simply because someone wanted to customize a variable.
    So our convention, since then, is that just loading a package
    shouldn't really change anything.

Not only was this common in standard libraries before this century, but it
is still common for personal "libraries" - that is, .emacs and its
extensions. It is normal for the latter, IMO, as long as they don't contain
defcustom's.

I said this in emacs-devel on Feb 8:

    I hope and expect that (beyond the bugs) few
    libraries will ever need to change user options, at least
    not by simply being loaded. Most will a) define standard
    values for options or b) provide commands to set options
    or c) behave themselves properly by modifying only
    non-user-option variables.

    I should make a distinction here - there are libraries
    and libraries. There are libraries that are intended for
    use by multiple users, and there are libraries that are
    essentially custom files or personal extensions thereof.
    Multi-user libraries are the ones that should not step on
    user options. Personal libraries are made to set user options.

    Some libraries start out life as a personal library and
    end up being shared to some extent by others. In
    some cases, user-option settings in a library shared this
    way are not bothersome - if the person using the library has
    the same environment and wants to do the same thing, for
    instance. This is essentially just cutting and pasting code.

    In general, however, a library destined for multiple users
    should not contain user-option settings - that is bad form.

That is, some "libraries" are, in effect, .emacs settings (setq...) and
startup code that have been relegated to one or more separate files loaded
at startup. Lots of users do that, to help them organize their settings. (A
common use is to deal with different settings for different platforms.)

It might make sense to have a standard, recognizable (textual) way to
distinguish these two types of emacs-lisp files ("libraries"), so users (and
tools) could more easily apply the different kinds of guidelines to them.

A first step, I think, is recognizing the different kinds of file and
establishing clear guidelines for each. In particular, their treatment wrt
customize is likely to be quite different. For example:

 1) std library: defcustom, defun, etc. only - no top-level setq or function
calls etc.
 2) personal startup library: top-level function calls, setq etc. Executed
after custom-set-variables, usually.

Coming up with such guidelines would also help people migrate a personal
library to become a clean multi-user library. A complete set of such
guidelines would include heuristics, such as the :set rule Per mentioned,
for dealing with customize.

It is, I guess, thanks to the introduction of customize that the standard
libraries are being forced to become cleaner wrt initializing and activating
things. And customize considerations are driving the separation in form
between standard libraries and personal startup libraries. Things that were
commonly done in both a few years ago are now appropriate only for one or
the other.

customization; std vs. personal libraries

[ken]

Drew Adams wrote:

>Per Abrahamsen said:
>
>[....]
>
>The rest of this email is about the first of these guidelines, and it might
>be somewhat off-topic for help-gnu-emacs.
>
>I noticed that RMS said this recently in emacs-devel:
>
>    Just loading appt.el probably should not activate the feature.
>    In the 90s it was not unusual for packages to work that way,
>    but when Custom was added it became common for a package to be
>    loaded simply because someone wanted to customize a variable.
>    So our convention, since then, is that just loading a package
>    shouldn't really change anything.
>
>Not only was this common in standard libraries before this century, but it
>is still common for personal "libraries" - that is, .emacs and its
>extensions. It is normal for the latter, IMO, as long as they don't contain
>defcustom's.
>
>I said this in emacs-devel on Feb 8:
>
>    I hope and expect that (beyond the bugs) few
>    libraries will ever need to change user options, at least
>    not by simply being loaded. Most will a) define standard
>    values for options or b) provide commands to set options
>    or c) behave themselves properly by modifying only
>    non-user-option variables.
>
>    I should make a distinction here - there are libraries
>    and libraries. There are libraries that are intended for
>    use by multiple users, and there are libraries that are
>    essentially custom files or personal extensions thereof.
>    Multi-user libraries are the ones that should not step on
>    user options. Personal libraries are made to set user options.
>
>    Some libraries start out life as a personal library and
>    end up being shared to some extent by others. In
>    some cases, user-option settings in a library shared this
>    way are not bothersome - if the person using the library has
>    the same environment and wants to do the same thing, for
>    instance. This is essentially just cutting and pasting code.
>
>    In general, however, a library destined for multiple users
>    should not contain user-option settings - that is bad form.
>
>That is, some "libraries" are, in effect, .emacs settings (setq...) and
>startup code that have been relegated to one or more separate files loaded
>at startup. Lots of users do that, to help them organize their settings. (A
>common use is to deal with different settings for different platforms.)
>
>It might make sense to have a standard, recognizable (textual) way to
>distinguish these two types of emacs-lisp files ("libraries"), so users (and
>tools) could more easily apply the different kinds of guidelines to them.
>
>A first step, I think, is recognizing the different kinds of file and
>establishing clear guidelines for each. In particular, their treatment wrt
>customize is likely to be quite different. For example:
>
> 1) std library: defcustom, defun, etc. only - no top-level setq or function
>calls etc.
> 2) personal startup library: top-level function calls, setq etc. Executed
>after custom-set-variables, usually.
>
>Coming up with such guidelines would also help people migrate a personal
>library to become a clean multi-user library. A complete set of such
>guidelines would include heuristics, such as the :set rule Per mentioned,
>for dealing with customize.
>
>It is, I guess, thanks to the introduction of customize that the standard
>libraries are being forced to become cleaner wrt initializing and activating
>things. And customize considerations are driving the separation in form
>between standard libraries and personal startup libraries. Things that were
>commonly done in both a few years ago are now appropriate only for one or
>the other.
>  
>


Perhaps a step in that direction, along with a step towards being more
user friendly, would be to implement user configuration files, i.e.,
ascii files containing variables and values for configuring emacs. 
Certainly everyone here is familiar with these.  Most applications in
the world use them.  The config file(s) for apache is just one of many
examples.  If we think about it from the viewpoint of a new emacs user
(but someone who may be expert in many applications and systems), it's
rather strange to have to learn how to code elisp in order to perform
trivial configuration tasks, like setting fore- and background colors,
fonts, format of timestamps, user email addresses, etc.

Yes, I'm well aware that emacs users can avail themselves of Customize
and I've used this quite a bit myself.  But I've found it less than
satisfying on many occasions.  Oftentimes it's not readily apparent what
a setting there-- typically it's simply some elisp function-- is for or
what it will do, and I'm again confronted with the necessity of learning
elisp to configure something which is child's play to configure in
another application.  It's also much more difficult to find a setting in
all the menus in Customize than it would be simply to read or search
through a regular ascii file.  I can also put my own comments into an
ascii file whereas I wouldn't attempt to do this to Customize.

Some on this list will mark these words as heresy and somehow believe
that someone who's interested in simply typing up a couple webpages or
starting into their thesis paper should study and learn some elisp
first.  As entertaining as it might be to write code, it's not for
everyone and for many it's so far away from the big picture, from the
task at hand, that it rules out even trying emacs.

Because it would make configuration simpler, ascii config files would
lower the amount of support necessary such as on this list.  If thought
through sufficiently, libraries which use the same values-- e.g., ports
and protocols and server names and so on in gnus and vm-- could use the
same ascii file to fetch variables from.  Users wouldn't have to change
code in their ~/.emacs if they wanted to switch from one to the other. 
Upgrading would be simpler.  For developers, rewriting library functions
would be easier; making a change to a legacy function wouldn't break an
application.  Users ~/.emacs wouldn't fill up so much with code from
earlier emacs versions and which becomes useless after an upgrade.

Would it be so difficult to parse a configuration file for values to
plug into a function?

Finally, an ascii configuration file would also provide a listing of
variables pertinent to the user, perhaps helping to maintain the
separation, addressed by Drew, between standard libraries and personal
startup libraries.


-- 
A lot of us are working harder than we want, at things we don't like to
do.  Why? ...In order to afford the sort of existence we don't care to live.
	-- Bradford Angier

Re: customization; std vs. personal libraries

[Thien-Thi Nguyen]

ken <gebser@speakeasy.net> writes:

> If thought
> through sufficiently [...]

probably the result would be straight elisp or the customize facility.

> Would it be so difficult to parse a configuration file for values to
> plug into a function?

parsing is no big deal.  the difficulty lies in synchronization w/ the
other methods (straight elisp and customize facility), handling session
changes, handling syntax and/or semantic errors, providing useful help,
etc.  note that the customize facility has precisely the same problems
to overcome; another configuration format adds more hair w/o resolving
these and in fact compounds the problems.

> Finally, an ascii configuration file would also provide a listing of
> variables pertinent to the user, perhaps helping to maintain the
> separation, addressed by Drew, between standard libraries and personal
> startup libraries.

i think under the ideals of GNU (four freedoms), such a separation would
in time (over many years over many people (but obviously not all ;-))
diminish, by dint of source code being able to more easily flow from
"standard" to "personal" and back to "standard".  this ideal requires
questioning of authority, understanding of the mechanisms used by the
author, application of those mechanisms on a personal scale (becoming an
author in one's own right), and publishing the personalized methods (if
one is inclined to share).

the framework for this social process requires a language, and although
elisp is not perfect (by far) for the purpose of personalizing emacs'
behavior, it is superior to declarative languages (like config files),
which fail to satisfy deep personalization the way fashion fails to
satisfy deep personalization.

granted, there are those for whom fashion is enough, whose luxury is to
be satisfied w/ a choice of pre-fabbed, post-angst, artful artifact.  i
can understand that point of view, and suspect that many who would be
able to realize the config-file approach you advocate, can also see its
merit.  however, to realize it you have to hack elisp.  and once you've
started down that path (why are you fighting it, btw?), people and ideas
you find along the way may change your original intent and motivation.

thi

Re: customization; std vs. personal libraries

[Per Abrahamsen]

ken <gebser@speakeasy.net> writes:

> Perhaps a step in that direction, along with a step towards being more
> user friendly, would be to implement user configuration files, i.e.,
> ascii files containing variables and values for configuring emacs. 

Eh ".emacs" is an ASCII file containing variables and values for
configuring Emacs.

Are you being ironic, or complaining that the ASCII file uses the format 

   (setq VAR VAL)

instead of
  
   VAR = VAL

?

Re: customization; std vs. personal libraries

[Kevin Rodgers]

Per Abrahamsen wrote:
 > ken <gebser@speakeasy.net> writes:
 >>Perhaps a step in that direction, along with a step towards being more
 >>user friendly, would be to implement user configuration files, i.e.,
 >>ascii files containing variables and values for configuring emacs.
 >
 >
 > Eh ".emacs" is an ASCII file containing variables and values for
 > configuring Emacs.
 >
 > Are you being ironic, or complaining that the ASCII file uses the format
 >
 >    (setq VAR VAL)
 >
 > instead of
 >
 >    VAR = VAL
 >
 > ?

<group name="emacs">
   <group name="editing">
     <group name="editing-basics">
       <variable name="line-number-mode">nil</variable>
     </group>
   </group>
</group>

Just kidding,
-- 
Kevin Rodgers

Re: defcustom: changing from defvar - order of execution

[Stefan Monnier]

>> Not only was this common in standard libraries before this
>> century, but it is still common for personal "libraries" -
>> that is, .emacs and its extensions.

>     .emacs and its extensions are not libraries.  Extending the meaning of
>     libraries to things like .emacs makes the word useless.

> OK. What's a better term?

Who needs a better term.  The point is that *libraries* should not do
anything (other than define new feature) when they're loaded and thus, since
.emacs is not a library, this rule of thumb doesn't apply to it.

>  - It happens that personal startup files sometimes evolve into multi-user
> libraries, and these sometimes evolve into standard Emacs libraries.

And they have to change between those stages.


        Stefan

Re: defcustom: changing from defvar - order of execution

[Stefan Monnier]

> Not only was this common in standard libraries before this century, but it
> is still common for personal "libraries" - that is, .emacs and its
> extensions. It is normal for the latter, IMO, as long as they don't contain

.emacs and its extensions are not libraries.  Extending the meaning of
libraries to things like .emacs makes the word useless.


        Stefan

RE: defcustom: changing from defvar - order of execution

[Drew Adams]

    > Not only was this common in standard libraries before this
    > century, but it is still common for personal "libraries" -
    > that is, .emacs and its extensions.

    .emacs and its extensions are not libraries.  Extending the meaning of
    libraries to things like .emacs makes the word useless.

OK. What's a better term?

Use whatever term you like. I think I made clear what I was talking about. I
referred to them as "personal 'libraries'" (note quotes) and "libraries that
are essentially custom files or personal extensions".

Whatever term you use, I think it's important to recognize:

 - These different kinds of files have different properties and should be
associated with different guidelines.

 - It happens that personal startup files sometimes evolve into multi-user
libraries, and these sometimes evolve into standard Emacs libraries.

The guidelines for the different file types would help someone evolve a
personal file toward a multi-user library.

RE: defcustom: changing from defvar - order of execution

[Drew Adams]

    > Not only was this common in standard libraries before this
    > century, but it is still common for personal "libraries" -
    > that is, .emacs and its extensions.

    .emacs and its extensions are not libraries.  Extending the meaning of
    libraries to things like .emacs makes the word useless.

OK. What's a better term?

Use whatever term you like. I think I made clear what I was talking about. I
referred to them as "personal 'libraries'" (note quotes) and "libraries that
are essentially custom files or personal extensions".

Whatever term you use, I think it's important to recognize:

 - These different kinds of files have different properties and should be
associated with different guidelines.

 - It happens that personal startup files sometimes evolve into multi-user
libraries, and these sometimes evolve into standard Emacs libraries.

The guidelines for the different file types would help someone evolve a
personal file toward a multi-user library.

Re: defcustom: changing from defvar - order of execution

[Stefan Monnier]

>> I see things like this fairly commonly, at the top level of the standard
>> Emacs libraries:

>     All these examples don't seem relevant since nowhere is it
>     suggested to the user to load the library in her .emacs.

> Fair enough. But if a user does end up loading such a library during startup
> (i.e. via .emacs) - whether by autoload or explicit load, the problem
> arises, no?

Could be, but I haven't seen it mentioned very often so it doesn't seem to
be a common problem.  Probably because it requires that people edit their
.emacs by hand.  I think there are 3 common safe scenarios:
1 - for everything relating to package FOO the user uses only Custom.
2 - for everything relating to package FOO the user doesn't use Custom and
    does all the configuration by hand in her .emacs.
3 - the user mixes up the two, but is aware that the relative position of
    the manual customizations and of the custom-set-variables is important.

The only dangerous case is when the user mixes Custom and manual .emacs
editing and doesn't pay attention to the relative position of the two styles
of customization.

> Granted, but what if a user wants to systematically do something at startup
> that is provided by a library? Autoload etc. are fine, but what if the user
> wants to call a library-defined function at each startup? Whether it's a
> command to show daily appointments or whatever...

Then she'll put it at the end of her .emacs because otherwise other
customizations will be missing.  Duh!

Every once in a while someone comes here with exactly this problem, where
she put her (desktop-load-default) at the beginning of her .emacs instead of
putting it at the end.

There's really not much we can do, and this problem is not directly related
to Custom since it occurs with other things as well.


        Stefan

Re: defcustom: changing from defvar - order of execution

[Stefan Monnier]

> The user in setup #2 has never used the library, let's say (and so, does not
> have the setq in .emacs). The user knows nothing about setq and Lisp; he
> just copies the text "(load-library "foo")(foo-fn)", per the library
> comments, to his .emacs. He fires up Emacs, and then uses Customize to set
> and save foovar. This causes (custom-set-variables...) to be added to the
> end of his .emacs - after the load-library and the call to foo-fn.

> The user is then surprised to find that the customization had no effect: in
> subsequent Emacs sessions, load-library does the defcustom, which sets
> foovar to nil; and foo-fn then executes with foovar=nil, returning `t'.

> What am I missing?

That this situation you describe is just a bug in the elisp library.
Most likely in the comment that suggests "(load-library "foo")(foo-fn)",
but it's hard to say without more info.
In any case the scenario you describe doesn't seem to be common.


        Stefan

RE: defcustom: changing from defvar - order of execution

[Drew Adams]

    > The user in setup #2 has never used the library, let's say
    (and so, does not
    > have the setq in .emacs). The user knows nothing about setq
    and Lisp; he
    > just copies the text "(load-library "foo")(foo-fn)", per the library
    > comments, to his .emacs. He fires up Emacs, and then uses
    Customize to set
    > and save foovar. This causes (custom-set-variables...) to be
    added to the
    > end of his .emacs - after the load-library and the call to foo-fn.

    > The user is then surprised to find that the customization had
    no effect: in
    > subsequent Emacs sessions, load-library does the defcustom, which sets
    > foovar to nil; and foo-fn then executes with foovar=nil,
    returning `t'.

    > What am I missing?

    That this situation you describe is just a bug in the elisp library.
    Most likely in the comment that suggests "(load-library "foo")(foo-fn)",
    but it's hard to say without more info.
    In any case the scenario you describe doesn't seem to be common.

Dunno if it's a bug, but it certainly does not seem that _uncommon_. In my
example scenario, the user puts "(load-library "foo")(foo-fn)" in his
.emacs, but the problem arises, in particular, when library foo itself calls
`foo-fn' (or otherwise references `foovar') at the _top level_. That may not
be good practice (?), but it is not uncommon, and I'm not sure what the
proper fix is.

I see things like this fairly commonly, at the top level of the standard
Emacs libraries:

  (defcustom align-load-hook nil
    "*Hook that gets run after the aligner has been loaded."
    :type 'hook
    :group 'align)

  (run-hooks 'align-load-hook)

That is, I see code that: 1) does a defcustom and then 2) uses the value of
that user variable at the _top level_ of the same library (not just inside a
defun). Loading the library uses the value of the variable defined in the
file (unless the variable is somehow set earlier).

In this case, it looks to me like `align-load-hook' will be nil when
`run-hooks' is evaluated, unless the user somehow sets `align-load-hook'
_before_ this library is loaded. Having custom-set-variables set the
variable at the end of the user's .emacs will be too late, if the user loads
this library before that.

Here's another example:

  (defcustom apropos-symbol-face 'bold
    "*Face for symbol name in Apropos output, or nil for none."
    :group 'apropos
    :type 'face)

  (define-button-type 'apropos-symbol
    'face apropos-symbol-face
    'help-echo "mouse-2, RET: Display more help on this symbol"
    'follow-link t
    'action #'apropos-symbol-button-display-help
    'skip t)

In this case, `apropos-symbol-face' will be `bold' when define-button-type
is run, unless the user somehow sets `apropos-symbol-face' _before_ this
library is loaded. (This code cannot just be an old throw-back, because
`define-button-type' is a new function.)

Here's another example:

  (defcustom mouse-avoidance-mode nil...)
  (if mouse-avoidance-mode
      (mouse-avoidance-mode mouse-avoidance-mode))

Here's another example:

  (defcustom calculator-use-menu t ...)
  (or calculator-mode-map
      ...
      (if (and calculator-use-menu ...

These examples are taken from just the first few standard Elisp libraries,
sorted alphabetically. I could go on, but you get the idea.

How is the user's customization (via Customize) taken into account in such
cases, if the custom-set-variables form is inserted at the _end_ of his
.emacs or custom-file? It looks to me like the _library_ (default) values of
such variables, not the user's customized values, will be used in the
library.

To me, it makes sense to generally avoid using user options at the top level
of the library that defines them, but I'm not sure such avoidance is always
feasible. In any case, as the above examples show, the standard libraries
are themselves full of counter examples.

No doubt I'm still missing something - please help me understand. I want to
fix the "bug in the elisp library" in question, but I don't know how to
proceed. I want a user to be able to just load the library and go - not have
to execute foo-fn interactively, but I want the library to take the user's
customized value of foovar into account.

Thanks,

  Drew

defcustom: changing from defvar - order of execution

[Drew Adams]

I'm unclear on the recommended way to change Lisp code from using defvar for
user options to using defcustom. I guess I'm also unclear on just how
defcustom and Customize work. I couldn't find an explanation of this in Info
for Emacs or Emacs Lisp.

Initial setup - library foo.el has this:

 (defvar foovar nil)
 (defun foo-fn () foovar)

Initial setup - user has this in .emacs:

 (defvar foovar t)
 (load-library "foo")
 (foo-fn)

When .emacs is loaded, (foo-fn) is executed, foovar is `t', so (foo-fn)
returns `t'.


Second setup - library foo.el has this:

 (defcustom foovar nil)
 (defun foo-fn () foovar)

Second setup - user has this in .emacs, after customizing foovar to `t' with
Customize:

 (load-library "foo")
 (foo-fn)
 ...
 (custom-set-variables '(foovar t)...)

When .emacs is loaded, (foo-fn) is executed, foovar is (has default value)
`nil', so (foo-fn) returns `nil'.

That is, because (custom-set-variables...) is executed after (foo-fn), it
has no effect during foo-fn's execution.

What am I missing/confusing here? What is the proper way for library foo.el
to move from using defvar to using defcustom? Also, what difference does it
make, if any, whether a defcustom is executed at the top level or a lower
level of a file.

Thanks. - Drew

RE: defcustom: changing from defvar - order of execution

[Drew Adams]

Oops - before someone gripes about users using defvar for variables that are
defined in libraries, let me change the initial user setup from this:

     (defvar foovar t)
     (load-library "foo")
     (foo-fn)

to this:

     (setq foovar t)
     (load-library "foo")
     (foo-fn)

I don't think it changes my overall question, in any case. Thanks. - Drew



    -----Original Message-----
    I'm unclear on the recommended way to change Lisp code from
    using defvar for user options to using defcustom. I guess I'm
    also unclear on just how defcustom and Customize work. I
    couldn't find an explanation of this in Info for Emacs or Emacs Lisp.

    Initial setup - library foo.el has this:

     (defvar foovar nil)
     (defun foo-fn () foovar)

    Initial setup - user has this in .emacs:

     (defvar foovar t)
     (load-library "foo")
     (foo-fn)

    When .emacs is loaded, (foo-fn) is executed, foovar is `t', so
    (foo-fn) returns `t'.


    Second setup - library foo.el has this:

     (defcustom foovar nil)
     (defun foo-fn () foovar)

    Second setup - user has this in .emacs, after customizing
    foovar to `t' with Customize:

     (load-library "foo")
     (foo-fn)
     ...
     (custom-set-variables '(foovar t)...)

    When .emacs is loaded, (foo-fn) is executed, foovar is (has
    default value) `nil', so (foo-fn) returns `nil'.

    That is, because (custom-set-variables...) is executed after
    (foo-fn), it has no effect during foo-fn's execution.

    What am I missing/confusing here? What is the proper way for
    library foo.el to move from using defvar to using defcustom?
    Also, what difference does it make, if any, whether a defcustom
    is executed at the top level or a lower level of a file.

Re: defcustom: changing from defvar - order of execution

[Stefan Monnier]

>     Second setup - library foo.el has this:

>      (defcustom foovar nil)
>      (defun foo-fn () foovar)

>     Second setup - user has this in .emacs, after customizing
>     foovar to `t' with Customize:

>      (load-library "foo")
>      (foo-fn)
>      ...
>      (custom-set-variables '(foovar t)...)

>     When .emacs is loaded, (foo-fn) is executed, foovar is (has
>     default value) `nil', so (foo-fn) returns `nil'.

You're comparing two different elisp package code and two different .emacs
code.  Try to separate those two cases; it will help you understand
the problem.

E.g. changing the elisp package to use defcustom, but without the user
changing her .emacs will not result in any problem.

The problem comes when the user replaces her "setq at the beginning" with
a "custom-set-var at the end".

It's only weakly related to the use of custom since the same behavior
appears if you move the setq, or if you move the custom-set-var.


        Stefan

RE: defcustom: changing from defvar - order of execution

[Drew Adams]

    You're comparing two different elisp package code and two
    different .emacs code.  Try to separate those two cases;...

    E.g. changing the elisp package to use defcustom, but without the user
    changing her .emacs will not result in any problem.
    The problem comes when the user replaces her "setq at the
    beginning" with a "custom-set-var at the end".

    It's only weakly related to the use of custom since the same behavior
    appears if you move the setq, or if you move the custom-set-var.

Let me try to be clearer.

The only differences are these:

 - the library in setup #1 uses defvar;
   the library in setup #2 uses defcustom

 - the user in setup #1 uses setq at the beginning;
   the user in setup #2 customizes the variable using Customize,
   which adds (custom-set-variables...) at the end of .emacs

The user in setup #2 has never used the library, let's say (and so, does not
have the setq in .emacs). The user knows nothing about setq and Lisp; he
just copies the text "(load-library "foo")(foo-fn)", per the library
comments, to his .emacs. He fires up Emacs, and then uses Customize to set
and save foovar. This causes (custom-set-variables...) to be added to the
end of his .emacs - after the load-library and the call to foo-fn.

The user is then surprised to find that the customization had no effect: in
subsequent Emacs sessions, load-library does the defcustom, which sets
foovar to nil; and foo-fn then executes with foovar=nil, returning `t'.

What am I missing?

I'm not trying to suggest something is wrong with Emacs (e.g. Customization)
here, I'm just wondering how to use defcustom so that users can customize
things. Telling them that they need to either use setq or to move the
custom-set-variables form that Customize inserts at the end of .emacs seems
the wrong way to proceed. I assume that I must be doing something wrong wrt
the library definition, that if I do things correctly there should be no
such problem. So, what am I missing here?

Thanks,

  Drew

--- my original message ---

    I'm unclear on the recommended way to change Lisp code from
    using defvar for user options to using defcustom. I guess I'm
    also unclear on just how defcustom and Customize work. I
    couldn't find an explanation of this in Info for Emacs or Emacs Lisp.

    Initial setup - library foo.el has this:

     (defvar foovar nil)
     (defun foo-fn () foovar)

    Initial setup - user has this in .emacs:

     (defvar foovar t)
     (load-library "foo")
     (foo-fn)

    When .emacs is loaded, (foo-fn) is executed, foovar is `t', so
    (foo-fn) returns `t'.


    Second setup - library foo.el has this:

     (defcustom foovar nil)
     (defun foo-fn () foovar)

    Second setup - user has this in .emacs, after customizing
    foovar to `t' with Customize:

     (load-library "foo")
     (foo-fn)
     ...
     (custom-set-variables '(foovar t)...)

    When .emacs is loaded, (foo-fn) is executed, foovar is (has
    default value) `nil', so (foo-fn) returns `nil'.

    That is, because (custom-set-variables...) is executed after
    (foo-fn), it has no effect during foo-fn's execution.

    What am I missing/confusing here? What is the proper way for
    library foo.el to move from using defvar to using defcustom?
    Also, what difference does it make, if any, whether a defcustom
    is executed at the top level or a lower level of a file.

Re: defcustom: changing from defvar - order of execution

[rgb]

> I'm unclear on the recommended way to change Lisp code from
> using defvar for user options to using defcustom. I guess I'm
> also unclear on just how defcustom and Customize work. I
> couldn't find an explanation of this in Info for Emacs or Emacs Lisp.
>
It appears that defcustom acts just like defvar and
custom-set-variables acts much like setq.
So the position of your load command, with respect to the
custom-set-variables section is unimportant.
Obviously the position of your call to foo-fn IS important.

In my .emacs nothing comes before custom-set-variables.
But I notice that if the section doesn't already exist
it gets added at the end rather than the beginning.
I question the logic behind that.  Especially considering
the existence of options like :require and :set-after which
make the need for anything before it unlikely.
At least it doesn't move if it's present so you can put it
where you want and it will stay.

RE: defcustom: changing from defvar - order of execution

[Drew Adams]

    It appears that defcustom acts just like defvar and
    custom-set-variables acts much like setq.

Yes, wrt setting the value.

    So the position of your load command, with respect to the
    custom-set-variables section is unimportant.

Right, if the user uses setq. In my initial email the user used defvar,
which only takes effect if done before the load (with its own defvar or
defcustom).

    Obviously the position of your call to foo-fn IS important.

    In my .emacs nothing comes before custom-set-variables.
    But I notice that if the section doesn't already exist
    it gets added at the end rather than the beginning.
    I question the logic behind that.  Especially considering
    the existence of options like :require and :set-after which
    make the need for anything before it unlikely.
    At least it doesn't move if it's present so you can put it
    where you want and it will stay.

Yes, I am referring to the placement in .emacs, by Customize, of
custom-set-variables. Obviously, a user can reposition that at will, but, a
priori, a user will just let Customize place it, and it will be placed at
the end, after the load-library.