Launchpad has imported 23 comments from the remote bug at https://bugs.documentfoundation.org/show_bug.cgi?id=43107.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-11-20T05:20:33+00:00 Christopher M. Penalver wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/4 ------------------------------------------------------------------------ On 2011-11-20T05:21:38+00:00 Christopher M. Penalver wrote: *** Bug 43086 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/5 ------------------------------------------------------------------------ On 2012-05-06T23:30:22+00:00 E-osc wrote: 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 *** Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/13 ------------------------------------------------------------------------ On 2012-05-06T23:51:50+00:00 Christopher M. Penalver wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/15 ------------------------------------------------------------------------ On 2012-10-06T21:02:53+00:00 Cno wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/17 ------------------------------------------------------------------------ On 2012-10-08T14:08:56+00:00 Alex Willmer wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/19 ------------------------------------------------------------------------ On 2012-11-06T13:58:49+00:00 Carsten Pohle wrote: Using Version 3.6.3.2 on Mac OSX, \n is inserted as literal text (i.e., not as a newline) as well. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/21 ------------------------------------------------------------------------ On 2013-03-22T17:50:12+00:00 Johnny Baloney wrote: Version 3.6.5.2 (Build ID: 5b93205) on Linux. Same problem - neither \n nor \n\n work. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/23 ------------------------------------------------------------------------ On 2013-07-09T10:18:39+00:00 Jorendc wrote: *** Bug 64144 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/25 ------------------------------------------------------------------------ On 2014-11-01T21:51:51+00:00 Nemo_bis wrote: Confirmed in 4.2.6.3 on Fedora (Build ID: 4.2.6.3-8.fc20). Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/27 ------------------------------------------------------------------------ On 2015-09-17T15:45:36+00:00 Patrick Smits wrote: 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 ;-) Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/28 ------------------------------------------------------------------------ On 2017-09-01T11:15:48+00:00 Qa-admin-q wrote: ** 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/29 ------------------------------------------------------------------------ On 2017-09-02T15:49:31+00:00 Documentfoundation-j wrote: Yes, it's still present, 5.3.6 on Fedora. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/30 ------------------------------------------------------------------------ On 2018-09-03T02:43:32+00:00 Qa-admin-q wrote: ** 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/31 ------------------------------------------------------------------------ On 2018-09-03T11:34:46+00:00 Documentfoundation-j wrote: Still present in 6.0.6.2. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/32 ------------------------------------------------------------------------ On 2018-09-03T23:22:33+00:00 Freedesktop-7 wrote: Confirming: still present in 6.0.6.2 on Gentoo Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/33 ------------------------------------------------------------------------ On 2018-09-07T15:23:39+00:00 Cno wrote: hmm - does anyone have a test document, with a cells containing line break and one with a new paragraph ? Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/34 ------------------------------------------------------------------------ On 2018-09-07T15:45:47+00:00 Documentfoundation-j wrote: > 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) Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/35 ------------------------------------------------------------------------ On 2018-09-07T16:03:24+00:00 Cno wrote: (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.. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/36 ------------------------------------------------------------------------ On 2018-09-07T16:07:35+00:00 Cno wrote: 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?? Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/37 ------------------------------------------------------------------------ On 2018-09-07T16:25:04+00:00 Documentfoundation-j wrote: > 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/38 ------------------------------------------------------------------------ On 2018-09-07T20:50:28+00:00 Cno wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/39 ------------------------------------------------------------------------ On 2018-09-07T21:30:45+00:00 Documentfoundation-j wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/892476/comments/40 ** Changed in: df-libreoffice Status: Unknown => Confirmed ** Changed in: df-libreoffice Importance: Unknown => Medium -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/892476 Title: [Upstream] Regular expression "\n" in replace field inputs "\n" instead of paragraph break Status in LibreOffice: Confirmed Status in libreoffice package in Ubuntu: Incomplete Bug description: 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 ProblemType: BugDistroRelease: Ubuntu 11.10 Package: libreoffice-calc 1:3.4.3-3ubuntu2 ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4 Uname: Linux 3.0.0-12-generic x86_64 ApportVersion: 1.23-0ubuntu4 Architecture: amd64 Date: Sat Nov 19 13:02:28 2011 EcryptfsInUse: YesInstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)SourcePackage: libreoffice UpgradeStatus: Upgraded to oneiric on 2011-10-16 (34 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/892476/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
