GNOME Bugzilla – Bug 73307
Non-split (jumping) cursor problems
Last modified: 2015-08-05 22:25:08 UTC
1) Virtual cursor positioning acts with respect to the strong cursor not the visible cursor. 2) Clicking at a position positions the strong cursor there, not the visible cursor. (This also affects GtkEntry, GtkLabel.) Fixing this probably requires GtkTextLayout API extensions and possibly also Pango API extensions to do the "x => weak cursor at x" mapping, since we don't export information from the weak log2vis table though we have code in PangoLayout to compute it.
Created attachment 6949 [details] [review] Patch partially dealing with virtual cursor problems
Making all 'high' textview bugs 2.2.0 as per havoc's request.
Adding PATCH keyword.
See discussion in bug 101380 of why an important component of this is probably switching the cursor direction on click within text.
CC myself.
I'm willing to fix this as soon as I figure out what this is all about :-).
Just turn on jumping cursor mode, try it some, and I think what I'm saying above will make more sense. When you click-to-select, navigate with the arrow keys, etc, the natural assumption is that you are moving the visible cursor, but that is frequently violated now.
The problem is, being a native bidi user, I still don't quite understand the strong and weak cursors (ok, I think I now, but they really should follow my keymap direction to make sense.) And don't know what visual cursor is for sure. How do I turn jumping cursor mode on?
History: After I implemented the current default split cursor support, I played around with it some and thought: "Wow, I'm really confused. Maybe it will make more sense to a native bidi user, but I doubt it." So, once we got some keyboard group detection code into place I tried implementing jumping-cursor mode. The basic idea of jumping-cursor mode is "show whichever of the strong or weak cursor corresponds to the current keyboard direction." You can turn this on by putting gtk-split-cursor = 0 in your ~/.gtkrc. However, once I had that implemented, I discovered that just showing and hiding the cursor wasn't enough ... it was necessary to modify navigation as well. The current navigation code always navigates the strong cursor, but that's really confusing when the strong cursor is invisible. That was more work than I was prepared to do at that point, so I filed this bug and moved on. At some later point, I realized that for click-to-position, the behavior of positioning the visible cursor at the click position might not be the natural one. The users choice of where they click actually is a stronger indication of what they are planning to do than the current keyboard layout. So instead you might want to switch the keyboard layout. That's what bug 101380 is about.
Owen, thanks for the detailed history. However, putting gtk-split-cursor = 0 in ~/.gtkrc doesn't make any different here. I remember testing that before to the same conclusion. Will investigate later. Thanks again.
Investigation never happened. 9 years later, time to close