Re: How to obtain x/y/hpos/vpos at eol -- excluding overlay 'after-string.

[Eli Zaretskii]

> Date:  Tue, 05 Apr 2016 10:37:44 -0700
> From:  Keith David Bershatsky <address@hidden>
> Cc:  address@hidden
> 
> PROBLEM # 1:  `mc_x_y_hpos_vpos` needs to be modified to exclude overlays 
> from the calculation so that placement and removal of fake cursors can be 
> correctly achieved.  Any assistance in modifying this function to exclude 
> overlays from the calculation would be greatly appreciated.

Actually, overlay strings is just one possible way of having a buffer
position concealed in the glyph row's glyphs.  There are a few more,
like display strings, selective display, invisible text, etc.  A
display or overlay string can also have a 'cursor' property on one of
its characters, and users will expect you to place the cursor on that
character.  All of those situations are problematic for finding the
cursor coordinates given just its buffer position.  For the full
story, see set_cursor_from_row.

So I think your design is sub-optimal.  AFAIU, you wait until
redisplay is done with its job and calls the frame's
update_window_end_hook.  Then you do all of the job of positioning the
additional cursors and drawing them in that hook.  This is suboptimal,
because you are forced to traverse the window anew starting from its
beginning for each additional cursor.  Instead, you could compute the
cursor coordinates as part of the layout code, like what we do with
set_cursor_from_row.  The results of that function, i.e. the
coordinates of the cursor in the window, are stored in the window
object, and update_window_end_hook just uses them to actually draw the
cursor.  You could refactor set_cursor_from_row and the code that
calls it to compute the coordinates of additional cursors, and then
you'd get the solution to your problems with overlays and whatnot for
free, because set_cursor_from_row already deals with all that.  And
your 2nd problem will go away as well, because the cursor coordinates
will be computed as part of the code which scrolls the display,
instead of trying to find the previous cursor position after scrolling
was already done.

You should also look at expose_frame and its subroutines, because
handling the expose events requires redrawing the cursors, which AFAIU
you currently don't do.