From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines Date: Fri, 21 Oct 2011 11:12:11 +0200 Message-ID: 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> <87vcrjfgt1.fsf@gmail.com> <80sjmmvm60.fsf@somewhere.org> <4EA129DB.4070006@christianmoe.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0016e64f81dadf731d04afcb77cb Return-path: Received: from eggs.gnu.org ([140.186.70.92]:54519) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHB9C-0001Wg-LG for emacs-orgmode@gnu.org; Fri, 21 Oct 2011 05:12:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RHB9A-000634-JY for emacs-orgmode@gnu.org; Fri, 21 Oct 2011 05:12:14 -0400 Received: from mail-qy0-f169.google.com ([209.85.216.169]:44487) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHB9A-00062t-FH for emacs-orgmode@gnu.org; Fri, 21 Oct 2011 05:12:12 -0400 Received: by qyk29 with SMTP id 29so341564qyk.0 for ; Fri, 21 Oct 2011 02:12:11 -0700 (PDT) In-Reply-To: <4EA129DB.4070006@christianmoe.com> 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: mail@christianmoe.com Cc: Sebastien Vauban , emacs-orgmode@gnu.org --0016e64f81dadf731d04afcb77cb Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 21, 2011 at 10:14 AM, Christian Moe wrote: > Hi again, > > I can quickly think of two advantages of the late lamented (if only by me) > #+BABEL header over using properties. > I also think that keeping the #+BABEL would be a good idea, as it keeps the options for babel separate (as are the functions - org-babel... ). It is true that babel is getting more and more interwined with org (which is a good think), but especially in my case, I use org more or less exclusively for literate programming (babel) and some org features (archiving, note capture...) in this context, it would be really nice to be able to keep the options for babel easily identifyable. I defined a new drawer (:BABEL:) and put my options / arguments / properties for babel in there. So my question would be: would i be possible to leave #+BABEL as an equivalent for #+PROPERTY ? Yes, it could be misused, but also used to make these options easily identifyable. My setup at the moment: #+DRAWERS: HIDDEN PROPERTIES STATE CONFIG BABEL OUTPUT LATEX :BABEL: #+BABEL: :session *R* #+BABEL: :results output #+BABEL: :exports code #+BABEL: :comments yes #+BABEL: :tangle Analysis_sensitivity.R #+BABEL: :var RESULTSDIR="/media/Results/clusterResults/nsa/LHCube/nsa.91.up-to-date/results/" #+BABEL: :var ANALYSISDIR="/home/rkrug/Documents/Projects/BiocontrolAndAlienDynamics/nonSpatialAcacia/LHCube/nsa.91.up-to-date/analysis/" :END: > 1. Allowing you to specify multiple buffer-wide options on the same line > (keeping things short), in the same colon :syntax as used in a src block > header (keeping things consistent and easy to copy back and forth). None of > this makes a substantive difference. > > 2. Allowing you to pass multiple buffer-wide arguments with :var. This > could make a substantive difference in some applications. The following will > work: > > #+BABEL: :var euro=1.3791 :var salestax=.15 > > The following will not, since it tries to set the same property: > > #+PROPERTY: var euro=1.3791 > #+PROPERTY: var salestax=.15 > I think it is a very important point, that the construct with :var still works - but as Eric only mentioned the *naming*, I assume that in the actual usage nothing changes. OK - the colon at the beginning - but I clud live with that change, although it makes it clear what the actual argument is which is set. > If BABEL is dropped for PROPERTY, it would be good for the :var: property > to support multiple arguments (comma-separated would be good for consistency > with passing arguments through the SRCNAME). E.g.: > > #+PROPERTY: var euro=1.3791, salestax=.15 > I think that would be a good idea, but I think that was already discussed some time ago and rejected? > I think I'd like this better in any case. > No - rather in separate lines... but different strokes for different folks... Cheers, Rainer > Yours, > Christian > > > > On 10/21/11 9:28 AM, Sebastien Vauban wrote: > >> Multiple lines may be used to specify multiple properties. e.g., >>> >>> #+PROPERTY: results silent >>> #+PROPERTY: cache yes >>> >> >> *But* I did not know it was limited to _one property per line_. >> >> Knowing that: >> >> - there is no confusion at all -- we simply (have to) know that the first >> word >> is the "name" without colon, and the rest are "values" >> >> - my argument in favor of #+PROPERTIES (over #+PROPERTY) simply falls. >> >> To sum up, I'm perfectly happy with the new choice. >> >> Best regards, >> Seb >> >> > > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D): +49 - (0)3 21 21 25 22 44 email: Rainer@krugs.de Skype: RMkrug --0016e64f81dadf731d04afcb77cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Oct 21, 2011 at 10:14 AM, Christ= ian Moe <mail= @christianmoe.com> wrote:
Hi again,

