Download it now!
Bug 53290 - [Find and replace] Backreference is not evaluated if word boundary is present in search string
Summary: [Find and replace] Backreference is not evaluated if word boundary is present...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected)
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Find-Search
  Show dependency treegraph
Reported: 2012-08-09 11:51 UTC by Mirosław Zalewski
Modified: 2019-12-19 09:56 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Mirosław Zalewski 2012-08-09 11:51:19 UTC
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:
what whatever what whatever
what whatever what
(there is no space after final word)
2. Open "Search and replace" dialog. Check "regular expression" in "More options".
3. In "Search" field write:
4. In "Replace" field write:
5. Hit "Replace all"

Expected output:
whatever whatever whatever whatever
whatever whatever whatever

Actual output depends on application.
1. Calc gets it all correct (as expected).
2. Impress and Draw gets it all wrong:
$1ever whatever $1ever whatever
$1ever whatever $1ever
3. Writer gets it half-correct - backreference is evaluated only if matched word is last word in line:
$1ever whatever $1ever whatever
$1ever whatever whatever

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
Comment 1 Mirosław Zalewski 2012-08-16 15:34:57 UTC

I have tried some other versions (all tests on Windows 7 x86). Results:

1. LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-

Problem exists (Calc gets it correct, Writer gets it half-correct, Impress and Draw get it wrong).

2. 3.3.0
OOO330m20 (Build: 9567)

Problem exists (Calc gets it correct, Writer gets it half-correct, Impress and Draw get it wrong).

3. 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?
Comment 2 Mirosław Zalewski 2012-11-24 14:21:32 UTC
I can still reproduce it on 3.6.4-rc1.
Marking as NEW, since it is 100% reproducible (different versions on different operating systems).
Comment 3 Michael Meeks 2012-12-18 16:37:40 UTC
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:


and how that fits into the editeng / text processing in draw would be a good place to start.
Comment 4 novacellus 2013-03-12 10:41:48 UTC
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).
Comment 5 Mirosław Zalewski 2013-03-20 12:41:49 UTC
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 :) .
Comment 6 QA Administrators 2015-02-19 15:42:49 UTC Comment hidden (obsolete)
Comment 7 Buovjaga 2015-03-08 20:01:06 UTC
Impress doesn't have regex in find & replace.

Win 7 Pro 64-bit, LibO Version:
Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
Locale: fi_FI

Version: (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 
Build ID: 40m0(Build:2)
Locale: en_US
Comment 8 Joel Madero 2015-03-11 18:25:02 UTC
*Please do not adjust the priority without consulting QA on the mailing list or in the chat room

Priorities are set per this chart:

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.
Comment 9 Mike Kaganski 2019-12-19 09:10:16 UTC
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: (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
Comment 10 Mike Kaganski 2019-12-19 09:56:37 UTC
FTR: "Support regexes in Impress" is tdf#122785.
Wrong Word behaviour is fixed in tdf#75806 and tdf#65038.