(Cc'ed to dres because I'm not sure you're on debian-emacsen, and the
xemacs packages exposed this problem. And sorry for the length, but
I wanted to make sure I gave plenty of background so people don't
have to guess what I'm talking about.)
OK, I *thought* I could make my emacsen-common "setting
debian-emacs-flavor" change cleanly and gradually. My original intent
with this change was to reorganize the emacs setup process so that
instead of having debian-emacs-flavor be set by each of the emacsen,
it would actually be set from the value of the argument that you pass
to debian-startup. I felt that this was a somewhat cleaner approach
and helped minimize the amount that we have to modify the upstream
code as compared to what I was doing in emacs20 before.
In any case, after making this change in emacsen-common *.10, and then
getting three separate bug reports in the past day indicating that
xemacs doesn't like the change at all, I looked at the xemacs code and
realized that I probably hadn't been nearly as clear as I should have
been in debian-emacs-policy regarding a couple of issues in the
startup process. So let me try to clarify what I intended, and then
get your comments if you have any.
First issue: now that I've had a chance to think about the change that
I mentioned above, that of having debian-startup handle declaring and
setting the value of debian-emacs-flavor, I'd like to revisit that
decision. Though I still like it in principle, I can see a possbile
problem. Originally I had intended that debian-startup would only be
called if site-run-file was true (i.e. if the user hadn't specified
--no-site-file (I'll show you how to easily do this in your flavor of
emacs below)). However, if I really had intended that, then this is
one of those things I should have specified in debian-emacs-policy
rather than presuming that people would poke around emacs20's
startup.el just because I alluded to it.
For the moment, lets presume that we decide that --no-site file
shouln't load debian-startup.el or call debian-startup as I had
intended. If you couple that with my recent move of
debian-emacs-flavor's definition and assignment to debian-startup.el,
starting up with --no-site-file would mean that debian-emacs-flavor
wouldn't be defined at all. Is that a problem? If we agree that it's
not a serious problem (given appropriate documentation), then I think
it's better than having the debian stuff always executed because then
--no-site-file allows you to get a "clean" emacs up and running, with
no debian stuff.
Second issue: the bug that precipitated this discussion surfaced
because in my debian-emacs-flavor "transition code" in the
emacsen-common package, I set it up so that debian-startup.el defines
debian-emacs-flavor and then initializes it to 'not-yet-set. Then
later in the function debian-startup I check for this value and issue
a warning to the maintainer to migrate to the new approach if it has
already been set. I thought this would allow us to transparently
upgrade to the new method over time, and in my tests here, emacs20 has
no problem with this, but somehow xemacs seems to be getting confused.
This led me to look at what's going on in the xemacs21 package, and
though from my initial glance, I didn't see exactly what was causing
the problem, I was surprised to see that xemacs21 had any code in
site-start.el. According to debian-emacs-policy, that file is
supposed to be *solely* for the local admin. It shouldn't have any
code in it, or am I confused? Is site-start.el.in in the xemacs21
package something like /etc/xemacs20/site-start.el? If so, then how
does /etc/emacs/site-start.el ever get loaded?
In any case, I guess it's possible that xemacs* waiting until
site-start to call debian-startup has something to do with the current
problem.
Right now, the code I used to handle debian-startup in emacs20's
startup.el file embodies all my assumptions (including the things that
should be in debian-emacs-policy, but arent). I guess that in the
short run, all the other emacsen maintainers could just snag this code
for their packages, but in the medium run, we should just agree upon
which of my assumptions should become policy, then update policy, and
then let everyone conform in whatever way is most convenient for them.
Here's the startup.el code (which right now presumes that we end up
deciding that --no-site-start should disable the debian stuff):
;; Debian version of site-start.
(if site-run-file
(progn
;; Load all the debian package snippets.
;; It's in here because we want -q to kill it too.
(if (load "debian-startup" t t nil)
(debian-startup 'emacs20))
;; Now the normal site file...
(load site-run-file t t nil)))
For reference, here are the bugs that have been filed about this
problem so far:
61080
61110
61133
Thanks
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
