Re: Getting column position accounting for overlays

[Eli Zaretskii]

> From: Yuri D'Elia <address@hidden>
> Date: Sat, 8 Aug 2015 18:29:18 +0200
> 
> On 08/08/15 17:43, Eli Zaretskii wrote:
> >> 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))
> 
> I didn't like this solution precisely because it doesn't rely on
> character-cells units

Why do you say that?  Did you try it and saw problems?  If so, please
show the test cases where the above doesn't do what you want.

> and was explicitly looking for character lengths/distances between
> arbitrary points.

So you are saying that you want to count a double-width character as a
single character "cell" even though it will take up 2 columns on
display?  And you'd like to count a TAB as a single "cell" even though
it can take 1 to 8 columns on display?  Why would something like that
be useful?  It also goes against current-column, which you said was
the model for what you were looking.

> If this calculation would be used in rigid-tabs for instance, I would
> calculate different amount of spaces whether a variable-pitch font is
> used or not, while my intention is much closer to (current-column).

current-column does know that a TAB doesn't take a single column.  And
you said that variable-pitch fonts are not part of the problem yuou
want to solve anyway.  So now I'm confused regarding what you are
looking for.

> If you're using a variable pitch font, everything does down the drain
> anyway.

Not if you calculate dimensions in pixels, no.