How to define TODOs within continuous text the best way?

How to define TODOs within continuous text the best way?

[Karl Maihofer]

Hi,

I write some articles in Org-Mode and use the html and latex export
function. I'm wondering about how to define TODOs within the text the
best way. I hope my bad english lasts to explain what I mean exactly:

I'd like to define a TODO like in the example below. When there is a
task somewhere in my text (I want to look something up etc.) I want to
define this task at the relevant position in my text. So I can lookup
all TODOs using the agenda-view and jump directly to the position in my
text.

The problem is that a TODO is always a new heading and so it is exported
in my html(latex)-version as a heading. I would prefer to format a TODO
as a text box or at least to exclude it from the html(latex)-export so
that it is only visible in org-mode - not in the exported version. But
when I exclude the TODO so that it isn't exported anymore, not only the
TODO itself but also the text below the TODO isn't exported until there
is a new heading - because the TODO itself is a heading, too.

I know that this is because Org-Mode is an outliner-mode, TODOs always
have to be defined with a beginning "*". But is there any possibility to
solve the problem? How do you define TODOs within the text when you use
Org-Mode as an authoring tool?

Perhaps it is possible to define TODOs as a very deep-level heading,
that isn't needed, like "********** TODO text" and change the export
function that this level isn't exported as a heading but as a
"div"-Container? Or every heading that contains "TODO" is not exported
as a heading but as a div-container?

What is the best way to handle TODOs within continuous text?

Kind regards,
Karl

-----------------------------------------------------------------------
* Heading 1

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy
eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam
voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet
clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit
amet.

* TODO Check again (or ********** TODO text?)

This paragraph still belongs to heading 1. Lorem ipsum dolor sit amet,
consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut
labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et
accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no
sea takimata sanctus est Lorem ipsum dolor sit amet.

* Heading 2

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy
eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam
voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet
clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit
amet.

-----------------------------------------------------------------------

Re: How to define TODOs within continuous text the best way?

[Sebastian Rose]

Karl Maihofer <ignoramus@gmx.de> writes:
> Perhaps it is possible to define TODOs as a very deep-level heading,
> that isn't needed, like "********** TODO text" and change the export
> function that this level isn't exported as a heading but as a
> "div"-Container? Or every heading that contains "TODO" is not exported
> as a heading but as a div-container?


Yes, this is possible. By default only the first three levels are
exported as headlines. Any headline that is deeper nested, is exported
as a list item.

The variable in question is

   `org-export-headline-levels'


> What is the best way to handle TODOs within continuous text?

Those list items are not displayed inline, but produce no entry in the
TOC.


I have several commands like that defined (\rzidea, ...) and some
produce a box with an icon and frame, that does not use the margin.


Here's the inline version:

=> --->8----------------------------->8----------------------------->8---

\newcommand { \rztodoinline }
[1]
{\colorbox[rgb]{1,0.4,0.2}{\textbf{TODO}}{\textbf{~#1}}}

<= ---8<-----------------------------8<-----------------------------8<---





For things I need to fix in the document itself, I prefer a more visible
presentation of TODOs. For LaTeX/PDF I even use this here:


=> --->8----------------------------->8----------------------------->8---
* Headline

  some text here...

  \rztodo{Description of todo.}

  more text here...

<= ---8<-----------------------------8<-----------------------------8<---


\rztodo is command defined in an LaTeX include file:


=> --->8----------------------------->8----------------------------->8---

\newcommand { \rztodo }
[1]
{%
  \medskip
  \nopagebreak
  \noindent
  \rule{\textwidth}{0.5pt}\\*[1mm]
  \marginpar{\colorbox[rgb]{1,0.4,0.2}{\textbf{TODO}}}
  #1\\*[-1mm]
  \rule{\textwidth}{0.5pt}\\
  \nopagebreak[3]
}

<= ---8<-----------------------------8<-----------------------------8<---



This creates a _very_ visible box in the margin and the result looks
like this (TODO is white on red):

=> --->8----------------------------->8----------------------------->8---

1 Headline

  some text here...

  ------------------------------------------------------  +------+
  Description of todo.                                    | TODO |
  ------------------------------------------------------  +------+

  more text here...

<= ---8<-----------------------------8<-----------------------------8<---



Best Regards,


   Sebastian

Re: How to define TODOs within continuous text the best way?

[Karl Maihofer]

Hi,

thanks for your answer!

Sebastian Rose schrieb:
> Yes, this is possible. By default only the first three levels are
> exported as headlines. Any headline that is deeper nested, is exported
> as a list item.
> 
> The variable in question is
> 
>    `org-export-headline-levels'

OK, I see. But now the text below the TODO-item is still part of the
list. So it is indented - in html.

