Agustin Martin <[EMAIL PROTECTED]> writes:
> Hi, Daniel, Joerg and Aaron (cc'ing all related bugs)
>
> On Tue, May 10, 2005 at 02:47:57PM +0200, Daniel Brockman wrote:
>> (See below for why this message is cross-posted to several bugs.)
>>
>> Agustin Martin <[EMAIL PROTECTED]> writes:
>>
>>> If I am not wrong, that should also be reproduced by a plain
>>>
>>> # dpkg-reconfigure emacs21
>>
>> Yes, you are right.
>>
>>> I can only check that now in a woody+dict-common system, and I
>>> cannot reproduce that problem. I am not in dial up and cannot try a
>>> real reinstall. Please check if 'dpkg-reconfigure emacs21' also
>>> gives that problem in your system. Please also provide info about
>>> the emacs version you are trying.
>>
>> It does. I'm using emacs21-21.4a-1 (and CVS Emacs from last night,
>> packaged with Jerome Marant's emacs-snapshot).
>
> Considering that this has been silent for emacs21 <= 21.3 and just
> issuing a warning for xemacs21, is possible that emacs-21.4 has
> changed handling of this things, raising severities. If this is
> true, this problem should only become evident with emacs-snapshot.
I'm sorry, I don't think this is reproducible on any system but mine.
Further investigation revealed that my debian-startup.el had this
(condition-case ()
(load file nil)
(message "Error while loading %s" file)))
instead of this,
(condition-case ()
(load file nil)
(error (message "Error while loading %s" file))))
which makes absolutely no sense whatsoever. I don't know how and when
this happened, but it explains all the problems I had, and a simple
reinstall fixed it.
>> Yes, you are quite right. I can't believe I missed this.
>> The error does not occur unless I also have auctex installed (some
>> other package that I do not have installed and whose first letter
>> is a, b, c, or d might also provoke it).
>
> I will try looking at this tomorrow in a real sid box with sid
> emacsen flavours.
It seems you don't have to bother. :-)
> Anyway, using condition-case in this (load), with a big error
> message in case of failure, is probably desirable to make code
> more robust.
In light of the new evidence this should not be necessary, as the code
that loads each individual file in /etc/emacs/site-start.d already has
a condition-case around the entire load.
> The (load file t) way Aaron plans for dictionary-el will not work
> here, the file to be loaded exists, but the autoloads triggered by
> that load not.
Actually, in the case of dictionary-el, the file to be loaded,
dictionary-init.elc, does *not* exist (it has not yet been
byte-compiled), and the fact that the autoloads refer to non-existent
files is irrelevant in two ways: first, the autoloads are never even
set up in the first place due to the error; and second, no part of the
startup script would ever attempt to call the autoloaded functions,
even if the error would not occur.
> Along with this I would consider filing bug reports against the
> packages that when byte-compiling load startup scripts for no
> good reason.
Yes, I didn't originally realize that this was part of the problem,
but now I think it is the part that should be fixed.
There are quite a lot of these though: Here are some examples of
packages whose install scripts invoke Emacs without --no-site-file:
- auctex
- css-mode
- cedet-common
- ede
- eieio
- elib
- emacsen-common (!)
- semantic
- speedbar
Would it be inappropriate to start filing bugs to these packages?
I s'pose I'd put them as enhancments, but there'd be lots of them.
>> Yes. I'm CCing the other bugs so that the maintainers of those
>> packages (bbdb and dictionary-el) do not have to worry so much
>> about this. (Sorry guys!)
>>
>> Maybe these bugs can even be closed. (Assuming that it actually is
>> considered OK for a package to require byte-compiled files in their
>> /etc/emacs/site-start.d scripts.)
>
> I will leave this bug report open for a while, until I add the
> condition-case statement, or a better fix.
I'll say it again: This was a false alarm. The bug will not bite
anyone who lives within normal reality.
However, it is indicative of a problem. Namely, the large bunch of
packages that load heaps of unnecessary stuff when byte-compiling.
I'd say there are some semi-major speed increases to make here, by
simply adding the --no-site-file option to every byte-compile run.
Thanks for helping me find the true source of the problem, Agustin,
and sorry for taking so long to reply.
--
Daniel Brockman <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
