After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 313718 - regression: unable to highlight last line
regression: unable to highlight last line
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkTextView
2.8.x
Other All
: Normal normal
: Need diagnosis
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: 310847
 
 
Reported: 2005-08-17 13:18 UTC by Jeroen Zwartepoorte
Modified: 2018-02-10 03:36 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jeroen Zwartepoorte 2005-08-17 13:18:07 UTC
So the current release of GtkSourceView highlights the active line, even when on
the last line. The last line is completely empty in this example. It does this
by painting the highlight in the expose handler (ugly hack).

I've rewritten this code to use the new paragraph-background GtkTextTag
attribute in gtk+ 2.8. The start iter is the start of the last line. The problem
here is that the end iter == start iter. There is nothing else past the start
iter to point the end iter to. So somewhere along the line GtkTextView (or
buffer) detects that start iter == end iter and doesn't apply the
paragraph-background tag. The end result being that if you're on the last line,
the line isn't highlighted.

I'm reporting the problem here. I don't know if this can be fixed with breaking
API (behavior). I don't see a workaround atm. Ideas?
Comment 1 Matthias Clasen 2005-08-24 16:39:02 UTC
Needs someone to figure out where exactly that == end optimization happens, and
how to avoid it.
Comment 2 Jeroen Zwartepoorte 2005-08-25 21:21:01 UTC
gtktextbtree.c, line 1759, _gtk_text_btree_tag method:

  if (gtk_text_iter_equal (start_orig, end_orig))
    return;

I don't what the extend of the start iter == end iter behavior is. Past that
line it's still passing start & end around. So just changing this check is
probably not enough. Need to look into this further (when i have more time).
Comment 3 Jeroen Zwartepoorte 2006-01-16 12:27:38 UTC
Code path looks as follows:

gtk_text_layout_draw
  gtk_text_layout_get_line_display
    get_style
      _gtk_text_btree_get_tags
    set_para_values
  render_para
Comment 4 Owen Taylor 2007-10-18 13:34:19 UTC
This is really a conceptual problem more than anything:

 - The attributes of a paragraph are the attributes of the first character
   in the paragraph, or, if the paragraph doesn't have any characters, the
   attributes at the end of the paragraph. (After the delimiters, if any)

   See calls to set_para_values() in gtk_text_layout_get_line_display()

 - For an empty last line:

   - There are are no characters
   - The position at the end of the paragraph is the position at the buffer end
   - At the buffer end, all tags have been toggled off.

So there is simply no way of setting paragraph attributes for an empty last 
line in the buffer. To see this happening without a tag with start == end,
just apply a paragraph_background tag to the entire buffer from start tag
to end tag.

Figuring out a fix for this might be related to a more general issue of wanting
to specify whether a tag applies to the positions at the tag start toggle
and the tag end toggle or not. If you had that ability, then a tag that
is inclusive on both ends is not empty, even if it is zero length.

See bug 316550 for someone who wanted to modify the behavior of inserting
at tag end. There are also some other related issues... it's not possible
to use not-editable tags to prevent inserting at the first position of the
buffer.


Comment 5 Matthias Clasen 2018-02-10 03:36:53 UTC
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.