From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Achim Gratz Newsgroups: gmane.emacs.devel Subject: Re: org-export raises stringp nil error Date: Fri, 08 Mar 2013 21:09:36 +0100 Organization: Linux Private Site Message-ID: <87vc91slfj.fsf@Rainer.invalid> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1362776117 26085 80.91.229.3 (8 Mar 2013 20:55:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Mar 2013 20:55:17 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 08 21:55:34 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 1UE4KD-000893-JK for ged-emacs-devel@m.gmane.org; Fri, 08 Mar 2013 21:55:33 +0100 Original-Received: from localhost ([::1]:48212 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE44W-0005mK-Hp for ged-emacs-devel@m.gmane.org; Fri, 08 Mar 2013 15:39:20 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:49993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE3cO-00040j-Jy for emacs-devel@gnu.org; Fri, 08 Mar 2013 15:10:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UE3bx-0001CF-Jj for emacs-devel@gnu.org; Fri, 08 Mar 2013 15:10:16 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:56571) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE3bx-0001C0-DU for emacs-devel@gnu.org; Fri, 08 Mar 2013 15:09:49 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UE3cF-000358-UR for emacs-devel@gnu.org; Fri, 08 Mar 2013 21:10:07 +0100 Original-Received: from pd9eb3aad.dip.t-dialin.net ([217.235.58.173]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Mar 2013 21:10:07 +0100 Original-Received: from Stromeko by pd9eb3aad.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Mar 2013 21:10:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 40 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: pd9eb3aad.dip.t-dialin.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.93 (gnu/linux) Cancel-Lock: sha1:eNbiOEB1mmEz5ty0RRMa4gT+VUY= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:157627 Archived-At: [please keep on emacs.devel] Eli Zaretskii writes: >> In any case, doing the built-in packages this way (or something similar) >> takes a lot of unecessary churn and merges out of the release process >> and I would think that would be a clear advantage to everyone involved. > > 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". Please enlighten me as to what this experiment was and when it happened so I can read up on it. This is a sincere request, I have no desire to repeat a past mistake. Note that I haven't said anything about what is core and what is not, that issue is orthogonal to how Emacs' structures its software repositories. Off the cuff I'd say we'd end up with roughly the same set of "core" packages than today, then grow from there. What I am talking about is reducing the interdependencies between projects on wildly different release schedules for the purpose of making the integration easier. That requires effort on both sides, but I posit that there is a net gain — if there is agreement on how to do this and an easily followed set of rules that describes the procedures. > Good luck (you will need it)! This is engineering, not gaming (although I wouldn't mind a bit of luck once in a while). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs