Re: error trying to customize browse-url-browser-function

Simon> add the alist widget to mail-lib, loading it only for old Simon> XEmacs that does not have this feature. I think a better solution for generically useful additions like this is to create a separate package, say, "back-to-the-future". Libraries from back-to-the-future should test for a feature or builtin object if possible (I do this in latin-unity-latin9.el, where I test for the existence of charsets and coding systems the library creates), otherwise for the last version that didn't have the feature provided by the compatibility library. This package would only be for new features (ie, ones it would be safe to dump). It might even be possible to provide configure support for optionally dumping them if they were core enough. That would make me happy because I could basically ignore them. We wouldn't distribute binaries with them dumped, so there would always be an easy fix. Features, whose only real defect is that they are features, would be fast-tracked to distribution, which would make authors and users happy. They might even be backward compatible to the previous stable version with some luck. (The alist and plist widgets probably are, for example.) Ben has been talking about doing something here (he also wants to be able to move features, usually from packages to core), but I'm not sure exactly what implementation he has in mind. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.