Created attachment 55673 [details] document that demonstrates problem with find&replace to reproduce this problem: 0. Open attachment 1. Edit->Find&Replace 2. Place into field "Search for": ([0-9]{2})([0-9]{2}) 3. Place into field "Replace with": $1.$2 4. click "More option" on bottom of dialog 5. check option "Enable regular expressions" 6. Press "Replace all" Expected: instead of 1345-1430 appears 13.45-14.30 Actually: instead of 1345-1430 appears 13.45-14..0 What is interesting: if press "Replace" to replace one-by-one cell, it replaces correctly reproduced in LibO 3.3.4, 3.4.3 and 3.5.0 beta 2 on Fedora 64 bit and Windows XP 32 bit
Confirm with LibO 3.5RC1 One by one: 13.45-14.30 13.45-14.30 14.50-15.30 12.55-13.35 12.30-13.40 In one go: 13.45-13..4 13.45-13..4 14.50-14..5 12.55-12..5 12.30-12..3
@ Florian Reisinger Thanks for interesting in my bug. But version -- most old version of LibO, where bug is reproducible, in my case 3.3.4. It is not current version of LibO.
*** Bug 47659 has been marked as a duplicate of this bug. ***
I was told that LO doesn't tolerate the character "&" at the beginning of the search or replace string, and the problem was reported in OOo and LO bug https://issues.apache.org/ooo/show_bug.cgi?id=116928. As a temporary solution, I recommend Alternative Find & Replace extension. There are different requests for Find & Replace. I opened Bug 38261 - Better Find&Replace with regular expressions, but it's Enhancement, and thus not a priority.
(In reply to comment #4) > I was told that LO doesn't tolerate the character "&" at the beginning of the > search or replace string, and the problem was reported in OOo and LO bug > https://issues.apache.org/ooo/show_bug.cgi?id=116928. thanks for the info, then this one is an enhancement, so also not an MAB thanks for the suggestion too:
Not sure i understand why we speak of enhancement here. This is a bug, obviously, which prevents using "Replace All" with regular expressions. My bug, which was marked as a duplicate for this one (and it looks like, indeed), clearly shows a wrong behaviour which can lead to malicious errors hard to notice when replacing many strings.
(In reply to comment #6) > Not sure i understand why we speak of enhancement here. This is a bug, Maybe I'm wrong - I'll ask the QA list for others to have a look.
Very less people using this feature.
Just for be more clear: in original descriptions nothing about "&" character. If problem with it exist, then it is completely another bug.
I can reproduce this issue with LibO 3.5.2.2. For me this is clearly a bug, since it runs contrary to people knowledgable about REs would expect. REs are probably not the feature that everyone needs, but for me it's still an important distinction of LibO versus MS Office... and as long as it is available it should be implemented correctly. Can't say much about the ampersand (&) issue, since I did not understand why the Apache Bug given should be related. Plus: There is no ampersand in the search or replace string, so most likely this is a different issue.
This is clearly a bug. I changed back to "Severity|normal" and "Priority|high". Cor Nouws and dE, please don't change without understanding what this means. Regular expressions are important advanced function that can be used either directly either through an add-on which enhances poor LO FInd&Replace dialog.
Priority wars! Please, do spend you time twiddling that back and forth, it's good and productive.
dtardon->dE: "The title clearly says "LibreOffice 3.5 most annoying bugs"... yours is not even a bug. ... We're only interested in bugs which cause data loss, corruption, crashes, and other i/o errors (especially with MS office formats)." So by your standards an incorrect replacement (which may go unnoticed) is not a data loss? Not even a bug? dtardon grabs some popcorn and eagerly awaits the next round of MAB changes...
Allright, let the bug be fixed!
David Tardon committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ea1cd1a10cc2d2bbf4f82aeca689fe81a3b79856 fdo#44861 make "Replace All" work with REs
Here some comments, most became obsolete with David's fix: This is inherited from OOo, I see it in OOo 3.3., OOo 3.4Beta and OOo 3.1.1. OOo2 not tested, OOo 1.1.4 did not know the $-replace-reference. The problem is limited to CALC, I tested the sample document pasted as plain text to a new WRITER document, result 'Replace all' as expected. I believe CALC has a problem to manage the find results and to associate them with the correct replace actions. I additionally tested with the complete contents of the 5 cells in the sample document in one Cell A1 of a new spreadsheet: 1. <f2> for edit mode 2. click before very first character 3. Menu 'Edit -> Find and Replace -> insert find and replace strings -> click "Regular Expressions"' 4. <Replace All> Expected: all 4-number-groups get an additional dot into the middle Actual: see below Result of step 4: 13.45-13..4 13..4-13..4 13..4-13..4 13..4-13..4 13..4-13..4 Here also everything works fine when I replace one by one. @All: I doubt that a bug concerning a function that never worked can be a "MAB". But if my suspect that there is a deeper find and replace problem is true, related problems might justify such a rating (I still doubt and tend to agree with dE's decision). IMHO careful research is much more relevant for a quick bugfixing process than listing in MAB @Timur: I do not understand relation to the AOOo bug I consider your comments as inappropriate (although I agree tat this is a Bug after my results in WRITER). @David: Thx for stopping discussion here with a FIX :-)
David Tardon committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4bd76b74c0145635ef69caa94e3235f6ce3ab5de&g=libreoffice-3-5 fdo#44861 make "Replace All" work with REs It will be available in LibreOffice 3.5.3.
@ David Tardon Thanks for fixing!
@David Tardon: thank you, a fix is indeed much more efficient than a war! Can't wait for Calc 3.5.3.
Thnak you, works now as expected in LO 3.5.3 rc0+ (LibreOffice 3.5.3rc0+ Version ID : 3d2333d-a73d29c-6845e52-f269e46-cd57e28) Best regards. JBF
Ok, this is how you get a bug fixed REAL quick in libreoffice! :D ;)
@ dE Now try to replace bugreports in MAB, closed by duplicate by their survived counterparts. It would be very useful job.
Works great for me with parallel installation of Master "LOdev 3.6.0alpha0+ – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 8a78020]" (tinderbox: Win-x86@6-fast pull time 2012-04-18 23:51:20) and proceeding due to original report. But I can't test due to comment 16 "tested with the complete contents of the 5 cells in the sample document in one Cell A1" (there is a mistake in the description: "A1" should be "B1") because of "Bug 48909 - EDITING: Crash when copy/paste contents of adjanced cells into 1 Cell". Currently I can't tell with what commit the bug has been introduced.
Zdeněk Crhonek committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/ef58bf56ad292656ad2de0a417eda72cc170f782%5E%21 uitest for bug tdf#44861 It will be available in 6.3.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.