emacs-devel
[Top][All Lists]
Advanced

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

RE: Emacs FAQ for Emacs 22.1


From: Drew Adams
Subject: RE: Emacs FAQ for Emacs 22.1
Date: Wed, 14 Dec 2005 10:31:10 -0800

    > I am not sure.  Perhaps either way is ok, or it may depend
    > on the context.

    While it depends in some manner on the context (the latter alternative
    is certainly not helpful when talking about Lisp data structures and
    programming practices), I think that with regard to .emacs forms, we
    should generally prefer advertising Custom.  It saves us from dealing
    with trouble from people who have in good faith used the wrong
    set-form on some variable (when does one need to use setq-default?),
    and who have, because of a lack of acquaintance with Lisp data
    structures, used the wrong or illegal sexp on the right hand side of
    stuff.

    People who use setq should be comfortable with reading and
    interpreting the documentation of variables.

    So I think that in the Emacs manual, we should generally focus on
    using customize.  There is nothing wrong with a chapter "how to
    achieve things with Lisp in your .emacs by hand" or so (cars come with
    service manuals, too), but for the general practice, I'd strongly
    suggest we recommend using the knobs and dials provided for the user
    where available instead of recommending fiddling with the engine
    yourself.

I generally agree with you here (focus on customize), except for relegating
all .emacs stuff to a separate section of the manual. It would be more
helpful, in general, to describe both methods together, for each individual
case (depending on the context). The customize method should of course be
emphasized and should be described first, but when the correponding Lisp
code for .emacs is _simple_ it should be presented too. IOW, I agree with
Romain about this.

Trying to do everything .emacs-related in a separate section of the manual
would be difficult and the result would be less useful, IMO. That doesn't
mean that we couldn't also have a section on .emacs practices (e.g. tips);
it just means that we shouldn't try to describe all the user-option Lisp
stuff in a .emacs section.

Of course, as you said, it all depends on the context.





reply via email to

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