Bug 333228

Comment 1 Dani Megert 2010-12-27 05:54:07 EST

Does it work when you explicitly copy the contents after step 3?

Comment 2 Shashank Shekhar 2010-12-27 17:42:35 EST

(In reply to comment #1)
> Does it work when you explicitly copy the contents after step 3?

Yeah I do copy explicitly with Ctrl+C after step 3. Ah, I think I left that out while writing the repro steps. Step 3.5.

To clarify: No, I'm not talking about the implicit copy that Linux does in this bug, I'm talking about an explicit copy with Ctrl+C from Eclipse to vim or gedit, and the difference in what gets pasted.

Thanks!

Comment 3 Dani Megert 2010-12-28 05:05:55 EST

(In reply to comment #2)
> (In reply to comment #1)
> > Does it work when you explicitly copy the contents after step 3?
> 
> Yeah I do copy explicitly with Ctrl+C after step 3. Ah, I think I left that out
> while writing the repro steps. Step 3.5.
> 
> To clarify: No, I'm not talking about the implicit copy that Linux does in this
> bug, I'm talking about an explicit copy with Ctrl+C from Eclipse to vim or
> gedit, and the difference in what gets pasted.
> 
> Thanks!

Strange, because it's the task of the target to extract the clipboard contents and at the point when we put the contents into clipboard on the Eclipse side we don't know the target. Given it works on most editors I suspect a VIM issue here (maybe vim locks the clipboard?).

Can you try this: disable the following preference
Java > Editor > Typing > [ ] Update imports
and try again?

Comment 4 Shashank Shekhar 2011-01-03 01:03:14 EST

> Strange, because it's the task of the target to extract the clipboard contents
> and at the point when we put the contents into clipboard on the Eclipse side we
> don't know the target. Given it works on most editors I suspect a VIM issue
> here (maybe vim locks the clipboard?).
> 
> Can you try this: disable the following preference
> Java > Editor > Typing > [ ] Update imports
> and try again?

Thanks, I tried what you suggested, but didn't help.

Emacs 24.4.1 and vim 7.2 both show the same problem

Another useful piece of information: This is more than collapsed imports -- anything that is collapsed has a problem (code blocks, javadoc blocks etc).

But you're right, typically Eclipse shouldn't have anything to do with it, but here's my reasoning (I might be very off since I haven't checked out the code):

The editor ultimately is equivalent to a rich textbox, and a collapsed block will mean that the real textbox contains only one line for the block, not 'n'.

So to allow clipboard copying to occur properly for blocks, maybe a Ctrl+C/Edit>Copy event is overridden and something special is done to parse all collapsed blocks. *That* is where I believe lies the problem -- if we're doing something funky there which non-GUI editors aren't able to understand.

That said, I'm talking through my hat since I haven't read the code. Hope this was useful.

Thanks!
Shashank

Comment 5 Dani Megert 2011-01-04 05:51:25 EST

> > Can you try this: disable the following preference
> > Java > Editor > Typing > [ ] Update imports
> > and try again?
> 
> Thanks, I tried what you suggested, but didn't help.
OK, strange.

> Another useful piece of information: This is more than collapsed imports --
> anything that is collapsed has a problem (code blocks, javadoc blocks etc).
Does it only fail when you copy/paste after Select All (Ctrl+A) or also when you manually select a subset of the whole text which includes some folded stuff?

Comment 6 Shashank Shekhar 2011-01-04 11:08:44 EST

> Does it only fail when you copy/paste after Select All (Ctrl+A) or also when
> you manually select a subset of the whole text which includes some folded
> stuff?

It fails in both cases. Just for the heck of it, I tried pasting in bash (shell) as well, no good.

Example of what I did to test:

Code:
========
package foo.bar;

+ import java.util.HashMap;..

public class Something {

+ public void foo().. 

  public void bar() {
    return "baz";
  }

}
=========

Select All + Copy/Paste obviously fails. The second one was a selection from the "f" in "public void foo()" to the semicolon after 'return "baz"'.

That only printed (in CLI):
foo().. 

  public void bar() {
    return "baz";

BTW, for what it's worth I'm in RHEL5, with GNOME 2.16.0

Thanks for investigating!
Shashank

Comment 7 Shashank Shekhar 2011-01-04 11:12:45 EST

> That only printed (in CLI):
> foo().. 
> 
>   public void bar() {
>     return "baz";

Actually, minor correction, the ".." after foo() isn't printed when I paste in a CLI environment.

How is the ".." square represented in Eclipse? Is it a part of the text editor, or an overlay like the curly-braces highlighters [rectangular outlines] when your cursor is on one brace?

Thanks

Comment 8 Dani Megert 2011-01-05 06:56:01 EST

Sorry, but no luck to reproduce this so far. Can you please try using this build:
http://download.eclipse.org/eclipse/downloads/drops/R-3.6.1-201009090800/index.php

Without additional plug-ins and a fresh workspace.


> How is the ".." square represented in Eclipse? Is it a part of the text 
> editor, or an overlay like the curly-braces highlighters
It's only drawn as overlay and not part of the text/model.

Comment 9 Markus Keller 2011-01-11 11:39:46 EST

I could reproduce this on a linux box.

(In reply to comment #2)
> Yeah I do copy explicitly with Ctrl+C after step 3. Ah, I think I left that out
> while writing the repro steps. Step 3.5.
> 
> To clarify: No, I'm not talking about the implicit copy that Linux does in this
> bug, I'm talking about an explicit copy with Ctrl+C from Eclipse to vim or
> gedit, and the difference in what gets pasted.

That's exactly the problem here. Terminal applications like vim or joe don't seem to consider the system clipboard on Shift+Insert. They always take the last selection. So, it doesn't matter whether you pressed Ctrl+C in Eclipse, since the clipboard is never read in your scenario.

You can see the same if you copy "Hello World" in gedit, and then select only "Hello": In vim, Shift+Insert pastes the selection, not the clipboard.

You need to find a way to really paste the system clipboard. In my install, Edit > Paste (Ctrl+Shift+V) does the job.

Comment 10 Shashank Shekhar 2011-01-11 11:54:41 EST

> That's exactly the problem here. Terminal applications like vim or joe don't
> seem to consider the system clipboard on Shift+Insert. They always take the
> last selection. So, it doesn't matter whether you pressed Ctrl+C in Eclipse,
> since the clipboard is never read in your scenario.
> 
> You can see the same if you copy "Hello World" in gedit, and then select only
> "Hello": In vim, Shift+Insert pastes the selection, not the clipboard.
> 
> You need to find a way to really paste the system clipboard. In my install,
> Edit > Paste (Ctrl+Shift+V) does the job.

Thanks! That makes sense.

So one final question (out of curiosity): does this mean that some special action is taken when a "copy to clipboard" event is intercepted in Eclipse and it inserts the hidden/folded content automatically?

The reason I ask is, is there a way to intercept the X Server event of text-selection event and do the same?

Comment 11 Markus Keller 2011-01-11 13:50:37 EST

Created attachment 186542 [details]
make Ctrl+C also set the selection clipboard

(In reply to comment #10)
> So one final question (out of curiosity): does this mean that some special
> action is taken when a "copy to clipboard" event is intercepted in Eclipse and
> it inserts the hidden/folded content automatically?

Yes. We use a rich text widget for the presentation and implement the folding underneath. Therefore, the X Server has currently no way to get hold of the hidden lines. Our copy action is a custom implementation that copies the underlying document.

> The reason I ask is, is there a way to intercept the X Server event of
> text-selection event and do the same?

No, but this could be implemented manually in the ProjectionViewer. However, that's quite a bit of work, and I don't think we can currently implement this without a performance hit (even on platforms that don't support the selection clipboard at all).

The attached patch is a compromise that just copies the text to the selection clipboard as well when the Copy action is invoked in Eclipse. That's not 100% correct, but it solves your use case without hurting others.

Comment 12 Markus Keller 2011-01-11 13:53:28 EST

Dani, I would release the patch. But we can also leave this bug open for a full solution or close it as invalid with the argument that the selection clipboard is really intended to hold the visible selection (so it's OK to miss the collapsed lines).

Comment 13 Dani Megert 2011-01-12 11:25:04 EST

> Dani, I would release the patch. But we can also leave this bug open for a full
> solution or close it as invalid with the argument that the selection clipboard
> is really intended to hold the visible selection (so it's OK to miss the
> collapsed lines).
I've discussed this with Markus. Given
- we never had a bug about this so far
- there's another way to paste the clipboard
- pasting using middle mouse also insert the visual selection
we decided not to apply the patch.