[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: compute-motion inconsistency

From: David Kastrup
Subject: Re: compute-motion inconsistency
Date: 23 Jul 2004 11:46:37 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

address@hidden (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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]