[fr] allow overriding the likely unintended consequence of org-export-with-tasks

[fr] allow overriding the likely unintended consequence of org-export-with-tasks

[Samuel Wales]

when org-export-with-tasks is set to nil, tasks will not be exported,
but non-task entries will.

you can make non-exported todo items and notes about your exported text.

* REF this is the top level of the subtree
*** NOTE this is just a note and should not be exported
*** but this i want to export of course

you can specify other values for the variable that have a similar
effect.  let's use nil for this example.

this is highly useful, but in my case, there is an unintended
consequence.   the REF todo kw prevents anything from being exported,
for subtree or region export.  not exporting is not a useful behavior.
i would prefer the top level of the subtree to be exported in all
cases, because i have asked org to export.  it does not matter what kw
it is set to or what the variable is set to.

technically, at least for subtree export, org is doing what the
variable says on the tin, but it is not useful here.

therefore, in order to work around the lack of exporting, i.e. the
unintended consequence, you have to temporarily remove the todo kw,
export, then restore kw.  even exporting a region starting after the
REF kw does not work.  should it?

regardless of the answer, it would be great if it were /possible/ to
export the top level despite its having a todo kw.

Re: [fr] allow overriding the likely unintended consequence of org-export-with-tasks

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> when org-export-with-tasks is set to nil, tasks will not be exported,
> but non-task entries will.
>
> you can make non-exported todo items and notes about your exported text.
>
> * REF this is the top level of the subtree
> *** NOTE this is just a note and should not be exported
> *** but this i want to export of course
>
> you can specify other values for the variable that have a similar
> effect.  let's use nil for this example.
>
> this is highly useful, but in my case, there is an unintended
> consequence.   the REF todo kw prevents anything from being exported,
> for subtree or region export.  not exporting is not a useful behavior.
> i would prefer the top level of the subtree to be exported in all
> cases, because i have asked org to export.  it does not matter what kw
> it is set to or what the variable is set to.

You can set org-export-with-tasks to '("REF"). It will make Org export
REF todo keywords, but not other todo keywords.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [fr] allow overriding the likely unintended consequence of org-export-with-tasks

[Samuel Wales]

On 3/23/23, Ihor Radchenko <yantar92@posteo.net> wrote:
> You can set org-export-with-tasks to '("REF"). It will make Org export
> REF todo keywords, but not other todo keywords.

this is true, but not relevant to my request.  it won't as a practical
matter work around or solve the problem.

i wrote: "i would prefer the top level of the subtree to be exported
in all cases, because i have asked org to export.  it does not matter
what kw it is set to or what the variable is set to."

of course, my request could be optional if desired, but agian it is
not useful to ask to export something and get a no-op.

as for ref [or blank] i do not want to have to keep or temporarily set
a todo kw, or lack of one, at the top level, merely to allow
exporting.  this would be requiring me to maintain a keyword that i do
not want there in the outiine, OR a keyword that i do not want ther
ein the variable, both of which could have various consequences both
semantic and user-comprehension-oriented.

i find that having the feature apply also on the top level heading is
1] pointless, because there is no point in exporting nothing, and 2]
unexpected/surprising because you just SAID to export the subtree!,
and 3] unintended for similar reasons.

in case anybody wants the no-op, making it optional to export the top
level heding would be copacetic.

>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [fr] allow overriding the likely unintended consequence of org-export-with-tasks

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> i wrote: "i would prefer the top level of the subtree to be exported
> in all cases, because i have asked org to export.  it does not matter
> what kw it is set to or what the variable is set to."
> ...
> as for ref [or blank] i do not want to have to keep or temporarily set
> a todo kw, or lack of one, at the top level, merely to allow
> exporting.  this would be requiring me to maintain a keyword that i do
> not want there in the outiine, OR a keyword that i do not want ther
> ein the variable, both of which could have various consequences both
> semantic and user-comprehension-oriented.

I see.

> i find that having the feature apply also on the top level heading is
> 1] pointless, because there is no point in exporting nothing, and 2]
> unexpected/surprising because you just SAID to export the subtree!,
> and 3] unintended for similar reasons.

Sometimes, there is point exporting nothing. In particular, for batch
exports. Also, nothing is too strong term. You will still have global
(empty) template being exported.

In other words, always exporting top-level heading is not always a good
idea.

> in case anybody wants the no-op, making it optional to export the top
> level heding would be copacetic.

One can modify

    ;; Ignore tasks, if specified by `:with-tasks' property.
    	(and todo
    	     (or (not with-tasks)
    		 (and (memq with-tasks '(todo done))
    		      (not (eq todo-type with-tasks)))
    		 (and (consp with-tasks) (not (member todo with-tasks)))))

condition in `org-export--skip-p' to take into account yet another
customization.

Patches welcome.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>