Another idea: Why not simply use comments?

#+HTML: <!--
#+LaTeX: \begin{comment}
* TODO Test
#+LaTeX: \end{comment}
#+HTML: -->

I think, this should work for me.

The only problem now is to exclude the TODO from the HTML-generated
Table of Contents. Using "#+EXPORT_EXCLUDE_TAGS: exclude" does not work.
Perhaps a bug in the html-export?

> I have several commands like that defined (\rzidea, ...) and some
> produce a box with an icon and frame, that does not use the margin.

That looks nice. But I think this is not the right solution for me?! For
me it is important that the TODOs are recognized by Org-Mode so that I
can jump to the position within my document using the agenda. In the
exported version of the file it is no problem when the TODOs are missing.

Thanks again and
Kind regards,

Karl

Re: How to define TODOs within continuous text the best way?

[Karl Maihofer]

Karl Maihofer schrieb:
> #+HTML: <!--
> #+LaTeX: \begin{comment}
> * TODO Test
> #+LaTeX: \end{comment}
> #+HTML: -->
> 
> I think, this should work for me.
> 
> The only problem now is to exclude the TODO from the HTML-generated
> Table of Contents. Using "#+EXPORT_EXCLUDE_TAGS: exclude" does not work.
> Perhaps a bug in the html-export?

Sorry, no bug, of course. When I mark the TODO-Item not to be exported,
the end-tags of the comment-tags are not exported, too. ;-)

Is there a way only to exclude an item from the table of contents?

Kind regards,
Karl

Re: How to define TODOs within continuous text the best way?

[Sebastian Rose]

Karl Maihofer <ignoramus@gmx.de> writes:
> Hi,
>
> thanks for your answer!
>
> Sebastian Rose schrieb:
>> Yes, this is possible. By default only the first three levels are
>> exported as headlines. Any headline that is deeper nested, is exported
>> as a list item.
>> 
>> The variable in question is
>> 
>>    `org-export-headline-levels'
>
> OK, I see. But now the text below the TODO-item is still part of the
> list. So it is indented - in html.


Hmmm - true - how are those todo items related to the rest of the text?

Todos in Org-mode are geared for TODO lists, not as annotations or
sidenotes.



> Another idea: Why not simply use comments?
>
> #+HTML: <!--
> #+LaTeX: \begin{comment}
> * TODO Test
> #+LaTeX: \end{comment}
> #+HTML: -->
>
> I think, this should work for me.
>
> The only problem now is to exclude the TODO from the HTML-generated
> Table of Contents. Using "#+EXPORT_EXCLUDE_TAGS: exclude" does not work.
> Perhaps a bug in the html-export?


http://orgmode.org/Changes.html#sec-19.3.4

 --->8----------------------------->8----------------------------->8---

* TODO not exported but in agena                     :noexport:

 ---8<-----------------------------8<-----------------------------8<---


works here.



> That looks nice. But I think this is not the right solution for me?! For
> me it is important that the TODOs are recognized by Org-Mode so that I
> can jump to the position within my document using the agenda. In the
> exported version of the file it is no problem when the TODOs are missing.




What about using links to those TODO items?

 --->8----------------------------->8----------------------------->8---

* headline

  This is the text with a [[todo-1][TODO-link]] inline...


 .... more content here, sections, lists, whatever...



# <<todo-1>>
* TODO This is the TODO

  This TODO will show up in the agenda.

 ---8<-----------------------------8<-----------------------------8<---


or


 --->8----------------------------->8----------------------------->8---

* headline

  This is the text with a [[Clean the garage]] inline...


.... more content here, sections, lists, whatever...


* TODO <<Clean the garage>>

  This TODO will show up in the agenda.

 ---8<-----------------------------8<-----------------------------8<---




???


This is all I can think of so far. Not exactly what you're looking for,
but maybe some of this or combinations from it might help.



  - Sebastian

Re: How to define TODOs within continuous text the best way?

[Sebastian Rose]

I can't think of a good way to make the TODO items inline for HTML
export, as the result is a list. Note, that the <p> element has to be
closed to have valid XHTML (wich means we can't use a CSS selector
`p ul' here to make it inline):

=> --->8----------------------------->8----------------------------->8---

<p> Some Text...
</p><ul>
<li id="sec-1.1.1.1.1"><span class="todo TODO"> TODO</span> Get the container <br/>
</li>
</ul>
<p> Some Text...

<= ---8<-----------------------------8<-----------------------------8<---

  Sebastian


