Eric Schulte writes:
> Eric S Fraga writes:
[...]
>> this was working on Friday but seems to have stopped working for me now
>> completely. For instance, your snippet above exports as
>
> Hmm, have you updated Org-mode in the last hour/minutes, there have
> indeed been a number of changes rec
Hi Seb,
I have attempted to reproduce the two problems I've seen mentioned,
specifically
1. repeated prompts to evaluate code when `org-confirm-babel-evaluate'
is set to nil
2. Org-mode files not being seen with Org set as the major mode
I've used the following minimal configuration
seb.el
"Sebastien Vauban" writes:
> Hi Eric,
>
> Eric Schulte wrote:
>>> Well, I have many other problems with this version (such as speed commands
>>> not working anymore, yasnippet expansion not working anymore on TAB, some
>>> files which say they're not in Org-agenda-files, etc.) but that's another
[...]
>
> Sorry for the delay in getting back to you: work sometimes interrupts
> and, just to add a little excitement in my life, we had a major lighting
> storm yesterday which blew out my home network! :( But I can't
> complain: a house down the street caught fire due to the same storm.
> It's
Hi Eric,
Eric Schulte wrote:
>> Well, I have many other problems with this version (such as speed commands
>> not working anymore, yasnippet expansion not working anymore on TAB, some
>> files which say they're not in Org-agenda-files, etc.) but that's another
>> story.
>
> I don't understand, are
>
> Well, I have many other problems with this version (such as speed commands not
> working anymore, yasnippet expansion not working anymore on TAB, some files
> which say they're not in Org-agenda-files, etc.) but that's another story.
>
I don't understand, are you saying that all of the above p
Hi Erics and Christian,
Eric Schulte wrote:
> Thanks for sharing these issues, it appears I messed some functionality
> up with some of my recent changes. I believe that I have fixed these
> issues. The following examples should now all export as described.
>
> The following exports as a normal
Hi,
Yes, these all checked out (assuming you meant the second one /should/
be exported -- as quoted code -- but not evaluated).
This is a nice addition, and rather cleaner and more intuitive than
the workarounds I've been playing with. (Faking an inline call to
block A with an inline src blo
Eric S Fraga writes:
> Eric Schulte writes:
>>
>> I've just pushed up an implementation for inline call blocks, the new
>> syntax is described in the documentation but a simple example is below.
>>
>> #+source: square
>> #+begin_src emacs-lisp :var it=0
>> (* it it)
>> #+end_sr
Eric Schulte writes:
>
> I've just pushed up an implementation for inline call blocks, the new
> syntax is described in the documentation but a simple example is below.
>
> #+source: square
> #+begin_src emacs-lisp :var it=0
> (* it it)
> #+end_src
>
> Here is a call_square(i
Christian Moe writes:
> Fixed, thanks. I should have guessed that might be it.
>
> Evaluating inline calls now works, but there are some ramifications
> for output and export that I hadn't thought about when I seconded the
> request.
>
>
> * Export
>
> The call itself should not be exported, but
Fixed, thanks. I should have guessed that might be it.
Evaluating inline calls now works, but there are some ramifications
for output and export that I hadn't thought about when I seconded the
request.
* Export
The call itself should not be exported, but I'm seeing:
:
: Here is a callsqua
>
> But I seem to have a problem (running your example):
>
> Debugger entered--Lisp error: (invalid-function (nonempty (a b) (let
> ((it (match-string a))) (if (= (length it) 0) (match-string b) it
> (nonempty (a b) (let (...) (if ... ... it)))()
> org-babel-lob-get-info()
> org-babel-lob
Hi, Eric,
Very nice, thanks!
I note the turnover on your long-term low-priority stack is about two
days.
:)
But I seem to have a problem (running your example):
Debugger entered--Lisp error: (invalid-function (nonempty (a b) (let
((it (match-string a))) (if (= (length it) 0) (match-string b
Eric Schulte writes:
> Christian Moe writes:
>
>> +1 for inline calls. No hurry, though.
>>
>
> I've just pushed up an implementation for inline call blocks, the new
> syntax is described in the documentation but a simple example is below.
>
> #+source: square
> #+begin_src emacs-lisp :v
Christian Moe writes:
> +1 for inline calls. No hurry, though.
>
I've just pushed up an implementation for inline call blocks, the new
syntax is described in the documentation but a simple example is below.
#+source: square
#+begin_src emacs-lisp :var it=0
(* it it)
#+end_src
Nicolas Goaziou writes:
> Eric S Fraga writes:
>
>>> I see no difference between the paragraph and the list item: in both
>>> cases, the table doesn't appear, as it has been moved right after the
>>> headline by `org-export-blocks-preprocess' during export.
>>>
>>> Are we observing the same phen
Eric S Fraga writes:
>> I see no difference between the paragraph and the list item: in both
>> cases, the table doesn't appear, as it has been moved right after the
>> headline by `org-export-blocks-preprocess' during export.
>>
>> Are we observing the same phenomenon?
>
> No, I don't believe so
Nicolas Goaziou writes:
> Hello,
>
> Eric S Fraga writes:
>
>> For completeness, I've attached a file which shows that it *can* work
>> but also that it confuses the export of lists (Nicolas?) if the inline
>> code is in a list item.
>
> I see no difference between the paragraph and the list ite
I have been following this thread with interest. When I export Eric's
babelcall.org, the result of the octave calculation is =nil= in both cases.
Is this the expected behaviour? I can confirm Nicolas' observations as well.
Chris
On Jun 23, 2011 9:49am, Nicolas Goaziou wrote:
Hello,
Eri
Hello,
Eric S Fraga writes:
> For completeness, I've attached a file which shows that it *can* work
> but also that it confuses the export of lists (Nicolas?) if the inline
> code is in a list item.
I see no difference between the paragraph and the list item: in both
cases, the table doesn't ap
+1 for inline calls. No hurry, though.
Yours,
Christian
On 6/23/11 7:32 AM, Eric Schulte wrote:
Eric S Fraga writes:
Eric Schulte writes:
Hi Eric,
Hi Eric! ;-)
So the problem is that the results are inserted as a separate block,
when you want them to be inserted inline? If so perhap
Eric Schulte writes:
[...]
>> Yes and no. I *do* want the effect that is achieved by using an inline
>> block but I do *not* want to write the whole block inline
>
> I find the following pattern
>
> #+source: big-block
> #+begin_src emacs-lisp :exports none
> "something complex"
> #+e
Eric S Fraga writes:
> Eric Schulte writes:
>
>> Hi Eric,
>
> Hi Eric! ;-)
>
>> So the problem is that the results are inserted as a separate block,
>> when you want them to be inserted inline? If so perhaps using an
>> "inline" block http://orgmode.org/manual/Structure-of-code-blocks.html
>>
Eric Schulte writes:
> Hi Eric,
Hi Eric! ;-)
> So the problem is that the results are inserted as a separate block,
> when you want them to be inserted inline? If so perhaps using an
> "inline" block http://orgmode.org/manual/Structure-of-code-blocks.html
> would result in the desired behavio
Hi,
The documentation for #+call is rather confusing:
It is also possible to evaluate named code blocks from anywhere in
an Org-mode buffer or an Org-mode table. #+call (or synonymously
#+function or #+lob) lines can be used to remotely execute code
blocks...
Because aparently #+call onl
Hi Eric,
So the problem is that the results are inserted as a separate block,
when you want them to be inserted inline? If so perhaps using an
"inline" block http://orgmode.org/manual/Structure-of-code-blocks.html
would result in the desired behavior.
Please let me know if I've misunderstood the
Hello,
I have been playing with org babel for putting results inline within an
exported latex file. A simple example is here:
--8<---cut here---start->8---
* testing inline evaluation of babel source blocks
#+srcname: benzene-chlorobenzene-relative-volati
28 matches
Mail list logo
