Bug 135451 - EDITING: Different behavior with No-break space and Narrow no-break space
Summary: EDITING: Different behavior with No-break space and Narrow no-break space
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.3.6.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-04 21:49 UTC by Leroy
Modified: 2020-08-05 08:43 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Leroy 2020-08-04 21:49:52 UTC
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
Comment 1 V Stuart Foote 2020-08-04 22:59:30 UTC
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.