From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: Allowing loose ordering in Org files Date: Mon, 09 Nov 2015 20:12:52 +0100 Message-ID: <87d1vjyojv.fsf@Rainer.invalid> References: <871tc83p01.fsf@flynn.nichework.com> <84io5j1k5h.fsf@gmail.com> <84611j19hk.fsf@gmail.com> <5638C2A1.2090801@iancu.ch> <87h9l32gfc.fsf@nicolasgoaziou.fr> <87d1vq3mh4.fsf@nicolasgoaziou.fr> <874mh23iw0.fsf@nicolasgoaziou.fr> <878u6eu5wg.fsf@Rainer.invalid> <315DDEDC-1BD9-4680-A8C8-B36821EB931C@gmail.com> <874mh2u2w0.fsf@Rainer.invalid> <87ziytyl3z.fsf@free.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40865) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvrsI-0004eq-H8 for emacs-orgmode@gnu.org; Mon, 09 Nov 2015 14:13:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvrsF-0006eT-59 for emacs-orgmode@gnu.org; Mon, 09 Nov 2015 14:13:06 -0500 Received: from plane.gmane.org ([80.91.229.3]:60221) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvrsE-0006eC-Pj for emacs-orgmode@gnu.org; Mon, 09 Nov 2015 14:13:03 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZvrsC-0001NP-Oi for emacs-orgmode@gnu.org; Mon, 09 Nov 2015 20:13:00 +0100 Received: from p54b47b6e.dip0.t-ipconnect.de ([84.180.123.110]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Nov 2015 20:13:00 +0100 Received: from Stromeko by p54b47b6e.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Nov 2015 20:13:00 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org John Wiegley writes: >>>>>> John Wiegley writes: >> I spoke to Nicolas directly and he mentioned that a goal for syntax >> regularity is to make it possible to reliably read and manipulate Org files >> outside of Emacs. How about keeping the discussion on the list and stop Cc: and Reaply-To: madness? > I've had time this weekend to rethink my feature request, and I realized that > even machine-friendly formatting is something I should be able to give up, to > have an Org that works better for me. The whole point of defining a formal syntax for Org is that it becomes possible to parse Org documents with something other than Emacs and still make sense of them. To reap that benefit, you need to drop some of the ad-hoc parsing that Org did in the past. > What has always made Org great (to me) is that it's a rather "light" overlay > on a plain old text file. What structure it does enforce -- say, the actual > syntax of drawers -- has always felt fairly "fluid". Still does. > Lately there seems to be a push to sacrifice some of this freedom in order to > gain efficiency and regularity. I imagine this is for the benefit of machine > parsers; but what if one doesn't use any machine parsers? Org never asked me > to give up flexibility for unknown benefits before. Yes it did and still does, just in other places that you may or may not care about. For instance, it asks you to not use multi-line table cells, or column and row spans. It also doesn't let you use a :TBLFM: drawer instead of that #+TBLFM: line just because it looks more neat (it really should, BTW :-). > It should be asked whether users want to trade formatting freedom for those > benefits. If it has been asked, I missed that discussion. So unless it's an > heavy maintenance burden to allow floating properties, for example, I don't > see why I, as a user, shouldn't be allowed to make that choice. I won't talk about "maintenance burden", but in any case it's a technical debt. You'd have to maintain two code paths that accomplish the same result or at least should. > To those who repeat the performance argument: This is an opt-in only request. > It is not about changing the performance of default Org, or making files more > difficult to parse outside of Emacs for everyone. You will find that the argument really wasn't about performance, but complexity. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada