[ANN] Changes to lists

[ANN] Changes to lists

[Nicolas Goaziou]

Hello,

I would like to announce, and submit to discussion, some list code
upgrades. So, let me introduce the changes done in development branch:

* Major changes

  1) It is possible (again) to have indentation of text determine the
     current level of the list. But this time, the 3 main exporters
     handle it. In other words, you can have:

     - a list
       - a sub-list
       Some text belonging to main list.
       - and even another sub-list

     This is on by default (with org-list-ending-method set to 'both).

  2) There is now support for finite alphabetical lists, thanks to
     Nathaniel Naff. This is off by default and activated by the
     variable `org-alphabetical-lists'.

     This also recognizes counters like [@c] in addition to normal
     counters (i.e. [@3]). For now, counters only affect matching
     bullets, so [@c] have no effect on a numbered list. Though, they
     will during export, where [@c] is the same as [@3].

     In original patch, bullet type was passed to HTML and DocBook
     exporters. I removed that part of the code for various reasons:

     - It wasn't consistent across every exporter ;
     - While it sounds nice in HTML and, maybe, DocBook, it is,
       usually, a bad idea to enforce bullet types in LaTeX ;
     - It should be the job of style files ;
     - Org should otherwise provide, at least, roman numbering, in
       order to give a real choice to the user, as alphabetical and
       numbered ordered lists are somewhat limited with regards to
       what exporters standardly offer.

     Thus, setting a list to alphabetical bullets will not ensure
     export will have them too. To sum it up, alphabetical lists are
     some cosmetics applied to lists in an Org buffer only. Here
     comes:

     a. Some list with an alphabetical bullet
        W. [@W] Upper case letters are also allowed.

  3) As announced before, lists can now contain drawers, inline tasks,
     and blocks, themselves containing lists. Two variables (one for
     the Org buffer, and one for exporters) are controlling this:
     `org-list-forbidden-blocks' (by default no list can live in
     example, verse, and src blocks), and `org-list-export-context'
     (lists in valid blocks and in inline tasks will be exported by
     default).

     + an example of a list
       #+begin_center
       1. with another list
       2. in a block
       #+end_center
     + and now another item

     As a special case, inline tasks, though starting at column 0, are
     always considered part of the first item above in the list.
     Consider the following example, with (require 'org-inlinetask),
     and try moving first sub-item, or exporting:

     - A list with
       + A sub-list
*************** TODO Stuff waiting
                1. First good reason to delay the task
                2. Second good reason to delay it
*************** END
       + Another sub-item

  4) Improve `newline-and-indent' (C-j): used in an item, it will keep
     text from moving at column 0. This allows to split text and make
     paragraphs while not breaking list. For example, type C-j twice
     at ¦, then M-q:

     + I have this quite long item. Now I'd like to start a new
       paragraph there. ¦This should be the beginning of the new
       paragraph.

  5) Improve `org-toggle-item' (C-c -): used on a region, it will
     change the region into *one* item. With a prefix argument, it
     will fallback to previous behavior and make every line in region
     an item. It permits to easily add paragraphs inside a close list.
     For example, if you mark the paragraph below, and use C-c -, it
     will be added to the list above it:

     #+begin_quote
     1. A list strolling around

     A paragraph that should be included in the list. Just select it
     and use C-c -.
     #+end_quote


* Bug fixes

  There are also some bug fixes. To name the visible ones:

  - Fix for checkboxes and cookies handling.

  - Export correctly sub-lists counters in LaTeX.

  - List are sturdier with regards to Babel printing output inside
    them.

  - Fix list to subtree transformation (with C-c C-*), as much as
    possible. Indeed, there is no equivalency between these
    constructs, mainly due to major change #1.


* What now?

  While Bernt Hansen helped me a lot already, some more testing would
  be appreciated. The repository is at:

          git://github.com/ngz/org-mode-lists.git new-struct

  It supersedes "recursive-lists" branch, submitted to the ML a few
  weeks ago.

  I'm open to ideas, suggestions, and criticism.

  Regards,

-- 
Nicolas

Re: [ANN] Changes to lists

[Nicolas Goaziou]

>   2) There is now support for finite alphabetical lists, thanks to
>      Nathaniel Naff.

Oops, I meant Nathaniel Flath.

-- Nicolas

Re: [ANN] Changes to lists

[Carsten Dominik]

Hi Nicolas,

this is very impressive.  Thanks so much for bringing
back sublists with intersected text.

>     In original patch, bullet type was passed to HTML and DocBook
>     exporters. I removed that part of the code for various reasons:


I am not sure if I understand this.  What was passed through in
the original patch, and what have you changed?


Also a first little thing I have found:

   1. a list
      - a sub-list
      - shslkjg kj
      - dsjkg kajhg
      Some text belonging to main list.
      - and even another sub-list
      - aksjdf alkjshf
      aslkdjf lkjasdflkj aklsjdfh klasj

If I go to the end of the last line and press M-RET it
fails with the backtrace below.  Not sure what it should
do in this case, but my preferred result would be to create the
"2." item for the first list.

Thanks!

- Carsten

Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p  
nil)
   goto-char(nil)
   (let* ((item ...) (item-end ...) (item-end-no-blank ...)  
(beforep ...) (split-line-p ...) (blank-nb ...) (ind ...) (bullet ...)  
(box ...) (text-cut ...) (body ...) (item-sep ...) (item-size ...)  
(size-offset ...)) (goto-char item) (org-indent-to-column ind) (insert  
body) (insert item-sep) (mapc (lambda ... ...) struct) (push (list  
item ind bullet nil box nil ...) struct) (setq struct (sort  
struct ...)) (if beforep (goto-char item) (setq struct ...) (goto- 
char ...)) struct)
   (let ((case-fold-search t)) (let*  
(... ... ... ... ... ... ... ... ... ... ... ... ... ...) (goto-char  
item) (org-indent-to-column ind) (insert body) (insert item-sep)  
(mapc ... struct) (push ... struct) (setq struct ...) (if  
beforep ... ... ...) struct))
   org-list-insert-item(215 ((15 2 "1. " nil nil nil 216) (27 5 "- "  
nil nil nil 45) (45 5 "- " nil nil nil 63) (63 5 "- " nil nil nil 82)  
(121 5 "- " nil nil nil 154) (154 5 "- " nil nil nil 177)) ((15) (27)  
(45 . 27) (63 . 45) (121) (154 . 121)) nil nil)
   (setq struct (org-list-insert-item pos struct prevs checkp desc))
   (let* ((struct ...) (prevs ...) (desc ...) (checkp ...)) (setq  
struct (org-list-insert-item pos struct prevs checkp desc)) (org-list- 
write-struct struct (org-list-parents-alist struct)) (when checkp (org- 
update-checkbox-count-maybe)) (looking-at org-list-full-item-re) (goto- 
char (match-end 0)) t)
   (if (save-excursion (goto-char itemp) (org-at-item-timer-p)) (progn  
(org-timer-item) t) (goto-char itemp) (let* (... ... ... ...) (setq  
struct ...) (org-list-write-struct struct ...) (when checkp ...)  
(looking-at org-list-full-item-re) (goto-char ...) t))
   (if (or (not itemp) (save-excursion ... ...)) nil (if (save- 
excursion ... ...) (progn ... t) (goto-char itemp)  
(let* ... ... ... ... ... ... t)))
   (unless (or (not itemp) (save-excursion ... ...)) (if (save- 
excursion ... ...) (progn ... t) (goto-char itemp)  
(let* ... ... ... ... ... ... t)))
   (let ((itemp ...) (pos ...)) (unless (or ... ...)  
(if ... ... ... ...)))
   org-insert-item()
   (not (org-insert-item))
   (or force-heading (not (org-insert-item)))
   (if (or force-heading (not ...)) (progn  
(let* ... ... ... ... ... ... ... ... ...)))
   (when (or force-heading (not ...)) (let* (... ... ... ... ... ...  
pos hide-previous previous-pos) (cond ... ... ...) (insert head) (just- 
one-space) (setq pos ...) (end-of-line 1) (unless ... ... ...)  
(when ... ...) (run-hooks ...)))
   (if (or (= ... 0) (and ... ...)) (progn (insert "\n* ") (run- 
hooks ...)) (when (or force-heading ...)  
(let* ... ... ... ... ... ... ... ... ...)))
   org-insert-heading(nil)
   call-interactively(org-insert-heading)
   (cond ((run-hook-with-args-until-success ...)) ((org-at-table-p)  
(call-interactively ...)) (t (call-interactively ...)))
   org-meta-return(nil)
   call-interactively(org-meta-return nil

On Jan 23, 2011, at 10:59 PM, Nicolas Goaziou wrote:

> Hello,
>
> I would like to announce, and submit to discussion, some list code
> upgrades. So, let me introduce the changes done in development branch:
>
> * Major changes
>
>  1) It is possible (again) to have indentation of text determine the
>     current level of the list. But this time, the 3 main exporters
>     handle it. In other words, you can have:
>
>     - a list
>       - a sub-list
>       Some text belonging to main list.
>       - and even another sub-list
>
>     This is on by default (with org-list-ending-method set to 'both).
>
>  2) There is now support for finite alphabetical lists, thanks to
>     Nathaniel Naff. This is off by default and activated by the
>     variable `org-alphabetical-lists'.
>
>     This also recognizes counters like [@c] in addition to normal
>     counters (i.e. [@3]). For now, counters only affect matching
>     bullets, so [@c] have no effect on a numbered list. Though, they
>     will during export, where [@c] is the same as [@3].
>
>     In original patch, bullet type was passed to HTML and DocBook
>     exporters. I removed that part of the code for various reasons:
>
>     - It wasn't consistent across every exporter ;
>     - While it sounds nice in HTML and, maybe, DocBook, it is,
>       usually, a bad idea to enforce bullet types in LaTeX ;
>     - It should be the job of style files ;
>     - Org should otherwise provide, at least, roman numbering, in
>       order to give a real choice to the user, as alphabetical and
>       numbered ordered lists are somewhat limited with regards to
>       what exporters standardly offer.
>
>     Thus, setting a list to alphabetical bullets will not ensure
>     export will have them too. To sum it up, alphabetical lists are
>     some cosmetics applied to lists in an Org buffer only. Here
>     comes:
>
>     a. Some list with an alphabetical bullet
>        W. [@W] Upper case letters are also allowed.
>
>  3) As announced before, lists can now contain drawers, inline tasks,
>     and blocks, themselves containing lists. Two variables (one for
>     the Org buffer, and one for exporters) are controlling this:
>     `org-list-forbidden-blocks' (by default no list can live in
>     example, verse, and src blocks), and `org-list-export-context'
>     (lists in valid blocks and in inline tasks will be exported by
>     default).
>
>     + an example of a list
>       #+begin_center
>       1. with another list
>       2. in a block
>       #+end_center
>     + and now another item
>
>     As a special case, inline tasks, though starting at column 0, are
>     always considered part of the first item above in the list.
>     Consider the following example, with (require 'org-inlinetask),
>     and try moving first sub-item, or exporting:
>
>     - A list with
>       + A sub-list
> *************** TODO Stuff waiting
>                1. First good reason to delay the task
>                2. Second good reason to delay it
> *************** END
>       + Another sub-item
>
>  4) Improve `newline-and-indent' (C-j): used in an item, it will keep
>     text from moving at column 0. This allows to split text and make
>     paragraphs while not breaking list. For example, type C-j twice
>     at ¦, then M-q:
>
>     + I have this quite long item. Now I'd like to start a new
>       paragraph there. ¦This should be the beginning of the new
>       paragraph.
>
>  5) Improve `org-toggle-item' (C-c -): used on a region, it will
>     change the region into *one* item. With a prefix argument, it
>     will fallback to previous behavior and make every line in region
>     an item. It permits to easily add paragraphs inside a close list.
>     For example, if you mark the paragraph below, and use C-c -, it
>     will be added to the list above it:
>
>     #+begin_quote
>     1. A list strolling around
>
>     A paragraph that should be included in the list. Just select it
>     and use C-c -.
>     #+end_quote
>
>
> * Bug fixes
>
>  There are also some bug fixes. To name the visible ones:
>
>  - Fix for checkboxes and cookies handling.
>
>  - Export correctly sub-lists counters in LaTeX.
>
>  - List are sturdier with regards to Babel printing output inside
>    them.
>
>  - Fix list to subtree transformation (with C-c C-*), as much as
>    possible. Indeed, there is no equivalency between these
>    constructs, mainly due to major change #1.
>
>
> * What now?
>
>  While Bernt Hansen helped me a lot already, some more testing would
>  be appreciated. The repository is at:
>
>          git://github.com/ngz/org-mode-lists.git new-struct
>
>  It supersedes "recursive-lists" branch, submitted to the ML a few
>  weeks ago.
>
>  I'm open to ideas, suggestions, and criticism.
>
>  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] Changes to lists

