Bug 108256 - EDITING: find/replace regular expressions: \n has 2 meanings, it shouldn't
Summary: EDITING: find/replace regular expressions: \n has 2 meanings, it shouldn't
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
: 91033 112575 (view as bug list)
Depends on:
Blocks: Find&Replace-Dialog
  Show dependency treegraph
Reported: 2017-05-31 04:26 UTC by akerblom
Modified: 2018-02-17 11:13 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

findReplace.odt: sample document showing two situations LO can't handle (13.91 KB, application/vnd.oasis.opendocument.text)
2018-02-17 10:38 UTC, Justin L

Note You need to log in before you can comment on or make changes to this bug.
Description akerblom 2017-05-31 04:26:01 UTC
In find/replace, when the "regular expressions" options box is checked, the product intentionally has "\n" mean one thing in the search box, and a different thing in the replace box:  

From the help file:
\n in the Search for text box stands for a line break that was inserted with the Shift+Enter key combination.
\n in the Replace with text box stands for a paragraph break that can be entered with the Enter or Return key.

This means that I can never search for a paragraph break, and I can never replace anything with a line break. 

As these are two different characters, they should really be represented by different expressions in the find/replace feature so that users have the flexibility to find on either one, and replace with either one.
Comment 1 Dieter 2017-06-01 13:03:36 UTC
I can understand your problem, but for me it is only a theoretical problem. I can't think of a situation, where I want to search for a paragraph break or want to replace something with a line break. Can you give one or two examples?
Comment 2 akerblom 2017-06-01 16:00:49 UTC
2 have occurred just in my household:

1- my daughter wanted to cut and paste song lyrics into a story she was writing, but in paragraph form.  So she needed to at the end of every line hand delete the paragraph break and replace it with a space.  It was a very long song.

2- I have hundreds/thousands of old emails from back when they were sent only in plain text format.  When you would reply, the paragraphs would be word-wrapped at 76 characters (or so) and on each new line a "> " would be prepended.  We'd format new paragraphs by having 2 carriage returns.  Preserving old emails into a document requires replacing all those single carriage returns with spaces and the double carriage returns with single carriage returns.  A lot of reformatting.

Basically - this is something you run into with reformatting text obtained from elsewhere.  Also, it would be helpful for bringing text from or to a spreadsheet format.

Clearly it is not a theoretical problem. In fact, a quick google search finds complaints about this going back 5-6 years, with some painful workarounds. But really this should just be in the already available find/replace feature.  Noone should have to cut and paste thier LibreWriter doc into MSWord to be able to replace on <CR>.
Comment 3 Dieter 2017-06-01 16:22:26 UTC
Thank you for the explanations and examples. I agree, that there are some situations, where it might be useful. Set to NEW.
Comment 4 Daniel Grigoras 2017-09-22 13:40:35 UTC Comment hidden (no-value)
Comment 5 V Stuart Foote 2017-09-22 22:00:01 UTC Comment hidden (no-value)
Comment 6 Justin L 2018-02-17 10:38:30 UTC
Created attachment 139959 [details]
findReplace.odt: sample document showing two situations LO can't handle

I think this document demonstrates the two situations described in comment 2 and also covers the "\nTextToReplace" concept from comment 4 which in MSWord search syntax would be "^pTextToReplace".

The key idea here is to do these things as single searches (preferably via a replace all). Otherwise the user has to make multiple "replace/next" passes through the document to accomplish each task.
Comment 7 Justin L 2018-02-17 10:59:38 UTC
*** Bug 91033 has been marked as a duplicate of this bug. ***
Comment 8 Justin L 2018-02-17 11:13:22 UTC
*** Bug 112575 has been marked as a duplicate of this bug. ***