emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Darlan Cavalcante Moreira <darcamo@gmail.com>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: Sebastien Vauban <wxhgmqzgwmuf@spammotel.com>,
	emacs-orgmode@gnu.org, mail@christianmoe.com
Subject: Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Date: Mon, 24 Oct 2011 15:07:16 -0300	[thread overview]
Message-ID: <4ea5a95b.059dec0a.606e.0c92@mx.google.com> (raw)
In-Reply-To: <87aa8t10np.fsf@gmail.com>


I didn't check the list for 3 days and this thread became a little hard to
follow. So, forgive me if I'm "answering" the wrong E-Mail.


I liked Christian's idea of using a single "var" property to tell babel
which regular properties it should use as variables (ignoring any variable
not defined). This would be enough for my use cases.

On the other hand, some way to append values to a property, such as using
some special keyword as I have suggested, could be a better solution in
order to keep consistence if people want this feature for non-babel related
properties.

--
Darlan

At Sat, 22 Oct 2011 09:53:25 -0600,
Eric Schulte wrote:
> 
> Darlan Cavalcante Moreira <darcamo@gmail.com> writes:
> 
> > It's excellent that now babel understands multiple values in the "var"
> > property (I was one of the people that wanted this), but "There Is One More
> > Thing".
> >
> > Would it be feasible to inherit variables from parent sub-trees?
> > Effectively, I'd like to append new values in lower level sub-trees, but
> > AFAIK setting the var property in a sub-tree will still replace the value
> > set in the parent sub-tree.
> >
> 
> Currently every new property specification entirely replaced previous
> specifications with the same name.
> 
> >
> > That is, in the example below the level-2 sub-trees would not have the foo
> > variable passed to babel.
> > * Code with foo
> >   :PROPERTIES:
> >   :var:      foo=1
> >   :END:
> >
> > ** Code only with bar
> >    :PROPERTIES:
> >    :var:      bar=2
> >    :END:
> >    src_block
> > ** Code only with baz
> >    :PROPERTIES:
> >    :var:      baz=3
> >    :END:
> >    src_block
> >
> > Maybe a special keyword, such as "inherit" (or "append") could be used to
> > incorporate variables defined in the parent sub-tree, such that the example
> > would become
> > * 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
> >
> > This should not affect global variables and "inherit" would inherit
> > variables defined only in the parent sub-tree (unless it also contains the
> > inherit keyword).
> >
> > As a use case scenario, suppose I need to perform simulations for a few
> > different scenarios, each with small variations. This would allow me to
> > define common variables for a scenario in a higher level sub-tree and more
> > specific variables in the lower level sub-trees.
> >
> 
> This sounds somewhat similar to my suggestion in reply to Rainer's
> email.
> 
> Best -- Eric
> 
> >
> > --
> > Darlan Cavalcante
> >
> >
> > At Fri, 21 Oct 2011 22:24:25 +0200,
> > Christian Moe <mail@christianmoe.com> wrote:
> >> 
> >> Hi,
> >> 
> >> Yes, that works nicely, and should solve Rainer's problem.
> >> I haven't been able to think of anything else that can't be handled by 
> >> properties.
> >> 
> >> And I do think it's a good idea to winnow down the syntax a bit, even 
> >> if things break. I just like to grumble.
> >> :-)
> >> 
> >> Yours,
> >> Christian
> >> 
> >> On 10/21/11 7:37 PM, Eric Schulte wrote:
> >> > Nice idea.  This same issue with "var" arose when we first started
> >> > allowing header arguments to be specified inside subtree properties.
> >> > I've just implemented your suggestion so the following are now possible.
> >> >
> >> > #+PROPERTY: var foo=1, bar=2
> >> > #+PROPERTY: cache yes
> >> >
> >> > #+begin_src emacs-lisp
> >> >    (+ foo bar)
> >> > #+end_src
> >> >
> >> > #+results[be32e67491d4e92f75769aebe423c20ca01626fe]:
> >> > : 3
> >> >
> >> > and
> >> >
> >> > #+begin_src emacs-lisp :var foo="this", bar="that"
> >> >    (concat foo " " bar)
> >> > #+end_src
> >> >
> >> > #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]:
> >> > : this that
> >> >
> >> > Thanks for the suggestion and I hope the above is a sufficient
> >> > replacement for the now-missing #+BABEL: syntax.
> >> >
> >> > Cheers -- Eric
> >> 
> >> 
> 
> -- 
> Eric Schulte
> http://cs.unm.edu/~eschulte/

  reply	other threads:[~2011-10-24 18:07 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
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 [this message]
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=4ea5a95b.059dec0a.606e.0c92@mx.google.com \
    --to=darcamo@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=mail@christianmoe.com \
    --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).