Re: Allowing loose ordering in Org files (Was: bug in org-habits)

[Aaron Ecay <aaronecay@gmail.com>]

Hi John,

2015ko azaroak 9an, John Wiegley-ek idatzi zuen:

[...]

> 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? 

I don’t think it’s possible to separate things like this.  Large parts
of org use a machine parser, written in elisp.  There are (perhaps
asymptotic) plans to transition the rest of org to work based on this
parser.

Adding knobs to this parser increases the burden of those who have
to build and maintain it.  It also heightens the burden for users
(especially novices): M-x customize-group org suddenly asks you one
(or more) questions about details of the syntax that previously you
didn’t need to consider.

We have discussions about extending the syntax fairly regularly.  It
would be good to discuss what questions we might ask of those proposals
to determine whether they should go forward.  Some that I can think of
are:
1. Is there a good (user-friendly, reliable) way to accomplish the same
   goal, given the resources currently available?
2. Is there a large community of users who need this feature and/or
   would adopt it if it became available?
3. Is this something that org’s “competitors” provide easily?  (Not
   necessarily out of a spirit of competition, but rather demonstrating
   a use case.)

I don’t include difficulty of implementation on that list.  I don’t
think the developers should wag the users.  Unfortunately however, I
don’t think your proposal fares well in light of these questions.  (I
don’t mean to imply that they are authoritative; anyone could very well
propose others.  I would be happy if a consensus developed about what
the right questions are, even if there is disagreement about the answers
in this specific case.)

> Org never asked me to give up flexibility for unknown benefits before.
> 
> 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 think framing it in terms of freedom is potentially misleading.
Because org is free software, its users are maximally free to do
any of a wide variety of things, including sticking with an old version,
patching the code locally, distributing a patch/fork/set of advices,
using another program, ...

I think it’s more illuminating to think of it in terms of org as a tool:
have the changes made it more difficult for you to accomplish your goals
with org?  Has something that was previously possible become impossible?
Has something that was previously easy gotten harder?  If the answer to
one of these questions is yes, then we can think of ways to solve the
difficulties.

Of course, you’ve already received quite a bit of feedback about the
proposal from a cross-section of the community.  So what I’ve said will,
I hope, function partially as a lens through which to understand that
feedback, as well as a framework in which to continue discussion if it’s
needed.

-- 
Aaron Ecay