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

From: Stephen Bach <[email-masked]>
Date: Sun, 24 May 2020 15:55:09 -0400

On Sun, May 24, 2020 at 3:09 PM Eli Zaretskii <[email-masked]> wrote:
> Don't use compute-motion.  It is a remnant of the old pre-Emacs 21
> display engine, and almost certainly doesn't support tricky display
> features.
>
> There are other functions that can do the same job.  If you describe
> what you need to do, I could try suggesting some alternatives that
> will work.

Thanks Eli. Specifically, I'm measuring the jagged contour of a buffer's
layout within a particular window, i.e. relating the final column of
each visual row (as displayed within the window) to concrete buffer
positions. This is notionally straightforward but complicated in
practice, as you will know -- e.g. line continuation/truncation,
`word-wrap', `visual-line-mode', `adaptive-wrap-prefix-mode',
multi-columnar glyphs. Text properties or overlays using 'display, and
so on.

In my initial go at this I used `end-of-visual-line' calls within a
`save-excursion' but I found that to be a little slow given the
frequency I was making the calls and I was also uncomfortable about all
the cursor movement, perhaps irrationally. But maybe this is the correct
approach?

Re: `compute-motion', perhaps the manual or the docstring could include
a short note to dissuade developers from using it? Its complicated
interface may be sufficient to keep most people away, but on the other
hand a complicated interface can suggest efficiency and intricate
functionality.