From xemacs-m  Sun Jan 12 19:25:44 1997
Received: from crystal.WonderWorks.COM (crystal.WonderWorks.com [192.203.206.1])
          by xemacs.org (8.8.4/8.8.4) with ESMTP
	  id TAA02610 for <xemacs-beta@xemacs.org>; Sun, 12 Jan 1997 19:25:42 -0600 (CST)
Received: by crystal.WonderWorks.COM 
	id QQbygb02393; Sun, 12 Jan 1997 20:25:43 -0500 (EST)
Date: Sun, 12 Jan 1997 20:25:43 -0500 (EST)
Message-Id: <QQbygb02393.199701130125@crystal.WonderWorks.COM>
From: Kyle Jones <kyle_jones@wonderworks.com>
To: xemacs-beta@xemacs.org
Subject: Re: 19.15b90: [PATCH] window.el: shrink-window-if-larger-than-buffer
In-Reply-To: <m2hgkmea12.fsf@altair.xemacs.org>
References: <QQbyfi01495.199701122039@crystal.WonderWorks.COM>
	<97Jan12.173254edt.10634(1)@jupiter.scs.Ryerson.CA>
	<m2hgkmea12.fsf@altair.xemacs.org>

Being that we're close to a release, I took a minimalist approach in
my patch.

But if you're going to rewrite that function anyway, be careful.
There is some subtlely involved.  You can't use forward-line to
select the proper window height, for instance.  This will loses on
wrapped lines.  You can't use vertical-motion either, unless you
know all the text in the buffer is displayed using a font that is
the same height and width as the 'default face font in that
locale and that there are no glyphs (image or strings!) displayed
in the buffer.

Sick though it is, inserting newlines at the top of the buffer
and checking (pos-visible-in-window-p (point-max)) avoids all
these problems.  Whoever it was who wrote the original knew that
they were doing, even if buffer-file-name gets set to nil too many
times and a variable or two is forgotten or unnecessary.

Since it's both late and a tricky function I vote for saving the
rewrite until after the release.  The really bad thing, the
buffer ordering problem, is taken care of with a much smaller
code change.

