(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" :)
(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