[Nicolas Goaziou]

Hello,

>>>>> Carsten Dominik writes:

>> In original patch, bullet type was passed to HTML and DocBook
>> exporters. I removed that part of the code for various reasons.

> I am not sure if I understand this. What was passed through in the
> original patch, and what have you changed?

In original patch, when you had a list with alphabetical bullets, you
would also have alphabetical bullets in HTML export (same for
DocBook).

Now, bullet type in Org buffer has no influence whatsoever on export.

> Also a first little thing I have found:

>    1. a list 
>       - a sub-list
>       - shslkjg kj
>       - dsjkg kajhg
>       Some text belonging to main list.
>       - and even another sub-list
>       - aksjdf alkjshf
>       aslkdjf lkjasdflkj aklsjdfh klasj

> If I go to the end of the last line and press M-RET it fails with
> the backtrace below. Not sure what it should do in this case, but my
> preferred result would be to create the "2." item for the first
> list.

I cannot reproduce it. I get "2." as expected. Odd.

Regards,

-- 
Nicolas

Re: [ANN] Changes to lists

[Bernt Hansen]

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

> Hello,
>
>>>>>> Carsten Dominik writes:
>
>>> In original patch, bullet type was passed to HTML and DocBook
>>> exporters. I removed that part of the code for various reasons.
>
>> I am not sure if I understand this. What was passed through in the
>> original patch, and what have you changed?
>
> In original patch, when you had a list with alphabetical bullets, you
> would also have alphabetical bullets in HTML export (same for
> DocBook).
>
> Now, bullet type in Org buffer has no influence whatsoever on export.
>
>> Also a first little thing I have found:
>
>>    1. a list 
>>       - a sub-list
>>       - shslkjg kj
>>       - dsjkg kajhg
>>       Some text belonging to main list.
>>       - and even another sub-list
>>       - aksjdf alkjshf
>>       aslkdjf lkjasdflkj aklsjdfh klasj
>
>> If I go to the end of the last line and press M-RET it fails with
>> the backtrace below. Not sure what it should do in this case, but my
>> preferred result would be to create the "2." item for the first
>> list.
>
> I cannot reproduce it. I get "2." as expected. Odd.
>
> Regards,

