[Upstream] Regular expression "\n" in replace field inputs "\n" instead of paragraph break

Downstream bug may be found at:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476

1) lsb_release -rd
Description: Ubuntu 11.10
Release: 11.10

2) apt-cache policy libreoffice-calc
libreoffice-calc:
  Installed: 1:3.4.4-0ubuntu1~ppa1
  Candidate: 1:3.4.4-0ubuntu1~ppa1
  Version table:
 *** 1:3.4.4-0ubuntu1~ppa1 0
        500 http://ppa.launchpad.net/libreoffice/ppa/ubuntu/ oneiric/main i386 Packages
        100 /var/lib/dpkg/status
     1:3.4.3-3ubuntu2 0
        500 http://us.archive.ubuntu.com/ubuntu/ oneiric/main i386 Packages

3) What is expected to happen in LibreOffice Calc is when one of the cells contains a line break -> Edit -> Find and Replace... -> in the "Search for" drop down \n -> in the "Replace with" drop down \n -> Regular expression button checked is the line break is replaced with a paragraph break as noted in http://help.libreoffice.org/Common/List_of_Regular_Expressions

4) What happens instead is the line break is replaced with the characters \n

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

Downstream bug may be found at:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476

1) lsb_release -rd
Description: Ubuntu 11.10
Release: 11.10

2) apt-cache policy libreoffice-calc
libreoffice-calc:
  Installed: 1:3.4.4-0ubuntu1~ppa1
  Candidate: 1:3.4.4-0ubuntu1~ppa1
  Version table:
 *** 1:3.4.4-0ubuntu1~ppa1 0
        500 http://ppa.launchpad.net/libreoffice/ppa/ubuntu/ oneiric/main i386 Packages
        100 /var/lib/dpkg/status
     1:3.4.3-3ubuntu2 0
        500 http://us.archive.ubuntu.com/ubuntu/ oneiric/main i386 Packages

3) What is expected to happen in LibreOffice Calc is when one of the cells contains a line break -> Edit -> Find and Replace... -> in the "Search for" drop down \n -> in the "Replace with" drop down \n -> Regular expression button checked is the line break is replaced with a paragraph break as noted in http://help.libreoffice.org/Common/List_of_Regular_Expressions

4) What happens instead is the line break is replaced with the characters \n

*** 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 ***

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.

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 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.

(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.

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.

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. ***

*** 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).

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 ;-)

** 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-20170901

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

** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.

If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug

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* be...

Dear Christopher M. Penalver,

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 with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.

If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug

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.