Re: A couple of problems with new module code.

|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org&gt; writes: Jerry> Steve Youngs <youngs(a)xemacs.org&gt; wrote: SJT> This is what _should_ happen. The autoloads should be there, SJT> and they should generate an informative error message if the SJT> .ell isn't present. I really disagree quite strongly here. IMO, the autoloads should only be built for modules that are installed. Jerry's solution of wrapping them in a '(when (file-exists-p "module.ell"))' does the next best thing and works well. SJT> Any modules that are distributed with XEmacs should be considered SJT> standard (eg, md5, gzip). Except for PostgreSQL and LDAP any other module in core is really nothing more than sample code. Eventually the other modules (base64, zlib) will undoubtedly "come online" as will other, yet to be dreamed of, modules. In the meantime, maybe we should move the currently "unused" modules into ./modules/sample/ until such time that somebody breaths life into them. SJT> The fact that today's sources include clearly optional stuff SJT> like postgresql and ldap should be considered transitional Why? The core is full of optional stuff that isn't considered transitional. I don't think I quite understand what you're getting at, Stephen. Jerry> On the other hand, this doesn't support installing new Jerry> modules later on that did not exist when the XEmacs binary Jerry> was compiled. On the gripping hand, that would still be a Jerry> problem if auto-autoloads.el contained only autoloads for Jerry> modules installed at build time. Yeah but it wouldn't take too much time and effort for some smart cookie to come up with a way for autoload.el to overcome this. :-) -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|