Consider following numbered list in Writer 1. Alice 2. has 3. a cat. Suppose I go to the first number and press enter, so the list looks like this: 1. 2. Alice 2. has 3. a cat. Now, when I go to the beginning of the word "Alice" and press bakcspace, number "2." disappears which is ok. The list looks like this: 1. Alice 2. has 3. a cat. Now, being still at the beginning of the word "Alice" I press backspace and strange reorder happens: Alice 1. has 2. a cat which is not OK, because the expected action of backspace should move the word "Alice" to the first position: 1. Alice 2. has 3. a cat. The problem does not exists if the line following a number is not empty.
This was the same in OOo 3.3. How MS Office does it: - first backspace: remove bullet/number _and_ indent - second backspace: take paragraph to first line, does not remove bullet (as nvhorst expects) OnlyOffice behaves like MS Office (with an extra backspace action to remove the indent). I agree that I'd expect the bullet/number to remain, and I would go with how OnlyOffice does it. Couldn't find a duplicate. UX/design team, any thoughts? Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 0ddd9f7e055a0c1ecb120de3e40c3fdb8373e9dc CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
(In reply to Stéphane Guillou (stragu) from comment #1) > How MS Office does it: > - first backspace: remove bullet/number _and_ indent > - second backspace: take paragraph to first line, does not remove bullet (as > nvhorst expects) > > OnlyOffice behaves like MS Office (with an extra backspace action to remove > the indent). > > I agree that I'd expect the bullet/number to remain, and I would go with how > OnlyOffice does it. No (to "first backspace: remove bullet/number _and_ indent"). Word doesn't have a proper concept of multiline list item; Writer has it. First backspace makes the item an "unnumbered item" (i.e., another paragraph inside the same list item), and that must not change. If there might be a *second* backspace removing the paragraph from the list, and then the *third* backspace moving it to the previous line without dropping the previous paragraph's numbering properties. But making Writer dumb, just because other software has no such functionality, is not OK.
(In reply to Mike Kaganski from comment #2) > No (to "first backspace: remove bullet/number _and_ indent"). > Word doesn't have a proper concept of multiline list item; Writer has it. > First backspace makes the item an "unnumbered item" (i.e., another paragraph > inside the same list item), and that must not change. > [...] making Writer > dumb, just because other software has no such functionality, is not OK. You misunderstood me, Mike. I said I would go with OnlyOffice's way, _not_ Word's: (In reply to Stéphane Guillou (stragu) from comment #1) > I would go with how > OnlyOffice does it. I.e: a) 1st backspace: remove numbering/bullet (i.e. turn the paragraph into an "unnumbered item") b) 2nd backspace: remove indent of the unnumbered item c) 3rd backspace: move paragraph to first line, keeping 1st number, to end up with: 1. Alice 2. has 3. a cat. I'd also be OK with no (b), if there's a reason not to have it. But I sometimes want to have a list that continues after a "normal" body text paragraph, so I would find that step useful too.
(In reply to Stéphane Guillou (stragu) from comment #3) Thanks for clarification; I need to learn reading also within parentheses (i.e., not only "OnlyOffice behaves like MS Office", but also "with an extra backspace action to remove the indent"). Agree.
I think what's expected is 1. Demote the list item if level > 1 (pressing backspace on "1.1 has" should make this paragraph "2. has") 2. Remove the list label string if level = 1 (pressing backspace on "2. has" should turn this into " has") 3. Remove the list attribute from the paragraph if level = 1 & list label = "" (pressing backspace on " has" should make this paragraph "has") (we do this currently only in case of empty paragraphs) 4. Merge the paragraph with the previous keeping all of the attribute (backspace on "has" ends up in "1. Alice has"; automatically adding a trailing space here) (we do this with any ordinary paragraph) Any concerns, Mike? (In reply to Stéphane Guillou (stragu) from comment #1) > Couldn't find a duplicate. UX/design team, any thoughts? Feels like a question we discuss weekly. But found just bug 128622 about Impress and bug 155834 about move up/down on those items.
(In reply to Heiko Tietze from comment #5) But what if you want to make this paragraph a second paragraph under 1.1?
(In reply to Mike Kaganski from comment #6) But anyway, what you suggest is consistent with what happens now; and current solution for sub-items is using the "unnumbered item" UI for the following item paragraphs.
(In reply to Mike Kaganski from comment #6) Ignore comment 7; for 1.2, backsace must first turn it into 1.1's following paragraph.
(In reply to Mike Kaganski from comment #6) > But what if you want to make this paragraph a second paragraph under 1.1? 1. Alice 1.1. Has 2. A 3. Cat On "2.A" I have to press backspace three times (-label, -list, merge) and then enter (+new paragraph with attributes from the previous).
(In reply to Heiko Tietze from comment #9) > 1. Alice > 1.1. Has > 2. A > 3. Cat > > On "2.A" I have to press backspace three times (-label, -list, merge) and > then enter (+new paragraph with attributes from the previous). And that is fine, wanted, and consistent with what comment 2 tells. Why do you write that?
(In reply to Mike Kaganski from comment #10) > Why do you write that? Just for clarification. The proposal (from the technical POV) is step #3, removing the list attribute.
(In reply to Heiko Tietze from comment #11) I agree with step 3 (but my concern in comment 6 and comment 8 was about step 1 in comment 5, which misses a "1.2" case). But step 3 is actually irrelevant to the issue from comment 0, which focuses on a bug of empty numebred paragraph being unexpectedly and inconsistently turned into an unnumbered entry, when a following unnumbered entry is merged into it using backspace. By the way, a very similar thing would also happen, if in comment 0, you manually remove " Alice" from list, before pressing backspace - the only difference is that "1. " will turn then not to " Alice", but to "Alice". So the real problem (and *bug*) is in #4 in comment 5.
I only want to add that basically Backspace key acts opposite to Enter key. So my idea is that if you are within the list and press Enter, you should not jump out of the list by pressing Backspace in such a manner that omits initial place in text where Enter had been pressed.
(In reply to Mike Kaganski from comment #12) > But step 3 is actually irrelevant to the issue from comment 0... Thought it wouldn't happen for no-list paragraphs but in fact it does (unless the list contains some character). Don't see a reason to remove the list attribute => BUG
(In reply to nvhorst from comment #13) Your message is unclear. Do you consider steps 2-3 in comment 5 wrong? Or do you consider your steps in comment 0 as "jump out of the list ... in such a manner that omits initial place in text" - which it is not, it just brings the current paragraph's formatting (including list settings) into the empty paragraph it joins to?
For consistency: 1. To change the list levels Tab/ShiftTab keys are used in LO if the cursor is at the beginning of a line. 2. To add new /remove existing item within a list Enter/Backspace is used. So I think that first point in comment #5 is questionable. In case backspace worked for demoting levels, there will be no possibility of multi-line paragraphs for levels >1 as far as I understand.
(In reply to nvhorst from comment #16) > So I think that first point in comment #5 is questionable. To not demote on backslash might feel like a regression for many users but I see the consistency. Plus, it allows to remove the list label at any level.
(In reply to Mike Kaganski from commen > you consider your steps in comment 0 as "jump out of the list ... in such a > manner that omits initial place in text" - which it is not, it just brings > the current paragraph's formatting (including list settings) into the empty > paragraph it joins to? Actually it omits the original place in a text where Enter was pressed for the first time, i.e. between '1. ' and the beginning of the 'Alice'. It is impossibles to keep consistent text flow and place the cursor exactly in this very position using enter and backspace keys.