At Sun, 19 Jun 2011 11:43:49 -0500,
Bill Jacobson wrote:
>
> For some months now, I've been successfully capturing Firefox data as
> explained here: http://orgmode.org/worg/org-contrib/org-protocol.html
> But the results below demonstrate a problem. The 2nd and 3rd represent
> what was captured
Nick Dokos hp.com> writes:
> Having said that, however, I think there *is* a problem:
>
> If you just start the python interpreter and start typing into it:
>
> --8<---cut here---start->8---
> x = 1
> for i in range(1,5):
> x = x + i
> print x
> print "Did
Herbert Sitz wrote:
> Eric Schulte gmail.com> writes:
> > I can confirm that I see the same behavior. Also, if I manually type
> > the body of the code block into the session I get the same error output
> > from Python, so I don't believe this is due to a problem with Babel.
> >
>
> It appear
Eric Schulte gmail.com> writes:
> I can confirm that I see the same behavior. Also, if I manually type
> the body of the code block into the session I get the same error output
> from Python, so I don't believe this is due to a problem with Babel.
>
It appears the problem is that the python ses
Eric Schulte gmail.com> writes:
>
> Hi Herbert,
>
> I can confirm that I see the same behavior. Also, if I manually type
> the body of the code block into the session I get the same error output
> from Python, so I don't believe this is due to a problem with Babel.
>
Eric -- Thanks. Surely t
"Sebastien Vauban"
writes:
> The only case that pops up to my mind now, of such a use case where
> overwriting could be "needed" (well, let's say useful) is for some pedagogical
> document that one would write, where code is constructed from a simplistic
> (and buggy) approach to a correct one.
>
Hi Herbert,
I can confirm that I see the same behavior. Also, if I manually type
the body of the code block into the session I get the same error output
from Python, so I don't believe this is due to a problem with Babel.
Thanks -- Eric
Herbert Sitz writes:
> I have a code block that evaluate
Hi Rob,
Thanks for pointing this out. The emacs-lisp interaction is so simple
we apparently never implemented checks which are routine in other
languages. I just pushed up a fix to the git repository so the
":results scalar" header argument combination should now be respected
for emacs-lisp.
Th
I have a code block that evaluates fine in non-session mode but which gives
syntax error in session mode. Since it works fine in non-session mode I assume
this is a bug?:
#+begin_src python :results output :session mypy
x = 1
for i in range(1,5):
x = x + i
print
hi --- I'm working through the org manual and have run into a strange
problem with ":results scalar"
M-x org-version gives "Org-mode version 7.5 (release_7.5.288.gcec8.dirty)".
I've made a code block using #+begin_src emacs-lisp :results scalar,
with the source just being '(1 2 3), but I get back
For some months now, I've been successfully capturing Firefox data as
explained here: http://orgmode.org/worg/org-contrib/org-protocol.html
But the results below demonstrate a problem. The 2nd and 3rd represent
what was captured into Emacs, the quoted line in each case being what
was highlighted
11 matches
Mail list logo
