There were patches submitted recently which may have some bearing on this problem (Custom was not setting specifiers properly, resulting in errors which apperently were caught and ignored). I haven't looked carefully at, let alone applied to 21.4, the patches. http://list-archive.xemacs.org/xemacs-patches/200107/msg00092.html http://list-archive.xemacs.org/xemacs-patches/200108/msg00000.html Try applying them; maybe that's all you need. The first hunk of the second patch should fail to apply to 21.4.4 (a different but equivalent patch has already been applied), but the second (the one you need) should work. These patches have no effect on other parts of XEmacs; I don't see how they can hurt you. If not, there are workarounds.... Karr> So do you mean to avoid using "custom" entirely, or just to Karr> not set faces/fonts with custom? The actual rule is "don't invoke custom-set-faces after directly manipulating faces." This is a problem, however, because custom.el is normally read after init.el. There are some patches by Didier Verna to make it possible to change the order, but I don't really undersatnd them: http://list-archive.xemacs.org/xemacs-patches/200104/msg00061.html I think if you rename your custom.el and explicitly load by the new name it at the beginning of init.el, you'll get better results. (This only works in >=21.4.4, including 21.5.x.) This will cause problems with saving your customizations (this is the part I don't understand yet). According to the documentation for `custom-file' you should be able to setq that to the new name in init.el. It is possible that we will change the order in which custom and init are loaded in the future. Karr> When I added it before I loaded "shell", then it failed Karr> with an unknown symbol error. Sorry, untested suggestion. I don't recall how to deal with this offhand (this is one of the things that Custom automates.) Sick as it sounds, maybe the simplest thing to do is Customize the face (even though it won't work), which will get Custom to create the face when custom.el is loaded. Then put direct calls to set-face-font in init.el to override the ineffective Custom specifications. I also should have known better than to use font "courier", since you specifically mentioned that you didn't have an italic version. Karr> saving the file and restarting. Not only did this not fix Karr> the problem, it also seemed to not change anything. After Karr> loading it, I used "apropos" to show me the value of Karr> "shell-output-face", and it still shows a font string using Karr> "courier". Right ... if you are simply restarting, then when custom.el gets loaded after init.el, all your work may get undone. A simple test is to start up, visit init.el, go to the end of the set-face-font sexp (ie, after the close paren), and type C-x C-e to execute it. This should fix your problem (until the next time something calls `custom-set-faces'). (Changes to face specifiers takes effect the next time the Emacs frame is repainted, so it should be visible in the shell buffer immediately.) Karr> If you meant to avoid using "custom" entirely, would I Karr> comment out all the code in my "custom.el" and create manual Karr> "setq"s in my "init.el"? No, just use for faces should be avoided. Terribly ironic, since managing faces was the original motivation for Custom.... -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

David> Following a recent discussion here, I have "(load David> "~/custom.el") at the top of init.el. Would that David> accomplish the same? Partially. However, unless you rename custom.el, custom.el will be reloaded after init.el. This is a problem in two cases: (1) init.el recomputes values for customized variables. (2) init.el adds specifications to faces. In both cases reloading custom.el will smash the changes made by init.el. If you do rename custom.el, setq custom-file to the new name in init.el. This tells Custom where to store new settings. (Otherwise it will recreate custom.el.) David> Would it cause other problems? This means that any code you have in init.el can depend on Customizations. This is unanimously agreed to be a good thing in general. Of course, this is Lisp, _anything_ can cause problems. If you forget that init.el depends on Customized variables (or Customize a variable that you forgot is used by init.el) you could get unexpected behavior. I believe it is always possible to get the default value of Customized variables (this is not true of specifiers, eg, faces), so a properly written init.el could be mostly free of such side effects of Custom. On the other hand, I know of no mechanism for Custom to take advantage of settings in init.el. So we are currently considering changing the loading order. This would mean your custom.el would get loaded twice, but I believe that is idempotent. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."