Bug 155834 - Unnumbered entries do not move together with their main entry, when list's "move item up / down" commands are used
Summary: Unnumbered entries do not move together with their main entry, when list's "m...
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-06-14 15:27 UTC by Mike Kaganski
Modified: 2023-07-14 08:13 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2023-06-14 15:27:32 UTC
In lists, there is a feature of "unnumbered entry" (Format->Lists->Insert Unnumbered Entry; put cursor to the very beginning of a non-first numbered entry and press Backspace). This feature (having a really bad name!) does *not* create new list entries, but rather puts this paragraph into the *same* list entry as the previous numbered paragraph. This way, one list item can contain multiple paragraphs, the same way as e.g. a table cell.

However, the controls for managing *lists* (e.g., Format->Lists->Move Item Down/Up) do not consider the *list items*, but instead, work with individual paragraphs.

Steps:

1. Type several paragraphs, e.g.:

  a
  b
  c
  d
  e

2. Select them, and make them a list (e.g., using F12).
3. Put cursor before "c", and press Backspace to make the "c" into the same item as "b".

At this stage, the document looks like

  1. a
  2. b
     c
  3. d
  4. e

4. Now put cursor to paragraph "b", and try to move it up using Format->Lists->Move Item Up.

Expected result: the *whole list item*, consisting of the two paragraphs "b" and "c", moves up; the document should become

  1. b
     c
  2. a
  3. d
  4. e

Actual result: only paragraph "b" moves up, leaving the paragraph "c" where it was, and thus, joining it to another list item. The document looks like

  1. b
  2. a
     c
  3. d
  4. e

