Re: A couple of problems with new module code.

SY> I really disagree quite strongly here. IMO, the autoloads SY> should only be built for modules that are installed. Jerry's SY> solution of wrapping them in a '(when (file-exists-p SY> "module.ell"))' does the next best thing and works well. If the module is in a package, auto-autoloads will only be built when it is installed. If it is part of core, then an XEmacs that doesn't have it is known to be crippled and it should do something more informative than barf on an undefined function---it should present an informed guess as to why the function is undefined. This is one reason why Ben wants xemacs-base back in core, for example. SJT> The fact that today's sources include clearly optional stuff SJT> like postgresql and ldap should be considered transitional SY> Why? The core is full of optional stuff that isn't considered SY> transitional. I don't think I quite understand what you're SY> getting at, Stephen. If it's optional, we should show it the door to packages. I want to get as much stuff out of core as possible. For two reasons. First, it improves response time to patches if the modules are in packages. Second, the less stuff there is in core, the more stable it can be. SY> Yeah but it wouldn't take too much time and effort for some SY> smart cookie to come up with a way for autoload.el to overcome SY> this. :-) Oh yeah? autoload.el is full of "WTF??!?" comments. As Jerry knows, I think he put a couple of them in there. :-) -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py