[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
compute-motion inconsistency
From: |
Kim F. Storm |
Subject: |
compute-motion inconsistency |
Date: |
23 Jul 2004 10:54:06 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 |
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 will take care of fixing the remaining cases at the C level.
It is more tricky to fix it at the lisp level (I will do it for the
packages delivered with emacs, but we cannot fix it for external
packages).
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).
Then we should change the doc string to read:
| 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',
| or that value minus 1 (for backwards compatibility).
WDYT?
- compute-motion inconsistency,
Kim F. Storm <=