Indeed, the same problem happens, when the cursor stays on paragraph "c" - then it moves without "parent" entry.
Comment 1 Heiko Tietze 2023-06-19 10:19:25 UTC
(In reply to Mike Kaganski from comment #0)
> Expected result: the *whole list item*, consisting of the two paragraphs "b"
> and "c", moves up...

At least according the styles inspector the "c" is still a list item, just without a list label string. I wouldn't expect the "c" to move.
Comment 2 Mike Kaganski 2023-06-19 10:32:48 UTC
(In reply to Heiko Tietze from comment #1)
> At least according the styles inspector the "c" is still a list item, just
> without a list label string.

Indeed it is shown as part of list. But when you think it's an individual *list item*, you yourself fall a victim of this "paragraph = list item" wrong idea.

> I wouldn't expect the "c" to move.

... which you express here. A list item is a *set of paragraphs* (possibly and most often consisting of a single paragraph), firsto of which has a label (number, marker, ...), and the rest do not.

The problem is: we do not communicate this idea to user in any way in the UI, and people do not even imagine that this is the case.
Comment 3 QA Administrators 2023-06-20 03:13:33 UTC Comment hidden (obsolete)
Comment 4 Heiko Tietze 2023-06-20 08:02:56 UTC
(In reply to Mike Kaganski from comment #2)
> But when you think it's an individual *list item*, you yourself 
> fall a victim of this "paragraph = list item" wrong idea.
Now I'm confused. Is it technically a list item or not? And since you asked UX, can we change this.

> The problem is: we do not communicate this idea to user in any way in the
> UI, and people do not even imagine that this is the case.
What do you have in mind? Could imagine to show the tab formatting mark for all list items. And we do not have an option beside backspace to suppress the label, which could be added to the B&N dialog. Or better as an extra command as it is related to a single item. Toggle on/off aka checkbox would allow both to suppress the label without backspace (PITA on macOS, btw.) and to get proper feedback.
Comment 5 Mike Kaganski 2023-06-20 08:53:01 UTC
(In reply to Heiko Tietze from comment #4)
> (In reply to Mike Kaganski from comment #2)
> > But when you think it's an individual *list item*, you yourself 
> > fall a victim of this "paragraph = list item" wrong idea.
> Now I'm confused. Is it technically a list item or not?

Again: a list item is not a paragraph, it is a *set of paragraphs*.
It is the same for e.g. table cells: a table cell is not a paragraphs, it is all paragraphs in it (sometimes one, sometimes many). But for table cells, we can have visual things (cell borders, even when there's no user borders - we can show dashed borders nevertheless).

> And since you asked UX, can we change this.

We *need not* change this, we need to allow users to *know* (see) it.

> > The problem is: we do not communicate this idea to user in any way in the
> > UI, and people do not even imagine that this is the case.
> What do you have in mind? Could imagine to show the tab formatting mark for
> all list items. And we do not have an option beside backspace to suppress
> the label, which could be added to the B&N dialog. Or better as an extra
> command as it is related to a single item. Toggle on/off aka checkbox would
> allow both to suppress the label without backspace (PITA on macOS, btw.) and
> to get proper feedback.

I don't know, maybe a kind of dotted rectangle around the whole current list item (=several paragraphs) appearing dynamically when you enter a list, when formatting marks are enabled ...

but this issue is not about that directly - just about the many paragraphs in the list to *behave* like a unit.

Compare to tables again. Let's imagine we have a "move table cell up" command. When we are in a paragraph inside a table cell (having several paragraphs), and use this command, the expectation would be, that the whole cell moves up, with all the paragraphs, not only the one paragraph where the cursor is.

But in case of lists, when we issue a "move list item up" command, not the *list item* moves, but a *part of the current item* - which is the *current paragraph*.
Comment 6 Mike Kaganski 2023-06-20 08:55:21 UTC
(In reply to Mike Kaganski from comment #5)
> It is the same for e.g. table cells: a table cell is not a paragraphs

Sorry for the typo, I intended to write: "a table cell is not a paragraph", and the "s" in the end was wrong.
Comment 7 Mike Kaganski 2023-06-20 09:05:23 UTC
(In reply to Mike Kaganski from comment #5)
> Compare to tables again. Let's imagine we have a "move table cell up" ...

Or use Navigator, and its "move chapter up". When you do that, it moves not only a heading, but also all the paragraphs that "belong" to this chapter. This is the normal expectation; and when talking about list *items* (not "list entries", which are individual paragraphs that form list items - individually or in groups), the "move item" must follow the same idiom.
Comment 8 Heiko Tietze 2023-06-20 09:14:32 UTC
(In reply to Mike Kaganski from comment #5)
> Again: a list item is not a paragraph, it is a *set of paragraphs*.
This does not match my understanding as a list being an attribute of the paragraph (and consequently I don't expect the item to move). But you are the expert...

> I don't know, maybe a kind of dotted rectangle around the whole current list
> item (=several paragraphs) appearing dynamically when you enter a list, when
> formatting marks are enabled ...
Do you agree with the more subtle proposal of a checkbox "[x] Show label" under the list menu? On by default, off when backspace was pressed - or this item is unchecked.
Comment 9 Mike Kaganski 2023-06-20 09:28:01 UTC
(In reply to Heiko Tietze from comment #8)
> (In reply to Mike Kaganski from comment #5)
> > Again: a list item is not a paragraph, it is a *set of paragraphs*.
> This does not match my understanding as a list being an attribute of the
> paragraph

This is completely technical implementation detail in Writer. This does not match common sense (no one will think that "Of course, this is usually the most time-consuming part." below constitutes a separate list item - which, e.g., may have an own "done" mark; people will understand that all three paragraphs from "Do the real work." till "Some more pseudo-deep thoughts on this..." constitute a single list item, and discuss one step number two). And your perception also does *not* match ODF, where a list like

  1. Create a plan.
  2. Do the real work.
     Of course, this is usually the most time-consuming part.
     Some more pseudo-deep thoughts on this...
  3. Report to the community.

will be

  <text:list>
   <text:list-item>
    <text:p>List item 1</text:p>
   </text:list-item>
   <text:list-item>
    <text:p>List item 2 paragraph 1</text:p>
    <text:p>List item 2 paragraph 2</text:p>
    <text:p>List item 2 paragraph 3</text:p>
   </text:list-item>
   <text:list-item>
    <text:p>List item 3</text:p>
   </text:list-item>
  </text:list>

All in all, you show exactly the problem that I ask to fix.

> > I don't know, maybe a kind of dotted rectangle around the whole current list
> > item (=several paragraphs) appearing dynamically when you enter a list, when
> > formatting marks are enabled ...
> Do you agree with the more subtle proposal of a checkbox "[x] Show label"
> under the list menu? On by default, off when backspace was pressed - or this
> item is unchecked.

Do you have a mockup?
Comment 10 Heiko Tietze 2023-06-20 09:35:24 UTC
(In reply to Mike Kaganski from comment #9)
> Do you have a mockup?

For a checkbox? The idea is to have a dedicated command for the same action as backspace. And to label it positively with "[x] Show label", or similar. 

(In reply to Mike Kaganski from comment #2)
> The problem is: we do not communicate this idea to user in any way in the
> UI, and people do not even imagine that this is the case.

Seeking for a (subtle) solution for this. Whether the paragraph moves with the list item above does not need special UI.
Comment 11 Mike Kaganski 2023-06-20 09:37:25 UTC
(In reply to Heiko Tietze from comment #10)
> (In reply to Mike Kaganski from comment #9)
> > Do you have a mockup?
> 
> For a checkbox? The idea is to have a dedicated command for the same action
> as backspace. And to label it positively with "[x] Show label", or similar. 

No, for the intended result. I strongly suspect that you imagine something completely incorrect, still not wanting to understand that I do not talk about showing the "labels" (that should *not* be shown for *following parts* of a list item).
Comment 12 Mike Kaganski 2023-06-20 09:38:52 UTC
Or - why did you even started to talk about "same action as backspace"? I am completely confused. Please start again, and focus on "move list item up/down" functionality.
Comment 13 Heiko Tietze 2023-06-21 12:50:50 UTC
(In reply to Mike Kaganski from comment #11)
> I strongly suspect that you imagine something
> completely incorrect, still not wanting to understand that I do not talk
> about showing the "labels" (that should *not* be shown for *following parts*
> of a list item).

Probably, in any case MSO behaves the same as LibreOffice.
Comment 14 Mike Kaganski 2023-06-21 13:13:00 UTC
(In reply to Heiko Tietze from comment #13)
> MSO behaves the same as LibreOffice.

A very important point that I didn't consider. Thank you. I need to check it.
Comment 15 Mike Kaganski 2023-06-25 20:18:27 UTC
(In reply to Heiko Tietze from comment #13)
> MSO behaves the same as LibreOffice.

I have tested this, and yes, using Move Up/Down function in MS Word 2016 does behave the same way.
However, it is completely unrelated.

In Word (and in its file format), there is no proper notion of *list item*, which would include several paragraphs. The list like

  1. a
  2. b
     c
  3. d
  4. e

would be represented by this OOXML markup:

    <w:p>
        <w:pPr>
            <w:pStyle w:val="ListParagraph"/>
            <w:numPr>
                <w:ilvl w:val="0"/>
                <w:numId w:val="1"/>
            </w:numPr>
        </w:pPr>
        <w:r>
            <w:t>a</w:t>
        </w:r>
    </w:p>
    <w:p>
        <w:pPr>
            <w:pStyle w:val="ListParagraph"/>
            <w:numPr>
                <w:ilvl w:val="0"/>
                <w:numId w:val="1"/>
            </w:numPr>
        </w:pPr>
        <w:r>
            <w:t>b</w:t>
        </w:r>
    </w:p>
    <w:p>
        <w:pPr>
            <w:pStyle w:val="ListParagraph"/>
        </w:pPr>
        <w:r>
            <w:t>c</w:t>
        </w:r>
    </w:p>
    <w:p>
        <w:pPr>
            <w:pStyle w:val="ListParagraph"/>
            <w:numPr>
                <w:ilvl w:val="0"/>
                <w:numId w:val="1"/>
            </w:numPr>
        </w:pPr>
        <w:r>
            <w:t>d</w:t>
        </w:r>
    </w:p>
    <w:p>
        <w:pPr>
            <w:pStyle w:val="ListParagraph"/>
            <w:numPr>
                <w:ilvl w:val="0"/>
                <w:numId w:val="1"/>
            </w:numPr>
        </w:pPr>
        <w:r>
            <w:t>e</w:t>
        </w:r>
    </w:p>

so the "list item" feature of Writer doesn't exist in Word, and so it's incorrect to consider how Word behaves in this regard. The "unnumbered entries" in Word are ordinary paragraphs, just having the same paragraph style as numbered entries, to have the same indentation.
Comment 16 Heiko Tietze 2023-07-14 08:13:11 UTC
No further input from UX, removing the keyword.