I can quickly think of two advantages of the late lamented (if only by me) = #+BABEL header over using properties.

I also think= that keeping the #+BABEL would be a good idea, as it keeps the options for= babel separate (as are the functions - org-babel... ). It is true that bab= el is getting more and more interwined with org (which is a good think), bu= t especially in my case, I use org more or less exclusively for literate pr= ogramming (babel) and some org features (archiving, note capture...) in thi= s context, it would be really nice to be able to keep the options for babel= easily identifyable.

I defined a new drawer (:BABEL:) and put my options / arguments / prope= rties for babel in there. So my question would be: would i be possible to l= eave #+BABEL as an equivalent for #+PROPERTY ? Yes, it could be misused, bu= t also used to make these options easily identifyable.

My setup at the moment:

#+DRAWERS: HIDDEN PROPERTIES STATE CONFI= G BABEL OUTPUT LATEX

:BABEL:
#+BABEL: :session *R*
#+BABEL: :r= esults output
#+BABEL: :exports code
#+BABEL: :comments yes
#+BAB= EL: :tangle Analysis_sensitivity.R
#+BABEL: :var RESULTSDIR=3D"/media/Results/clusterResults/nsa/LHCube/n= sa.91.up-to-date/results/"
#+BABEL: :var ANALYSISDIR=3D"/home/= rkrug/Documents/Projects/BiocontrolAndAlienDynamics/nonSpatialAcacia/LHCube= /nsa.91.up-to-date/analysis/"
:END:



1. Allowing you to specify multiple buffer-wide options on the same line (k= eeping things short), in the same colon :syntax as used in a src block head= er (keeping things consistent and easy to copy back and forth). None of thi= s makes a substantive difference.

2. Allowing you to pass multiple buffer-wide arguments with :var. This coul= d make a substantive difference in some applications. The following will wo= rk:

=A0#+BABEL: :var euro=3D1.3791 :var salestax=3D.15

The following will not, since it tries to set the same property:

=A0#+PROPERTY: var euro=3D1.3791
=A0#+PROPERTY: var salestax=3D.15

I think it is a= very important point, that the construct with :var still works - but as Er= ic only mentioned the *naming*, I assume that in the actual usage nothing c= hanges.

OK - the colon at the beginning - but I clud live with that change, alt= hough it makes it clear what the actual argument is which is set.


If BABEL is dropped for PROPERTY, it would be good for the :var: property t= o support multiple arguments (comma-separated would be good for consistency= with passing arguments through the SRCNAME). E.g.:

=A0#+PROPERTY: var euro=3D1.3791, salestax=3D.15

= I think that would be a good idea, but I think that was already discussed s= ome time ago and rejected?


I think I'd like this better in any case.

No -= rather in separate lines... but different strokes for different folks...= =A0

Cheers,

Rainer


Yours,
Christian



On 10/21/11 9:28 AM, Sebastien Vauban wrote:
Multiple lines may be used to specify multiple properties. e.g.,

#+PROPERTY: results silent
#+PROPERTY: cache yes

*But* I did not know it was limited to _one property per line_.

Knowing that:

- there is no confusion at all -- we simply (have to) know that the first w= ord
=A0 is the "name" without colon, and the rest are "values&q= uot;

- my argument in favor of #+PROPERTIES (over #+PROPERTY) simply falls.

To sum up, I'm perfectly happy with the new choice.

Best regards,
=A0 Seb






--
Rainer M. K= rug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl= . Phys. (Germany)

Centre of Excellence for Invasion Biology
Stell= enbosch University
South Africa

Tel : =A0 =A0 =A0 +33 - (0)9 53 10 27 44
Cell: =A0 = =A0 =A0 +33 - (0)6 85 62 59 98
Fax (F): =A0 =A0 =A0 +33 - (0)9 58 10 27 = 44

Fax (D): =A0 =A0+49 - (0)3 21 21 25 22 44

email: =A0 =A0 = =A0Rainer@krugs.de=

Skype: =A0 =A0 =A0RMkrug

--0016e64f81dadf731d04afcb77cb--