Copy and Paste onto highlighted text

[waxhead]

v5.10.0 built for i486-linux-gnu-thread-multi

Wx Version: 0.91 wxWidgets 2.8.9

This is trunk after 0.36 was released.

I'm running trunk at the moment.

To replicate the bug, have more than one tab open, highlight the text in the editor copy. In the other tab, hight the text you want to replace and paste.

The highlight disappears and no text is pasted in place.

This does appear to be something 'internal' to Padre. Copying and pasting text externally to Padre works fine.

[therek]

Gave it a try on my FreeBSD box (i386-freebsd-thread-multi-64int) with exact same versions of Perl/Wx running r5249 and couldn't reproduce the problem.

[waxhead]

Interesting, I've updated trunk again tonight.

To test this out I open a new file typed some text and then opened another editor tab and typed some more. Did a copy from one, highlighted some text and did a paste.

It worked as it should.

So to make sure I'm not going mad, I opened a perl script.

I then copied some test from "unsaved 1". I went back to the perlscript, and then highlighted some test and pasted it in, and it failed.

No text was pasted into the file.

I wonder if it's something odd with opening the file?

[therek]

Alright. I managed to reproduce your problem this time. It appears only when you:

• first select and copy text,
• then double click to mark text that's to be replace
• and then try to paste it.

It does not happen when you select text to be replaced with keyboard (as I usually do).

The source of problem here is that UNIX graphical environments actually utilize two different clipboards for copy/pasting. One is your WM's clipboard (GTK in case of wxGTK) accessible through CTRL-C/CTRL-V, the other one is X11's accessible through mouse text selection for copying and middle button for pasting. This actually allows you to store two different strings in clipboards (try first double clicking, and CTRL-C different texts, then middle-click and CTRL-V).

It appears that wxGTK/STC cripples the content of CTRL-C clipboard when it pulls double-click selection into the clipboard, though it does not happen when you do it the other way around.

A solution to this issue might be grabbing clipboard content on EVT_TEXT_COPY, storing is somewhere (for example in Padre::DB::History) and retrieving it from there on EVT_TEXT_PASTE. Though it might introduce a bit of overhead, that might not be really needed--IMHO it's not a big problem afterall.

[patspam]

This bug is more extensive for me (Padre 0.37, Wx.pm 0.91 and wxWidgets 2.8.9, Ubuntu 9.04).

Steps to reproduce:
*) Copy some text
*) Select text with the mouse <- immediately clears paste buffer

Does not happen if you select text with the keyboard instead.
Regardless of whether you double-click or not.
Regardless of how many tabs are open.

Perhaps this is a separate bug altogether?

[Sewi]

The bug is solved (r6885) but unfortunatly the solution has another bug:
When using the middle button for pasting, the (correct) result is sometimes mixed. It seems that another event fires on the middle button, but I can't find it.

[Sewi]

Update: The 2nd event inserts the content of the X11 clipboard (and not the "regular" filled using Ctrl+C/Ctrl+V).

Open a terminal/shell window, select something and copy it using Ctrl+Shift+C. Go to padre, select something and copy it using Ctrl+C. Now press the middle button (it doesn't happen every time, you may need to try some times): Your padre-selection is being inserted and sometimes also the terminal/shell selection follows.

Maybe, a workaround could backup and clear the X11 buffer on the middle_up event and restore it when the event is done or shortly (~50ms?) after it is done.

[code4pay]

Hopefully the attached diff fixes this issue. Needs some testing by other people and on Windows

Commit Comment: Fix for Bug #390. Now chooses which clipboard to use selecting and pasting in X11.

[code4pay]

Attempted fix for Pasting isssue

[Sewi]

Patch results:

• New, empty editor window
• Write "foo", next line "bar"
• Select "foo" by double clicking it
• Select "bar" by double clicking it
• Press middle button

Expected:

• "bar" is replaced by "foo"

What happens:

• "bar" is (depending on exact cursor position) replaced by "bbarar" or "babarr"

Others:

• Text copied to clipboard by selecting is not usable on other apps (tried using shell window).

[yakudzo]

This is perl, v5.8.8 built for i686-linux-thread-multi
Wx Version=(0,94) wxWidgets 2.8.10 unicode=(1)
Padre 0.52
KDE 4.3

bug still exist. Steps to reproduce:

1) select some text(e.g New, empty editor window ) and copy to buffer with ctrl+c
2) open padre document and paste it with middle mouse button
3) you will get the result:
NeNew?, empty editor windoww, empty editor window

[submersible_toaster]

There are a horde of bugs hiding in here, and working nicely with the X11 implied selection buffer AND a real clipboard seems difficult.

Desired behaviour for users WITHOUT a middle-button-pastes-my-last-selection-addiction..,

• control-c and select,context click,copy share the same clipboard
• select text followed by paste replaces the selection with the clipboard buffer

For middle button users, as above and also

Middle button should replace the current selection with the so called 'PrimarySelection?'. The problem this raises is how to distinguish when a selection buffer should be written to the PrimarySelection? or not.

Driving me crazy now...

[code4pay]

Looks like the patch was not included I will chase that up. Patch was tested by Sewi IRC log from 2009-11-11  http://irclog.perlgeek.de/padre/2009-11-11. Shows the discussion

