bug#41513: `compute-motion' can miscount buffer positions in the presence of 'before-string/'after-string overlays

[Stephen Bach]

On Mon, May 25, 2020 at 11:22 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> Please tell more.  What exactly would you like to measure?  Is it the
> width of each screen line? or just the maximum width of the longest
> line among those shown in the window? or something else?

The width of each screen line, kind-of. I'm writing a
terminal-compatible drawing library for displaying low-res
visualizations in the buffer/window:

   - https://sjbach.com/canvas-emacs-logo.mp4
   - https://sjbach.com/canvas-mario.mp4

To draw an image I apply temporary overlays to buffer ranges that
correspond to window coordinates which themselves correspond to the
"pixels" of the image.

A performance-sensitive part of this turns out to be when I walk between
`window-start' and `window-end' to figure out (1) the buffer positions
of the final characters of visible screen lines/visual rows, and (2) the
buffer positions underlying particular window coordinates that happen to
fall within the buffer text -- both of which I've been using
`compute-motion' to calculate.

Is `vertical-motion' a more reliable analogue to `compute-motion'? I see
it can take a (COLS . LINES) argument, so it appears similar.