GNOME Bugzilla – Bug 81412
Track leading/trailing cursor positions
Last modified: 2018-02-10 03:40:44 UTC
Description of Problem: The [End] key does not always position the text cursor behind the last character when a line is wrapped. Steps to reproduce the problem: 1. Start gedit2. 2. Type in the following text (do not type the line number): 1 The quick brown fox jumps over the fat and lazy dog. The quick brown fox j umps over the fat and lazy dog. 3. Press the [Up] key. 4. Press the [End] key. Actual Results: The text cursor ("|") is positioned in front of the last character. 1 The quick brown fox jumps over the fat and lazy dog. The quick brown fox |j umps over the fat and lazy dog. Expected Results: The text cursor ("|") should be positioned behind the last character. 1 The quick brown fox jumps over the fat and lazy dog. The quick brown fox j| umps over the fat and lazy dog. How often does this happen? Most of the time. It appears to depend on the window width. Version Details: gtk2-2.0.2.0.200205071406-0.snap.ximian.1 gedit2-1.118.0.0.200205071406-0.snap.ximian.1
I believe that this bug is described by the following comment in gtktextlayout.c: /* FIXME: As a bad hack, we move back one position when we * are inside a paragraph to avoid going to next line on a * forced break not at whitespace. Real fix is to keep track * of whether marks are at leading or trailing edge? */
Would need to add a leading/trailing flag to GtkTextMark; that's simple, but using it everywhere would be some work. This bug, is however, pretty important for CJK, Thai, and other languages that don't use whitespace for text boundaries.
*** Bug 155890 has been marked as a duplicate of this bug. ***
*** Bug 428252 has been marked as a duplicate of this bug. ***
*** Bug 396308 has been marked as a duplicate of this bug. ***
*** Bug 517434 has been marked as a duplicate of this bug. ***
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.