[BUG] adding new plain lists item changes previous one it it ends in a number on a single lijne followed by a dot

[BUG] adding new plain lists item changes previous one it it ends in a number on a single lijne followed by a dot

[Gregor Zattler]

Dear org-mode developers,

adding a new list item via M-RET (org-insert-heading) may change
text in a previous list item, if this ends in a number on a
single line followed by a dot:

-------------------------------
- Several astonishing things happened in
  2007.
- And then there was another item.X
-------------------------------

When typing M-RET with cursor at X I would expect the following
outcome (again with X marking the cursor position):

-------------------------------
- Several astonishing things happened in
  2007.
- And then there was another item.
- X
-------------------------------

This is the correct result when using Emacs 23.2 with its
org-mode 6.33.


But with today's org-mode "Org-mode version 7.5
(release_7.4.300.g0b7c)" I instead get:

-------------------------------
- Several astonishing things happened in
    1. 
- And then there was another item.
- X
-------------------------------

Note that "  2007." has changed to "    1." in line 2.


The same bug is present in the maintenance version "Org-mode
version 7.5 (release_7.4.3.g76a2)".


This only happens when the number is followed by a dot.  Without
the dot both new versions of org-mode do not change the number on
the last line of the first item.


I did all tests with "emacs -nw -Q" and with Emacs 23.2 and
24.0.50 as of 2011-01-16.


Fixing bugs in org-mode is beyond me.

Ciao; Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: [BUG] adding new plain lists item changes previous one it it ends in a number on a single lijne followed by a dot

[Jeff Horn]

I can reproduce this in org-mode 7.4 with emacs 24.

This occurs most often for me when listing a bibliography in a plain
list when I have auto-fill-mode on.

On Wed, Feb 2, 2011 at 2:20 PM, Gregor Zattler <telegraph@gmx.net> wrote:
> Dear org-mode developers,
>
> adding a new list item via M-RET (org-insert-heading) may change
> text in a previous list item, if this ends in a number on a
> single line followed by a dot:
>
> -------------------------------
> - Several astonishing things happened in
>  2007.
> - And then there was another item.X
> -------------------------------
>
> When typing M-RET with cursor at X I would expect the following
> outcome (again with X marking the cursor position):
>
> -------------------------------
> - Several astonishing things happened in
>  2007.
> - And then there was another item.
> - X
> -------------------------------
>
> This is the correct result when using Emacs 23.2 with its
> org-mode 6.33.
>
>
> But with today's org-mode "Org-mode version 7.5
> (release_7.4.300.g0b7c)" I instead get:
>
> -------------------------------
> - Several astonishing things happened in
>    1.
> - And then there was another item.
> - X
> -------------------------------
>
> Note that "  2007." has changed to "    1." in line 2.
>
>
> The same bug is present in the maintenance version "Org-mode
> version 7.5 (release_7.4.3.g76a2)".
>
>
> This only happens when the number is followed by a dot.  Without
> the dot both new versions of org-mode do not change the number on
> the last line of the first item.
>
>
> I did all tests with "emacs -nw -Q" and with Emacs 23.2 and
> 24.0.50 as of 2011-01-16.
>
>
> Fixing bugs in org-mode is beyond me.
>
> Ciao; Gregor
> --
>  -... --- .-. . -.. ..--.. ...-.-
>
> _______________________________________________
> 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
>



-- 
Jeffrey Horn
http://www.failuretorefrain.com/jeff/

Re: [BUG] adding new plain lists item changes previous one it it ends in a number on a single lijne followed by a dot

[Nicolas Goaziou]

Hello,

>>>>> Gregor Zattler writes:

> adding a new list item via M-RET (org-insert-heading) may change
> text in a previous list item, if this ends in a number on a single
> line followed by a dot:

> ------------------------------- 
> - Several astonishing things happened in 
>   2007. 
> - And then there was another item. 
> - X
> -------------------------------

> Note that " 2007." has changed to " 1." in line 2.

