From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Carsten Dominik <carsten.dominik@gmail.com>
Cc: Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: Request for opinions: [ANN] List improvement v.2o
Date: Fri, 20 Aug 2010 02:56:54 +0200 [thread overview]
Message-ID: <87zkwiyucp.wl%n.goaziou@gmail.com> (raw)
In-Reply-To: <17A93AC0-1896-481D-B2E9-E1DA5879A1D0@gmail.com>
Hello,
I introduced in this branch a new variable, namely
`org-list-ending-method', to allow fine-grained control on list
endings.
Here is its docstring:
Determine where plain lists should end.
Valid values are symbols 'regexp, 'indent or 'both.
When set to 'regexp, Org will look into two variables,
`org-empty-line-terminates-plain-lists' and the more general
`org-list-end-regexp', to know what will end lists. This is the
default value.
When set to 'indent, indentation of the last non-blank line will
determine if point is in a list. If that line is less indented
than the previous item in the section, if any, list has ended.
When set to 'both, each of the preceding methods must confirm
that point is in a list.
So, to sum it up, if you want to keep same behaviour as before, while
still having bug fixes and most improvements, there are two cases:
- if you had `org-empty-line-terminates-plain-lists' to nil, you only
need to set `org-list-ending-method' to 'indent.
- if you had `org-empty-line-terminates-plain-lists' to t, you need to
keep it to t, and to set `org-list-ending-method' to 'both (because
you still end your lists with indentation, but you allow a blank
line, that is a regexp, to also end it).
My advice is still to keep 'regexp (default value) and end lists with
a well defined pattern, for two reasons:
1. It is faster. Indent method has to walk each line of the list to
find its boundaries, while regexp method is a two searches trip,
independently from the size of the list.
2. It is more consistent. With indent method, inserting a new line,
indenting, then inserting some chars on the one hand, and inserting
a new line, some chars, then indenting on the other hand won't give
similar results at all.
But now, there is at least the opportunity to not follow my advice!
Regards,
-- Nicolas
next prev parent reply other threads:[~2010-08-20 0:57 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-22 21:08 [ANN] List improvement v.2 Nicolas Goaziou
2010-07-23 7:55 ` Nicolas Goaziou
2010-07-23 16:58 ` Eric Schulte
2010-07-25 16:17 ` Nicolas Goaziou
2010-07-27 12:51 ` Scot Becker
2010-07-27 14:50 ` Daniel Martins
2010-07-27 17:49 ` Nicolas Goaziou
2010-08-15 6:26 ` Carsten Dominik
2010-08-15 8:45 ` Glauber Alex Dias Prado
2010-08-15 11:29 ` Nicolas Goaziou
2010-08-15 14:40 ` Carsten Dominik
2010-08-15 20:52 ` Glauber Alex Dias Prado
2010-08-16 7:17 ` Carsten Dominik
2010-08-15 13:21 ` Nicolas Goaziou
2010-08-15 14:07 ` Nicolas Goaziou
2010-08-17 17:24 ` Request for opinions: [ANN] List improvement v.2o Carsten Dominik
2010-08-17 17:25 ` Carsten Dominik
2010-08-17 18:02 ` Nicolas Goaziou
2010-08-18 6:53 ` Sébastien Vauban
2010-08-18 22:50 ` Daniel Martins
2010-08-18 7:38 ` Christian Moe
2010-08-18 9:09 ` Nicolas Goaziou
2010-08-18 12:39 ` Christian Moe
2010-08-20 0:56 ` Nicolas Goaziou [this message]
2010-08-21 11:29 ` Bernt Hansen
2010-08-21 14:18 ` Nicolas Goaziou
2010-08-21 14:22 ` Bernt Hansen
2010-08-27 8:24 ` [ANN] List improvement v.2 Carsten Dominik
2010-08-27 10:57 ` Bernt Hansen
2010-09-02 8:13 ` Carsten Dominik
2010-09-03 8:39 ` Eric S Fraga
2010-09-03 14:34 ` Nicolas Goaziou
2010-09-03 17:16 ` Eric S Fraga
2010-09-03 20:26 ` Nicolas Goaziou
2010-09-03 20:42 ` Eric S Fraga
2010-09-03 15:06 ` Sebastian Rose
2010-09-04 3:54 ` Matt Lundin
2010-09-04 10:24 ` Nicolas Goaziou
2010-09-04 11:36 ` Carsten Dominik
2010-09-04 12:09 ` Nicolas Goaziou
2010-09-07 11:25 ` Strange behavior of M-RET with new list improvements Anthony Lander
2010-09-07 11:46 ` Bernt Hansen
2010-09-07 12:05 ` Anthony Lander
2010-09-07 17:11 ` Nicolas Goaziou
2010-09-17 13:01 ` [Bug] Level 2 text not exported in LaTeX (well in HTML) + some comments Sébastien Vauban
2010-09-17 15:29 ` Eric S Fraga
2010-09-18 18:02 ` Nicolas Goaziou
2010-09-18 21:53 ` Eric S Fraga
2010-09-19 9:24 ` Nicolas Goaziou
2010-09-19 21:07 ` Sébastien Vauban
2010-09-20 7:54 ` Eric S Fraga
2010-09-22 11:35 ` Carsten Dominik
2010-09-22 20:21 ` Sébastien Vauban
2010-09-22 21:31 ` Nicolas Goaziou
2010-09-18 17:44 ` Nicolas Goaziou
2010-09-19 21:01 ` Sébastien Vauban
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
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zkwiyucp.wl%n.goaziou@gmail.com \
--to=n.goaziou@gmail.com \
--cc=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).