From xemacs-m  Fri Sep 26 10:32:19 1997
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id KAA22651
	for <xemacs-beta@xemacs.org>; Fri, 26 Sep 1997 10:32:15 -0500 (CDT)
Received: from crystal.WonderWorks.COM by relay1.UU.NET with ESMTP 
	(peer crosschecked as: [192.203.206.1])
	id QQdiri27544; Fri, 26 Sep 1997 10:38:10 -0400 (EDT)
Received: by crystal.WonderWorks.COM 
	id QQdiri19943; Fri, 26 Sep 1997 10:37:52 -0400 (EDT)
Date: Fri, 26 Sep 1997 10:37:52 -0400 (EDT)
Message-Id: <QQdiri19943.199709261437@crystal.WonderWorks.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Kyle Jones <kyle_jones@wonderworks.com>
To: xemacs-beta@xemacs.org
Subject: Re: latin/kana flashing in SKK, 20.3 "Sarajevo" XEmacs  Lucid (beta23)
In-Reply-To: <m24t78o947.fsf@altair.xemacs.org>
References: <m0xEaqM-00002WC@tanko.sk.tsukuba.ac.jp>
	<m24t78o947.fsf@altair.xemacs.org>
X-Mailer: VM 6.34 under 20.3 "Sarajevo" XEmacs  Lucid (beta23)
X-Face: /cA45WHG7jWq>(O3&Z57Y<"WsX5ddc,4c#w0F*zrV#=M
        0@~@,s;b,aMtR5Sqs"+nU.z^CSFQ9t`z2>W,S,]:[+2^
        Nbf6v4g>!&,7R4Ot4Wg{&tm=WX7P["9%a)_da48-^tGy
        ,qz]Z,Zz\{E.,]'EO+F)@$KtF&V

SL Baur writes:
 > What you describe and what your GIF shows sounds like typical XEmacs
 > behavior when it has to deal with multiply sized fonts in the same
 > buffer.
 > 
 > If I'm right, XEmacs has worked this way since 19.12 (I have no
 > earlier experience with XEmacs).  It is better to do it this way than
 > reserve the maximum possible font height for each line.  How would you
 > propose to fix it?

It is indeed standard behavior.  I've been using an isearch face
that uses a larger font than the default face and the lines below
a search match move downward as a result.  It's been this way
since 19.10 or 19.11 and I don't see any other way to do it.  The
space has to come from somewhere, and the display code can't know
how much space is needed until the first char of a larger font
has been inserted.

