* I'm tripping over #+BABEL: vs. #+PROPERTY:
@ 2012-03-14 18:23 Ken Williams
2012-03-14 18:28 ` Eric Schulte
0 siblings, 1 reply; 11+ messages in thread
From: Ken Williams @ 2012-03-14 18:23 UTC (permalink / raw)
To: emacs-orgmode@gnu.org
1) I see from http://orgmode.org/Changes.html, section "Incompatible changes", that I have to change my #+BABEL: lines to something else, in order to upgrade from 7.7 to 7.8.03. But I can't figure out to what.
I previously had:
#+BABEL: :session *R* :results output :exports both
#+begin_src R :exports none :results silent
setwd('c:/Users/ken/wdir')
source("src/main/R/mylib.R")
#+end_src
What does that translate to, using #+PROPERTY: syntax? I tried the following, but then when I execute a "#+begin_src R" block, it doesn't evaluate in a session called *R*, it just evaluates in-process. No *R* buffer is created.
#+PROPERTY: session *R*
#+PROPERTY: results output
#+PROPERTY: exports both
A pointer to some transition doc would also be great, if such a thing exists.
2) In the same list of "Incompatible changes", it says "code blocks are named with - results are named with code block may still be labeled with named with #+tblname: will be considered to be named results". What on earth does that mean?? I would offer a doc patch but I can't figure it out. =)
--
Ken Williams, Senior Research Scientist
WindLogics
http://windlogics.com
CONFIDENTIALITY NOTICE: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of any kind is strictly prohibited. If you are not the intended recipient, please contact the sender via reply e-mail and destroy all copies of the original message. Thank you.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: I'm tripping over #+BABEL: vs. #+PROPERTY:
2012-03-14 18:23 I'm tripping over #+BABEL: vs. #+PROPERTY: Ken Williams
@ 2012-03-14 18:28 ` Eric Schulte
2012-03-14 18:32 ` Ken Williams
2012-03-14 21:21 ` Nick Dokos
0 siblings, 2 replies; 11+ messages in thread
From: Eric Schulte @ 2012-03-14 18:28 UTC (permalink / raw)
To: Ken Williams; +Cc: emacs-orgmode@gnu.org
Hi Ken,
Did you press C-c C-c on each property line after it was written?
Property lines only take effect either with C-c C-c, or when the file is
first opened.
Best,
Ken Williams <Ken.Williams@windlogics.com> writes:
> 1) I see from http://orgmode.org/Changes.html, section "Incompatible
> changes", that I have to change my #+BABEL: lines to something else,
> in order to upgrade from 7.7 to 7.8.03. But I can't figure out to
> what.
>
> I previously had:
>
> #+BABEL: :session *R* :results output :exports both
>
> #+begin_src R :exports none :results silent
> setwd('c:/Users/ken/wdir')
> source("src/main/R/mylib.R")
> #+end_src
>
> What does that translate to, using #+PROPERTY: syntax? I tried the
> following, but then when I execute a "#+begin_src R" block, it doesn't
> evaluate in a session called *R*, it just evaluates in-process. No
> *R* buffer is created.
>
> #+PROPERTY: session *R*
> #+PROPERTY: results output
> #+PROPERTY: exports both
>
> A pointer to some transition doc would also be great, if such a thing exists.
>
> 2) In the same list of "Incompatible changes", it says "code blocks
> are named with - results are named with code block may still be
> labeled with named with #+tblname: will be considered to be named
> results". What on earth does that mean?? I would offer a doc patch
> but I can't figure it out. =)
>
>
> --
> Ken Williams, Senior Research Scientist
> WindLogics
> http://windlogics.com
>
>
> CONFIDENTIALITY NOTICE: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of any kind is strictly prohibited. If you are not the intended recipient, please contact the sender via reply e-mail and destroy all copies of the original message. Thank you.
>
--
Eric Schulte
http://cs.unm.edu/~eschulte/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: I'm tripping over #+BABEL: vs. #+PROPERTY:
2012-03-14 18:28 ` Eric Schulte
@ 2012-03-14 18:32 ` Ken Williams
2012-03-14 18:39 ` Eric Schulte
2012-03-14 21:21 ` Nick Dokos
1 sibling, 1 reply; 11+ messages in thread
From: Ken Williams @ 2012-03-14 18:32 UTC (permalink / raw)
To: Eric Schulte; +Cc: emacs-orgmode@gnu.org
Aha! That was the trick, thanks.
How about a translation of the text for question 2)?
-Ken
> -----Original Message-----
> From: Eric Schulte [mailto:eric.schulte@gmx.com]
> Sent: Wednesday, March 14, 2012 1:29 PM
> To: Ken Williams
> Cc: emacs-orgmode@gnu.org
> Subject: Re: [O] I'm tripping over #+BABEL: vs. #+PROPERTY:
>
> Hi Ken,
>
> Did you press C-c C-c on each property line after it was written?
> Property lines only take effect either with C-c C-c, or when the file is first
> opened.
> [...]
>
> > 2) In the same list of "Incompatible changes", it says "code blocks
> > are named with - results are named with code block may still be
> > labeled with named with #+tblname: will be considered to be named
> > results". What on earth does that mean?? I would offer a doc patch
> > but I can't figure it out. =)
CONFIDENTIALITY NOTICE: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of any kind is strictly prohibited. If you are not the intended recipient, please contact the sender via reply e-mail and destroy all copies of the original message. Thank you.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: I'm tripping over #+BABEL: vs. #+PROPERTY:
2012-03-14 18:32 ` Ken Williams
@ 2012-03-14 18:39 ` Eric Schulte
2012-03-14 18:49 ` Ken Williams
0 siblings, 1 reply; 11+ messages in thread
From: Eric Schulte @ 2012-03-14 18:39 UTC (permalink / raw)
To: Ken Williams; +Cc: emacs-orgmode@gnu.org
> How about a translation of the text for question 2)?
[...]
>> > 2) In the same list of "Incompatible changes", it says "code blocks
>> > are named with - results are named with code block may still be
>> > labeled with named with #+tblname: will be considered to be named
>> > results". What on earth does that mean?? I would offer a doc patch
>> > but I can't figure it out. =)
Name code blocks with "#+name:" and their results will be named with
"#+results:", e.g.,
#+name: foo
#+begin_src emacs-lisp
:foo
#+end_src
#+RESULTS: foo
: :foo
If you want to include literal data you should also use "#+name:" to
name the data, e.g.,
#+name: bar
: bar
For backwards compatibility and inter-operation with existing table
functionality, you can use "#+tblname:" instead of "#+name:" when naming
a table.
#+tblname: baz
| foo | bar |
| baz | quz |
Hope that clarifies. Cheers,
--
Eric Schulte
http://cs.unm.edu/~eschulte/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: I'm tripping over #+BABEL: vs. #+PROPERTY:
2012-03-14 18:39 ` Eric Schulte
@ 2012-03-14 18:49 ` Ken Williams
0 siblings, 0 replies; 11+ messages in thread
From: Ken Williams @ 2012-03-14 18:49 UTC (permalink / raw)
To: Eric Schulte; +Cc: emacs-orgmode@gnu.org
> -----Original Message-----
> From: Eric Schulte [mailto:eric.schulte@gmx.com]
> Sent: Wednesday, March 14, 2012 1:40 PM
> To: Ken Williams
> Cc: emacs-orgmode@gnu.org
> Subject: Re: [O] I'm tripping over #+BABEL: vs. #+PROPERTY:
>
> > How about a translation of the text for question 2)?
> [...]
>
> Hope that clarifies. Cheers,
Thanks. I think I see what happened - the following text (in the commit message for 7e93b90f8816346a16ad49cee22870b17c05b211) :
- call lines are specified with #+call:
- code blocks are named with #+name:
- results are named with #+name:, however results generated by a code
block may still be labeled with #+results:, and tables named with
#+tblname: will be considered to be named results
got mangled by the HTML builder into this:
call lines are specified with #+call:
code blocks are named with - results are named with code block may still be labeled with named with #+tblname: will be considered to be named results
So some '#' characters probably need to be escaped.
-Ken
CONFIDENTIALITY NOTICE: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of any kind is strictly prohibited. If you are not the intended recipient, please contact the sender via reply e-mail and destroy all copies of the original message. Thank you.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: I'm tripping over #+BABEL: vs. #+PROPERTY:
2012-03-14 18:28 ` Eric Schulte
2012-03-14 18:32 ` Ken Williams
@ 2012-03-14 21:21 ` Nick Dokos
2012-03-15 15:15 ` Sebastien Vauban
1 sibling, 1 reply; 11+ messages in thread
From: Nick Dokos @ 2012-03-14 21:21 UTC (permalink / raw)
To: Eric Schulte; +Cc: nicholas.dokos, emacs-orgmode@gnu.org, Ken Williams
Eric Schulte <eric.schulte@gmx.com> wrote:
>
> Did you press C-c C-c on each property line after it was written?
Just to clarify: do I really have to C-c C-c on each line? If I add a
bunch of them and then do C-c C-c on one of them, shouldn't that be
enough to refresh the setup?
Thanks,
Nick
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: I'm tripping over #+BABEL: vs. #+PROPERTY:
2012-03-14 21:21 ` Nick Dokos
@ 2012-03-15 15:15 ` Sebastien Vauban
2012-03-15 16:14 ` Nick Dokos
0 siblings, 1 reply; 11+ messages in thread
From: Sebastien Vauban @ 2012-03-15 15:15 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Nick and Eric,
Nick Dokos wrote:
> Eric Schulte <eric.schulte-KK0ffGbhmjU@public.gmane.org> wrote:
>>
>> Did you press C-c C-c on each property line after it was written?
>
> Just to clarify: do I really have to C-c C-c on each line? If I add a
> bunch of them and then do C-c C-c on one of them, shouldn't that be
> enough to refresh the setup?
I got no reaction on my idea of "automagic C-c C-c" (on 2012-03-04 Sun, see
http://www.mail-archive.com/emacs-orgmode-mXXj517/zsQ@public.gmane.org/msg52739.html):
The "automagic C-c C-c" should be NOT[1] done after each key press or some
such. That certainly would be a killer feature, in its real acception:
performance would be unbearable.
In my mind, automatically (re-)parsing the meta options should be each time
the user presses `C-c C-v C-e' (eval code blocks); that is, when the user
expects his options to be taken into account.
Does it make sense?
Best regards,
Seb
Footnotes:
[1] This word was missing (in the original post)!
--
Sebastien Vauban
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: I'm tripping over #+BABEL: vs. #+PROPERTY:
2012-03-15 15:15 ` Sebastien Vauban
@ 2012-03-15 16:14 ` Nick Dokos
2012-03-15 16:39 ` Thomas S. Dye
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Nick Dokos @ 2012-03-15 16:14 UTC (permalink / raw)
To: Sebastien Vauban; +Cc: nicholas.dokos, emacs-orgmode
Sebastien Vauban <wxhgmqzgwmuf@spammotel.com> wrote:
> Hi Nick and Eric,
>
> Nick Dokos wrote:
> > Eric Schulte <eric.schulte@gmx.com> wrote:
> >>
> >> Did you press C-c C-c on each property line after it was written?
> >
> > Just to clarify: do I really have to C-c C-c on each line? If I add a
> > bunch of them and then do C-c C-c on one of them, shouldn't that be
> > enough to refresh the setup?
>
> I got no reaction on my idea of "automagic C-c C-c" (on 2012-03-04 Sun, see
> http://www.mail-archive.com/emacs-orgmode@gnu.org/msg52739.html):
>
> The "automagic C-c C-c" should be NOT[1] done after each key press or some
> such. That certainly would be a killer feature, in its real acception:
> performance would be unbearable.
>
> In my mind, automatically (re-)parsing the meta options should be each time
> the user presses `C-c C-v C-e' (eval code blocks); that is, when the user
> expects his options to be taken into account.
>
> Does it make sense?
>
> Best regards,
> Seb
>
> Footnotes:
>
> [1] This word was missing (in the original post)!
>
Well, it might make sense but you can try it out and let us know:
- make files with 10, 100, 1000 trivial (or even empty) code blocks,
just enough to make sure that org-babel-execute-maybe is really called
on them: I think that it will be called even on empty code blocks, but
I'm not sure if there is some optimization in there.
- measure the time it takes to export each one to html (say).
- add a call to org-mode-restart into org-babel-execute-maybe, and time
the same operation again: how significant is the slowdown?
If the slowdown is bearable in these cases, then it will be bearable in
realistic situations, where block execution is going to be a much more
significant fraction of the total.
BTW, what's the biggest file you (all, not just Seb) have in terms of the
number of code blocks it contains? In my case, the largest one had about
two dozen code blocks, so the 100 case would easily cover me, but I suspect
there are much bigger ones out there.
Nick
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: I'm tripping over #+BABEL: vs. #+PROPERTY:
2012-03-15 16:14 ` Nick Dokos
@ 2012-03-15 16:39 ` Thomas S. Dye
2012-03-18 21:37 ` Sebastien Vauban
2012-03-19 8:21 ` Rainer M Krug
2 siblings, 0 replies; 11+ messages in thread
From: Thomas S. Dye @ 2012-03-15 16:39 UTC (permalink / raw)
To: nicholas.dokos; +Cc: Sebastien Vauban, emacs-orgmode
Nick Dokos <nicholas.dokos@hp.com> writes:
> Sebastien Vauban <wxhgmqzgwmuf@spammotel.com> wrote:
>
>> Hi Nick and Eric,
>>
>> Nick Dokos wrote:
>> > Eric Schulte <eric.schulte@gmx.com> wrote:
>> >>
>> >> Did you press C-c C-c on each property line after it was written?
>> >
>> > Just to clarify: do I really have to C-c C-c on each line? If I add a
>> > bunch of them and then do C-c C-c on one of them, shouldn't that be
>> > enough to refresh the setup?
>>
>> I got no reaction on my idea of "automagic C-c C-c" (on 2012-03-04 Sun, see
>> http://www.mail-archive.com/emacs-orgmode@gnu.org/msg52739.html):
>>
>> The "automagic C-c C-c" should be NOT[1] done after each key press or some
>> such. That certainly would be a killer feature, in its real acception:
>> performance would be unbearable.
>>
>> In my mind, automatically (re-)parsing the meta options should be each time
>> the user presses `C-c C-v C-e' (eval code blocks); that is, when the user
>> expects his options to be taken into account.
>>
>> Does it make sense?
>>
>> Best regards,
>> Seb
>>
>> Footnotes:
>>
>> [1] This word was missing (in the original post)!
>>
>
> Well, it might make sense but you can try it out and let us know:
>
> - make files with 10, 100, 1000 trivial (or even empty) code blocks,
> just enough to make sure that org-babel-execute-maybe is really called
> on them: I think that it will be called even on empty code blocks, but
> I'm not sure if there is some optimization in there.
>
> - measure the time it takes to export each one to html (say).
>
> - add a call to org-mode-restart into org-babel-execute-maybe, and time
> the same operation again: how significant is the slowdown?
>
> If the slowdown is bearable in these cases, then it will be bearable in
> realistic situations, where block execution is going to be a much more
> significant fraction of the total.
>
> BTW, what's the biggest file you (all, not just Seb) have in terms of the
> number of code blocks it contains? In my case, the largest one had about
> two dozen code blocks, so the 100 case would easily cover me, but I suspect
> there are much bigger ones out there.
Hi Nick,
118 source code blocks and growing.
Tom
>
> Nick
>
>
--
Thomas S. Dye
http://www.tsdye.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: I'm tripping over #+BABEL: vs. #+PROPERTY:
2012-03-15 16:14 ` Nick Dokos
2012-03-15 16:39 ` Thomas S. Dye
@ 2012-03-18 21:37 ` Sebastien Vauban
2012-03-19 8:21 ` Rainer M Krug
2 siblings, 0 replies; 11+ messages in thread
From: Sebastien Vauban @ 2012-03-18 21:37 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Nick,
Nick Dokos wrote:
>> The "automagic C-c C-c" should be NOT[1] done after each key press or
>> some such. That certainly would be a killer feature, in its real
>> acception: performance would be unbearable.
>>
>> In my mind, automatically (re-)parsing the meta options should be each
>> time the user presses `C-c C-v C-e' (eval code blocks); that is, when
>> the user expects his options to be taken into account.
>>
>> Does it make sense?
>>
>> Best regards,
>> Seb
>>
>> Footnotes:
>>
>> [1] This word was missing (in the original post)!
>>
>
> Well, it might make sense but you can try it out and let us know:
>
> - make files with 10, 100, 1000 trivial (or even empty) code blocks, just
> enough to make sure that org-babel-execute-maybe is really called on them:
> I think that it will be called even on empty code blocks, but I'm not sure
> if there is some optimization in there.
>
> - measure the time it takes to export each one to html (say).
>
> - add a call to org-mode-restart into org-babel-execute-maybe, and time the
> same operation again: how significant is the slowdown?
>
> If the slowdown is bearable in these cases, then it will be bearable in
> realistic situations, where block execution is going to be a much more
> significant fraction of the total.
I'll give it a shot, and report the pre/post results "à la Weight Watchers".
Thanks for pointing out some detailed calls I have to make for testing that
idea!
> BTW, what's the biggest file you (all, not just Seb) have in terms of the
> number of code blocks it contains? In my case, the largest one had about two
> dozen code blocks, so the 100 case would easily cover me, but I suspect
> there are much bigger ones out there.
The biggest number of code blocks in any document I have is around 20.
Best regards,
Seb
--
Sebastien Vauban
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: I'm tripping over #+BABEL: vs. #+PROPERTY:
2012-03-15 16:14 ` Nick Dokos
2012-03-15 16:39 ` Thomas S. Dye
2012-03-18 21:37 ` Sebastien Vauban
@ 2012-03-19 8:21 ` Rainer M Krug
2 siblings, 0 replies; 11+ messages in thread
From: Rainer M Krug @ 2012-03-19 8:21 UTC (permalink / raw)
To: nicholas.dokos; +Cc: Sebastien Vauban, emacs-orgmode
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 15/03/12 17:14, Nick Dokos wrote:
> Sebastien Vauban <wxhgmqzgwmuf@spammotel.com> wrote:
>
>> Hi Nick and Eric,
>>
>> Nick Dokos wrote:
>>> Eric Schulte <eric.schulte@gmx.com> wrote:
>>>>
>>>> Did you press C-c C-c on each property line after it was written?
>>>
>>> Just to clarify: do I really have to C-c C-c on each line? If I add a bunch of them and
>>> then do C-c C-c on one of them, shouldn't that be enough to refresh the setup?
>>
>> I got no reaction on my idea of "automagic C-c C-c" (on 2012-03-04 Sun, see
>> http://www.mail-archive.com/emacs-orgmode@gnu.org/msg52739.html):
>>
>> The "automagic C-c C-c" should be NOT[1] done after each key press or some such. That
>> certainly would be a killer feature, in its real acception: performance would be unbearable.
>>
>> In my mind, automatically (re-)parsing the meta options should be each time the user presses
>> `C-c C-v C-e' (eval code blocks); that is, when the user expects his options to be taken into
>> account.
>>
>> Does it make sense?
>>
>> Best regards, Seb
>>
>> Footnotes:
>>
>> [1] This word was missing (in the original post)!
>>
>
> Well, it might make sense but you can try it out and let us know:
>
> - make files with 10, 100, 1000 trivial (or even empty) code blocks, just enough to make sure
> that org-babel-execute-maybe is really called on them: I think that it will be called even on
> empty code blocks, but I'm not sure if there is some optimization in there.
>
> - measure the time it takes to export each one to html (say).
>
> - add a call to org-mode-restart into org-babel-execute-maybe, and time the same operation
> again: how significant is the slowdown?
>
> If the slowdown is bearable in these cases, then it will be bearable in realistic situations,
> where block execution is going to be a much more significant fraction of the total.
>
> BTW, what's the biggest file you (all, not just Seb) have in terms of the number of code blocks
> it contains? In my case, the largest one had about two dozen code blocks, so the 100 case would
> easily cover me, but I suspect there are much bigger ones out there.
142 - used in literal programming.
Rainer
>
> Nick
>
- --
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys.
(Germany)
Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa
Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44
Fax (D): +49 - (0)3 21 21 25 22 44
email: Rainer@krugs.de
Skype: RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9m7JsACgkQoYgNqgF2egoV4ACeISeB8GZWSCDSkIPgqIHViqeh
fokAn3cgygfMKr2VInkLkHHX3gIPe58G
=S2uU
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-03-19 8:22 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-14 18:23 I'm tripping over #+BABEL: vs. #+PROPERTY: Ken Williams
2012-03-14 18:28 ` Eric Schulte
2012-03-14 18:32 ` Ken Williams
2012-03-14 18:39 ` Eric Schulte
2012-03-14 18:49 ` Ken Williams
2012-03-14 21:21 ` Nick Dokos
2012-03-15 15:15 ` Sebastien Vauban
2012-03-15 16:14 ` Nick Dokos
2012-03-15 16:39 ` Thomas S. Dye
2012-03-18 21:37 ` Sebastien Vauban
2012-03-19 8:21 ` Rainer M Krug
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).