Karl Maihofer <ignoramus@gmx.de> writes:
> Hi,
>
> I write some articles in Org-Mode and use the html and latex export
> function. I'm wondering about how to define TODOs within the text the
> best way. I hope my bad english lasts to explain what I mean exactly:
>
> I'd like to define a TODO like in the example below. When there is a
> task somewhere in my text (I want to look something up etc.) I want to
> define this task at the relevant position in my text. So I can lookup
> all TODOs using the agenda-view and jump directly to the position in my
> text.
>
> The problem is that a TODO is always a new heading and so it is exported
> in my html(latex)-version as a heading. I would prefer to format a TODO
> as a text box or at least to exclude it from the html(latex)-export so
> that it is only visible in org-mode - not in the exported version. But
> when I exclude the TODO so that it isn't exported anymore, not only the
> TODO itself but also the text below the TODO isn't exported until there
> is a new heading - because the TODO itself is a heading, too.
>
> I know that this is because Org-Mode is an outliner-mode, TODOs always
> have to be defined with a beginning "*". But is there any possibility to
> solve the problem? How do you define TODOs within the text when you use
> Org-Mode as an authoring tool?
>
> Perhaps it is possible to define TODOs as a very deep-level heading,
> that isn't needed, like "********** TODO text" and change the export
> function that this level isn't exported as a heading but as a
> "div"-Container? Or every heading that contains "TODO" is not exported
> as a heading but as a div-container?
>
> What is the best way to handle TODOs within continuous text?
>
> Kind regards,
> Karl
>
> -----------------------------------------------------------------------
> * Heading 1
>
> Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy
> eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam
> voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet
> clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit
> amet.
>
> * TODO Check again (or ********** TODO text?)
>
> This paragraph still belongs to heading 1. Lorem ipsum dolor sit amet,
> consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut
> labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et
> accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no
> sea takimata sanctus est Lorem ipsum dolor sit amet.
>
> * Heading 2
>
> Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy
> eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam
> voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet
> clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit
> amet.
>
> -----------------------------------------------------------------------
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>

Re: How to define TODOs within continuous text the best way?

[Carsten Dominik]

On Mar 28, 2009, at 3:23 PM, Karl Maihofer wrote:
>
> I'd like to define a TODO like in the example below. When there is a
> task somewhere in my text (I want to look something up etc.) I want to
> define this task at the relevant position in my text. So I can lookup
> all TODOs using the agenda-view and jump directly to the position in  
> my
> text.
>
> The problem is that a TODO is always a new heading and so it is  
> exported
> in my html(latex)-version as a heading.


Sometimes, miracles do happen.

The question about non-outline tasks is, really, a FAQ.  We have
been over this question again and again, though not recently.
Each time this question came up I thought it over again, each
time with the same result: that this is not possible in a
reasonable clean way in the framework of Org's hierarchical
document structure.

The ideas that were contemplated usually were things like adding
a new syntax which is "only" for task management treated as a
headline, but not otherwise.  I remember proposals like

#*** TODO my task

or finding a way to add metadata it plain list items, or many
other similar ideas.

The trouble is, task management is much of Org, so new syntax
would be a lot of work.  It would destroy he cleanness of much of
Org.  So always the answer was it cannot be done.

That is not to say that I do not appreciate the wish for such a
structure.  In an outline/list driven setting, one can always
re-arrange things to make tasks a separate section.  However,
when writing a book or extensive notes, the text becomes dominant
over the density of outline nodes, and then getting a task into
the right place becomes an issue.

This new thread, first greeted with a sigh on my side,
somehow has changed the perception by focussing on *export*
handling of nodes.

And it is now clear to me that, in fact, there is a reasonable
clean pass to "inline" tasks:

                   Fool the user, not Org!

We will make them just normal outline nodes with stars,
metadata and all the rest.  Full citizens.  But then we treat
them specially in just two situations:

1. For visibility cycling: We disqualify these tasks from being
    recognized during visibility cycling.  Simply by setting a
    limit for the outline depth to be seen by cycling, treating
    any deeper levels as normal text.  So if the parent opens, all
    these "disqualified" nodes are treated as text and open as
    well.

2. During export: We treat the node and its meta data as special
    and export it as some inline construct, and we do this in the
    export *preprocessor* already, so that the backends never know
    there was an outline node at all.  This fixes any issues with
    section numbering, text and list continuation etc.

3. As icing on the cake we introduce special fontification which
    make inline tasks look deeply indented.

