>>>>> "Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
Chris> [EMAIL PROTECTED] (Karl M. Hegbloom) writes:
>> I think you're making a mountain out of a molehill.
Chris> I have one question: is this going to be transparent to
Chris> *all* existing users? If the answer is yes, then this
Chris> might be acceptable. Otherwise, I have to agree with the
Chris> naysayers that it's a terrible idea. (And I'm not sure you
Chris> *can* make it *totally* transparent, for reasons I'll
Chris> elucidate on request.)
When XEmacs starts up, it first reads `site-start.el', which will be
a Debian specific file that will make it run the stuff down in
/etc/xemacs.d. (As specified by the emacsen-common package). After
the site inits run, it will load `user-init-file'. `user-init-file'
used to be "~/.emacs", which is the same file that GNU Emacs reads.
Right after it loads and evaluates `user-init-file', it checks to see
whether `custom-file' has been changed from the default value by the
user's `user-init-file'. If it is still the default value, then
`custom-file' is loaded (by code in `startup.el'). After that, the
site-wide `default.el' is processed, if it exists.
What I've done is change the _default_ values of `user-init-file' and
`custom-file' to "~/.xemacs/init.el" and "~/.xemacs/.options.el",
respectivly. "~/.emacs" is NOT touched _unless_ you put something
like...[1]
(setq user-init-file (expand-file-name "~/.emacs")
custom-file (expand-file-name "~/.emacs"))
(nil-if-err (load user-init-file))
(nil-if-err (load custom-file))
... into "~/.xemacs/init.el". If that is done, then the behaviour
will be just like it used to be... that is, if you run both GNU
Emacs and XEmacs, you'll need a `(cond ...' around everything in
.emacs to separate out the parts that only work in one or the other
of the emacsen, and when you save options via the `M-x customize'
interface, they'll be written to .emacs, so that when you save
options that only XEmacs has defined, GNU Emacs will stop during
initialization with an error message, and vise versa.
I you prefer that behaviour, there will be commented off code in
init.el. Most people who can write the cond in .emacs can also
remove the semicolons and uncomment that. (They could more easily
remove the cond, and move the code for XEmac initialization into
"~/.xemacs/init.el".) If someone has written code that "depends" on
"~/.emacs", there's really no reason why they cannot search and
replace the hard ".emacs" with `user-init-file'.
I've written a startup function that will check and see if there's a
"~/.xemacs" directory yet, and if not, will create it and write some
starter files in there. It will also create a subdirectory there for
the user's personal lisp programs, along with a Makefile that when
run, will create an "auto-autoloads.el" for them.
A lot has changed with this version of XEmacs. On startup, it cdr's
down the installed lisp tree, and loads all of the
"auto-autoloads.el" files that are there. It does this at runtime,
so newly installed lisp is there the next time you start, without
redumping the XEmacs binary to bring in those autoloads. Any sexp in
a program can be marked for autoloading with a `;;;###autoload'
comment. The ;;;###autoload thing has been around a while, but the
runtime reading of "auto-autoloads.el" is new, I think.
Chris> Most newbies don't write elisp. Most newbies, in fact,
Chris> don't actually experiment much. Those that do are used to
Chris> things breaking for odd reasons, and they usually have
Chris> friends to help them. These friends will join the chorus
Chris> of experienced users, saying, "this system is broken,
Chris> switch to Red Hat", when they *finally* figure out just
Chris> what is going on.
A fool and his money are soon parted. `reinstall' is how you fix
windows... blah blah... 1000 trite words of M$ bashing...
Chris> This change will also annoy the hell out of anyone (even a
Chris> newbie) who uses multiple flavors of Unix -- maybe Debian
Chris> at home and Solaris at work. It's especially going to
Chris> annoy those who currently mirror or share their home
Chris> directory between different systems, some Debian.
I will explain the setup in a README, and a short quick edit will set
them back up.
(cond
((string-match "^21.[12].*XEmacs" emacs-version)
;; This is XEmacs...
(setq user-init-file (expand-file-name "~/.xemacs/init.el")
custom-file (expand-file-name "~/.xemacs/.options.el"))
(condition-case err
(load user-init-file)
(t nil))
(condition-case err
(load custom-file)
(t nil)))
(t
;; This is an older XEmacs or GNU Emacs.
))
In addition, they might like to paste their custom settings into the
new file. Real tough edit, that... if they've already used it long
enough to HAVE custom settings, they probably can deal with the edit
and restart.
Chris> No, it's not the world's most important issue.
:-) I hope the Mule doesn't step in the molehill and break a let.
Look on this as an opportunity to clean up your XEmacs initialization
cruftorama.
Footnotes:
[1] 00_debian.el will contain:
(defmacro nil-if-err (&rest body)
"Run body inside a `condition-case', and return NIL if an error is thrown.
This is useful in your \"~/.xemacs/init.el\" for things like:
\(nil-if-err (load \"somefile\"\)\)
... when \"somefile.el\" might not be there."
`(condition-case err
,@body
(t nil)))
