Description: Cut is cutting outside the selected range Steps to Reproduce: 1. Open the attached file 2. Select the yellow highlight text.. except the first spacing.. so starting at 'f' of four. Until the point (without . included) 3. CTRL+X Press CTRL+Z. No include the . in the selection.. no it does I would expect in the first place Actual Results: Yellow marking gone in full Expected Results: Should remain small block with yellow marking Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 7.2.0.0.alpha0+ (x64) Build ID: f2171af6ce3516598d9f8bac8294025a21a5b1a2 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL and in 4.4.7.2 and in 4.3 but not in 4.2
Created attachment 168902 [details] Example file
Thank you for reporting the bug. I can confirm the bug present in Version: 7.0.3.1 (x64) Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL Version: 7.2.0.0.alpha0+ (x64) Build ID: 761a672d62df1891b9f4f367a499b220ab2b33fa CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Created attachment 168998 [details] Different example same effect Select the yellow marked area
@Buovjaga If you're in the mood of doing a 'skippy' hard bibisect.. I got made few mistake while bibisect.. and got bored.. and LibO kept continue crashing or not opening at all (with gen backend). So not sure if even possible to get something useful Could have copy/pasted the demo also if opening failed.. Anyhow did try really hard I might look into it someday
I used Linux's bibisect-43max. There is a range of about 550 commits where the document wouldn't load until 'Revert "impl. enumeration for ZipPackage"', and then a few more commits until the main text re-appeared (thanks to 'Support for singleton constructor functions'). https://cgit.freedesktop.org/libreoffice/core/log/?id=c0864f26f3143ea81c65d3826fae32a8fd54c531&qt=range&q=94227ec32e4736d4a85e4d82be195eaef5ce45f1..997d21183322a0a94b96868073808841d2773902 There are lots of commits dealing with string length, and comments... P.S. I found the description a bit confusing - too much irrelevant information. I focused on the fact that the leading space was selected as part of the deletion, and the undo showed the leading space included in the selection. I almost wouldn't call this a bug, since in most cases, connecting the fullstop to the end of the previous word would be the general user intention.
(In reply to Justin L from comment #5) > I almost wouldn't call this a bug, since in most cases, connecting the > fullstop to the end of the previous word would be the general user intention. This kind of 'feature' shouldn't be hardcoded somewhere. It it will eat 'explicit' set formatting -red formatting - attachment 168998 [details] Also not working consistently: replace the ! attachment 168998 [details] by '.' and select & cut the yellow text next.. now it works as I would expect it to work I really dislike an Office Suite knowing what. Prefer to be in control :P So if this somehow 'wanted' it should be done by auto-correct, IMHO
Dear Telesto, 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
Same as Justin, I wouldn't consider the removal of the preceding space as a bug, it's more of a convenience feature for people wanting to cut a word without ending up with useless or duplicated space. Ctrl + Z does restore it as expected. And the conversation is better had in bug 141738. However, there is certainly some inconsistency, and that would be a bug: 1. Open attachment 168998 [details] 2. Cut yellow highlight: preceding space removed 3. Ctrl + Z: space restored 4. Change exclamation point to a full stop 5. Cut yellow highlight: preceding space not removed! 6. Ctrl + Z 7. Change back to exclamation point 8. Cut yellow highlight: preceding space still not removed! So let's change the focus of this report. Reproduced in recent trunk build: Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 5589659829f8a1cef8ca1c8a468732105bbe231b CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Worked consistently in: Version: 6.1.0.3 Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk2; Locale: en-AU (en_AU.UTF-8); Calc: group threaded Bibisected with linux-64-6.2 repo to first bad build commit [ae82aa93d4536e9529688f412def4a23908f1d40] which points to core commit 94c1af65367dcbc7272455cf6d4940252a289b62 which is a cherrypick of: commit 32902f66e7749b2d06d13f50416be5323a0c0ea9 author Michael Stahl <Michael.Stahl@cib.de> Fri Nov 30 17:54:41 2018 +0100 committer Michael Stahl <Michael.Stahl@cib.de> Tue Dec 18 17:55:30 2018 +0100 sw_redlinehide: make layout based Show/Hide mode the default Turns out it's related to track changes. Not reproduced if turned off. Michael, can you please have a look?
this functionality, which i was previously unaware of, is implemented in: SwWrtShell::IntelligentCut() if(cWord == WORD_NO_SPACE && ' ' == cPrev ) { cWord = WORD_SPACE_BEFORE; // delete the space before if(bCut) { Push(); if(IsCursorPtAtEnd()) SwapPam(); ClearMark(); SetMark(); SwCursorShell::Left(1,SwCursorSkipMode::Chars); SwFEShell::Delete(true); Pop(SwCursorShell::PopMode::DeleteCurrent); } } ... and has existed since initial CVS import. since this function is obviously more intelligent than i am, i can't know what it ought to do (but perhaps we should tell marketing to mention the AI feature a lot). fixed the regression on master anyway.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ab2b0bd10481e9d0bb5bfea09ab0b034bb246c52 tdf#139631 sw_redlinehide: fix IntelligentCut feature with redlines It will be available in 24.8.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/53d8675436cb500adff0f9f6aa0063b9c00962dd tdf#139631 sw_redlinehide: fix IntelligentCut feature with redlines It will be available in 24.2.1. 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.
Thanks Michael for the intelligence-mending, fix verified in: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d0dcd87788910e3c9f67a2b68534019c05b77bad CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded