Steps to reproduce: 1. Create a new text document. 2. On the first line, just type some text. 3. On the second line, start the numbering, and add some text. 4. On the third line, the numbering is automatically set to "2.". Add some text. 5. Now you want to also include the numbering for the first line. So you click anywhere in the first line and click the "numbering" button. => Both the first and second lines start with "1.". The second line should have been incremented to "2." and the third line to "3.".
This is more an enhancement request; you can never predict what the user exactly wanted, just guess that he/she wanted to extend the numbering.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
Tested with LibO 3.6.0.4 and steps to reproduce in comment 0 are still valid to reproduce the issue.
Okay, status set to NEW
Tested with LibO 5.3 beta2 and steps to reproduce in comment 0 are still valid to reproduce the issue. Of course, selecting all three, turning off numbering and turning it back on "fixes" the issue. Very little incentive (low priority) to touch this and risk all kinds of problems, and nobody else included in the CC list after many years.
This doesn't seem like a problem, as Justin noticed. But, for me problem is another step: 6. go to 2nd line and right-click "Continue previous numbering" => 2nd line is 2. (OK) but 3rd line is 1. instead od 3. (NOK)
(In reply to Timur from comment #10) > => 2nd line is 2. (OK) but 3rd line is 1. instead od 3. (NOK) I confirm this with 6.2.0.0.alpha1 and I also think, that this is a bug.
Repro 6.4+
Created attachment 162397 [details] Test ODT Repro Comment 0 and Comment 10 in LO 7.1+.
I'm no more sure this is a bug. Help I proposed in https://bugs.documentfoundation.org/show_bug.cgi?id=135895#c44 also works here. Just select 1st *and* numbered and it will work in step 5. Or select all items and numbering will continue in step 6. LO gives more options and doesn't predict what user wants, as Comment 1 said. You can decide exactly what to include in Continue and what not. Now I think it's good, just to have this explained in Help.
(In reply to Timur from comment #14) > I'm no more sure this is a bug. I agree with you regarding to the original problem. Your observation in comment 10 is still valid and for me decision is open, if this is a bug or the expected result (see for example bug 140579 comment 2). But it's also O. K. for me to close this bug as resolved and open a new one for the issue in comment 10.
Here is another way to understand "Continue previous numbering", which shows that comment 10 can be understood as expected behavior. As noted in comment 14 > You can decide exactly what to include in Continue and what not. Here is the logic: Start with a list, such as described in comment 0, steps 1-5. Here is one with 5 items. 1. item 1 1. item 2 2. item 3 3. item 4 4. item 5 Technique 1. Select item 1 and any of item 3, 4, or 5, (but not item 2), right-click, "continue previous numbering" Result: makes the (expected?) continuous numbering 1-5 (for all 5 items). Technique 2. Select only items 2 and 3, right-click, "continue previous numbering" Result: gives 1.2.3 (for items 1-3) and 1.2. for items 4 and 5. In other words: Technique 1 allows you to make a continuous list by selecting the list item added at top, plus an arbitrary item in the middle of the list. Technique 2 allows you to "add" as many items as you want from the original list to the "new" first item. Both techniques seem like meaningful workflows -- also for DF users -- and could be (easily?) documented. A better label for the command is: "Include in previous list" (The techniques also works with bulleted lists, but with a directional effect, described in bug 117233, comment 8)
Created attachment 169994 [details] quick and dirty first attempt at help for "Continue previous numbering" Discussion about "expected" or "desired" behavior is ongoing. Attachment shows first attempt to document "current" behavior. Can adjust once decisions are made about "expected" behavior.
Created attachment 169995 [details] quick and dirty first attempt at help for "Continue previous numbering" Discussion about "expected" or "desired" behavior is ongoing. Attachment shows first attempt to document "current" behavior. Can adjust once decisions are made about "expected" behavior.
(In reply to sdc.blanco from comment #18) > Created attachment 169995 [details] > quick and dirty first attempt at help for "Continue previous numbering" > > Discussion about "expected" or "desired" behavior is ongoing. > Attachment shows first attempt to document "current" behavior. > Can adjust once decisions are made about "expected" behavior. Thanks for htat first draft. To be honest, I don't understand the first part. And why not call it "Merge two lists", because it works for ordered and unordered lists.
Created attachment 170045 [details] Illustration of different uses of continue previous numbering (In reply to Dieter from comment #19) > To be honest, I don't understand the first part. Have you tried to follow the instructions while sitting with two lists? Can you identify more precisely what is unclear? Meanwhile, I have attached a document that takes three separate lists, and uses the "first part" to merge lists in various ways, and actually goes beyond the first part (which was only written in relation to two lists). The combinations in these examples show current behavior. See especially #4 and #5 in the attachment. Notice that, in principle, the first part should document all these cases. How to describe? Alternatively, if no one know the "expected" behavior, then it is hard to document. One (temporary) solution is to document typical situations (e.g., combining two numbered lists) -- which also seems to be the source of bug reports. > And why not call it "Merge two lists", because it works for ordered > and unordered lists. At the time it was made, the focus in this and other bugs was on numbered lists and numbering being wrong. Plus the command name refers to numbering. Assumed that users would be looking for help to combined numbered (ordered) lists, hence the label. (but no problem to call it "merge two lists") Also, with bullets, if the bullet symbols are different in the two lists, then it matters which direction the selection is made. I have suggested "Include in a previous list" as an alternative command name. Another possibility might be: "Combine lists" (which might give a better expectation than "continue previous numbering). Then the documentation would show the rules/procedures for combining lists (according to the "expected" behavior, when it gets decided).
(In reply to sdc.blanco from comment #20) > Have you tried to follow the instructions while sitting with two lists? > Can you identify more precisely what is unclear? In the second step should be added, that you still have to press Ctrl key. I tested, but but it doesn't continue previous numbering, but first list (in my example a numbered list) takes style from second (alphabetical list). That might be a bug and should be reported somewhere else. So I don't understand, why I shouldn't select first item of the second list. So for me correct description would be: 1. Press Ctrl key and select paragraphs to be included from the second list 2. Still hold Ctrl key and select at least one paragraph from the first list, except for the first item. 3. Right click, choose List - Continue previous numbering BTW: This bug report is getting chaotic. So I propose to open a new bug report only for documentation issue.
(In reply to sdc.blanco from comment #20) > I have suggested "Include in a previous list" as an alternative command > name. Another possibility might be: "Combine lists" (which might give a > better expectation than "continue previous numbering). Then the > documentation would show the rules/procedures for combining lists (according > to the "expected" behavior, when it gets decided). I think, this is already discussed in bug 140579. We should to reduce this bug to one issue.
(In reply to sdc.blanco from comment #20) Just reading your comment from bug 140579 comment 15 I realise, that actual situation is mor complex and it seems to be difficult to keep description short. I think it wasn't clear to me, that first / second list in description in attachment 169995 [details] is the first selected and the second selected list (and not the fist / second list on the page). That must be clear.
Based on bug 140579, comment 51, STR in comment 0 and comment 10 here "expected behavior" (i.e., not bugs). In comment 0, if user wants line 3 to be 3. - then select part of line 2 and part of line 3, before using the command. Will give desired/expected result. Comment 10 just repeats and describes STR. Note that in step 6 in comment 10, cursor is placed in line 2, but no selection is made. Result is expected behavior. I think this ticket should be closed as NAB.
Alternatively, as "enhancement" request - the specific proposal would "break" existing functionality. Meanwhile, https://git.libreoffice.org/help/commit/cf21df79f4499a4836adbb0e2c448048b5be418b has provided help about how to achieve the desired/expected outcome with existing functionality.
I close as Notabug. We just have to read help and understand the behavior.