Re: Error if locale is omitted in set-progress-feedback-instantiator

"Paul Moore" <gustav(a)morpheus.demon.co.uk&gt; writes: Actually, with the "broken" version on my XP Home box, xemacs -q -f message-mail wasn't enough. It needed something extra from my Gnus setup to trigger the problem. I don't know what, though (Yes I do! See below). Ack. I copied the directory tree built on Win2000 across unchanged, and ran Gnus. No bug. So the same sources, with the same version of MSVC6, built (as far as I can manage) the same, run on the same box, with the same configuration, work fine when the build was done on Windows 2000, but fail when the build was done on XP Home. I did a complete diff of the 2 installed trees. The only files which differ are: * The executables * The elc files under XEmacs-21.5-b11/lisp * The elc files under xemacs-packages/lisp/gnus Why would the elc files differ? Are they not architecture independent? Could this point to a problem in the byte-compiler somehow? [Nope, I looked at a bytecode file, the username and machine the bytecode was compiled on is in there. So that's a red herring...] I'm baffled. I'll do a few more experiments... OK, after a bit more checking, the only file that matters is the executable. Running the EXE built on XP fails with the bug, running the one built on 2K works, when the executable is in the exact same installation tree. (I copied both exes into both trees, the 2K exe worked in both, the XP exe failed in both). Right. I did a binary search on the initialisation files. The line that causes the problem is in my custom.el custom-set-variables section: '(font-lock-mode nil nil (font-lock)) I've no idea why this breaks one build but not the other. Just as a check, I looked at (current-locale) on both machines. Both show "English_United States.1252", so that doesn't look relevant... I'm out of ideas now. Any suggestions? Paul. -- This signature intentionally left blank