definition lists in org-mode

definition lists in org-mode

[Eddward DeVilla]

Hi all,

    I was wondering if anyone has a good way to embed definition list
into a plain list?  I think they'd be nifty.  OK, to be honest, I'm
trying to solve a problem specific to the way I do things and try to
make the solution seem more general.  Specifically, I'm using a
checkbox list to represent questions and little research items for
projects, like so:

* WORKING project
*** Investigate
     - [X] Can we do this -- Yes
       Bob say it's OK.
     - [ ] Do we need to do that

What I'm after here is a short statement of the question, possibly a
short statement of the answer, and the details under it so I can hide
the detail with visibility cycling on plain lists.  I already kind of
do this, but it goes horribly wrong when every I try to use ESC-Q to
re-wrap the item.  Don't get me wrong, I'd use a plain definition list
too if it were there.  This is just the nit that triggered all this.

Now first off, I know I could get most of what I want if I were to
switch to use outline entries instead of a plain list.  Heading don't
wrap.  That just seems wrong though.  It's a list.  I'd have to
replace the simple checkboxes with TODO keyword (which isn't so
unreasonable now that we can have multiple sequences) and I've been
using the outline entries to represent document sections, projects and
project sub headings.  If I start using todo items here, then I'll
have to start using something more complicated that the agenda-todo
list to get my projects and not the sub steps under them.  I could
just be I have to change how I do things.  That's not always bad.

I also know I could make the answer a sub-bullet.  I do it when I need
to, but it's not visually appealing.  It looks like a sub list when it
just being used to prevent word-wrap.  Likewise I sometimes use ':' if
the answer is one line.  This isn't so bad, if the answer is one line.
 If I ever become an avid user of the publishing feature, my thought
might change on that.

Getting back to definition lists, I recently saw rst
(reStructuredText) and found it interesting.  I like it's feature set
in general and I like that most of the features I like were already in
org-mode though maybe with a different syntax.  Two features that that
jump out at me were the definition lists and and the fields lists.  (I
also like the options list, but its obviously only for parameter
lists.  I guess I'm list oriented.)  Interestingly, the field lists
look like multi-live versions of org-mode's properties.

The definition list just looked like a nice way to represent my
outstanding/answered questions.  I've always thought that, but I
didn't realize they could solve my question formatting problem before
now.  They also looks like another great way to organize miscellaneous
info.  The rst definition list provide the term, the definition and
and optional list of classifiers on the term.  I didn't ever think of
having classifiers but I like them.

I guess this gets me to my question(s)?  Would anyone else find
definition lists useful?  Is there already a good way to do definition
list and/or my question lists that I'm just missing?  If having
definition lists is a good feature to add, how should it be added?
I'd like to see it be something that can be embedded in a plain list
but I could get by with it if that isn't reasonable.  I think we need
to be able to have regular text, sub-lists, tables, etc in the
definition though.  What syntax would work?  I was inspired by rst,
but I think rst is too different from org-mode to adopter their
syntax.

Sorry to bring this up right on the heels of properties.  That is
going to need to settle down some I'm sure.  Things just clicked when
I was reading upon rst and I figured I'd forget about it shortly.  For
those who are curious about what rst is, it looks like a plain text
readable mark that can be processed into other pretty print markups.
Seems, kind of like html, but comfortably readable in source form.   I
put links to it (and it's definition lists) below.

Edd

http://docutils.sourceforge.net/rst.html
http://docutils.sourceforge.net/docs/user/rst/quickstart.html
http://docutils.sourceforge.net/docs/user/rst/quickref.html#definition-lists
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#definition-lists

Re: definition lists in org-mode

[Rick Moynihan]

Eddward DeVilla wrote:
> ...
> Now first off, I know I could get most of what I want if I were to
> switch to use outline entries instead of a plain list.  Heading don't
> wrap.  That just seems wrong though.  It's a list.  I'd have to
> replace the simple checkboxes with TODO keyword (which isn't so
> unreasonable now that we can have multiple sequences) 

Out of curiousity this led me to try doing something like this:

(setq org-todo-keywords
       '((sequence "TODO" "|" "DONE")
         (type "[ ]" "|" "[X]")
         ))

i.e. Hack an implementation of checkboxes onto the todo-keywords 
feature.  Unfortunately it fails to work, the checkboxes aren't 
recognised as TODO keywords, and don't cycle properly.  Obviously also 
C-c can't be used to toggle them (as it adds tags) and these wouldn't be 
real checkboxes.

I'm not sure if there is a need for checkboxes in outlines.  When I 
started with org-mode this is something I felt like I needed; though 
this is likely due to me having previously used vim outliner for about a 
year.

Can anyone else see a use/need for this?

Vim outliner supports checkboxes as part of outlines, which allows 
folding etc...  It will also automatically check parent boxes when all 
child boxes are checked (is there a way for org-mode to do this???)

R.

Re: definition lists in org-mode

[Carsten Dominik]

On Jul 6, 2007, at 11:56, Rick Moynihan wrote:

> Eddward DeVilla wrote:
>> ...
>> Now first off, I know I could get most of what I want if I were to
>> switch to use outline entries instead of a plain list.  Heading don't
>> wrap.  That just seems wrong though.  It's a list.  I'd have to
>> replace the simple checkboxes with TODO keyword (which isn't so
>> unreasonable now that we can have multiple sequences)
>
> Out of curiousity this led me to try doing something like this:
>
> (setq org-todo-keywords
>       '((sequence "TODO" "|" "DONE")
>         (type "[ ]" "|" "[X]")
>         ))

