emacs-devel
[Top][All Lists]
Advanced

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

Re: Customize Rogue


From: Per Abrahamsen
Subject: Re: Customize Rogue
Date: Thu, 13 Mar 2003 22:59:42 +0100
User-agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.1 (sparc-sun-solaris2.8)

David Masterson <address@hidden> writes:

> John Wiegley has a tool called initsplit.el on his web-site for
> breaking customizations into multiple files. 

Fine, but the user should not then try to change these values
permanently through the Customize interface, as this will have no
effect.  Therefore the 'saved-value' attribute *not* be set for these
values, which was what I stated in the message you replied to.

> The issue (I believe) is why load all the customization information
> for a package into Emacs if you're not going to load the package (at
> least during this particular session)?

Because it is faster to do it than to check whether you need to do it?

I'd be very surprised if anyone can provide measured numbers
demonstrating that splitting customization information into multiple
lazy-loaded files make Emacs upstart faster than when the variables is
stored in a single custom-set-variables section in .emacs.  Note that
custom-set-variables itself is lazy, it will not actually evaluate the
values much or set the variables until the relevant packages have been
loaded.  So the only time saved is parsing, and parsing Lisp is
trivial.

> Also, it would allow you to keep the customizations for a
> package close to (in the sense of your .emacs files) everything else
> associated with the package.  Different people (I guess) have
> different levels of what they consider to be a "tidy" .emacs file.

Customize will probably never be the tool for people who want a "tidy"
custom-file, hand written Lisp can always be cleaner.

> However, you've got a good point that I can't think how customize
> would be able to find and set the customizations once they've been
> "split" into multiple locations -- regardless whether the split was
> done in customize fashion (a la initsplit.el) or via setq like things
> (a la set-activate).

Uh, does initsplit.el use multiple custom-set-variables?  That is
guarenteed to cause problems whenever the user tries to modify the
variables.  If so, it *really* should use setq (or a set-activate
woralike) instead.

Maybe the existence if initsplit.el is an argument for including
set-activate in Emacs, to make it easier to write such tools.  It is
hard for automated tools to read doctrings to find the proper Lisp
function to set the variable.





reply via email to

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