Re: Getting column position accounting for overlays

[Eli Zaretskii <eliz@gnu.org>]

> From: Yuri D'Elia <wavexx@thregr.org>
> Date: Sat, 8 Aug 2015 17:19:02 +0200
> 
> On 08/08/15 16:45, Eli Zaretskii wrote:
> >> Ah yes, but that's precisely the problem: I need to calculate POS
> >> beforehand.
> > 
> > Yes, of course.  But you will have the same problem if you do get the
> > text dimensions: you need to compare that with something to do useful
> > things with the value.  Right?
> 
> Getting text dimensions was/is sort of a work-around.
> If I could get displayed text easily, the iteration over overlays
> wouldn't be needed: I could just take the string length.

Take the string length and do what with it?

And please don't assume that given a string you can compute its
visual length easily: you can't, not with variable-pitch fonts.  And
then you have images, stretches, etc.

> Again, it would have problems on its own as we discussed, so far none of
> the solutions work perfectly.

Solutions to what problem(s)?

> To be more concrete, what about a (visual-column) function, that just
> gives what's currently needed?

I've already shown you a way to compute that, several message ago.
Let me repeat:

  (/ (car (window-text-pixel-size nil (line-beginning-position) (point)))
     (default-font-width))

> (visual-column &optional logical)
> 
> Return the horizontal position of point. Beginning of the *visual* line
> is column 0.                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  ^^^^^^^^^^^

This is contrary to current-column conventions: it counts from the
beginning of the physical line, not visual line.  If you want to count
from the beginning of the visual line, replace line-beginning-position
above with something like

  (save-excursion (beginning-of-visual-line) (point))