Sewi
	Tried it using Gnome texteditor but it doesn't support mid-button at all :-)
        
09:13
	code4pay
	yes though I think you can copy from a terminal and paste to it using middle mouse


09:14
	
	So I guess we need to work out exactly what functionality we want the middle mouse button to perform


09:14
	
	I'd be happy with it working like it would in say a terminal session

   
09:14
	
	on X11 not sure about windows
     

09:15
	Sewi
	will try with other tools, but currently writing a test :-)


    
09:15
	code4pay
	ok


 
09:22
	
	kdevelop looks like it works pretty well the same as my patch does. ie allows the middle mouse to work as it would in a terminal


        
09:23
	Sewi
	All tests successful :-)

       

09:23
	code4pay
	OK great


        
09:25
	Sewi
	Openoffice: Replace selection does work, but it replaces the selection by the last selected value (the thing being replaced), so it does nothing at all. Won't expect this


       
09:30
	
	same for poedit

}}

[Sewi]

Sorry, submersible, but this patch doesn't work for me.
Applied it on r10022.

Middle button pasting doesn't work at all with this patch (for me), nothing is pasted but the current selection (if there is any) is removed (probably replaced by nothing).

[Sewi]

PS: Using this patch seems to clear the X PrimarySelection? buffer. I used middle-button-paste in a shell window just before starting Padre and now the shell's paste buffer is empty.

[submersible_toaster]

Folks please ignore the 390-submersible patch (you do you delete attachments in trac?), it's broken.

[code4pay]

I made a commit http://padre.perlide.org/trac/changeset/10023, which makes the middle mouse button on X11 work in a way similar to some other editing apps nedit, kate, kdevelop, komodo edit etc. This is achieved by basically letting the Wxcontrol just handle it (we don't call paste at all). However some devs would prefer to keep the old behavior, (which would be my preference as well).

The problem with trying to implement the previous middle button paste functionality is that on X11 the middle mouse will perform an X11 paste not matter what other actions you take in the code (If you remove all copy and paste statements X11 will still do the select and middle button paste). Therefore if we do a paste and there is text in the X11 clipboard it will also perform a paste and you get 2 different texts pasted.

One thought I had was to empty the X11 clipboard before we perform a paste. Problem with this is it seems you can not replace the content of the X11 clipboard by sending it a null value. I tried "" and undef with no luck. There is also a clear function for the clipboard but this seems to only work on the primary clipboard.

The other thought was to copy the content of the primary clipboard to the X11 clipboard. Then when X11 does its paste it will paste only our copied content. This would prevent being able to copy on select from other apps and paste into Padre. And it would also mean that Padre would do an insert when pasting on highlighted text rather than an overwrite defeating the purpose.

I will commit another change that will let the user choose between the
10023 style or the previous style but the previous style will still remain broken, until some one can work out a way around the X11 pasting.

[Sewi]

It seems that you already tried some things. I'll share my thoughts here without trying them first:

• Save the clipboard content to a temporary variable
• Save the current selection start and length
• Set the current selection length to 0
• Copy the current selection to the clipboard
• Restore the current selection start and length
• Paste
• (Maybe delayed) restore the clipboard content

The 2nd paste event which occurs in Padre doesn't seem to be a X11 event as it doesn't happen in many other X11 apps. Restoring the pre-r10023 state and debugging which code is actually being run may help. The Devel::Trace module from CPAN might help with this but I never tried it myself.

[patspam]

Sewi++, code4pay++, submersible_toaster++, ..

Just wanted to say thanks to everyone who's working on squashing this tricky one.. it's far and above the most annoying bug that bites me when using Padre for daily dev. You guys rock!

[code4pay]

@Sewi, If you look at the example file /Padre/share/examples/wx/22_notebook.pl and use the editor you will note on X11 it provides copy and paste using the middle button. Therefore I think my assumption (that X11 will paste regardless) still stands.

[submersible_toaster]

As I have discovered with several other Wx events... ->Skip can be very important if your event handler is manipulating things that the default handler also manipulates. code4pay is correct in saying that for X11 platforms, NOT performing a padre Paste but allowing the event to propagate results in the generally expected (not always desirable) selection buffer paste that X11 people are familiar with.

The documentation for WxEvent? regarding Skip is somewhat confusing. What it boils down to in my opinion is ; If you want an event to stop propagating because you have handled it, Skip by all means - but be certain you have taken the default event handlers behaviour in mind. On the flip side , if you are being notified of the event but choosing NOT to Skip the propagation to other handlers, be certain you are not mutating things that subsequent handlers would also mutate.

Gives me a headache!

[Sewi]

Possible fix in r10036.

Thank you, submersible. I tried to change the ->Skip to (1) (on the pre-r10023 state) and was unable to reproduce the duplicate-paste error during ~50 tries.

The PerlMonks?  http://perlmonks.org/?node_id=814720 survey got two results (in my opinion):
1. There is no X11 default
2. The pre-10023 behavior is what most people like

Please re-check if the error still occurs on your system.

[waxhead]

How's it going with this? Will this be ready for a release in a few days time?

[adamk]

WORKSFORME on Win32