Daniel Bausch writes:
> I did some tests with my documents and they look fine. Thanks for your work.
>
Great, good to know.
>
> (A minor remark, offtopic: If the document ends just below a source
> code block, no results are inserted when the block is executed. You
> have to insert an additio
I did some tests with my documents and they look fine. Thanks for your work.
(A minor remark, offtopic: If the document ends just below a source code
block, no results are inserted when the block is executed. You have to insert
an additional blank line, for a result to can appear.)
Daniel
Am
Thomas S. Dye wrote:
> And, revising the files before Worg updates the Org-mode it uses will
> break them, right?
Yup - they got to be done at the same time.
Nick
>
> Tom
>
> Nick Dokos writes:
>
> > I'm trying to add a note to Worg hacks but before I push, I use my local
> > org setup to
And, revising the files before Worg updates the Org-mode it uses will
break them, right?
Tom
Nick Dokos writes:
> I'm trying to add a note to Worg hacks but before I push, I use my local
> org setup to publish Worg locally and take a look at it (not entirely reliable
> since my org version is u
Nick Dokos writes:
> Eric Schulte wrote:
>
>> The attached updated patch fixes a bug in the original.
>>
>
> Minor problem in applying:
>
> ,
> | $ git apply ~/Mail/inbox/724
> | /home/nick/Mail/inbox/724:671: trailing whitespace.
> | #+name:
> | /home/nick/Mail/inbox/724:599: new blank li
Eric Schulte wrote:
> The attached updated patch fixes a bug in the original.
>
Minor problem in applying:
,
| $ git apply ~/Mail/inbox/724
| /home/nick/Mail/inbox/724:671: trailing whitespace.
| #+name:
| /home/nick/Mail/inbox/724:599: new blank line at EOF.
| +
| warning: 2 lines add wh
The attached updated patch fixes a bug in the original.
>From 0e43d59ee8d46a63f86780a502de726271bc39de Mon Sep 17 00:00:00 2001
From: Eric Schulte
Date: Fri, 28 Oct 2011 10:44:21 -0600
Subject: [PATCH] removing code block, results and call-line synonyms -- BREAKING CHANGE
Following a round of on
The attached patch implements these changes, please see the patch
comment as it contains all of the pertinent information.
If any brave volunteers would be willing to test this patch locally
before I apply it to the Org-mode git repository that would be greatly
appreciated.
Thanks to the test sui
> > Daniel (who used Babel to write his thesis in one big file with all data
> > and chart generating code interleaved with the text -- faboulous!)
>
> Indeed - could we hope to get a glimpse at some examples (or even the whole
> thing) at some point?
Unfortunately not at the moment, because we'r
Daniel Bausch wrote:
> Am Mittwoch 26 Oktober 2011, 15:10:03 schrieb Giovanni Ridolfi:
> > Nick Dokos writes:
> > > Eric Schulte wrote:
> > >> Surprisingly (to me) srcname is the winner here, but luckily I haven't
> > >> yet voted, and although I would have though #+source: would have been
> >
Am Mittwoch 26 Oktober 2011, 15:10:03 schrieb Giovanni Ridolfi:
> Nick Dokos writes:
> > Eric Schulte wrote:
> >> Surprisingly (to me) srcname is the winner here, but luckily I haven't
> >> yet voted, and although I would have though #+source: would have been
> >> the winner I like the simplicity
Nick Dokos writes:
> Eric Schulte wrote:
>
>> Surprisingly (to me) srcname is the winner here, but luckily I haven't
>> yet voted, and although I would have though #+source: would have been
>> the winner I like the simplicity of using #+name: for named code blocks
>> as well as named data. So I
Daniel Bausch writes:
>> > However, I'd like to ask, what happens, if one refers to a
>> > name of a source block where data is expected, does it then refer to
>> > the results produced by that source block? How are such situations
>> > handeled at the moment?
>>
>> Try it out, but be ready to
Daniel Bausch writes:
>> > However, I'd like to ask, what happens, if one refers to a
>> > name of a source block where data is expected, does it then refer to
>> > the results produced by that source block? How are such situations
>> > handeled at the moment?
>>
>> Try it out, but be ready to
Am Dienstag 25 Oktober 2011, 19:21:22 schrieb Nick Dokos:
> Eric Schulte wrote:
> > Martyn Jago writes:
> > > Nick Dokos writes:
> > >> Eric Schulte wrote:
> > >>> Surprisingly (to me) srcname is the winner here, but luckily I
> > >>> haven't yet voted, and although I would have though #+source
> > However, I'd like to ask, what happens, if one refers to a
> > name of a source block where data is expected, does it then refer to
> > the results produced by that source block? How are such situations
> > handeled at the moment?
>
> Try it out, but be ready to press C-g, because I would gue
Eric Schulte wrote:
> Martyn Jago writes:
>
> > Nick Dokos writes:
> >
> >> Eric Schulte wrote:
> >>
> >>> Surprisingly (to me) srcname is the winner here, but luckily I haven't
> >>> yet voted, and although I would have though #+source: would have been
> >>> the winner I like the simplicity
Martyn Jago writes:
> Nick Dokos writes:
>
>> Eric Schulte wrote:
>>
>>> Surprisingly (to me) srcname is the winner here, but luckily I haven't
>>> yet voted, and although I would have though #+source: would have been
>>> the winner I like the simplicity of using #+name: for named code blocks
>
Nick Dokos writes:
> Eric Schulte wrote:
>
>> Surprisingly (to me) srcname is the winner here, but luckily I haven't
>> yet voted, and although I would have though #+source: would have been
>> the winner I like the simplicity of using #+name: for named code blocks
>> as well as named data. So I
>
> Then maybe #+results for (anonymous) results only, but #+name for anything
> else from [1] and [3].
This seems like a reasonable approach.
> Wasn't there a concept of linking a results block to its originiating
> source block by some id and we need a place to put the checksum in.
Not that I
Eric Schulte wrote:
> Surprisingly (to me) srcname is the winner here, but luckily I haven't
> yet voted, and although I would have though #+source: would have been
> the winner I like the simplicity of using #+name: for named code blocks
> as well as named data. So I'll vote for #+name: here ma
Surprisingly (to me) srcname is the winner here, but luckily I haven't
yet voted, and although I would have though #+source: would have been
the winner I like the simplicity of using #+name: for named code blocks
as well as named data.
Ditto -- it just wasn't on the table yet when I cast my vo
Alright,
I've tallied up the results and we have the following (with full voting
information below [1]).
Call lines
| call | 13 |
It seems unanimous that remote code block calls should use the #+call:
syntax moving forward.
Data and result names
| (name results) | 3 |
| name | 2 |
Hi Rainer,
Rainer M Krug wrote:
> On Fri, Oct 21, 2011 at 6:24 PM, Eric Schulte wrote:
>>> Just to make it as easy as possible for everyone
>>> Might it be possible to introduce a small flags like "obsolete" and
>>> "stable" (standard)
>>> Old functions, old syntax, etc., might move first to o
Hi Daniel,
Daniel Bausch wrote:
> Am Dienstag 25 Oktober 2011, 03:30:46 schrieb Eric Schulte:
>> "Sebastien Vauban" writes:
>> > Daniel Bausch wrote:
>> >>> named code blocks [1] -- "source" "srcname" "function"
>
> calling external functions [2] -- "call" "lob"
>
>
> #+object_begin var
> x = 1
> y = 2
> #+end
I was thinking on similar lines. This together with Nicolas's suggestion
of "one name" will be wonderful.
I think it is easier to explain what I think by means of an example. In
case of lisp, the SAME variable name could either act as a function or a
Am Dienstag 25 Oktober 2011, 03:30:46 schrieb Eric Schulte:
> "Sebastien Vauban" writes:
> > Hi Daniel,
> >
> > Daniel Bausch wrote:
> >>> named code blocks [1] -- "source" "srcname" "function"
> >>>
> >>> calling external functions [2] -- "call" "lob"
> >>>
> >>> named
On Tue, Oct 25, 2011 at 8:52 AM, Rainer M Krug wrote:
>
>
> On Fri, Oct 21, 2011 at 7:37 PM, Sebastien Vauban <
> wxhgmqzgw...@spammotel.com> wrote:
>
>> Hi Eric,
>>
>> Eric Schulte wrote:
>> >> Now, between "srcname" and "source": I'm used to whatever my Yasnippet
>> is
>> >> entering for me. Th
On Fri, Oct 21, 2011 at 6:24 PM, Eric Schulte wrote:
> > Just to make it as easy as possible for everyone
> > Might it be possible to introduce a small flags like "obsolete" and
> > "stable" (standard)
> > Old functions, old syntax, etc., might move first to obsolete before
> > completely remo
"Sebastien Vauban" writes:
> Hi Daniel,
>
> Daniel Bausch wrote:
>>> named code blocks [1] -- "source" "srcname" "function"
>>> calling external functions [2] -- "call" "lob"
>>> named data [3] -- "tblname" "resname" "results" "data"
>>
>> what about "#+name:" for [1] and
Does org have TAB completion in "call lines" for names of blocks that can
be called? Using "srcname" for blocks of code could make things easier but
if this is not the case then I "name" is just fine.
--
Darlan
At Mon, 24 Oct 2011 08:37:13 +0100,
Eric S Fraga wrote:
>
> Daniel Bausch writes:
Daniel Bausch writes:
> Hi,
>
>> named code blocks [1] -- "source" "srcname" "function"
>> calling external functions [2] -- "call" "lob"
>> named data [3] -- "tblname" "resname" "results" "data"
>
> what about "#+name:" for [1] and [3], and "#+call:" for [2] ?
>
> That a
Hi Daniel,
Daniel Bausch wrote:
>> named code blocks [1] -- "source" "srcname" "function"
>> calling external functions [2] -- "call" "lob"
>> named data [3] -- "tblname" "resname" "results" "data"
>
> what about "#+name:" for [1] and [3], and "#+call:" for [2] ?
>
> That
Am Sonntag 23 Oktober 2011, 18:09:01 schrieben Sie:
> Daniel Bausch writes:
> > Am Freitag, 21. Oktober 2011, 21:10:27 schrieb Thomas S. Dye:
> >> Eric Schulte writes:
> >> >>> I'm confused by [3] so I will say nothing for now, except to ask
> >> >>> some questions: are we talking about what a hu
Hi Eric,
Hi Seb,
Eric Schulte wrote:
We could open an older file and if it isn't working, we could try
#+PROPERTY: babel-function-set obsolete
I think that making use of such a feature is almost as onerous as
changing to the new terms (which is a simple search replace, in fact
once terms ar
Daniel Bausch writes:
> Am Freitag, 21. Oktober 2011, 21:10:27 schrieb Thomas S. Dye:
>> Eric Schulte writes:
>> >>> I'm confused by [3] so I will say nothing for now, except to ask some
>> >>> questions: are we talking about what a human would use to label a piece
>> >>> of data for consumption
Hi,
> named code blocks [1] -- "source" "srcname" "function"
> calling external functions [2] -- "call" "lob"
> named data [3] -- "tblname" "resname" "results" "data"
what about "#+name:" for [1] and [3], and "#+call:" for [2] ?
That a table or list contains data is obvi
Am Freitag, 21. Oktober 2011, 21:10:27 schrieb Thomas S. Dye:
> Eric Schulte writes:
> >>> I'm confused by [3] so I will say nothing for now, except to ask some
> >>> questions: are we talking about what a human would use to label a piece
> >>> of data for consumption by a block (including perhaps
>
> Let me help revise the documentation when the dust settles and the
> syntax changes are in place. As it stands now, #+data: doesn't show up
> in the index to the manual, and the entry for #+tblname: leads only to
> a description of its use in spreadsheets.
>
Thanks Tom, any help with the docu
Hi Eric,
my preferences are:
- source for code blocks. I think srcname looks ugly (although not as
ugly as tblname).
- call
- data and results for, well, data and results. With the same semantics
as Torsten Wagner suggested, i.e. a source block cannot change the
contents of a data block. It
Eric Schulte writes:
>>> I'm confused by [3] so I will say nothing for now, except to ask some
>>> questions: are we talking about what a human would use to label a piece
>>> of data for consumption by a block (including perhaps the future
>>> possibilities of lists and paragraphs that Tom brough
Hi Eric,
Eric Schulte writes:
> named code blocks [1] -- "source" "srcname" "function"
> calling external functions [2] -- "call" "lob"
> named data [3] -- "tblname" "resname" "results" "data"
here my votes:
[1] -- "srcname"
[2] -- "call"
[3] -- ? "
I would choose ei
> Just to make it as easy as possible for everyone
> Might it be possible to introduce a small flags like "obsolete" and
> "stable" (standard)
> Old functions, old syntax, etc., might move first to obsolete before
> completely removed...
> We could open an older file and if it isn't working, we
Eric Schulte writes:
> t...@tsdye.com (Thomas S. Dye) writes:
>
>> Eric Schulte writes:
>>
[1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME,
#+FUNCTION,
#+CALL, #+LOB, and SBE, some of which are interchangeable; some
not. I'd prefer
deprecating an old fo
So far I have the following.
code block names
| source | dye |
| srcname | dokos |
| srcname | moe |
| srcname | vauban |
| srcname | wagner |
| name| goaziou |
call lines
| call | dye |
| call | dokos |
| call | moe |
| call | vauban |
| call | wagner |
| call | goaz
Hi Eric and Torsten,
Eric Schulte wrote:
>> We could open an older file and if it isn't working, we could try
>>
>> #+PROPERTY: babel-function-set obsolete
>
> I think that making use of such a feature is almost as onerous as
> changing to the new terms (which is a simple search replace, in fact
>
"Sebastien Vauban" writes:
> Hi Torsten,
>
> Torsten Wagner wrote:
>> I tend to #+results: because it fits more to the entire babel syntax.
>> However, earlier on the mailing list people were pointing out that one
>> is going to change "results" for a unknown source block (that was the
>> reason
Hi Eric,
Eric Schulte wrote:
>> Now, between "srcname" and "source": I'm used to whatever my Yasnippet is
>> entering for me. That's currently "srcname". I don't have a strong opinion,
>> though, to choose one over the other, except that I like Nick's argument with
>> the table analogy.
>>
>>> I a
>
> Now, between "srcname" and "source": I'm used to whatever my Yasnippet is
> entering for me. That's currently "srcname". I don't have a strong opinion,
> though, to choose one over the other, except that I like Nick's argument with
> the table analogy.
>
>> I agree on [2] "call".
>
> I clearly
Nicolas Goaziou writes:
> Hello,
>
> Eric Schulte writes:
>
>> There are currently a number of instances of synonymous keywords when
>> dealing with code blocks, specifically.
>>
>> named code blocks [1] -- "source" "srcname" "function"
>> calling external functions [2] -- "call" "lob"
>> I'm confused by [3] so I will say nothing for now, except to ask some
>> questions: are we talking about what a human would use to label a piece
>> of data for consumption by a block (including perhaps the future
>> possibilities of lists and paragraphs that Tom brought up)? what babel
>> would
t...@tsdye.com (Thomas S. Dye) writes:
> Eric Schulte writes:
>
>>> [1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME,
>>> #+FUNCTION,
>>> #+CALL, #+LOB, and SBE, some of which are interchangeable; some
>>> not. I'd prefer
>>> deprecating an old form when a better one is found.
>>
>
> I disagree with Tom on [1]: it should clearly be "srcname", in analogy
> to #+tblname - and also so I don't have to change my files :-} (but see
> my question about tblname below).
>
> I agree on [2] "call".
>
noted
>
> I'm confused by [3] so I will say nothing for now, except to ask some
> q
Hello,
Eric Schulte writes:
> There are currently a number of instances of synonymous keywords when
> dealing with code blocks, specifically.
>
> named code blocks [1] -- "source" "srcname" "function"
> calling external functions [2] -- "call" "lob"
> named data [3] -- "
Hi Torsten,
Torsten Wagner wrote:
> I tend to #+results: because it fits more to the entire babel syntax.
> However, earlier on the mailing list people were pointing out that one
> is going to change "results" for a unknown source block (that was the
> reason "data" was introduced) and I thin
Hi Nick, Tom, Eric and all,
Nick Dokos wrote:
> Thomas S. Dye wrote:
>> Eric Schulte writes:
>>
[1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME,
#+FUNCTION,
#+CALL, #+LOB, and SBE, some of which are interchangeable; some
not. I'd prefer deprecating an old f
Hi,
> Ideally if we limit each of the above to only one alternative we could
> simplify the specification of code blocks in Org-mode making them easier
> to learn and use and removing some of the mystery around their syntax.
>
> What does everyone think?
Just to make it as easy as possible for ev
I disagree with Tom on [1]: it should clearly be "srcname", in analogy
to #+tblname - and also so I don't have to change my files :-} (but see
my question about tblname below).
I'll have to change my files, either way. The price one pays for
inconsistency. But as I've recently learned from Ca
Thomas S. Dye wrote:
> Eric Schulte writes:
>
> >> [1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME,
> >> #+FUNCTION,
> >> #+CALL, #+LOB, and SBE, some of which are interchangeable; some
> >> not. I'd prefer
> >> deprecating an old form when a better one is found.
> >
> > This
Eric Schulte writes:
>> [1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME, #+FUNCTION,
>> #+CALL, #+LOB, and SBE, some of which are interchangeable; some
>> not. I'd prefer
>> deprecating an old form when a better one is found.
>
> This point of view has been raised previously both
60 matches
Mail list logo
