Re: org-export raises stringp nil error

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > > I see that we have come a full circle, what with all this new blood
 > > > pouring into Emacs development, and we are finally ready to repeat the
 > > > failed experiment with dividing Emacs into "core" and "all the rest".

[...]

 > I meant XEmacs.  I'll ask Stephen to describe that and suggest any
 > conclusions from that experience, including those which contradict my
 > personal conclusions.

You've spent too much time listening to David Kastrup, and not really
understanding what he was saying, I think.  Splitting XEmacs into core
and packages was a success, and still is.[1][2]  Nobody ever suggests
going back in general, although there are often suggestions that very
specific functionality be moved back into core.  Occasionally package
maintainers drop out because they don't like constraints of the XEmacs
distribution framework, and we can't find a volunteer to take over for
them.  Still, people are much more interested in adding functionality
or moving implementation from C to Lisp than in refactoring the
packages.

One interesting fact, however, is that the single most-requested
feature for the packages is a single tarball containing both the core
sources and the current SUMOs.  About what somebody suggested, moving
most applications like Gnus and CEDET into GNU ELPA, and distributing
some approximation to ELPA's head version with Emacs.

 > Your optimism in this matter is enviable, but my gray hair doesn't let
 > me share it.  I don't believe in any net gain here.

That's probably because the gains would not be shared equally.  Quite
likely core development would suffer a bit.  (1) Especially if the
ELPA packages are distributed with Emacs, releases would take more
effort.  (2) Probably a volunteer maintainer for the ELPA will be
needed.  (3) Changes to APIs that are currently treated as "internal"
will get more pushback, especially as packages that are currently deep
in "3rd party" territory join ELPA, and get more exposure and
popularity, but their maintainers can't afford to keep up with Emacs
changes.  (4) A few developers who now have to hang out on emacs-devel
to find out whether they're allowed commit won't bother.  These
effects are going to be second-order, though, because package
maintainers will still need to come to emacs-devel to get new features
they need.

The packages, OTOH, have little to lose, and they will enjoy their
freedom to release on their own schedule.  Thing is, there are a lot
of packages, and only one core.  For the whole community it would be a
gain, a significant one, I think.


Footnotes: 
[1]  In large part thanks to Norbert Koch, who handles package
releases for us.

[2]  XEmacs' big problems are political (people who work on Emacsen
tend to be on the "F" side of "FLOSS" rather than the "O" side), and
that we had to spend a huge amount of effort trying to maintain GNU
compatibility, but on the other hand our features didn't much attract
most third party developers because they couldn't use them on Emacs
... and once Emacs *did* get them, it chose to provide them with
incompatible APIs.  We never managed to come up with a real killer
feature such that Emacs users and developers *had* to use XEmacs; for
the majority of XEmacs users and contributors it was only marginally
better than Emacs.  Enough to get many to switch in its heyday (of
course the long release drought of the early 1990s had a lot to do
with that), though.

So, yes, if the fork were an "experiment", in that sense it is
failing.  The market wants Emacs (for good and sufficient reason), not
XEmacs.  But XEmacs has its fans (also for good reason).