Yes, and unfortunately, I don't see any solution here. It isn't really
a bug: a line starting with white space, followed by a number sticked
to a dot is exactly the definition, regexp wise, of a list item (as
explained in `org-plain-list-ordered-item-terminator' doc-string).
That's why removing the dot solves the problem.

There are two workarounds I can think of, at the moment:

1. Use (setq org-plain-list-ordered-item-terminator ?)). But that will
   affect every ordered list.
2. Insert some invisible char (non-breaking space " ") in front of the
   item, or just after the dot. But this requires manual changes every
   time the problem arises.


As a side-note, this problem isn't specific to recent versions of Org.
For example, in 6.33, use M-RET at X in the following example:

> ------------------------------- 
> - Several astonishing things happened in 
>   2007. And then there was another item.X
> -------------------------------

Regards,

--
Nicolas

Re: [BUG] adding new plain lists item changes previous one it it ends in a number on a single lijne followed by a dot

[Christian Moe]

Hi,

For once, I have to disagree: Numbers at the beginning of the line 
inadvertently starting a list item is a bug.

It means you can mess up your exported document (it doesn't just 
happen at M-RET) by just writing a perfectly normal text, and there is 
no easy-to-remember escape. (I really don't like the invisible-space 
workaround -- it's hard to remember how to insert it, and it's a 
bizarre trick to have to tell newcomers.)

ReStructuredText provides a backslash-escape for this, even though its 
more rigid structure reduces the chances of the error happening.

Could we borrow that trick, or would it conflict with something else?
E.g.

-------------------------------
- Several astonishing things happened in
    \2007.
- And then there was another item.
- X
-------------------------------

Yours,
Christian

On 2/2/11 10:16 PM, Nicolas Goaziou wrote:
> Hello,
>
>>>>>> Gregor Zattler writes:
>
>> adding a new list item via M-RET (org-insert-heading) may change
>> text in a previous list item, if this ends in a number on a single
>> line followed by a dot:
>
>> -------------------------------
>> - Several astonishing things happened in
>>    2007.
>> - And then there was another item.
>> - X
>> -------------------------------
>
>> Note that " 2007." has changed to " 1." in line 2.
>
> Yes, and unfortunately, I don't see any solution here. It isn't really
> a bug: a line starting with white space, followed by a number sticked
> to a dot is exactly the definition, regexp wise, of a list item (as
> explained in `org-plain-list-ordered-item-terminator' doc-string).
> That's why removing the dot solves the problem.
> There are two workarounds I can think of, at the moment:
>
> 1. Use (setq org-plain-list-ordered-item-terminator ?)). But that will
>     affect every ordered list.
> 2. Insert some invisible char (non-breaking space " ") in front of the
>     item, or just after the dot. But this requires manual changes every
>     time the problem arises.
>
>
> As a side-note, this problem isn't specific to recent versions of Org.
> For example, in 6.33, use M-RET at X in the following example:
>
>> -------------------------------
>> - Several astonishing things happened in
>>    2007. And then there was another item.X
>> -------------------------------
>
> 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: [BUG] adding new plain lists item changes previous one it it ends in a number on a single lijne followed by a dot

[Nicolas Goaziou]

Hello,

>>>>> Christian Moe writes:

> Numbers at the beginning of the line inadvertently starting a list
> item is a bug.

You call it a bug, but it is actually the Org definition of a numbered
item. This is in the manual. Though, I think I understand what you
mean: this definition can lead to surprising results. But the user is
warned in the documentation.

> It means you can mess up your exported document (it doesn't just
> happen at M-RET) by just writing a perfectly normal text, and there
> is no easy-to-remember escape. (I really don't like the
> invisible-space workaround -- it's hard to remember how to insert
> it, and it's a bizarre trick to have to tell newcomers.)

See the solution 1 posted before. This is the "original" solution,
although, admittedly, similar problems will resurface with numbers and
parenthesis, albeit less frequently.

> ReStructuredText provides a backslash-escape for this, even though
> its more rigid structure reduces the chances of the error happening.
> Could we borrow that trick, or would it conflict with something
> else?

I don't follow you here. Inserting a non-breaking space (it was only
an example, by the way) is an unacceptable trick to tell to newcomers
but adding a backslash in front of numbers isn't? It looks the same to
me.

As long as Org cannot tell between an ordered item and a number at the
end of a sentence, those problems will persist. And I can't see any
non-hackish solution about it.

