Re: Re: Bugs and suggestions for Org 4.70

[Bastien <bzg@altern.org>]

Carsten Dominik <dominik@science.uva.nl> 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