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 15:57:26 -0600 Message-ID: <87zkgvfhra.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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:38832) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RH0cg-0000Jx-Rr for emacs-orgmode@gnu.org; Thu, 20 Oct 2011 17:58:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RH0cZ-0004es-3G for emacs-orgmode@gnu.org; Thu, 20 Oct 2011 17:57:53 -0400 Received: from mail-gy0-f169.google.com ([209.85.160.169]:38689) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RH0cY-0004eV-KY for emacs-orgmode@gnu.org; Thu, 20 Oct 2011 17:57:50 -0400 Received: by gyf3 with SMTP id 3so3867528gyf.0 for ; Thu, 20 Oct 2011 14:57:48 -0700 (PDT) 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: > >> ... I've just pushed up what I >> consider to be a clean implementation. Put briefly the new behavior is >> that "properties may be used to specify header arguments". More >> completely... >> >> 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist. >> >> 2. The existing #+PROPERTY: line may now be used to specify values for >> header arguments, e.g., >> >> #+PROPERTY: results silent >> >> would silence all results in the current buffer. >> >> I think this should be simple, easy to remember, and it certainly >> cleaned up the code base. Please let me know what you think of this new >> setup. >> > > 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. Cheers -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/