From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: org-export raises stringp nil error Date: Sun, 10 Mar 2013 02:53:26 +0900 Message-ID: <87li9wh33d.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87ip539io1.fsf@nautilus.nautilus> <87zjye96ph.fsf@bzg.ath.cx> <87vc928kcm.fsf@bzg.ath.cx> <83sj46z468.fsf@gnu.org> <87txomz1j7.fsf@yandex.ru> <83li9yyyul.fsf@gnu.org> <87li9xu9y5.fsf@Rainer.invalid> <83zjydy8ny.fsf@gnu.org> <87vc91slfj.fsf@Rainer.invalid> <83haklx7yq.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1362851643 30457 80.91.229.3 (9 Mar 2013 17:54:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Mar 2013 17:54:03 +0000 (UTC) Cc: Achim Gratz , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 09 18:54:28 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UENyP-0007QV-S6 for ged-emacs-devel@m.gmane.org; Sat, 09 Mar 2013 18:54:22 +0100 Original-Received: from localhost ([::1]:42360 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UENy4-000667-0c for ged-emacs-devel@m.gmane.org; Sat, 09 Mar 2013 12:54:00 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:54508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UENxu-00064w-OU for emacs-devel@gnu.org; Sat, 09 Mar 2013 12:53:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UENxp-00047f-Qj for emacs-devel@gnu.org; Sat, 09 Mar 2013 12:53:50 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:41936) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UENxj-00045s-PU; Sat, 09 Mar 2013 12:53:40 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id E36C59708E1; Sun, 10 Mar 2013 02:53:26 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A46F811F432; Sun, 10 Mar 2013 02:53:26 +0900 (JST) In-Reply-To: <83haklx7yq.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta32) "habanero" b0d40183ac79 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:157673 Archived-At: 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).