[ANN] List improvement v.2

[ANN] List improvement v.2

[Nicolas Goaziou]

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 ? 


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

Re: [ANN] List improvement v.2

[Nicolas Goaziou]

Errata:

>   Case 2: `org-list-end-regexp' is "^[ \t]*___[ \t]*\n"

It is "^[ \t]*__[ \t]*\n" (only 2 underscores)

>    I think those rules make a sane default behavior (except for the
>    indent rule, perhaps).

I meant the _insert_ rule which can be a bit surprising at first.


-- Nicolas

Re: [ANN] List improvement v.2

[Eric Schulte]

Hi Nicolas,

This looks really great, I have applied it to my setup and will be
stress testing it over the next couple of days.

A couple of quick points:

1) The url to use for cloning should be
   http://github.com/ngz/org-mode-lists.git

2) This is very minor, but could you rebase your branch against master?
   That would make switching back and forth slightly easier.

3) Since I can't help but relate things to Babel... What do you think
   about having list types recognized by Babel (as arrays).  This could
   add nice flexibility to passing data back and forth between Babel and
   the buffer, it could make it possible to do some fancy list stuff,
   and if we add Hash-Maps or Dictionaries to Babel as first class
   objects (which seems like a reasonable move at some point in the
   nearish future) then they could integrate well with description
   lists.

Thanks for the new functionality, I look forward to playing with it.

Best -- Eric

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> 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 ? 
>
>
> 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

Re: [ANN] List improvement v.2

[Nicolas Goaziou]

Hello,
>>>>> Eric Schulte writes:

> 2) This is very minor, but could you rebase your branch against master?
>    That would make switching back and forth slightly easier.

I rebased against master and pushed to github.

> 3) Since I can't help but relate things to Babel... What do you think
>    about having list types recognized by Babel (as arrays).  This could
>    add nice flexibility to passing data back and forth between Babel and
>    the buffer, it could make it possible to do some fancy list stuff,
>    and if we add Hash-Maps or Dictionaries to Babel as first class
>    objects (which seems like a reasonable move at some point in the
>    nearish future) then they could integrate well with description
>    lists.

It's a good idea, and I think the job from org-list side is already
done, thanks to Bastien Guerry. You should have a look at
`org-list-parse-list' and `org-list-to-generic'. With both of them,
you can change a list back and forth to anything you'd like.

Regards,

-- Nicolas

Re: [ANN] List improvement v.2

[Scot Becker]

[-- Attachment #1.1: Type: text/plain, Size: 9188 bytes --]

Nicolas and list friends

This sounds great.  And it seems you've made it easy to try by putting in in
git.  Since my git usage consists almost exclusively of pulling from the
org-mode repository, and I've never dealt with testing branches, would one
of you be so kind as to feed me the commands necessary to try this out in
the  easiest way possible.  I keep current on the org 'master' repo.

Should I pull a separate repo, or make a branch on the one I have?  Assuming
I find no reason to undo the changes, and assuming they are merged into the
core after some weeks, and assuming that I want keep current on the main org
repository, will I need to do anything if and when these changes get added
to the core if I'm already testing them on the branch?  I'm sure all of this
is blissfully easy (git seems so clever), but I'd be glad to have someone
explain how to do it in the easiest way.

Scot


On Thu, Jul 22, 2010 at 10:08 PM, Nicolas Goaziou <n.goaziou@gmail.com>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 ?
>
>
> 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
>

[-- Attachment #1.2: Type: text/html, Size: 10660 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

Re: [ANN] List improvement v.2

[Daniel Martins]

[-- Attachment #1.1: Type: text/plain, Size: 9882 bytes --]

I am on the same level as Scot and with the same doubts.

Anyway one more vote to include these improvements to the core repository of
org-mode ASAP.

Daniel

2010/7/27 Scot Becker <scot.becker@gmail.com>

> Nicolas and list friends
>
> This sounds great.  And it seems you've made it easy to try by putting in
> in git.  Since my git usage consists almost exclusively of pulling from the
> org-mode repository, and I've never dealt with testing branches, would one
> of you be so kind as to feed me the commands necessary to try this out in
> the  easiest way possible.  I keep current on the org 'master' repo.
>
> Should I pull a separate repo, or make a branch on the one I have?
> Assuming I find no reason to undo the changes, and assuming they are merged
> into the core after some weeks, and assuming that I want keep current on the
> main org repository, will I need to do anything if and when these changes
> get added to the core if I'm already testing them on the branch?  I'm sure
> all of this is blissfully easy (git seems so clever), but I'd be glad to
> have someone explain how to do it in the easiest way.
>
> Scot
>
>
>
> On Thu, Jul 22, 2010 at 10:08 PM, Nicolas Goaziou <n.goaziou@gmail.com>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 ?
>>
>>
>> 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
>>
>
>
> _______________________________________________
> 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
>
>

[-- Attachment #1.2: Type: text/html, Size: 11613 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

Re: [ANN] List improvement v.2

[Nicolas Goaziou]

Hello,

>>>>> Scot Becker writes:
> Should I pull a separate repo, or make a branch on the one I have?

Both options are possible. In order to make a specific branch in your
current repo, it's a two steps move (and one optional):

  git checkout -b new-lists

  git remote add ngz http://github.com/ngz/org-mode-lists.git (optional
step, it avoids typing the whole url everytime you want to update)

Then, to keep up-to-date:

  git pull ngz end-lists

Don't forget to M-x org-reload.

> Assuming I find no reason to undo the changes, and assuming they are
> merged into the core after some weeks, and assuming that I want keep
> current on the main org repository, will I need to do anything if
> and when these changes get added to the core if I'm already testing
> them on the branch?

You will then switch to master branch, delete new-lists branch (and
ngz remote repository), then reload org-mode.

  git checkout master

  git pull

  git branch -D new-lists

  git remote rm ngz (optional)

  M-x org-reload

I'm no specialist of git, there might be even quicker way to do all of
this.

Thanks for testing.

Regards,

-- Nicolas

Re: [ANN] List improvement v.2

[Carsten Dominik]

Hi Nicolas,

I have finally started to look at your changes to the list  
implementation.
Lots of it is very good!  I like for example that TAB indentation now  
works
a lot better.

Here are a few problems I noted so far:

1 Error when pressing M-RET in second line after list
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   - Example item1
   - Exmaple item2

With cursor position at "@", M-RET throws an error

2 Incompatibility 1
~~~~~~~~~~~~~~~~~~~~
   - Example 1
   - Ex 2

   This used to be outside of the list.  The HTML exporter still treats
   it as being outside of the list.  The LaTeX exporter treats it as
   part of the last item.  If I add a second empty line, then both
   exporters handle it well.

   So this breaks with documented properties of the lists.  I guess
   this is unavoidable because this is just how the new list definition
   works.  But it will break existing documents when exported to LaTeX

3 Text between two sublists
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   - Ex1
   - Ex2
     - Ex2a
     - Ex2b
     Some text between two sublists
     - A new list starts

This always was an inconsistency between HTML and LaTeX export, and it
still is now.  There seems to be no way now to do what I intend here,
putting some text between two lists.


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 ?
>
>
> 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

Re: [ANN] List improvement v.2

[Glauber Alex Dias Prado]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Hi Nicolas,
>
> I have finally started to look at your changes to the list
> implementation.
> Lots of it is very good!  I like for example that TAB indentation now
> works
> a lot better.
>
> Here are a few problems I noted so far:
>
> 1 Error when pressing M-RET in second line after list
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   - Example item1
>   - Exmaple item2
>
> With cursor position at "@", M-RET throws an error
>
> 2 Incompatibility 1
> ~~~~~~~~~~~~~~~~~~~~
>   - Example 1
>   - Ex 2
>
>   This used to be outside of the list.  The HTML exporter still treats
>   it as being outside of the list.  The LaTeX exporter treats it as
>   part of the last item.  If I add a second empty line, then both
>   exporters handle it well.
>
>   So this breaks with documented properties of the lists.  I guess
>   this is unavoidable because this is just how the new list definition
>   works.  But it will break existing documents when exported to LaTeX
>
> 3 Text between two sublists
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   - Ex1
>   - Ex2
>     - Ex2a
>     - Ex2b
>     Some text between two sublists
>     - A new list starts
>
> This always was an inconsistency between HTML and LaTeX export, and it
> still is now.  There seems to be no way now to do what I intend here,
> putting some text between two lists.

preferably not only for lists, something like:

* some stuff
  quick intro
** nest 1  
   stuff about nest1
  now what i dont think is possible and dont even know if it is usually
  done on latex something that belongs to some stuff and is in between
  nest 1 and 2, i find it usefull for commenting on nests(thats why
  i miss it) and looks like it is the same thing you are wishing for lists?
  My use case for this is mostly note-taking.
** nest 2
   stuff about nest2

could be also usefull, if it makes sense, btw the lists are taking shape :).

>
>
> 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 ?
>>
>>
>> 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
>
>
>
>
> _______________________________________________
> 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

Re: [ANN] List improvement v.2

[Nicolas Goaziou]

Hello,

> Glauber Alex Dias Prado writes:
>> Carsten Dominik <carsten.dominik@gmail.com> writes:

>> 1 Error when pressing M-RET in second line after list
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> 
>> - Example item1
>> - Exmaple item2
>> 
>> With cursor position at "@", M-RET throws an error

This is now fixed.


>> 2 Incompatibility 1
>> ~~~~~~~~~~~~~~~~~~~~
>> - Example 1
>> - Ex 2
>> 
>> This used to be outside of the list.  The HTML exporter still treats
>> it as being outside of the list.  The LaTeX exporter treats it as
>> part of the last item.  If I add a second empty line, then both
>> exporters handle it well.
>> 
>> So this breaks with documented properties of the lists.  I guess
>> this is unavoidable because this is just how the new list definition
>> works.  But it will break existing documents when exported to LaTeX

According to the new list definition, LaTeX exporter is correct here.
Now, DocBook and HTML exporters will also treat it as being part of
the last item (unless `org-empty-line-terminates-plain-lists' is t,
obviously).


>> 3 Text between two sublists
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> 
>> - Ex1
>> - Ex2
>>   - Ex2a
>>   - Ex2b
>>   Some text between two sublists
>>   - A new list starts
>> 
>> This always was an inconsistency between HTML and LaTeX export, and it
>> still is now.  There seems to be no way now to do what I intend here,
>> putting some text between two lists.

I removed this inconsistency (see 2.).

Alas, what you want to achieve here isn't possible. Lists are now a
strong structural element. Think of them as mini headings. Indentation
of body means nothing in both of them. In the case of headings, only
the number of stars matters, while lists only pay attention to
indentation of bullets.

There's somewhat a workaround though, as you can indent the very first
item of a list to any column, making this possible:

- List 1, item 1
  - List 1, sub item 1


Some comments after list 1 has ended

  - List 2, item 1
  - List 2, item 2


- List 3, item 1


While there are in fact 3 different lists, it more or less looks like
what you want to do (and it could be cleaner with
`org-empty-line-terminates-plain-lists' set to t). Please note that
trick won't survive an export.

If export matters, there are quote blocks, or verbatim, or example.
But I won't teach you all of this! ;)


> preferably not only for lists, something like:

> * some stuff
>   quick intro
> ** nest 1  
>    stuff about nest1
>   now what i dont think is possible and dont even know if it is usually
>   done on latex something that belongs to some stuff and is in between
>   nest 1 and 2, i find it usefull for commenting on nests(thats why
>   i miss it) and looks like it is the same thing you are wishing for lists?
>   My use case for this is mostly note-taking.
> ** nest 2
>    stuff about nest2

> could be also usefull, if it makes sense, btw the lists are taking shape :).

You are right, this is exactly the same problem. I think there are 2
ways to handle this:

1. either indentation brings information, and there can't possibly be
   a working automatic indentation (like previous list implementation)
   as you can never tell for sure if current line is badly indented or
   sending information on something.

2. either indentation is given by structural elements (like headings
   in your example) and there's no "in between nest 1 and 2".
   

Since Org is about structure, option 2 is, in my opinion, clearly the
way to go.

Regards,

-- Nicolas

Re: [ANN] List improvement v.2

[Carsten Dominik]

On Aug 15, 2010, at 10:45 AM, Glauber Alex Dias Prado wrote:

> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> Hi Nicolas,
>>
>> I have finally started to look at your changes to the list
>> implementation.
>> Lots of it is very good!  I like for example that TAB indentation now
>> works
>> a lot better.
>>
>> Here are a few problems I noted so far:
>>
>> 1 Error when pressing M-RET in second line after list
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>  - Example item1
>>  - Exmaple item2
>>
>> With cursor position at "@", M-RET throws an error
>>
>> 2 Incompatibility 1
>> ~~~~~~~~~~~~~~~~~~~~
>>  - Example 1
>>  - Ex 2
>>
>>  This used to be outside of the list.  The HTML exporter still treats
>>  it as being outside of the list.  The LaTeX exporter treats it as
>>  part of the last item.  If I add a second empty line, then both
>>  exporters handle it well.
>>
>>  So this breaks with documented properties of the lists.  I guess
>>  this is unavoidable because this is just how the new list definition
>>  works.  But it will break existing documents when exported to LaTeX
>>
>> 3 Text between two sublists
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>  - Ex1
>>  - Ex2
>>    - Ex2a
>>    - Ex2b
>>    Some text between two sublists
>>    - A new list starts
>>
>> This always was an inconsistency between HTML and LaTeX export, and  
>> it
>> still is now.  There seems to be no way now to do what I intend here,
>> putting some text between two lists.
>
> preferably not only for lists, something like:
>
> * some stuff
>  quick intro
> ** nest 1
>   stuff about nest1
>  now what i dont think is possible and dont even know if it is usually
>  done on latex something that belongs to some stuff and is in between
>  nest 1 and 2, i find it usefull for commenting on nests(thats why
>  i miss it) and looks like it is the same thing you are wishing for  
> lists?
>  My use case for this is mostly note-taking.
> ** nest 2
>   stuff about nest2
>
> could be also usefull, if it makes sense, btw the lists are taking  
> shape :).

This has been discussed here a million times and it is not going to  
happen.

- Carsten

>
>>
>>
>> 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 ?
>>>
>>>
>>> 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
>>
>>
>>
>>
>> _______________________________________________
>> 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] List improvement v.2

