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

[Rainer M Krug <r.m.krug@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3887 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5464 bytes --]