From: Christian Moe <mail@christianmoe.com>
To: Rainer M Krug <r.m.krug@gmail.com>
Cc: Sebastien Vauban <wxhgmqzgwmuf@spammotel.com>, emacs-orgmode@gnu.org
Subject: Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Date: Mon, 24 Oct 2011 13:37:29 +0200 [thread overview]
Message-ID: <4EA54DF9.40307@christianmoe.com> (raw)
In-Reply-To: <CAGhLh6FyDcs+WW+jr0+n1Qj=zenT-PsHPsZ_BGwtL939PqXc3g@mail.gmail.com>
> This all sounds very interesting, but I have problems understanding
> the advantages - possibly because I only had one coffee this morning.
It may not be feasible and the disadvantages may outnumber the
advantages; we'll see. But having several coffees under my belt
already, I'll argue my corner. :-)
To recapitulate, I'm proposing that the values of (declared) variables
for code blocks could be assigned from properties with the same names,
so that:
:PROPERTIES:
:var: x=1, y=2, z=-3
:END:
could also, and interchangeably, be written:
:PROPERTIES:
:x: 1
:y: 2
:z: -3
:var: x, y, z
:END:
Here setting the `var' property with variable names, but without
assignments, would declare that the variables are to be passed to the
src block, and prompt Babel to look for the values in properties with
the same names.
I think some of the advantages should be clear.
First:
------
It would easily let code blocks collect data from Org entry
properties, without having to use lisp expressions or first collecting
the properties in a dynamic block and then referencing the d.b. This
would be nice particularly when your data is already in
outline/property form.
A second advantage:
-------------------
It would allow a great deal of flexibility in passing variables
according to position in the outline hierarchy.
#+BEGIN_EXAMPLE
* Some default settings
:PROPERTIES:
:x: 1
:y: 2
:z: -3
:var: x, y, z
:END:
** For all cases where y=5
:PROPERTIES:
:y: 5
:END:
*** A case where x=1, y=5, z=-3
#+begin_src R
(...)
#+end_src
*** A case where x=1, y=5, z=8: no need to specify y again
#+begin_src R :var z=8
(...)
#+end_src
(z could alternatively have been specified as a property, same as y
above)
#+END_EXAMPLE
This modular re-use of values from higher up in the outline, on any
number of levels, should more than compensate for the loss of
buffer-wide assignments with the #+BABEL header.
With a single :var: property for passing arguments, on the other hand,
this is not possible. You have to re-assign values to all three
variables on each level. (Note: Eric's idea for accumulative
properties, on the other hand, /would/ allow you to do this with a
single :var: property.)
>
> #+PROPERTY: SVNVERSION (vc-working-revision (buffer-file-name))
> #+PROPERTY: SVNSTATE ( symbol-name (vc-state (or
> (buffer-file-name) org-current-export-file)))
> #+PROPERTY: SVNSTATENUM (if (eq (vc-state (or (buffer-file-name)
> org-current-export-file)) 'up-to-date) 0 13)
> #+PROPERTY: DISP_PACKAGE "seedDisp_0.4-13.tar.gz"
>
>
> I think this syntax opens the door for dangerous typos - If you type e.g:
>
> #+PROPERTY: vat x=10
>
> what would this be? it should have been
>
> #+PROPERTY: var x=10
>
> but now?
Now there would be a :vat: property with the value "x=10". It will not
be passed to any code block because (as I imagine the scheme) any
variables to be passed to a code block still need to be /declared/
with a :var: property or :var header argument, so it will not conflict
with any `vat' variable you might have defined in the code. Instead,
you will notice the typo when your code block results in an error
message that x is missing, same as now. The result of misspelling var
under my scheme would be the same as misspelling it now.
> One could allow this syntax in the case that the variable has
> been defined before, by using the var syntax:
To simplify your example, you think this is permissible:
#+PROPERTY: var x, y, z
#+PROPERTY: x 1
#+PROPERTY: y (1+ 1)
#+PROPERTY: z (- 0 3)
but this is not:
#+PROPERTY: x 1
#+PROPERTY: y (1+ 1)
#+PROPERTY: z (- 0 3)
#+PROPERTY: var x, y, z
As I imagine the scheme, it wouldn't matter and the two are
interchangeable. The `#+PROPERTY: y (1+ 1)' assignment, in and of
itself, would only create a property :y: with the string value "(1+
1)". When Babel began to execute a code block, it would first look up
the value of the property :var: at point to see what variables to
pass, and the order of the PROPERTY headers is not important. It would
then look for the values of the properties :x:, :y: and :z: at point,
and only then, knowing that these are variables for a code block,
would it evaluate any lisp expressions in these values.
A third advantage:
------------------
It would provide one way to solve your problem -- very long assignment
expressions that are difficult to group on a line. It is not
necessarily the best way to solve that specific problem, compared with
the various options Eric came up with, such as #+PROPERTY+:.
>
> But this would not make
>
> #+PROPERTY+:
>
> redundant, but rather enhance it.
Possibly; my solution only applies to the :var passed to a code block;
there may be other property assignments that it would be good to be
able to split over several lines. Also, I can certainly see the
attraction of the analogous #+TBLFM+: -- though I'm fine with the
existing `C-c '' solution for that, and would be equally happy to see
that solution extended to solve your problem.
Yours,
Christian
next prev parent reply other threads:[~2011-10-24 11:35 UTC|newest]
Thread overview: 132+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-20 19:43 [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines Eric Schulte
2011-10-20 20:06 ` Nick Dokos
2011-10-20 20:12 ` Eric Schulte
2011-10-20 20:51 ` Nick Dokos
2011-10-20 21:04 ` Sebastien Vauban
2011-10-20 21:50 ` [RFC] Standardized code block keywords Eric Schulte
2011-10-21 1:52 ` Thomas S. Dye
2011-10-21 2:57 ` Nick Dokos
2011-10-21 7:26 ` Christian Moe
2011-10-21 16:12 ` Eric Schulte
2011-10-21 19:10 ` Thomas S. Dye
2011-10-23 12:20 ` Daniel Bausch
2011-10-23 16:09 ` Thomas S. Dye
2011-10-24 5:49 ` Daniel Bausch
2011-10-21 8:17 ` Sebastien Vauban
2011-10-21 16:17 ` Eric Schulte
2011-10-21 17:37 ` Sebastien Vauban
[not found] ` <CAGhLh6GXg6nMZ-xdu-EP=YRx7Pznrme2Yq1S0vdc6Yq0tPMxFg@mail.gmail.com>
2011-10-25 6:59 ` Rainer M Krug
2011-10-21 16:08 ` Eric Schulte
2011-10-21 16:05 ` Eric Schulte
2011-10-21 18:02 ` Thomas S. Dye
2011-10-22 15:19 ` Eric Schulte
2011-10-21 7:43 ` Torsten Wagner
2011-10-21 8:27 ` Sebastien Vauban
2011-10-21 16:25 ` Eric Schulte
2011-10-21 16:24 ` Eric Schulte
2011-10-21 17:41 ` Sebastien Vauban
2011-10-24 1:06 ` Torsten Wagner
2011-10-25 6:44 ` Rainer M Krug
2011-10-25 7:24 ` Jambunathan K
2011-10-25 8:21 ` Sebastien Vauban
2011-10-21 12:22 ` Nicolas Goaziou
2011-10-21 16:27 ` Eric Schulte
2011-10-21 17:48 ` Eric Schulte
2011-10-21 19:24 ` Viktor Rosenfeld
2011-10-23 12:42 ` Daniel Bausch
2011-10-24 7:37 ` Eric S Fraga
2011-10-24 14:39 ` Darlan Cavalcante Moreira
2011-10-24 7:47 ` Sebastien Vauban
2011-10-25 1:30 ` Eric Schulte
2011-10-25 7:14 ` Daniel Bausch
2011-10-25 8:14 ` Sebastien Vauban
2011-10-25 14:44 ` Eric Schulte
2011-10-25 15:38 ` Christian Moe
2011-10-25 15:42 ` Nick Dokos
2011-10-25 16:28 ` Martyn Jago
2011-10-25 16:49 ` Eric Schulte
2011-10-25 17:21 ` Nick Dokos
2011-10-26 5:58 ` Daniel Bausch
2011-10-26 13:10 ` Giovanni Ridolfi
2011-10-26 14:41 ` Daniel Bausch
2011-10-26 15:04 ` Nick Dokos
2011-10-27 5:25 ` Daniel Bausch
2011-10-28 16:49 ` Eric Schulte
2011-10-28 18:31 ` Eric Schulte
2011-10-28 18:40 ` Nick Dokos
2011-10-28 18:52 ` Eric Schulte
2011-10-28 23:22 ` Nick Dokos
2011-10-28 23:39 ` Thomas S. Dye
2011-10-29 2:18 ` Nick Dokos
2011-10-31 7:25 ` Daniel Bausch
2011-10-31 19:01 ` Eric Schulte
2011-11-01 6:34 ` C-c C-c not working at end of #+end_src line (was: [RFC] Standardized code block keywords) Daniel Bausch
2011-10-25 14:17 ` [RFC] Standardized code block keywords Eric Schulte
2011-10-26 5:41 ` Daniel Bausch
2011-10-26 6:17 ` Thomas S. Dye
2011-10-26 12:16 ` Eric Schulte
2011-10-21 18:14 ` Thorsten
2011-10-20 21:34 ` [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines Eric Schulte
2011-10-20 21:44 ` suvayu ali
2011-10-20 21:52 ` Eric Schulte
2011-10-20 22:23 ` Suvayu Ali
2011-10-20 21:47 ` Sebastien Vauban
2011-10-20 21:54 ` Eric Schulte
2011-10-20 21:57 ` Nick Dokos
2011-10-20 21:48 ` Nick Dokos
2011-10-20 21:57 ` Eric Schulte
2011-10-20 22:08 ` Nick Dokos
2011-10-20 22:18 ` Eric Schulte
2011-10-21 7:28 ` Sebastien Vauban
2011-10-21 8:14 ` Christian Moe
2011-10-21 9:12 ` Rainer M Krug
2011-10-21 10:47 ` Christian Moe
2011-10-21 10:59 ` Rainer M Krug
2011-10-21 11:17 ` Christian Moe
2011-10-21 11:18 ` Rainer M Krug
2011-10-21 17:37 ` Eric Schulte
2011-10-21 18:09 ` Nick Dokos
2011-10-22 15:25 ` Eric Schulte
2011-10-21 18:35 ` Rainer M Krug
2011-10-21 18:40 ` Rainer M Krug
2011-10-22 7:58 ` Christian Moe
2011-10-24 9:44 ` Rainer M Krug
2011-10-22 15:52 ` Eric Schulte
2011-10-22 19:07 ` Christian Moe
2011-10-24 10:10 ` Rainer M Krug
2011-10-24 11:37 ` Christian Moe [this message]
2011-10-24 12:11 ` Sebastien Vauban
2011-10-24 12:38 ` Christian Moe
2011-10-24 15:07 ` Nicolas Goaziou
2011-10-24 9:50 ` Rainer M Krug
2011-10-25 9:35 ` Sebastien Vauban
2011-10-25 10:06 ` Rainer M Krug
2011-10-25 10:31 ` Sebastien Vauban
2011-10-25 11:47 ` Rainer M Krug
2011-10-25 14:13 ` Eric Schulte
2011-10-26 14:00 ` Sebastien Vauban
2011-10-26 15:20 ` Eric Schulte
2011-10-22 15:26 ` Eric Schulte
2011-10-21 20:24 ` Christian Moe
2011-10-21 21:05 ` Darlan Cavalcante Moreira
2011-10-22 7:08 ` Sebastien Vauban
2011-10-22 15:53 ` Eric Schulte
2011-10-24 18:07 ` Darlan Cavalcante Moreira
2011-10-31 18:53 ` Eric Schulte
2011-10-31 20:18 ` Samuel Wales
[not found] ` <87obwwkia5.fsf@gmail.com>
[not found] ` <CAJcAo8scJXx=3s0f_FDAJXFKW2uh5gFTHwgDRbM6xXohr5ZPzQ@mail.gmail.com>
2011-10-31 22:22 ` Samuel Wales
2011-11-01 1:28 ` Eric Schulte
2011-11-01 14:26 ` Nick Dokos
2011-11-01 15:02 ` Nick Dokos
2011-11-01 15:17 ` Eric Schulte
2011-11-02 11:12 ` Rainer M Krug
2011-11-02 12:18 ` Nicolas Goaziou
2011-11-02 14:16 ` Rainer M Krug
2011-11-03 18:40 ` Eric Schulte
2011-11-03 18:51 ` Jambunathan K
2011-11-04 9:15 ` Rainer M Krug
2011-11-02 12:57 ` Brian Wightman
2011-11-02 14:18 ` Rainer M Krug
2011-11-03 1:29 ` Bastien
2011-10-20 21:27 ` Christian Moe
2011-10-20 21:32 ` Nick Dokos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EA54DF9.40307@christianmoe.com \
--to=mail@christianmoe.com \
--cc=emacs-orgmode@gnu.org \
--cc=r.m.krug@gmail.com \
--cc=wxhgmqzgwmuf@spammotel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).