Description: When creating a list that is indented (with TAB), items c and d will always lose their indent. Tried on multiple computers running Windows on new and several older versions of Writer. List ends up looking like below: a) b) c) d) e) f) Steps to Reproduce: 1. Type "a." or "a)" with text after it. 2. Repeat for "b." / "b)" and so on 3. When you get to "c." or "c)", the indent will be lost. Also happens for "d." / "d)" 4. Indent returns for "e." / "e)" and following letters. 5. Problem will not occur unless text is following the items on the list (not just a, b, c, etc.) Actual Results: a) first item, retains indent when I press “enter” b) second item, retains indent when I press “enter” c) third item, LOSES indent when I press “enter” d) fourth item, LOSES indent when I press “enter” e) fifth item, retains indent when I press “enter” f) so do the rest Expected Results: a) first item b) second item c) third item d) fourth item e) fifth item f) etc. Reproducible: Always User Profile Reset: Yes Additional Info: See above
Repro using Version: 7.4.1.1 (x64) / LibreOffice Community Build ID: 0a046a10cbf1679eea5538bd3ab63156caa3a036 CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (ru_RU); UI: en-US Calc: CL Jumbo. If you enable "Bulleted and numbered lists" under AutoCorrect Options (Options tab), it would change a bit: for a and b, it would work the same, but for c, it turns the line into a *numbered list*, using *roman numerals* (so after pressing Enter, the next line is automatically numbered "ci"). Disabling "Delete spaces and tabs at end and start of line" has no effect on this. But disabling autocorrect while typing as a whole fixes this. Using OOo 3.2.0, the picture is the same. It looks that the problem is somehow related to the automatic recognition of Roman numerals. It works erratically, though: it should not affect the text when the "Bulleted and numbered lists" is disabled (the default now).
By the way, the same problem happens when you type "<tab>1. blah", which confirms the list detection theory.
(In reply to Mike Kaganski from comment #1) > Disabling "Delete spaces and tabs at end and start of line" has no effect on > this. But disabling "Delete spaces and tabs at beginning and end of paragraph" avoids the problem. So it looks like the "Delete spaces and tabs at beginning and end of paragraph" only works in conjunction with other matching rules (even disabled, like numbering) - so looks like a bug in "Delete spaces and tabs at beginning and end of paragraph". It likely should work regardless of the other matching rules.
A possible code pointer: SwAutoFormat::DeleteLeadingTrailingBlanks in sw/source/core/edit/autofmt.cxx.
It seems relevant to add here that there inconsistencies between text and associated functionality between Menu Items (like Format > Spacing > "Increase indent") and Tools > Customize > Keyboard commands (like "Indent") Specifically related to this existing report, I tried to set "CTRL + >" and "CTRL + <" to Increase and Decrease list indent, respectively. 1 - you can't find that Keyboard command searching for "indent", yet there are 3 distinct "Increase" options - confusing 2 - the "Increase indent" functionality, through this function .uno:IncreaseIndent does something quite different and unreliable in the doc, compared with the menu option to "Increase indent" noted above It would be nice to have really consistent and reliable nested-list functionality, to easily achieve nested (un-)ordered lists, whether from the menu or keyboard shortcuts. Lists like 1. one 2. two • two-detail • two-detail a. two-detail-a i. two-detail-a-i Right now in this version, such nested lists are really difficult to achieve
Created attachment 188658 [details] icons for working with lists - unreliable
Perhaps I'm off a bit with prior comment about increase/decrease indent, and I should use Promote and Demote outline level for this purpose - menus and keyboard commands. Nonetheless, I find the promote/demote outline level equally unreliable and inconsistent. I think an overhaul for paragraph indentation, outline level promotion/demotion, with or without subpoints would greatly improve this basic functionality.
Dear Real Ice Cube, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This bug seems similar to Bug 166539 and Bug 67797—could it be a duplicate? What do you think?
*** This bug has been marked as a duplicate of bug 67797 ***