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
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
>
>
--
Carsten Dominik
Sterrenkundig Instituut "Anton Pannekoek"
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477
next prev parent 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
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 \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).