Re: Use DEFAULT argument to completing-read

KJ> Martin Buchholz writes: KJ> Maybe. It's true if you believe that all that code is our KJ> responsibility. One point of breaking out the packages is that KJ> we no longer are responsible for the quality of all the code KJ> that claims to run under XEmacs. The stuff distributed ouside KJ> the core XEmacs is not part of XEmacs anymore. Your statement KJ> is false if you believe in the new reality, as I do. KJ> I'm serious. We need to stop thining of every piece of Lisp in KJ> the package tree as being part of XEmacs and our responsibility. KJ> Today's model more clearly reflects reality. We could put all KJ> the code back into the distribution and pretend that we were KJ> doing quality control. But that doesn't mean QC will actually KJ> get done. Past evidence indicates that it won't, which is part KJ> of what drove us to push the ever increasing pile of Lisp code KJ> out of the distribution. What an interesting idea. I don't think this statement of responsibility is anywhere on the web site. If we claim to only try to support the XEmacs core, then we're not really trying to provide a functional editor at all. XEmacs without packages is not an Emacs at all. Or there have to be separate projects that provide a complete editing solution, with XEmacs at the core. Then we could put up a disclaimer at ftp.xemacs.org, directing newbies to other sites that provide actual editors, if that's what they want. Anyways, Kyle, I think your idea is crazy. It's the Linux kernel without Linux CDROM distributors. Only the lunatic fringe would use it. (Dear readers: sorry, but the fact that you're reading this puts you into the lunatic fringe) It might make sense to have supported and unsupported packages, (and the supported ones are seamfully bundled with XEmacs), but we're not currently doing this either. KJ> Getting a stable XEmacs is the same as getting a stable working KJ> environment involving an operating system and some number of KJ> applications. Unless you get the whole bundle from a vendor, KJ> there will be some experimentation involved in getting a setup KJ> you're satisfied with. Almost everybody gets the whole bundle from a vendor. Linus does, for example. Steve is the rare exception who tries to maintain his own personal version of Linux. KJ> Well, that's certainly provocating enough to get discussion KJ> going. :) KJ> My opinion: the XEmacs audience is largely computer professionals KJ> who will have no problem using 'tar' (or similar) and installing I want XEmacs to be a useful tool for everyone. KJ> the packages they need to get work done. So I think providing a KJ> fancy interface over the package system is largely a waste of KJ> time. We need a way to keep unstable packages from the stable KJ> ones, so the user gets a choice. We need a way for the user to KJ> easily see what they need to install to get a certain feature. What I don't understand is that the user had a choice before the package system. How hard is running rm -rf lisp/vm One could even provide a GUI around this operation. Providing the individual packages as little tarballs has not really made the user's life any easier. Instead, the work which is _required_ to get a vaguely functional editor has gone up tremendously. Again, the user should be able to get an excellent editor by following these simple and obvious steps: tar xf configure make make install After that, the user should be able to customize to his heart's content, including removing and adding new pieces of functionality. How the content of that user tarball is subdivided into development projects is up to us. Martin