From: Christian Moe <mail@christianmoe.com>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: Sebastien Vauban <wxhgmqzgwmuf@spammotel.com>, emacs-orgmode@gnu.org
Subject: Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Date: Sat, 22 Oct 2011 21:07:03 +0200 [thread overview]
Message-ID: <4EA31457.3090800@christianmoe.com> (raw)
In-Reply-To: <87fwil10o2.fsf@gmail.com>
Hi,
Eric Schulte wrote:
>
> I can think of three options for how to handle this situation.
>
> 1. If it turns out to be possible/desirable my preferred solution
> here would be to add general property support for appending values
> to properties when properties are over specified
(...)
>
> 2. Adding a "#+PROPERTY:" line authoring helper similar to the
> table formula helper making it more natural to edit such long
> property lines.
>
> 3. It may be possible to add syntax for extending #+PROPERTY:
> specifications across multiple lines, something like
>
> #+PROPERTY: var MAINVERSION=0,
> #+PROPERTY+: SVNVERSION=(vc-working-revision (buffer-file-name)),
(...)
These are all interesting ideas, as was Darlan's alternative
suggestion to Eric's suggestion (1), namely to use a special inherit
argument.
I'd like to toss out a different idea, which I think is brilliant, but
which may go down in flames once we've had a time to think it through.
(And sorry if it's been proposed before; I came to Org just as
Org-Babel was being stabilized.)
In short, let Babel assign to any declared variables of a src block
the values of any properties at point with the same name. In other words:
- The :var header argument / :var: property could declare variables
without assigning values, that is, you could have
`:var foo=1, bar, baz=3' to tell Babel that `bar' is a variable too.
- When a variable is declared, but no value assigned, Babel would look
for a property (e.g. `:bar: 2') at point with the same name as the
variable.
- If property inheritance is turned on, this means a variable can be
specified at any level of the outline.
- If no further changes were made (such as the property accumulation
Eric suggested), it would still be possible to /declare/ variables
only at /one/ level of the outline besides in the code block and
calls, since declarations all belong to the same `:var:' property.
However, this approach would mean that declarations could be kept
short and there would be a great deal of modularity in what values
would be assigned.
Two examples follow.
---
Example 1.
Darlan suggested a special "inherit" argument, as follows:
* Code with foo
:PROPERTIES:
:var: foo=1
:END:
** Code with foo and bar
:PROPERTIES:
:var: bar=2, inherit
:END:
src_block
** Code with foo and baz
:PROPERTIES:
:var: baz=3, inherit
:END:
src_block
Here is the same example under my proposal and with property
inheritance turned on:
* Code with foo
:PROPERTIES:
:foo: 1
:END:
** Code with foo and bar
:PROPERTIES:
:bar: 2
:END:
src_block :var foo, bar
** Code with foo and baz
:PROPERTIES:
:baz: 3
:END:
src_block :var foo, baz
Instead of declaring foo,bar and foo,baz in the src_blocks, we could
define them once and for all at the top of the outline:
* Code with foo
:PROPERTIES:
:foo: 1
:var: foo, bar, baz
:END:
** Code with foo and bar
:PROPERTIES:
:bar: 2
:END:
src_block
** Code with foo and baz
:PROPERTIES:
:baz: 3
:END:
src_block
Under the first subhead, Org-babel would know (because the :var:
property is inherited) to look for foo, bar and baz properties. It
would find values for foo and bar (bar is defined as a property of
that subhead, foo is inherited from the top-level heading). It would
not find any value for baz. At this point, since no value could be
assigned to baz, it would be ignored and would not be passed to the
code block.
---
Example 2.
Let's take Rainer's problem :
On 10/22/11 5:52 PM, Eric Schulte wrote:
>>
>> #+BABEL: :var MAINVERSION=0
>> #+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name))
>> #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file)))
>> #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13)
>> #+BABEL: :var DISP_PACKAGE="seedDisp_0.4-13.tar.gz"
>>
Have a buffer-level property for all the long lines (sorry if my email
client wraps these lines):
#+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"
Also, we have a buffer-level line declaring all these variables, and
including MAINVERSION with the ordinary assignment. Thanks to last
night's change, we can list them all on one line.
#+PROPERTY: var MAINVERSION=0, SVNVERSION, SVNSTATE, SVNSTATENUM,
DISP_PACKAGE
I don't know what kind of code this example applies to, but let's
imagine that we also have a header that resets one of these properties:
* Variant for main version 1
:PROPERTIES:
:MAINVERSION: 1
:END:
...and below that, we finally have a code block, with a header that
declares a variable locally:
#+HEADERS: :var somelocalvar="something or other"
#+BEGIN_SRC Perl
while(...) {
...
}
#+END_SRC
This should expand to something like:
#!/usr/bin/perl
use warnings;
my $MAINVERSION = 1;
my $SVNVERSION = "0.4.13";
my $SVNSTATE = "something or other"
my $SVNSTATENUM = 13;
my $DISP_PACKAGE = "seedDisp_0.4-13.tar.gz";
my $somelocalvar = "something or other";
while(...) {
...
}
---
OK, hopefully my idea is clear by now.
Could it be made to work?
Would it solve some problems?
Would it mess other things up even worse?
Yours,
Christian
next prev parent reply other threads:[~2011-10-22 19:04 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 [this message]
2011-10-24 10:10 ` Rainer M Krug
2011-10-24 11:37 ` Christian Moe
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=4EA31457.3090800@christianmoe.com \
--to=mail@christianmoe.com \
--cc=emacs-orgmode@gnu.org \
--cc=schulte.eric@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).