I am *forever* getting text inserted at the wrong place because it's inserted at the mouse cursor rather than the text cursor. This happens particularly in web textareas but the problem is common to most/all GUI applications I think. (I just tried in OpenOffice and it's the same there).
Surely by default one would expect text to be inserted at the *text* cursor, not where you've moved the mouse cursor to which is often out of the way to avoid it obscuring what you're typing.
My editor (xvile) manages to do it right, it's a GUI application but text inserts where I'm typing.
Is there a setting somewhere to say "insert text at the text cursor"?
On 28-Feb-10 12:06:44, Chris G wrote:
I am *forever* getting text inserted at the wrong place because it's inserted at the mouse cursor rather than the text cursor. This happens particularly in web textareas but the problem is common to most/all GUI applications I think. (I just tried in OpenOffice and it's the same there).
Surely by default one would expect text to be inserted at the *text* cursor, not where you've moved the mouse cursor to which is often out of the way to avoid it obscuring what you're typing.
My editor (xvile) manages to do it right, it's a GUI application but text inserts where I'm typing.
Is there a setting somewhere to say "insert text at the text cursor"?
-- Chris Green
Question: Does "text insertion at mouse cursor" *always* happen, regardless of where the text cursor is? Or is it something that tends to "cut in" and does not happen 100% consistently?
If the latter, then it may well be due to spurious signals from the mouse/touchpad. For example, the touchpad on one of my laptops is hypersensitive. If I am using a text editor where the text cursor position can be moved by a mouse click (to where the mouse cursor happens to be), then suddenly I find my text going in where the mouse cursor is, as a result of the touchpad picking up the proximity of one of my hands and, in effect, sending a "touchpad tapped" signal (equivalent to left nmouse click). You could also get spurious signals from the mouse cable picking up EM interference (e.g. by passing close by a PSU).
On the other hand, if I am using a text editor which pays no attention to the mouse (e.g. vim) then I have no trouble.
However, in the text editor which is part of the email program I use, I get this problem from time to time. One solution is to deliberately move the mouse cursor out of the window, so that it cannot affect the text cursor.
Either way, what you can do about it depends on the program being used. In some, you may be able to turn off "mouse click moves text cursor", in others (probably most) not. In some (like vim) the mouse is irrelevant to text cursor positioning. I can't advise about this aspect of the matter.
Ted.
-------------------------------------------------------------------- E-Mail: (Ted Harding) Ted.Harding@manchester.ac.uk Fax-to-email: +44 (0)870 094 0861 Date: 28-Feb-10 Time: 13:21:22 ------------------------------ XFMail ------------------------------
On Sun, Feb 28, 2010 at 01:21:26PM -0000, Ted Harding wrote:
On 28-Feb-10 12:06:44, Chris G wrote:
I am *forever* getting text inserted at the wrong place because it's inserted at the mouse cursor rather than the text cursor. This happens particularly in web textareas but the problem is common to most/all GUI applications I think. (I just tried in OpenOffice and it's the same there).
Surely by default one would expect text to be inserted at the *text* cursor, not where you've moved the mouse cursor to which is often out of the way to avoid it obscuring what you're typing.
My editor (xvile) manages to do it right, it's a GUI application but text inserts where I'm typing.
Is there a setting somewhere to say "insert text at the text cursor"?
Question: Does "text insertion at mouse cursor" *always* happen, regardless of where the text cursor is? Or is it something that tends to "cut in" and does not happen 100% consistently?
It's always, or at least always in any particular application.
[snip]
On the other hand, if I am using a text editor which pays no attention to the mouse (e.g. vim) then I have no trouble.
[x]vile is similar to vim, i.e. it's a vi clone, just a different one that I grew up with so I stick with it. In its GUI incarnation (xvile) it *is* mouse aware, i.e. one can position the cursor with the mouse and editor (as opposed to terminal window) text selection can be done with the mouse. But *pasting* with the mouse (middle button, no chance of mis-recognised clicks) always goes to the text cursor.
I would have assumed that gvim is the same, if it isn't then that's one more reason to stay with xvile. :-)
However, in the text editor which is part of the email program I use, I get this problem from time to time. One solution is to deliberately move the mouse cursor out of the window, so that it cannot affect the text cursor.
Doesn't work too well for me as I use 'focus follows mouse'. :-) So if I paste when the mouse cursor isn't in the appropriate place for text to be inserted something else completely will happen, e.g. a menu pops up if it's on the desktop background.
Either way, what you can do about it depends on the program being used. In some, you may be able to turn off "mouse click moves text cursor", in others (probably most) not. In some (like vim) the mouse is irrelevant to text cursor positioning. I can't advise about this aspect of the matter.
I want (as in xvile) "[left] mouse click moves cursor" *and* "[middle] mouse click pastes text *at the text cursor*", I don't really see why that isn't the default set up.
At Sun, 28 Feb 2010 13:53:24 +0000, Chris G wrote:
On Sun, Feb 28, 2010 at 01:21:26PM -0000, Ted Harding wrote:
On 28-Feb-10 12:06:44, Chris G wrote:
I am *forever* getting text inserted at the wrong place because it's inserted at the mouse cursor rather than the text cursor. This happens particularly in web textareas but the problem is common to most/all GUI applications I think. (I just tried in OpenOffice and it's the same there).
Surely by default one would expect text to be inserted at the *text* cursor, not where you've moved the mouse cursor to which is often out of the way to avoid it obscuring what you're typing.
My editor (xvile) manages to do it right, it's a GUI application but text inserts where I'm typing.
Is there a setting somewhere to say "insert text at the text cursor"?
Question: Does "text insertion at mouse cursor" *always* happen, regardless of where the text cursor is? Or is it something that tends to "cut in" and does not happen 100% consistently?
It's always, or at least always in any particular application.
[snip]
On the other hand, if I am using a text editor which pays no attention to the mouse (e.g. vim) then I have no trouble.
[x]vile is similar to vim, i.e. it's a vi clone, just a different one that I grew up with so I stick with it. In its GUI incarnation (xvile) it *is* mouse aware, i.e. one can position the cursor with the mouse and editor (as opposed to terminal window) text selection can be done with the mouse. But *pasting* with the mouse (middle button, no chance of mis-recognised clicks) always goes to the text cursor.
I would have assumed that gvim is the same, if it isn't then that's one more reason to stay with xvile. :-)
However, in the text editor which is part of the email program I use, I get this problem from time to time. One solution is to deliberately move the mouse cursor out of the window, so that it cannot affect the text cursor.
Doesn't work too well for me as I use 'focus follows mouse'. :-) So if I paste when the mouse cursor isn't in the appropriate place for text to be inserted something else completely will happen, e.g. a menu pops up if it's on the desktop background.
Either way, what you can do about it depends on the program being used. In some, you may be able to turn off "mouse click moves text cursor", in others (probably most) not. In some (like vim) the mouse is irrelevant to text cursor positioning. I can't advise about this aspect of the matter.
I want (as in xvile) "[left] mouse click moves cursor" *and* "[middle] mouse click pastes text *at the text cursor*", I don't really see why that isn't the default set up.
So Chris, have you worked out whether you're suffering from the accidentally-brushing-the-touchpad problem?
The Acer Aspire One has a handy key for switching off the touchpad: Fn F7. This may be a good way to resolve your problem: switch off touchpad with handy keybinding while typing; switch on again while mousing.
If your laptop doesn't have something like this, I expect similar functionally could be implemented using synclient and your window manager/desktop environment's keybinding mechanism.
The synclient magic is:
synclient TapButton1=0 # or 1 to enable
(see $ man synclient for details).
Although you may not be able to capture Fn keys, you should be able to capture SUPER key combinations (the key which often has a Windows logo on it) which may be a good source of spare keybindings.
For metacity, GConf allows you to define keybindings. See /apps/metacity/global_keybings and ./keybinding_commands. SUPER+m, for example, would be:
<Mod4>m
in GConf language.
Metacity's keybinding mechanism doesn't provide a toggle mechanism (i.e. the same keybinding doing two different, but opposite actions, on/off, enable/disable). But you could probably solve that by wrapping a synclient call in a bash script which leaves a status dot file somewhere and then bind your chosen key to this script.
(Fluxbox actually provides a keybinding definition mechanism which *does* include toggling, very neat.)
Happy hacking.
On Sun, 28 Feb 2010 12:06:44 +0000 Chris G cl@isbd.net wrote:
I am *forever* getting text inserted at the wrong place because it's inserted at the mouse cursor rather than the text cursor. This happens particularly in web textareas but the problem is common to most/all GUI applications I think. (I just tried in OpenOffice and it's the same there).
Surely by default one would expect text to be inserted at the *text* cursor, not where you've moved the mouse cursor to which is often out of the way to avoid it obscuring what you're typing.
My editor (xvile) manages to do it right, it's a GUI application but text inserts where I'm typing.
Is there a setting somewhere to say "insert text at the text cursor"?
Chris,
Which GUI environment are you having the problem with, i.e. GNOME, KDE Xfce etc?
My experience using GNOME is that for most applications that have some kind of text entry widget, clicking in that text entry not only focuses that widget but sets the text insertion point to where the mouse click happens.
For many applications, for example editors, the major part of the main window is a form of text entry so here I would typically find that if I click in the application's main window to raise that window to the top it has the side effect of changing the text insertion point. The solution I have always used for this to to click on the title bar to raise an application instead.
HTH, Steve.
On Mon, Mar 01, 2010 at 12:08:43PM +0000, Richard Lewis wrote:
At Sun, 28 Feb 2010 13:53:24 +0000, Chris G wrote:
On Sun, Feb 28, 2010 at 01:21:26PM -0000, Ted Harding wrote:
On 28-Feb-10 12:06:44, Chris G wrote:
I am *forever* getting text inserted at the wrong place because it's inserted at the mouse cursor rather than the text cursor. This happens particularly in web textareas but the problem is common to most/all GUI applications I think. (I just tried in OpenOffice and it's the same there).
Surely by default one would expect text to be inserted at the *text* cursor, not where you've moved the mouse cursor to which is often out of the way to avoid it obscuring what you're typing.
My editor (xvile) manages to do it right, it's a GUI application but text inserts where I'm typing.
Is there a setting somewhere to say "insert text at the text cursor"?
Question: Does "text insertion at mouse cursor" *always* happen, regardless of where the text cursor is? Or is it something that tends to "cut in" and does not happen 100% consistently?
It's always, or at least always in any particular application.
[snip]
On the other hand, if I am using a text editor which pays no attention to the mouse (e.g. vim) then I have no trouble.
[x]vile is similar to vim, i.e. it's a vi clone, just a different one that I grew up with so I stick with it. In its GUI incarnation (xvile) it *is* mouse aware, i.e. one can position the cursor with the mouse and editor (as opposed to terminal window) text selection can be done with the mouse. But *pasting* with the mouse (middle button, no chance of mis-recognised clicks) always goes to the text cursor.
I would have assumed that gvim is the same, if it isn't then that's one more reason to stay with xvile. :-)
However, in the text editor which is part of the email program I use, I get this problem from time to time. One solution is to deliberately move the mouse cursor out of the window, so that it cannot affect the text cursor.
Doesn't work too well for me as I use 'focus follows mouse'. :-) So if I paste when the mouse cursor isn't in the appropriate place for text to be inserted something else completely will happen, e.g. a menu pops up if it's on the desktop background.
Either way, what you can do about it depends on the program being used. In some, you may be able to turn off "mouse click moves text cursor", in others (probably most) not. In some (like vim) the mouse is irrelevant to text cursor positioning. I can't advise about this aspect of the matter.
I want (as in xvile) "[left] mouse click moves cursor" *and* "[middle] mouse click pastes text *at the text cursor*", I don't really see why that isn't the default set up.
So Chris, have you worked out whether you're suffering from the accidentally-brushing-the-touchpad problem?
It's definitely *not* that, I'm using a 4 button trackball with a dedicated 'middle' button which is the paste button.
[snip ways of preventing accidental button pushes]
My problem is that applications are *designed* to paste text at the *mouse cursor* position and I want to paste text at the *text cursor* position. I don't think you have quite understood what my original rant was about.
On 1 March 2010 13:34, Chris G cl@isbd.net wrote:
My problem is that applications are *designed* to paste text at the *mouse cursor* position and I want to paste text at the *text cursor* position. I don't think you have quite understood what my original rant was about.
I noticed middle click pasting moved the text cursor before dropping the text in years ago, so I use the keyboard instead.
Tim.
On Mon, Mar 01, 2010 at 01:16:42PM +0000, Steve Fosdick wrote:
On Sun, 28 Feb 2010 12:06:44 +0000 Chris G cl@isbd.net wrote:
I am *forever* getting text inserted at the wrong place because it's inserted at the mouse cursor rather than the text cursor. This happens particularly in web textareas but the problem is common to most/all GUI applications I think. (I just tried in OpenOffice and it's the same there).
Surely by default one would expect text to be inserted at the *text* cursor, not where you've moved the mouse cursor to which is often out of the way to avoid it obscuring what you're typing.
My editor (xvile) manages to do it right, it's a GUI application but text inserts where I'm typing.
Is there a setting somewhere to say "insert text at the text cursor"?
Chris,
Which GUI environment are you having the problem with, i.e. GNOME, KDE Xfce etc?
My experience using GNOME is that for most applications that have some kind of text entry widget, clicking in that text entry not only focuses that widget but sets the text insertion point to where the mouse click happens.
That's a *left* button click. To paste text you use the middle button and that *doesn't* move the cursor.
For many applications, for example editors, the major part of the main window is a form of text entry so here I would typically find that if I click in the application's main window to raise that window to the top it has the side effect of changing the text insertion point. The solution I have always used for this to to click on the title bar to raise an application instead.
This isn't the issue.
Let me try and describe it again. I'm talking about the 'classic' Unix copy/paste with the mouse where you copy text by dragging with the left button (button 1) pressed or, maybe, by multi-clicking the left button. You then paste that text by pressing the 'middle' button, that's button 3.
If you do this in a text window (Gnome Terminal, or an xterm) the text is always pasted at the text cursor position (usually the prompt) regardless of where you have left the mouse cursor. Thus you can go back to a previous command or the result of an ls, copy something and then paste it at the prompt without having to carefully reposition the *mouse* cursor back at the prompt. It also works this way in my (GUI) editor, xvile.
I.e. button 1 (left) selects text and/or moves the *mouse cursor*, button 3 (middle) pastes text (at the *text* cursor) but doesn't move the mouse cursor.
I want the same thing to happen in textareas and other GUIs, that's all. Unless I'm missing some configuration option I don't know about just about all applications I've tried (textareas in Firefox, Open Office, etc.) pastes the text at the *mouse* cursor position when I click button 3 even though text I enter from the keyboard is placed at the text cursor position.
Maybe no one uses a three (or more) button mouse nowadays so button 3 is emulated by pressing 1 and 2 simultaneously and thus there is a risk of it being seen as a button 1 press and moving the cursor.
I have always been careful to buy a mouse (or trackball) with a proper 3rd button so that there is no risk that the paste action will be ambiguous.
I'm not really expecting a solution to this problem, I was just having a bit of a rant at what seems like poor UI design common to almost every GUI app (apart from terminal windows and, maybe, a few editors). Unless, of course, there is some generic user interface option that I don't know about.
On Mon, Mar 01, 2010 at 01:34:45PM +0000, Chris G wrote:
My problem is that applications are *designed* to paste text at the *mouse cursor* position and I want to paste text at the *text cursor* position. I don't think you have quite understood what my original rant was about.
You could have made your question much more clear by mentioning that you meant you had this problem when using cut & paste. I was utterly confused by what the hell you were on about and it seems that I wasn't the only one.
Adam
Hi all,
On 01/03/2010, Chris G cl@isbd.net wrote:
My problem is that applications are *designed* to paste text at the *mouse cursor* position and I want to paste text at the *text cursor* position. I don't think you have quite understood what my original rant was about.
I'm pretty sure I've also encountered this, so it's not Chris going insane.
It's pretty much as if the standard action is (pseudo-C++):
void onPasteButtonAction() { Position p = MouseCursor.position(); textArea->insertText(pasteBuffer, AtLocation(p)); }
Srdj
At Mon, 1 Mar 2010 13:34:45 +0000, Chris G wrote:
On Mon, Mar 01, 2010 at 12:08:43PM +0000, Richard Lewis wrote:
At Sun, 28 Feb 2010 13:53:24 +0000, Chris G wrote:
On Sun, Feb 28, 2010 at 01:21:26PM -0000, Ted Harding wrote:
On 28-Feb-10 12:06:44, Chris G wrote:
I am *forever* getting text inserted at the wrong place because it's inserted at the mouse cursor rather than the text cursor. This happens particularly in web textareas but the problem is common to most/all GUI applications I think. (I just tried in OpenOffice and it's the same there).
Surely by default one would expect text to be inserted at the *text* cursor, not where you've moved the mouse cursor to which is often out of the way to avoid it obscuring what you're typing.
My editor (xvile) manages to do it right, it's a GUI application but text inserts where I'm typing.
Is there a setting somewhere to say "insert text at the text cursor"?
Question: Does "text insertion at mouse cursor" *always* happen, regardless of where the text cursor is? Or is it something that tends to "cut in" and does not happen 100% consistently?
It's always, or at least always in any particular application.
[snip]
On the other hand, if I am using a text editor which pays no attention to the mouse (e.g. vim) then I have no trouble.
[x]vile is similar to vim, i.e. it's a vi clone, just a different one that I grew up with so I stick with it. In its GUI incarnation (xvile) it *is* mouse aware, i.e. one can position the cursor with the mouse and editor (as opposed to terminal window) text selection can be done with the mouse. But *pasting* with the mouse (middle button, no chance of mis-recognised clicks) always goes to the text cursor.
I would have assumed that gvim is the same, if it isn't then that's one more reason to stay with xvile. :-)
However, in the text editor which is part of the email program I use, I get this problem from time to time. One solution is to deliberately move the mouse cursor out of the window, so that it cannot affect the text cursor.
Doesn't work too well for me as I use 'focus follows mouse'. :-) So if I paste when the mouse cursor isn't in the appropriate place for text to be inserted something else completely will happen, e.g. a menu pops up if it's on the desktop background.
Either way, what you can do about it depends on the program being used. In some, you may be able to turn off "mouse click moves text cursor", in others (probably most) not. In some (like vim) the mouse is irrelevant to text cursor positioning. I can't advise about this aspect of the matter.
I want (as in xvile) "[left] mouse click moves cursor" *and* "[middle] mouse click pastes text *at the text cursor*", I don't really see why that isn't the default set up.
So Chris, have you worked out whether you're suffering from the accidentally-brushing-the-touchpad problem?
It's definitely *not* that, I'm using a 4 button trackball with a dedicated 'middle' button which is the paste button.
[snip ways of preventing accidental button pushes]
My problem is that applications are *designed* to paste text at the *mouse cursor* position and I want to paste text at the *text cursor* position. I don't think you have quite understood what my original rant was about.
Ah, I see. Yes, I misunderstood. I think there were two cognitive blockages, one very dull and the other quite interesting.
The dull one was that the brushing-the-touchpad problem immediately came to mind as I read your initial post, so I read the rest of the thread with that firmly at the front of my thinking.
The more interesting one was that I couldn't conceive of the idea of deliberately clicking in a text frame and *not* expecting the text cursor to be re-positioned to the click site. This is almost quite distressing. I used to use Emacs in an xterm as a matter of habbit which, of course, paid no attention to mouse clicks. I now use GTK Emacs which does move the cursor when clicked on, *but* I rarely ever click on my Emacs (I just Alt+TAB to it). As a result, it seems I now assume that the point of clicking in a text frame is to move the cursor, and I couldn't see beyond this narrow-minded conception. :-(
At Mon, 1 Mar 2010 13:49:21 +0000, Tim Green wrote:
On 1 March 2010 13:34, Chris G cl@isbd.net wrote:
My problem is that applications are *designed* to paste text at the *mouse cursor* position and I want to paste text at the *text cursor* position. I don't think you have quite understood what my original rant was about.
I noticed middle click pasting moved the text cursor before dropping the text in years ago, so I use the keyboard instead.
That's another good point. I don't really use the mouse for anything.
On Mon, Mar 01, 2010 at 01:49:21PM +0000, Tim Green wrote:
On 1 March 2010 13:34, Chris G cl@isbd.net wrote:
My problem is that applications are *designed* to paste text at the *mouse cursor* position and I want to paste text at the *text cursor* position. I don't think you have quite understood what my original rant was about.
I noticed middle click pasting moved the text cursor before dropping the text in years ago, so I use the keyboard instead.
Can you paste mouse selected text with the keyboard without having to CTRL/C to copy the text?
I have 'select with button 1, paste with button 3' ingrained in my mind. Having to do 'select with button 1, move hand back to keyboard, hit CTRL/C to copy text, move hand back to mouse to select insertion point, move hand back to keyboard, hit CTRL/V to paste' very long-winded in comparison.
... and middle click doesn't have to move the cursor, it's just a (crap) design decision by someone, somewhere. It doesn't happen in xvile for example.
I think MS Windows defaults have spoilt things.
At Mon, 1 Mar 2010 13:53:19 +0000, Chris G wrote:
On Mon, Mar 01, 2010 at 01:16:42PM +0000, Steve Fosdick wrote:
On Sun, 28 Feb 2010 12:06:44 +0000 Chris G cl@isbd.net wrote:
I am *forever* getting text inserted at the wrong place because it's inserted at the mouse cursor rather than the text cursor. This happens particularly in web textareas but the problem is common to most/all GUI applications I think. (I just tried in OpenOffice and it's the same there).
Surely by default one would expect text to be inserted at the *text* cursor, not where you've moved the mouse cursor to which is often out of the way to avoid it obscuring what you're typing.
My editor (xvile) manages to do it right, it's a GUI application but text inserts where I'm typing.
Is there a setting somewhere to say "insert text at the text cursor"?
Chris,
Which GUI environment are you having the problem with, i.e. GNOME, KDE Xfce etc?
My experience using GNOME is that for most applications that have some kind of text entry widget, clicking in that text entry not only focuses that widget but sets the text insertion point to where the mouse click happens.
That's a *left* button click. To paste text you use the middle button and that *doesn't* move the cursor.
For many applications, for example editors, the major part of the main window is a form of text entry so here I would typically find that if I click in the application's main window to raise that window to the top it has the side effect of changing the text insertion point. The solution I have always used for this to to click on the title bar to raise an application instead.
This isn't the issue.
Let me try and describe it again. I'm talking about the 'classic' Unix copy/paste with the mouse where you copy text by dragging with the left button (button 1) pressed or, maybe, by multi-clicking the left button. You then paste that text by pressing the 'middle' button, that's button 3.
If you do this in a text window (Gnome Terminal, or an xterm) the text is always pasted at the text cursor position (usually the prompt) regardless of where you have left the mouse cursor. Thus you can go back to a previous command or the result of an ls, copy something and then paste it at the prompt without having to carefully reposition the *mouse* cursor back at the prompt. It also works this way in my (GUI) editor, xvile.
I think a key difference here is that you're (rather, one is) not X pasting the text into an xterm. When you 'paste' into an xterm, the text actually gets typed into that xterm. (You can sometimes see this if you paste a large wodge of text, it takes a visible amount of time and inserts the text sequentially.)
As you say, this is simply not the way that other GUI text frames behave.
On Mon, Mar 01, 2010 at 02:02:32PM +0000, Richard Lewis wrote:
At Mon, 1 Mar 2010 13:49:21 +0000, Tim Green wrote:
On 1 March 2010 13:34, Chris G cl@isbd.net wrote:
My problem is that applications are *designed* to paste text at the *mouse cursor* position and I want to paste text at the *text cursor* position. I don't think you have quite understood what my original rant was about.
I noticed middle click pasting moved the text cursor before dropping the text in years ago, so I use the keyboard instead.
That's another good point. I don't really use the mouse for anything.
How do you select text to copy then? I guess you can do it with the keyboard but if it's at the other end of a large editing window it gets a bit clumsy. The ability to be able to select bits of text at one place (with the mouse/mouse cursor) and paste them somewhere else (at the text cursor) is really, really useful at times. You can, for example select a collection of words one by one from a line and paste them back somewhere else in a different order without to much hand/mouse movement.
A typical case (which does work as it's in a terminal window) is that I'll do an 'ls' to list some files and then want to perform some action on a selection of them. So, it's :-
chris$ ls chris$ ls CHA17 MR GREEN 2.jpg email contact details.doc python CHA17 MR GREEN 3.jpg fred results-survey86534.csv CHA17 MR GREEN.jpg gradwell results-survey86534.doc Chris Test Project.pod isbd results-survey86534.gnumeric Christmas.mdb jrml results-survey86534.uos Desktop limesurvey.sql rhinotes.txt Mail mmboat src Marmalade Jan 2010.glabels moin temp News new.html tmp bin office10.iso view.html correspondence pictures vvexport_86534.csv details.txt postponed www diagrams pyboat xxx.rtf chris$ rm new.html view.html vvexport_86534.csv xxx.rtf chris$
Copying and pasting those filenames is dead easy, move mouse cursor over the filename, double-click to select the name, hit middle button and it's pasted at the prompt (text cursor), hit space bar (with the other hand), select next file ..... No major mouse movement, no major hand movement as one hand stays on the mouse the other hand hits the space bar.
If, as happens in textareas and GUI apps, the text cursor moves you can't easily use the mouse to select things and put them all in one place without lots of mouse movement.
On 01 Mar 13:53, Chris G wrote:
I'm not really expecting a solution to this problem, I was just having a bit of a rant at what seems like poor UI design common to almost every GUI app (apart from terminal windows and, maybe, a few editors). Unless, of course, there is some generic user interface option that I don't know about.
Well, that's good, because it's down to the developers how to interpret mouse actions, and they all disagree with each other...
Now, what you might be interested in instead is that there's a keyboard shortcut for pasting the X11 clipboard, Shift-Ins, that should do what you expect.
Thanks,
On 01 Mar 14:14, Chris G wrote:
On Mon, Mar 01, 2010 at 02:02:32PM +0000, Richard Lewis wrote:
At Mon, 1 Mar 2010 13:49:21 +0000, Tim Green wrote:
On 1 March 2010 13:34, Chris G cl@isbd.net wrote:
My problem is that applications are *designed* to paste text at the *mouse cursor* position and I want to paste text at the *text cursor* position. I don't think you have quite understood what my original rant was about.
I noticed middle click pasting moved the text cursor before dropping the text in years ago, so I use the keyboard instead.
That's another good point. I don't really use the mouse for anything.
How do you select text to copy then? I guess you can do it with the keyboard but if it's at the other end of a large editing window it gets a bit clumsy. The ability to be able to select bits of text at one place (with the mouse/mouse cursor) and paste them somewhere else (at the text cursor) is really, really useful at times. You can, for example select a collection of words one by one from a line and paste them back somewhere else in a different order without to much hand/mouse movement.
A typical case (which does work as it's in a terminal window) is that I'll do an 'ls' to list some files and then want to perform some action on a selection of them. So, it's :-
chris$ ls chris$ ls CHA17 MR GREEN 2.jpg email contact details.doc python CHA17 MR GREEN 3.jpg fred results-survey86534.csv CHA17 MR GREEN.jpg gradwell results-survey86534.doc Chris Test Project.pod isbd results-survey86534.gnumeric Christmas.mdb jrml results-survey86534.uos Desktop limesurvey.sql rhinotes.txt Mail mmboat src Marmalade Jan 2010.glabels moin temp News new.html tmp bin office10.iso view.html correspondence pictures vvexport_86534.csv details.txt postponed www diagrams pyboat xxx.rtf chris$ rm new.html view.html vvexport_86534.csv xxx.rtf chris$Copying and pasting those filenames is dead easy, move mouse cursor over the filename, double-click to select the name, hit middle button and it's pasted at the prompt (text cursor), hit space bar (with the other hand), select next file ..... No major mouse movement, no major hand movement as one hand stays on the mouse the other hand hits the space bar.
If, as happens in textareas and GUI apps, the text cursor moves you can't easily use the mouse to select things and put them all in one place without lots of mouse movement.
Right - 2 things here...
1) Copy pasting filenames is never a good idea, and if you're really going to do that at least use ls -1 so that you only get 1 long list of filenames. Otherwise, use find and xargs for multiple files, with the -print0 option to find and the -0 option to xargs.
2) Copy paste is not just an X11 thing, there's a seperate setup for using copy paste in screen, which works really really quite nicely. (Also, vim, for copying between files has the y operator, etc).
On Mon, Mar 01, 2010 at 02:00:54PM +0000, Richard Lewis wrote:
It's definitely *not* that, I'm using a 4 button trackball with a dedicated 'middle' button which is the paste button.
[snip ways of preventing accidental button pushes]
My problem is that applications are *designed* to paste text at the *mouse cursor* position and I want to paste text at the *text cursor* position. I don't think you have quite understood what my original rant was about.
Ah, I see. Yes, I misunderstood. I think there were two cognitive blockages, one very dull and the other quite interesting.
The dull one was that the brushing-the-touchpad problem immediately came to mind as I read your initial post, so I read the rest of the thread with that firmly at the front of my thinking.
The more interesting one was that I couldn't conceive of the idea of deliberately clicking in a text frame and *not* expecting the text cursor to be re-positioned to the click site. This is almost quite distressing. I used to use Emacs in an xterm as a matter of habbit which, of course, paid no attention to mouse clicks. I now use GTK Emacs which does move the cursor when clicked on, *but* I rarely ever click on my Emacs (I just Alt+TAB to it). As a result, it seems I now assume that the point of clicking in a text frame is to move the cursor, and I couldn't see beyond this narrow-minded conception. :-(
Your missing what a proper mouse-aware GUI editor can do then! :-)
The one I use is actually an EMACS engine underneath, its ancestor is an incarnation of microEmacs. Xvile is mouse aware in that left button clicks move the cursor and select text but middle button clicks still paste at the text cursor insertion point.
By the way an application that runs in an xterm *can* be mouse aware, though I only know of one that is, the tin newsreader. It's a normal text mode application that runs in an xterm (or gnome-terminal, or whatever) but you can select newsgroups or articles by clicking on them with the mouse. This can cause some slight oddities if you try and select text with the mouse but there are ways to turn the mouse awareness off temporarily when you want to select text.
On Mon, Mar 01, 2010 at 02:21:56PM +0000, Brett Parker wrote:
On 01 Mar 14:14, Chris G wrote:
Copying and pasting those filenames is dead easy, move mouse cursor over the filename, double-click to select the name, hit middle button and it's pasted at the prompt (text cursor), hit space bar (with the other hand), select next file ..... No major mouse movement, no major hand movement as one hand stays on the mouse the other hand hits the space bar.
If, as happens in textareas and GUI apps, the text cursor moves you can't easily use the mouse to select things and put them all in one place without lots of mouse movement.
Right - 2 things here...
- Copy pasting filenames is never a good idea, and if you're really
going to do that at least use ls -1 so that you only get 1 long list of filenames. Otherwise, use find and xargs for multiple files, with the -print0 option to find and the -0 option to xargs.
I wasn't really advocating what I did as a good/proper way of doing something, I was just trying to show how useful it can be to have a text insertion point which isn't moved around by the paste button.
- Copy paste is not just an X11 thing, there's a seperate setup for
using copy paste in screen, which works really really quite nicely. (Also, vim, for copying between files has the y operator, etc).
Yes, many editors and things will have shortcuts for selecting text, doesn't really help with my original rant though does it! :-)
On Mon, Mar 01, 2010 at 01:53:43PM +0000, Adam Bower wrote:
On Mon, Mar 01, 2010 at 01:34:45PM +0000, Chris G wrote:
My problem is that applications are *designed* to paste text at the *mouse cursor* position and I want to paste text at the *text cursor* position. I don't think you have quite understood what my original rant was about.
You could have made your question much more clear by mentioning that you meant you had this problem when using cut & paste. I was utterly confused by what the hell you were on about and it seems that I wasn't the only one.
It doesn't feel as if my later explanations were much different from my first one, but obviously there was something lacking in my first post, sorry.
On Mon, Mar 01, 2010 at 02:22:54PM +0000, Chris G wrote:
On Mon, Mar 01, 2010 at 02:00:54PM +0000, Richard Lewis wrote:
It's definitely *not* that, I'm using a 4 button trackball with a dedicated 'middle' button which is the paste button.
[snip ways of preventing accidental button pushes]
My problem is that applications are *designed* to paste text at the *mouse cursor* position and I want to paste text at the *text cursor* position. I don't think you have quite understood what my original rant was about.
Ah, I see. Yes, I misunderstood. I think there were two cognitive blockages, one very dull and the other quite interesting.
The dull one was that the brushing-the-touchpad problem immediately came to mind as I read your initial post, so I read the rest of the thread with that firmly at the front of my thinking.
The more interesting one was that I couldn't conceive of the idea of deliberately clicking in a text frame and *not* expecting the text cursor to be re-positioned to the click site. This is almost quite distressing. I used to use Emacs in an xterm as a matter of habbit which, of course, paid no attention to mouse clicks. I now use GTK Emacs which does move the cursor when clicked on, *but* I rarely ever click on my Emacs (I just Alt+TAB to it). As a result, it seems I now assume that the point of clicking in a text frame is to move the cursor, and I couldn't see beyond this narrow-minded conception. :-(
Your missing what a proper mouse-aware GUI editor can do then! :-)
Oops, horrible me, "you're".
The one I use is actually an EMACS engine underneath, its ancestor is an incarnation of microEmacs. Xvile is mouse aware in that left button clicks move the cursor and select text but middle button clicks still paste at the text cursor insertion point.
By the way an application that runs in an xterm *can* be mouse aware, though I only know of one that is, the tin newsreader. It's a normal text mode application that runs in an xterm (or gnome-terminal, or whatever) but you can select newsgroups or articles by clicking on them with the mouse. This can cause some slight oddities if you try and select text with the mouse but there are ways to turn the mouse awareness off temporarily when you want to select text.
-- Chris Green
main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
On Mon, Mar 01, 2010 at 02:16:22PM +0000, Brett Parker wrote:
On 01 Mar 13:53, Chris G wrote:
I'm not really expecting a solution to this problem, I was just having a bit of a rant at what seems like poor UI design common to almost every GUI app (apart from terminal windows and, maybe, a few editors). Unless, of course, there is some generic user interface option that I don't know about.
Well, that's good, because it's down to the developers how to interpret mouse actions, and they all disagree with each other...
Now, what you might be interested in instead is that there's a keyboard shortcut for pasting the X11 clipboard, Shift-Ins, that should do what you expect.
Shift-Ins doesn't seem to do anything for me in a textarea I just tried.
Ah, it works in this terminal window though, since terminals work the way I like anyway it doesn't win me much!
On Mon, 1 Mar 2010 14:34:26 +0000 Chris G cl@isbd.net wrote:
On Mon, Mar 01, 2010 at 02:16:22PM +0000, Brett Parker wrote:
On 01 Mar 13:53, Chris G wrote:
I'm not really expecting a solution to this problem, I was just having a bit of a rant at what seems like poor UI design common to almost every GUI app (apart from terminal windows and, maybe, a few editors). Unless, of course, there is some generic user interface option that I don't know about.
Well, that's good, because it's down to the developers how to interpret mouse actions, and they all disagree with each other...
Now, what you might be interested in instead is that there's a keyboard shortcut for pasting the X11 clipboard, Shift-Ins, that should do what you expect.
Shift-Ins doesn't seem to do anything for me in a textarea I just tried.
Ah, it works in this terminal window though, since terminals work the way I like anyway it doesn't win me much!
There are actually two mechanisms in X which can be used to copy/paste text from one place to another.
The old-style X method is to use selections. Dragging the mouse over some text selects it and when you release the mouse button leaves it as the primary selection. Centre-click then pastes the primary selection into the destination application, usually at the mouse cursor as you have noted.
The other method is to use the clipboard and in many applications there are keyboard shortcuts bound to the cut/copy/paste operations, often Ctrl-X (cut) Ctrl-C (copy), Ctrl-V (paste) so it would often be possible to use these without needing to click in the destination application which in turn should mean the paste happens at the text insertion point.
HTH, Steve.
On Mon, Mar 01, 2010 at 04:46:26PM +0000, Steve Fosdick wrote:
On Mon, 1 Mar 2010 14:34:26 +0000 Chris G cl@isbd.net wrote:
On Mon, Mar 01, 2010 at 02:16:22PM +0000, Brett Parker wrote:
On 01 Mar 13:53, Chris G wrote:
I'm not really expecting a solution to this problem, I was just having a bit of a rant at what seems like poor UI design common to almost every GUI app (apart from terminal windows and, maybe, a few editors). Unless, of course, there is some generic user interface option that I don't know about.
Well, that's good, because it's down to the developers how to interpret mouse actions, and they all disagree with each other...
Now, what you might be interested in instead is that there's a keyboard shortcut for pasting the X11 clipboard, Shift-Ins, that should do what you expect.
Shift-Ins doesn't seem to do anything for me in a textarea I just tried.
Ah, it works in this terminal window though, since terminals work the way I like anyway it doesn't win me much!
There are actually two mechanisms in X which can be used to copy/paste text from one place to another.
The old-style X method is to use selections. Dragging the mouse over some text selects it and when you release the mouse button leaves it as the primary selection. Centre-click then pastes the primary selection into the destination application, usually at the mouse cursor as you have noted.
The other method is to use the clipboard and in many applications there are keyboard shortcuts bound to the cut/copy/paste operations, often Ctrl-X (cut) Ctrl-C (copy), Ctrl-V (paste) so it would often be possible to use these without needing to click in the destination application which in turn should mean the paste happens at the text insertion point.
Yes, the Ctrl-C/Ctrl-V cut/paste does paste at the text cursor but, as I said in one of my postings above it is much more messy to cut/paste this way in many (most?) situations. The 'old-style' (what's old about it?) method uses only the mouse and for that reason is better IMHO as you don't have to move from mouse to keyboard and back so much.
-
Adam Bower -
Brett Parker -
Chris G -
Richard Lewis -
samwise -
Srdjan Todorovic -
Steve Fosdick -
Ted.Harding＠manchester.ac.uk -
Tim Green