Hello,
Eric Schulte schulte.e...@gmail.com writes:
Nicolas Goaziou n.goaz...@gmail.com writes:
As a side note, I think `org-babel-under-commented-heading-p' is useful
enough (with an optional parameter to prevent inheritance, maybe) to be
moved into org.el.
I agree.
Here is the patch.
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Eric Schulte schulte.e...@gmail.com writes:
Nicolas Goaziou n.goaz...@gmail.com writes:
As a side note, I think `org-babel-under-commented-heading-p' is useful
enough (with an optional parameter to prevent inheritance, maybe) to be
moved
Hi Nicolas and Eric,
Eric Schulte schulte.e...@gmail.com writes:
Looks good to me, I'll leave to Bastien since it touches core Org-mode
functionality and not just Babel.
Looks good to me, please apply,
--
Bastien
Bastien b...@gnu.org writes:
Hi Nicolas and Eric,
Eric Schulte schulte.e...@gmail.com writes:
Looks good to me, I'll leave to Bastien since it touches core Org-mode
functionality and not just Babel.
Looks good to me, please apply,
Applied.
--
Eric Schulte
https://cs.unm.edu/~eschulte
now that everybody is happy, agreeing, and singing in a circle holding
hands, i thought i'd stir the pot. :] i hope i don't get wicked
glares. :]
there are a few unresolved questions. there is also something that,
for my workflow at least, is a bug.
i set org-export-with-tasks to nil,
note: this is not a high priority for me, but it seems like a bug, it
can result in surprising behavior for new users, and it helps clarify
this thread, so it seemed worth posting. the ecm is in this thread.
Hi Nicolas and Eric,
Eric Schulte schulte.e...@gmail.com writes:
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Eric Schulte schulte.e...@gmail.com writes:
This sounds like a good compromise to me. As you say, this should
easily and visually support both use cases and is intuitive.
Eric Schulte schulte.e...@gmail.com writes:
Sorry for being unclear here. I wanted to propose different
behaviour for TAGs (lets say :noexport:) and the COMMENT keyword.
I am perfectly fine with :noexport: only prohibiting export but
still allowing evaluation.
But I propose that COMMENT be
Hello,
Eric Schulte schulte.e...@gmail.com writes:
This sounds like a good compromise to me. As you say, this should
easily and visually support both use cases and is intuitive. I've not
touched the export machinery myself, so I'll leave the implementation to
Nicolas but I definitely
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Eric Schulte schulte.e...@gmail.com writes:
This sounds like a good compromise to me. As you say, this should
easily and visually support both use cases and is intuitive. I've not
touched the export machinery myself, so I'll leave the
Andreas Leha wrote:
Just to confirm. This is what you suggest, correct?
* test
** Not exported
:noexport:
:PROPERTIES:
:noeval: yes
:export: none
:END:
Maybe it's not a real problem, but quotes are for sure not
Hi Eric,
Eric Schulte schulte.e...@gmail.com writes:
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
Hi Eric,
Eric Schulte schulte.e...@gmail.com writes:
So what is your suggestion for the OP to achieve what he is after?
noexport and noeval at the same time.
I'm jumping in
Samuel Wales wrote:
No. This has been raised previously and there was a consensus that it
is often desirable for code in a COMMENT section to be evaluated on
export. Personally I often stuff code blocks into COMMENT sections
which I want run as part of my publishing process (e.g., to create
Samuel Wales samolog...@gmail.com writes:
how about call lines?
to me, they should not run if they are not supposed to be exported.
is this a bug?
* babel should not export a call line via todo kw
*** NEXT to reproduce
set org-export-with-tasks to nil
*** NEXT
please consider this a bug report.
On 3/13/14, Samuel Wales samolog...@gmail.com wrote:
how about call lines?
to me, they should not run if they are not supposed to be exported.
is this a bug?
* babel should not export a call line via todo kw
*** NEXT to reproduce
set
Sorry for being unclear here. I wanted to propose different
behaviour for TAGs (lets say :noexport:) and the COMMENT keyword.
I am perfectly fine with :noexport: only prohibiting export but
still allowing evaluation.
But I propose that COMMENT be more treated like a comment, so more
like a
So what is your suggestion for the OP to achieve what he is after?
noexport and noeval at the same time.
I'm jumping in half way through here, but wouldn't setting the :noeval
property to yes and :export property to none on the subtree work?
One may also want to COMMENT the subtree to
Hi Eric,
Eric Schulte schulte.e...@gmail.com writes:
So what is your suggestion for the OP to achieve what he is after?
noexport and noeval at the same time.
I'm jumping in half way through here,
Thanks for jumping in.
but wouldn't setting the :noeval
property to yes and :export
On Mar 13, 2014 5:49 PM, Andreas Leha andreas.l...@med.uni-goettingen.de
wrote:
Hi Eric,
Eric Schulte schulte.e...@gmail.com writes:
So what is your suggestion for the OP to achieve what he is after?
noexport and noeval at the same time.
I'm jumping in half way through here,
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
Hi Eric,
Eric Schulte schulte.e...@gmail.com writes:
So what is your suggestion for the OP to achieve what he is after?
noexport and noeval at the same time.
I'm jumping in half way through here,
Thanks for jumping in.
but
how about call lines?
to me, they should not run if they are not supposed to be exported.
is this a bug?
* babel should not export a call line via todo kw
*** NEXT to reproduce
set org-export-with-tasks to nil
*** NEXT this should not run
#+call: hi(a=2)
*** hi
No. This has been raised previously and there was a consensus that it
is often desirable for code in a COMMENT section to be evaluated on
export. Personally I often stuff code blocks into COMMENT sections
which I want run as part of my publishing process (e.g., to create
resources used in
Rainer M Krug wrote:
Ken Mankoff mank...@gmail.com writes:
On 2014-03-11 at 08:47, zwz wrote:
In my setup, there is
(setq org-export-exclude-tags '(private exclude)
and In my test.org:
* test
** Not exported:exclude:
#+BEGIN_SRC ditaa :file test.png :cmdline -E
Sebastien Vauban sva-n...@mygooglest.com
writes:
Rainer M Krug wrote:
Ken Mankoff mank...@gmail.com writes:
On 2014-03-11 at 08:47, zwz wrote:
In my setup, there is
(setq org-export-exclude-tags '(private exclude)
and In my test.org:
* test
** Not exported:exclude:
Ken Mankoff mank...@gmail.com writes:
Hi Andreas,
On 2014-03-11 at 09:41, Andreas Leha wrote:
Hi Ken,
Ken Mankoff mank...@gmail.com writes:
On 2014-03-11 at 08:47, zwz wrote:
In my setup, there is
(setq org-export-exclude-tags '(private exclude)
and In my test.org:
* test
** Not
Rainer M Krug rai...@krugs.de writes:
Ken Mankoff mank...@gmail.com writes:
On 2014-03-11 at 08:47, zwz wrote:
In my setup, there is
(setq org-export-exclude-tags '(private exclude)
and In my test.org:
* test
** Not exported:exclude:
#+BEGIN_SRC ditaa :file
In my example, I did not set the header argument session, and variable
org-babel-default-header-args has the value:
(:results . replace)
(:exports . code)
(:cache . no)
(:noweb . no)
(:hlines . no)
(:tangle . no))
However, the block still runs.
I wanted to try and reproduce this,
Hi zwz,
zwz zhangwe...@gmail.com writes:
Ken Mankoff mank...@gmail.com writes:
Hi Andreas,
On 2014-03-11 at 09:41, Andreas Leha wrote:
Hi Ken,
Ken Mankoff mank...@gmail.com writes:
On 2014-03-11 at 08:47, zwz wrote:
In my setup, there is
(setq org-export-exclude-tags '(private
In my setup, there is
(setq org-export-exclude-tags '(private exclude)
and In my test.org:
* test
** Not exported:exclude:
#+BEGIN_SRC ditaa :file test.png :cmdline -E
++---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
x | 0 cRED | 0
On 2014-03-11 at 08:47, zwz wrote:
In my setup, there is
(setq org-export-exclude-tags '(private exclude)
and In my test.org:
* test
** Not exported:exclude:
#+BEGIN_SRC ditaa :file test.png :cmdline -E
++---+---+---+---+---+---+---+
Hi Ken,
Ken Mankoff mank...@gmail.com writes:
On 2014-03-11 at 08:47, zwz wrote:
In my setup, there is
(setq org-export-exclude-tags '(private exclude)
and In my test.org:
* test
** Not exported:exclude:
#+BEGIN_SRC ditaa :file test.png :cmdline -E
Hi Andreas,
On 2014-03-11 at 09:41, Andreas Leha wrote:
Hi Ken,
Ken Mankoff mank...@gmail.com writes:
On 2014-03-11 at 08:47, zwz wrote:
In my setup, there is
(setq org-export-exclude-tags '(private exclude)
and In my test.org:
* test
** Not exported:exclude:
Ken Mankoff mank...@gmail.com writes:
On 2014-03-11 at 08:47, zwz wrote:
In my setup, there is
(setq org-export-exclude-tags '(private exclude)
and In my test.org:
* test
** Not exported:exclude:
#+BEGIN_SRC ditaa :file test.png :cmdline -E
33 matches
Mail list logo
