Re: How to organize tasks about Worg within Worg documents (was: Re: [Worg] CSS improvements)

2024-03-30 Thread Ihor Radchenko
Adam Porter  writes:

> Using a normal heading for a task would "commandeer" the structure of 
> the document, which I think is a real problem.

Not really. If some section is incomplete, marking it "TODO" means that
it should be completed. And the details might be listed in the logbook
notes, for example. The section name itself does not necessarily have to
details what needs to be done.

We have multiple instances of such "TODO" items in WORG, some also
include comments on what should be done.

On the other hand, inlinetasks are more concrete and immediately mark
both where exactly and what needs to be done.

> ISTM that there are a few potential solutions:
>
> a. Using inline tasks...
>
> b. Using commented lines...
>
> c. Keeping tasks in a separate file...
> ...

"Thomas S. Dye"  writes:
> d. Keeping tasks under a heading held back from export...

> ...

Adam Porter  writes:

> Regardless of the decision, I do think that having this stated as a 
> policy somewhere would be helpful.
>
> WDYT?

I am not 100% sure if we need to constrain "TODO" items to one or
another style. Global todo list, marking existing sections as TODO, and
inlinetasks all may have their place depending on the situation.

The policy we may want to set is whether "TODO" keywords and notes
should be displayed to all the users. WORG has this set all over the
place - some TODO headings are marked to be not exported, some TODO
keywords are hidden via #+options: todo:nil, some notes are placed into
# comments.

May we have some kind of css-based toggle that will enable "developer
mode", revealing all the todo keywords, inlinetasks, and notes? Then, we
hide the "unfinished" parts from users by default, but let them see what
can be contributed?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



Re: How to organize tasks about Worg within Worg documents (was: Re: [Worg] CSS improvements)

2024-03-29 Thread Thomas S. Dye

Aloha all,

Adam Porter  writes:


On 3/29/24 04:48, Ihor Radchenko wrote:

Also, we may consider re-using inlinetask style for TODO: 
entries.


Rather than
#+begin_center
TODO: Even better, find a volunteer to maintain this 
information!

#+end_center

We can do

 TODO Even better, ...


That is a lot of asterisks, and I can't remember if inline 
tasks are
enabled by default.  :)  But in general, sure, I've no 
objection.  I
think that we should have some standard way to encode tasks 
within Worg

documents, regardless of what it is.

Yeah. And... we do.
https://orgmode.org/worg/worg-editing.html#orgce51883
Just a normal heading with TODO keyword.


I'm not sure that page really covers the question of how to 
present tasks about

the document within the same document.

Using a normal heading for a task would "commandeer" the 
structure of the

document, which I think is a real problem.

ISTM that there are a few potential solutions:

a. Using inline tasks.  Although not enabled by default, they 
seem to

   solve the problem pretty well.

b. Using commented lines, i.e.

 # TODO: Improve this information.

   Potentially we could even comment Org syntax within the file, 
   like:


 # * TODO Improve this information  :research_needed:

   Which encodes a normal Org heading but as a commented line, 
   so it 	
   wouldn't affect the structure of the document itself.  Of 
   course,
   that would not appear in the exported content, which is 
   probably not
   what we want; but those headings could still be collected, 
   e.g. by

   something like magit-todos.

c. Keeping tasks in a separate file.  We do already have the 
/todo.org
   file, so maybe this is what we should standardize on, i.e. 
   never
   putting tasks in the documents themselves but only in this 
   file.


Here's another potential solution that I find useful.

d. Keeping tasks under a heading held back from export.
I have a capture template that saves tasks about the document 
under a * Tasks :no-export: heading.  To keep the agenda sane, I 
don't add the file.  Instead, I show buffer local tasks with 
org-sidebar.


hth,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye



How to organize tasks about Worg within Worg documents (was: Re: [Worg] CSS improvements)

2024-03-29 Thread Adam Porter

On 3/29/24 04:48, Ihor Radchenko wrote:


Also, we may consider re-using inlinetask style for TODO: entries.

Rather than
#+begin_center
TODO: Even better, find a volunteer to maintain this information!
#+end_center

We can do

 TODO Even better, ...


That is a lot of asterisks, and I can't remember if inline tasks are
enabled by default.  :)  But in general, sure, I've no objection.  I
think that we should have some standard way to encode tasks within Worg
documents, regardless of what it is.


Yeah. And... we do.
https://orgmode.org/worg/worg-editing.html#orgce51883

Just a normal heading with TODO keyword.


I'm not sure that page really covers the question of how to present 
tasks about the document within the same document.


Using a normal heading for a task would "commandeer" the structure of 
the document, which I think is a real problem.


ISTM that there are a few potential solutions:

a. Using inline tasks.  Although not enabled by default, they seem to
   solve the problem pretty well.

b. Using commented lines, i.e.

 # TODO: Improve this information.

   Potentially we could even comment Org syntax within the file, like:

 # * TODO Improve this information  :research_needed:

   Which encodes a normal Org heading but as a commented line, so it
   wouldn't affect the structure of the document itself.  Of course,
   that would not appear in the exported content, which is probably not
   what we want; but those headings could still be collected, e.g. by
   something like magit-todos.

c. Keeping tasks in a separate file.  We do already have the /todo.org
   file, so maybe this is what we should standardize on, i.e. never
   putting tasks in the documents themselves but only in this file.

Regardless of the decision, I do think that having this stated as a 
policy somewhere would be helpful.


WDYT?