Problem description: If you copy or move paragraphs to a new position always no paragraph end character is inserted in front or after the inserted paragraph. Steps to reproduce: [1] Create a new text document. [2] Display non-printing characters. [3] Insert four short paragraphs with at least 2 Sentences each. [4] Select the second paragraph with four mouse clicks. → All words of paragraph but not the paragraph end character are displayed as selected. Expected: Also the paragraph end character and the rest of the line should be displayed as selected. Go on with step 5a or 5b. [5a] Copy paragraph to Clipboard: Ctrl+C. Go on with step 6a or 6b. [5b] Cut paragraph to Clipboard: Ctrl+X. The paragraph end character of the paragraph of the cutted paragraph still remains. Expected: Also the paragraph end character should be deleted. Go on with 6a or 6b. [6a] Move cursor in front of the first word of the fourth paragraph. Go on with 7a. [7a] Insert paragraph from Clipboard: Ctrl+V → The text of the second paragraph is added to the fourth paragraph. That means no paragraph end character is inserted. Expected: Insertion of a new paragraph before the fourth paragraph, that means a paragraph end character has to be inserted. END. [6b] Move cursor directly in front of the paragraph end character of the third paragraph. Go on with 7b. [7b] Insert paragraph from Clipboard: Ctrl+V → The text of the second paragraph is added to the third paragraph. That means no paragraph end character is inserted. Expected: Insertion of a new paragraph after the third paragraph, that means a paragraph end character has to be inserted. END. The behaviour is equal if you drag and drop the paragraph with the mouse. Bug already exists in my oldest installed version 3.5.0. Bug 68268 describes a similar problem with sentences. Operating System: Windows 7 Version: 4.1.0.4 release
Thank you for your bug report, I can reproduce this bug running LibreOffice. Version: 4.1.1.2 Build ID: 7e4286b58adc75a14f6d83f53a03b6c11fa2903 on Mac osx 10.8.4.
** 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 (4.4.1 or later) 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-01
Bug still exists in version 4.4.1.2 with Win 7. Bug already exists in version 3.3.0. Hence version set to "Inherited from OOo".
** 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.0.5 or 5.1.2 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
Bug still exists with version 5.2.0.
** 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
Bug still exists with version 5.4.4. (64Bit, Win10)
Is this even valid? Behavior now when you select content (with 4 mouse clicks OR with <Ctrl><Shift>+<Down>) of a paragraph--you _do not_ include the paragraph break. So it would be wrong to insert one on paste. If you need the paragraph end in the selection, extend the selection to include the end marker. Current (legacy behavior) is correct. IMHO => WONTFIX
Double checked the behavior of MS Word and the paragraph break is included in the selection, meaning like requested here. On the other hand it's pretty clear what is selected and with one additional key stroke you can add the break. IIRC, we had the same or similar discussion where the cursor should go when jumping with ctrl+up/down where it also wasn't clear if we go to the beginning of the next paragraph or the end of the current. Both approaches have an advantage, IMHO.
(In reply to Heiko Tietze from comment #9) > ... On the other hand it's pretty > clear what is selected and with one additional key stroke you can add the > break. I think a quad click in order to select a paragraph is not used by a lot of users. Thus I do not think that most of these users are aware that they have to select the paragraph end character explicitly. In most cases they afterwards will 'repair' the text by deleting and/or inserting a paragraph end character. Furthermore it's more logical and consistent to insert a paragraph with a paragraph end character: A word is also inserted with an additional space and a sentence is inserted with a full stop. Certainly this is not a bigger problem, but I think a change would make LibreOffice just a bit smarter at this place.
I would not wish nor dare to touch this. I like the behavior of Writer more then the one in Word. I remember that I always had to be careful / change selection there. Also it is not just the paragraph end that is copied. It also has influence on formatting. So can we expect requests in that area too? Writer is fine, just good, in this regard. IMO WontFix,
Application Comparison: = Browsers = Firefox : Not Included Chromium-based : Included = Word Processors = Abiword : Included Calligra : Not Included - Windows - WordPad : Included MS Word : Included WordPerfect : Included - Mac - WPS/Kingsoft : Included iWork Pages : Included TextEdit : Included - Browser - Google Docs : Included
I agree with Cor Nouws in comment 11. But I would support the idea if the user can choose the behavior (with or without end character) in the options dialog.
also, this "problem" already exists since 1995 or so :) Apart from that I appreciate the present behavior for a workflow faster and cleaner than I remember from the other program, also consider what one might break in existing macro applications. I suggest to close as NotABug
We discussed the pros and cons in the design meeting. While users from other tools would benefit from the familiar workflow (see Jay's comparison in comment 12) the LibreOffice users know and accept our way of dealing with paragraph breaks. So we came to the conclusion to keep the current behavior.
*** Bug 88923 has been marked as a duplicate of this bug. ***
I think we should reconsider this one in the light of all the "See Also" that stem from not understanding this one, and probably there will be more. At lest we need a dedicated help page. I'm in favor of option for a user to choose, if feasible.
We talked about the topic in the design meeting and agree with Timur that an option would be nice. However, the implementation should be done carefully facing the pitfalls of paragraph handling. For example whether source or target style is taken needs to be defined.