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