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" == Ben Wing <[email protected]> writes:

    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.