[Glauber Alex Dias Prado]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> On Aug 15, 2010, at 10:45 AM, Glauber Alex Dias Prado wrote:
>
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>
>>> Hi Nicolas,
>>>
>>> I have finally started to look at your changes to the list
>>> implementation.
>>> Lots of it is very good!  I like for example that TAB indentation now
>>> works
>>> a lot better.
>>>
>>> Here are a few problems I noted so far:
>>>
>>> 1 Error when pressing M-RET in second line after list
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>  - Example item1
>>>  - Exmaple item2
>>>
>>> With cursor position at "@", M-RET throws an error
>>>
>>> 2 Incompatibility 1
>>> ~~~~~~~~~~~~~~~~~~~~
>>>  - Example 1
>>>  - Ex 2
>>>
>>>  This used to be outside of the list.  The HTML exporter still treats
>>>  it as being outside of the list.  The LaTeX exporter treats it as
>>>  part of the last item.  If I add a second empty line, then both
>>>  exporters handle it well.
>>>
>>>  So this breaks with documented properties of the lists.  I guess
>>>  this is unavoidable because this is just how the new list definition
>>>  works.  But it will break existing documents when exported to LaTeX
>>>
>>> 3 Text between two sublists
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>  - Ex1
>>>  - Ex2
>>>    - Ex2a
>>>    - Ex2b
>>>    Some text between two sublists
>>>    - A new list starts
>>>
>>> This always was an inconsistency between HTML and LaTeX export, and
>>> it
>>> still is now.  There seems to be no way now to do what I intend here,
>>> putting some text between two lists.
>>
>> preferably not only for lists, something like:
>>
>> * some stuff
>>  quick intro
>> ** nest 1
>>   stuff about nest1
>>  now what i dont think is possible and dont even know if it is usually
>>  done on latex something that belongs to some stuff and is in between
>>  nest 1 and 2, i find it usefull for commenting on nests(thats why
>>  i miss it) and looks like it is the same thing you are wishing for
>> lists?
>>  My use case for this is mostly note-taking.
>> ** nest 2
>>   stuff about nest2
>>
>> could be also usefull, if it makes sense, btw the lists are taking
>> shape :).
>
> This has been discussed here a million times and it is not going to
> happen.
>
> - Carsten

Sorry i cant catchup on everything. I was thinking here could this be
done as footnotes on org headings? the look certainly wouldnt be the
same but perhaps the effect would, am gonna try it later, never played
with footnotes export.

cheers,
glauber.

>
>>
>>>
>>>
>>> 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 ?
>>>>
>>>>
>>>> 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
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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] List improvement v.2

[Carsten Dominik]

Hi Alex,

On Aug 15, 2010, at 10:52 PM, Glauber Alex Dias Prado wrote:

> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> On Aug 15, 2010, at 10:45 AM, Glauber Alex Dias Prado wrote:
>>
>>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>>
>>>> Hi Nicolas,
>>>>
>>>> I have finally started to look at your changes to the list
>>>> implementation.
>>>> Lots of it is very good!  I like for example that TAB indentation  
>>>> now
>>>> works
>>>> a lot better.
>>>>
>>>> Here are a few problems I noted so far:
>>>>
>>>> 1 Error when pressing M-RET in second line after list
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>> - Example item1
>>>> - Exmaple item2
>>>>
>>>> With cursor position at "@", M-RET throws an error
>>>>
>>>> 2 Incompatibility 1
>>>> ~~~~~~~~~~~~~~~~~~~~
>>>> - Example 1
>>>> - Ex 2
>>>>
>>>> This used to be outside of the list.  The HTML exporter still  
>>>> treats
>>>> it as being outside of the list.  The LaTeX exporter treats it as
>>>> part of the last item.  If I add a second empty line, then both
>>>> exporters handle it well.
>>>>
>>>> So this breaks with documented properties of the lists.  I guess
>>>> this is unavoidable because this is just how the new list  
>>>> definition
>>>> works.  But it will break existing documents when exported to LaTeX
>>>>
>>>> 3 Text between two sublists
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>> - Ex1
>>>> - Ex2
>>>>   - Ex2a
>>>>   - Ex2b
>>>>   Some text between two sublists
>>>>   - A new list starts
>>>>
>>>> This always was an inconsistency between HTML and LaTeX export, and
>>>> it
>>>> still is now.  There seems to be no way now to do what I intend  
>>>> here,
>>>> putting some text between two lists.
>>>
>>> preferably not only for lists, something like:
>>>
>>> * some stuff
>>> quick intro
>>> ** nest 1
>>>  stuff about nest1
>>> now what i dont think is possible and dont even know if it is  
>>> usually
>>> done on latex something that belongs to some stuff and is in between
>>> nest 1 and 2, i find it usefull for commenting on nests(thats why
>>> i miss it) and looks like it is the same thing you are wishing for
>>> lists?
>>> My use case for this is mostly note-taking.
>>> ** nest 2
>>>  stuff about nest2
>>>
>>> could be also usefull, if it makes sense, btw the lists are taking
>>> shape :).
>>
>> This has been discussed here a million times and it is not going to
>> happen.
>>
>> - Carsten
>
> Sorry i cant catchup on everything. I was thinking here could this be
> done as footnotes on org headings? the look certainly wouldnt be the
> same but perhaps the effect would, am gonna try it later, never played
> with footnotes export.

I am not sure if I understand what you are describing here, maybe you  
can make a detailed example of what you have in mind.

- Carsten

Re: [ANN] List improvement v.2

[Nicolas Goaziou]

>>>>> Carsten Dominik writes:
Hello,

> But it will break existing documents when exported to LaTeX

It will break existing documents when exporting to anything (except
ASCII). You can use the following (quick and dirty) code to make the
transition easier:

(defun org-switch-to-new-lists ()
  "Make current buffer compatible with new list definition."
  (goto-char (point-min))
  (while (< (point) (point-max))
    (while (and (org-in-item-p)
		(not (org-at-item-p))
		(not (looking-at "^[ \t]*$"))
		(not (and (org-in-regexps-block-p
                           "^[ \t]*#\\+begin_" "^[ \t]*#\\+end_")
                          (not (looking-at "^[ \t]*#\\+begin_"))))
                (<= (org-get-indentation)
		    (save-excursion
		      (org-beginning-of-item)
		      (org-get-indentation))))
      (newline))
    (beginning-of-line 2)))

Regards,

-- Nicolas

Re: [ANN] List improvement v.2

[Nicolas Goaziou]

Argh, it should be:

(defun org-switch-to-new-lists ()
  "Make current buffer compatible with new list definition."
  (goto-char (point-min))
  (let ((case-fold-search t))
    (while (< (point) (point-max))
      (while (and (org-in-item-p)
                  (not (org-at-item-p))
                  (not (looking-at "^[ \t]*$"))
                  (not (and (org-in-regexps-block-p
                             "^[ \t]*#\\+begin_" "^[ \t]*#\\+end_")
                            (not (looking-at "^[ \t]*#\\+begin_"))))
                  (<= (org-get-indentation)
                      (save-excursion
                        (org-beginning-of-item)
                        (org-get-indentation))))
        (newline))
      (beginning-of-line 2))))

Sorry for the noise.

Regards,

-- Nicolas

Request for opinions: [ANN] List improvement v.2o

[Carsten Dominik]

