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: Sat, 09 Mar 2013 12:07:50 +0100 Organization: Linux Private Site Message-ID: <87ppz8x249.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> <87vc91slfj.fsf@Rainer.invalid> <83haklx7yq.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1362827327 26478 80.91.229.3 (9 Mar 2013 11:08:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Mar 2013 11:08:47 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 09 12:09:12 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 1UEHeJ-00008k-Ff for ged-emacs-devel@m.gmane.org; Sat, 09 Mar 2013 12:09:11 +0100 Original-Received: from localhost ([::1]:44529 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UEHdx-0002vG-FF for ged-emacs-devel@m.gmane.org; Sat, 09 Mar 2013 06:08:49 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:36331) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UEHdL-0002Gh-8V for emacs-devel@gnu.org; Sat, 09 Mar 2013 06:08:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UEHdD-0004j7-Ga for emacs-devel@gnu.org; Sat, 09 Mar 2013 06:08:11 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:55090) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UEHdD-0004j0-A2 for emacs-devel@gnu.org; Sat, 09 Mar 2013 06:08:03 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UEHdW-0007w1-Co for emacs-devel@gnu.org; Sat, 09 Mar 2013 12:08:22 +0100 Original-Received: from pd9eb3062.dip.t-dialin.net ([217.235.48.98]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Mar 2013 12:08:22 +0100 Original-Received: from Stromeko by pd9eb3062.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Mar 2013 12:08:22 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 49 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: pd9eb3062.dip.t-dialin.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.93 (gnu/linux) Cancel-Lock: sha1:h90R58SkMoXKW8h5y7yP3EBqRjs= 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:157653 Archived-At: Eli Zaretskii writes: > I meant XEmacs. I'll ask Stephen to describe that and suggest any > conclusions from that experience, including those which contradict my > personal conclusions. Thank you. > I don't understand what that means. There's no "core" packages today, > the entire Emacs repository is handled as one monolith piece of > software. The fact that some parts of it are copies of upstream > repositories maintained by others elsewhere is not relevant to the > issues I have with separating them from Emacs. If you made some directories subprojects (in Git parlance; bizarr probably also has something that is almost, but not entirely unlike it), your Emacs checkout would look exactly the same as today. What would change is that if you fixed a bug in e.g. Org, you would fix it in the Emacs branch of the Org repository and then commit the subproject within Emacs pointing to the new head that contains the fix. Now, properly making these replaceable with newer (or maybe even older) ELPA packages obviously requires some extra steps away from the status quo, but again these have nothing to do with "which repo does that directory come from". > Your optimism in this matter is enviable, but my gray hair doesn't let > me share it. It has been a while that someone called me an optimist, so thank you. Also, I have enough gray hair of my own, so you don't need to share it. :-) > I don't believe in any net gain here. I don't know why is that so, > perhaps because complexity tends to disrupt any hope of reaching an > "agreement on how to do this" and having "an easily followed set of > rules that describes the procedures". Heck, we couldn't even agree on > the VCS to use, remember? I'll concede you this point. No, I don't expect any new arrangement to be friction-less, but maybe a less so than the current one. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada