emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Carsten Dominik <carsten.dominik@gmail.com>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: Org Mode List <emacs-orgmode@gnu.org>
Subject: Request for opinions:  [ANN] List improvement v.2o
Date: Tue, 17 Aug 2010 19:25:05 +0200	[thread overview]
Message-ID: <17A93AC0-1896-481D-B2E9-E1DA5879A1D0@gmail.com> (raw)
In-Reply-To: <87ocdzw7gq.wl%n.goaziou@gmail.com>


On Jul 22, 2010, at 11:08 PM, Nicolas Goaziou wrote:

> Hello,
>
> Here is a new, and probably final feature-wise, suggestion of list
> improvement in Org Mode.
>
> Table of Contents
> =================
> 1 What is it about again ?
> 2 Is that all ?
>   2.1 Preserving blank lines
>   2.2 Timer lists
>   2.3 Automatic rules
>   2.4 `org-apply-on-list'
> 3 Where can it be tried ?


Hi everyone,

I would like to have a discussion about the list improvements proposed  
by
Nicolas.  I have tested his code now for a few days (on and off).  I  
like
many things.  About some issues I am not as happy, but maybe we should
accept these in exchange for the significant improvements we can get.

With Nicolas' code, we loose

1. The ability to have several sublists separated by text, for example

   - item1
       - subitem A1
       - subitem A2

       some text in between the lists, identified as such by indentation

       - subitem B1
       - subitem B2

Such a construct is no longer possible.  The LaTeX exporter already
was not able to deal with this situation, but the HTML and DocBook
exporters did handle this correcty (and still do, actually, contrary to
what Nicolas wrote in one of his messages).  In the past
we have had several requests to upgrade the LaTeX exporter in
this respect, but that has not happened - it is not easy to do.

2. Some existing documents will break because we now need an end-of-list
   that is clearly defined, and not by indentation.  Nicolas proposes a
   double empty line or some special string to be defined.  Breaking  
existing
   documents is always bad, of cause.  I still hope we can do something
   about this if we think really hard, like making text that is less
   indented than the list *also* terminate a list.

These are, as far as I can see, the most important disadvantages.

On the other had, using Nicolas' code, we gain

1. More consistent behavior of line indentation with TAB in lists.
   Basically, TAB will no longer break list structure.  This was
   something that has bothered me quite a bit in the past.

2. With org-cycle-include-plaint-lists set, cycling of list items
   works consistently as far as I can see, and no longer hides
   text after the end of the list.

3. Consistent behavior in the different exporters (see the point
   I made earlier about text between sublists).  More work is needed,
   but basically this is what it comes down to.

4. A significant list of additional consistency improvements, as
   detailed by Nicolas in his mail (see below).

I would like to invite comments, and maybe clever
proposals on how to maybe get a bit of extra backward
compatibility.  Also, if would be great if more people could
get his code and test it - lists are complex, and it is
quite possible that there are hidden problems that show only
up with  wider variety of examples.



>
>
> 1 What is it about again ?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> I redefined lists in Org Mode. Lists start, as before, at a bullet
> (whose true regexp is at `org-item-beginning-re'), and end at either
> `org-list-end-regexp', a new headline, or, obviously, end of buffer.
>
> `org-list-end-regexp' is customizable and defaults to 2 blank lines,
> but `org-empty-line-terminates-plain-lists' has precedence over it.
> Moreover, any `org-list-end-regexp' found in special blocks does not
> end list. Here are two examples of valid lists:
>
> Case 1: `org-list-end-regexp' is at default value
>
>
> - First item
>
>   - Sub item
>
>     #+BEGIN_EXAMPLE
>     Two blank lines below
>
>
>     Two blank lines above
>     #+END_SRC
>
>   - Last sub item
>
>
> List has ended at the beginning of this line.
>
> Case 2: `org-list-end-regexp' is "^[ \t]*___[ \t]*\n"
>
>
> - item 1
> - item 2
>   - sub-item
>   - sub-item 2
> - item 3
> __
> List has ended at the beginning of this line.
>
> Now, Org Mode knows when a list has ended and how to indent line
> accordingly. In other words, you can `org-return-indent' three times
> to exit a list and be at the right column to go on with the text.
>
> This new definition is also understood by exporters (LaTeX, DocBook,
> HTML or ASCII) and `org-list-end-regexp' will appear in source as a
> blank line, whatever its value is (as long as it starts with a caret
> and ends with a newline character, as specified in doc-string).
>
> Another advantage is that you can have two lists of different types
> in a row like in the example below:
>
>
> - item
> - item
>
>
> 1. item
> 2. item
>
> In this example, you can move (or cycle, or indent) items in the
> second list without worrying about changing the first one.
>
> 2 Is that all ?
> ~~~~~~~~~~~~~~~~
>
> Yes and no. I tried as much as possible to keep compatibility with
> previous implementation. But, as I was at it, I made a number of
> minor improvements I am now going to describe.
>
> 2.1 Preserving blank lines
> ===========================
>
>  `org-move-item-up' and `org-move-item-down' will not eat blank
>  lines anymore. You can move an item up and down and stay assured
>  list will keep its integrity.
>
>  The same is true for `org-sort-list' that would previously collapse
>  the list being sorted. Sorting is now safe.
>
>  `org-insert-item', when 'plain-list-item is set to 'auto in
>  `org-blank-before-new-entry' (the default, I think), will work hard
>  to guess the appropriate number of blank lines to insert before the
>  item to come. The function is also much more predictable (in
>  previous version, trying to insert an item with point on a blank
>  line between 2 items would create a new headline).
>
> 2.2 Timer lists
> ================
>
>  There are three improvements in timer lists (C-c C-x -).
>
>  1. When a new item is created, it should be properly indented and
>     not sticked to column 0 anymore,
>
>  2. When an item is inserted in a pre-existing timer list, it will
>     take profit of what has been done to `org-insert-item',
>
>  3. `org-sort-list' can now sort timer lists with the t and T
>     commands.
>
>  /Note/: in order to preserve lists integrity, Org Mode will send an
>  error if you try to insert a timer list inside a list of another
>  type.
>
> 2.3 Automatic rules
> ====================
>
>  I've added sets of rules (applied by default) that can improve
>  lists experience. You can deactivate them individually by
>  customizing `org-list-automatic-rules'.
>
>  Bullet rule: Some may have noticed that you couldn't obtain *
>                   as a bullet when cycling a list at column 0 or Org
>                   would have taken them for headings.
>
>                   I extended the idea. Now, * bullet will be changed
>                   to - if you outdent it to column 0. This and the
>                   fact that LaTeX exporter now recognizes such lists
>                   as valid make *-lists very usable.
>
>                   In the same register, cycling items of a
>                   description list will not offer 1. or 1), as
>                   ordered and description lists are incompatible.
>
>  Checkbox rule: It replaces `org-provide-checkbox-statistics'
>                     which has become obsolete.
>
>  Indent rule: This set prevents user from breaking his list by
>                   inadvertence, when indenting or outdenting items
>                   and sub-trees. Only moves that keep list integrity
>                   are allowed.
>
>                   The main advantage of it is when you insert a new
>                   item and immediately press one or more TAB,
>                   positions offered will all be meaningful. Quick
>                   and efficient.
>
>                   As a special case, moving the top item of the list
>                   will move the whole list with it.
>
>  Insert rule: As a consequence of the new definition of lists,
>                   items cannot be inserted inside a special block in
>                   the middle of a list. With this rule activated,
>                   item will be insert right before that special
>                   block. If not, Org will only throw an error.
>
>  Renumber rule: It replaces `org-auto-renumber-ordered-lists'
>                     which has become obsolete.
>
>  I think those rules make a sane default behavior (except for the
>  indent rule, perhaps). And they are easy to disable if one think
>  they get too much in the way.
>
> 2.4 `org-apply-on-list'
> ========================
>
>  It's not much, but I added that small function, inspired from
>  `apply-of-rectangle', that might be of some use. It basically
>  applies a function passed as argument to each item of the list
>  (with a possible return value for functional usage).
>
>  As an illustration, here is a small function that walks through a
>  list (and its sublists, if any), checking every item with a blank
>  checkbox whose body is matched by REGEXP. It returns the number of
>  items checked.
>
>
> (defun my-check-o-matic (regexp)
>   ;; Function we are going to apply.
>   (let ((search-and-check
>          (lambda (count)
>            (let* ((body-end (save-excursion (org-end-of-item-text- 
> before-children)))
>                   ;; Take care of any sublist first
>                   (count (if (not (org-item-has-children-p))
>                              count
>                            (goto-char body-end)
>                            (org-apply-on-list search-and-check  
> count))))
>              ;; Tests and checking if the formers are successful
>              (if (and (save-excursion (re-search-forward regexp body- 
> end t))
>                       (org-at-item-checkbox-p)
>                       (equal (match-string 1) "[ ]"))
>                  (progn (org-toggle-checkbox) (1+ count))
>                count)))))
>     ;; Call of `org-apply-on-list': notice initial value of counter
>     (format "%d items checked"(org-apply-on-list search-and-check  
> 0))))
>
> 3 Where can it be tried ?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> The source is at:
>
> git@github.com:ngz/org-mode-lists.git   branch: end-lists
>
> It is merged very frequently with git head, and I keep a clone of
> Org Mode master branch at the same place. So, you can switch from
> end-lists to master without too much hassle. It is very stable
> anyway, so you do not need to be an adventurous type.
>
> Feedback, suggestions and comments are welcome.
>
> Regards,
>
> -- 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

  parent reply	other threads:[~2010-08-17 17:25 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 [this message]
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
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=17A93AC0-1896-481D-B2E9-E1DA5879A1D0@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 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).