[-- Attachment #1: Type: text/html, Size: 24068 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

Request for opinions: [ANN] List improvement v.2o

[Carsten Dominik]

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

Re: Request for opinions: [ANN] List improvement v.2o

[Nicolas Goaziou]

Hello,
>>>>> Carsten Dominik writes:


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

Well, I just verified, and I maintain HTML and DocBook behave as LaTeX
here. Are you sure to be running git head? I fixed this in two steps,
you might be stuck between them.

Regards,

-- Nicolas

Re: Request for opinions: [ANN] List improvement v.2o

[Sébastien Vauban]

Hi Carsten and Nicolas,

Carsten Dominik wrote:
> On Jul 22, 2010, at 11:08 PM, Nicolas Goaziou wrote:
>
> 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.

From what I understood, without testing anything of it (yet), I would really
urge for a support of old documents (the ones with simple constructions) by
adopting a rule like the one you propose, where indentation could terminate
the list.

Best regards,
  Seb

-- 
Sébastien Vauban


_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Re: Request for opinions: [ANN] List improvement v.2o

[Daniel Martins]

[-- Attachment #1.1: Type: text/plain, Size: 1818 bytes --]

I have the opposite view.

I did not tried yet the code because I am a naive git user and worry about
messing things up adding another complex branch.

However I must say that all my lists (and I have a lot of them!) do not
satisfy me completely. The problem of breaking indentation and changing
patterns in the middle of lists is often annoying.

I am willing to have some work to rearrange all my lists if the
implementation is changing the viewpoint we have about lists (therefore
turning future impriovements easier) and the code is intrisically coherent
as I think Nicolas code is.

In other words, One vote for Nicolas code.

Daniel

2010/8/18 Sébastien Vauban <wxhgmqzgwmuf@spammotel.com>

> Hi Carsten and Nicolas,
>
> Carsten Dominik wrote:
> > On Jul 22, 2010, at 11:08 PM, Nicolas Goaziou wrote:
> >
> > 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.
>
> From what I understood, without testing anything of it (yet), I would
> really
> urge for a support of old documents (the ones with simple constructions) by
> adopting a rule like the one you propose, where indentation could terminate
> the list.
>
> Best regards,
>  Seb
>
> --
> Sébastien Vauban
>
>
> _______________________________________________
> 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
>

[-- Attachment #1.2: Type: text/html, Size: 2425 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

Re: Request for opinions: [ANN] List improvement v.2o

[Christian Moe]

Carsten Dominik wrote:

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

+1

Ending lists by indentation most closely resembles how one would end a 
list in ordinary typed prose (with a single blank line before a 
following paragraph, not two, certainly not with an end-of-list 
symbol). Since Org is currently capable of understanding this 
"natural" syntax, the change would be a real step backwards.

Speaking for myself I know it would break a *lot* of my stuff.

Otherwise, Nicolas Goaziou's changes look nice. I hope a way can be 
found to have it both ways.

Yours,
Christian

Re: Request for opinions: [ANN] List improvement v.2o

[Nicolas Goaziou]

Hello,
>>>>> Christian Moe writes:

> Ending lists by indentation most closely resembles how one would end a 
> list in ordinary typed prose (with a single blank line before a 
> following paragraph, not two, certainly not with an end-of-list 
> symbol).

Just to clear up things: you can still end a list with a single blank
line with `org-empty-line-terminates-plain-lists', just not by
default.

Moreover, I posted in this list a function that can ease moving
documents from the existing list format to this one. It should prevent
breaking stuff.

Regards,

-- Nicolas

Re: Request for opinions: [ANN] List improvement v.2o

[Christian Moe]

Oops. Sorry.

CM



Nicolas Goaziou wrote:
> Hello,
>>>>>> Christian Moe writes:
> 
>> Ending lists by indentation most closely resembles how one would end a 
>> list in ordinary typed prose (with a single blank line before a 
>> following paragraph, not two, certainly not with an end-of-list 
>> symbol).
> 
> Just to clear up things: you can still end a list with a single blank
> line with `org-empty-line-terminates-plain-lists', just not by
> default.
> 
> Moreover, I posted in this list a function that can ease moving
> documents from the existing list format to this one. It should prevent
> breaking stuff.
> 
> 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
> 


-- 

Christian Moe
E-mail:  mail@christianmoe.com
Website: http://christianmoe.com

Re: Request for opinions: [ANN] List improvement v.2o

[Nicolas Goaziou]

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

Re: Request for opinions: [ANN] List improvement v.2o

[Bernt Hansen]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

Hi Nicolas,

I just started trying out your new list code in one of my org-mode
setups and I think I found a problem.

Today I entered an org-capture task like this

,----
| ** NEXT Investigate errors in log
|    :CLOCK:
|    CLOCK: [2010-08-21 Sat 07:00]
|    :END:
|    :LOGBOOK:
|    - State "NEXT"       from "TODO"       [2010-08-21 Sat 07:00]
|    :END:
|    [2010-08-21 Sat 07:00]
`----

and when I hit TAB at the end of this to add details I get this

,----
| ** NEXT Investigate errors in log
|    :CLOCK:
|    CLOCK: [2010-08-21 Sat 07:00]
|    :END:
|    :LOGBOOK:
|    - State "NEXT"       from "TODO"       [2010-08-21 Sat 07:00]
|    :END:
|    [2010-08-21 Sat 07:00]
|      >cursor goes here
|    >instead of here
`----

The tab indent is treating the list in the :LOGBOOK: as active even
though I'm not in the drawer.

Regards,
Bernt

Re: Request for opinions: [ANN] List improvement v.2o

[Nicolas Goaziou]

Hello,

>>>>> Bernt Hansen writes:

> Today I entered an org-capture task like this

> ,----
> | ** NEXT Investigate errors in log
> |    :CLOCK:
> |    CLOCK: [2010-08-21 Sat 07:00]
> |    :END:
> |    :LOGBOOK:
> |    - State "NEXT"       from "TODO"       [2010-08-21 Sat 07:00]
> |    :END:
> |    [2010-08-21 Sat 07:00]
> `----

> and when I hit TAB at the end of this to add details I get this

> ,----
> | ** NEXT Investigate errors in log
> |    :CLOCK:
> |    CLOCK: [2010-08-21 Sat 07:00]
> |    :END:
> |    :LOGBOOK:
> |    - State "NEXT"       from "TODO"       [2010-08-21 Sat 07:00]
> |    :END:
> |    [2010-08-21 Sat 07:00]
> |      >cursor goes here
> |    >instead of here
> `----

> The tab indent is treating the list in the :LOGBOOK: as active even
> though I'm not in the drawer.

It is now fixed.

Thank you very much for testing this branch and reporting this bug.

Regards

-- Nicolas

Re: Request for opinions: [ANN] List improvement v.2o

[Bernt Hansen]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

>> The tab indent is treating the list in the :LOGBOOK: as active even
>> though I'm not in the drawer.
>
> It is now fixed.
>
> Thank you very much for testing this branch and reporting this bug.

Thanks for the quick fix and for also fixing the other two issues I
reported to you on IRC.  I'll let you know if I find any other issues.

Currently I'm only testing this on weekends but if it seems to be stable
enough I'll also add it to the system I use at work (on Windows).

Regards,
Bernt

Re: [ANN] List improvement v.2

[Carsten Dominik]

Hi,

I am close to merging these changes into the master branch.

Any objections?

- Carsten

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 ?
>
>
> 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

Re: [ANN] List improvement v.2

[Bernt Hansen]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Hi,
>
> I am close to merging these changes into the master branch.
>
> Any objections?

I'm currently using this list implementation full-time.  We found two
export bugs just yesterday which I believe are now fixed.  There are no
outstanding bugs that I'm aware of at this time.  Including it in master
would get more testers in a hurry which is probably a good thing.

I think this implementation is currently stable enough to be included.

Regards,
Bernt

Re: [ANN] List improvement v.2

[Carsten Dominik]

Hi everyone,

I have now merged Nicolas' branch into the current master.  Hopefully  
all will go well.
If not, I am sure Nicolas can fix things on short notice.

Thanks to Nicolas for the big chunk of work!

- Carsten

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 ?
>
>
> 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

Re: [ANN] List improvement v.2

[Eric S Fraga]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

On Thu, 2 Sep 2010 10:13:09 +0200, Carsten Dominik <carsten.dominik@gmail.com> wrote:
> 
> Hi everyone,
> 
> I have now merged Nicolas' branch into the current master.  Hopefully
> all will go well.
> If not, I am sure Nicolas can fix things on short notice.

One quick problem I have run into today: 

org-toggle-checkbox (C-c C-x C-b) doesn't seem to do anything now?  I
have to put in the checkboxes manually (not a severe problem
obviously :-).

[-- Attachment #2: Type: text/plain, Size: 75 bytes --]

-- 
Eric S Fraga
GnuPG: 8F5C 279D 3907 E14A 5C29  570D C891 93D8 FFFC F67D

[-- Attachment #3: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

Re: [ANN] List improvement v.2

[Nicolas Goaziou]

Hello,
>>>>> Eric S Fraga writes:

> One quick problem I have run into today:

> org-toggle-checkbox (C-c C-x C-b) doesn't seem to do anything now? I
> have to put in the checkboxes manually.

I cannot reproduce it on git head. If you were inserting non-existing
checkboxes, I guess you meant C-u C-c C-x C-b.

Anyway, could you put a minimal example?

Regards,

-- Nicolas

Re: [ANN] List improvement v.2

[Eric S Fraga]

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

On Fri, 03 Sep 2010 16:34:36 +0200, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> 
> Hello,
> >>>>> Eric S Fraga writes:
> 
> > One quick problem I have run into today:
> 
> > org-toggle-checkbox (C-c C-x C-b) doesn't seem to do anything now? I
> > have to put in the checkboxes manually.
> 
> I cannot reproduce it on git head. If you were inserting non-existing
> checkboxes, I guess you meant C-u C-c C-x C-b.

I must be dreaming... I am *sure* that, until yesterday or today, I
have always used C-c C-x C-b to insert a checkbox if none were
present; at least, that's what my fingers tell me and they have a
better memory than my head...  I have always used C-c C-c to actually
mark or unmark the checkbox.  Have the default bindings changed?

In any case, apologies for the noise but maybe I can suggest a change
to the default?  C-c C-c already does an excellent job of
checking/unchecking a checkbox so it would be nice if C-c C-x C-b
would do as I thought it did: insert a checkbox if not present.  Is
this a reasonable or desirable behaviour?

Just a thought.

Thanks,
eric

[-- Attachment #2: Type: text/plain, Size: 75 bytes --]

-- 
Eric S Fraga
GnuPG: 8F5C 279D 3907 E14A 5C29  570D C891 93D8 FFFC F67D

[-- Attachment #3: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

Re: [ANN] List improvement v.2

[Nicolas Goaziou]

> I must be dreaming... I am *sure* that, until yesterday or today, I
> have always used C-c C-x C-b to insert a checkbox if none were
> present; at least, that's what my fingers tell me and they have a
> better memory than my head... I have always used C-c C-c to actually
> mark or unmark the checkbox. Have the default bindings changed?

I remember now. When I rewrote org-toggle-checkbox, I followed closely
its docstring. Thus, the default bindings changed because they weren't
on par with documentation.

> In any case, apologies for the noise but maybe I can suggest a
> change to the default? C-c C-c already does an excellent job of
> checking/unchecking a checkbox so it would be nice if C-c C-x C-b
> would do as I thought it did: insert a checkbox if not present. Is
> this a reasonable or desirable behaviour?

C-c C-x C-b is more specific than C-c C-c. When used on an headline,
it checks/unchecks all the items in the subtree. When used with a
region active, it should checks/unchecks all items inside it.

About the last point, I just noticed it isn't working as expected at
the moment, but I have a patch for it.

Regards,

-- Nicolas

Re: [ANN] List improvement v.2

[Eric S Fraga]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]

On Fri, 03 Sep 2010 22:26:31 +0200, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> 
> 
> > I must be dreaming... I am *sure* that, until yesterday or today, I
> > have always used C-c C-x C-b to insert a checkbox if none were
> > present; at least, that's what my fingers tell me and they have a
> > better memory than my head... I have always used C-c C-c to actually
> > mark or unmark the checkbox. Have the default bindings changed?
> 
> I remember now. When I rewrote org-toggle-checkbox, I followed closely
> its docstring. Thus, the default bindings changed because they weren't
> on par with documentation.

Ah ha!  Thanks.  Gives me a bit more faith in my sanity (maybe
unrealistic but there you are ;-).

I can get used to the new default behaviour (which does indeed match
the documentation).

Thanks,
eric

[-- Attachment #2: Type: text/plain, Size: 75 bytes --]

-- 
Eric S Fraga
GnuPG: 8F5C 279D 3907 E14A 5C29  570D C891 93D8 FFFC F67D

[-- Attachment #3: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

Re: [ANN] List improvement v.2

[Sebastian Rose]

Eric S Fraga <ucecesf@ucl.ac.uk> writes:
> org-toggle-checkbox (C-c C-x C-b) doesn't seem to do anything now?  I
> have to put in the checkboxes manually (not a severe problem
> obviously :-).


That works here as well as `C-c C-c'




  Sebastian

Re: [ANN] List improvement v.2

[Matt Lundin]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Hi everyone,
>
> I have now merged Nicolas' branch into the current master.  Hopefully
> all will go well.
> If not, I am sure Nicolas can fix things on short notice.
>
> Thanks to Nicolas for the big chunk of work!

Thanks, Nicolas, for all your work on this! Here are a couple pieces of
feedback:

1. On my machine, toggling a checkbox within a long list takes a long
   time. I have a 200+ item list. It takes approximately 5 seconds for
   org to toggle a single checkbox within the list (see elp results
   below).[1] With the previous list implementation, toggling happened
   immediately. (Note: I am not using headline cookies in conjunction
   with that particular list.)

2. Typing C-c C-x C-b on the following headline correctly checks all
   boxes; typing C-c C-x C-b again, however, does not uncheck the boxes:

--8<---------------cut here---------------start------------->8---
* TODO headline with checkboxes
  SCHEDULED: <2010-09-04 Sat +1d>
  :LOGBOOK:
  - State "DONE"       from "STARTED"    [2010-09-03 Fri 23:46]
  CLOCK: [2010-09-03 Fri 23:30]--[2010-09-03 Fri 23:46] =>  0:16
  :END:
  :PROPERTIES:
  :LAST_REPEAT: [2010-09-03 Fri 23:46]
  :END:
  
  - [ ] One
  - [ ] Two
  - [ ] Three
--8<---------------cut here---------------end--------------->8---

I believe the problem has to do with the presence of an extra list item
(i.e., the state change item). The following headline toggles all
checkboxes on and off correctly:

--8<---------------cut here---------------start------------->8---
* TODO headline with checkboxes 
  
  - [ ] One
  - [ ] Two
  - [ ] Three
--8<---------------cut here---------------end--------------->8---

Best, 

Matt

Footnotes:

[1] elp results when toggling a checkbox within a large list

--8<---------------cut here---------------start------------->8---
org-ctrl-c-ctrl-c                                             1           5.68269       5.68269
org-toggle-checkbox                                           1           5.650102      5.650102
org-update-checkbox-count-maybe                               1           5.648023      5.648023
org-update-checkbox-count                                     1           5.648003      5.648003
org-end-of-item                                               232         5.3426449999  0.0230286422
org-list-bottom-point                                         233         4.3239439999  0.0185576995
org-list-bottom-point-with-indent                             233         3.921707      0.0168313605
org-get-indentation                                           29365       1.4235310000  4.847...e-05
org-list-maybe-skip-block                                     2138        1.2333620000  0.0005768765
org-list-search-unenclosed-generic                            2376        1.1932790000  0.0005022218
org-search-backward-unenclosed                                1646        1.0381150000  0.0006306895
org-get-item-beginning                                        942         0.8054259999  0.0008550169
org-at-item-p                                                 28838       0.7241530000  2.511...e-05
org-get-end-of-item                                           232         0.570308      0.0024582241
org-get-next-item                                             232         0.5490350000  0.0023665301
org-list-get-item-same-level                                  232         0.545578      0.0023516293
org-in-item-p                                                 232         0.4611839999  0.0019878620
org-list-bottom-point-with-regexp                             233         0.2118030000  0.0009090257
org-search-forward-unenclosed                                 730         0.1853020000  0.0002538383
org-list-in-item-p-with-regexp                                232         0.1458080000  0.0006284827
org-list-in-item-p-with-indent                                232         0.1198680000  0.0005166724
org-list-ending-between                                       466         0.0946269999  0.0002030622
org-list-repair                                               1           0.030683      0.030683
org-get-end-of-list                                           11          0.0180769999  0.0016433636
org-list-struct                                               1           0.008442      0.008442
org-on-heading-p                                              466         0.0069959999  1.501...e-05
org-entry-get                                                 2           0.003465      0.0017325
org-get-property-block                                        2           0.00342       0.00171
org-at-heading-p                                              232         0.0027940000  1.204...e-05
org-checkbox-blocked-p                                        1           0.00161       0.00161
org-list-end-re                                               466         0.0013310000  2.856...e-06
org-list-struct-assoc-at-point                                13          0.0008569999  6.592...e-05
org-list-top-point                                            1           0.000853      0.000853
org-in-regexp                                                 4           0.0007769999  0.0001942499
org-back-to-heading                                           4           0.000721      0.00018025
org-footnote-at-reference-p                                   1           0.000679      0.000679
org-list-top-point-with-indent                                1           0.000507      0.000507
org-list-struct-fix-struct                                    1           0.000486      0.000486
org-babel-execute-safely-maybe                                1           0.000364      0.000364
org-babel-execute-maybe                                       1           0.000352      0.000352
org-list-struct-fix-bul                                       1           0.000313      0.000313
org-babel-execute-src-block-maybe                             1           0.000267      0.000267
org-at-item-checkbox-p                                        4           0.00026       6.5e-05
org-babel-get-src-block-info                                  1           0.000255      0.000255
org-list-top-point-with-regexp                                1           0.000232      0.000232
org-list-at-regexp-after-bullet-p                             4           0.000216      5.4e-05
org-footnote-at-definition-p                                  1           0.000186      0.000186
org-babel-where-is-src-block-head                             1           0.000137      0.000137
org-list-struct-fix-ind                                       1           0.000137      0.000137
org-list-send-list                                            1           0.000118      0.000118
org-on-target-p                                               1           9.2e-05       9.2e-05
org-activate-footnote-links                                   1           8.4e-05       8.4e-05
org-font-lock-hook                                            1           8.3e-05       8.3e-05
org-inlinetask-fontify                                        1           6.9e-05       6.9e-05
org-list-bullet-string                                        1           6.8e-05       6.8e-05
org-fontify-meta-lines-and-blocks                             1           6.8e-05       6.8e-05
org-unfontify-region                                          1           6.6e-05       6.6e-05
org-activate-plain-links                                      1           6.4e-05       6.4e-05
org-babel-lob-execute-maybe                                   1           5.7e-05       5.7e-05
org-do-emphasis-faces                                         1           4.7e-05       4.7e-05
org-at-table-p                                                2           4.6e-05       2.3e-05
org-babel-lob-get-info                                        1           4.4e-05       4.4e-05
org-at-property-p                                             1           4.2e-05       4.2e-05
org-list-struct-get-parent                                    12          3.999...e-05  3.333...e-06
org-at-table.el-p                                             1           3.9e-05       3.9e-05
org-list-inc-bullet-maybe                                     12          3.899...e-05  3.249...e-06
org-list-struct-origins                                       1           3.6e-05       3.6e-05
org-activate-dates                                            1           3.3e-05       3.3e-05
org-activate-tags                                             1           3e-05         3e-05
org-activate-angle-links                                      1           2.8e-05       2.8e-05
org-activate-bracket-links                                    1           2.2e-05       2.2e-05
org-activate-code                                             1           2.1e-05       2.1e-05
org-font-lock-add-priority-faces                              1           1.7e-05       1.7e-05
org-mode-flyspell-verify                                      2           1.499...e-05  7.499...e-06
org-babel-hash-at-point                                       1           1.2e-05       1.2e-05
org-before-change-function                                    1           1.2e-05       1.2e-05
org-remove-font-lock-display-properties                       1           1.1e-05       1.1e-05
org-hide-wide-columns                                         1           1.1e-05       1.1e-05
org-list-struct-apply-struct                                  1           9e-06         9e-06
org-region-active-p                                           1           6e-06         6e-06
org-fontify-entities                                          1           4e-06         4e-06
org-activate-target-links                                     1           4e-06         4e-06
org-raise-scripts                                             1           3e-06         3e-06
org-do-latex-and-special-faces                                1           3e-06         3e-06
org-font-lock-add-tag-faces                                   1           3e-06         3e-06
--8<---------------cut here---------------end--------------->8---

Re: [ANN] List improvement v.2

[Nicolas Goaziou]

Hello,
>>>>> Matt Lundin writes:

> 1. On my machine, toggling a checkbox within a long list takes a
> long time. I have a 200+ item list. It takes approximately 5 seconds
> for org to toggle a single checkbox within the list (see elp results
> below).[1] With the previous list implementation, toggling happened
> immediately. (Note: I am not using headline cookies in conjunction
> with that particular list.)

> 2. Typing C-c C-x C-b on the following headline correctly checks all
> boxes; typing C-c C-x C-b again, however, does not uncheck the
> boxes.

I just sent to maintainers a patch that should fix both issues. Please
tell me if it works for you when it hits master branch.

By the way, as you are using quite long lists, you might want to know
that C-c C-x C-b will be faster than C-c C-c to toggle a single item,
as C-c C-c also checks numbering, indentation, and the overall
integrity of the list.

Thank you for reporting this.

Regards,

-- Nicolas

Re: [ANN] List improvement v.2

[Carsten Dominik]

On Sat, Sep 4, 2010 at 12:24 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Hello,
>>>>>> Matt Lundin writes:
>
>> 1. On my machine, toggling a checkbox within a long list takes a
>> long time. I have a 200+ item list. It takes approximately 5 seconds
>> for org to toggle a single checkbox within the list (see elp results
>> below).[1] With the previous list implementation, toggling happened
>> immediately. (Note: I am not using headline cookies in conjunction
>> with that particular list.)
>
>> 2. Typing C-c C-x C-b on the following headline correctly checks all
>> boxes; typing C-c C-x C-b again, however, does not uncheck the
>> boxes.
>
> I just sent to maintainers a patch that should fix both issues. Please
> tell me if it works for you when it hits master branch.
>
> By the way, as you are using quite long lists, you might want to know
> that C-c C-x C-b will be faster than C-c C-c to toggle a single item,
> as C-c C-c also checks numbering, indentation, and the overall
> integrity of the list.

One possibility to improve performance would then be to have C-c C-c
not do that, but to only do that when changing a bullet type or so.

I think that C-c C-c to toggle a bullet is a good key and should be
fast, also for long lists.

- Carsten
>
> Thank you for reporting this.
>
> Regards,
>
> -- Nicolas
>

Re: [ANN] List improvement v.2

[Nicolas Goaziou]

Hello,
>>>>> Carsten Dominik writes:

> One possibility to improve performance would then be to have C-c C-c
> not do that, but to only do that when changing a bullet type or so.

> I think that C-c C-c to toggle a bullet is a good key and should be
> fast, also for long lists.

Sorry for not being clear. With the patch, C-c C-c will still be fast!
On my laptop, with a 500+ items list, C-c C-x C-b is now
instantaneous, while C-c C-c has a delay (almost unnoticeable) of
about 0.2 s (that is, both without any statistics to update).

Moreover, reducing C-c C-c to only toggle checkboxes when on a
checkboxed item will prevent anyone to fix indentation, numbering, or
integrity of a list containing only checkboxes with that key-binding.
Look at this list:

1. [ ] some
3. [ ] checkboxed
4. [ ] list

How would you repair it then? You could move an item up and down, but
it doesn't feel so natural.


The gain of speed is so small that I don't think we should bother,
with regards to what we would lose.

Regards,

-- Nicolas

Strange behavior of M-RET with new list improvements

[Anthony Lander]

Hi Nicolas & list,

I've noticed some strange behavior with the new list code when  
pressing M-RET:

Firstly, if I have a construct like this:

<-------------
*** Some heading
      - Bullet
      - Bullet
      - Bullet |
<-------------

With the cursor at |, M-RET correctly adds another list item  
(indented, and started with -). But now there is no way to make a new  
heading with M-RET, except to terminate the list with a blank line,  
and then press M-RET (even though list followed immediately by  
headline is a valid terminated list). Previously, if the cursor was at  
the beginning of the line after the last bullet, M-RET would produce a  
new heading:

<-------------
*** Some heading
      - Bullet
      - Bullet
      - Bullet
|
<-------------

(press M-RET)

<-------------
*** Some heading
      - Bullet
      - Bullet
      - Bullet
*** |
<-------------

With the new code, it produces an indented list item with -. Is there  
any way to get the old behaviour back? Perhaps a good compromise is  
that M-RET at bol produces a heading, even if logically that spot  
could continue a list? (You can continue the list with M-RET on the  
last line of the list).

The second problem is with folded headlines. Org mode behaves  
correctly, but the result is surprising for the user. If you have the  
headline above, but folded, with the cursor at the end of the line,  
like this:

<-------------
*** Some heading...|
<-------------

pressing RET to open a new line, followed by M-RET (presumably to make  
a new heading) results in the following:

<-------------
*** Some heading... 	- Bullet
	- |
<-------------

So Org is trying to make a new list item, because the previous line is  
a list item, even though it's folded. I believe that since only a  
heading is visible, that should be interpreted to mean that the user  
wants a new heading. I am not sure why the heading displays partially  
folded, and partially opened, but refolding and reopening with TAB  
shows that the structure is correct.

Thanks,

   -Anthony

Re: Strange behavior of M-RET with new list improvements

[Bernt Hansen]

Anthony Lander <anthonylander@yahoo.com> writes:

> I've noticed some strange behavior with the new list code when
> pressing M-RET:
>
> Firstly, if I have a construct like this:
>
> <-------------
> *** Some heading
>      - Bullet
>      - Bullet
>      - Bullet |
> <-------------
>
> With the cursor at |, M-RET correctly adds another list item
> (indented, and started with -). But now there is no way to make a new
> heading with M-RET, except to terminate the list with a blank line,
> and then press M-RET (even though list followed immediately by
> headline is a valid terminated list). Previously, if the cursor was at
> the beginning of the line after the last bullet, M-RET would produce a
> new heading:

Hi Anthony,

I noticed the same thing when I initially started using the new list
code.  I've just trained my fingers to use C-RET for new headlines
instead.

-Bernt

Re: Strange behavior of M-RET with new list improvements

[Anthony Lander]

On 7-Sep-10, at 7:46 AM, Bernt Hansen wrote:

> Anthony Lander <anthonylander@yahoo.com> writes:
>
>> I've noticed some strange behavior with the new list code when
>> pressing M-RET:
>>
>> Firstly, if I have a construct like this:
>>
>> <-------------
>> *** Some heading
>>     - Bullet
>>     - Bullet
>>     - Bullet |
>> <-------------
>>
>> With the cursor at |, M-RET correctly adds another list item
>> (indented, and started with -). But now there is no way to make a new
>> heading with M-RET, except to terminate the list with a blank line,
>> and then press M-RET (even though list followed immediately by
>> headline is a valid terminated list). Previously, if the cursor was  
>> at
>> the beginning of the line after the last bullet, M-RET would  
>> produce a
>> new heading:
>
> Hi Anthony,
>
> I noticed the same thing when I initially started using the new list
> code.  I've just trained my fingers to use C-RET for new headlines
> instead.

Thanks Brent. I use CUA mode pretty much all the time (dons flameproof  
suit), and rightly or wrongly, it steals C-RET. I will look at binding  
the new headline function to something, though. That's a good  
workaround.

   -Anthony




> -Bernt
>

Re: Strange behavior of M-RET with new list improvements

[Nicolas Goaziou]

Hello,
>>>>> Anthony Lander writes:

> Firstly, if I have a construct like this:

> <-------------
> *** Some heading
>       - Bullet
>       - Bullet
>       - Bullet |
> <-------------

> With the cursor at |, M-RET correctly adds another list item
> (indented, and started with -). But now there is no way to make a
> new heading with M-RET, except to terminate the list with a blank
> line, and then press M-RET (even though list followed immediately by
> headline is a valid terminated list). Previously, if the cursor was
> at the beginning of the line after the last bullet, M-RET would
> produce a new heading

As you said, the point is logically still in the list, so M-RET will
produce a new item. If you want to enforce a new heading there, you
can use C-u M-RET.

> The second problem is with folded headlines. Org mode behaves
> correctly, but the result is surprising for the user. If you have
> the headline above, but folded, with the cursor at the end of the
> line, like this:

> <------------- *** Some heading...| <-------------

> pressing RET to open a new line, followed by M-RET (presumably to
> make a new heading) results in the following:

> <------------- *** Some heading... - Bullet - | <-------------

I just sent a patch to maintainer about this. Thank you for reporting
this bug.

Regards,

-- Nicolas

[Bug] Level 2 text not exported in LaTeX (well in HTML) + some comments

[Sébastien Vauban]

Hi Nicolas,

--8<---------------cut here---------------start------------->8---
#+TITLE:     Problems in LaTeX with nested list levels
#+LANGUAGE:  en_US

* Imaginary example

We have two steps:

1) Ask for it.

2) Make it, answering the following questions:

   - Got the docs?
   - Signed them?
   - Checked it?

   THIS LINE DOES NOT SHOW UP in LaTeX!!!

After the 2-steps model, we...

* Other remarks

- Before, if I remember good, the sequence of list levels was: =-=, =+=, =*=,
  =1.= and =1)=. Now, the last two have been inverted: first, =1)=, then =1.=.
  Just a tiny detail (was used to it).

- When =S-right arrowing= this line twice, I *sometimes* get my list items
  transformed into headlines... Though, I cannot repeat with as many times as
  I want... Conditions still strange to me.

* Variables

In my =.emacs= file, I have:

#+begin_src emacs-lisp
;; an empty line does not end all plain list levels
(setq org-empty-line-terminates-plain-lists nil)

;; default value
(setq org-list-ending-method 'both)
#+end_src
--8<---------------cut here---------------end--------------->8---

Best regards,
  Seb

-- 
Sébastien Vauban


_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Bug] Level 2 text not exported in LaTeX (well in HTML) + some comments

[Eric S Fraga]

[-- Attachment #1: Type: text/plain, Size: 2565 bytes --]

On Fri, 17 Sep 2010 15:01:58 +0200, Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> wrote:
> 
> Hi Nicolas,
> 
> --8<---------------cut here---------------start------------->8---
> #+TITLE:     Problems in LaTeX with nested list levels
> #+LANGUAGE:  en_US
> 
> * Imaginary example
> 
> We have two steps:
> 
> 1) Ask for it.
> 
> 2) Make it, answering the following questions:
> 
>    - Got the docs?
>    - Signed them?
>    - Checked it?
> 
>    THIS LINE DOES NOT SHOW UP in LaTeX!!!

I can confirm this with:

: Org-mode version 7.01trans (release_7.01h.514.g878d)
: GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0)
:  of 2010-08-14 on raven, modified by Debian

it appears the nested lists within an item that is to continue makes
all remaining text within that item disappear.  I actually had this
problem three days ago with a very large document in which whole
sections disappeared but, as it was 3am, I thought it was me doing
something silly.

if the line after the nested list is not indented, it appears in the
exported file albeit not part of the enumerated list.

However, more strange behaviour appears as soon as you have multiple
nested lists.  Consider this org snippet:

--8<---------------cut here---------------start------------->8---
Consider the following list:

1. the first numbered item
   - the first item
   - the second
   - not the fourth

   followed by some paragraph that is indented which disappears on latex export.

   - another nested list but this appears in the outer list
   - as does this!

   and some more text which does appear.

and now something that is not indented.
--8<---------------cut here---------------end--------------->8---

this generates:

--8<---------------cut here---------------start------------->8---
Consider the following list:

\begin{itemize}
\item the first numbered item

\begin{itemize}
\item the first item
\item the second
\item not the fourth
\end{itemize}

\item another nested list but this appears in the outer list
\item as does this

   and some more text which does appear.
\end{itemize}

and now something that is not indented.
--8<---------------cut here---------------end--------------->8---

notice that the outer list is itemize and not enumerate.

> #+begin_src emacs-lisp
> ;; an empty line does not end all plain list levels
> (setq org-empty-line-terminates-plain-lists nil)
> 
> ;; default value
> (setq org-list-ending-method 'both)
> #+end_src

I have these same settings.

[-- Attachment #2: Type: text/plain, Size: 75 bytes --]

-- 
Eric S Fraga
GnuPG: 8F5C 279D 3907 E14A 5C29  570D C891 93D8 FFFC F67D

[-- Attachment #3: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

Re: [Bug] Level 2 text not exported in LaTeX (well in HTML) + some comments

[Nicolas Goaziou]

Hello,

>>>>> Eric S Fraga writes:

> However, more strange behaviour appears as soon as you have multiple
> nested lists.

Just to avoid any misconception: if I get it correctly, what you do
call "multiple nested lists" cannot exist.

You can have nested lists, but no more than one sub-list at each
level. As soon as a line is less indented than the preceding item of
the list, *all* sub-lists end at that line.

Regards,

-- Nicolas

Re: [Bug] Level 2 text not exported in LaTeX (well in HTML) + some comments

[Eric S Fraga]

[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]

On Sat, 18 Sep 2010 20:02:24 +0200, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> 
> Hello,
> 
> >>>>> Eric S Fraga writes:
> 
> > However, more strange behaviour appears as soon as you have multiple
> > nested lists.
> 
> Just to avoid any misconception: if I get it correctly, what you do
> call "multiple nested lists" cannot exist.
> 
> You can have nested lists, but no more than one sub-list at each
> level. As soon as a line is less indented than the preceding item of
> the list, *all* sub-lists end at that line.
> 
> Regards,
> 
> -- Nicolas

So you are saying, if I understand you correctly, that you cannot have
something like this:

--8<---------------cut here---------------start------------->8---
1. some text

   - a nested list
   - with two items

   some more text for the first numbered item

   - another nested list
   - with two items

2. the second outer list item
--8<---------------cut here---------------end--------------->8---

If so, why not?  This would seem to be quite a likely and useful
scenario.  

I do this all the time in latex and I was sure that I had done this
before in org.  Is my recollection wrong?  Was this not possible
before?

[-- Attachment #2: Type: text/plain, Size: 75 bytes --]

-- 
Eric S Fraga
GnuPG: 8F5C 279D 3907 E14A 5C29  570D C891 93D8 FFFC F67D

[-- Attachment #3: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

Re: [Bug] Level 2 text not exported in LaTeX (well in HTML) + some comments

[Nicolas Goaziou]

>>>>> Eric S Fraga writes:

> So you are saying, if I understand you correctly, that you cannot
> have something like this:

> --8<---------------cut here---------------start------------->8--- 
> 1. some text
>    - a nested list
>    - with two items
>    some more text for the first numbered item
>    - another nested list - with two items
> 2. the second outer list item 
> --8<---------------cut here---------------end--------------->8---

Exactly.

> If so, why not? This would seem to be quite a likely and useful
> scenario.

It would require a slightly different model with an added depth of
complexity. To tell the truth, I had looked into this, but hadn't
found a satisfying (clean) solution.

For example, how should Org handle indentation of such a line, or any
line within the list? Should it "round" the indentation to the closest
level of a sub-list? And if you add a new line, should the user insert
spaces to reach the desired level of sub-list, or should Org TAB-cycle
indentation through every level of the list? Wouldn't this be painful
on deeply nested lists? If the list is so long that you can't display
it's first items, what happens when you want to end the 4th of 6
sub-lists? Could you remember what proper indentation is needed?

Those questions are more rhetorical than anything else. My point is
just that this kind of scenario, while certainly doable, would need
more thought, and much more work to implement. Is it _that_ useful?

> I do this all the time in latex and I was sure that I had done this
> before in org. Is my recollection wrong? Was this not possible
> before?

As far as I remember, LaTeX exporter has never been able to parse
this, though the HTML one did.

Note that a TAB on your line of text was (i.e. in the latest stable
release) indenting it past the second nested list item. That signifies
even Org wasn't understanding properly the meaning of your list.

Regards,

-- Nicolas

Re: [Bug] Level 2 text not exported in LaTeX (well in HTML) + some comments

[Sébastien Vauban]

Hi Nicolas,

Nicolas Goaziou wrote:
>>>>>> Eric S Fraga writes:
>> So you are saying, if I understand you correctly, that you cannot have
>> something like this:
>
>> --8<---------------cut here---------------start------------->8---
>> 1. some text
>>    - a nested list
>>    - with two items
>>    some more text for the first numbered item
>>    - another nested list - with two items
>> 2. the second outer list item
>> --8<---------------cut here---------------end--------------->8---
>
> Exactly.
>
>> If so, why not? This would seem to be quite a likely and useful scenario.
>
> It would require a slightly different model with an added depth of
> complexity. To tell the truth, I had looked into this, but hadn't found a
> satisfying (clean) solution.
>
> [...]
>
> Those questions are more rhetorical than anything else. My point is just
> that this kind of scenario, while certainly doable, would need more thought,
> and much more work to implement. Is it _that_ useful?
>
>> I do this all the time in latex and I was sure that I had done this before
>> in org. Is my recollection wrong? Was this not possible before?
>
> As far as I remember, LaTeX exporter has never been able to parse this,
> though the HTML one did.

Yes, the HTML parser was often better than the LaTeX one, though I wasn't that
interested by the HTML one...

I would definitely say that, yes, being able to support the above example (or
mine) would be _that_ useful. I don't consider such written constructs as bad
writing, and hence would like Org to let me write them.

I can even tell you it was difficult to make other colleagues accept to use
Org simply because of the limitations it had in the nested lists.

Best regards,
  Seb

-- 
Sébastien Vauban


_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Bug] Level 2 text not exported in LaTeX (well in HTML) + some comments

[Eric S Fraga]

[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]

On Sun, 19 Sep 2010 11:24:09 +0200, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> 
> >>>>> Eric S Fraga writes:
> 
> > So you are saying, if I understand you correctly, that you cannot
> > have something like this:
> 
> > --8<---------------cut here---------------start------------->8--- 
> > 1. some text
> >    - a nested list
> >    - with two items
> >    some more text for the first numbered item
> >    - another nested list - with two items
> > 2. the second outer list item 
> > --8<---------------cut here---------------end--------------->8---
> 
> Exactly.
> 
> > If so, why not? This would seem to be quite a likely and useful
> > scenario.
> 
> It would require a slightly different model with an added depth of
> complexity. To tell the truth, I had looked into this, but hadn't
> found a satisfying (clean) solution.

Okay.

> For example, how should Org handle indentation of such a line, or any
> line within the list? Should it "round" the indentation to the closest
> level of a sub-list? 

Good question!  I don't know the answer to this.

[...]

> Those questions are more rhetorical than anything else. My point is
> just that this kind of scenario, while certainly doable, would need
> more thought, and much more work to implement. Is it _that_ useful?

I think it would be useful but not having it is definitely not a show
stopper!  It has come up as an issue for me recently because I have
been managing the writing of a proposal with contributions from many
authors and some of those authors like having multiple lists within
other lists.  It was when exporting a draft of the whole document that
I realised that I was losing text, but I only noticed this because I
lost a whole section which was several pages long!

I think the key is not necessarily to support multiple sub-lists
within an item but to *ensure* that no text is lost in export.  I can
see at a glance possibly whether text is formatted correctly but I
cannot tell as easily that text has been lost in export.  When working
on a 30+ page document, this is crucial.  

From your previous message, it sounds like you have a fix for the lost
text issue; that would be the main improvement for my usage.

> > I do this all the time in latex and I was sure that I had done this
> > before in org. Is my recollection wrong? Was this not possible
> > before?
> 
> As far as I remember, LaTeX exporter has never been able to parse
> this, though the HTML one did.

That could very well be.

Thanks,
eric

[-- Attachment #2: Type: text/plain, Size: 75 bytes --]

-- 
Eric S Fraga
GnuPG: 8F5C 279D 3907 E14A 5C29  570D C891 93D8 FFFC F67D

[-- Attachment #3: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

Re: [Bug] Level 2 text not exported in LaTeX (well in HTML) + some comments

[Carsten Dominik]

On Sep 19, 2010, at 11:24 AM, Nicolas Goaziou wrote:

>>>>>> Eric S Fraga writes:
>
>> So you are saying, if I understand you correctly, that you cannot
>> have something like this:
>
>> --8<---------------cut here---------------start------------->8---
>> 1. some text
>>   - a nested list
>>   - with two items
>>   some more text for the first numbered item
>>   - another nested list - with two items
>> 2. the second outer list item
>> --8<---------------cut here---------------end--------------->8---
>
> Exactly.
>
>> If so, why not? This would seem to be quite a likely and useful
>> scenario.
>
> It would require a slightly different model with an added depth of
> complexity. To tell the truth, I had looked into this, but hadn't
> found a satisfying (clean) solution.

One clean solution I can think of is to allow terminating a list with
a special item, like

    - one
      - a
      - b
      - @<       (this means sublist ends here)

One could also have - @<< to mean closing two levels.

This would allow stable indentation control.

- Carsten

>
> For example, how should Org handle indentation of such a line, or any
> line within the list? Should it "round" the indentation to the closest
> level of a sub-list? And if you add a new line, should the user insert
> spaces to reach the desired level of sub-list, or should Org TAB-cycle
> indentation through every level of the list? Wouldn't this be painful
> on deeply nested lists? If the list is so long that you can't display
> it's first items, what happens when you want to end the 4th of 6
> sub-lists? Could you remember what proper indentation is needed?
>
> Those questions are more rhetorical than anything else. My point is
> just that this kind of scenario, while certainly doable, would need
> more thought, and much more work to implement. Is it _that_ useful?
>
>> I do this all the time in latex and I was sure that I had done this
>> before in org. Is my recollection wrong? Was this not possible
>> before?
>
> As far as I remember, LaTeX exporter has never been able to parse
> this, though the HTML one did.
>
> Note that a TAB on your line of text was (i.e. in the latest stable
> release) indenting it past the second nested list item. That signifies
> even Org wasn't understanding properly the meaning of your list.
>
> 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

Re: [Bug] Level 2 text not exported in LaTeX (well in HTML) + some comments

[Sébastien Vauban]

Hi Carsten and Nicolas,

Carsten Dominik wrote:
> On Sep 19, 2010, at 11:24 AM, Nicolas Goaziou wrote:
>>>>>>> Eric S Fraga writes:
>>
>>> So you are saying, if I understand you correctly, that you cannot
>>> have something like this:
>>
>>> --8<---------------cut here---------------start------------->8---
>>> 1. some text
>>>   - a nested list
>>>   - with two items
>>>   some more text for the first numbered item
>>>   - another nested list - with two items
>>> 2. the second outer list item
>>> --8<---------------cut here---------------end--------------->8---
>>
>> Exactly.
>>
>>> If so, why not? This would seem to be quite a likely and useful
>>> scenario.
>>
>> It would require a slightly different model with an added depth of
>> complexity. To tell the truth, I had looked into this, but hadn't
>> found a satisfying (clean) solution.
>
> One clean solution I can think of is to allow terminating a list with
> a special item, like
>
>    - one
>      - a
>      - b
>      - @<       (this means sublist ends here)
>
> One could also have - @<< to mean closing two levels.
>
> This would allow stable indentation control.

And, in the case that such a construct would not be used, I wouldn't mind
having to manually indent the paragraph where I want to place it, as long as
the indentation is used to decide to what the text must be attached to.

(thinking at backward-compatibility solution)

Best regards,
  Seb

-- 
Sébastien Vauban


_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Re: [Bug] Level 2 text not exported in LaTeX (well in HTML) + some comments

[Nicolas Goaziou]

Hello,

>>>>> Sébastien Vauban writes:

> And, in the case that such a construct would not be used, I wouldn't
> mind having to manually indent the paragraph where I want to place
> it, as long as the indentation is used to decide to what the text
> must be attached to.

Please (re-)read my "rhetorical" questions: this is not as simple as
it sounds.

> (thinking at backward-compatibility solution)

I have to disagree here, as those constructs were only partly
recognized (and partly broken): again, LaTeX exporter and
auto-indentation weren't aware about them.

Anyway, before thinking at backward-compatibility, the design should
be fixed first. Now, on the other hand, there's Carsten's "ASCII duck
head" idea...

Well, I still can't help thinking those constructs are ill-defined and
can be avoided by reorganizing the list, or using headings. Even those
do not support such constructs, for a good reason.

Regards,

-- Nicolas

Re: [Bug] Level 2 text not exported in LaTeX (well in HTML) + some comments

[Nicolas Goaziou]

Hello,

>>>>> Sébastien Vauban writes:

> 1) Ask for it.

> 2) Make it, answering the following questions:

>    - Got the docs?
>    - Signed them?
>    - Checked it?

>    THIS LINE DOES NOT SHOW UP in LaTeX!!!

The whole list should indeed end at this line. I sent a patch
correcting this.

> * Other remarks

> - Before, if I remember good, the sequence of list levels was: =-=,
>   =+=, =*=, =1.= and =1)=. Now, the last two have been inverted:
>   first, =1)=, then =1.=. Just a tiny detail (was used to it).

I hadn't noticed that before and the doc-string of
`org-cycle-list-bullet' says you are right. Fixed.

> - When =S-right arrowing= this line twice, I *sometimes* get my list
>   items transformed into headlines... Though, I cannot repeat with as
>   many times as I want... Conditions still strange to me.

I cannot reproduce it at the moment. Please tell me if you have more
data about it.

Regards,

-- Nicolas

Re: [Bug] Level 2 text not exported in LaTeX (well in HTML) + some comments

[Sébastien Vauban]

Hi Nicolas,

Nicolas Goaziou wrote:
>>>>>> Sébastien Vauban writes:
>
>> 1) Ask for it.
>
>> 2) Make it, answering the following questions:
>
>>    - Got the docs?
>>    - Signed them?
>>    - Checked it?
>
>>    THIS LINE DOES NOT SHOW UP in LaTeX!!!
>
> The whole list should indeed end at this line. I sent a patch
> correcting this.

I do see the text exported now. Though, it's not located where I expect to see
it...

It is text that still belongs to enumerated item #2, as shown by the
indentation. Is this possible?


>> * Other remarks
>
>> - Before, if I remember good, the sequence of list levels was: =-=,
>>   =+=, =*=, =1.= and =1)=. Now, the last two have been inverted:
>>   first, =1)=, then =1.=. Just a tiny detail (was used to it).
>
> I hadn't noticed that before and the doc-string of
> `org-cycle-list-bullet' says you are right. Fixed.

Thanks.


>> - When =S-right arrowing= this line twice, I *sometimes* get my list
>>   items transformed into headlines... Though, I cannot repeat with as
>>   many times as I want... Conditions still strange to me.
>
> I cannot reproduce it at the moment. Please tell me if you have more
> data about it.

This is a very bad behavior when it happens. But it must be very confined to
certain user behaviors, as I have problems trying to reproduce it now. I'll
tell you as soon as it happens.

Best regards,
  Seb

-- 
Sébastien Vauban


_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode