From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: Re: Bugs and suggestions for Org 4.70 Date: Fri, 13 Apr 2007 15:11:22 +0200 Message-ID: <87odlsto5h.fsf@bzg.ath.cx> References: <87k5willk1.fsf@bzg.ath.cx> <871wio1nl8.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HcLd6-0002Bh-U4 for emacs-orgmode@gnu.org; Fri, 13 Apr 2007 09:15:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HcLd2-00023Y-2G for emacs-orgmode@gnu.org; Fri, 13 Apr 2007 09:15:56 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HcLd1-00023I-Rp for emacs-orgmode@gnu.org; Fri, 13 Apr 2007 09:15:51 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HcLYk-00076j-AH for emacs-orgmode@gnu.org; Fri, 13 Apr 2007 09:11:26 -0400 Received: by ug-out-1314.google.com with SMTP id j3so535322ugf for ; Fri, 13 Apr 2007 06:11:25 -0700 (PDT) In-Reply-To: (Carsten Dominik's message of "Fri\, 13 Apr 2007 14\:38\:35 +0200") 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: emacs-orgmode@gnu.org Carsten Dominik writes: >> Mmhh. It may require a full rewriting of the lists parsing funcs; i >> didn't check your code for that, but having spent a good amount of time >> trying to implement something like this for my old bhl-mode, I know list >> parsing is always challenging. > > Well, in this case it is even impossible. How could > you distinguish the two? I guess the only way would be to require an empty > line before a new list item, but that is not acceptable. The approach i tried to implement was to delimit list environments before matching list items. For example "[\t ]*\([0-9]+\|[-+o]\) " would match a list item and this item will start a new list environment. Depending on (match-string 1), this list environment would be ordered, unordered, etc. Then the parser would try to find the end of the list environment before doing any conversion. The end of a list environment is often a new line starting with something else than tabs/whitespaces (this definition my not be sufficient, of course). Finally, within the list environment (a region), the parser would process each list item of a certain type, ignoring number in unordered lists and dashes in ordered lists ... but enough with speculations, i just wanted to sketch the idea. > Yes, interesting idea, implementation not very fast I am afraid, too many > other things on my plate right now. Thanks very much -- i think everyone agrees it's already difficult to follow the amazing pace of Org development ! -- Bastien