We can always change `org-plain-list-ordered-item-terminator' default
value to the safer ?), though.

Regards,

--
Nicolas

Re: [BUG] adding new plain lists item changes previous one it it ends in a number on a single lijne followed by a dot

[Jeff Horn]

On Thu, Feb 3, 2011 at 9:09 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Hello,
>
>>>>>> Christian Moe writes:
>
>> Numbers at the beginning of the line inadvertently starting a list
>> item is a bug.
>
> You call it a bug, but it is actually the Org definition of a numbered
> item. This is in the manual. Though, I think I understand what you
> mean: this definition can lead to surprising results. But the user is
> warned in the documentation.

What about a compromise? I envision an editable variable called
"org-plain-list-regexp-delimiter" (in the same vein as
"org-export-latex-emphasis-alist") that is a list of delimiters
recognized for plain lists. I rarely use periods (always use
parentheses), so the value of this variable could default to the
current behavior, but be customizable to remove specific delimiters
from the list.

-- 
Jeffrey Horn
http://www.failuretorefrain.com/jeff/

Re: [BUG] adding new plain lists item changes previous one it it ends in a number on a single lijne followed by a dot

[Nicolas Goaziou]

Hello,

>>>>> Jeff Horn writes:

> What about a compromise? I envision an editable variable called
> "org-plain-list-regexp-delimiter" (in the same vein as
> "org-export-latex-emphasis-alist") that is a list of delimiters
> recognized for plain lists. I rarely use periods (always use
> parentheses), so the value of this variable could default to the
> current behavior, but be customizable to remove specific delimiters
> from the list.

It is certainly doable, but it wouldn't help for the problem at hand.
There is already a way to not use dots (this is the solution you
envision), but only parenthesis, as numbered items separators.

Regards,

--
Nicolas

Re: [BUG] adding new plain lists item changes previous one it it ends in a number on a single lijne followed by a dot

[Jeff Horn]

On Thu, Feb 3, 2011 at 11:47 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> It is certainly doable, but it wouldn't help for the problem at hand.
> There is already a way to not use dots (this is the solution you
> envision), but only parenthesis, as numbered items separators.

Is there a variable? It would appear there is. It seems like it should
solve the problem. Anyone know why it doesn't?

,----[ org-plain-list-ordered-item-terminator ]
| The character that makes a line with leading number an ordered list item.
| Valid values are ?. and ?).  To get both terminators, use t.  While
| ?. may look nicer, it creates the danger that a line with leading
| number may be incorrectly interpreted as an item.  ?) therefore is
| the safe choice.
`----

-- 
Jeffrey Horn
http://www.failuretorefrain.com/jeff/

Re: [BUG] adding new plain lists item changes previous one it it ends in a number on a single lijne followed by a dot

[Christian Moe]

On 2/3/11 3:09 PM, Nicolas Goaziou wrote:
> Hello,
>
>>>>>> Christian Moe writes:
>
>> Numbers at the beginning of the line inadvertently starting a list
>> item is a bug.
>
> You call it a bug, but it is actually the Org definition of a numbered
> item. This is in the manual. Though, I think I understand what you
> mean: this definition can lead to surprising results. But the user is
> warned in the documentation.

I'm sorry, that was silly of me, and I take it back. You and Achim 
Gratz are both right. If it follows from the specification, and the 
manual warns about it, it's not a bug.  I'm usually the first to point 
that out to others... don't know what got into me.

>
>> It means you can mess up your exported document (it doesn't just
>> happen at M-RET) by just writing a perfectly normal text, and there
>> is no easy-to-remember escape. (I really don't like the
>> invisible-space workaround -- it's hard to remember how to insert
>> it, and it's a bizarre trick to have to tell newcomers.)

>> ReStructuredText provides a backslash-escape for this, even though
>> its more rigid structure reduces the chances of the error happening.
>> Could we borrow that trick, or would it conflict with something
>> else?
>
> I don't follow you here. Inserting a non-breaking space (it was only
> an example, by the way) is an unacceptable trick to tell to newcomers
> but adding a backslash in front of numbers isn't? It looks the same to
> me.

Sorry I put it that way, that wasn't helpful. Backslash too was just 
an example. In this case, an example of a typical escape character 
that's right there on my keyboard. I'm not saying it looks better than 
what you get with `C-q 240' or similar, but it's easy to remember.

> As long as Org cannot tell between an ordered item and a number at the
> end of a sentence, those problems will persist. And I can't see any
> non-hackish solution about it.

Absolutely.

> We can always change `org-plain-list-ordered-item-terminator' default
> value to the safer ?), though.

As you've pointed out, there's a setting for us to tweak if we want 
this, and changing the default would probably cause greater annoyances 
for more people. So I'm not urging that.

I'll try to make friends with the invisible non-breaking space.
:)

Yours,
Christian

Re: [BUG] adding new plain lists item changes previous one it it ends in a number on a single lijne followed by a dot

