Non-breaking spaces¹ and non-breakable narrow space² behave differently when combining Ctrl(+Shift) with left and right arrows, backspace and delete keys. ¹(Ctrl+Shift+Space; Unicode: No-break space, U+00A0) ²(Shift+Alt+Space; Unicode: Narrow no-break space, U+202F) Test case with non-breaking space: 1.a. Type a Ctrl+Shift+Space b (without spaces) 1.b. Press Ctrl+Left arrow, and the cursor will go to the left of "a" Non-breaking spaces within a word behave as part of the word. Steps to reproduce: 2.a. Type a Shift+Alt+Space b (without spaces) 2.b.1. Press Ctrl+Left arrow, and the cursor will go to the left of "b" 2.b.2. Press again Ctrl+Left arrow, and the cursor will go to the left of the non-breakable narrow space 2.b.3. Press again Ctrl+Left arrow, and finally the cursor will go to the left of "b" Non-breakable narrow spaces (NBNS) within a word, for this issue, makes it to behave as NBNS*2+1 words; in this example three words. Expected behavior³ instead of 2.b.1 to 2.b.3.: 2.b. Press Ctrl+Left arrow, and the cursor will go to the left of "a" ³Especially in large numbers. For "Word and character count", both spaces count as characters but do not count as word; like (normal) space. For the character I am using "space". For the key I am using "Space". Although dictionaries spell it as "Space bar", in LibreOffice Help, "Space" and "Spacebar" are used interchangeably (https://help.libreoffice.org/6.4/en-US/text/swriter/04/01020000.html, https://help.libreoffice.org/6.4/en-US/text/shared/optionen/01040600.html). LibreOffice 6.3.6.2 (x86); OS: Windows 6.1 Version: 6.3.6.2 (x86) Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497 CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; Locale: es-MX (es_MX); UI-Language: en-US Calc: threaded
OK, confirming on 2020-07-29 TB77 Windows build of master Version: 7.1.0.0.alpha0+ (x64) Build ID: <buildversion> CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL The LibreOFfice assigned shortcuts are: U+202F Alt+Shift+Space -- Insert Narrow No-break Space (.uno:InsertNarrowNobreakSpace) U+00A0 Ctrl+Shift+Space -- Insert non-breaking space (.uno:InsertNonBreakingSpace) Or, done efficiently with the convenient <Alt>+X toggle of a Unicode entry. The non-breaking spaces probably should have the same ICU lib handling for either in that neither should be counted as word bounds--strings should be 1 word. And the <Ctrl> <R,L> should move to beginning or end of either (it does for the NBS, not for the NNBS). The NBS word bound movement is correct (inherited from OOo), the NNBS was only command was only added recently by Heiko with https://gerrit.libreoffice.org/c/core/+/66776/ for bug 121596 and maybe needed more work on the edit shell behavior. And for many of these NPC/formatting marks we do have bug 58434 to get them all on the same toggle control for visibility on document canvas.
NNBS (U+202F) also affect the use of decimal tab stops. Having a number (e.g. 12 345.6) with NNBS as thousand separator will align at the right of 12 not of 345.
The same at Version: 7.1.7.2 (x86) / LibreOffice Community Build ID: c6a4e3954236145e2acb0b65f68614365aeee33f CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: es-MX (es_MX); UI: en-US Calc: threaded
The word boundaries in LO are processed using u_isWhitespace that excludes the no-break-spaces. The Unicode functions defined in [1] can be used: u_isUWhiteSpace=UCHAR_WHITE_SPACE: Unicode White_Space property; most of general categories "Z" (separators) + most whitespace ISO controls (including no-break spaces, but excluding IS1..IS4) u_isWhitespace: Java isWhitespace; Z + whitespace ISO controls but excluding no-break spaces u_isJavaSpaceChar: Java isSpaceChar; just Z (including no-break spaces) u_isspace: Z + whitespace ISO controls (including no-break spaces) u_isblank: "horizontal spaces" = TAB + Zs [1] https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/uchar_8h.html We could add simply the Narrow no-break space, U+202F, as a workaround
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/70c99eef1643a17b2c1f0dba38b55a58cdb9aafc tdf#135451 - Change the skipSpace implementation of the break iterator It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Andreas, when doing Ctrl + Left navigation on "a b" (separated by NNBS), LO 7.5 does now lump it with "a" just like it would with a breaking space (an improvement over LO 7.4, which would take the NNBS as a word - thank you for that!). However, as I understand it, Leroy argues it should behave the same as with a NBS: the whole "a b" is taken as a single word. (It can be tested here in a web browser: at least Firefox does skip the whole string in one go, no intermediate stop at the left of "b".) Is a follow-up needed for that or am I missing something?
Yes, you are right. We should re-open the ticket and check for a fix.
The same at Version: 7.5.3.2 (x86) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: es-MX (es_MX); UI: es-ES Calc: threaded
(In reply to LeroyG from comment #8) > The same at Like in comment #6.
Issue is inherited as it is present in OOo 3.3