Todo keywords need to be words currently, so you could do
something like

(setq org-todo-keywords
       '((sequence "TODO" "|" "DONE")
         (type "I_I" "|" "IXI")
         ))

> i.e. Hack an implementation of checkboxes onto the todo-keywords 
> feature.  Unfortunately it fails to work, the checkboxes aren't 
> recognised as TODO keywords, and don't cycle properly.  Obviously also 
> C-c can't be used to toggle them (as it adds tags) and these wouldn't 
> be real checkboxes.

Well, a two-state todo setup really *is* a checkbox, even if it does
not look like one.  About the only difference is the command you
use to toggle the state.

>
> I'm not sure if there is a need for checkboxes in outlines.  When I 
> started with org-mode this is something I felt like I needed; though 
> this is likely due to me having previously used vim outliner for about 
> a year.
>
> Can anyone else see a use/need for this?
>
> Vim outliner supports checkboxes as part of outlines, which allows 
> folding etc...  It will also automatically check parent boxes when all 
> child boxes are checked (is there a way for org-mode to do this???)

Not currently.  I have just implemented this for boolean properties
in column view (will be in 5.02), but not yet for TODO states.

- Carsten

Re: definition lists in org-mode

[Rick Moynihan]

Carsten Dominik wrote:
> 
> Well, a two-state todo setup really *is* a checkbox, even if it does
> not look like one.  About the only difference is the command you
> use to toggle the state.

I agree that they have the same number of states, but I think the 
differences between them are far greater than the command used to toggle 
state.

Obvious differences are that checkboxes don't show in the agenda and to 
my knowledge they can't be scheduled/deadlined etc...  They also 
(perhaps by convention more than anything else) indicate an ordered or 
unordered list, which outlines (at least for me) don't.

After thinking about it; I have on occasion wanted to schedule a 
checkboxed item into the agenda.  This said I'm not convinced supporting 
this is a good idea.  Does anyone else have any views?

R.

Re: definition lists in org-mode

[Carsten Dominik]

On Jul 6, 2007, at 12:45, Rick Moynihan wrote:

> Carsten Dominik wrote:
>> Well, a two-state todo setup really *is* a checkbox, even if it does
>> not look like one.  About the only difference is the command you
>> use to toggle the state.
>
> I agree that they have the same number of states, but I think the 
> differences between them are far greater than the command used to 
> toggle state.
>
> Obvious differences are that checkboxes don't show in the agenda and 
> to my knowledge they can't be scheduled/deadlined etc...  They also 
> (perhaps by convention more than anything else) indicate an ordered or 
> unordered list, which outlines (at least for me) don't.

Yes, of course you are right.  What I meant:  you can *use* TODO/DONE
exactly like a checkbox because it is a 2-state thing.

>
> After thinking about it; I have on occasion wanted to schedule a 
> checkboxed item into the agenda.  This said I'm not convinced 
> supporting this is a good idea.  Does anyone else have any views?

Checkbox items will not make it into the agenda.  At some time in the
past I wanted to make this happen, but this I have given up.

- Carsten

Re: definition lists in org-mode

[Eddward DeVilla]

On 7/6/07, Rick Moynihan <rick@calicojack.co.uk> wrote:
> After thinking about it; I have on occasion wanted to schedule a
> checkboxed item into the agenda.  This said I'm not convinced supporting
> this is a good idea.  Does anyone else have any views?

I'm usually for collapsing similar things in to one more flexible
thing, but there is a lot of meaning attached to something being a
todo entry in the outline as opposed to being a mere checkbox in a
list.  Some times it would be nice to steal a feature of one and use
it on the other, but the implicit difference is too useful I think to
collapse them.