I have put these features into a new add-on, org-inlinetask.el.
Just (require 'org-inlinetask) should turn it on for you, and
any headline with a level 15 or deeper (30 if you use odd levels
only) will then be subject to the special treatment.

I just pushed this file into the git repository.  Read the file
commentary for explanations and try it out - I think the
mechanism work surprisingly well.

I simply cannot believe that after all those years, we might be
able to close this task.

- Carsten


> I would prefer to format a TODO
> as a text box or at least to exclude it from the html(latex)-export so
> that it is only visible in org-mode - not in the exported version. But
> when I exclude the TODO so that it isn't exported anymore, not only  
> the
> TODO itself but also the text below the TODO isn't exported until  
> there
> is a new heading - because the TODO itself is a heading, too.
>
> I know that this is because Org-Mode is an outliner-mode, TODOs always
> have to be defined with a beginning "*". But is there any  
> possibility to
> solve the problem? How do you define TODOs within the text when you  
> use
> Org-Mode as an authoring tool?
>
> Perhaps it is possible to define TODOs as a very deep-level heading,
> that isn't needed, like "********** TODO text" and change the export
> function that this level isn't exported as a heading but as a
> "div"-Container? Or every heading that contains "TODO" is not exported
> as a heading but as a div-container?
>
> What is the best way to handle TODOs within continuous text?
>
> Kind regards,
> Karl
>
> -----------------------------------------------------------------------
> * Heading 1
>
> Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam  
> nonumy
> eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed  
> diam
> voluptua. At vero eos et accusam et justo duo dolores et ea rebum.  
> Stet
> clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor  
> sit
> amet.
>
> * TODO Check again (or ********** TODO text?)
>
> This paragraph still belongs to heading 1. Lorem ipsum dolor sit amet,
> consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut
> labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos  
> et
> accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren,  
> no
> sea takimata sanctus est Lorem ipsum dolor sit amet.
>
> * Heading 2
>
> Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam  
> nonumy
> eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed  
> diam
> voluptua. At vero eos et accusam et justo duo dolores et ea rebum.  
> Stet
> clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor  
> sit
> amet.
>
> -----------------------------------------------------------------------
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: How to define TODOs within continuous text the best way?

[Bernt Hansen]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Sometimes, miracles do happen.

:)

