According to: https://help.libreoffice.org/7.2/en-US/text/shared/01/06040100.html Ignore double spaces Replaces two or more consecutive spaces with a single space. 0. Tools > AutoCorrect > AutoCorrect Options - Options tab uncheck all [T] and [M] options, except for [T] options "Ignore double spaces" 1. Make sure: Tools > AutoCorrect > While Typing (is enabled) 2. Used Default PS. 3. Enter text, sometimes with double (or more) spaces. Actual results: 1. Contra "help", no double spaces are replaced. (also tried with Tools - AutoCorrect - Apply -- just in case....) 2. If there are "double" or "triple" spaces, they are flagged with blue ripple underlining -- no underlining with 4 or more spaces. 3. The "option" did not seem to have any effect on the grammar flagging. That is, they appear (if only double or triple), regardless of the option setting. Does it have another function? Not clear what the intended function is. Need to improve functionality (and align with help page). (If the purpose is only to "ignore grammatical errors" then I wonder if it is worthwhile to "clutter" up the "options" with this trivial choice, given there are other "ignore" options). Has been present since OOo 1.1.0
Tried again with a new version installed. "Ignore double spaces" might be better labelled "Prevent double spaces". If "Ignore double spaces" is enabled, and AutoCorrect > While Typing is Enabled. then: (a) if the cursor is on a space, then it is not possible to introduce additional spaces. (b) if the cursor is in a text string, then it is possible to introduce one space, but not any more. In short, with this option enabled, it is impossible to make more than one space. Tested in Writer and Calc. Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 396c2ad2daad6fe6a11703d0ae1593929834afe2 Source code also comments it as "prevent double space" https://opengrok.libreoffice.org/xref/core/editeng/source/misc/svxacorr.cxx?r=94306083#1312 Conclusions: 1. The documentation needs to be updated. The current description was present in its initial check-in in 2004. 2. The option was available in OOo 1.1.0 3. Maybe ask UXEval on changing Option name to "Prevent double spaces"?
From: https://opengrok.libreoffice.org/xref/core/officecfg/registry/schema/org/openoffice/Office/Common.xcs?r=35713de9#1374 <prop oor:name="RemoveDoubleSpaces" oor:type="xs:boolean" oor:nillable="false"> <!-- OldPath: AutoCorrect/Options/All --> <!-- OldLocation: Soffice.cfg --> <!-- UIHints: Tools AutoCorrect/AutoFormat Options Ignore Double Spaces --> <info> <desc>Specifies if multiple spaces should be combined into one.</desc> <label>Ignore double spaces</label> </info> <value>false</value> </prop> Was the intention to create a "removedoublespaces" function, and along the way, the vision changed to "prevent" double spaces, without a corresponding updating here in the registry (which then got copied into Help?) If there is no intention for a "remove double spaces" function, then a friendly source code cleanup would be to rename "RemoveDoubleSpaces" to "PreventDoubleSpaces" and rename the "IgnoreDoubleSpace" flag ( include/editeng/svxacorr.hxx ), which is used in ( editeng/source/misc/acorrcfg.cxx and cui/source/tabpages/autocdlg.cxx ) to something like "NoDoubleSpace" cui/inc/strings.hrc to change label of Option
(In reply to sdc.blanco from comment #1) > In short, with this option enabled, it is impossible to make more than one > space. Correction: Cursor placed immediately after a character can always insert a space, even if there are multiple spaces after it. (no opinion about whether "bug" or "feature" -- just an observation -- which some might consider a "workaround" for how to add spaces (albeit, one at a time). Another observation: Can use Tab key anywhere.
Hello sdc.blanco@youmail.dk, I've marked this as NEEDINFO as I'm not sure which OS you used to test. I tested this on MacOS Sonoma 14.1.2 with the ARM64 processor Apple M2 Pro Chip and I was unable to reproduce the bug with the steps you gave. I tested both on the stable build and master/daily build listed below. Version: 24.2.1.2 (AARCH64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 10; OS: macOS 14.1.2; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Version: 24.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 1cda27cf69054b006aa1b16cab8f56339274588b CPU threads: 10; OS: macOS 14.1.2; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Dear sdc.blanco, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Repro: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: dda85e275d70d6365009042b8e207337f2e712c2 CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: da-DK (da_DK); UI: en-US Calc: CL threaded
(In reply to sdc.blanco from comment #0) > 1. Contra "help", no double spaces are replaced. (also tried with Tools - > AutoCorrect - Apply -- just in case....) "Apply" doesn't apply (heh) in this case as the option doesn't have the [M] flag. I do confirm what you said: we can always add spaces immediately after a character that is not a space, but we are prevented from adding a space when we are before a character. Let's show this labeling proposal to the UX team. I suppose this is somewhat a matter of taste. The help page at least could benefit from a different wording than "replaces".
(In reply to Buovjaga from comment #7) > I suppose this is somewhat a matter of taste. The help page at least could > benefit from a different wording than "replaces". Indeed, a bit bike-shedding. But my sprachgefuehl also favors "Prevent" over "Ignore". An alternative could be "Suppress".