Created attachment 152141 [details] file with 3 words Assign a key (eg, ~w) to InsertWord (Tools>Customize kbd>Navigate). Open words.odt; put cursor near A or B, hit ~w: 'AB' is selected: OK; M or N, hit ~w: 'MN' is selected: OK; C or D, hit ~w: comma is selected! Double-click works, with hardblank included.
(In reply to TorrAB from comment #0) > Assign a key (eg, ~w) to InsertWord (Tools>Customize kbd>Navigate). Can't find the command InsertWord. Do you mean Select Word?
(In reply to Dieter Praas from comment #1) > (In reply to TorrAB from comment #0) > > Assign a key (eg, ~w) to InsertWord (Tools>Customize kbd>Navigate). > > Can't find the command InsertWord. Do you mean Select Word? Yes! Sorry about that.
I confirm that beaviour with Version: 6.2.5.1 (x64) Build-ID: 9a940173fab1747f02322bc89779759d52b3a086 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded and Version: 6.4.0.0.alpha0+ (x64) Build ID: ae823e4633a76d13cebc6432b9e44b9b2862326b CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-26_23:06:07 Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded I think the reason is the protected space between comma and CD => I changed bug summary a little.
Not sure this is a bug. Use of the NBS (U+00a0) depends on placement relative to punctuation. That is when prepended (i.e. following the comma) is included with a "double click" mouse selection. Likewise is included when the NBS is appended (i.e. preceding the closing parehnthesis ). And again included with the "double click" mouse selection, or the "Select Word" UNO action. So this handling of NBS is either hard coded in edit engine, or is an ICU lib function (have not checked src). Believe it is wrapped up in the way we handle selection at ICU 'word' bounds. And we have at least three UNO actions that can be used. 1. double mouse click 2. Select Word (assigned by OP, but action of double mouse click) 3. Select to Beginning of Word (assigned <Ctl>+<Shift>+<L cursor>) 4. Select to Word Right (assigned <Ctl>+<Shift>+<R cursor>) Anyhow the handling is consistent--the NBS is included with the correct word depending on leading or trailing punctuation. So Not A Bug? And, to select the literal of the middle word, rather than double click or the "Select Word" action--position cursor and select to begining of Word, or select to end of Word (labeled as Select to Word Right)--both of which have assigned keyboard shortcuts.
The edit engine handling of the selections at word bounds is done in impedit2.cxx, no special logic for NBS or other NPC noted. Meaning, IIUC the word boundary is as provided by ICS lib. https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit2.cxx?&r=a682d129&h=1412#1480
s/ICS/ICU
Created attachment 152495 [details] file with 5 words to select
(In reply to V Stuart Foote from comment #5) > The edit engine handling The Writer text core doesn't use EditEngine to determine word boundaries though..
(In reply to V Stuart Foote from comment #5) > Meaning, IIUC the word boundary is as provided by ICS lib. So NAB/NOB? Protected space as well as non-breaking spaces or any other special space are formatting aids, they don't separate one word from the other. Like sticking units to the number. What I mean, I don't see the scenario where protected space is used and word selection is expected as requested.
(In reply to Heiko Tietze from comment #9) > (In reply to V Stuart Foote from comment #5) > > Meaning, IIUC the word boundary is as provided by ICS lib. > > So NAB/NOB? > > Protected space as well as non-breaking spaces or any other special space > are formatting aids, they don't separate one word from the other. Like > sticking units to the number. What I mean, I don't see the scenario where > protected space is used and word selection is expected as requested. 'non-breaking spaces or any other special space […] don't separate one word from the other'. True. But, try this again: Put cursor between f and g, hit ~w: the 4 dashes are selected, but 'efgh' (which was targeted) is NOT! NAB, really?
(In reply to TorrAB from comment #10) > (In reply to Heiko Tietze from comment #9) The valid 'bug' here is difference in behavior of Word selection. A double mouse click correctly selects to full word bounds, with correct handling of NPC as expected. A customized shortcut assigned the 'Select Word' UNO action does not. And in fact is loosing its position passing over the NPC and selecting the preceeding word's text run! With shortcut assigned for Select Word, open attachment 152495 [details] Position text cursor to the word 'efgh' and enter the shortcut. Selection jumps backward to the '---- ' word. Whilst a double mouse click will select the ' efgh'. Similar misbehavior if positioned at ' CDEF'. A double mouse click will select the word, but using the shortcut 'Word Select' will jump backward and select ',;:!* ' =-testing-= Windows 10 Home 64-bit en-US (1809) with Version: 6.4.0.0.alpha0+ (x64) Build ID: 2f2f4767089512c34514896bc37823f9310e9dd4 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-07-10_02:13:57 Locale: en-US (en_US); UI-Language: en-US Calc: threaded or with Version: 6.2.5.2 (x64) Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
(In reply to V Stuart Foote from comment #11) > ... > A double mouse click correctly selects to full word bounds, with correct > handling of NPC as expected. > > A customized shortcut assigned the 'Select Word' UNO action does not. And in > fact is loosing its position passing over the NPC and selecting the > preceeding word's text run! True, that's a nasty bug. Removing UX.
Still present in Version: 7.1.4.1 (x64) / LibreOffice Community Build ID: f67b1ddedeb24fca1c5938e7cebfab73d708b35b CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL
Dear TorrAB, 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
A bit different behaviour in Version: 7.6.0.1 (X86_64) / LibreOffice Community Build ID: 776eaf34564cbf3f034a0ba1fd1d5c32ff9ccf1c CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded but still wrong Steps: 1. Assign a key (eg, Strg+W) to "Select Word" (Tools -> Customize -> Keyboard) 2. Open attachment 152141 [details] 3. Put cursor between A and B, hit Strg+W: 'AB' is selected: OK 4. Put cursor between M and N, hit Strg+W: 'MN' is selected: OK 5. Put cursor between C and D, hit Strg+W: 'AB" is selected! Wrong (Double-click works, with hardblank included.) 6. Put cursor behind CD, hit Strg+W: 'CD' is selected: OK