Problem description: The Search&Replace feature does not properly support regular expressions with lookaheads. It is able to find matches that conform with the lookahead, but pressing the replace button does nothing. Steps to reproduce: 1. You have a text that contains certain combinations of characters, for example AB, and you want to change the formatting of A only if it occurs in front of B. 2. Click Edit → Search & Replace 3. Enter into "Search for": A(?=B) 4. Enter into "Replace by": A 5. While "Replace is focussed, click "Format" and select superscript. 5. Click "Search" and it does find results. 6. Click "Replace". Current behavior: The text stays unchanged. Expected behavior: The matches (A) should be replaced so that they are formatted in superscript. Operating System: Ubuntu Version: 4.0.3.3 release
Hi I could not reproduce this problem on LO 4.0.4, Debian testing amd64. Following your instructions results in superscripted A just before normal B. Can you check if problem still applies to newer version? Best regards Mirosław Zalewski
I was just searching for another (potential) regex problem, and ran across this one. Here are my results: (1) Following OP's instructions *exactly*, I get the *same* result: "AB" remains unchanged. (2) IF, however, I use "Replace All" instead of "Replace", then the "A" is superscripted. I have tried this repeatedly, and it is consistent: in this scenario "Replace" finds *but does not replace* the intended string; but "Replace All" correctly performs the operation. I am using LibO Writer Version: 4.1.4.2 Build ID: 410m0(Build:2) under Linux Mint 13 (LTS; built on Ubuntu Precise 12.04) on a Toshiba Satellite A100. (I would change the status of this comment to "confirmed", but that's not an option I see. Sorry!)
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
I have tried to reproduce this bug again. LibreOffice 4.2.6.2, Debian testing amd64: bug COULD BE reproduced LibreOffice 4.0.4.2, Windows 7 x86: bug COULD BE reproduced Therefore, I am marking this bug as NEW (i.e. confirmed). As for my previous comment, when I wrote that I could not reproduce this bug - I guess I must have clicked "Replace All" instead of "Replace". As David points out, this bug exists if you click "Replace", but not if you click "Replace All". Right now, using 4.0.4 (the same version that I used back then), I could reproduce this issue. Or it might be that this bug did exist, was fixed in 4.0.4 on Linux and then introduced again. But it seems very unlikely.
** 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 (5.0.0.5 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) 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-09-03
Still repro. Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: a7c3a2a9be83686657c06f37d521f9f6d2004ddd Threads 4; Ver: Windows 6.1; Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2015-11-28_04:39:18 Locale: fi-FI (fi_FI)
Created attachment 127405 [details] FindReplaceLookAssertion.odt
Hi More information (I thought to create a new report, but as I was going to use exactly the same title...) Problem also occurs with look-behind assertion. Steps to reproduce: 1. File> Open> FindReplaceLookAssertion.odt attached 2. Edit> Find & Replace 3. Find: (?<=\()[^)]+(?=\)) 4. Click Find All Expected & actual results: text *into* parentheses selected 5. Replace: &test 6. Other options untick "Current selection only" 7. Replace All Expected result: test added before all ) Actual result: "&" is not interpretated (added as text) Note: same replacement is ok with Calc Regards
** 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 (5.4.1 or 5.3.6 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) 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170929
In tdf#75806, leading characters were added to analyzed part of string in TextSearch::searchForward. This fixes look-behind assertions. To handle look-ahead assertions, similarly trailing characters need to be added there.
https://gerrit.libreoffice.org/85487
*** Bug 111646 has been marked as a duplicate of this bug. ***
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0cd3b7926cafc01d06b589124215e9cb7c148f19 tdf#65038: use trailing string characters for look-ahead assertions It will be available in 6.5.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.
*** Bug 136890 has been marked as a duplicate of this bug. ***