[Libreoffice-bugs] [Bug 43107] Regular expression "\n" in replace field inputs "\n" instead of line(paragraph?) break

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=43107

--- Comment #22 from DN <documentfoundation at nuclearsunshine.com> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20180907/d01fe669/attachment.html>