Re: Future package: proposed content

Moving to xemacs-design. Reply-To set. viteno> From my point of view this sounds like a good approach. viteno> If nobody else objects to the idea, send me the file(s) viteno> you already have for this package and I try to get them viteno> packed up and distributed. Please don't. It's really important that we get this either right the first time, or wrong in a way that doesn't screw the users no matter what we do to fix it. We really should think about what problems we're trying to solve, what APIs we want to provide, etc. Is it really enough to have a future-x file? What do we do for 21.4 when 22.0 has x-foo-new and 22.2 has a changed version of x-foo-new and a new function x-bar-new? Do you realize that you (I mean "Norbert") may have to build separate versions of these things for different old versions of XEmacs (21.4 v. 22.0)? This has been tried before (the APEL package). It's no accident that "APEL" is a 4-letter word! -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.