*** Bug 43086 has been marked as a duplicate of this bug. ***

I think this is a duplicate of bug44398, i.e. isn't this a more general problem than just \n?

(behaviour confirmed with version 3.5.3release, details entered in comment with bug 44398)

*** This bug has been marked as a duplicate of bug 44398 ***

Winfried Donkers, I do not agree with this being a duplicate of bug 44398, nor do I agree with bug 44398 being accepted as a valid report for that matter based on the title.

Many, purposefully or ignorantly, make wide-scoped "fix everything about a feature set" reports, as 44398's title is, and your subsequent comment https://bugs.freedesktop.org/show_bug.cgi?id=44398#c2 . This makes a report less likely to be resolved quickly.

However, this (43107) report is targeted, specific, and detailed.

Please do not toggle this report further unless you are submitting a patch. Thank you.

In 3.5.7 rc1 or 3.6.2.2 use "\n\n" in the replace field.
That works for me.
Can you pls check that?
(I remeber in the late OOo times there was a change in this, but can't find the details now).

I intend to close this one soon

(In reply to comment #4)
> In 3.5.7 rc1 or 3.6.2.2 use "\n\n" in the replace field.
> That works for me.
> Can you pls check that?

In Calc 3.6.2.2 (Build ID: da8c1e6) on Windows 7 64-bit, if I
 - use "\n\n" (excluding quotes) in the replace field
 - Click Replace all

Calc inserts those literal characters into the cell(s), not newline characters. Based on that I don't think this bug is fixed.

Using Version 3.6.3.2 on Mac OSX, \n is inserted as literal text (i.e., not as a newline) as well.

Version 3.6.5.2 (Build ID: 5b93205) on Linux. Same problem - neither \n nor \n\n work.

*** Bug 64144 has been marked as a duplicate of this bug. ***

Confirmed in 4.2.6.3 on Fedora (Build ID: 4.2.6.3-8.fc20).

This bug still exists in LO 5.0.1.2 on Windows 7.

It's a really painful bug, since manually entering cells, going to the right point and doing a Alt-Enter multiple times per cell is very time consuming, prone to error and above all very dull ;-)

Yes, it's still present, 5.3.6 on Fedora.

Still present in 6.0.6.2.

Confirming: still present in 6.0.6.2 on Gentoo

hmm - does anyone have a test document, with a cells containing line break and one with a new paragraph ?

> does anyone have a test document

You can't reproduce?

Steps:

* Create a blank sheet
* Double-click on a cell to inline-edit it
* Enter two-line content (e.g. "first line", <Ctrl>-<Enter>, "last line") and hit <Enter>
* Open find/replace (Ctrl-H)
* Expand "other options" and tick "regular expressions"
* In find, enter "\n" without quotation marks
* In replace, enter "\nmiddle line\n"
* Click "Replace all"

Expected:

* Cell contains three lines: "first line", "middle line", "last line"

Actual:

* Cell contains one line: "first line\nmiddle line\nlast line" (literal string)

(In reply to DN from comment #17)

> * Create a blank sheet
> * Double-click on a cell to inline-edit it
> * Enter two-line content (e.g. "first line", <Ctrl>-<Enter>, "last line")
> and hit <Enter>

Help reads: : "\n is for line end entered with Shft+Enter"

Hence I do not have a file to test this exactly..

> * Cell contains one line: "first line\nmiddle line\nlast line" (literal
> string)

I see that too, of course, but..

behavior was the same in version 3.3.0 and is in OpenOffice.
So, is this really a bug, or something that behaves different than expected??

> Help reads: : "\n is for line end entered with Shft+Enter"

(for anyone else reading - the help page by clicking Help on the search/replace window and clicking "List of Regular Expressions")

This is a documentation bug. This refers to Writer only, not Calc.

In *Writer*, <Enter> creates a "Paragraph break", whereas <Shift><Enter> creates a "line break". Search/replace works as per the "List of Regular Expressions" docs in Writer, specifically:

> \n
> Represents a line break that was inserted with the Shift+Enter key combination. To change a line break into a paragraph break, enter \n in the Find and Replace boxes, and then perform a search and replace.
> \n in the Find text box stands for a line break that was inserted with the Shift+Enter key combination.
> \n in the Replace text box stands for a paragraph break that can be entered with the Enter or Return key.



> Hence I do not have a file to test this exactly..

The steps I listed result in a doc to test this.



> behavior was the same in version 3.3.0 and is in OpenOffice.
> So, is this really a bug, or something that behaves different than expected??

It's a bug. The content of "replace" should be interpreted as a regex (i.e. \n should be interpreted as a newline, not a literal string). It may well have always been a bug in Open/LibreOffice.

(In reply to DN from comment #20)
> > Help reads: : "\n is for line end entered with Shft+Enter"
> 
> (for anyone else reading - the help page by clicking Help on the
> search/replace window and clicking "List of Regular Expressions")
> 
> This is a documentation bug. This refers to Writer only, not Calc.

There is more. Who says Ctrl+Enter creates a new line in a Calc text cell?

Unzip a Calc file with a 'new line', and you see:
  <text:p>text on line one</text:p><text:p>And this on line too</text:p>

Unzip a Writer file with a 'new line', and you see:
  <text:p text:style-name="P1">This is line one<text:line-break/>and this is line two</text:p>

So, although the Calc cell UI does not know the paragraph concept, the xml file does.
Thus the question still stands: what are the bugs, and/or not yet implemented features? (see below)
 
> > Hence I do not have a file to test this exactly..
> 
> The steps I listed result in a doc to test this.

They don't - hence my request ;)
 
> > behavior was the same in version 3.3.0 and is in OpenOffice.
> > So, is this really a bug, or something that behaves different than expected??
> 
> It's a bug. The content of "replace" should be interpreted as a regex (i.e.
> \n should be interpreted as a newline, not a literal string). It may well
> have always been a bug in Open/LibreOffice.

No doubt that I agree, that one would expect that Find & Replace replaces 'line breaks'. In any case, in there is no line break, a result 'not found' would be more appropriate.

So bugs/problems are:
- a 'new line' in Calc text cells, produces a new paragraph;
  - it makes sense that, since Shift+Enter does the opposite of Enter,
   Ctrl+Enter is used for the line break (new line/paragraph)
  - maybe it should really create a line break?
- Find & Replace should either report: no new lines found; or behave different in Calc text, handling paragraphs as if it were line breaks;
- documentation is not clear/complete.

adding @eike and @regina to cc.

(In reply to Cor Nouws from comment #21)
> There is more. Who says Ctrl+Enter creates a new line in a Calc text cell?

It does. Did you test and see what happens?
 
> Unzip a Calc file with a 'new line', and you see:
>   <text:p>text on line one</text:p><text:p>And this on line too</text:p>
> 
> Unzip a Writer file with a 'new line', and you see:
>   <text:p text:style-name="P1">This is line one<text:line-break/>and this is
> line two</text:p>

This isn't relevant to whether this is a bug. What's relevant is what the user actually sees/experiences. Which is a newline. Which is *also* what's in the docs: https://help.libreoffice.org/Common/Inserting_Line_Breaks_in_Cells

> So, although the Calc cell UI does not know the paragraph concept, the xml
> file does.

Unless it's a fundamental limitation of ODS, this is also irrelevant in terms of this being a bug, and just means there is separate bug with saving to ODS. Even in the case of a fundamental limitation of the format, it doesn't negate this bug; it might make it CANTFIX at most.

> Thus the question still stands: what are the bugs, and/or not yet
> implemented features? (see below)
>  
> > > Hence I do not have a file to test this exactly..
> > 
> > The steps I listed result in a doc to test this.
> 
> They don't - hence my request ;)

Your previous comments made no mention of my steps not working. Please tell me how the outcome when you tried differed from my description.

 > > > behavior was the same in version 3.3.0 and is in OpenOffice.
> > > So, is this really a bug, or something that behaves different than expected??
> > 
> > It's a bug. The content of "replace" should be interpreted as a regex (i.e.
> > \n should be interpreted as a newline, not a literal string). It may well
> > have always been a bug in Open/LibreOffice.
> 
> No doubt that I agree, that one would expect that Find & Replace replaces
> 'line breaks'. In any case, in there is no line break, a result 'not found'
> would be more appropriate.

Covered above. Ctrl-Enter = line break per docs. Displays as line break. User wants a line break. Document saving bugs are irrelevant, unless they're the *cause* of this bug. A "not found" would be adding another effective bug (in terms of intended/documented behaviour) to align with other buggy behaviour elsewhere.

> 
> So bugs/problems are:
> - a 'new line' in Calc text cells, produces a new paragraph;

Separate bug re. ODS and maybe internal state.

Additionally, the *find* part works fine. The *replace* part is this bug.

>   - it makes sense that, since Shift+Enter does the opposite of Enter,
>    Ctrl+Enter is used for the line break (new line/paragraph)

It effectively does now (user experience/documentation). Again, nothing to do with this bug, which is about *replacement*.

>   - maybe it should really create a line break?

Not directly relevant, might be a dependency for this bug - see above.

> - Find & Replace should either report: no new lines found; or behave
> different in Calc text, handling paragraphs as if it were line breaks;

Or Ctrl-Enter should just actually insert a line break per the docs - possibly a separate bug. Again, this bug is about *replacement* being literal \n instead of an (effectively) line break.

> - documentation is not clear/complete.

Possibly, but tangential.

> 
> adding @eike and @regina to cc.

Still present, 6.2.8.2.

Documentation bug fixed in https://git.libreoffice.org/help/+/55d4e405d8dbdf58ba45823b3895e8a79e5a8aed.

(In reply to DN from comment #20)
> The content of "replace" should be interpreted as a regex (i.e.
> \n should be interpreted as a newline, not a literal string).

While I *don't* tell that this tdf#43107 is not a bug, I want to stress that it's incorrect to consider *replacement* string as a "regex" - no, it is never so. Only a search string is a regex. The replacement string is a special string that, as per documentation [1], may contain references.

We have an extension of that syntax; and there is bug 106137 to extend it further. I would argue that for consistency, exactly because in Calc, the newline in a cell inserts *paragraphs* (not only available in the file format, but also in the API; and that is not a bug), the \n in the replacement box should behave *consistently* with Writer, where it inserts paragraphs.

Just don't say that replacement string is a "regex" :)

[1] https://unicode-org.github.io/icu/userguide/strings/regexp.html#find-and-replace

Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/help/commit/00a07b02f82b2177c6d1ad90168528ca9eb73be8

Related: tdf#43107 Clarify \n in Find and Replace

*** Bug 152838 has been marked as a duplicate of this bug. ***

As the original reporter, I accept this being root caused to a documentation issue now fixed by:
https://bugs.documentfoundation.org/show_bug.cgi?id=43107#c27

I wouldn't have filed this report if it had been documented as such to begin with.