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. Another possibility I would think of is that some package is so broken that has managed to raise from its /etc/emacs/.. files the severity emacs has with this things (not sure if this can be done), and does this in a non local way, so is inherited by others. I never tried emacs-snapshot packages, so the dictionaries-common system is completely untested for it. I do not know if has any special thing that might also influence this. > 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. > >> I don't know what would be a good solution in this case, but you > >> may find it helpful to know that I've filed a similar couple of > >> bugs on the dictionary-el and BBDB packages (Bug#308335 and > >> Bug#308336, respectively) --- which also cause this same problem. > > > > The trivial fix is to surround the code by a condition-case, so we > > work around other packages bugs. I do not think that is desirable, > > so I wait for your log. > > I agree. Sorry, I do not have time to investigate further and/or > create a log right now, but I will follow up on this tonight. If we confirm that this is a problem only with emacs-snapshot, there is no hurry in making a quick fix go to sarge. Anyway, using condition-case in this (load), with a big error message in case of failure, is probably desirable to make code more robust. 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. 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'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. Regarding byte-compiled files load from /etc/emacs/site-start.d/.., if the emacs ispell pop-up menus are to be updated with the really installed dictionaries, we require loading of ispell.elc itself (another place where that might fail) from startup scripts, so we really need those byte compiled files be loaded (that will be triggered by ispell-change-dictionary call). Thanks again for your feedback, Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
