From: storm@cua.dk (Kim F. Storm)
Subject: compute-motion inconsistency
Date: 23 Jul 2004 10:54:06 +0200 [thread overview]
Message-ID: <m3u0vzp0i9.fsf@kfs-l.imdomain.dk> (raw)
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?
next reply other threads:[~2004-07-23 8:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-23 8:54 Kim F. Storm [this message]
2004-07-23 9:46 ` compute-motion inconsistency David Kastrup
2004-07-23 12:56 ` Kim F. Storm
2004-07-23 18:44 ` Stefan Monnier
2004-07-23 19:04 ` David Kastrup
2004-07-24 19:44 ` Richard Stallman
2004-07-25 22:24 ` Kim F. Storm
2004-08-02 15:28 ` Kim F. Storm
2004-08-02 21:17 ` Andreas Schwab
2004-08-02 23:45 ` Kim F. Storm
2004-08-03 9:48 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3u0vzp0i9.fsf@kfs-l.imdomain.dk \
--to=storm@cua.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).