I tried reproducing it too and failed...until I added 2 blank lines
BEFORE the list.

Then I get the same error as Carsten.

-Bernt

--8<---------------cut here---------------start------------->8---
* Lists


  1. a list
     - a sub-list
     - shslkjg kj
     - dsjkg kajhg
     Some text belonging to main list.
     - and even another sub-list
     - aksjdf alkjshf
     aslkdjf lkjasdflkj aklsjdfh klasj
--8<---------------cut here---------------end--------------->8---

Re: [ANN] Changes to lists

[Nicolas Goaziou]

>>>>> Bernt Hansen writes:

> I tried reproducing it too and failed...until I added 2 blank lines
> BEFORE the list.

Ok. Spotted and fixed. Thanks to Carsten and you.

Re: [ANN] Changes to lists

[Sébastien Vauban]

Hi Nicolas,

Carsten Dominik wrote:
> this is very impressive.  Thanks so much for bringing
> back sublists with intersected text.

With some delay... let me thank your for incorporating this feature. I really
wanted it, and I'm very glad you could make it.

Ex-cel-lent!

Thank you,
  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: [ANN] Changes to lists

[Achim Gratz]

Nicolas Goaziou <n.goaziou@gmail.com> writes:
>   While Bernt Hansen helped me a lot already, some more testing would
>   be appreciated. The repository is at:
>
>           git://github.com/ngz/org-mode-lists.git new-struct
>
>   It supersedes "recursive-lists" branch, submitted to the ML a few
>   weeks ago.

Can I access through http://, as I'll be behind a firewall for testing?
Also, the repository is a clone of the orgmode.git, so your branch
should work as a remote to another clone of the same, right?


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: Re: [ANN] Changes to lists

[Nicolas Goaziou]

Hello,

>>>>> Achim Gratz writes:

> Can I access through http://, as I'll be behind a firewall for
> testing?

I guess you can clone instead:

          http://github.com/ngz/org-mode-lists.git new-struct

> Also, the repository is a clone of the orgmode.git, so your branch
> should work as a remote to another clone of the same, right?

Yes, it should.

Regards,

-- 
Nicolas

Re: [ANN] Changes to lists

[Achim Gratz]

Nicolas Goaziou <n.goaziou@gmail.com> writes:
>  http://github.com/ngz/org-mode-lists.git

Thanks, that works nicely - should be working fine from work I guess.
Just been trying to do a make, there are a few undeclared items you may
want to check upon:

In org-in-item-p:
org-list.el:443:41:Warning: reference to free variable `org-drawer-regexp'

In org-list-context:
org-list.el:508:59:Warning: reference to free variable `org-drawers'

In org-list-struct:
org-list.el:624:57:Warning: reference to free variable `org-drawers'

In org-list-get-children:
org-list.el:977:40:Warning: assignment to free variable `child'
org-list.el:978:13:Warning: reference to free variable `child'

In org-list-bullet-string:
org-list.el:1719:1:Warning: defsubst `org-list-bullet-string' was used before
    it was defined

In org-toggle-checkbox:
org-list.el:2038:35:Warning: reference to free variable `org-drawer-regexp'

In org-list-parse-list:
org-list.el:2606:28:Warning: reference to free variable `parse-item'

