Carsten Dominik <[EMAIL PROTECTED]> 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 _______________________________________________ Emacs-orgmode mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-orgmode
