Hi,
This is what I have heard so far. In the current mechanism
Con:
a) To correctly implement the configuration file, care must be taken
to handle the removed-but-not-purged state, which requires a file
existence test
b) One needs to make sure that user changes are not discarded.
Pro:
a) The mechanism is already in place
b) One can put in any code, not just auto loads, in the file loaded at
startup.
In the new directory proposed, one can put autolodas etc in a
non-configuration file that is loaded at startup
Pros:
a) This file is gone when the package is removed, so no file
existence check is required
b) Simple variable settings can be in the configuration file, and
they shall not harm anything if the file remains after removing
the package [Not strictly true, since there could be two
competing packages that set the same variable, or reset a variable
also used by upstream emacs -- I do not think simple variable
setting are quite as innocent as this]
Cons:
a) This requires changes in the emacsen common infrastructure
b) For anything other than autoloads, you probably still need
something similar ot the current mechanism anyway -- setting the
load-path, setting some variables that are not private to the
package, creating derived modes, etc.
On the balance, I do not see the benefit. Is a file existence
test so onerous? Does anyone have nay numbers on how long it takes?
manoj
--
Ferguson's Precept: A crisis is when you can't say "let's forget the
whole thing."
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
