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
headline
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
it:
- A lot of the code handling TODOs was written early when there were
no plain lists. That code often explicitly assumes that TODO is
preceded
by the beginning of a line and a few stars. Several regular
expressions
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
a
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
features
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
