Eric: Thanks - but for the moment I will go with Jambunathan's suggestion
and stick with the latest version before the removal of BABEL.
For the record, I created a local branch before the removal of BABEL and
used
git checkout MyBranch
to switch to this branch. So I can keep my local git repo
In order to prevent confusion or needless argument: the path I
think we should back off of is the committing of these changes to
master - I think the work should be done in a branch and cooked
thoroughly before merging it to master.
Partly agree here - I was bitten by the changes, and
Rainer - if he feels uncomfortable - can choose *not* to update his git
repo and switch his local checkout to a historical version.
[1] to see the info page evaluate (info (elisp)File Local
Variables)
A usage note for adding these variables without straining the brain.
M-x
On Tue, Nov 1, 2011 at 4:17 PM, Eric Schulte schulte.e...@gmail.com wrote:
Nick Dokos nicholas.do...@hp.com writes:
Nick Dokos nicholas.do...@hp.com wrote:
Can we please back off this path?
In order to prevent confusion or needless argument: the path I think we
should back off of
Hello,
Rainer M Krug r.m.k...@gmail.com writes:
Then one should possibly also think of merging #+LATEX into #+PROPERTY -
which I think would make it more consistent (and this is a serious
suggestion).
Are you sure you're talking about the #+LATEX: keywords, allowing to
insert LaTeX code only
On Tue, Nov 1, 2011 at 10:17 AM, Eric Schulte schulte.e...@gmail.com wrote:
This is also after all the development repository, and while I do try
very hard never to break this head of this repository at the same time I
think it is an acceptable place to try out new functionality.
Given that a
On Wed, Nov 2, 2011 at 1:18 PM, Nicolas Goaziou n.goaz...@gmail.com wrote:
Hello,
Rainer M Krug r.m.k...@gmail.com writes:
Then one should possibly also think of merging #+LATEX into #+PROPERTY -
which I think would make it more consistent (and this is a serious
suggestion).
Are you
On Wed, Nov 2, 2011 at 1:57 PM, Brian Wightman
midlife...@wightmanfam.orgwrote:
On Tue, Nov 1, 2011 at 10:17 AM, Eric Schulte schulte.e...@gmail.com
wrote:
This is also after all the development repository, and while I do try
very hard never to break this head of this repository at the same
Hi Brian,
Brian Wightman midlife...@wightmanfam.org writes:
Given that a common recommendation for a bug fix is to 'try commit
blah blah blah', would it make sense to have bug fixes go onto a
'maint' branch (as well as master), and new features / changed
features stay on the master branch?
Eric Schulte schulte.e...@gmail.com wrote:
My concerns with respect to a property drawer solution are two fold.
1) In the same way that #+PROPERTY: assumes its value will live on a
single line, property drawers assume that their values will live on a
single line. I don't see how it
Nick Dokos nicholas.do...@hp.com wrote:
Can we please back off this path?
In order to prevent confusion or needless argument: the path I think we
should back off of is the committing of these changes to master - I think
the work should be done in a branch and cooked thoroughly before merging
Nick Dokos nicholas.do...@hp.com writes:
Nick Dokos nicholas.do...@hp.com wrote:
Can we please back off this path?
In order to prevent confusion or needless argument: the path I think we
should back off of is the committing of these changes to master - I think
the work should be done in
It is now possible to specify multi-line properties using a property
block. This should make it more natural to specify many file-wide
variables through properties. For example,
#+begin_property
var foo=1,
bar=2,
baz=3,
qux=4
#+end_property
#+begin_src
On 2011-10-31, Eric Schulte schulte.e...@gmail.com wrote:
It is now possible to specify multi-line properties using a property
block. This should make it more natural to specify many file-wide
variables through properties. For example,
Could this be changed to work using the property drawer?
Hi Eric,
Properties can be specified in the properties drawer. But
multiple-line ones cannot at present (at least not without serializing the way
multiple-line macros are serialized).
Therefore you propose new syntax for multiple-line properties.
I propose that allowing the properties drawer
My concerns with respect to a property drawer solution are two fold.
1) In the same way that #+PROPERTY: assumes its value will live on a
single line, property drawers assume that their values will live on a
single line. I don't see how it will be easier to fold multi-line
properties
Hi Eric,
Eric Schulte wrote:
I think that makes sense.
While thinking about all of this, and working in real-life documents, I just
came back to a suggestion which I made some time ago. It goes about this
enhancement:
Would it be possible to specify buffer-wide language specific header
Sebastien Vauban wxhgmqzgw...@spammotel.com writes:
Hi Eric,
Eric Schulte wrote:
I think that makes sense.
While thinking about all of this, and working in real-life documents, I just
came back to a suggestion which I made some time ago. It goes about this
enhancement:
Would it be
Hi Eric,
Eric Schulte wrote:
#+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))
On Tue, Oct 25, 2011 at 11:35 AM, Sebastien Vauban
wxhgmqzgw...@spammotel.com wrote:
Hi Eric,
Eric Schulte wrote:
#+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:
Hi Rainer,
Rainer M Krug wrote:
While thinking about all of this, and working in real-life documents, I
just
came back to a suggestion which I made some time ago. It goes about this
enhancement:
Would it be possible to specify buffer-wide language specific header
arguments?
That
On Tue, Oct 25, 2011 at 12:31 PM, Sebastien Vauban
wxhgmqzgw...@spammotel.com wrote:
Hi Rainer,
Rainer M Krug wrote:
While thinking about all of this, and working in real-life documents, I
just
came back to a suggestion which I made some time ago. It goes about this
enhancement:
I think that makes sense.
While thinking about all of this, and working in real-life documents, I just
came back to a suggestion which I made some time ago. It goes about this
enhancement:
Would it be possible to specify buffer-wide language specific header
arguments?
Yes, this
On Sat, Oct 22, 2011 at 9:58 AM, Christian Moe m...@christianmoe.comwrote:
On 10/21/11 8:40 PM, Rainer M Krug wrote:
Just to add to it: at the moment I have e.g:
#+BABEL: :var MAINVERSION=0
#+BABEL: :var SVNVERSION=(vc-working-**revision (buffer-file-name))
#+BABEL: :var SVNSTATE=(
On Sat, Oct 22, 2011 at 5:52 PM, Eric Schulte schulte.e...@gmail.comwrote:
Just to add to it: at the moment I have e.g:
#+BABEL: :var MAINVERSION=0
#+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name))
#+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name)
On Sat, Oct 22, 2011 at 9:07 PM, Christian Moe m...@christianmoe.comwrote:
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
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
Hi all,
Christian Moe wrote:
This all sounds very interesting, but I have problems understanding
the advantages - possibly because I only had one coffee this morning.
I think some of the advantages should be clear.
A second advantage:
---
It would allow a great deal of
On 10/24/11 2:11 PM, Sebastien Vauban wrote:
(...)
But I just have a comment on your second advantage, something that can render
your example inefficient: inheritance is not on by default, and you need to
enable if for *specific properties*.
You can set `org-use-property-inheritance' to t, to
Hello,
Christian Moe m...@christianmoe.com writes:
But you're right, property inheritance is not on by default and
I forgot to mention that this time around. (I think I did mention it
in the previous long message where I presented the idea.)
AFAIK, Babel has always searched its properties
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).
Hi Darlan,
Darlan Cavalcante Moreira wrote:
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
On 10/21/11 8:40 PM, Rainer M Krug wrote:
Just to add to it: at the moment I have e.g:
#+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
Will
#+PROPERTY: var foo=1
#+PROPERTY: var bar=2
also work, or result in one variable not signed?
Try it out :)
This is a question about property behavior not specific to code blocks.
I believe that the second line will override the first, which is why it
was necessary to be able to
Just to clarify my understanding: on a #+PROPERTY line, you *have* to
say
#+PROPERTY: var a=1, b=2
but in the code block itself, you can say *either*
#+begin_src emacs-lisp :var a=1, b=2
...
*or*
#+begin_src emacs-lisp :var a=1 :var b=2
...
correct
Experimentally, both of
Just to add to it: at the moment I have e.g:
#+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
Darlan Cavalcante Moreira darc...@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
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
Hi Eric and Nick,
Eric Schulte wrote:
Nick Dokos nicholas.do...@hp.com writes:
Eric Schulte schulte.e...@gmail.com wrote:
Other than colon confusion (having to specify ``:results silent'' on
the src block header line and ``results silent'' in the #+PROPERTY line
to get the same
Hi again,
I can quickly think of two advantages of the late lamented (if only by
me) #+BABEL header over using properties.
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
On Fri, Oct 21, 2011 at 10:14 AM, Christian Moe m...@christianmoe.comwrote:
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
On 10/21/11 11:12 AM, Rainer M Krug wrote:
On Fri, Oct 21, 2011 at 10:14 AM, Christian Moe m...@christianmoe.com
mailto:m...@christianmoe.com wrote:
(...)
2. Allowing you to pass multiple buffer-wide arguments with :var.
This could make a substantive difference in some applications.
On Fri, Oct 21, 2011 at 12:47 PM, Christian Moe m...@christianmoe.comwrote:
On 10/21/11 11:12 AM, Rainer M Krug wrote:
On Fri, Oct 21, 2011 at 10:14 AM, Christian Moe m...@christianmoe.com
mailto:m...@christianmoe.com** wrote:
(...)
2. Allowing you to pass multiple buffer-wide
On 10/21/11 12:59 PM, Rainer M Krug wrote:
So, using your above mentioned example, after the first PROPERTY line,
euro=1.3795 and SALESTAX not set, while after the second one
salestax=.15, and euro is unset? That would be quite bad.
That's what I'd expected, but actually, euro is set and
On Fri, Oct 21, 2011 at 1:17 PM, Christian Moe m...@christianmoe.comwrote:
On 10/21/11 12:59 PM, Rainer M Krug wrote:
So, using your above mentioned example, after the first PROPERTY line,
euro=1.3795 and SALESTAX not set, while after the second one
salestax=.15, and euro is unset? That
Christian Moe m...@christianmoe.com writes:
Hi again,
I can quickly think of two advantages of the late lamented (if only by
me) #+BABEL header over using properties.
1. Allowing you to specify multiple buffer-wide options on the same
line (keeping things short), in the same colon
Eric Schulte schulte.e...@gmail.com wrote:
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
On Fri, Oct 21, 2011 at 7:37 PM, Eric Schulte schulte.e...@gmail.comwrote:
Christian Moe m...@christianmoe.com writes:
Hi again,
I can quickly think of two advantages of the late lamented (if only by
me) #+BABEL header over using properties.
1. Allowing you to specify multiple
On Fri, Oct 21, 2011 at 8:35 PM, Rainer M Krug r.m.k...@gmail.com wrote:
On Fri, Oct 21, 2011 at 7:37 PM, Eric Schulte schulte.e...@gmail.comwrote:
Christian Moe m...@christianmoe.com writes:
Hi again,
I can quickly think of two advantages of the late lamented (if only by
me)
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
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
Hi,
I have just pushed up a change to the Org-mode git repository which
removes support for #+BABEL lines. Please use the more general
#+PROPERTIES lines instead.
Best -- Eric
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Eric Schulte schulte.e...@gmail.com wrote:
I have just pushed up a change to the Org-mode git repository which
removes support for #+BABEL lines. Please use the more general
#+PROPERTIES lines instead.
Coming late to the dance - sorry. I think that's very confusing.
Property is an
Nick Dokos nicholas.do...@hp.com writes:
Eric Schulte schulte.e...@gmail.com wrote:
I have just pushed up a change to the Org-mode git repository which
removes support for #+BABEL lines. Please use the more general
#+PROPERTIES lines instead.
Coming late to the dance - sorry. I think
Eric Schulte schulte.e...@gmail.com wrote:
Nick Dokos nicholas.do...@hp.com writes:
Eric Schulte schulte.e...@gmail.com wrote:
I have just pushed up a change to the Org-mode git repository which
removes support for #+BABEL lines. Please use the more general
#+PROPERTIES lines
Hi Nick and Eric,
Nick Dokos wrote:
Eric Schulte schulte.e...@gmail.com wrote:
Nick Dokos nicholas.do...@hp.com writes:
Eric Schulte schulte.e...@gmail.com wrote:
I have just pushed up a change to the Org-mode git repository which
removes support for #+BABEL lines. Please use the more
Whoa -- before this gets more confusing:
Eric, did you push up a (new, or at least so far undocumented in the
manual) syntax involving a #+PROPERTIES line, as Nick and Sebastien
seem to understand you?
Or was #+PROPERTIES just a typo, and you mean using the #+PROPERTY
line or :PROPERTIES:
Christian Moe m...@christianmoe.com wrote:
Whoa -- before this gets more confusing:
Eric, did you push up a (new, or at least so far undocumented in the
manual) syntax involving a #+PROPERTIES line, as Nick and Sebastien
seem to understand you?
Or was #+PROPERTIES just a typo, and you
Nick Dokos nicholas.do...@hp.com writes:
Eric Schulte schulte.e...@gmail.com wrote:
Nick Dokos nicholas.do...@hp.com writes:
Eric Schulte schulte.e...@gmail.com wrote:
I have just pushed up a change to the Org-mode git repository which
removes support for #+BABEL lines. Please use
Hi Eric,
On Thu, Oct 20, 2011 at 11:34 PM, Eric Schulte schulte.e...@gmail.com wrote:
2. The existing #+PROPERTY: line may now be used to specify values for
header arguments, e.g.,
#+PROPERTY: results silent
would silence all results in the current buffer.
Is the 'results' without a
Hi Eric,
Eric Schulte wrote:
Nick Dokos nicholas.do...@hp.com writes:
Eric Schulte schulte.e...@gmail.com wrote:
Nick Dokos nicholas.do...@hp.com writes:
Eric Schulte schulte.e...@gmail.com wrote:
I have just pushed up a change to the Org-mode git repository which
removes support for
Eric Schulte schulte.e...@gmail.com wrote:
... I've just pushed up what I
consider to be a clean implementation. Put briefly the new behavior is
that properties may be used to specify header arguments. More
completely...
1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist.
suvayu ali fatkasuvayu+li...@gmail.com writes:
Hi Eric,
On Thu, Oct 20, 2011 at 11:34 PM, Eric Schulte schulte.e...@gmail.com wrote:
2. The existing #+PROPERTY: line may now be used to specify values for
header arguments, e.g.,
#+PROPERTY: results silent
would silence all results
Sebastien Vauban wxhgmqzgw...@spammotel.com writes:
Hi Eric,
Eric Schulte wrote:
Nick Dokos nicholas.do...@hp.com writes:
Eric Schulte schulte.e...@gmail.com wrote:
Nick Dokos nicholas.do...@hp.com writes:
Eric Schulte schulte.e...@gmail.com wrote:
I have just pushed up a change to
Sebastien Vauban wxhgmqzgw...@spammotel.com wrote:
I just have one question, as I'm puzzled by the lack of `:' in front of the
properties: how do we distinguish the argument value from the argument
name?
For example, how do we translate, in the new syntax,
#+BABEL::results output
Nick Dokos nicholas.do...@hp.com writes:
Eric Schulte schulte.e...@gmail.com wrote:
... I've just pushed up what I
consider to be a clean implementation. Put briefly the new behavior is
that properties may be used to specify header arguments. More
completely...
1. The #+PROPERTIES:
Eric Schulte schulte.e...@gmail.com wrote:
Other than colon confusion (having to specify ``:results silent'' on
the src block header line and ``results silent'' in the #+PROPERTY line
to get the same behavior), this looks better. Not sure what (if
anything) can or should be done about the
Nick Dokos nicholas.do...@hp.com writes:
Eric Schulte schulte.e...@gmail.com wrote:
Other than colon confusion (having to specify ``:results silent'' on
the src block header line and ``results silent'' in the #+PROPERTY line
to get the same behavior), this looks better. Not sure what (if
On Thu, 20 Oct 2011 15:52:42 -0600
Eric Schulte schulte.e...@gmail.com wrote:
suvayu ali fatkasuvayu+li...@gmail.com writes:
Hi Eric,
On Thu, Oct 20, 2011 at 11:34 PM, Eric Schulte
schulte.e...@gmail.com wrote:
2. The existing #+PROPERTY: line may now be used to specify values
for
69 matches
Mail list logo
