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.
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, because
Bastien writes:
> Hi Nicolas and Eric,
>
> Eric Schulte 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
PGP: 0x614CA05D
Hi Nicolas and Eric,
Eric Schulte 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
Nicolas Goaziou writes:
> Hello,
>
> Eric Schulte writes:
>
>> Nicolas Goaziou 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
Hello,
Eric Schulte writes:
> Nicolas Goaziou 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.
Regards,
--
Nicolas Goaz
Hi Nicolas and Eric,
Eric Schulte writes:
> Nicolas Goaziou writes:
>
>> Hello,
>>
>> Eric Schulte 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 mysel
Nicolas Goaziou writes:
> Hello,
>
> Eric Schulte 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
Hello,
Eric Schulte 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 support this approach.
Eric Schulte 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 more treat
> 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
>
please consider this a bug report.
On 3/13/14, Samuel Wales 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 org-export-with
Samuel Wales 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 this should n
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
Hi Eric,
Eric Schulte writes:
> Andreas Leha writes:
>
>> Hi Eric,
>>
>> Eric Schulte 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 f
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 s
> 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
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
#+
Andreas Leha writes:
> Hi Eric,
>
> Eric Schulte 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 :no
On Mar 13, 2014 5:49 PM, "Andreas Leha"
wrote:
>
> Hi Eric,
>
> Eric Schulte 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.
Hi Eric,
Eric Schulte 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 pro
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 th
Hi zwz,
zwz writes:
> Ken Mankoff writes:
>
>> Hi Andreas,
>>
>> On 2014-03-11 at 09:41, Andreas Leha wrote:
>>> Hi Ken,
>>>
>>> Ken Mankoff writes:
>>>
On 2014-03-11 at 08:47, zwz wrote:
> In my setup, there is
> (setq org-export-exclude-tags '("private" "exclude")
>
> a
> 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 a
Rainer M Krug writes:
> Ken Mankoff 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.
Ken Mankoff writes:
> Hi Andreas,
>
> On 2014-03-11 at 09:41, Andreas Leha wrote:
>> Hi Ken,
>>
>> Ken Mankoff 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
>>
Sebastien Vauban
writes:
> Rainer M Krug wrote:
>> Ken Mankoff 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:
>>
Rainer M Krug wrote:
> Ken Mankoff 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 :
Ken Mankoff 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 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:
Hi Ken,
Ken Mankoff 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
>>
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
> ++---+---+---+---+---+---+---+
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
33 matches
Mail list logo
