<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Regular expression "\n" in replace field inputs "\n" instead of line(paragraph?) break" href="https://bugs.documentfoundation.org/show_bug.cgi?id=43107#c22">Comment # 22</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Regular expression "\n" in replace field inputs "\n" instead of line(paragraph?) break" href="https://bugs.documentfoundation.org/show_bug.cgi?id=43107">bug 43107</a> from <a class="email" href="mailto:documentfoundation@nuclearsunshine.com" title="DN <documentfoundation@nuclearsunshine.com>"> DN</a> <pre>(In reply to Cor Nouws from <a href="show_bug.cgi?id=43107#c21">comment #21</a>) > 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: <a href="https://help.libreoffice.org/Common/Inserting_Line_Breaks_in_Cells">https://help.libreoffice.org/Common/Inserting_Line_Breaks_in_Cells</a> > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>