Re: Getting column position accounting for overlays

[Yuri D'Elia <wavexx@thregr.org>]

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.

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

>> It's not so trivial, considering that you basically have to handle all
>> 'display cases manually to replicate what emacs does, you might have
>> overlapping overlays, and so on. I also think that it's bound to break
>> if 'display gets extended to support new properties.
> 
> It's simply impossible, except in a few special cases.  If we need
> such a feature that should work everywhere, we will need to ask the
> display engine to supply this information.
> 
> But I still am unsure when would this be needed.

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

---

(visual-column &optional logical)

Return the horizontal position of point. Beginning of the *visual* line
is column 0. This is calculated by adding together the widths of all the
displayed representations of the characters, *including 'display
overlays*, between the start of the previous *visual* line and point
(e.g., control characters will have a width of 2 or 4, tabs
will have a variable width).

If logical is non-nil, count displayed characters since the beginning of
the current logical line.

(visual-column t) is similar to (current-column), with the difference
that overlays are taken into account.

---

This would be the ideal basis for any visual-alignment function.