I remember Carsten musing about this in the past and it sounds like
there were some implementation issues that made it unreasonable.  It
it were reasonable to implement and if it was just as easy to get the
current differences between todo entries and checkbox lists then I
guess I wouldn't be against it.  If everything became an outline entry
I would definitely need the '*' hiding though.  :-)

Edd

Re: definition lists in org-mode

[Rick Moynihan]

Eddward DeVilla wrote:
> On 7/6/07, Rick Moynihan <rick@calicojack.co.uk> wrote:
>> After thinking about it; I have on occasion wanted to schedule a
>> checkboxed item into the agenda.  This said I'm not convinced supporting
>> this is a good idea.  Does anyone else have any views?
> 
> I'm usually for collapsing similar things in to one more flexible
> thing, but there is a lot of meaning attached to something being a
> todo entry in the outline as opposed to being a mere checkbox in a
> list.  Some times it would be nice to steal a feature of one and use
> it on the other, but the implicit difference is too useful I think to
> collapse them.
> 

Agreed.  My gut feeling is that they fulfill largely different purposes. 
  The problem is that I tend to make a decision to structure something 
with lists & checkboxes, and later on discover I want an item in the 
list to appear inside the agenda.

Duplicating this into an outline is one way to achieve this; but this 
presents several problems:

