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