[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] [ANN] New lists definition

From: Carsten Dominik
Subject: Re: [Orgmode] [ANN] New lists definition
Date: Fri, 2 Jul 2010 11:56:35 +0200

Hi Nicolas,

this sounds interesting! Take you time in cleaning it up and testing it - we will not include this before release 7, to big a change for this moment in time.


- Carsten

On Jul 2, 2010, at 11:48 AM, Nicolas Goaziou wrote:


I'd like to announce an attempt to change the internals of lists in
org-mode. Now a list is still started by `org-item-re' but is now
ended by `org-list-end-re', which defaults to one or two blank lines,
depending on the value of `org-empty-line-terminates-plain-lists'.
Obviously, headings still terminate lists, too.

Please note that `org-item-re' is not valid inside org-blocks or latex
blocks. So you can perfectly have a #+begin_example block with 4
consecutive blank lines inside: it will not break your current list.

* So what are the benefits of it ?

 Well, now indentation is handled by org-mode and not by the user. It
 means you can C-j and get the right indentation anytime, or
 indent-region without worries – how many times did I indent buffer
 and saw everything past a certain point was wrong because of a list?
 `org-indent-mode' should also work great with it.

As a consequence, you can have two lists with different bullets – i.e.
 "-" and "1." — only separated by blank lines, that will not interfere
 with each other.

 I also improved handling of lists starting with "*", by deleting
 org-item-beginning-re. Such lists should export correctly in latex
 now. On the same topic, I also fixed an inconsistency of
`org-indent-item-tree' that would permit an item to get outdented past
 the top-level item of the list – very problematic in *-lists, as "*"
 could hit column 0 and become an heading.

 I also squashed a few bugs. Thus, `org-list-to-html' won't enclose
 any item within "<dd>" and "</dd>" even for non-descriptive lists

* Is that all ?

 Hopefully yes. I tried to keep the same behavior as before in all
 others aspects of lists. `org-move-item-up',
 `org-beginning-of-item-list', etc. should do what you would expect
 from them. Thus, I hope it will not break anything.

 Most of the changes are internal. I rewrote some basic functions and
 patched most of the others. I removed useless functions only when I
 was sure they weren't used anywhere else in org or contrib
 directories. I also reorganized org-list.el, because functions of
 the same family – i.e. navigation within a list – were scattered all
 over the file, and it was difficult to have a good overview of it.
 But I keep an "unorganized" version of the changes, just in case.

* What if I don't like 2 blank lines as a list separator ?

 Well, that's the good thing of it. It is not hard-coded. It's just a
 matter of replacing "\n[ \t]*\n\\([ \t]*\n\\)+" line in
 `org-list-end-re' with, for example, "\n[ \t]*  [ \t]*\n" (" " can
 be obtained with C-x 8 RET a0 RET).

 The limitation of it is that exporters must see them (to interpret
 them) and must remove them before exporting if they are visible. But
 those functionalities shouldn't be hard to code into org-exp.el if
 there really is a need for them.

* What is not working yet ?

 Every exporter using the tools provided by org-list.el – namely
 `org-list-parse-list', `org-list-to-generic', `org-list-to-latex'
 among others — should recognize list-enders. Alas, org-html.el
 provides its own list interpreter, so there is no benefit from the
 new definition, though it still exports as before. I have ideas
 about it and started to implement something, but it is more a hack
 than anything else. I just wish org-html.el would use

 There are certainly many things that I broke in the process. That's
 why, if this idea is appealing, I'd appreciate some testers. I have
 run many basic tests – which all seem satisfying – in the past few
 days, but there's nothing like real-life confrontation. I'm open to
 any suggestion or criticism. If you think I spent too much time on
 insignificant details, do not hesitate to say it too.

* So, where can I test it ?

 You can find it at:

 address@hidden:ngz/org-mode.git   branch: end-lists

Thanks for any feedback.

-- Nicolas

Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.

- Carsten

reply via email to

[Prev in Thread] Current Thread [Next in Thread]