Bug 36220 - Numbering is not updated when a new item is added at the beginning of the list and Continue previous numbering is not consistent
Summary: Numbering is not updated when a new item is added at the beginning of the lis...
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: low enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Bullet-Number-Outline-Lists Writer-Styles-List
  Show dependency treegraph
 
Reported: 2011-04-13 13:31 UTC by Frédéric Buclin
Modified: 2021-03-23 16:10 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Test ODT (8.84 KB, application/vnd.oasis.opendocument.text)
2020-06-25 10:40 UTC, Timur
Details
quick and dirty first attempt at help for "Continue previous numbering" (32.20 KB, image/png)
2021-02-23 10:34 UTC, sdc.blanco
Details
quick and dirty first attempt at help for "Continue previous numbering" (32.29 KB, image/png)
2021-02-23 10:38 UTC, sdc.blanco
Details
Illustration of different uses of continue previous numbering (351.92 KB, application/vnd.oasis.opendocument.graphics)
2021-02-25 09:03 UTC, sdc.blanco
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Frédéric Buclin 2011-04-13 13:31:46 UTC
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.".
Comment 1 Jan Holesovsky 2011-04-14 16:29:09 UTC
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.
Comment 2 Björn Michaelsen 2011-12-23 12:01:17 UTC Comment hidden (obsolete)
Comment 3 Florian Reisinger 2012-08-14 14:01:07 UTC Comment hidden (obsolete)
Comment 4 Florian Reisinger 2012-08-14 14:02:13 UTC Comment hidden (obsolete)
Comment 5 Florian Reisinger 2012-08-14 14:06:51 UTC Comment hidden (obsolete)
Comment 6 Florian Reisinger 2012-08-14 14:08:56 UTC Comment hidden (obsolete)
Comment 7 Frédéric Buclin 2012-08-14 14:52:13 UTC Comment hidden (obsolete)
Comment 8 Florian Reisinger 2012-08-15 17:13:11 UTC
Okay, status set to NEW
Comment 9 Justin L 2017-01-20 06:14:08 UTC
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.
Comment 10 Timur 2018-01-19 10:26:13 UTC
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)
Comment 11 Dieter 2018-10-30 14:07:36 UTC
(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.
Comment 12 Timur 2019-09-06 08:59:27 UTC Comment hidden (obsolete)
Comment 13 Timur 2020-06-25 10:40:08 UTC
Created attachment 162397 [details]
Test ODT

Repro Comment 0 and Comment 10 in LO 7.1+.
Comment 14 Timur 2021-02-23 06:59:26 UTC
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.
Comment 15 Dieter 2021-02-23 07:53:33 UTC
(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.
Comment 16 sdc.blanco 2021-02-23 09:26:49 UTC
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)
Comment 17 sdc.blanco 2021-02-23 10:34:18 UTC Comment hidden (obsolete)
Comment 18 sdc.blanco 2021-02-23 10:38:20 UTC
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.
Comment 19 Dieter 2021-02-25 07:39:44 UTC
(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.
Comment 20 sdc.blanco 2021-02-25 09:03:33 UTC
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).
Comment 21 Dieter 2021-02-28 10:54:49 UTC
(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.
Comment 22 Dieter 2021-02-28 10:59:00 UTC
(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.
Comment 23 Dieter 2021-02-28 11:26:00 UTC
(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.
Comment 24 sdc.blanco 2021-03-23 13:06:54 UTC
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.
Comment 25 sdc.blanco 2021-03-23 13:18:39 UTC
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.
Comment 26 Timur 2021-03-23 16:10:11 UTC
I close as Notabug.
We just have to read help and understand the behavior.