From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Another GTD question. Date: Fri, 20 Oct 2006 09:54:12 +0200 Message-ID: References: <76f7cd71190bcff68e57e71d163fe49f@science.uva.nl> <3c12eb8d0610041011g22dda93ahf42608e6482f8c77@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gb1Pz-0008Mn-4i for emacs-orgmode@gnu.org; Fri, 20 Oct 2006 16:56:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gb1Py-0008KE-8W for emacs-orgmode@gnu.org; Fri, 20 Oct 2006 16:56:38 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gb1Py-0008Je-28 for emacs-orgmode@gnu.org; Fri, 20 Oct 2006 16:56:38 -0400 Received: from [64.233.182.184] (helo=nf-out-0910.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gb1Px-0006fG-BS for emacs-orgmode@gnu.org; Fri, 20 Oct 2006 16:56:37 -0400 Received: by nf-out-0910.google.com with SMTP id q29so1764156nfc for ; Fri, 20 Oct 2006 13:56:35 -0700 (PDT) In-Reply-To: <3c12eb8d0610041011g22dda93ahf42608e6482f8c77@mail.gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Piotr Zielinski Cc: emacs-orgmode 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