help-gnu-emacs
[Top][All Lists]
Advanced

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

RE: re-loading an elisp file


From: Drew Adams
Subject: RE: re-loading an elisp file
Date: Sat, 5 Mar 2011 10:06:43 -0800

> > Sounds like you are discovering that `defvar' does not 
> > assign a variable a value if it already has one.  
> 
> Actually, I thought my computer had some corrupt memory... but then I
> googled and after a time read about it on a forum on the web.

Suit yourself, but I recommend starting with Emacs's own doc: `C-h r'.
Emacs Wiki is also a good resource: www.emacswiki.org.

> > This is a feature.
> 
> Hmm.  I've heard that said before.

Learn about it and you will convince yourself.
It is a very _useful_ feature.

But no one forces you to use it.  And certainly no one suggests that you use it
to do something it is not intended for.

> > `setq' and `setq-default' do, however.
> > But in general an Elisp library should not act this way, by 
> > design.  A personal init file is another story - there you might
> > want to use `setq' and `setq-default' in some cases.
> 
> The forum said that the simplest way to re-initialize a variable in
> elisp was to reboot emacs.

Sounds like a forum to avoid, or at least to read only judiciously.

> I thought, "that's knuckle-headed... can't be true."  But I guess it is.

No, of course it isn't true.

> Your work-around though-- changing all the defvar's to setq's--
> is preferable.

I did _not_ suggest that, and what I suggested is not a "workaround".  If you
read the cited forum only as carefully as you read what I wrote, then perhaps it
is not the forum's advice that was misguided...

Emacs Lisp gives you ways to assign values unconditionally - e.g. setq.

And it gives you ways to assign a value if there is not already a value - IOW,
to initialize a variable (_only_ initialize) - e.g., defvar, defcustom.

It's up to you to choose the right Emacs Lisp facilities to accomplish what you
want.

defvar and defcustom are used very often, precisely because of the feature of
being no-ops if the variable has already been set.  But if you want to set a
variable unconditionally each time you load a file, then do not try to use
defvar to do that.

In general, Emacs libraries are designed to be loadable without changing
existing user settings.  Typically a user has to invoke some command to make a
loaded library actually change some existing value.  And decades of user
experiences have shown this to be a good pattern.

User init files, on the other hand, often unconditionally set variables (e.g.
using setq or setq-default).  And those user settings are then respected by
libraries that are loaded - precisely because those libraries use defvar or
defcustom, not setq, for their initialization.

And even in user init files, practice over the years has tended to reduce the
habit of using setq in favor of taking advantage of Customize (defcustom).
There are several reasons for that, including type-checking and initialization
with side effects (i.e., initializing a variable can also call for other,
related initialization operations).

And with cleaner libraries to load nowadays (in general), the need for
re-assigning things in user init files has been reduced.  If a library does not
stomp on your initialized settings simply by loading it, then you need not
counter that by re-setting such things after loading the library.  In general,
your init file can now count on making its own settings without worrying about
the libraries it loads altering those settings.

Changing variable values simply by loading a file can be particularly
problematic when the sexp defining the value is not a constant.  IOW, (setq foo
42) is one thing, but (setq foo (+ foo 42)) and (setq foo (oracle-at-delphi))
are something else again.

Consider this as friendly advice.  If it helps, fine.  If not, ignore.




reply via email to

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