<snip>
>                   Fool the user, not Org!
>
> We will make them just normal outline nodes with stars,
> metadata and all the rest.  Full citizens.  But then we treat
> them specially in just two situations:
>
> 1. For visibility cycling: We disqualify these tasks from being
>    recognized during visibility cycling.  Simply by setting a
>    limit for the outline depth to be seen by cycling, treating
>    any deeper levels as normal text.  So if the parent opens, all
>    these "disqualified" nodes are treated as text and open as
>    well.
>
> 2. During export: We treat the node and its meta data as special
>    and export it as some inline construct, and we do this in the
>    export *preprocessor* already, so that the backends never know
>    there was an outline node at all.  This fixes any issues with
>    section numbering, text and list continuation etc.
>
> 3. As icing on the cake we introduce special fontification which
>    make inline tasks look deeply indented.
>
> I have put these features into a new add-on, org-inlinetask.el.
> Just (require 'org-inlinetask) should turn it on for you, and
> any headline with a level 15 or deeper (30 if you use odd levels
> only) will then be subject to the special treatment.
>
> I just pushed this file into the git repository.  Read the file
> commentary for explanations and try it out - I think the
> mechanism work surprisingly well.
>
> I simply cannot believe that after all those years, we might be
> able to close this task.

I think there's a bug here.  I have started using 
(setq org-odd-levels-only t)

again and org-cycle() complains about 'limit' not having a value.

,----[ org.el line 4533 ]
| 			  (and limit-level (1- (* limit 2)))
`----                                             ^^^^^

All I did was update to the latest version in git and did not make any
other changes to my setup (ie. I'm not using the
(require 'org-inlinetask)
stuff)

I'm not sure what this is supposed to be..

Here's the backtrace.

-Bernt


Debugger entered--Lisp error: (void-variable limit)
  (* limit 2)
  (1- (* limit 2))
  (and limit-level (1- (* limit 2)))
  (if org-odd-levels-only (and limit-level (1- ...)) limit-level)
  (and limit-level (if org-odd-levels-only (and limit-level ...) limit-level))
  (let* ((limit-level ...) (nstars ...) (outline-regexp ...) (bob-special ...) (org-cycle-hook ...) (pos ...)) (if (or bob-special ...) (setq arg t)) (cond (... ... ...) (... ... ...) (... ...) (... ...) (... ...) (... ...) (... ... ...) (buffer-read-only ...) (...) (...) (... ...) (... ...) (t ...)))
  org-cycle(nil)
  call-interactively(org-cycle)
  recursive-edit()
  byte-code("Æ\x10	@Ç=ƒ!\0ÈÉÊ\"ˆËÉ!‰\x1aA@)¢Ì=ƒ!\0ÈÍÊ\"ˆÎ\v!ˆÏ ˆÐ	!ˆ\fƒc\0Ñed\"\rVƒW\0ebˆÒ\r¥yˆ`\x1e^[dbˆÒ\r¥\rZyˆ\x0e^[`|ˆ)ÓcˆebˆÔÕÖ \"ˆ× ˆÔØ!ˆÙÊ\x1e\x1c\x1e\x1dÔØ!ˆŠÚ ˆ+Ù‡" [unread-command-char debugger-args x debugger-buffer noninteractive debugger-batch-max-lines -1 debug backtrace-debug 4 t backtrace-frame lambda 5 pop-to-buffer debugger-mode debugger-setup-buffer count-lines 2 "...\n" message "%s" buffer-string kill-emacs "" nil recursive-edit middlestart buffer-read-only standard-output] 4)
  debug(error (void-variable limit))
  (* limit 2)
  (1- (* limit 2))
  (and limit-level (1- (* limit 2)))
  (if org-odd-levels-only (and limit-level (1- ...)) limit-level)
  (and limit-level (if org-odd-levels-only (and limit-level ...) limit-level))
  (let* ((limit-level ...) (nstars ...) (outline-regexp ...) (bob-special ...) (org-cycle-hook ...) (pos ...)) (if (or bob-special ...) (setq arg t)) (cond (... ... ...) (... ... ...) (... ...) (... ...) (... ...) (... ...) (... ... ...) (buffer-read-only ...) (...) (...) (... ...) (... ...) (t ...)))
  org-cycle(nil)
  call-interactively(org-cycle)
  recursive-edit()
  byte-code("Æ\x10	@Ç=ƒ!\0ÈÉÊ\"ˆËÉ!‰\x1aA@)¢Ì=ƒ!\0ÈÍÊ\"ˆÎ\v!ˆÏ ˆÐ	!ˆ\fƒc\0Ñed\"\rVƒW\0ebˆÒ\r¥yˆ`\x1e^[dbˆÒ\r¥\rZyˆ\x0e^[`|ˆ)ÓcˆebˆÔÕÖ \"ˆ× ˆÔØ!ˆÙÊ\x1e\x1c\x1e\x1dÔØ!ˆŠÚ ˆ+Ù‡" [unread-command-char debugger-args x debugger-buffer noninteractive debugger-batch-max-lines -1 debug backtrace-debug 4 t backtrace-frame lambda 5 pop-to-buffer debugger-mode debugger-setup-buffer count-lines 2 "...\n" message "%s" buffer-string kill-emacs "" nil recursive-edit middlestart buffer-read-only standard-output] 4)
  debug(error (void-variable limit))
  (* limit 2)
  (1- (* limit 2))
  (and limit-level (1- (* limit 2)))
  (if org-odd-levels-only (and limit-level (1- ...)) limit-level)
  (and limit-level (if org-odd-levels-only (and limit-level ...) limit-level))
  (let* ((limit-level ...) (nstars ...) (outline-regexp ...) (bob-special ...) (org-cycle-hook ...) (pos ...)) (if (or bob-special ...) (setq arg t)) (cond (... ... ...) (... ... ...) (... ...) (... ...) (... ...) (... ...) (... ... ...) (buffer-read-only ...) (...) (...) (... ...) (... ...) (t ...)))
  org-cycle(nil)
  call-interactively(org-cycle)
  yas/expand()
  call-interactively(yas/expand)

Re: How to define TODOs within continuous text the best way?

[Carsten Dominik]

Fixed, thanks.

- Carsten

On Mar 30, 2009, at 10:18 PM, Bernt Hansen wrote:

> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> Sometimes, miracles do happen.
>
> :)
>
> <snip>
>>                  Fool the user, not Org!
>>
>> We will make them just normal outline nodes with stars,
>> metadata and all the rest.  Full citizens.  But then we treat
>> them specially in just two situations:
>>
>> 1. For visibility cycling: We disqualify these tasks from being
>>   recognized during visibility cycling.  Simply by setting a
>>   limit for the outline depth to be seen by cycling, treating
>>   any deeper levels as normal text.  So if the parent opens, all
>>   these "disqualified" nodes are treated as text and open as
>>   well.
>>
>> 2. During export: We treat the node and its meta data as special
>>   and export it as some inline construct, and we do this in the
>>   export *preprocessor* already, so that the backends never know
>>   there was an outline node at all.  This fixes any issues with
>>   section numbering, text and list continuation etc.
>>
>> 3. As icing on the cake we introduce special fontification which
>>   make inline tasks look deeply indented.
>>
>> I have put these features into a new add-on, org-inlinetask.el.
>> Just (require 'org-inlinetask) should turn it on for you, and
>> any headline with a level 15 or deeper (30 if you use odd levels
>> only) will then be subject to the special treatment.
>>
>> I just pushed this file into the git repository.  Read the file
>> commentary for explanations and try it out - I think the
>> mechanism work surprisingly well.
>>
>> I simply cannot believe that after all those years, we might be
>> able to close this task.
>
> I think there's a bug here.  I have started using
> (setq org-odd-levels-only t)
>
> again and org-cycle() complains about 'limit' not having a value.
>
> ,----[ org.el line 4533 ]
> | 			  (and limit-level (1- (* limit 2)))
> `----                                             ^^^^^
>
> All I did was update to the latest version in git and did not make any
> other changes to my setup (ie. I'm not using the
> (require 'org-inlinetask)
> stuff)
>
> I'm not sure what this is supposed to be..
>
> Here's the backtrace.
>
> -Bernt
>
>
> Debugger entered--Lisp error: (void-variable limit)
>  (* limit 2)
>  (1- (* limit 2))
>  (and limit-level (1- (* limit 2)))
>  (if org-odd-levels-only (and limit-level (1- ...)) limit-level)
>  (and limit-level (if org-odd-levels-only (and limit-level ...)  
> limit-level))
>  (let* ((limit-level ...) (nstars ...) (outline-regexp ...) (bob- 
> special ...) (org-cycle-hook ...) (pos ...)) (if (or bob- 
> special ...) (setq arg t)) (cond (... ... ...) (... ... ...)  
> (... ...) (... ...) (... ...) (... ...) (... ... ...) (buffer-read- 
> only ...) (...) (...) (... ...) (... ...) (t ...)))
>  org-cycle(nil)
>  call-interactively(org-cycle)
>  recursive-edit()
>  byte-code("Æ\x10	@Ç=ƒ!ÈÉÊ\"ˆËÉ!‰\x1aA@)¢Ì=ƒ!ÈÍÊ\"ˆÎ\v!ˆÏ ˆÐ	!ˆ\fƒcÑed\"
> VƒWebˆÒ
> ¥yˆ`\x1e^[dbˆÒ
> ¥
> Zyˆ\x0e^[`|ˆ)ÓcˆebˆÔÕÖ \"ˆ× ˆÔØ!ˆÙÊ\x1e\x1c\x1e\x1dÔØ!ˆŠÚ ˆ+Ù‡" [unread-command-char  
> debugger-args x debugger-buffer noninteractive debugger-batch-max- 
> lines -1 debug backtrace-debug 4 t backtrace-frame lambda 5 pop-to- 
> buffer debugger-mode debugger-setup-buffer count-lines 2 "...\n"  
> message "%s" buffer-string kill-emacs "" nil recursive-edit  
> middlestart buffer-read-only standard-output] 4)
>  debug(error (void-variable limit))
>  (* limit 2)
>  (1- (* limit 2))
>  (and limit-level (1- (* limit 2)))
>  (if org-odd-levels-only (and limit-level (1- ...)) limit-level)
>  (and limit-level (if org-odd-levels-only (and limit-level ...)  
> limit-level))
>  (let* ((limit-level ...) (nstars ...) (outline-regexp ...) (bob- 
> special ...) (org-cycle-hook ...) (pos ...)) (if (or bob- 
> special ...) (setq arg t)) (cond (... ... ...) (... ... ...)  
> (... ...) (... ...) (... ...) (... ...) (... ... ...) (buffer-read- 
> only ...) (...) (...) (... ...) (... ...) (t ...)))
>  org-cycle(nil)
>  call-interactively(org-cycle)
>  recursive-edit()
>  byte-code("Æ\x10	@Ç=ƒ!ÈÉÊ\"ˆËÉ!‰\x1aA@)¢Ì=ƒ!ÈÍÊ\"ˆÎ\v!ˆÏ ˆÐ	!ˆ\fƒcÑed\"
> VƒWebˆÒ
> ¥yˆ`\x1e^[dbˆÒ
> ¥
> Zyˆ\x0e^[`|ˆ)ÓcˆebˆÔÕÖ \"ˆ× ˆÔØ!ˆÙÊ\x1e\x1c\x1e\x1dÔØ!ˆŠÚ ˆ+Ù‡" [unread-command-char  
> debugger-args x debugger-buffer noninteractive debugger-batch-max- 
> lines -1 debug backtrace-debug 4 t backtrace-frame lambda 5 pop-to- 
> buffer debugger-mode debugger-setup-buffer count-lines 2 "...\n"  
> message "%s" buffer-string kill-emacs "" nil recursive-edit  
> middlestart buffer-read-only standard-output] 4)
>  debug(error (void-variable limit))
>  (* limit 2)
>  (1- (* limit 2))
>  (and limit-level (1- (* limit 2)))
>  (if org-odd-levels-only (and limit-level (1- ...)) limit-level)
>  (and limit-level (if org-odd-levels-only (and limit-level ...)  
> limit-level))
>  (let* ((limit-level ...) (nstars ...) (outline-regexp ...) (bob- 
> special ...) (org-cycle-hook ...) (pos ...)) (if (or bob- 
> special ...) (setq arg t)) (cond (... ... ...) (... ... ...)  
> (... ...) (... ...) (... ...) (... ...) (... ... ...) (buffer-read- 
> only ...) (...) (...) (... ...) (... ...) (t ...)))
>  org-cycle(nil)
>  call-interactively(org-cycle)
>  yas/expand()
>  call-interactively(yas/expand)

Re: How to define TODOs within continuous text the best way?

[Bernt Hansen]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Fixed, thanks.

Awesome!  Thanks!!

-Bernt

Re: How to define TODOs within continuous text the best way?

[Karl Maihofer]

Hi Carsten!

Carsten Dominik schrieb:
> I just pushed this file into the git repository.  Read the file
> commentary for explanations and try it out - I think the
> mechanism work surprisingly well.

Thanks a lot! That seems to be what i was looking for. I just tried the
latest git-version and have still some problems. But I am not a
programmer...

At first i didn't get a lisp/org-inlinetask.elc when i compiled org
(require 'org-inlinetask in my .emacs didn't work). So I added
org-inlinetask.el to the LISPF-List in the Makefile. In the
dependencies-section a added lisp/org-inlinetask.elc: lisp/org.el
lisp/org-exp.el. Now I do have an org-inlinetask.elc. Visibility cycling
now works as expected, so that i think org-inlinetask is loaded correctly.

But the following simple org-file is not exported correctly:

-------------------------------------------------------
* Heading 1

Frist paragraph (heading 1).

*************** TODO Inline!

Second paragraph (heading 1).

* Heading 2

First paragraph (heading 2).
--------------------------------------------------------

Export result is something like this:

--------------------------------------------------------
1 Heading 1

First paragraph (heading 1).

Second paragraph (heading 1).

2

=>=>=> TODO Inline!

Heading 2

First paragraph (heading 2).
-------------------------------------------------------------

HTML-Source is:

-------------------------------------------------------------
<div id="content">
<h1 class="title">test</h1>


<div id="table-of-contents">
<h2>Inhaltsverzeichnis</h2>
<div id="text-table-of-contents">
<ul>
<li><a href="#sec-1">1 Heading 1 </a></li>
<li><a href="#sec-2">2 </a></li>
</ul>
</div>
</div>

<div id="outline-container-1" class="outline-2">
<h2 id="sec-1"><span class="section-number-2">1</span> Heading 1 </h2>
<div class="outline-text-2" id="text-1">


<p>
Frist paragraph (heading 1).
</p>

<p>
Second paragraph (heading 1).
</p>
</div>

</div>

<div id="outline-container-2" class="outline-2">
<h2 id="sec-2"><span class="section-number-2">2</span> </h2>
<div class="outline-text-2" id="text-2">


<p>
&rArr;&rArr;&rArr; <b>TODO Inline!</b>
</p>
<p>
Heading 2

</p>
<p>
Frist paragraph (heading 2).
</p></div>
</div>
<div id="postamble">
<p class="author"> Autor: Karl
<a href="mailto:karl@netbook">&lt;karl@netbook&gt;</a>
</p>
<p class="date"> Datum: 2009-03-31 17:15:12 CEST</p>
<p class="creator">HTML generated by org-mode 6.24trans in emacs 23</p>
</div>

</div>
--------------------------------------------------------------------

Regards,
Karl

Re: How to define TODOs within continuous text the best way?

[Carsten Dominik]

Hi Karl,

thanks for checking this out.  Yes, I left a stupid bug
which did not show with my more complex test case.
This is fixed now.

About the .elc file, yes, another omission on my side, but
you could have run it anyway.

- Carsten

On Mar 31, 2009, at 5:23 PM, Karl Maihofer wrote:

> Hi Carsten!
>
> Carsten Dominik schrieb:
>> I just pushed this file into the git repository.  Read the file
>> commentary for explanations and try it out - I think the
>> mechanism work surprisingly well.
>
> Thanks a lot! That seems to be what i was looking for. I just tried  
> the
> latest git-version and have still some problems. But I am not a
> programmer...
>
> At first i didn't get a lisp/org-inlinetask.elc when i compiled org
> (require 'org-inlinetask in my .emacs didn't work). So I added
> org-inlinetask.el to the LISPF-List in the Makefile. In the
> dependencies-section a added lisp/org-inlinetask.elc: lisp/org.el
> lisp/org-exp.el. Now I do have an org-inlinetask.elc. Visibility  
> cycling
> now works as expected, so that i think org-inlinetask is loaded  
> correctly.
>
> But the following simple org-file is not exported correctly:
>
> -------------------------------------------------------
> * Heading 1
>
> Frist paragraph (heading 1).
>
> *************** TODO Inline!
>
> Second paragraph (heading 1).
>
> * Heading 2
>
> First paragraph (heading 2).
> --------------------------------------------------------
>
> Export result is something like this:
>
> --------------------------------------------------------
> 1 Heading 1
>
> First paragraph (heading 1).
>
> Second paragraph (heading 1).
>
> 2
>
> =>=>=> TODO Inline!
>
> Heading 2
>
> First paragraph (heading 2).
> -------------------------------------------------------------
>
> HTML-Source is:
>
> -------------------------------------------------------------
> <div id="content">
> <h1 class="title">test</h1>
>
>
> <div id="table-of-contents">
> <h2>Inhaltsverzeichnis</h2>
> <div id="text-table-of-contents">
> <ul>
> <li><a href="#sec-1">1 Heading 1 </a></li>
> <li><a href="#sec-2">2 </a></li>
> </ul>
> </div>
> </div>
>
> <div id="outline-container-1" class="outline-2">
> <h2 id="sec-1"><span class="section-number-2">1</span> Heading 1 </h2>
> <div class="outline-text-2" id="text-1">
>
>
> <p>
> Frist paragraph (heading 1).
> </p>
>
> <p>
> Second paragraph (heading 1).
> </p>
> </div>
>
> </div>
>
> <div id="outline-container-2" class="outline-2">
> <h2 id="sec-2"><span class="section-number-2">2</span> </h2>
> <div class="outline-text-2" id="text-2">
>
>
> <p>
> &rArr;&rArr;&rArr; <b>TODO Inline!</b>
> </p>
> <p>
> Heading 2
>
> </p>
> <p>
> Frist paragraph (heading 2).
> </p></div>
> </div>
> <div id="postamble">
> <p class="author"> Autor: Karl
> <a href="mailto:karl@netbook">&lt;karl@netbook&gt;</a>
> </p>
> <p class="date"> Datum: 2009-03-31 17:15:12 CEST</p>
> <p class="creator">HTML generated by org-mode 6.24trans in emacs 23</ 
> p>
> </div>
>
> </div>
> --------------------------------------------------------------------
>
> Regards,
> Karl
>

Re: How to define TODOs within continuous text the best way?

[Daniel Clemente]

El dl, mar 30 2009, Carsten Dominik va escriure:

> I simply cannot believe that after all those years, we might be
> able to close this task.

  Wow, that's wonderful! Thanks for a so easy solution.
  I was needing this functionality since a long time.



  About org-inlinetask-export:

,----
| Documentation:
| What should be done with inlinetasks upon export?
| Possible values:
| 
| nil            Remove entirely
| arrow          Insert heading in bold, preceeded by an arrow
| arrow+content  Insert arrow and headline, add content below in an
|                #+begin_example box (ugly, but works for now)
| 
`----

  Could you add that the „Remove entirely“ means „Remove entirely ... just the header (but not the content)“?


-- Daniel

Re: How to define TODOs within continuous text the best way?

[Carsten Dominik]

[-- Attachment #1.1: Type: text/plain, Size: 1633 bytes --]


On Mar 31, 2009, at 9:53 PM, Daniel Clemente wrote:

> El dl, mar 30 2009, Carsten Dominik va escriure:
>
>> I simply cannot believe that after all those years, we might be
>> able to close this task.
>
>  Wow, that's wonderful! Thanks for a so easy solution.
>  I was needing this functionality since a long time.
>
>
>
>  About org-inlinetask-export:
>
> ,----
> | Documentation:
> | What should be done with inlinetasks upon export?
> | Possible values:
> |
> | nil            Remove entirely
> | arrow          Insert heading in bold, preceeded by an arrow
> | arrow+content  Insert arrow and headline, add content below in an
> |                #+begin_example box (ugly, but works for now)
> |
> `----
>
>  Could you add that the „Remove entirely“ means „Remove entirely ...  
> just the header (but not the content)“?


The "content" of an inline task is not the text up to the next heading,
it usually is empty.

However, I have implemented a hackers solution, so that you can do


***************** TODO my inline task
                   DEADLINE...
                   PROPERTIES...
                   This is considered to be "content" of the
                   inline task, up to this line:
***************** END


I will make this clearer in the docs, the file header of
org-inlinetask.el does describe this.

- Carsten

>
>
> -- Daniel
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode


[-- Attachment #1.2: Type: text/html, Size: 2616 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode