I think it's a duplicate of bug 401194:

https://bugzilla.gnome.org/show_bug.cgi?id=401194

I can confirm that this still happens in 2.30.3, from Linux Mint 9 (Ubuntu 10.04.) This makes programming an absolute hell. Unfortunately, I can't give any advice to duplicate this-- just start using Gedit as your every-day programming editor if you don't already, and you *will* run into it.

Does anyone really care if gedit works or not?  

What do we users need to do to get gedit working?  

I mean no other similar product exhibits this crazy behavior.  

Thus far, the copy-paste functionality is most reliable when the cursor is moved with arrow keys and extremely unreliable when the cursor is moved with the mouse.

So what would it take to get this fixed?

Well, I use gedit dayly and never experience this problem and the same is true for all the other gedit developers, so it is very hard to fix it... Beside if this problem was more common we'd have been flooded with duplicate reports, so I fear it may be something very specific to your system.

I do have this problem occasionally. There is also another problem, which is that when you Ctrl+C then select some whitespace and you Ctrl+V you're actually pasting the whitespace (as if the primary and secondary clipboard are conflicting). I strongly believe this is a bug in gtk+ though (we don't do anything special afaik). The problem is that it is almost impossible to reproduce in a reliable way, indicating that there is some race condition (intuitively I would think this is because of the asynchronous behavior of the clipboard).

It's starting to sound like I am speaking to a customer service rep from Asus. 

Instead of just writing us off how about just hearing me out for a minute, please.  

OK?

Other editors do copy-paste fine, so it's not the HW.  Why do you think other editors have no copy-paste issues?

The issue is settling time when the cursor is relocated. 

If one wishes to PASTE and the cursor is relocated by use of the mouse, there is a 50% chance the PASTE will occur at the cursor location and 50% chance the paste will be done at a random location.

But...

If we relocate the cursor with the mouse, then hit left or right arrow keys, then bring the cursor back using arrow keys, the operation becomes more reliable.  Why do you suppose that is?

It then works because the SW finally caught up with the HW. It's an issue that goes back to the 4MHz Z80 days when trying to input an entire screen's worth of data to the UART.  The serial input was faster than the Z80 could handle it.  This cursor issue just smells of the same problem.

Here's a possible solution:

After a relocation via mouse, put in a debounce or a timing loop and things will be cool.  I am almost sure that will work.

Created attachment 179473 [details]
this is my ~/.gnome2/gedit

Michael, how about if we try to figure out what our gedit configurations have in common?

I've got the following plugins configured at the moment:
* code comment
* document statistics
* file browser pane
* insert date/time
* modelines
* right pane (3rd party plugin)a
* smart spaces
* symbol browser (3rd party)
* tabswitch (3rd party)

However, I happen to know that this problem was still there *before* I added the three 3rd-party plugins, so they have nothing to do with it. 

I have seen an Ubuntu bug report where this bug was blamed on Compiz, however *do not be fooled.* I'm using Metacity without composite enabled. 

I am attaching my ~/.gnome2/gedit, that may help...

Max, I have been debugging stuff before most of the developers' parents were even conceived.  Forty-six years of debugging stuff tells me that if smells of timing issues, it's a timing issue.  It is NOT configuration.  No way, no how.

What should be done is ALWAYS validate the the cursor location before a paste is done.  Loop around the location function until the function output is identical say ten consecutive times.  That will fix it.

Are you really more than 90 years old?

As Paolo says we non of the current developers have this problem, so please if you want this fixed, just try to debug GtkTextView and make a patch for it.

