GNOME Bugzilla – Bug 81880
Pasting a text selection by clicking the middle mouse button doesn't position the text cursor behind the inserted text.
Last modified: 2018-05-02 13:40:32 UTC
Description of Problem: Pasting a text selection by clicking the middle mouse button should position the text cursor right behind the inserted text in order to be able to continue typing. Steps to reproduce the problem: 1. Start gedit2. 2. Type in the following text (do no type the line numbers): 1 One Two Three 2 Four Five Six 3. Select "One ". 1 [One ]Two Three 2 Four Five Six 4. Click the middle mouse button in front of the word "Five". 1 [One ]Two Three 2 Four One Five Six Actual Results: The text selection is pasted correctly. The text cursor is still behind the text selection (although invisible). Expected Results: The text cursor should be positioned behind the inserted text in order to be able to continue typing. 5. Press [space]. Actual Results: The text selection "One " on the 1st line is erased and replaced with a blank. Expected Results: The text selection "One " on the 1st line should be cancelled and a blank should be inserted behind the inserted "One " on the 2nd line. How often does this happen? Always. Additional Information: This would make gedit2 have the same middle mouse button behaviour as NEdit. Version Details: gtk2-2.0.2.0.200205130458-0.snap.ximian.1 gedit2-1.118.0.0.200205130458-0.snap.ximian.1
Basically a UI decision. I don't know the answer offhand.
The current behaviour certainly seems broken, especially the text cursor disappearing altogether at one point. I haven't really played with this, but my first reaction would be that selecting text and pasting it somewhere with the middle mouse button should leave you in exactly the same state as selecting the text, hitting Ctrl+C, moving the cursor to the insertion point and hitting Ctrl+V.
I assume you're suggesting that the selected text should remain selected, but that the cursor focus should move to where the paste occurred. If this is the case, the I agree. This would allow you to continue pasting using the middle mouse button, but also save the hassel of having to click again to continue working at the point of paste. Looking at my own work patterns (and I'm sure I'm not unique in this) you typically paste text to where you are currently working and not from where you are currently working to another area. Thus, it would make good UI sense to have the cursor follow the paste. Also, with the current behavior, if the selection comes from another window, then you have to focus the window to continue working in it. For example, if you select a command from a web page, and then middle click paste it the terminal you then have to focus the window to run the command. Having the cursor focus follow paste would alleviate this issue.
Rodd, your comments reflect exactly what was meant. The cursor focus should go to where the text paste occured. Your multiple-window example shows that the current implementation behaves inconsistently. Additional Information: The text widgets in Mozilla have the same middle mouse button behaviour as NEdit. They allow the user to continue typing where the text paste occured.
I have some additional information. As a result of this problem, pasting a text selection at the end of a document by clicking the middle mouse button *will not* display the end of the document. On the other hand, pasting a text selection at the end of a document with either [Ctrl]+[V] or [Shift]+[Insert] *will* display the end of the document.
*** Bug 90608 has been marked as a duplicate of this bug. ***
I'd urge everyone to go and read bug 90608 as it's not so much a duplicate of this bug, but an extension (IMHO). bug 90608 discusses that fact that middle clicking at the end of a selection seems to replace the current selection, instead of pasting the selection at the end of the current selection.
*** Bug 127705 has been marked as a duplicate of this bug. ***
The following patch seems to fix it: in gtktextbuffer during pre_paste_prep we move the "insert" mark at the insertion point in gtktextview after having pasted the text we retrieve the "insert" mark and move the cursor to it making sure of also scroll the window if needed. (note that we cannot simply move the cursor to the iter retrieved at the button click because the clipboard would be emptied)
Created attachment 24811 [details] [review] proposed patch
I presume this is to fix both gtk+-2.2.5 and gtk+-HEAD?
the patch is against HEAD, dunno about 2.2... I presume that it should apply there too.
This patch really makes no sense to me - the two changes are: A) Before inserting the text, we move the "insert" mark (just one end of the selection) to the new insertion point. B) After we request the text, we move both ends of the selection to the the "insert" mark. Note that these two steps can occur in either order, depending on whether the paste is from the same process or from a different process. I don't see how this is going to work in the case where B) happens first. And with a little testing, in fact, the results in the remote case are in fact incorrect. I'm going to revert the patch, and reopen and move to the 2.4.1 milestone.
Ugh, sorry. My testing seemed to indicate that it works. Maybe the testing was too superficial...
Comment on attachment 24811 [details] [review] proposed patch Needs-work based on owen's comment.
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as Matthias said he was trying to do himself on IRC and was asking for help with. If you see this message, it means I was successful at fixing the borken-ness in bugzilla :) Sorry for the spam; just query on this message and delete all emails you get with this message, since there will probably be a lot.
Has this bug been forgotten? The current behavior is a bit annoying specially when pasting into a different "screen page" as the view scrolls back to the cursor.
Created attachment 147736 [details] [review] Place the cursor after the paste has been done This patch places the cursor at the location where the past has been done as soon as the paste event is finished. This seems to be the best place where to change the position as the paste event is asynchronous.
Question. Does still allow for multiple pastes of the highlighted text?
> Question. Does still allow for multiple pastes of the highlighted text? This patch allows exactly what the existing implementation of GtkTextView does. As long as the highlighted text comes from another application there will be no problem. Currently GtkTextView doesn't allow highlighted text from the same buffer to be copy pasted more than once because the paste operation unselects the highlighted text and the text is not stored in the clipboard. I believe that this is a separate bug.
*** Bug 631195 has been marked as a duplicate of this bug. ***
*** Bug 334467 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/220.