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