(In reply to comment #10)
> Are you really more than 90 years old?

Just a youthful 62.  And as proof of that, I just shoveled 14 inches of snow off my driveway this morning.  

I started programming as a high school junior when the NSF offered a summer course in Fortran at NYU.

Okay, here is one conceivable scenario in which plugins could exacerbate a timing issue-- (and I say this without really knowing how plugins in Gedit are implemented.) Suppose that the "hooks" for each plugin will add some extra execution time to gedit's main loop. Could this not change the timing and induce a race condition where there was none, or something like that? 

So what I will try to do this afternoon is create a simple plugin for gedit that just calls sleep(0.1) a lot or something like that, see if I can make the bug happen more often.

(In reply to comment #11)
> As Paolo says we non of the current developers have this problem, so please if
> you want this fixed, just try to debug GtkTextView and make a patch for it.

Ignacio:

IMO, it has little to do with debugging GtkTextView.  It has to do with gedit's understanding that data returned from GtkTextView can be unstable for a few milliseconds.  Your developers can solve this in a few hours by just treating the returned data from  GtkTextView as data that needs to be db-bounced while it would take me several months to go through the logic.

should be de-bounced (not db-bounced)  sorry

The problem with the "few milliseconds" thing is that sometimes it happens even if you wait a nontrivial amount of time before pasting.

(In reply to comment #16)
> The problem with the "few milliseconds" thing is that sometimes it happens even
> if you wait a nontrivial amount of time before pasting.


You can wait decades before pasting but that does not alter the fact that GtkTextView had already supplied the unstable data to gedit immediately after the left mouse click.  

The bug still remains that the cursor location obtained from GtkTextView needs to be de-bounced. Without de-bouncing, the results, as I extrapolate from Ignacio's comments, are hardware dependent.

Makes sense.

If that is indeed what the bug is, then this could be fixed either in GtkTextView or in Gedit. Since the documentation for GtkTextView says nothing about debouncing being necessary (or at least [1], which I skimmed,) it may be reasonable to say that this is a TextView bug and not a Gedit bug. 

[1]http://library.gnome.org/devel/gtk/unstable/GtkTextView.html

gedit inherits from GtkTextView and when we have this kind of issues we do the fixes in GtkTextView directly so everybody can get the fix. As said before either debug GtkTextView or provide a workaround in gedit for now. But really without being able to reproduce we cannot do anything about it.

I also have this bug from time to time and I've just found a way to always reproduce it (I'll attach a screencast to illustrate the following steps):

1) Select text (in the screencast: "projet GNU" on the line 12) and copy it with "Ctrl+c".

2) Deselect the copied text. The cursor is still on the same line (in the screencast: line 12).

3) Move the graphical pointer with the mouse (in the screencast: over the line 28) and click on the scroll wheel. Nothing is copied because there's no selection, and the cursor stays to the same line (in the screencast: line 10).

4) Paste with "Ctrl+v".

Actual result: the previous copied text is pasted on the line clicked with the scroll wheel (in the screencast: line 28).

5) Paste again with "Ctrl+v".

Actual result: the second time we paste, it's OK: the text is pasted where the cursor is (in the screencast: line 12).

Created attachment 179494 [details]
Screencast illustrating the steps to reproduce the bug

(In reply to comment #20)
> Nothing is copied because there's no selection, and the cursor stays to the 
> same line (in the screencast: line 10).

Obviously, it's line 12 (not line 10) in the screencast. Sorry...

Ah, so if you accidentally n00bed MOUSE3 due to over-enthusiastic scrolling (or, in my case, *all the time* due to the impreciseness of a touchpad,) it'll paste somewhere between where you started and where you want it to go. 

Note that this definitely does not explain *all* of the problems-- maybe it's a way to reliably generate an old stale position with which to confuse gedit.

Jean-Philippe: you rock! This is indeed 100% reproducible here. It is also reproducible in gtk-demo using Gtk+ 3.0, so I'm reassigning to gtk+.

I'll try to have a look at this bug soon.

Is this a side effect of GtkTextView not knowing its own layout until after the signal handlers have run and the idle callback gets around to doing it's thing? That has driven me nuts for a while now, because we lack a programmatic way to say "Look, I know GtkTextView is trying to be smart, but I really need the line-height and y-range parameters to be accurate, so can you just go and do it? Don't worry, I'll wait."

If it is, then I just discovered something that is a bit of a kludge but seems to be serving as a workaround: cycle the main loop with while (gtk_events_pending()) { gtk_main_iteration_do(); } Much to my surprise, this allows the idle handler to run, when it comes back, the allocation has been done and line heights etc are available.

When Michael noted "unstable data from the text view" this came to mind. Position in the GdkWindow is a side effect of layout, and if that hasn't happened in the button press handler which is taking care of paste, then you could easily be getting wrong co-ordinates as a result.

Anyway, just a thought. Sorry for the noise otherwise.

AfC

I'm working on this.

Just pushed a patch that fixes this problem. Thanks for reporting it. Also the screencast was really helpful.

http://git.gnome.org/browse/gtk+/commit/?id=b7de18ab35e587df98032eaaa3d159d8f8fd64f4

BTW, I fixed what I think it was the problem, feel free to reopen the bug or file a new one if you find out that this bug is not fixed.

Is this fix in gtk+-3.0.1??

Thanks.

yes it is

Has this fix been backported to older versions of GTK? I know the bug exists in older versions.