[ANN] New lists definition

[ANN] New lists definition

[Nicolas Goaziou]

Hello,

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
  anymore.


* 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
  `org-list-to-html'.

  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:

  git@github.com:ngz/org-mode.git   branch: end-lists



Thanks for any feedback.

-- Nicolas

Re: [ANN] New lists definition

[Carsten Dominik]

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.

Thanks!

- Carsten

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

> Hello,
>
> 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
>  anymore.
>
>
> * 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
>  `org-list-to-html'.
>
>  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:
>
>  git@github.com: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.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

- Carsten

Re: [ANN] New lists definition

[Nicolas Goaziou]

If anyone wants to test it, new location is:

       git@github.com:ngz/org-mode-lists.git  branch: end-lists

It should be mostly on par with git head (which was not the case
before).

-- Nicolas