This can easyly be reproduced: Tab, -- to produce a dash, tab, some text, enter. The result should look like this: – Some text. However, enter removes the first tab, so the result is: – Some text.
Correction: The bug is not connected only to dash! The same happens with: tab, a number, dot, space, some text, enter with the desired result: 3. Some text. Enter changes this to 3. Some tex.
reproducible under Win7x64 using LibO 5.1.5.2
Not a bug, just the Autocorrect defaults. When you uncheck defaults from Tools -> Autocorrect -> Autocorrect Options: Options tab "Delete spaces and tabs at beginning and end of paragraph" "Delete spaces and tabs at end and start of line" you get the formatting behavior you want of not removing leading white space.
Very interesting, thank you very much, VSF!!! However, there is still a question regarding the behavior of this autocorrect option: With activated options: "Delete spaces and tabs at beginning and end of paragraph" "Delete spaces and tabs at end and start of line" the tab at the beginning of a paragraph is removed in these cases: tab, -- to produce a dash, tab, some text, enter tab, a number, dot, space, some text, enter BUT NOT in this simple case: tab, some text, enter ???
(In reply to Butch from comment #4) > ... > However, there is still a question regarding the behavior of this > autocorrect option: > ... > NOT in this simple case: > > tab, some text, enter > > ??? Yes I see the same. Suspect it lives down in the editengine, while in sw the handling for the Autocorrect options are: action to remove leading or trailing blanks are defined here http://opengrok.libreoffice.org/xref/core/sw/source/core/edit/autofmt.cxx#1078 Spaces are defined to include \t and " " http://opengrok.libreoffice.org/xref/core/sw/source/core/edit/autofmt.cxx#151 called from http://opengrok.libreoffice.org/xref/core/sw/source/core/edit/autofmt.cxx#698 They look like they should handle the "tab, some text, enter" case. Unfortunately I am unable to trace and find the exception affecting that formatting. Significant? Not really, seems kind of a corner case that actually does what most would expect to retain the leading \t or " " indent before simple text. The main issue in OP was that removal is set on by default--disabling its autocorrect option still functions as intended (mostly).