Sebastien Vauban
writes:
> Yes, you just show that the documentation is not up-to-date, as that
> functionality *is* implemented for most languages.
This constant is defined in the ob-core.el I have
(colnames . ((nil no yes)))
which seems to indicate that the documentation is up-to-dat
Hi Sebastien,
2015ko urtarrilak 23an, Sebastien Vauban-ek idatzi zuen:
> Yes, you just show that the documentation is not up-to-date, as that
> functionality *is* implemented for most languages.
>
> Doing some bit of archeology, I just found out that:
>
> - Eric wrote a patch to support the abov
Sebastien Vauban
writes:
> Hello Thomas and Rainer,
>
> Rainer M Krug wrote:
>> Sebastien Vauban writes:
>>>
>>> #+begin_src R :rownames yes :colnames '(Lg Nb)
>>> data(iris)
>>> head(table(iris$Petal.Length, iris$Species)[, "setosa"], n=2)
>>> #+end_src
>>>
>>> returns:
>>>
>>> | | x
Hello Thomas and Rainer,
Rainer M Krug wrote:
> Sebastien Vauban writes:
>>
>> #+begin_src R :rownames yes :colnames '(Lg Nb)
>> data(iris)
>> head(table(iris$Petal.Length, iris$Species)[, "setosa"], n=2)
>> #+end_src
>>
>> returns:
>>
>> | | x |
>> |-+|
>> | 1 | 1 |
>>
Sebastien Vauban
writes:
> Hello,
>
> The following ECM shows it all:
>
> #+begin_src R :rownames yes :colnames '(Lg Nb)
> data(iris)
> head(table(iris$Petal.Length, iris$Species)[, "setosa"])
> #+end_src
>
> returns:
>
> | | x |
> |-+|
> | 1 | 1 |
> | 1.1 | 1 |
> |
Aloha Seb,
I don't think babel knows anything about objects created within source
code blocks. I think you'll have to set the column names yourself,
within the R source code block.
All the best,
Tom
Sebastien Vauban
writes:
> Hello,
>
> The following ECM shows it all:
>
> #+begin_src R :r
Hello,
The following ECM shows it all:
#+begin_src R :rownames yes :colnames '(Lg Nb)
data(iris)
head(table(iris$Petal.Length, iris$Species)[, "setosa"])
#+end_src
returns:
| | x |
|-+|
| 1 | 1 |
| 1.1 | 1 |
| 1.2 | 2 |
| 1.3 | 7 |
| 1.4 | 13 |
| 1.5 | 13
to reproduce in maint:
c-c ' on a fairly large shell source block
move point someplace
c-x c-s
sometimes point moves
sometimes the position in the window recenters
it seems quite random
what i expected was no changes of anything
thanks
>
> I applied the patch and it is working.
>
Great, I've just pushed it up.
Best,
--
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D
Eric Schulte writes:
> Rainer M Krug writes:
>
>> Eric Schulte writes:
>>
Apologies - I am still struggling with encryption..
So here is my example:
--8<---cut here---start->8---
#+TITLE: single_to_multi
#+DATE: <20
Rainer M Krug writes:
> Eric Schulte writes:
>
>>>
>>> Apologies - I am still struggling with encryption..
>>>
>>> So here is my example:
>>>
>>> --8<---cut here---start->8---
>>> #+TITLE: single_to_multi
>>> #+DATE: <2013-10-15 Tue>
>>> #+AUTHOR: Rainer M
Eric Schulte writes:
>>
>> Apologies - I am still struggling with encryption..
>>
>> So here is my example:
>>
>> --8<---cut here---start->8---
>> #+TITLE: single_to_multi
>> #+DATE: <2013-10-15 Tue>
>> #+AUTHOR: Rainer M. Krug
>> #+EMAIL: rai...@krugs.de
>
>
> Apologies - I am still struggling with encryption..
>
> So here is my example:
>
> --8<---cut here---start->8---
> #+TITLE: single_to_multi
> #+DATE: <2013-10-15 Tue>
> #+AUTHOR: Rainer M. Krug
> #+EMAIL: rai...@krugs.de
>
> ≈* Load R packages and data
>
Eric Schulte writes:
> Rainer M Krug writes:
>
>> Eric Schulte writes:
>>
>>> Rainer M Krug writes:
>>>
Eric Schulte writes:
> Rainer M Krug writes:
>
>> Eric Schulte writes:
>>
>>> Charles Berry writes:
>>>
John Hendy gmail.com> writes:
bini55Rmu2tZs.bin
Description: application/pgp-encrypted
binZzbsrmcnDw.bin
Description: Binary data
Rainer M Krug writes:
> Eric Schulte writes:
>
>> Rainer M Krug writes:
>>
>>> Eric Schulte writes:
>>>
Rainer M Krug writes:
> Eric Schulte writes:
>
>> Charles Berry writes:
>>
>>> John Hendy gmail.com> writes:
>>>
>>> [deleted]
>
>
Eric Schulte writes:
> Rainer M Krug writes:
>
>> Eric Schulte writes:
>>
>>> Rainer M Krug writes:
>>>
Eric Schulte writes:
> Charles Berry writes:
>
>> John Hendy gmail.com> writes:
>>
>> [deleted]
>>> >
>>> > I think the default behavior should be re
Rainer M Krug writes:
> Eric Schulte writes:
>
>> Rainer M Krug writes:
>>
>>> Eric Schulte writes:
>>>
Charles Berry writes:
> John Hendy gmail.com> writes:
>
> [deleted]
>> >
>> > I think the default behavior should be reverted, as tangling and
>> > export
Eric Schulte writes:
> Rainer M Krug writes:
>
>> Eric Schulte writes:
>>
>>> Charles Berry writes:
>>>
John Hendy gmail.com> writes:
[deleted]
> >
> > I think the default behavior should be reverted, as tangling and
> > exporting are two different things. When I t
Rainer M Krug writes:
> Eric Schulte writes:
>
>> Charles Berry writes:
>>
>>> John Hendy gmail.com> writes:
>>>
>>> [deleted]
>
> I think the default behavior should be reverted, as tangling and
> exporting are two different things. When I tangle, I want to see the
> code
Eric Schulte writes:
> Charles Berry writes:
>
>> John Hendy gmail.com> writes:
>>
>> [deleted]
>>> >
>>> > I think the default behavior should be reverted, as tangling and
>>> > exporting are two different things. When I tangle, I want to see the
>>> > code blocks as they are in the org docume
Charles Berry writes:
> John Hendy gmail.com> writes:
>
> [deleted]
>> >
>> > I think the default behavior should be reverted, as tangling and
>> > exporting are two different things. When I tangle, I want to see the
>> > code blocks as they are in the org document (with possible variables and
>
John Hendy gmail.com> writes:
[deleted]
> >
> > I think the default behavior should be reverted, as tangling and
> > exporting are two different things. When I tangle, I want to see the
> > code blocks as they are in the org document (with possible variables and
> > expansions) but not to create
On Tue, Mar 18, 2014 at 3:44 AM, Rainer M Krug wrote:
> Eric Schulte writes:
>
>> John Hendy writes:
>>
>>> On Mon, Mar 17, 2014 at 10:00 AM, Eric Schulte
>>> wrote:
John Hendy writes:
>>> Out of curiosity, is there a consensus that this is the preferred
>>> behavior for tangling by defa
Eric Schulte writes:
> John Hendy writes:
>
>> On Mon, Mar 17, 2014 at 10:00 AM, Eric Schulte
>> wrote:
>>> John Hendy writes:
>>>
On Fri, Feb 7, 2014 at 1:22 PM, Rainer M Krug wrote:
>
>
>
> On 02/07/14, 17:47 , Eric Schulte wrote:
> > Rainer M Krug writes:
> >
John Hendy writes:
> On Mon, Mar 17, 2014 at 10:00 AM, Eric Schulte wrote:
>> John Hendy writes:
>>
>>> On Fri, Feb 7, 2014 at 1:22 PM, Rainer M Krug wrote:
On 02/07/14, 17:47 , Eric Schulte wrote:
> Rainer M Krug writes:
>
>> On 02/07/14, 07:18 , John Hendy
On Mon, Mar 17, 2014 at 10:00 AM, Eric Schulte wrote:
> John Hendy writes:
>
>> On Fri, Feb 7, 2014 at 1:22 PM, Rainer M Krug wrote:
>>>
>>>
>>>
>>> On 02/07/14, 17:47 , Eric Schulte wrote:
>>> > Rainer M Krug writes:
>>> >
>>> >> On 02/07/14, 07:18 , John Hendy wrote:
>>> >>> Greetings,
>>> >>
John Hendy writes:
> On Fri, Feb 7, 2014 at 1:22 PM, Rainer M Krug wrote:
>>
>>
>>
>> On 02/07/14, 17:47 , Eric Schulte wrote:
>> > Rainer M Krug writes:
>> >
>> >> On 02/07/14, 07:18 , John Hendy wrote:
>> >>> Greetings,
>> >>>
>> >>>
>> >>> I don't usually tangle, but am creating a code file
On Fri, Feb 7, 2014 at 1:22 PM, Rainer M Krug wrote:
>
>
>
> On 02/07/14, 17:47 , Eric Schulte wrote:
> > Rainer M Krug writes:
> >
> >> On 02/07/14, 07:18 , John Hendy wrote:
> >>> Greetings,
> >>>
> >>>
> >>> I don't usually tangle, but am creating a code file to go along with a
> >>> presentat
Hi Thomas,
I guess the fix hasn't made it to maint yet.
#+call: repeated-text(eg=example) :results raw
#+RESULTS:
1. this is the first line
2. this is the second line with %VARIANT% as the value
3. this is the third line
#+name: repeated-text
#+begin_src sh :results verbatim output :var eg=
Hi Samuel,
I think not. I get these results now:
#+call: repeated-text(x="foo",eg=example) :results raw
#+results:
1. this is the first line
2. this is the second line with foo as the value
3. this is the third line
All the best,
Tom
Samuel Wales writes:
> hi thomas,
>
> is this still a bug
hi thomas,
is this still a bug?
samuel
On 11/22/13, Thomas S. Dye wrote:
> Aloha all,
>
> Responding to a query by Gary Oberbrunner, I tried to point out the use
> of example blocks to name arbitrary pieces of text. What I found is that
> the example block isn't passed whole to a babel source
On 02/07/14, 17:47 , Eric Schulte wrote:
> Rainer M Krug writes:
>
>> On 02/07/14, 07:18 , John Hendy wrote:
>>> Greetings,
>>>
>>>
>>> I don't usually tangle, but am creating a code file to go along with a
>>> presentation I'm giving this weekend so that attendees can try things
>>> out afterw
Rainer M Krug writes:
> On 02/07/14, 07:18 , John Hendy wrote:
>> Greetings,
>>
>>
>> I don't usually tangle, but am creating a code file to go along with a
>> presentation I'm giving this weekend so that attendees can try things
>> out afterward by cloning my github repo where all the data and
On 02/07/14, 07:18 , John Hendy wrote:
> Greetings,
>
>
> I don't usually tangle, but am creating a code file to go along with a
> presentation I'm giving this weekend so that attendees can try things
> out afterward by cloning my github repo where all the data and
> necessary files are stored.
Hello Eric,
Eric Schulte wrote:
> "Sebastien Vauban" writes:
>> Eric Schulte wrote:
When results caching is enabled, and when the hash must be updated, the
"meta-lines" in front of the results block are _deleted_.
>>>
>>> You should use a named code block if you want to decorate the res
"Sebastien Vauban" writes:
> Hello Eric,
>
> Eric Schulte wrote:
>>> When results caching is enabled, and when the hash must be updated, the
>>> "meta-lines" in front of the results block are _deleted_.
>>
>> You should use a named code block if you want to decorate the results.
>
> No, as long a
Hello Eric,
Eric Schulte wrote:
>> When results caching is enabled, and when the hash must be updated, the
>> "meta-lines" in front of the results block are _deleted_.
>
> You should use a named code block if you want to decorate the results.
No, as long as the lines which I do insert between the
You should use a named code block if you want to decorate the results.
Best,
"Sebastien Vauban" writes:
> Hello,
>
> When results caching is enabled, and when the hash must be updated, the
> "meta-lines" in front of the results block are _deleted_.
>
> Such meta-lines include:
> - ATTR_LaTeX li
Hello,
When results caching is enabled, and when the hash must be updated, the
"meta-lines" in front of the results block are _deleted_.
Such meta-lines include:
- ATTR_LaTeX lines
- BEGIN/END_CENTER environments
ECM:
--8<---cut here---start->8---
#+PROPERTY:
Achim Gratz writes:
> Eric Schulte writes:
>> In that thread we agreed that the expansion of no-web references
>> *should* be included in code blocks for hashing, but no-one has had the
>> time to implement this.
>
> I think we may have discussed this before, but if you make the hashes
> dependen
Achim Gratz wrote:
> Eric Schulte writes:
>> In that thread we agreed that the expansion of no-web references
>> *should* be included in code blocks for hashing, but no-one has had the
>> time to implement this.
>
> I think we may have discussed this before, but if you make the hashes
> dependent o
Eric Schulte writes:
> In that thread we agreed that the expansion of no-web references
> *should* be included in code blocks for hashing, but no-one has had the
> time to implement this.
I think we may have discussed this before, but if you make the hashes
dependent on the possibly recursive nowe
"Sebastien Vauban" writes:
> Hi Eric,
>
> Eric Schulte wrote:
>> "Sebastien Vauban" writes:
>>>
>>> IIRC, some time ago, a bug involving the computation of the hash (when
>>> option cache is enabled) and NoWeb code blocks. I remember that it had been
>>> fixed.
>>>
>>> However, the following exa
Hi Eric,
Eric Schulte wrote:
> "Sebastien Vauban" writes:
>>
>> IIRC, some time ago, a bug involving the computation of the hash (when
>> option cache is enabled) and NoWeb code blocks. I remember that it had been
>> fixed.
>>
>> However, the following example shows it's not (true anymore):
>>
>>
Aloha all,
Responding to a query by Gary Oberbrunner, I tried to point out the use
of example blocks to name arbitrary pieces of text. What I found is that
the example block isn't passed whole to a babel source block--whitespace
is removed from the first line.
* Whitespace on first line of exampl
Hi Seb,
Could you git bisect this breakage to isolate the offending commit?
Thanks,
"Sebastien Vauban" writes:
> Hello Eric,
>
> IIRC, some time ago, a bug involving the computation of the hash (when option
> cache is enabled) and NoWeb code blocks. I remember that it had been fixed.
>
> Howev
Hello Eric,
IIRC, some time ago, a bug involving the computation of the hash (when option
cache is enabled) and NoWeb code blocks. I remember that it had been fixed.
However, the following example shows it's not (true anymore):
--8<---cut here---start->8---
#+
>>>
>>> The question is now why is this function org-babel-mark-file-as-tangled
>>> receives NULL as a buffer-file-name?
>>
>> I'm not sure, but perhaps you could wrap the body of buffer-file-name in
>> a (when (buffer-file-name) ...) form to protect against null files.
>
> Sounds reasonable and I
Eric Schulte writes:
> Rainer M Krug writes:
>
>> OK - narrowed it down to a post tangle hook which I need for proper
>> debugging of R (jumping to source line in org file and not tangled R file):
>>
>> ,
>> | #+begin_src emacs-lisp
>> | (defvar org-babel-tangled-file nil
>> | "If non-nill
Rainer M Krug writes:
> OK - narrowed it down to a post tangle hook which I need for proper
> debugging of R (jumping to source line in org file and not tangled R file):
>
> ,
> | #+begin_src emacs-lisp
> | (defvar org-babel-tangled-file nil
> | "If non-nill, current file was tangled with o
OK - narrowed it down to a post tangle hook which I need for proper
debugging of R (jumping to source line in org file and not tangled R file):
,
| #+begin_src emacs-lisp
| (defvar org-babel-tangled-file nil
| "If non-nill, current file was tangled with org-babel-tangle")
| (put 'org-babel-t
Forgot: tried with 8.2 stable release and with version from git - both
the same.
Rainer M Krug writes:
> Hi
>
> I have a strange error when tangling.
>
> I have a large org file with several code blocks tangling in about
> 20 R files and one bash file. Usually tangling works perfectly, but
> so
Hi
I have a strange error when tangling.
I have a large org file with several code blocks tangling in about
20 R files and one bash file. Usually tangling works perfectly, but
sometimes one code block does not tangle a code block to a file. These
are different blocks. When I change the name of th
Hello,
Rasmus writes:
> I wanted to combine a table of text and a generated result (in org to
> LaTaX using the new exporter). It would seem src_R snips would be
> perfect for this. However, it does not seem to work. I.e. src_R is
> translated correctly in the text, but not in the table.
Tha
Hi,
I wanted to combine a table of text and a generated result (in org to
LaTaX using the new exporter). It would seem src_R snips would be
perfect for this. However, it does not seem to work. I.e. src_R is
translated correctly in the text, but not in the table.
Is this a feature or a bug?
Bastien writes:
> Hi Chuck,
>
> cbe...@tajo.ucsd.edu writes:
>
>> My apologies if this is already reported (I recall seeing something like
>> this, but cannot find it in the archives).
>>
>> A list element starting with an inline src block is improperly
>> parsed.
>
> I cannot reproduce this wit
Hi Chuck,
cbe...@tajo.ucsd.edu writes:
> My apologies if this is already reported (I recall seeing something like
> this, but cannot find it in the archives).
>
> A list element starting with an inline src block is improperly
> parsed.
I cannot reproduce this with Org 7.9.1.
--
Bastien
My apologies if this is already reported (I recall seeing something like
this, but cannot find it in the archives).
A list element starting with an inline src block is improperly
parsed. for example
- src_emacs-lisp{(org-version)}
is not executed by babel. An ECM:
,
| * virgin version
|
Andreas Leha writes:
> Andreas Leha writes:
>
>> Hi all,
>>
>> I do not know what could be the cause of this, but I can't have a
>> table with header as argument to a source block any more:
>>
>> #+name: table_w_header
>> | one | two |
>> |-+-|
>> | 1 | 3 |
>>
>> #+begin_src R :var t
Andreas Leha writes:
> Hi all,
>
> I do not know what could be the cause of this, but I can't have a
> table with header as argument to a source block any more:
>
> #+name: table_w_header
> | one | two |
> |-+-|
> | 1 | 3 |
>
> #+begin_src R :var tbl=table_w_header
>
> #+end_src
>
> I
Hi all,
I do not know what could be the cause of this, but I can't have a
table with header as argument to a source block any more:
#+name: table_w_header
| one | two |
|-+-|
| 1 | 3 |
#+begin_src R :var tbl=table_w_header
#+end_src
If I do C-c C-v v on the above source block, I ge
On Tuesday, April 17, 2012 at 7:46 AM Sebastien Vauban wrote:
>Hi Rainer,
>
>Rainer M Krug wrote:
>> I am irritated - shouldn't the following create a pdf?
>>
>> #+begin_src R :results file :file sustEconOnlyNonRec.pdf :session R
>> plot(runif(100))
>> #+end_src
>>
>> I am getting no error messa
Nick Dokos wrote:
> Sebastien Vauban wrote:
>
> > Hi Rainer,
> >
> > Rainer M Krug wrote:
> > > I am irritated - shouldn't the following create a pdf?
> > >
> > > #+begin_src R :results file :file sustEconOnlyNonRec.pdf :session R
> > > plot(runif(100))
> > > #+end_src
> > >
> > > I am getti
Sebastien Vauban wrote:
> Hi Rainer,
>
> Rainer M Krug wrote:
> > I am irritated - shouldn't the following create a pdf?
> >
> > #+begin_src R :results file :file sustEconOnlyNonRec.pdf :session R
> > plot(runif(100))
> > #+end_src
> >
> > I am getting no error messages in the R console, nothi
Hi Rainer,
Rainer M Krug wrote:
> I am irritated - shouldn't the following create a pdf?
>
> #+begin_src R :results file :file sustEconOnlyNonRec.pdf :session R
> plot(runif(100))
> #+end_src
>
> I am getting no error messages in the R console, nothing in the messages?
I'm not using R -- yet! -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi
I am irritated - shouldn't the following create a pdf?
#+begin_src R :results file :file sustEconOnlyNonRec.pdf :session R
plot(runif(100))
#+end_src
I am getting no error messages in the R console, nothing in the messages?
Org-mode version 7.
Eric Schulte writes:
> Andreas Leha writes:
>
>> Hi all,
>>
>> I think there is a bug in babel concerning inline source block calls.
>>
>> Suppose, I have a source block that generates a file:
>> #+name: someplot
>> #+begin_src R :results graphics :file someplot.pdf :var somemax=10
>> plot(1:s
Andreas Leha writes:
> Hi all,
>
> I think there is a bug in babel concerning inline source block calls.
>
> Suppose, I have a source block that generates a file:
> #+name: someplot
> #+begin_src R :results graphics :file someplot.pdf :var somemax=10
> plot(1:somemax)
> #+end_src
>
> #+results:
Hi all,
I think there is a bug in babel concerning inline source block calls.
Suppose, I have a source block that generates a file:
#+name: someplot
#+begin_src R :results graphics :file someplot.pdf :var somemax=10
plot(1:somemax)
#+end_src
#+results: someplot
[[file:someplot.pdf]]
I am tryi
Hi,
Thanks for reporting this bug. I've just pushed up a patch.
Cheers,
Andreas Leha writes:
> Hi all,
>
> there seems to be a bug in call lines:
>
> Suppose, I have a src block with two parameters:
>
> #+name: insert_hline
> #+header: :var fulltable=mytable() :var after_row=1
> #+begin_src e
Hi Andreas,
I think the behaviour you have discovered is governed by the constant
org-babel-block-lob-one-liner-regexp;
However, tweaking this regular expression the right way seems to be really hard
(impossible):
http://stackoverflow.com/questions/546433/regular-expression-to-match-outer-br
Hi all,
there seems to be a bug in call lines:
Suppose, I have a src block with two parameters:
#+name: insert_hline
#+header: :var fulltable=mytable() :var after_row=1
#+begin_src emacs-lisp
(let ((rrr (cons (quote hline) fulltable))
(bottomrows (nthcdr after_row fulltable))
(
Hi Eric,
Eric Schulte writes:
> Thanks for bringing up this bug. I'm attaching a patch to this email,
> once the current repositories issues are resolved I'll apply this patch
> to the repository. In the interim, you can apply this patch to your
> local copy of the git repository with.
Applie
Nicolas Girard writes:
> 2012/3/19 Eric Schulte
>>
>> Thanks for bringing up this bug. I'm attaching a patch to this email,
>> once the current repositories issues are resolved I'll apply this patch
>> to the repository. In the interim, you can apply this patch to your
>> local copy of the git
2012/3/19 Eric Schulte
>
> Thanks for bringing up this bug. I'm attaching a patch to this email,
> once the current repositories issues are resolved I'll apply this patch
> to the repository. In the interim, you can apply this patch to your
> local copy of the git repository with.
>
Great ! It'
Rainer M Krug writes:
> On 19/03/12 15:17, Eric Schulte wrote:
>> Hi Rainer,
>>
>> I see you CC'd me on this email. I personally do not know anything about
>> how the graphics
>> header argument to R code blocks works.
>
> Sorry - I thought it was part of babel, and when I hear "babel", I thin
Hi Nicolas,
Thanks for bringing up this bug. I'm attaching a patch to this email,
once the current repositories issues are resolved I'll apply this patch
to the repository. In the interim, you can apply this patch to your
local copy of the git repository with.
$ cd your/path/to/org
$ git am
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19/03/12 15:17, Eric Schulte wrote:
> Hi Rainer,
>
> I see you CC'd me on this email. I personally do not know anything about how
> the graphics
> header argument to R code blocks works.
Sorry - I thought it was part of babel, and when I hear "b
Hi Rainer,
I see you CC'd me on this email. I personally do not know anything
about how the graphics header argument to R code blocks works. I would
recommend looking deeper into the behavior using the following tools
- Look at the expanded code block body using org-babel-expand-src-block
- Run
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I did not get any response so far, so I hope that the email did not went out...
Rainer
- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When giving the header argument :title: the graph is not produced in a file:
* This works
Display boxplot of s
Hi all,
I've been succesfully using babel to make various literate programming work.
Unfortunately, tangling performance has dramatically decreased, to the
point of being barely usable.
I wish I could get advantage of the "quick & dirty noweb expansion" Eric
introduced in january, but it has an und
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When giving the header argument :title: the graph is not produced in a file:
* This works
Display boxplot of spread of Mff over time for each release strategy
:PROPERTIES:
:results: graphics
:file: SpreadOverTime.pdf
:width: 4
:height: 8
Works here. Thanks.
Tom
Eric Schulte writes:
> Fixed, Thanks for the report.
>
> t...@tsdye.com (Thomas S. Dye) writes:
>
>> Aloha all,
>>
>> BEGIN and END are transposed with empty results, as shown in the example
>> below. The results shown are from two evaluations of the source code
>> blo
Fixed, Thanks for the report.
t...@tsdye.com (Thomas S. Dye) writes:
> Aloha all,
>
> BEGIN and END are transposed with empty results, as shown in the example
> below. The results shown are from two evaluations of the source code
> block.
>
> I'm using Org-mode version 7.8.03 (release_7.8.03.575
Aloha all,
BEGIN and END are transposed with empty results, as shown in the example
below. The results shown are from two evaluations of the source code
block.
I'm using Org-mode version 7.8.03 (release_7.8.03.575.g06a1b)
All the best,
Tom
* Empty results
#+begin_src emacs-lisp :results silent
Applied. Thanks,
aditya siram writes:
> Hi all,
> When I tangle a source block with ":comments yes" any spaces in the
> sub-heading in which the block is found are replaced with "%2520"
> instead of "%20". As a consequence when I "org-babel-detangle" the
> correct heading is not found.
>
> As an
Hi all,
When I tangle a source block with ":comments yes" any spaces in the
sub-heading in which the block is found are replaced with "%2520"
instead of "%20". As a consequence when I "org-babel-detangle" the
correct heading is not found.
As an example given the following org file:
* Babel Tanglin
Hi all,
I experience unexpected behaviour when an inline source block is not
preceded by whitespace.
Example:
===
* Test inline
This is a functional inline src_R{print("source block")}.
This (src_R{print("here")}) is not.
===
Regards,
Andreas
Achim Gratz writes:
> Eric Schulte writes:
>> Yes, I'm now pushing bug-fix commits to maint as well as master.
>
> That way you duplicate the commit (the same change now has two ID).
> I think it would be preferrable to push bugfixes to maint and then merge
> maint back into master.
>
Alright,
Eric Schulte writes:
> Yes, I'm now pushing bug-fix commits to maint as well as master.
That way you duplicate the commit (the same change now has two ID).
I think it would be preferrable to push bugfixes to maint and then merge
maint back into master.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#4
Achim Gratz writes:
> Eric Schulte writes:
>> Great, both the test case and a fixed version of this function are now
>> applied to the git repository.
>
> You've pushed it to both maint and master?
>
Yes, I'm now pushing bug-fix commits to maint as well as master.
>
>
> Achim.
--
Eric Schult
Eric Schulte writes:
> Great, both the test case and a fixed version of this function are now
> applied to the git repository.
You've pushed it to both maint and master?
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Waldorf Blofeld:
http://S
Martyn Jago writes:
> Eric Schulte writes:
>
>> Martyn Jago writes:
>>
>>> Martyn Jago writes:
>>>
>>> [...]
>>>
>>> The problem appears to be associated with the way `member' works:
>>>
>>> - on Emacs 23+ the following doesn't generate an error
>>> - on Emacs 22 it generates "Wrong type ar
Eric Schulte writes:
> Martyn Jago writes:
>
>> Martyn Jago writes:
>>
>> [...]
>>
>> The problem appears to be associated with the way `member' works:
>>
>> - on Emacs 23+ the following doesn't generate an error
>> - on Emacs 22 it generates "Wrong type argument: listp, 58"
>>
>> #+begin_sr
Martyn Jago writes:
> Martyn Jago writes:
>
>> There is a bug running babel on Emacs 22.1.1 with a minimal init file.
>>
>
> [...]
>
>>
>> The following fails:
>>
>> * Test fails
>>
>> #+begin_src emacs-lisp :results silent
>>
>> "hello there"
>>
>> #+end_src
>>
>
> [...]
>
> The problem appears
Martyn Jago writes:
> There is a bug running babel on Emacs 22.1.1 with a minimal init file.
>
[...]
>
> The following fails:
>
> * Test fails
>
> #+begin_src emacs-lisp :results silent
>
> "hello there"
>
> #+end_src
>
[...]
The problem appears to be associated with the way `member' works:
There is a bug running babel on Emacs 22.1.1 with a minimal init file.
The following code works:
--8<---cut here---start->8---
* Test passes
#+begin_src emacs-lisp
"hello there"
#+end_src
#+results:
: hello there
--8<---cut here---
Štěpán Němec writes:
> `org-babel-insert-result' unconditionally strips any text properties
> from the evaluation result.
>
> One problem is that this isn't documented. Another problem is that this
> behaviour might not be desirable (I can't imagine why one _would_ want
> to have the properties s
`org-babel-insert-result' unconditionally strips any text properties
from the evaluation result.
One problem is that this isn't documented. Another problem is that this
behaviour might not be desirable (I can't imagine why one _would_ want
to have the properties stripped, on the contrary -- I need
1 - 100 of 167 matches
Mail list logo
