Re: Release plans

["Stephen J. Turnbull" <stephen@xemacs.org>]

Thien-Thi Nguyen writes:

 > This characterization doesn't cleanly apply in this case; i'd like
 > to point out that the ban on the addition of dynamic loading to
 > Emacs is not an imposition on all Emacs users, only on those users
 > who hack Emacs and write to its repo.

This is sufficiently important that Richard has devoted some thought
and an explicit ban to the problem.  If other users were similarly
problematic, I would suppose that he would have considered adding it
to the GPL, or so.

 > FWIW, i stand w/ the ban mostly due to personal ineptitude: i
 > can't imagine (though i've tried) any coroutine that could not be
 > supervised through a repl to a subprocess.  Moreover, i believe
 > everything useful moves to a network protocol eventually.

Thank you for making this point; it is true in my opinion, too.

However, I think of dynamic loading not as adding more features to
Emacs, but rather pushing features out of Emacs.  The modules I
personally work on at the moment are things like libcurl and neon,
which provide fast, robust access to network protocols, *maintained by
somebody else*.  I've also used them in the past (libcanna) to push
junky, hard-to-maintain, but popular, code out of core.

This strategy has been quite successful for Python.

 > This includes not just functionality, but methodology.  Now that
 > DVCs are on the rise, it's no big deal to flourish your Emacs
 > without having to "write to its repo".

True, but in the GNU Project it is considered anti-social to do that.
That is basically what Lucid did, and look at what that led to.