New odd behaviour with 5.4.0.3 x64 on Win10 x64. I cut and paste a lot in writing reports and do not usually want the source formatting, so generally paste as "unformatted text". I often do this between pre-prepared quote marks. The unformatted text paste now puts the trailing quote in the wrong place. Steps to reproduce:- 1. Create a new blank document 2. Write some words with a line break in there somewhere. This will be the source text (mine is usually from Acrobat pdf's but this doesnt matter) 3. Prepare some target text - "" will do nicely 4. Select and Ctrl-C the text created in (2) 5. Place the cursor between the characters created in (3) and Ctrl-V. The text will appear correctly between the "" 6. Repeat from (3) but this time, on pasting, paste using Ctrl-shift-V and select unformatted text. Now the trailing quote appears incorrectly at the end of the first line of the pasted text, rather than at the end of the whole block. A small bug, but I am having to make a lot of manual adjustments to correct for it.
Confirmed the placement of a closing quote is made at the end of the first paragraph/linebreak from pasted material. But it happens for any target text in a paragraph. On Windows 10 Ent 64-bit en-US with Version: 5.4.0.3 (x64) Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c CPU threads: 8; OS: Windows 6.19; UI render: GL; Locale: en-US (en_US); Calc: group Note: if the copied text has line continuations <Shift><Return> rather than new lines the target is split to the end of the pasted content. Seems composing the paste result is incorrectly stopping with the first new line.
Just to confirm that this is still present in 5.4.1.2.
Just to confirm that this bug is still present in 5.4.2.2 x64
Just to confirm that this is still present in 5.4.4.4 and 6.0.0.1. I am left stuck on 5.3x :(
QA note: Version is the earliest build an issue is reproducible. Please do not adjust unless performing bibisect. Simpler STR, prepare new document with "" target marker. Position cursor between marks. Open Help -> About dialog, select and <Ctrl>+c to copy its text. As selection here will "only" be unformatted text, Close the dialog to return cursor focus to document at the target. A <Ctrl>+v to paste the unformatted text. Closing quote of marker will be positioned to end of the first paragraph of the pasted text.
Created attachment 138692 [details] tail of terminal output from bibisect I see the bug in, for exmaple, daily Linux dbgutil bibisect repository version 2017-12-16. So I am setting O/S = All. Working on debian-buster in the till54 bibisect repository, I see that the bug entered LO somewhere in the 62 or so commits commit date s-h -------- ---------- -------- good ea8b303b 2017-04-25 e4f28aea bad 96ac09db 2017-04-26 d8a56401 I am removing keyword bibisectRequest and adding keywords regression, bibisected. In the bibisected range, I notice commit e68b6e34, "Optimize plain-text import". Michael, are you interested?
Confirmed. Regression introduced by: author Michael Meeks <michael.meeks@collabora.com> 2017-04-24 14:58:54 +0100 committer Michael Meeks <michael.meeks@collabora.com> 2017-04-25 16:49:41 +0200 commit e68b6e349c31ac1376e90218013e1e7612f2b522 (patch) tree b1c19255d11dc1e99c08b71b4ae12e31412bef7b parent dec025d4cb51f252ecd7e981fe36800cf2bedff5 (diff) Optimize plain-text import. Cost of managing rsids is very significant >50% of import time, new Rsids will be generated for changes anyway. Also avoid un-necessary splitting of paragraphs on new-line. Bisected with: bibisect-linux-64-5.4 Adding Cc: to Michael Meeks
*** Bug 114706 has been marked as a duplicate of this bug. ***
Bug 114706 contains more general case to reproduce.
(In reply to Kevin Suo from comment #9) > Bug 114706 contains more general case to reproduce. Yes, agree it is not related to the delimiters, "" or any other. Issue is with the plain text paste/import action.
*** Bug 113708 has been marked as a duplicate of this bug. ***
This (and its duplicates) mudt be a duplicate of bug 115088 which is just now fixed. The have the same bisect result. Need to test against the most recent version. *** This bug has been marked as a duplicate of bug 115088 ***