From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines Date: Thu, 20 Oct 2011 16:18:18 -0600 Message-ID: <87vcrjfgt1.fsf@gmail.com> References: <87pqhrih3s.fsf@gmail.com> <30891.1319141196@alphaville.dokosmarshall.org> <87fwinifqu.fsf@gmail.com> <32184.1319143892@alphaville.dokosmarshall.org> <87zkgvgxe7.fsf@gmail.com> <1405.1319147324@alphaville.dokosmarshall.org> <87zkgvfhra.fsf@gmail.com> <2127.1319148505@alphaville.dokosmarshall.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:38388) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RH0wV-0004ps-Uk for emacs-orgmode@gnu.org; Thu, 20 Oct 2011 18:18:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RH0wU-0008Ql-FC for emacs-orgmode@gnu.org; Thu, 20 Oct 2011 18:18:27 -0400 Received: from mail-yw0-f41.google.com ([209.85.213.41]:39587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RH0wU-0008Qa-49 for emacs-orgmode@gnu.org; Thu, 20 Oct 2011 18:18:26 -0400 Received: by ywa17 with SMTP id 17so299791ywa.0 for ; Thu, 20 Oct 2011 15:18:25 -0700 (PDT) In-Reply-To: <2127.1319148505@alphaville.dokosmarshall.org> (Nick Dokos's message of "Thu, 20 Oct 2011 18:08:25 -0400") 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: nicholas.dokos@hp.com Cc: Org Mode Nick Dokos writes: > Eric Schulte wrote: > >> > Other than "colon confusion" (having to specify ``:results silent'' on >> > the src block header line and ``results silent'' in the #+PROPERTY line >> > to get the same behavior), this looks better. Not sure what (if >> > anything) can or should be done about the colons. >> > >> >> I don't know of a good solution for colons. If we decided to add colons >> then the subtree property blocks would become akward, with entries like >> >> ** foo >> :PROPERTIES: >> ::results: silent >> :END: >> >> I would say we could look for each value both with and without colons, >> but property searches of this nature are slow and doubling the speed >> impact simply for allow colon flexibility doesn't seem to be a good >> tradeoff. I think this will just have to be something that users will >> need to learn. >> > > I agree[fn:1]: the point is to simplify the code, not complicate it > *and* slow down everything at the same time. Maybe the header args > section of the manual can use the "colon as delimiter" method to explain > the equivalent forms and that will suffice. > I agree, the header argument syntax portion of the documentation could be made more clear, and I did like you explanation to Seb's email. Perhaps you could submit a documentation patch? :) > > Nick > > Footnotes: > > [fn:1] ...but I take some perverse pleasure from the fact that both > Suvayu and Seb asked the question :-) I noticed that too, and it no doubt means that this same question will occur to future users. -- Eric Schulte http://cs.unm.edu/~eschulte/