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
The text selection is pasted correctly. The text cursor is still behind the
text selection (although invisible).
The text cursor should be positioned behind the inserted text in order to
be able to continue typing.
5. Press [space].
The text selection "One " on the 1st line is erased and replaced with a blank.
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?
This would make gedit2 have the same middle mouse button behaviour as NEdit.
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
I assume you're suggesting that the selected text should remain
selected, but that the cursor focus should move to where the paste
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
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.
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
*** 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
(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]
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
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
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
Ugh, sorry. My testing seemed to indicate that it works. Maybe the
testing was too superficial...
Comment on attachment 24811 [details] [review]
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.