Created attachment 180641 [details] Sample Document Steps how to reproduce with Server Installation of Version: 7.4.0.0.alpha0+ (x64) Build ID b871abad383583f02eb49c7e49aeae01f6941072 CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE | Calc: CL | Auto Colibre Theme | Newly created User Profile: 0. Open attached sample document 1. Menu ˋFind → Replaceˊ » Dialog opens 3. Check "Reglar Expressions" 4. Type serch string "^r" (without Quotations Marks), leave Replace string empty 5. [Find all] » all first "r" of a paragraph will be highlighted 6. [Replace all] » Expected: only leading "r" of paragraph will be deleted » Actual: all "r" will be deleted and it does not matter whether you replace forward or backward 10. Close without saving and reopen 0. Open attached sample document 11. Menu ˋFind → Replaceˊ » Dialog opens 13. Check "Regular Expressions" 14. Type search string "r$" (without Quotations Marks), leave Replace string empty 15. [Find all] » all first "r" of a paragraph will be highlighted 16. [Replace all] » Expected: only "r" at end of paragraph (= end of line) will be deleted » Actual: as expected and it does not matter whether you replace forward or backward Additional info: ----------------- a) That's a strange difference between 'delete all first "r"' and 'delete all last "r"'. I think it's a bug, not a feature. b) Additional research shows a possible reason: If you replace one by one you see that the highlighting will stay at the old place as long as there is a paragraph leading "r". Only when there is nor more "r" in the line (and so also no leading "r" highlighting jumps to next line b1) You might argue that that is intended. I can follow with some tummy ache b2) 'Replace Backwards' changes the behavior, after having replaced highlighting jumps to line before. but continuing highlighting will go around and around as long as no more "r" has survived But: c) Proceeding as (b) for r$ paragraph terminating "r" shows a different behavior in details, but the result will be the same no "r" will survive if you press [Replace] often enough. d) I did not test all details, but difference between (6) and (16) has been inherited from OOo My concern: ----------- Different behavior in 6: deletes all "r" and 16: only deletes all LAST "r"
I was able to reproduce the reported issue. (Not the specified build but on a Release version) Version: 7.3.4.2 (x64) / LibreOffice Community Build ID: 728fec16bd5f605073805c3c9e7c4212a0120dc5 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-GB Calc: CL Additional Notes: Step 15.a – should be >> all last "r" of a paragraph will be highlighted This issue is happening only on specific content. if the leading text “r” is followed by the same letter on the same line and on the next paragraph then the issue occurs. For (OtherSample), the function is working as expected. I tried a different product MSO Version 2205 Build 16.0.15225.20172 64-bit used “^pr”(without Quotations Marks) and it yielded the below result: >> Highlighted value is almost the same (but including the line break) >>When ‘Replace All’ is triggered only the leading "r" of the paragraph was deleted (not all) but will append the remaining text to a single line. (SampleMSOandReference) The result is somewhat closer to what is expected of the Writer, but do we know if any individuals or corporations will use a document with that particular sequence?
Created attachment 180849 [details] OtherSample
Created attachment 180850 [details] SampleMSOandReference
Based on Comment 1, I will mark as NEW.
Created attachment 180876 [details] ExpandedSample
Replicated using Version: 7.3.4.2 / LibreOffice Community Build ID: 728fec16bd5f605073805c3c9e7c4212a0120dc5 CPU threads: 8; OS: Mac OS X 12.0.1; UI render: default; VCL: osx Locale: en-PH (en_PH.UTF-8); UI: en-US Calc: threaded I retried and expanded the data in the Find field and found the issue more serious than I initially assessed. The issue is not isolated to a single letter but rather to the entirety of the value in the Find field. (ExpandedValue) shows another set of text. Use "^pa" and "^aa" (without Quotations Marks) accordingly to show the gravity of the issue. Reiterating the result in the competing product. Although not what we expected as well. Tried in Google Docs as well using "\pa" (without Quotations Marks) >> same result with Writer By fixing the issue in the Writer we can improve the value to users, and provide a function that is not present in the competing products.