Re: [O] Possible bug with new exporter and org-babel

[Eric Schulte]

address@hidden writes:

> Eric Schulte <address@hidden> writes:
>
>> Where *is* "req" defined?  So far the behavior you describe seems
>> expected.
>
> Sorry for the ambiguity - req isn't defined!
>
> Let me explain a little more clearly: I'm trying to generate some
> release notes using org-mode, pulling data from the github issue
> tracking system.  I'm really just using org as a text markup
> language. One comment in the issue tracker included a stack trace of the
> form
>
>       /foo/bar/call_req() 
>
> where call_req is a function defined in our (non-org) code.  The
> presence of this plain text string in the body of my org document causes
> exporting to fail.
>
> I'm not familiar with either the new exporter or the details of babel
> (though a happy user of it), but my expected behaviour would be that any
> babel cleverness would require more to invoke it than just call_foo()
> or that there would be some means to say, on a document by document
> basis "do not invoke babel"
>

Oh, I understand now, thanks for explaining.

>
> In any event: is there a way I can include the phrase "call_req()" in
> the plain body of my document? Ideally without escaping it, but so so be
> it.
>

You can either set the `org-export-babel-evaluate' variable to nil,
which will inhibit all babel evaluation (this could be done using a file
local variable), or you can escape call_req() as in the attached
example.

#+Options: ^:{}

* Foo
You can avoid attempted evaluation if the call is made to be an
example (this will then export in monospace).

=call_req()=

Escaped inside a =call_req()= line of text.

Another way to escape the stack trace as an example.
: /foo/bar/call_req()

>
> Thanks for your patience.

Cheers,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte