Description: Select a word (without leading or following space in Writer. Hit Ctrl C. Place the cursor somewhere within a piece of text and hit Ctrl V. Irrespective of placement, a leading space is always added, even if the cursor is placed after a space i.e. you get this (vertical bar shows cursor position) blabla, "| » blabla, " pasted blabla, " | » blabla, " pasted , | » , pasted The default behaviour I would expect would be that if a select a word without also selecting leading spaces, paste action should result in there not being a leading space. Or if LO is smart, the it should only insert a leading space if appropriate i.e. if I did blabla.| then the outcome blabla. pasted would be acceptable. But not the current behaviour. Actual Results: see above Expected Results: see above Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0
not reproducable for me with LO 5.3.6.1 and Win10 x64
Hi Michael, Use Alt+Ctrl+Shift+V instead of Ctrl+V at the copy place, or Ctrl+Shift+V and make your choice into the contextual menu. These commands are available in the Edit menu.
If it's an issue not longer present in future versions I can live with it until then. But long-term the Alt+Ctrl+Shift+V / Ctrl+Shift+V is NOT a practicable workaround, always adding a leading space is not an acceptable default behaviour for users.
(In reply to Michael Bauer from comment #3) > If it's an issue not longer present in future versions I can live with it > until then. But long-term the Alt+Ctrl+Shift+V / Ctrl+Shift+V is NOT a > practicable workaround, always adding a leading space is not an acceptable > default behaviour for users. I agree to you, that the long-term is not user friendly. I also couldn't reproduce the behaviour with an older version(4.4.7.2). So perhaps a newer version won't help you.
Hi Michael, Dieter, A precision: Ctrl+Shift+V with Un/Formated Text paste the clipboard content without leading space. Alt+Ctrl+V is a shortcut available. This can be added by you right now ? Is it a good choice? Do you have an other idea to submit to enhancement? Jacques
(In reply to Jacques Guilleron from comment #5) > Hi Michael, Dieter, > > A precision: Ctrl+Shift+V with Un/Formated Text paste the clipboard content > without leading space. > Alt+Ctrl+V is a shortcut available. This can be added by you right now ? Is > it a good choice? Do you have an other idea to submit to enhancement? > > Jacques Jacques, you set the bug to NEW and enhancement. Could you reproduce it? I think this is necessary before you change the status to NEW. => Set to NEEDINFO In addition: When I use Ctrl+Shift+V the "paste special" dialog is opened. So I don't understand why this should solve the problem in a userfriendly way even if it exists.
You are right. The Copy with leading space is a usual attempt and in conform with the private suite. I was focused to find a simpler way to copy without leading space. Alt+Ctrl+V associated with Copy unformated text is easier a little, and can be added to replace Alt+Ctrl+Shift+V. That's what I proposed as enhancement. But this is not the matter of this report. It can make the object of a new one. This one can be closed I think as Not a bug. Do you agree? Thanks for the attention.
(In reply to Jacques Guilleron from comment #7) > You are right. > The Copy with leading space is a usual attempt and in conform with the > private suite. > I was focused to find a simpler way to copy without leading space. > Alt+Ctrl+V associated with Copy unformated text is easier a little, and can > be added to replace Alt+Ctrl+Shift+V. That's what I proposed as enhancement. > But this is not the matter of this report. > It can make the object of a new one. I agree to you > This one can be closed I think as Not a bug. > Do you agree? I wouldn't close it yet. Perhaps another use can reproduce it. But feel free to decide different.
I can't confirm an issue with double space. When copying "word" in the sentence "this is a word for testing" then before and after "word" a space will be inserted when pasting "word". When copying "this" no space will be added. When copying "testing" no space will be added. If I add a question mark at the end of the sentence and I'm copying "testing?" then no space will be added. Sometimes I noticed a leading or trailing space, but I can't reproduce it. The behaviour could need some love, maybe. But MS Word is doing the same when copying "word" in the example above. Generally speaking, LibreOffice works as 'expected'. Version: 6.0.0.0.alpha0+ Build ID: 9c34471f54870fc685c343f4af30310e75d3a9ca CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-09-06_02:17:21 Locale: de-DE (de_DE.UTF-8); Calc: group
I would like to add a new set of steps to reliably reproduce. 1. Select a word (without leading spaces) in LibreOffice Writer. 2. Copy the selected word. 2. Place the cursor AT THE END of a line that ends in one or more trailing spaces. 3. Paste the selected word at the new cursor position. Observed behavior: LibreOffice inserts an extra leading space before the word disregarding the current number of spaces at the end of the line. Expected behavior: LibreOffice only inserts a space before a pasted word if A) the word was selected without leading spaces, and B) the word was pasted immediately after another word without a space in between Note: This "expected behavior" that I describe above can be observed if one pastes a word without leading spaces IN THE MIDDLE of a line rather than AT THE END of a line. Additional Information: LibreOffice Version: 6.0.0.0.alpha0+ Operating System: Ubuntu Gnome 17.04
I confirm the results described in comment 10. But that means, that this behaviour occurs only at the end of a paragraph (= end of the line with trailing spaces). Normally a paragraph doesn't end with a space. So in most cases it is userfriendly (in my point of view), if a space is added, even when you copy a word without spaces. Is this really a bug? And if so, what would be an appropriate summary. I don't change the status to new, because I can't confirm the bug as it is described in the summary.
I don't think it is default user behaviour to type, not insert an ending space and then paste. Certainly in my case (I also asked my colleagues and they confirm the same behaviour) that if they paste something at the end of the line, there is usually a space they have typed before they paste something. So at least in my mini-survey, most people will end up with extraneous double spaces.
So also in your case the described behaviour only occurs at the end of a paragraph?
On 5.4.1.2 now but yes, it seems to be the case that this only happens at the end of the paragraph. I also tried inserting into the middle of a sentence in the middle of 4 or more spaces and it does not seem to add an additional one there. Well spotted blendergeek, I hadn't seen that pattern :)
I believe this is a bug and I will try to explain. I will use underscores as stand-ins for spaces so that we can visualize it. We have the following paragraph: Lorem_ipsum_dolor_sit_ Note that there is a trailing "space" at the end of the line. I position the cursor at the end of the line and paste "amet" (copied without spaces). The paragraph now reads: Lorem_ipsum_dolor_sit__amet Notice the TWO "spaces" between "sit" and "amet". I would expect to only find one space there especially given that if I had pasted "amet" with the cursor just before "sit" the paragraph would read Lorem_ipsum_dolor_ametsit Note the ONE "space" between dolor and amet despite the cursor being AFTER the space. This is different from the behavior at the end of the line and is thus counterintuitive and I therefore would consider it a bug.
Set to NEW and changed the bug summary. actual result: If you copy a word without spaces and paste it at the end pof a pargraph, LO always adds a leading space expectd result: LO only adds a leading space if a space is missing at the end of the paragraph
*** Bug 125175 has been marked as a duplicate of this bug. ***
*** Bug 152202 has been marked as a duplicate of this bug. ***