emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lin


From: Rainer M Krug
Subject: Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Date: Fri, 21 Oct 2011 11:12:11 +0200



On Fri, Oct 21, 2011 at 10:14 AM, Christian Moe <address@hidden> 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:      address@hidden

Skype:      RMkrug


reply via email to

[Prev in Thread] Current Thread [Next in Thread]