Re: Allowing loose ordering in Org files

[Achim Gratz <Stromeko@nexgo.de>]

John Wiegley writes:
>>>>>> John Wiegley <johnw@gnu.org> 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