Re: [AC21.5] easy-mmode in core must be dumped

This does _not_ belong on XEmacs Review. Reply-To and M-F-T directed to XEmacs Design. Ben> I moved it into core because I didn't really see any Ben> alternative given that paragraphs.el depends on it. And I Ben> think it's pretty basic functionality. I really question the Ben> wisdom of having xemacs-base separate at all ... The Ben> packages should be *optional* but xemacs-base is completely Ben> required. IMO, "required editor functionality" != "XEmacs core functionality". Equating them was a fundamental mistake that Steve Baur made when he first split up the packages. The point of packages is to define _modules_, not to save disk or RAM space. The UI should mostly _not_ be considered part of the core, no matter how basic it is to users! Very little of the editor (ie, far less than classic vi presents, more like say "pico") should be part of the core. "Core" to me means Lisp engine + Lisp primitives + basic text manipulation + redisplay + I/O. Ie, those lowlevel APIs which can't be robustly changed by loading a Lisp library or two. If the core functionality of 21.4 (as I defined it) is sufficient to support the functionality of easy-mmode.el, paragraphs.el, regexp-opt.el---and as far as I know all of those things are true---then these should be in separate packages that can be used by both 21.4 and 21.5. There is no reason why modern functionality, and especially bugfixes, that happened to not to have been available when 21.4 was released should deliberately be made hard to add to 21.4. If it turns out to really be that hard, after actually trying it, _then_ move the library/package into the cores separately. Or maybe have a load-path like ("package1" "package2" "stdlib-vn" "stdlib-vn-1" "stdlib") (normally no "core"; if it's in core, I'm thinking it should be dumped; of course we'll probably need a mechanism to dump a lot of the stdlib packages, too). Ie, what we should have is XEmacs -+- 21.4-core | +- 22.0-core (nee 21.5-core) | +- standard-packages (eg, efs, dired, xemacs-base, field, stdlib-22.0) | +- unbundled-packages And then we can finally rm -rf xemacs-packages/apel! The main thing I see is that we would have to do a much better job than we currently do of testing multi-version compatibility of changes to the standard packages. But in the case of a new standard package, say field, we would simply say "we hope it's compatible with 21.4, but we can't promise that without field testing" (pun unintended). If this makes 21.5 harder to develop, then we need to further refactor to make packages work better in this context. What you're saying AFAICT is equivalent to you need to move this stuff into 21.5 because the underlying internal APIs are poorly designed so the dependencies can't move into packages. Maybe that's not true, but you sure aren't documenting your case in a way that it can be reviewed. The argument that we have to distribute basic editor UI with the text/ Lisp/redisplay core will shortly be moot. I have the basic facility in place; I need to address a couple more common use-cases, and I'll be ready to commit to 21.5 in a week or so. It can be implemented as a pure extension with no changes to existing files except a new directory in etc/ to hold the packages and a new target in the toplevel Makefile, so it could be added to 21.4 (and I expect it to be; this is something that people, including you, have been demanding for seven or eight years now). Ben> The counter "argument" that having this in the packages Ben> allows people to get this stuff automatically upon updating Ben> is not something I buy. Updates should not change core Ben> functionality; if we want it into 21.4, we can release a new Ben> version of 21.4. Nice in theory, but in practice trying to backport your code from 21.5 to 21.4, and screwing it up because gratuitous renaming in the 21.5 codebase makes diff useless, is something that has embarrassed me on several occasions. (Most recently the very nasty regexp bug that David Kastrup continues to badger us about.) If you are going to continue your habit of refactoring and renaming stuff all over the place---and I think you SHOULD---"we can release a new version of 21.4" is semantically equivalent to "let's mostly not bother with 21.4", assuming you're not willing to commit to doing a lot more work on the stable branch than you've done in the past. I don't consider that good policy, especially since you pretty clearly intend to go on to apply it to 22.0 once it goes stable. Ben> BTW I strongly think that field.el should be moved into core, Ben> as there is a core dependency. This is also a good example Ben> of core functionality that should *not* be part of the Ben> packages. True, but "core dependency" is a reason for moving that dependency out of core, not vice versa. "Core" should be defined by "there are reasons why this would be hard to implement in a conceptually separate module", not "it would be convenient if I could just change these two modules in a parallel fashion without being screamed at by people depending on a different version of the API." field.el may very well be such a module, but the fact that you've introduced a new dependency in core (obviously it's new, because it can't possibly be in 21.4) doesn't prove that the dependency itself belongs in core! -- 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.