If you have a look at the gtkdoc for GtkTextView's gtk_text_view_add_child_in_window() method, ie http://library.gnome.org/devel/gtk/stable/GtkTextView.html#gtk-text-view-add-child-in-window you'll see it has a reference to bug #64518 . That bug appears resolved and in any case not entirely relevant.

Poking away at it, I found that having embedded the GtkTextView in a GtkScrolledWindow and then connecting to the GtkVScrollbar's 'value-changed' signal (inherited from GtkRange) as suggested didn't seem that reliable. Reading through some of the comments in the gtk/gtktextview.c code I think I understand some of the complexities involved, and that the scollbar value changing is only about half way through the process.

Almost by chance I hit on connecting a handler to the GtkAdjustment 'value-changed' signal, and using that as the place to call gtk_text_view_move_child() *does* seem to work.

Anyway, after all this it is pretty clear that I don't fully grasp the implications of the interrelationships between the various GtkWidgets and GdkWindows involved, so I apologize if I missed something obvious. Nevertheless, the reference to an "unfixed" bug in the gtkdoc for gtk_text_view_add_child_in_window() probably needs to be changed.

I'd be more than happy to prepare a patch, but as I've indicated I'm not precisely sure what the right thing to suggest is.

AfC