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

Previous Next

Full log

Message #17 received at 41513 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Bach <sjbach <at> sjbach.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 41513 <at> debbugs.gnu.org
Subject: Re: bug#41513: `compute-motion' can miscount buffer positions in the
 presence of 'before-string/'after-string overlays
Date: Mon, 25 May 2020 16:16:08 -0400

On Mon, May 25, 2020 at 11:22 AM Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.