We have mark_set on GtkTextBuffer, which (I assume?) is sufficient;
that leaves GtkEntry to fix. GtkText is dead code. Need details on
what the signal will be used for in the accessibility API, etc. though
in order to plan this change.

GtkTextView:  It's not apparent that mark_set will help, as we need
the visible cursor position and it's not clear that we can distinguish
the mark_set in gtk_text_buffer_place_cursor() from any other mark_set
operation.  

But it looks as though gtk_text_buffer_get_iter_* and
gtk_text_buffer_place_cursor
will be helpful.  What we need is a
property change signal fired for all operations that
change the cursor position... if there is no 
cursor position property then I think we need one,
in which case gtk_text_buffer_place_cursor
would do the property change notification (to the
GtkTextView ?)

We need the same feature (cursor position 
change notification) in GtkEntry.  At first glance
it looks as though connecting to the "move_cursor" signal
will do what we need.  OK, perhaps we can forget 
GtkText, but probably we could implement what we need
on it using the same mechanism.

(P.S. - GtkTextBuffer API docs (GTK+2.0) seem to be missing 
 most functions - maybe we should file another bug ? ;-)

- See gtk_text_view_mark_set_handler() for an example of
  tracking the cursor in a buffer.

- ::move_cursor doesn't do what you want. It is an action
  signal called by key bindings - signals in GTK+ have a dual 
  nature, they are usually used for notification, but there are 
  also is a usage asintrospectable, dynamically callable
  member functions for things like callbacks.

- The doc rebuild wasn't getting run for a while, but the
  docs look fine now.

We actually already have the API for GtkEntry too - connect
to:

 notify::text_position

However, it looks like there are some notifications missing
for this property, so leaving the bug open, but not as
an API bug.

Notifications on ::text_position should be fixed now.