- Your files rapidly become less DRY (Don't Repeat Yourself) and harder 
to maintain.
- You loose the context of the list (i.e. any notion of sequence)

I guess these are the sorts of use-cases/trade-offs we should be 
discussing as part of David O'Toole's community writing suggestion.  Is 
anything happening with this yet?

R.

Re: definition lists in org-mode

[Carsten Dominik]

On Jul 6, 2007, at 18:28, Rick Moynihan wrote:

> Agreed.  My gut feeling is that they fulfill largely different 
> purposes.  The problem is that I tend to make a decision to structure 
> something with lists & checkboxes, and later on discover I want an 
> item in the list to appear inside the agenda.

In such a case I usually make the headline above the checkbox
list a TODO and have that show up in the agenda.  From there
it is only one or two TAB presses to the checkboxes.

- Carsten

Suggestion: Jump points

[Rick Moynihan]

Carsten Dominik wrote:
> 
> On Jul 6, 2007, at 18:28, Rick Moynihan wrote:
> 
>> Agreed.  My gut feeling is that they fulfill largely different 
>> purposes.  The problem is that I tend to make a decision to structure 
>> something with lists & checkboxes, and later on discover I want an 
>> item in the list to appear inside the agenda.
> 
> In such a case I usually make the headline above the checkbox
> list a TODO and have that show up in the agenda.  From there
> it is only one or two TAB presses to the checkboxes.
> 
> - Carsten

I too have tried this, but it means if you start editing your lists (and 
if they're numbered) the list numbers get reset which can be annoying.

I sometimes have quite long lists within outlines, and I guess the 
problem is that I know what project I want to work on yet I want to 
quickly find the item within it which I'd previously identified as 
tackling next.  Sometimes when returning to such a list it takes me a 
while to figure out which task I was supposed to tackling next.

So here's a suggestion.  Why not support jump points (or jump lines), 
which would be essentially be a syntactic marker that would tell 
org-mode to jump to a specific line within an outline when visiting from 
the agenda e.g. via follow mode.

* My main project outline.
   blah blah blah...
   ...

   - [ ] do something
   - [ ] do this ++
   - [ ] do something else
   ...

I'm not too bothered about the syntax, but here the ++ indicates the 
line which the point should be placed on within that outline.

Some simple interactive commands could be written to reset the jump 
point to a new line within that outline.  This would simply remove any 
existing jump-point and insert a new one at the point.  Naturally this 
command might want to alert you about jump-point removal, and if there 
were multiple points (accidentally) defined within a single outline it 
might warn you of this, perhaps moving you into an interactive mode to 
clean them up and set the point to where you wanted.

Is this something people might find useful?  I personally find I spend a 
lot of time trying to re-acquire my previous context within a particular 
task, something like this might help.

Actually, after thinking about this; I realise that Emacs has bookmarks 
(a feature I've not yet put to use) perhaps a better idea would be to 
integrate these with org-mode and visiting the file via the agenda?

What do people think?

R.

Re: Suggestion: Jump points

[Eddward DeVilla]

On 7/11/07, Rick Moynihan <rick@calicojack.co.uk> wrote:
> Is this something people might find useful?  I personally find I spend a
> lot of time trying to re-acquire my previous context within a particular
> task, something like this might help.
>
> Actually, after thinking about this; I realise that Emacs has bookmarks
> (a feature I've not yet put to use) perhaps a better idea would be to
> integrate these with org-mode and visiting the file via the agenda?
>
> What do people think?

I'm not sure I understand it.  You place a token (you were using ++)
in the body under an outline item.  Then when you select the item from
agenda, instead of putting the cursor on that headline, it will look
for (the first?) line with that token in it's subtree.  If the token
does not exist in the subtree it just places the cursor on the
heading.  Is this what you are suggesting?  (If not then the rest of
my comment may be off.)

First, I avoid losing context in a different way.  I have one emacs
session that is always running to take care of 'administrative matter'
and it is were I do most of my org-mode/project planning and tracking.
 When I'm in the middle of doing something with a project, I have it's
tree open in an indirect buffer.  I have one frame with just agenda's
todo list in it for reporting and another frame with three windows (or
so) so I can look at a few things at once.  Since each project is in
it's own buffer, I can get context just be where I left the cursor.
For my uses, what I would love is a way to have org-mode remember how
a subtree was folded so I could hide a subtree and then reopen it
later with all of it children exposed or hidden as they were before.
I like to use hiding for context in a project, but I get by without
it.

Getting back to your suggestion, I have an idea.  First pick a good
token.  I don't care for ++ because it means something in C code, but
I think you could get a way with picking your own token here.  Next, I
wonder if there is a search subtree?  I didn't see it in on a quick
search of the manual, but I could have missed it if it exists.  If it
doesn't exist, I think it might be handy here and in other places.
With a subtree search, you could search out the token after agenda
takes you to the project tree.  You could make a custom key binding to
search for you token.  Also, if there is a hook that runs after agenda
takes you to a heading, you might be able to put this search there.

That all depends on a few things.  Does subtree search exist or should
it?  Is a key binding good enough for a find-next-jump-point function?
 Is there (or should there be) a hook that runs after agenda takes you
to a heading?

Edd

Re: Suggestion: Jump points

[Rick Moynihan]

Eddward DeVilla wrote:
> On 7/11/07, Rick Moynihan <rick@calicojack.co.uk> wrote:
>> Is this something people might find useful?  I personally find I spend a
>> lot of time trying to re-acquire my previous context within a particular
>> task, something like this might help.
>>
>> Actually, after thinking about this; I realise that Emacs has bookmarks
>> (a feature I've not yet put to use) perhaps a better idea would be to
>> integrate these with org-mode and visiting the file via the agenda?
>>
>> What do people think?
> 
> I'm not sure I understand it.  You place a token (you were using ++)
> in the body under an outline item.  Then when you select the item from
> agenda, instead of putting the cursor on that headline, it will look
> for (the first?) line with that token in it's subtree.  If the token
> does not exist in the subtree it just places the cursor on the
> heading.  Is this what you are suggesting?  (If not then the rest of
> my comment may be off.)

Apologies for my poor explanation but yes this is precisely what I'm 
talking about.

> First, I avoid losing context in a different way.  I have one emacs
> session that is always running to take care of 'administrative matter'
> and it is were I do most of my org-mode/project planning and tracking.
>  When I'm in the middle of doing something with a project, I have it's
> tree open in an indirect buffer.  I have one frame with just agenda's
> todo list in it for reporting and another frame with three windows (or
> so) so I can look at a few things at once.  Since each project is in
> it's own buffer, I can get context just be where I left the cursor.
> For my uses, what I would love is a way to have org-mode remember how
> a subtree was folded so I could hide a subtree and then reopen it
> later with all of it children exposed or hidden as they were before.
> I like to use hiding for context in a project, but I get by without
> it.

I've never knowingly used indirect buffers, and I'll certainly take a 
look at them as I can see how I might find them useful.  I frequently 
use org-narrow-to-subtree which I find useful for hiding irrelevant 
details.  Incidentally it would be nice to be able to set follow mode to 
automatically narrow to the current agenda selection.

I've personally taken to using follow mode, and having my org-mode Emacs 
session split vertically into two panes, with the agenda on the right. 
I then navigate my org file via the open agenda buffer with follow mode. 
  I'm guessing that your method doesn't (easily) allow you to jump from 
the agenda to your projects indirect buffer, which is a feature I quite 
like using.

> Getting back to your suggestion, I have an idea.  First pick a good
> token.  I don't care for ++ because it means something in C code, but
> I think you could get a way with picking your own token here.  Next, I
> wonder if there is a search subtree?  I didn't see it in on a quick
> search of the manual, but I could have missed it if it exists.  If it
> doesn't exist, I think it might be handy here and in other places.
> With a subtree search, you could search out the token after agenda
> takes you to the project tree.  You could make a custom key binding to
> search for you token.  Also, if there is a hook that runs after agenda
> takes you to a heading, you might be able to put this search there.
> 
> That all depends on a few things.  Does subtree search exist or should
> it?  Is a key binding good enough for a find-next-jump-point function?
>  Is there (or should there be) a hook that runs after agenda takes you
> to a heading?

Good suggestions, and it did occur to me that I might be able to 
implement this as a personal extension to org-mode, and I'm sure for 
someone with good Emacs fu, this would take 5 minutes.  For me?  Well it 
might be a nice motivating exercise to learn some more elisp :)

Anyway, it's always good to have a discussion about how people are using 
and extending org-mode.

R.

Re: Suggestion: Jump points

[Eddward DeVilla]

On 7/11/07, Rick Moynihan <rick@calicojack.co.uk> wrote:
> Apologies for my poor explanation but yes this is precisely what I'm
> talking about.

You probably explained it well.  I'm pretty thick at times.

> I've never knowingly used indirect buffers, and I'll certainly take a
> look at them as I can see how I might find them useful.  I frequently
> use org-narrow-to-subtree which I find useful for hiding irrelevant
> details.  Incidentally it would be nice to be able to set follow mode to
> automatically narrow to the current agenda selection.

I couldn't live without C-u,C-c,C-x,b.  :-)

> I've personally taken to using follow mode, and having my org-mode Emacs
> session split vertically into two panes, with the agenda on the right.
> I then navigate my org file via the open agenda buffer with follow mode.
>   I'm guessing that your method doesn't (easily) allow you to jump from
> the agenda to your projects indirect buffer, which is a feature I quite
> like using.

I like the idea of using agenda as a browser.  I like have multiple
windows open in a frame to look at multiple files (or projects) side
by side at once.  Early on, agenda got a little crazy if you used it
with multiple windows and I used to run org in the same session where
I did all my source editing.  I'd easily have 5 or more windows in a
frame.  I'll have to see if it will work if I have just two windows in
the agenda frame.

> Good suggestions, and it did occur to me that I might be able to
> implement this as a personal extension to org-mode, and I'm sure for
> someone with good Emacs fu, this would take 5 minutes.  For me?  Well it
> might be a nice motivating exercise to learn some more elisp :)

The key binding would be easy if there were a search subtree function.
 Looking through org.el, I'm thinking there isn't.  Likewise, there
doesn't appear to be a hook for agenda following.  I could be wrong as
I'm still getting to know lisp and org.el.

Edd

Re: Suggestion: Jump points

[Carsten Dominik]

On Jul 11, 2007, at 16:51, Eddward DeVilla wrote:
>
> That all depends on a few things.  Does subtree search exist or should
> it?  Is a key binding good enough for a find-next-jump-point function?
> Is there (or should there be) a hook that runs after agenda takes you
> to a heading?

Org does search subtree all the time, but there is indeed no dedicated
function yet.  I'll make one.  But in the mean time,
this is all it takes:

(let ((end (save-excursion (org-end-to-subtree t))))
	(re-search-forward SEARCH-REGEXP end))

- Carsten



--
Carsten Dominik
Sterrenkundig Instituut "Anton Pannekoek"
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477

Re: Suggestion: Jump points

[Scott Jaderholm]

On 7/11/07, Rick Moynihan <rick@calicojack.co.uk> wrote:
> So here's a suggestion.  Why not support jump points (or jump lines),
> which would be essentially be a syntactic marker that would tell
> org-mode to jump to a specific line within an outline when visiting from
> the agenda e.g. via follow mode.
>
> * My main project outline.
>    blah blah blah...
>    ...
>
>    - [ ] do something
>    - [ ] do this ++
>    - [ ] do something else

Hi Rick,

I'm guessing you have a really good reason for organizing your project
using lists and check boxes instead of TODOs and headings, in which
case this email isn't really useful--but, in the extremely unlikely
event that you don't, I thought I'd note how this becomes a non-issue
if you organize your work in the following way:

* My main project outline
** TODO do something
** NEXT do this
   SCHEDULED: <2007-07-12 Thu>
** do something else

If you schedule individual tasks, instead of projects, then the agenda
will take you right to your next item. If you schedule projects, then
it's easy to see what is the next item to be done because it says
NEXT.

Cheers,
Scott

Re: Suggestion: Jump points

[Rick Moynihan]

Scott Jaderholm wrote:
> On 7/11/07, Rick Moynihan <rick@calicojack.co.uk> wrote:
> Hi Rick,
> 
> I'm guessing you have a really good reason for organizing your project
> using lists and check boxes instead of TODOs and headings, in which

Don't count on it :)

> case this email isn't really useful--but, in the extremely unlikely
> event that you don't, I thought I'd note how this becomes a non-issue
> if you organize your work in the following way:
> 
> * My main project outline
> ** TODO do something
> ** NEXT do this
>    SCHEDULED: <2007-07-12 Thu>
> ** do something else

Thanks for the suggestion, I can see how this structure might be better 
suited for this sort of thing, and I do structure much of my org-file 
like this, though I hadn't thought of using a NEXT keyword.

I think my problem is that I sometimes find myself torn between outlines 
  and lists/checkboxes.  Lists/checkboxes have some advantages over 
outlines, though outlines are obviously more powerful.  I find I tend to 
use lists/checkboxes for smaller tasks which are best done in sequence, 
and where I want to track the % of progress.  Is this possible with 
outlines?

e.g.

1. [X] Do this first
2. [X] Do this second
3. [ ] Do this collection of tasks third but in any order [66%]
    - [X] foo
    - [ ] bar
    - [X] baz
4. [ ] Do this fourth

I might well take your suggestions on board though and see how I get on. 
  This said I can still think of situations where I might want 
follow-mode in the agenda to move the point directly to a 
bookmarked\tagged jump-point within an outline.  For example, I often 
write quite extensive notes within an outline heading, and sometimes it 
might be nice to jump straight to where you were editing.

R.

Re: Suggestion: Jump points

[Daniel J. Sinder]

On 07/11/2007 08:28 AM, Scott Jaderholm wrote:
> On 7/11/07, Rick Moynihan <rick@calicojack.co.uk> wrote:
>> So here's a suggestion.  Why not support jump points (or jump lines),
>> which would be essentially be a syntactic marker that would tell
>> org-mode to jump to a specific line within an outline when visiting from
>> the agenda e.g. via follow mode.
>>
>> * My main project outline.
>>    blah blah blah...
>>    ...
>>
>>    - [ ] do something
>>    - [ ] do this ++
>>    - [ ] do something else
> 
> Hi Rick,
> 
> I'm guessing you have a really good reason for organizing your project
> using lists and check boxes instead of TODOs and headings, in which
> case this email isn't really useful--but, in the extremely unlikely
> event that you don't, I thought I'd note how this becomes a non-issue
> if you organize your work in the following way:
> 
> * My main project outline
> ** TODO do something
> ** NEXT do this
>   SCHEDULED: <2007-07-12 Thu>
> ** do something else
> 
> If you schedule individual tasks, instead of projects, then the agenda
> will take you right to your next item. If you schedule projects, then
> it's easy to see what is the next item to be done because it says
> NEXT.

If I may jump in here, I'll add that go a little further to aid with
multiple projects.  I use two SEQ_TODO's like this:
#+SEQ_TODO:  TODO NEXT INPROGRESS WAITING | DONE CANCELED
#+SEQ_TODO:  PROJECT | COMPLETE

Then my project trees (all in one file) look like this:
* PROJECT My main project outline  :Work:
** TODO do something
** NEXT do this
   SCHEDULED: <2007-07-12 Thu>
** TODO do something else
** WAITING someone else is working on this
** INPROGRESS Here's what I'm currently working on
* PROJECT Another project
** NEXT next for another project
** TODO do anothre thing

When I generate agendas, I can do a tags/TODO agenda on
'Work/PROJECT|NEXT'.  Through indentation, the agenda visually
groups everything so I can see what's next for each project.  It
looks something like this.

PROJECT My main project outline                    :Work:
.NEXT do this
PROJECT Another project                            :Work:
.NEXT next for another project

This is great for a weekly review, to make certain all project have
a defined NEXT action.

A tags/TODO agenda that includes all TODO keywords will also group
tasks by project, but will give broader scope.

(One down-side to this is that M-S-<RET> on the first TODO after a
PROJECT headline inserts a new PROJECT rather than a new TODO, which
I have to then change.  The alternative, of course, is to add at the
end of the list for a project.

Regards,
Dan

Re: Suggestion: Jump points

[Carsten Dominik]

Hi Rick,

I have not found a good and general way to introduce the feature
you are asking for. In 5.08 there will be a new hook
`org-agenda-after-show-hook'.  This hook will be run after
the agenda has exposed an entry, either by an interactive
command like TAB or RET, or by follow mode.  I guess you
could try to get a function in there that will search for
your marker, something like (untested)

(defun find-ricks-marker ()
   "FIXME"
   (let ((pos (point)) beg end)
     (org-back-to-heading t)
     (setq beg (point))
     (org-end-of-subtree t)
     (setq end (point))
     (goto-char beg)
     (if (re-search-forward "\\+\\+" end t)
	(goto-char (match-beginning 0))
       (goto-char pos))))

Hope this helps.

- Carsten

On Jul 11, 2007, at 13:52, Rick Moynihan wrote:

> Carsten Dominik wrote:
>> On Jul 6, 2007, at 18:28, Rick Moynihan wrote:
>>> Agreed.  My gut feeling is that they fulfill largely different 
>>> purposes.  The problem is that I tend to make a decision to 
>>> structure something with lists & checkboxes, and later on discover I 
>>> want an item in the list to appear inside the agenda.
>> In such a case I usually make the headline above the checkbox
>> list a TODO and have that show up in the agenda.  From there
>> it is only one or two TAB presses to the checkboxes.
>> - Carsten
>
> I too have tried this, but it means if you start editing your lists 
> (and if they're numbered) the list numbers get reset which can be 
> annoying.
>
> I sometimes have quite long lists within outlines, and I guess the 
> problem is that I know what project I want to work on yet I want to 
> quickly find the item within it which I'd previously identified as 
> tackling next.  Sometimes when returning to such a list it takes me a 
> while to figure out which task I was supposed to tackling next.
>
> So here's a suggestion.  Why not support jump points (or jump lines), 
> which would be essentially be a syntactic marker that would tell 
> org-mode to jump to a specific line within an outline when visiting 
> from the agenda e.g. via follow mode.
>
> * My main project outline.
>   blah blah blah...
>   ...
>
>   - [ ] do something
>   - [ ] do this ++
>   - [ ] do something else
>   ...
>
> I'm not too bothered about the syntax, but here the ++ indicates the 
> line which the point should be placed on within that outline.
>
> Some simple interactive commands could be written to reset the jump 
> point to a new line within that outline.  This would simply remove any 
> existing jump-point and insert a new one at the point.  Naturally this 
> command might want to alert you about jump-point removal, and if there 
> were multiple points (accidentally) defined within a single outline it 
> might warn you of this, perhaps moving you into an interactive mode to 
> clean them up and set the point to where you wanted.
>
> Is this something people might find useful?  I personally find I spend 
> a lot of time trying to re-acquire my previous context within a 
> particular task, something like this might help.
>
> Actually, after thinking about this; I realise that Emacs has 
> bookmarks (a feature I've not yet put to use) perhaps a better idea 
> would be to integrate these with org-mode and visiting the file via 
> the agenda?
>
> What do people think?
>
> R.
>
>

--
Carsten Dominik
Sterrenkundig Instituut "Anton Pannekoek"
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477

Re: definition lists in org-mode

[Eddward DeVilla]

On 7/6/07, Carsten Dominik <dominik@science.uva.nl> wrote:
> Todo keywords need to be words currently, so you could do
> something like
>
> (setq org-todo-keywords
>        '((sequence "TODO" "|" "DONE")
>          (type "I_I" "|" "IXI")
>          ))

Cool.  I'll have to remember that.  I can get back my old states _, v
& X.  :-)  I could just switch to using todo entries and tag my
projects for agenda.

> Well, a two-state todo setup really *is* a checkbox, even if it does
> not look like one.  About the only difference is the command you
> use to toggle the state.

Agenda is oblivious to checkboxes.  Checkboxes count toward the
progress tokens.  And todo entries are pretty colors.  :-)  All are
little things and probably not too hard to deal with.

> Not currently.  I have just implemented this for boolean properties
> in column view (will be in 5.02), but not yet for TODO states.

Cool!

Edd

Re: definition lists in org-mode

[Eddward DeVilla]

On 7/6/07, Rick Moynihan <rick@calicojack.co.uk> wrote:
> Out of curiousity this led me to try doing something like this:
>
> (setq org-todo-keywords
>        '((sequence "TODO" "|" "DONE")
>          (type "[ ]" "|" "[X]")
>          ))
>
> i.e. Hack an implementation of checkboxes onto the todo-keywords
> feature.  Unfortunately it fails to work, the checkboxes aren't
> recognised as TODO keywords, and don't cycle properly.  Obviously also
> C-c can't be used to toggle them (as it adds tags) and these wouldn't be
> real checkboxes.

I also tied this, coming from hnb and also trying to match the free
form note I made prior to discovering outliners.  I guess that's why
I'm a big fan of folding plain lists.  I like the TODO entries, but
they are for complicated things like projects  or things that should
stand out, like a section header.  I use the lists for littler tasks
like "edit file", "find this answer" or "run regressions".

> I'm not sure if there is a need for checkboxes in outlines.  When I
> started with org-mode this is something I felt like I needed; though
> this is likely due to me having previously used vim outliner for about a
> year.

  Well I use the plain lists and checkboxes in my outlines.  I use the
progrss tokens in parent list items and section header outline
entries.  The org outline entries and plain list entries are different
and I don't think that is bad.  That serve different purposes well.
Agenda is aware of outline entries and ignores the plain lists.  Plain
lists are simpler and less decorated.  Have both checkboxes and TODO
sequences on outline entries feels a little cluttered.

> Vim outliner supports checkboxes as part of outlines, which allows
> folding etc...

  There is an option to allow folding in plain lists.  I can't live without it.

> It will also automatically check parent boxes when all
> child boxes are checked (is there a way for org-mode to do this???)

hnb would replace checkbox with a percentage in parent nodes.
Org-mode have two tokens that you can put in an outline entry or in
plain lists (and maybe other places?) that will gave the percentage or
ratio of completed checkboxes.  '[/]' & '[%]'  It updates them when
you create or check a checkbox using an org binding or function.  It
only totals for the current outline entry and not sub entries.  In a
plain list it will represent the sub-tree

Edd

Re: definition lists in org-mode

[Carsten Dominik]

On Jul 6, 2007, at 0:01, Eddward DeVilla wrote:
>
> What I'm after here is a short statement of the question, possibly a
> short statement of the answer, and the details under it so I can hide
> the detail with visibility cycling on plain lists.  I already kind of
> do this, but it goes horribly wrong when every I try to use ESC-Q to
> re-wrap the item.  Don't get me wrong, I'd use a plain definition list
> too if it were there.  This is just the nit that triggered all this.

It it is only the wrapping, you could simply hack org-fill-paragraph, 
for
example like this:

(defun org-fill-paragraph (&optional justify)
   "Re-align a table, pass through to fill-paragraph if no table."
   (let ((table-p (org-at-table-p))
	(table.el-p (org-at-table.el-p)))
     (cond ((equal (char-after (point-at-bol)) ?*) t) ; skip headlines
	  ((org-at-item-p) t)
	  ((org-in-item-p)
	   (save-excursion
	     (save-restriction
	       (org-beginning-of-item)
	       (beginning-of-line 2)
	       (narrow-to-region (point) (point-max))
	       (fill-paragraph nil))))
	  (table.el-p t)                             ; skip table.el tables
	  (table-p (org-table-align) t)              ; align org-mode tables
	  (t nil))))                                 ; call paragraph-fill

Our you could play with the variables paragraph-start, 
paragraph-separate,
and auto-fill-inhibit-regexp.

But I guess you are really after definition lists.  Muse uses

term :: definition

which is not a bad syntax, I guess.

- Carsten

Re: definition lists in org-mode

[Eddward DeVilla]

On 7/6/07, Carsten Dominik <dominik@science.uva.nl> wrote:
> It it is only the wrapping, you could simply hack org-fill-paragraph,
> for
> example like this:

Thanks.  I'll have to play with it.

> But I guess you are really after definition lists.

I actually like definition lists, but sadly the real nit I'm try to
address is the wrapping.  Maybe I have hack something where a ':' (or
some such) at the end of the first  line of a list entry prevents the
wrap.  In org-mode it would look like a definition list item and it
could be recognized for publishing since definition list are actually
nice.

  - term : (qualifier :)*
    definition

  - [ ] question : (brief answer)*
    long winded explaination & response

Edd

Re: definition lists in org-mode

[Carsten Dominik]

On Jul 6, 2007, at 17:43, Eddward DeVilla wrote:
>
>> But I guess you are really after definition lists.
>
> I actually like definition lists, but sadly the real nit I'm try to
> address is the wrapping.  Maybe I have hack something where a ':' (or
> some such) at the end of the first  line of a list entry prevents the
> wrap.  In org-mode it would look like a definition list item and it
> could be recognized for publishing since definition list are actually
> nice.

We already have "\\" to force a line break, at least for export.
I guess it is only consistent when I make the line
wrapping commands honor this as well.  Probably in 5.02.


  - [ ] question : (brief answer)   \\
    long winded explaination & response

- Carsten