Re: symbol's value as variable is void: allow-remote-paths

Richard Cook writes: There currently is no provision at all for packages in the release. It's not as easy as "just include"; provision must be made to install in the right place. That's non-trivial (think root vs. non-root), and there are disagreements about how to think about package installations that will have to be settled to actually get this in the distribution. There is also a requirement of backward compatibility with the stable distribution. You're certainly welcome to do the work. Be warned that it's a fair amount of work (I've tried before but ran out of tuits very quickly), likely to be endlessly bikeshedded, and in the end, nobody will actually notice it's been done. :-) Inclusion of a standard library of packages with XEmacs will surely slow down the release process, as it does in Python (where the standard library policy is an endless source of discussion on their dev lists). The bigger the stdlib, the more drag it will create, I believe. Moving packaged libraries back into core has huge downsides. First, it means that the libraries now have stable and unstable versions, both of which need to be maintained (and in general the stable version will be defacto unmaintained, and definitely will not get any improvements). Worse, the library will not be moved into the stable version (if it is, we then have two unstable versions, one of them correctly labeled and the other a lie :-); that means that we have two different procedures and contexts for loading the library. Third, two different contexts for updating the library with new versions. Fourth, for externally maintained libraries (which in theory includes dired and efs), it will double (at least) the burden on the maintainer. Fifth, it will surely slow down the release cycle for improvements and bugfixes alike. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/mailman/listinfo/xemacs-beta