From: Carsten Dominik <carsten.dominik@gmail.com>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: [ANN] New lists definition
Date: Fri, 2 Jul 2010 11:56:35 +0200 [thread overview]
Message-ID: <2AA4C642-7AAF-4F46-BC5B-AA40B80F5EBE@gmail.com> (raw)
In-Reply-To: <87d3v6gqoc.wl%n.goaziou@gmail.com>
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
next prev parent reply other threads:[~2010-07-02 9:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-02 9:48 [ANN] New lists definition Nicolas Goaziou
2010-07-02 9:56 ` Carsten Dominik [this message]
2010-07-10 19:03 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2AA4C642-7AAF-4F46-BC5B-AA40B80F5EBE@gmail.com \
--to=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=n.goaziou@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.