In org-list-to-generic:
org-list.el:2830:11:Warning: reference to free variable `export-sublist'

In end of data:
org-list.el:2942:1:Warning: the following functions are not known to be
    defined: org-inlinetask-outline-regexp, org-count, org-current-level,
    org-previous-line-empty-p


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Re: [ANN] Changes to lists

[Nicolas Goaziou]

Hello,

>>>>> Achim Gratz writes:

> Just been trying to do a make, there are a few undeclared items you
> may want to check upon:

Compiling should be clean now. Thank you.

Regards,

--
Nicolas

Re: [ANN] Changes to lists

[Samuel Wales]

You asked for comments and suggestions.

Adding inline tasks sounds like a great way to allow all sorts of
things.  I like that.

I never have anyin various ways would lists at column 0.  I always
want the top level at column 2.  Supporting this would be great.  C-c
- not putting lists at column 0 (optionally) and demoting top level
would be useful.

I'd like to see c-c - on headlines preserve hierarchy.

On current org version I still have issues with indentation, but they
are minor.  I will just do 2 blank lines after lists.

Thanks.

Re: [ANN] Changes to lists

[Samuel Wales]

On 2011-01-24, Samuel Wales <samologist@gmail.com> wrote:
> I never have anyin various ways would lists at column 0.  I always

That should be "I almost never want lists at column 0".

In particular I frequently do c-c - then use c-x r o.

The only time I want lists at column 0 is if I do something like this,
where indentation is violated anyway.

1.  something

paragraph.

another

2.  something

another

Re: [ANN] Changes to lists

[Nicolas Goaziou]

Hello,

>>>>> Samuel Wales writes:

> I never have anyin various ways would lists at column 0. I always
> want the top level at column 2. Supporting this would be great.
> C-c - not putting lists at column 0 (optionally) 

There is already support for that. Use M-S-right or M-S-left on top
item of a list to move the whole list to any column.

> and demoting top level would be useful.

Just promote every item but the first one using a region.

> I'd like to see c-c - on headlines preserve hierarchy.

I can look into that.

Regards,

--
Nicolas

Re: [ANN] Changes to lists

[Nicolas Goaziou]

Hello,

>>>>> Samuel Wales writes:

> I'd like to see c-c - on headlines preserve hierarchy.

This is now implemented, and hopefully working.

Thanks for suggesting this,

Regards,

--
Nicolas

Re: [ANN] Changes to lists

[Samuel Wales]

Hi Nicolas,

I tried c-c - on

  - indented text and it worked perfectly, preserving hierarchy
  - headlines and it did not preserve hierarchy

I tried c-c * on

  - indented text and it did not preserve hierarchy
  - a list and it did not preserve hierarchy

Latest git.

Samuel

On 2011-02-10, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Hello,
>
>>>>>> Samuel Wales writes:
>
>> I'd like to see c-c - on headlines preserve hierarchy.
>
> This is now implemented, and hopefully working.
>
> Thanks for suggesting this,
>
> Regards,
>
> --
> Nicolas
>


-- 
The Kafka Pandemic:
http://thekafkapandemic.blogspot.com/2010/12/welcome-to-kafka-pandemic-two-forces_9182.html
I support the Whittemore-Peterson Institute (WPI)
===
I want to see the original (pre-hold) Lo et al. 2010 NIH/FDA/Harvard MLV paper.

Re: [ANN] Changes to lists

[Nicolas Goaziou]

Hello,

>>>>> Samuel Wales writes:

> Latest git.

This is on list devel branch, not on master branch yet.

Regards,

--
Nicolas

Re: [ANN] Changes to lists

[Karl Maihofer]

Nicolas,

Nicolas Goaziou <n.goaziou <at> gmail.com> writes:
> I would like to announce, and submit to discussion, some list code
> upgrades. So, let me introduce the changes done in development branch:

Great! Thanks a lot. I just tested the inline task part and have an issue with
demoting of list items, please see below.

>      As a special case, inline tasks, though starting at column 0, are
>      always considered part of the first item above in the list.
>      Consider the following example, with (require 'org-inlinetask),
>      and try moving first sub-item, or exporting:
> 
>      - A list with
>        + A sub-list
> *************** TODO Stuff waiting
>                 1. First good reason to delay the task
>                 2. Second good reason to delay it
> *************** END
>        + Another sub-item

Pressing M-<right> with the cursor on "Item 2" in the example below inserts a
space before the inline task, so that it's no longer recognized as a task.

----------------------------------- Example ----------------------------------
- Item 1
- Item 2
  - Item 2.1

*************** Inline Task
Text
*************** END

  - Item 2.2
- Item 3
-------------------------------------------------------------------------------

Kind regards,
Karl

Re: Re: [ANN] Changes to lists

[Nicolas Goaziou]

Hello,

>>>>> Karl Maihofer writes:

> Pressing M-<right> with the cursor on "Item 2" in the example below
> inserts a space before the inline task, so that it's no longer
> recognized as a task.

> - Item 1 
> - Item 2
>   - Item 2.1
>
> *************** Inline Task 
>   Text
> *************** END
>
>   - Item 2.2
> - Item 3

Fixed and pushed. I also repaired wrong indentation of text inside the
task.

Thanks for reporting this.

Regards,

--
Nicolas

Re: Re: [ANN] Changes to lists

[Karl Maihofer]

Nicolas,

thanks, demoting works now as expected.

I do have another issue when I export inline tasks:

1. If the inline task doesn't have a "headline", there is an empty  
space before the content of the inline task. I think in earlier  
versions it wasn't there. See item 2 in the example below. I sometimes  
use inline tasks just to comment a line of my lists, so I do not use a  
TODO-state nor a "headline" for that inline task. Perhaps it is a good  
idea not to use just <b></b> and <br> but a div-container (for the  
"headline" and another one for the text below of it) to be able to use  
CSS for formatting?

2. Lists in inline tasks are not exported properly (item 2a in the  
example below).

Thanks a lot for your work!!

---------------------------- begin example  
----------------------------------------
Test

- item 1
*************** TODO Inline Task
Test
*************** END
- item 2
***************
Inline Task without a "headline"
*************** END
   - item 2a
*************** TODO Inline Task
Text, and a list:
- item 1
   - item 1a
   - item 1b
- item 2
*************** END
   - item 2b
- item 3
-------------------------------- end example ---------------------------------


Regards,
Karl


Zitat von Nicolas Goaziou <n.goaziou@gmail.com>:
> Hello,
>
>>>>>> Karl Maihofer writes:
>
>> Pressing M-<right> with the cursor on "Item 2" in the example below
>> inserts a space before the inline task, so that it's no longer
>> recognized as a task.
>
>> - Item 1
>> - Item 2
>>   - Item 2.1
>>
>> *************** Inline Task
>>   Text
>> *************** END
>>
>>   - Item 2.2
>> - Item 3
>
> Fixed and pushed. I also repaired wrong indentation of text inside the
> task.
>
> Thanks for reporting this.
>
> 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: Re: [ANN] Changes to lists

[Karl Maihofer]

Nicolas,

I found another bug. When I put the cursor on item 2 in my example and  
cycle through with TAB, I get the following:

TAB once:

- item 2...

another TAB:

- item 2
***************
Inline Task without a "headline"
*************** END
   - item 2a...         (=> item 2b is missing!!)

third TAB: all

It seems as if the list in the inline task confuses the cycle functionality.

Regards,
Karl



Zitat von Karl Maihofer <ignoramus@gmx.de>:
> ---------------------------- begin example  
> ----------------------------------------
> Test
>
> - item 1
> *************** TODO Inline Task
> Test
> *************** END
> - item 2
> ***************
> Inline Task without a "headline"
> *************** END
>   - item 2a
> *************** TODO Inline Task
> Text, and a list:
> - item 1
>   - item 1a
>   - item 1b
> - item 2
> *************** END
>   - item 2b
> - item 3
> -------------------------------- end example  
> ---------------------------------
>
>
> Regards,
> Karl
>
>
> Zitat von Nicolas Goaziou <n.goaziou@gmail.com>:
>> Hello,
>>
>>>>>>> Karl Maihofer writes:
>>
>>> Pressing M-<right> with the cursor on "Item 2" in the example below
>>> inserts a space before the inline task, so that it's no longer
>>> recognized as a task.
>>
>>> - Item 1
>>> - Item 2
>>>  - Item 2.1
>>>
>>> *************** Inline Task
>>>  Text
>>> *************** END
>>>
>>>  - Item 2.2
>>> - Item 3
>>
>> Fixed and pushed. I also repaired wrong indentation of text inside the
>> task.
>>
>> Thanks for reporting this.
>>
>> 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
>

Re: Re: [ANN] Changes to lists

[Nicolas Goaziou]

>>>>> Karl Maihofer writes:

> It seems as if the list in the inline task confuses the cycle
> functionality.

Folding has been fixed, but you will need to use "git pull -f".

Regards,

--
Nicolas

Re: Re: [ANN] Changes to lists

[Nicolas Goaziou]

Hello,

>>>>> Karl Maihofer writes:

> I do have another issue when I export inline tasks:

> 1. If the inline task doesn't have a "headline", there is an empty
> space before the content of the inline task. I think in earlier
> versions it wasn't there. See item 2 in the example below. I
> sometimes use inline tasks just to comment a line of my lists, so I
> do not use a TODO-state nor a "headline" for that inline task.
> Perhaps it is a good idea not to use just <b></b> and <br> but a
> div-container (for the "headline" and another one for the text below
> of it) to be able to use CSS for formatting?

There is no support for inline tasks without a headline. Most of the
regexps refering to inline tasks need some space after the stars. If
you still want to use that, you should tweak
org-inlinetask-export-templates.

> 2. Lists in inline tasks are not exported properly (item 2a in the
> example below).

This should be fixed now. Thanks.

Regards,

--
Nicolas

Re: [ANN] Changes to lists

[Karl Maihofer]

Nicolas,

Nicolas Goaziou <n.goaziou <at> gmail.com> writes:
> > 2. Lists in inline tasks are not exported properly (item 2a in the
> > example below).
> 
> This should be fixed now. Thanks.

This does not work for me. Lists in inline tasks are still exported as follows:

*
  item 1
*
  item 2

What do I miss?

Regards,
Karl

Re: Re: [ANN] Changes to lists

[Nicolas Goaziou]

Hello,

>>>>> Karl Maihofer writes:

> This does not work for me. Lists in inline tasks are still exported
> as follows:

> *
>   item 1
> *
>   item 2

> What do I miss?

Well, nothing. I just pushed a small patch to remove unneeded newline
characters. It does help a bit in you situation.

Though, the default HTML template for inline tasks encloses them in a
<pre> tag. Thus, you have to keep in mind export will be very
sensitive to white space or newlines anyway. If it doesn't fit your
needs, you can always configure org-inlinetask-export-templates.

Regards,

--
Nicolas

Re: [ANN] Changes to lists

[Achim Gratz]

Hi Nicolas,

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

I've found some time today to install the new-struct branch at my work
machine.  Things look good so far and the checkboxes have started to
work again. :-)

I've briefly switched on alphabetical lists and that has worked quite
well on the lists I tried it on.  None of them were overly long, though.

There's another regression with regards to checkboxes vs. the "old"
7.01h that I've noticed.  If sublists are put into drawers, then
checkboxes depending on that sublist are not updated with your new
version and progress boxes on that sublist will always be at [0%] and
[0/0].  The hierarchy inside the drawer is correctly updated as well as
anything around the drawer.  Try the folloing testcase:

--8<---------------cut here---------------start------------->8---
#+DRAWERS: CLOSED

* [1/3] List Checkbox Test

  - [-][%] First [/] <-- this will be updated
    + [ ] Sub1
    + [ ] Sub2
    + [X] Sub3
  - [-] Second
    :CLOSED:
    + [-] [%] Sub1 [/] <-- this will not be updated
      * [ ] Subsub1
      * [ ] Subsub2
      * [X] Subsub3
    + [X] Sub2
    + [X] Sub3
    :END:
  - [X] Third
    + [X] Sub1
    + [X] Sub2
    + [X] Sub3
--8<---------------cut here---------------end--------------->8---

In this case "Second" will not be recognized to have a sublist with the
new version, while it was at 7.01h.  It is debatable what the "correct"
behaviour is, but if in doubt I'd opt for keeping it backwards
compatible.  Another slight oddity is present in the HTML export of this
list:

--8<---------------cut here---------------start------------->8---
<ul>
<li>
[-] First
<ul>
<li>
<b>[<span style="visibility:hidden;">X</span>]</b> Sub1
</li>
<li>
<b>[<span style="visibility:hidden;">X</span>]</b> Sub2
</li>
<li>
<b>[X]</b> Sub3
</li>
</ul>
</li>
<li>
<b>[X]</b> Second
</li>
<li>
[-] Third
<ul>
<li>
<b>[X]</b> Sub1
</li>
<li>
<b>[<span style="visibility:hidden;">X</span>]</b> Sub2
</li>
<li>
<b>[X]</b> Sub3
</li>
</ul>
</li>
</ul>
--8<---------------cut here---------------end--------------->8---

The unfinished checkboxes and progress cookies are not boldened as they
are in Orgmode itself and putting a hidden "X" inside the not begun
checkboxes is somewhat tenous as the "hidden" attribute might not be
honored (as happens for example if you display with "no style").
Putting a non-breaking space there might be a better idea.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: Re: [ANN] Changes to lists

[Nicolas Goaziou]

Hello,

>>>>> Achim Gratz writes:

> There's another regression with regards to checkboxes vs. the "old"
> 7.01h that I've noticed. If sublists are put into drawers, then
> checkboxes depending on that sublist are not updated with your new
> version and progress boxes on that sublist will always be at [0%]
> and [0/0].

[...]

> In this case "Second" will not be recognized to have a sublist with
> the new version, while it was at 7.01h. It is debatable what the
> "correct" behaviour is, but if in doubt I'd opt for keeping it
> backwards compatible. 

Lists in drawers (or blocks, or inline tasks) are, now, completely
unrelated to outer parts of the buffer. Even though you make it look
like the list in the drawer is in continuity of the other one, it is
not the case. As a corollary, boxes in such a list cannot be seen by a
cookie living outside the structure they share.

> Another slight oddity is present in the HTML export of this list:

[...]

> The unfinished checkboxes and progress cookies are not boldened as
> they are in Orgmode itself and putting a hidden "X" inside the not
> begun checkboxes is somewhat tenous as the "hidden" attribute might
> not be honored (as happens for example if you display with "no
> style"). Putting a non-breaking space there might be a better idea.

As far as I can remember, I did not change this behavior. Though, I
don't mind boldening empty and unfinished checkboxes as well, nor I do
mind exchanging the hidden attribute for a non-breaking space.

What do others users think about this ?

Regards,

--
Nicolas

Re: [ANN] Changes to lists

[Achim Gratz]

Nicolas Goaziou <n.goaziou@gmail.com> writes:
> Lists in drawers (or blocks, or inline tasks) are, now, completely
> unrelated to outer parts of the buffer. Even though you make it look
> like the list in the drawer is in continuity of the other one, it is
> not the case. As a corollary, boxes in such a list cannot be seen by a
> cookie living outside the structure they share.

Fair enough.  Since this behaves different than the former
implementation it should be documented as a user-visible change.  So far
I've been using the drawers only to prevent fully completed checklists
from cluttering the display.  This is maybe a somewhat odd use for a
drawer, but the reason for using this was that the VISIBILITY property
wasn't evaluated for lists.  I'll have to think of maybe doing a feature
request towards this end.

Two more things I've stumbled over.  

1) If you open a new list after another list, M-RET will not produce a
new list item, but yet another new list:

--8<---------------cut here---------------start------------->8---
- list 1
- entry
- more entries

- list 2 <-- M-RET

- <-- is produced by M-RET
--8<---------------cut here---------------end--------------->8---

2) Last but not least: sublist folding (visibility cycling) has stopped
working.  I can unfold an entry folded by an earlier version of
org-mode, but trying to fold the sublist again I'll only get "EMPTY
ENTRY" in the mode line (but no error beep or something like that).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

Re: Re: [ANN] Changes to lists

[Nicolas Goaziou]

Hello,

>>>>> Achim Gratz writes:

> 1) If you open a new list after another list, M-RET will not produce
> a new list item, but yet another new list:

> --8<---------------cut here---------------start------------->8---
> - list 1 
> - entry
> - more entries

> - list 2 <-- M-RET

> - <-- is produced by M-RET
> --8<---------------cut here---------------end--------------->8---

You did not open a new list. By default, 2 blank lines are required to
end a list. In fact, you just added a new item to the previous list,
separated from others by a blank line. M-RET tries to be smart and
separate items with a blank line from that point.

> 2) Last but not least: sublist folding (visibility cycling) has
> stopped working. I can unfold an entry folded by an earlier version
> of org-mode, but trying to fold the sublist again I'll only get
> "EMPTY ENTRY" in the mode line (but no error beep or something like
> that).

Could you provide an example? I fail to see what's wrong, as folding
is fine on my test file.

Regards,

--
Nicolas

Re: [ANN] Changes to lists

[Achim Gratz]

Nicolas Goaziou <n.goaziou@gmail.com> writes:
> You did not open a new list. By default, 2 blank lines are required to
> end a list. In fact, you just added a new item to the previous list,
> separated from others by a blank line. M-RET tries to be smart and
> separate items with a blank line from that point.

Ah, OK - that wasn't clear to me.

> Could you provide an example? I fail to see what's wrong, as folding
> is fine on my test file.

--8<---------------cut here---------------start------------->8---
- List
  free text inside list
  over some lines (this folds)
  - sublist (this doesn't fold including subsequent entries)
  - more entries
  inline text after sublist doesn't fold, either
--8<---------------cut here---------------end--------------->8---

Also, fill-paragraph doesn't know about inline text unless you are using
blank lines atop.  That's probably to be expected, but in case there's
something one can do about it I'd like to know - I'd like to have no
blank lines if possible.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: Re: [ANN] Changes to lists

[Nicolas Goaziou]

Hello,

>>>>> Achim Gratz writes:

> Also, fill-paragraph doesn't know about inline text unless you are
> using blank lines atop. That's probably to be expected, but in case
> there's something one can do about it I'd like to know - I'd like to
> have no blank lines if possible.

I think folding and filling should behave better now. You will need to
force a branch update, as I rebased the repo against master.

Regards,

--
Nicolas

Re: [ANN] Changes to lists

[Achim Gratz]

Nicolas Goaziou <n.goaziou@gmail.com> writes:
> I think folding and filling should behave better now. You will need to
> force a branch update, as I rebased the repo against master.

Works wonderfully well with the limited testcase I have here at home.  I
expect it will do just as well with my stuff at work, I'll let you know
in a few days.  Thank you!


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: Re: [ANN] Changes to lists

[David Maus]

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

At Thu, 27 Jan 2011 21:39:03 +0100,
Nicolas Goaziou wrote:
>
> > The unfinished checkboxes and progress cookies are not boldened as
> > they are in Orgmode itself and putting a hidden "X" inside the not
> > begun checkboxes is somewhat tenous as the "hidden" attribute might
> > not be honored (as happens for example if you display with "no
> > style"). Putting a non-breaking space there might be a better idea.
>
> As far as I can remember, I did not change this behavior. Though, I
> don't mind boldening empty and unfinished checkboxes as well, nor I do
> mind exchanging the hidden attribute for a non-breaking space.
>
> What do others users think about this ?

The non-breaking space in an unchecked item would not (necessarily) be
as wide as the X in a checked item.  But a checkbox list that does not
align is in my eyes far better than unchecked items that appear as
checked when viewed w/o CSS.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de

[-- Attachment #1.2: Type: application/pgp-signature, Size: 230 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: Re: [ANN] Changes to lists

[Nicolas Goaziou]

Hello,

>>>>> David Maus writes:

> The non-breaking space in an unchecked item would not (necessarily)
> be as wide as the X in a checked item. But a checkbox list that does
> not align is in my eyes far better than unchecked items that appear
> as checked when viewed w/o CSS.

I've pushed a change in that direction. Unchecked boxes do not rely
anymore on visibility:hidden style property.

Regards,

--
Nicolas

Re: [ANN] Changes to lists

[Achim Gratz]

Nicolas Goaziou <n.goaziou@gmail.com> writes:
> I've pushed a change in that direction. Unchecked boxes do not rely
> anymore on visibility:hidden style property.

Looks OK, but the space should probably be replaced by &nbsp; to avoid
possible tearing of the checkbox.  The regex for matching does not
catch "[-]", which explains why this type of checkbox is not boldened.
I think something like

	      (if (string-match "^[ \t]*\\[\\([X -]\\)\\]" line)
		  (setq line
			(replace-match
			 (if (equal (match-string 1 line) " ")
			     "<b>[&nbsp]</b>"
			   (concat "<b>[" (match-string 1 line) "]</b>")
			 t t line))))

should work, but I don't have enough experience with the string
replacement functions to be sure that it always does.

Meanwhile I've encountered the same questionable construct in the HTML
export of "\\___" (whitespace placeholder).


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: Re: [ANN] Changes to lists

[Nicolas Goaziou]

Hello,

>>>>> Achim Gratz writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>> I've pushed a change in that direction. Unchecked boxes do not rely
>> anymore on visibility:hidden style property.

> Looks OK, but the space should probably be replaced by &nbsp; to
> avoid possible tearing of the checkbox. The regex for matching does
> not catch "[-]", which explains why this type of checkbox is not
> boldened. I think something like

Checkboxes are not boldened anymore since that patch. They are
enclosed in <code> tags. You may be, somehow, looking at old code.

Regards,

--
Nicolas

Re: [ANN] Changes to lists

[Achim Gratz]

Nicolas Goaziou <n.goaziou@gmail.com> writes:
> Checkboxes are not boldened anymore since that patch. They are
> enclosed in <code> tags. You may be, somehow, looking at old code.

Indeed I was on a branch that hadn't been fully merged with your latest
changes, sorry for the confusion.  But I sustain the suggestion for
&nbsp; instead of a space character. :-)


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Re: [ANN] Changes to lists

[Nicolas Goaziou]

>>>>> Achim Gratz writes:

> But I sustain the suggestion for   instead of a space
> character. :-)

Done. You may need to use -f flag.

Thank you for the suggestion,

--
Nicolas

Re: [ANN] Changes to lists

[Achim Gratz]

Nicolas Goaziou <n.goaziou@gmail.com> writes:
> Thank you for the suggestion,

Thank you for consideration and implementation.


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: [ANN] Changes to lists

[Achim Gratz]

Achim Gratz <Stromeko@nexgo.de> writes:
> I've found some time today to install the new-struct branch at my work
> machine.  Things look good so far and the checkboxes have started to
> work again. :-)

I've since been working with the code (and doing the occasional pull)
without noticing any ill effects.  I'd like to see this included in the
next official orgmode release.

Thank you Nicolas!


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [ANN] Changes to lists

[Eric S Fraga]

Nicolas,

a possible bug with respect to export to latex of lists which contain
babel code.  The following example:

--8<---------------cut here---------------start------------->8---
# -*- coding: utf-8; -*-
#+TITLE:     examplebug.org
#+AUTHOR:    Eric S Fraga
#+EMAIL:     e.fraga@ucl.ac.uk
#+OPTIONS:   H:3 num:t toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
#+OPTIONS:   TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc

* babel results overwrite following text 

  1. start an item so that following is indented:

     #+begin_src octave :var x=10
3*x+5
     #+end_src

     #+results:
     : 35

  2. a second item starts here
--8<---------------cut here---------------end--------------->8---

with or without the "3*x+5" indented to line up with the # on the lines
before and after, generates the following latex code snippet:

--8<---------------cut here---------------start------------->8---
\begin{enumerate}
\item start an item so that following is indented:

\lstset{language=octave}
\begin{lstlisting}
     3*x+5
\end{lstlisting}
\end{enumerate}
\begin{enumerate}
\item a second item starts here
\end{enumerate}
--8<---------------cut here---------------end--------------->8---

Note the ending and immediate starting of an enumerate environment after
the listing corresponding to the babel octave code.

By the way, although a fix that required the babel code to be indented
to the same level as the meta statements would be satisfactory, a
solution that allowed code within the block to be indented to any
position would be more welcome.  Code written in the mode associated
with the particular language will often be automatically indented...

Thanks,
eric
-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.4 (release_7.4.260.gba0f6.dirty)

Re: [ANN] Changes to lists

[Eric S Fraga]

(may be rude to followup on my own post but...)

Further on the problem with exporting a list with a babel code block:
if I ask the results to be exported as well as the code (code only is
the default) via:

     #+begin_src octave :var x=10 :exports both

the export works correctly and generates:

--8<---------------cut here---------------start------------->8---
\begin{enumerate}
\item start an item so that following is indented:

\lstset{language=octave}
\begin{lstlisting}
3*x+5
\end{lstlisting}

\begin{verbatim}
      35
\end{verbatim}

\item a second item starts here
\end{enumerate}
--8<---------------cut here---------------end--------------->8---

Interesting!  Just an extra data point... ;-)

Thanks again,
eric

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.4 (release_7.4.260.gba0f6.dirty)

Re: [ANN] Changes to lists

[Nicolas Goaziou]

Hello,

> Note the ending and immediate starting of an enumerate environment
> after the listing corresponding to the babel octave code.

I cannot reproduce it with:

-----
* babel results overwrite following text 

  1. start an item so that following is indented:

     #+begin_src emacs-lisp :var x=10
(+ (* 3 x) 6)
     #+end_src

     #+results:
     : 36

  2. a second item starts here
-----

Are you sure it still happens with a recent branch? Is it specific to
octave?

> By the way, although a fix that required the babel code to be
> indented to the same level as the meta statements would be
> satisfactory, a solution that allowed code within the block to be
> indented to any position would be more welcome. Code written in the
> mode associated with the particular language will often be
> automatically indented...

Normally, lists should not pay attention to anything inside blocks so
I highly doubt it is related to indentation of code.

Sorry for not being very helpful here.

Regards,

--
Nicolas

Re: [ANN] Changes to lists

[Eric S Fraga]

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

> Hello,
>
>> Note the ending and immediate starting of an enumerate environment
>> after the listing corresponding to the babel octave code.
>
> I cannot reproduce it with:
>
> -----
> * babel results overwrite following text 
>
>   1. start an item so that following is indented:
>
>      #+begin_src emacs-lisp :var x=10
> (+ (* 3 x) 6)
>      #+end_src
>
>      #+results:
>      : 36
>
>   2. a second item starts here
> -----
>
> Are you sure it still happens with a recent branch? Is it specific to
> octave?

The short example file I included in my original message now works just
fine.  The error was definitely present in

: Org-mode version 7.4 (release_7.4.260.gba0f6.dirty)

but is fixed in the current version:

: Org-mode version 7.4 (release_7.4.302.gd840.dirty)

By the way, the /dirty/ bit comes from a minor change I made to
ob-octave's definition of variables, a change which does not affect the
export.

>> By the way, although a fix that required the babel code to be
>> indented to the same level as the meta statements would be
>> satisfactory, a solution that allowed code within the block to be
>> indented to any position would be more welcome. Code written in the
>> mode associated with the particular language will often be
>> automatically indented...
>
> Normally, lists should not pay attention to anything inside blocks so
> I highly doubt it is related to indentation of code.

Okay.  That was just a guess!

> Sorry for not being very helpful here.

No problem!  Everything's fine now so some other change has fixed
things; I'm happy :)

Thanks,
eric

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.4 (release_7.4.302.gd840.dirty)

Re: [ANN] Changes to lists

[Eric S Fraga]

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

> Hello,
>
>> Note the ending and immediate starting of an enumerate environment
>> after the listing corresponding to the babel octave code.
>
> I cannot reproduce it with:
>
> -----
> * babel results overwrite following text 
>
>   1. start an item so that following is indented:
>
>      #+begin_src emacs-lisp :var x=10
> (+ (* 3 x) 6)
>      #+end_src
>
>      #+results:
>      : 36
>
>   2. a second item starts here
> -----
>
> Are you sure it still happens with a recent branch? Is it specific to
> octave?

The short example file I included in my original message now works just
fine.  The error was definitely present in

: Org-mode version 7.4 (release_7.4.260.gba0f6.dirty)

but is fixed in the current version:

: Org-mode version 7.4 (release_7.4.302.gd840.dirty)

By the way, the /dirty/ bit comes from a minor change I made to
ob-octave's definition of variables, a change which does not affect the
export.

>> By the way, although a fix that required the babel code to be
>> indented to the same level as the meta statements would be
>> satisfactory, a solution that allowed code within the block to be
>> indented to any position would be more welcome. Code written in the
>> mode associated with the particular language will often be
>> automatically indented...
>
> Normally, lists should not pay attention to anything inside blocks so
> I highly doubt it is related to indentation of code.

Okay.  That was just a guess!

> Sorry for not being very helpful here.

No problem!  Everything's fine now so some other change has fixed
things; I'm happy :)

Thanks,
eric

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.4 (release_7.4.302.gd840.dirty)

Re: [ANN] Changes to lists

[Eric S Fraga]

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

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

[...]

> Normally, lists should not pay attention to anything inside blocks so
> I highly doubt it is related to indentation of code.

The on-going saga of lists and blocks!  Sorry about this...

Attached is a simple org file which includes latex, html and babel
source code blocks:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: example list with blocks --]
[-- Type: text/orgmode, Size: 870 bytes --]

# -*- coding: utf-8; -*-
#+TITLE:     examplebug.org
#+AUTHOR:    Eric S Fraga
#+EMAIL:     e.fraga@ucl.ac.uk
#+OPTIONS:   H:3 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
#+OPTIONS:   TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:nil
#+latex_header: \usepackage{tikz}

* latex code block within list
  1. I have a list
  2. with several items
  3. and then one of them includes some latex:
     #+begin_latex
\begin{tikzpicture}[x=2cm,y=2cm]
  \draw [red] (0,0) -- (2,2);
\end{tikzpicture}
     #+end_latex
  4. subsequent list items start a new list
  5. if we include some html
     #+begin_html
<img src="mip.png" alt="Mixed integer programming">
     #+end_html
  6. that works fine.
  7. if we include a babel code block
     #+begin_src octave :exports code :var x=20
3*x+5
     #+end_src

     #+results:
     : 65
  8. that also works just fine.



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


The latter two do not cause any problems with an
enumerated list; the first does unfortunately.  I've attached the
resulting latex file as well.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: latex code generated by org export --]
[-- Type: text/x-tex, Size: 1164 bytes --]

% Created 2011-02-06 Sun 15:29
\documentclass{scrartcl}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{fixltx2e}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{float}
\usepackage{wrapfig}
\usepackage{soul}
\usepackage{textcomp}
\usepackage{marvosym}
\usepackage[integrals]{wasysym}
\usepackage{latexsym}
\usepackage{amssymb}
\usepackage{hyperref}
\tolerance=1000
\usepackage{xcolor}
\usepackage{listings}
\usepackage{amsmath}
\usepackage{tikz}
\providecommand{\alert}[1]{\textbf{#1}}
\begin{document}



\title{examplebug.org}
\author{Eric S Fraga}
\date{06 February 2011}
\maketitle


\section*{latex code block within list}
\label{sec-1}

\begin{enumerate}
\item I have a list
\item with several items
\item and then one of them includes some latex:
\end{enumerate}
\begin{tikzpicture}[x=2cm,y=2cm]
  \draw [red] (0,0) -- (2,2);
\end{tikzpicture}

\begin{enumerate}
\item subsequent list items start a new list
\item if we include some html
\item that works fine.
\item if we include a babel code block
\lstset{language=octave}
\begin{lstlisting}
3*x+5
\end{lstlisting}
\item that also works just fine.
\end{enumerate}

\end{document}

[-- Attachment #5: Type: text/plain, Size: 312 bytes --]



Any suggestions?  I cannot see why latex, html and babel should be
handled any differently...  I guess I could move from using begin_latex
to "begin_src latex" instead?

Thanks,
eric

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.4 (release_7.4.317.gca220.dirty)

[-- Attachment #6: 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] Changes to lists

[Nicolas Goaziou]

Hello,

>>>>> Eric S Fraga writes:

> Any suggestions? I cannot see why latex, html and babel should be
> handled any differently... I guess I could move from using
> begin_latex to "begin_src latex" instead?

Function replacing blocks was not setting `original-indentation'
property.

