From xemacs-m  Fri Mar 21 07:08:45 1997
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id HAA02076;
	Fri, 21 Mar 1997 07:08:44 -0600 (CST)
Message-Id: <199703211308.HAA02076@xemacs.org>
To: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
cc: Martin Buchholz <mrb@Eng.Sun.COM>, Steven L Baur <steve@miranova.com>,
        xemacs-beta@xemacs.org
Subject: Re: PATCH: Re: char-before (Re: XEmacs 19.15-b102 is released) 
In-reply-to: Your message of "Fri, 21 Mar 1997 17:44:05 +0200."
             <199703210844.RAA15664@mikan.jaist.ac.jp> 
Date: Fri, 21 Mar 1997 07:08:44 -0600
From: Chuck Thompson <cthomp@xemacs.org>

    Martin> The best thing Ben did in his massive Mule rewrite was to make
    Martin> byte positions completely inaccessible from the lisp level.
    Martin> It is impossible to end up in the middle of a character.  All
    Martin> lisp operations are character, not byte, oriented.

    MORIOKA> I like this choice.  HANDA Ken'ichi and RMS gave up this
    MORIOKA> choice because of terrible speed down.  I discussed with
    MORIOKA> Ken'ichi about this.  He proposed to use cache about
    MORIOKA> position <-> byte conversion.


Ben and I discussed doing just that really early, possibly even before
he started doing any coding for the MULE changes.  The basic idea was
to use the extent structure internally to track the boundaries between
different size characters.  In the degenerate case you would possibly
end up worse performance (and definitely higher memory usage) but most
of the time it should be a huge win.

It is very similar in concept to the optimization which is responsible
for cursor redisplay not being utterly dog slow as it was in the early
19.12 beta days.  Close enough that it could probably be considered a
partitial proof of concept.



			-Chuck

