[Bug: 21.4.15] Bad interaction between scroll-conservatively, scroll-step and beginning-of-buffer.
ben at 666.com
Tue May 4 02:28:26 EDT 2004
Hmm, I'm not sure what the context here is but your statements about
mule aren't quite right. Forward and backward are not (especially)
asymmetrical, that is one of the most basic features of the mule
encoding ... Point-min is indeed always in the cache and one of the
very first things the position conversion code does is check for this
position so it's unlikely it's getting forgotten. And the macros should
pretty much always resolve in such a way that a non-Mule compile feels
no hit from the "old" days -- basically any place that this wouldn't be
the case, I bracketed specifically with #ifdef MULE.
In any case however, I think this is irrelevant -- redisplay does its
own weird caching which is independent of the buffer-position caching,
and it looks like you're getting stuck on this somewhere. The only
person who ever really understood this is Chuck Thompson, and he (a)
never documented it, and (b) has answered all questions about it for at
least the last 6-7 years with "I don't remember anymore". This is one
of the few areas I've never tried to understand ... [Any of you who are
working on it, *please* document what you've come to understand!]
From: Stephen J. Turnbull [mailto:turnbull at sk.tsukuba.ac.jp] On Behalf
Of Stephen J. Turnbull
Sent: Monday, May 03, 2004 9:06 PM
To: Jerry James
Cc: XEmacs Beta; Ben Wing
Subject: Re: [Bug: 21.4.15] Bad interaction between
scroll-conservatively, scroll-step and beginning-of-buffer.
>>>>> "Jerry" == Jerry James <james at xemacs.org> writes:
Jerry> If the place we are trying to reach is "close", this makes
Jerry> sense. So why don't we get here when doing M->? Does some
Jerry> code elsewhere note that we are going "far away" and skip
Jerry> this altogether somehow?
This is quite possible. Remember that under Mule going forward and
backward are asymmetrical in the small, and that a buffer is not an
array of characters. Mule does a lot of caching of buffer positions.
Supposedly (point-min) and (point-max) are both always in the cache, but
maybe somehow XEmacs thinks that (point-min) isn't there?
Note that just because something isn't a Mule build doesn't mean that
the fundamental algorithms haven't felt the impact of needing to be
compatible with Mule.
Institute of Policy and Planning Sciences
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
More information about the XEmacs-Beta