This should be fixed now. Could you confirm this?

Regards,

--
Nicolas

Re: [ANN] Changes to lists

[Eric S Fraga]

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

> Hello,
>
>>>>>> Eric S Fraga writes:
>
>> Any suggestions? I cannot see why latex, html and babel should be
>> handled any differently... I guess I could move from using
>> begin_latex to "begin_src latex" instead?
>
> Function replacing blocks was not setting `original-indentation'
> property.
>
> This should be fixed now. Could you confirm this?

I cannot because your changes do not seem to have propagated
through... =git pull= tells me "Already up-to-date" and =git log= tells
me that the most recent commit was

,----
| commit ca220e9c40e4467f436a0a1501fb1fd730093cec
| Merge: 68cf793 73be48b
| Author: Carsten Dominik <carsten.dominik@gmail.com>
| Date:   Sun Feb 6 08:14:58 2011 +0100
| 
|     Merge branch 'fix-todo-list-with-extended-today'
`----

I'm eager to try your fix, mind you!

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.4 (release_7.4.317.gca220.dirty)

Re: [ANN] Changes to lists

[Nicolas Goaziou]

>>>>> Eric S Fraga writes:

> I cannot because your changes do not seem to have propagated
> through...

Commit looks ok on github, so it should be available. Did you try
"pull -f"? I rebased against master a few days ago.

Regards,

--
Nicolas