GNOME Bugzilla – Bug 361766
Cursor is positioned where it shouldn't
Last modified: 2016-12-02 22:24:04 UTC
gedit saves cursor position for each file and position the cursor there next time you open the file. Whatever this use to position the cursor, it happens now that it may position it somewhere that is not a cursor position. To test, copy this into a text file in gedit: ab بّ and position the cursor between 'a' and 'b'. Now save and close gedit. Open the file in another editor and remove the first line completely. Open the file in gedit again, see the weak cursor showing up which is an indication of the cursor being in between the Arabic cluster. Just move the cursor and you cannot get it back to where it was originally anymore.
gedit bug, since there is gtk_text_iter_is_cursor_position() to check whether given offset is good to place cursor.
I am not totally convinced... If I cannot reach a cursor position with the keyboard/mouse, gtk should prevent me to do so even programmatically and move the cursor at the start(or end?) of the cluster for me...
The fix would be: void gtk_text_buffer_set_mark () { if ((_gtk_text_btree_mark_is_insert (get_btree (buffer), mark) || _gtk_text_btree_mark_is_selection_bound (get_btree (buffer), mark)) && !gtk_text_iter_is_cursor_position (iter)) { g_warning ("can't place cursor or selection bound not at cursor position"); return; } ... } And you still want to fix it in gedit. Do you like the idea? (It can't be silent, it would be no better than now, what happens if you place cursor in the middle of \r\n)
I committed the check in gedit, but still I think that gtk should either state that placing cursor on that spot is illegal (and then spew a warning as per muntyan patch, possibly mentioning the gtk_text_iter_is_cursor_position function) or deal silently with the case (either not moving the cursor or moving it at the start of the cluster). If the second option is picked, it should be documented that place_cursor may actually not move the cursor at all... If we really want to get fancy we could even make gtk_text_buffer_place_cursor return a boolean (at the moment it returns void so it should be possible without api break) Anyway moving back to gtk
I agree with paolo that gtk+ should move the cursor back to the first of the grapheme.
It will break this: gtk_text_iter_forward_char(iter); gtk_text_buffer_move_mark(buffer, mark, iter); /* we could move it one char forward again, why not */ It should probably spit a warning so developer knows something is wrong, but it shouldn't start failing where it worked before.
Hey Behdad, is this still an issue? Since Paolo fixed it in gedit I don't really have a way to try and reproduce it with recent versions of the software stack.
Don't know. Marking obsolete.