From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: Allowing loose ordering in Org files (Was: bug in org-habits) Date: Tue, 10 Nov 2015 01:40:13 +0000 Message-ID: <877flqskci.fsf@gmail.com> 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; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40817) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zvxv1-0006aY-QU for emacs-orgmode@gnu.org; Mon, 09 Nov 2015 20:40:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zvxuy-0002Jp-D4 for emacs-orgmode@gnu.org; Mon, 09 Nov 2015 20:40:19 -0500 Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]:36230) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zvxuy-0002Jj-4X for emacs-orgmode@gnu.org; Mon, 09 Nov 2015 20:40:16 -0500 Received: by wmww144 with SMTP id w144so99041675wmw.1 for ; Mon, 09 Nov 2015 17:40:15 -0800 (PST) In-Reply-To: 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: John Wiegley Cc: emacs-orgmode@gnu.org Hi John, 2015ko azaroak 9an, John Wiegley-ek idatzi zuen: [...] > Lately there seems to be a push to sacrifice some of this freedom in orde= r to > gain efficiency and regularity. I imagine this is for the benefit of mach= ine > parsers; but what if one doesn't use any machine parsers?=20 I don=E2=80=99t think it=E2=80=99s 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=E2=80=99t 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=E2=80=99s =E2=80=9Ccompetitors=E2=80=9D provi= de easily? (Not necessarily out of a spirit of competition, but rather demonstrating a use case.) I don=E2=80=99t include difficulty of implementation on that list. I don= =E2=80=99t think the developers should wag the users. Unfortunately however, I don=E2=80=99t think your proposal fares well in light of these questions. = (I don=E2=80=99t 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. >=20 > It should be asked whether users want to trade formatting freedom for tho= se > 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=E2=80=99s 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=E2=80=99ve already received quite a bit of feedback about the proposal from a cross-section of the community. So what I=E2=80=99ve 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=E2= =80=99s needed. --=20 Aaron Ecay