Re: compute-motion inconsistency

[David Kastrup <dak@gnu.org>]

storm@cua.dk (Kim F. Storm) writes:

> The interface to compute-motion is inconsistent, and the
> implementation is inconsistent too.
> 
> Problem is the "width" arg, quoting from the doc string:
> 
> | width is the number of columns available to display text;
> | this affects handling of continuation lines.
> | This is usually the value returned by `window-width', less one (to allow
> | for the continuation glyph).
> 
> But on window based display, there is no continuation glyph, so
> typically the value provided for the width arg is one too small.
> I checked the caller of compute-motion (and compute_motion
> at the C level), and the calls are not consistent either.
> 
> Some calls subtract 1 unconditionally,
> some subtract 1 on non-window systems,
> and some do not subtract 1 at all.
> 
> IIRC, the ones which does this correctly (the second category) I
> have fixed myself while working on redisplay over the past years.

I somewhat doubt that they do this correctly.  I think that things
differ again if one customizes the fringes off.

In my opinion, it is a complete mistake not to leave the continuation
glyph mess actually to compute-motion itself as soon as the WINDOW
parameter is actually present.

> For backwards compatibility, I suggest the following change to
> compute-motion:
> 
> If "width" equals (1- (window-width)) on a window system,
> automatically use (window-width) instead.
> 
> If "width" equals (window-width) on a non-window system,
> automatically subtract 1 (for the continuation glyph).

That's not "compatibility", that is madness.  I don't think that this
sort of change, which makes things utterly incomprehensible and
unpredictable for the sake of some backward compatibility idea, is
warranted.

I prefer an incompatible change where just window-width can be used,
always.  We had inconsistent behavior and usage before, tough.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum