GNOME Bugzilla – Bug 732418
Incorrect line numbering when breaking a long line
Last modified: 2014-07-17 21:06:22 UTC
I use Gedit 3.12.2. I have configured Gedit with the following options: - Display line numbers: yes - Enable text wrapping: yes - Do not split words over two lines: yes Instructions for reproducing the bug: - Create a new text file with the "0123456789" string block repeated 10 times on line 1 (put a space between repetitions). - Write "Hello World" on line 2. - Shrink the Gedit window horizontally until line 1 is displayed on two lines (for example five blocks on the first line and five blocks on the second line). - Move the cursor to the beginning of the second block. - Hit enter without moving the mouse or the cursor. Line 1 breaks into two lines as expected. So we have five blocks on line 1 and five other blocks on line 2. But the "Hello World" line still is on line 2 instead of line 3. It becomes line 3 only when you move the mouse or the cursor. So the problem is that Gedit doesn't refresh line numbers immediately.
Maybe related, the drawing of misspelled words doesn't disappear completely directly, when we fix a word. The problem comes maybe from a code we removed in gtksourceview, that redraws the text view on certain changes: https://git.gnome.org/browse/gtksourceview/commit/?id=949cd128064201935f90d999544e6a19f8e3baa6 It can also be a GtkTextView bug, for example with the changes with the pixel cache.
I can reproduce the bug with gtksourceview's test-widget.
The bug occurs with gedit 3.8 too, so the culprit is neither the above commit, nor the pixel cache in GtkTextView.
Created attachment 281023 [details] [review] gutter: always invalidate the whole GdkWindow Call gdk_window_set_invalidate_handler() in update_gutter_size(), because the GdkWindow is created only when its size is greater than 0. update_gutter_size() is already called when the widget is realized, so it ensures that the invalidate handler is set at least once. The performances should not be a problem, because the gutter was already redrawn completely on each mouse motion event in the gutter (not when moving the mouse in the text view).
To describe a little more the bug: The wrapped line is at line 1 and takes two visible lines on the screen, with a third visible line at line number 2. When the wrapped line is split, the third visible line doesn't need to be redrawn by GtkTextView, since its position is still the same. So GtkTextView sends a ::draw signal with a clipped region only for the two first visible lines, not for the third one. The problem is that the third visible line has a different line number (2 -> 3).
Fixed: https://git.gnome.org/browse/gtksourceview/commit/?id=822e4c5ee71ed4e447fd14a8dc1c1ded751efece Thanks for the bug report.