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.