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

[Eli Zaretskii]

> Date:  Mon, 04 Apr 2016 14:06:08 -0700
> From:  Keith David Bershatsky <address@hidden>
> 
> There are a couple of applications where this would be useful.
> 
> The first application is a common function available interactively called 
> `posn-at-point` which cannot return the desired `x` and `hpos` when an 
> 'after-string is present at point.  For example, line-move-visual in 
> simple.el has never worked correctly when I have overlay 'after-string at the 
> end of the line.  So, I have been using a workaround with `vertical-motion` 
> to calculate the desired `temporary-goal-column`.  Here is the link to a 
> thread on emacs.stackexchange.com from about a year ago relating to this 
> issue:
> 
> http://emacs.stackexchange.com/questions/7957/calculating-cursor-position-excluding-the-overlay-after-string

Your original request was about doing this on the C level, so the
above use case is not really related: line-move-visual is implemented
in Lisp.

> The second application is related to feature request 22873 (multiple fake 
> cursors) and a dormant (yet related) feature request 17684 (drawing a 
> vertical line the length of the window).  I have not been able to accurately 
> predict programmatically where the fake cursors are located subsequent to the 
> screen scrolling when overlay 'after-string are present.  [I spent a day 
> writing up a function to calculate the differential of `y` and `vpos` based 
> on previous and current window-start/end, only to discover that the Little 
> Rascals (fake cursors) were still somewhere else when scrolling.]  The 
> function `erase_phys_cursor` redraws the character (where the cursor was) 
> based upon (in part) the values of x/y/hpos/vpos.  Until I can figure out how 
> to accurately predict where those Little Rascals (fake cursors) have gone to 
> when scrolling occurs, the easiest thing to do is erase/redraw everything 
> along the `x` axis.  `erase_phys_cursor` should not be used, however, when 
> there is no TEXT along the `x` axis - because that yields strange looking 
> glyphs along the right side of the screen.  Before calling 
> `erase_phys_cursor` (or my custom function `mc_erase`), I want to check to 
> see where the end of the visual line is -- i.e., x/y/hpos/vpos at the end of 
> each visual line -- and only erase/redraw characters when the `x` axis is 
> less than the end of the visual line

This is indeed about something you do in C.  However, I don't
understand why you try using posn-at-point, which is a Lisp API, for a
job you need to do in C.  On the C level, you have access to a more
elaborate information, e.g. you can examine the object at point and do
something when it is an overlay string.

I must admit I still don't see clearly why you need screen coordinates
corresponding to a buffer position, in the multiple-curses scenario.
Isn't it your code that positions those cursors in the first place?
If so, why do you need to find out where those cursors are, if your
code did the positioning?