Re: [Orgmode] [ANN] List improvement v.2
On Thu, 2 Sep 2010 10:13:09 +0200, Carsten Dominik carsten.domi...@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 :-). -- Eric S Fraga GnuPG: 8F5C 279D 3907 E14A 5C29 570D C891 93D8 FFFC F67D ___ 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: [Orgmode] [ANN] List improvement v.2
Eric S Fraga ucec...@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 ___ 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: [Orgmode] [ANN] List improvement v.2
On Fri, 03 Sep 2010 16:34:36 +0200, Nicolas Goaziou n.goaz...@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 -- Eric S Fraga GnuPG: 8F5C 279D 3907 E14A 5C29 570D C891 93D8 FFFC F67D ___ 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: [Orgmode] [ANN] List improvement v.2
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
Re: [Orgmode] [ANN] List improvement v.2
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,
Re: [Orgmode] [ANN] List improvement v.2
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
Re: [Orgmode] [ANN] List improvement v.2
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 ___ 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: [Orgmode] [ANN] List improvement v.2
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 ___ 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: [Orgmode] [ANN] List improvement v.2
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.goaz...@gmail.comwrote: 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
Re: [Orgmode] [ANN] List improvement v.2
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 ___ 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: [Orgmode] [ANN] List improvement v.2
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 ___ 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: [Orgmode] [ANN] List improvement v.2
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.goaz...@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
[Orgmode] [ANN] List improvement v.2
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,
