emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Carsten Dominik <carsten.dominik@gmail.com>
To: Piotr Zielinski <piotr.zielinski@gmail.com>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: Another GTD question.
Date: Fri, 20 Oct 2006 09:54:12 +0200	[thread overview]
Message-ID: <ca9412eed00c3c55f51e2c2316d03bba@gmail.com> (raw)
In-Reply-To: <3c12eb8d0610041011g22dda93ahf42608e6482f8c77@mail.gmail.com>

Hi Piotr,

thanks for sticking my head into that dark hole again :-)

Yes, the issues of headlines and plain list items have been bugging me 
for a long time, and am I glad to share my thoughts here - if only to 
grab this chance to organize them again.  Maybe some kind of solution 
will present itself eventually.

First of all, there is one subtle but critical structural difference
between the two concepts of outline headlines and items.

A headline starts a new subsection in a tree.  The body below the 
only ends at the next headline.  This is, in fact sometimes unfortunate,
because you can never go back to the level of text where you were.
For example:

    * level one
      some text
    ** item1
    ** item2
      And now I would like to continue with the thought started with 
"some text"
      but I cannot!

Items allow you to do just that

    * level one
      some text
      - item1
      - item2
      And here we continue after "some text"

I see this problem as the single most frustrating issue.  When I want to
record a TODO in the middle of some longish text, I ----- cannot reaaly
do so.  Therefore, allowing plain list items to become TODO entries is
something I *really* want.

I am not sure if *anyone* has actually noticed, but org-mode does not 
provide proper outlining support for plain list items.  If you set 
org-cycle-include-plain-lists, org-mode is cheating.  Items are 
temporarily (for the duration of an org-cycle command) treated as 
outline headings.  So in the example above, "And here we continue..." 
is actually treated as part of item2, betraying the true structure.

So one thing to be fixed is definitely this: proper cycle functionality 
for plain lists.  The reason why this is more difficult is that to find 
the end of an item, you cannot simply use a regular expression search 
for the next heading, you have to walk down line by line to find the 
next line with the proper indentation.  That is why the handling code 
for promotion etc is separate.

If you are looking for common handling code for things like promotion 
and demotion, you can go one level up and use function like 
org-shiftmetaleft, which do the proper dispatching.

About checklists and TODO items, I think that it makes sense to have 
both, one lightweight, and a more heavy one for use in agenda buffers.

But what would be nice is to have the possibility to make a plain list 
item a TODO entry.  I'd really like this.  Here are the problems with 

- A lot of the code handling TODOs was written early when there were
   no plain lists.  That code often explicitly assumes that TODO is 
   by the beginning of a line and a few stars.  Several regular 
   that are used all over the place implicitly make this assumption.  
This is
   just bad programming, but there you are, org-mode has been growing 
instead of
   having been designed from top to bottom.

- To make TODO in plain list items fully useful, I'd have to be able to
   apply tags to them.  However, other than headlines, the first line of 
   plain list item does not have a defined end, it can be filled and
   wrapped - so where would a good place be, where should TAGS be stored?
   Any good proposals?

- Another issue would be:  If I have a deadline or a scheduled item,
   should it refer to plain list item of which it is a part, or should
   it (as it does now) always refer to the nearest headline?  I guess
   the former would make more sense, greately increasing the complexity
   when scanning files for the agenda.  This would slow down creation
   of the agenda - maybe a price we could pay, I don't know.

The most important obstacle is that I would need something like 3
consecutive days with nothing else on my mind to make the changes
without introducing too many new bugs.  These I currently don't have,
they are very difficult to find.

Anyway, if there is ever a version 5 of org-mode, it will have these 
and require intensive testing. :-)

> 1. As opposed to headings, plain list items can consists of more than
>   one line.  On the other hand, they cannot be assigned tags or
>   marked TODO.  So, sometimes, one has to use one or the other.  This
>   is especially problematic, if you would like a TODO item below a
>   multi-line plain list item.  It would be great if the features of
>   headings and plain lists could be, at least to some extent,
>   combined.
> 2. Code duplication.  At the moment, AFAIK, you need to write separate
>   code for headings and plain lists.  Also, some features exist for
>   both but in different forms, for example, TODO/DONE for headings is
>   essentially the same as [ ]/[X] for plain lists.  I don't mind
>   having different representation for the same concept as long as
>   their share the same handling code.
> However, I feel that any attempt at integrating integrating headings
> and plain lists would require a significant rewrite.  Carsten, could
> you please comment on the main difficulties of such integration?
> Thanks,
> Piotr

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

  reply	other threads:[~2006-10-20 20:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-26 20:03 Another GTD question Alex Bochannek
2006-09-27 12:39 ` Charles Cave
2006-09-29 10:07   ` Christopher Kuettner
2006-09-30  5:25   ` Alex Bochannek
2006-09-30 11:28     ` Carsten Dominik
2006-10-01 14:41       ` Piotr Zielinski
2006-10-02  8:58         ` Chris Lowis
2006-10-14  4:44       ` Alex Bochannek
2006-10-01 23:54     ` Charles Cave
2006-10-14  4:53       ` Alex Bochannek
2006-09-27 14:18 ` Uwe Jochum
2006-10-04 16:11 ` Carsten Dominik
2006-10-04 17:11   ` Piotr Zielinski
2006-10-20  7:54     ` Carsten Dominik [this message]
2006-10-21 20:54       ` Christopher Kuettner
     [not found]         ` <b71b18520610211738s297f8f79u227d2ce32e10d2d9@mail.gmail.com>
2006-10-22  0:39           ` Eddward DeVilla
2006-10-23  6:10             ` Carsten Dominik
2006-10-23  7:21               ` Xiao-Yong Jin
2006-10-23  7:36                 ` Carsten Dominik
2006-10-23 20:30                   ` Xiao-Yong Jin
2006-10-23 13:24               ` Eddward DeVilla
2006-10-22 11:28         ` Pete Phillips
2006-10-05 13:01   ` Jason F. McBrayer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ca9412eed00c3c55f51e2c2316d03bba@gmail.com \
    --to=carsten.dominik@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=piotr.zielinski@gmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).