First of all, an important simplification might be to treat
"invisibility" as a paragraph attribute similar to margins, i.e. 
only the setting active on the first char of the paragraph matters, 
and modifies the whole paragraph.

Second, the big complication: if you can hide a ton of paragraphs,
that lets us put thousands of paragraphs onscreen at once. And the
scalability of the widget depends on the fact that validating onscreen
paragraphs is cheap. So implementing this will _require_ some
optimization that allows us to "quick-validate" invisible paragraphs
without actually creating the PangoLayout, or something like that.

Enhancement, right, havoc?

Created attachment 13545 [details] [review]
patch

Above patch makes intra-paragraph invisible text work mostly ok by
fixing the cursor movement functions to skip invisible chars. A lot
more  needs to be done before invisible text can be declared
supported, of course.

Looks good to me, thanks.

I committed a similar patch.

A. This seems to work in 2.2.1. Any reason this bug is still open?
B. In 2.2.1, even though it seems to work, it still sends a warning on
stdout, is that normal?

It only seems to work; there are still many open issues.

Could someone summarize what the remaining open issues are
wrt this item ? Thanks.

Yeah, this seems to work beautimously in 2.2.1.  We're using this in
Gaim 0.65cvs to hide/unhide timestamps on messages.

If there are no other issues with this, could something be done about:
Gtk-WARNING **: The "invisible" property on GtkTextTag is not
supported for GTK 2.0, it will be added in a future release. see
http://bugzilla.gnome.org bug #66194 for status

It's quite annoying.  If there are still issues with invisibility,
what are they, out of curiosity?

Its kind of working for making parts of a paragraph invisible. But it
doesn't properly handle making more than a paragraph invisible. I
believe that I could make it crash easily in that scenario. The
problem with completing the support in the current approach is that
you have to duplicate all navigation functions to have a variant which
operates on all chars and one which operates on visible chars only.
And when using navigation internally, you always have to wonder
whether invisible parts should be skipped or not. When looking at
this, I came to the conclusion that the right way to support invisible
text would be with some form of nested model (like TreeModelFilter),
but that is kind of hard, given that GtkTextBuffer is not an interface...

Thanks for the explanation, Matthias.  I ended up removing the use of
invisibility for the timestamps because it causes weird behavior with
mouse highlighting.

I suppose this is just another part of the incomplete nature of the
feature: When text at the beginning of a line is invisible (eg. the
timestamps in gaim conversations), attempting to select/highlight text
in the GtkTextView does not select/highlight the text directly under
the mouse cursor.  Instead it selects text at an offset to the right
of the mouse cursor equal to the length of the text that is invisible
at the beginning of the row.

Perhaps this is a bit more clear, "it hilights based on offsets that
aren't updated with visibility."

This is with gtk 2.2.1--I have not tried with 2.2.2.  We would love to
see this feature fully implemented, by the way :-)

*** Bug 139509 has been marked as a duplicate of this bug. ***

From testing the gtk-2-6 branch, the only thing not working for completely
invisible paragraphs/lines is moving the cursor from the start/end of the
next/previous line to the invisible line. The following patch fixes this
(do-while loop that continues until it finds a visible line). This patch should
be enough to get the basic "hide lines" functionality working (very useful for
GtkSourceView). If this gets committed, please also remove the g_warning from
gtktexttag.c:1237.

Created attachment 38978 [details] [review]
patch against gtk-2-6 branch

Moving to 2.6.5 to consider Jeroens patch

The patch may be a step in the right direction, but even with it, it is still
very easy to trigger things like:

(lt-testtext:28618): Pango-CRITICAL **: pango_layout_get_cursor_pos: assertion
`layout != NULL' failed

(lt-testtext:28618): Pango-CRITICAL **: pango_layout_get_cursor_pos: assertion
`layout != NULL' failed

(lt-testtext:28618): Pango-CRITICAL **: pango_layout_index_to_pos: assertion
`layout != NULL' failed

when invisible text is present in the buffer. The particular case above was
provoked by making a paragraph completely invisible, then moving the cursor in
it using Ctrl-Up/Ctrl-Down

So this requires adding new API for going forward/backward to a visible line.
I've written some untested code. Does this look like a correct approach?

gboolean
gtk_text_iter_forward_visible_line (GtkTextIter *iter)
{
  while (gtk_text_iter_forward_line (iter))
    {
      do
        {
          if (!gtk_text_iter_forward_char (iter))
            return FALSE;
          
          if (!_gtk_text_btree_char_is_invisible (iter))
            return TRUE;
        }
      while (!gtk_text_iter_ends_line (iter));
    }
    
  return FALSE;
}

Attached patch fixes the Ctrl-Up/Down corner case by introducing some new API:
gtk_text_iter_[forward|backward]_visible_line(s). This is needed for navigating
invisible lines in gtktextview.

Created attachment 47062 [details] [review]
patch against gtk-2-6 branch

2005-06-13  Matthias Clasen  <mclasen@redhat.com>

	Make invisible text work a bit better (#66194, patch by
	Jeroen Zwartepoorte)
	
	* gtk/gtk.symbols:
	* gtk/gtktextiter.[hc]: Add function to move by
	visible lines.

	* gtk/gtktextview.c (gtk_text_view_move_cursor_internal): 
	Skip invisible text when moving by paragraphs.

	* gtk/gtktextlayout.c (gtk_text_layout_move_iter_visually): 
	Skip invisible lines here too.

Ok, committed that. One thing that needs fixing before we can remove the warning 
is that there is an assumption that display->layout != NULL after calling 
gtk_text_layout_get_line_display(). That assumption is made in many places in
gtktextlayout.c, basically everywhere where a pango_layout function is called.

The problem is that gtk_text_layout_get_line_display() has an optimization for
totally invisible lines which returns a display without a layout. 

The easiest fix for this problem may be to simply give the display and empty
layout in this case.

Or just remove the optimization...

Created attachment 48237 [details] [review]
another patch

This patch seems to make most assertions go away, I only got a single 

(lt-testtext:21957): Gtk-CRITICAL **: line_display_iter_to_index: assertion
`_gtk_text_iter_get_text_line (iter) == display->line' failed

while playing with it so far. I did notice that Ctrl-PgUp seems to have stopped

working, but that may be independent.

The Ctrl-PgUp thing was something unrelated. 

2005-07-11  Matthias Clasen  <mclasen@redhat.com>

	* gtk/gtktexttag.c (gtk_text_tag_class_init) 
	(gtk_text_tag_set_property): Remove the runtime warning about 
	the invisible property, add a warning about possible remaining
	problems to the documentation of the property.  (#66194)