[Achim Gratz]

Christian Moe <mail@christianmoe.com> writes:
> For once, I have to disagree: Numbers at the beginning of the line
> inadvertently starting a list item is a bug.

Something that is a direct result of the specification can't be usefully
called a bug of the implementation.  It may still be unexpected and/or
unwanted behaviour, so I like to call it an accidental feature.

Please not that it can (by specification) happen to other list
constructs just as well - and given the chance, it will.  Let me try:

--8<---------------cut here---------------start------------->8---
1. This is an awfully constructed example of how I might mess up (1, 2,
  3) - oops, I just did.  I might have triggered a different accidental
  feature if my linewrap would have been set two columns later.  How's
  that looking to you?
--8<---------------cut here---------------end--------------->8---

> It means you can mess up your exported document (it doesn't just
> happen at M-RET) by just writing a perfectly normal text, and there is
> no easy-to-remember escape. (I really don't like the invisible-space
> workaround -- it's hard to remember how to insert it, and it's a
> bizarre trick to have to tell newcomers.)

Again, this is the result of syntactic convenience for the common case.
This sort of thing tends to break less common cases, which is precisely
the reason TeX macros are sprinkled with seemingly superfluous {} at
every conceivable word boundary.


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

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: adding new plain lists item changes previous one it it ends in a number on a single lijne followed by a dot

[Gregor Zattler]

Hi Nicolas,

* Nicolas Goaziou <n.goaziou@gmail.com> [02. Feb. 2011]:
>>>>>> Gregor Zattler writes:
> 
>> adding a new list item via M-RET (org-insert-heading) may change
>> text in a previous list item, if this ends in a number on a single
>> line followed by a dot:
> 
>> ------------------------------- 
>> - Several astonishing things happened in 
>>   2007. 
>> - And then there was another item. 
>> - X
>> -------------------------------
> 
>> Note that " 2007." has changed to " 1." in line 2.
> 
> Yes, and unfortunately, I don't see any solution here. It isn't really
> a bug: a line starting with white space, followed by a number sticked
> to a dot is exactly the definition, regexp wise, of a list item (as
> explained in `org-plain-list-ordered-item-terminator' doc-string).

I understand that blank-number-dot starts a plain list item.
But in my example the numbered list would be second level whilst
the unordered list would be first level (of indentation).
Org-mode rightly inserts a dash but why does it fiddle with
another list item of different (second) level when inserting an
new first level item?  Is this necessary to in order to insert
the next dashed item?  

That's different to your example:

> As a side-note, this problem isn't specific to recent versions of Org.
> For example, in 6.33, use M-RET at X in the following example:
> 
>> ------------------------------- 
>> - Several astonishing things happened in 
>>   2007. And then there was another item.X
>> -------------------------------

I see the problem but here the cursor is at a second level item.
Therefore it is not astonishing that org-mode produces another
one with M-RET.


In my case I could see the change of "2007." to "1."  because
it was so near it was also on the display.  But this may happen
with list items which are not displayed and therefore one would
not recognise the damage... 



> There are two workarounds I can think of, at the moment:
> 
> 1. Use (setq org-plain-list-ordered-item-terminator ?)). But that will
>    affect every ordered list.

I'll do this.  Thank you and the other commentators for your help.

Ciao; Gregor

Re: Re: adding new plain lists item changes previous one it it ends in a number on a single lijne followed by a dot

[Nicolas Goaziou]

Hello,

> I understand that blank-number-dot starts a plain list item. But in
> my example the numbered list would be second level whilst the
> unordered list would be first level (of indentation). Org-mode
> rightly inserts a dash but why does it fiddle with another list item
> of different (second) level when inserting an new first level item?
> Is this necessary to in order to insert the next dashed item?

Before applying any modification to a list, Org will check its
integrity and correct it. It is necessary, as inserting an item can
change bullets, which in turn can change indentation. And we want this
just right.

Even if it wasn't the case, Org would still recognize the line as an
item start, and problems would arise sooner or later (for example upon
exporting).

> In my case I could see the change of "2007." to "1." because it was
> so near it was also on the display. But this may happen with list
> items which are not displayed and therefore one would not recognise
> the damage...

I understand this. But as it has already been told in this thread, "."
as bullet separator is risky and you've just encountered the risk. I
don't see a solution about it, but I'm all ears to any reasonable way
to handle this.

Regards,

--
Nicolas