Backreference ($n) in "replace" is not evaluated if word boundary symbol is present in "search" string. Steps to reproduce: 1. Open new document, write to it: #v+ what whatever what whatever what whatever what #v- (there is no space after final word) 2. Open "Search and replace" dialog. Check "regular expression" in "More options". 3. In "Search" field write: (what)\> 4. In "Replace" field write: $1ever 5. Hit "Replace all" Expected output: #v+ whatever whatever whatever whatever whatever whatever whatever #v- Actual output depends on application. 1. Calc gets it all correct (as expected). 2. Impress and Draw gets it all wrong: #v+ $1ever whatever $1ever whatever $1ever whatever $1ever #v- 3. Writer gets it half-correct - backreference is evaluated only if matched word is last word in line: #v+ $1ever whatever $1ever whatever $1ever whatever whatever #v- I was able to reproduce this behavior on: 1. LibreOffice 3.6 on Windows 7, i386 (only Writer tested) 2. LibreOffice 3.5.5 on Debian, amd64 3. LibreOffice 3.5.0 on Windows 7, i386 (only Writer tested) (build id: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735) I can not check it on any earlier version of LO, but this is possible regression. Best regards Mirosław Zalewski
Hi I have tried some other versions (all tests on Windows 7 x86). Results: 1. LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 Problem exists (Calc gets it correct, Writer gets it half-correct, Impress and Draw get it wrong). 2. OpenOffice.org 3.3.0 OOO330m20 (Build: 9567) Problem exists (Calc gets it correct, Writer gets it half-correct, Impress and Draw get it wrong). 3. OpenOffice.org 2.4.2 Problem exists (Calc gets it correct, Writer gets it half-correct, Impress and Draw get it wrong). 4. Apache OpenOffice 3.4.0 AOO340m1(Build9590) - Rev. 1327774 Problem is somehow fixed (Calc and Writer get it correct, Impress gets it wrong; Draw is not able to search by regexp anymore). So, this is not regression - it actually never worked as it should in LibreOffice. I don't know if it ever did in OOo. Apache guys have fixed Writer - maybe change may be incorporated in LO?
I can still reproduce it on 3.6.4-rc1. Marking as NEW, since it is 100% reproducible (different versions on different operating systems).
As we re-based on the Apache code-base we got this fix for writer - so it works there nicely now. As you note it worked in calc. In draw regexp search has been removed/disabled (no idea why) That leaves this as an impress issue. Since the whole regex code changed in 4.0 and we will not back-port; I'll pull up the version to that and re-title. Thanks for the careful report ! If someone is interested in doing more research on this poking at: svx/source/dialog/srchdlg.cxx and how that fits into the editeng / text processing in draw would be a good place to start.
I have encountered (no backreferences stored) a similar problem when using regex lookarounds in my search string. You can reproduce it with a simple search string, eg. (?<=\s)(\d).
novacellus: To keep this bug report clean, I have reverted changes you have made. This bug is about Impress inability to handle case described in first comment. Since there is no number, your regexp will not match in this case. It is another issue and should be handled as such. Please file another bug report, mentioning: - exact string you are working on - results you get - results you expect - LO version you have tested - applications that are affected (is this only Writer, or also Calc and Impress?). Thank you for your cooperation and will to make LibreOffice better :) .
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (4.4.0.3 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-02-19
Impress doesn't have regex in find & replace. Win 7 Pro 64-bit, LibO Version: 4.4.1.2 Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432 Locale: fi_FI Version: 4.5.0.0.alpha0+ (x64) Build ID: 5a009a4387a84a36d2e3418c7e7b097cb10c3f5a TinderBox: Win-x86_64@42, Branch:master, Time: 2015-03-04_15:00:21 Locale: fi_FI Ubuntu 14.10 64-bit Version: 4.4.1.2 Build ID: 40m0(Build:2) Locale: en_US
Prioritizing: *Please do not adjust the priority without consulting QA on the mailing list or in the chat room http://webchat.freenode.net/?channels=libreoffice-qa Priorities are set per this chart: https://wiki.documentfoundation.org/File:Prioritizing_Bugs_Flowchart.jpg Per Michael's input from the comment, it seems like this is an enhancement request. Regex was updated for Calc/Writer but for some reason left out of Impress. So - it's an enhancement to bring that functionality into impress.
This is a bug. The missing regex support in Impress is another thing; but in the absence of the support, the search string "(what)\>" in parentheses and with trailing angle bracket should *not* match anything in the search text from repro steps given in comment 0. So the still reproducible result of replacing "what" with "$1ever" (by the way, only the first time after opening F&R dialog: undoing changes in the document without closing the dialog and trying to replace all again does not replace anything) is actually a bug. Tested with Version: 6.5.0.0.alpha0+ (x64) Build ID: eb973a46ba0e34026db2d2929f2aa10505623872 CPU threads: 12; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: CL
FTR: "Support regexes in Impress" is tdf#122785. Wrong Word behaviour is fixed in tdf#75806 and tdf#65038.
Dear Mirosław Zalewski, 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
repro 26.8 (under very specific circumstances) 1.) In Writer, I have to first open the find and replace dialog (Ctrl-H) and turn on regex. Close LO so regex is saved to user search preferences. 2.) Start Impress or Draw, do a search for (what)\>. It will do a regex search. Note that any use of the quick find (in either Writer or Impress/Draw) forces regex off.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ce4939aeacb81d378885dce96947872437c9e631 tdf#53290 srchdlg: only set SearchItem RegExp if button is visible It will be available in 27.2.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.