From xemacs-m  Fri Jan  3 11:26:16 1997
Received: from cdc.noaa.gov (manager.Colorado.EDU [128.138.218.210])
          by xemacs.cs.uiuc.edu (8.8.4/8.8.4) with SMTP
	  id LAA03172 for <xemacs-beta@xemacs.org>; Fri, 3 Jan 1997 11:26:15 -0600 (CST)
Received: from charney by cdc.noaa.gov (SMI-8.6/SMI-SVR4)
	id KAA05181; Fri, 3 Jan 1997 10:26:17 -0700
Received: by charney (SMI-8.6) id KAA08191; Fri, 3 Jan 1997 10:26:17 -0700
Sender: mdb@cdc.noaa.gov
To: XEmacs beta-list <xemacs-beta@xemacs.org>
Subject: Re: Bug in window-displayed-height?
References: <kig4thnbvpr.fsf@jagor.srce.hr>
	<m220cqlkms.fsf@proletcult.slip.ifi.uio.no>
	<m2iv5kc53r.fsf@altair.xemacs.org>
Organization: CIRES, University of Colorado
X-Attribution: mb
From: Mark Borges <mdb@cdc.noaa.gov>
Date: 03 Jan 1997 10:26:15 -0700
In-Reply-To: Steven L Baur's message of 30 Dec 1996 09:30:16 -0800
Message-ID: <vk916azn48.fsf@cdc.noaa.gov>
Lines: 60
X-Mailer: Gnus v5.2.40/XEmacs 19.15

>> On 30 Dec 1996 09:30:16 -0800,
>> Steven L Baur(sb) wrote:
sb> I've found some new symptoms of what looks to be the same problem.
sb> In particular, the scrollbar doesn't appear to be getting valid
sb> buffer size information at all times.  In the case I ran across,
sb> executing recenter caused the scrollbar to truncate the top of the
sb> file until the window was split and restored.  I have not reduced
sb> this to a simple test case yet.

Has any progress been made on this front? It bites me several times a
day (I have `scroll-on-clipped-lines' set to t). If not, can the other
variable, `gnus-xmas-force-redisplay', which is apparently not in the
distributed Gnus and is an rgnus feature, be propagated to
Gnus-5.2.40? Or perhaps use the other (sit-for 0) trick?

>>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

Lars> Hrvoje Niksic <hniksic@srce.hr> writes:
Hrvoje> What exactly bug is this?  I am refering to the docstring of
Hrvoje> gnus-xmas-force-redisplay:
Hrvoje> 
Hrvoje> If non-nil, force a redisplay before recentering the summary buffer.
Hrvoje> This is ugly, but it works around a bug in `window-displayed-height'.
Hrvoje> 
Hrvoje> I've had this set to nil for quite awhile, and have observed no
Hrvoje> incorrect behaviour.  How exactly does this bug manifest, and in what
Hrvoje> way is window-displayed-height incorrect?

Lars> It's a bit tricky to reproduce, but I was able to reproduce it
Lars> consistently with XEmacs 19.14 using a particular Gnus window config.

Lars> Let's say you have:

Lars> ----
Lars> Win1
Lars> ----
Lars> Win2
Lars> ----
Lars> Win3
Lars> ----

Lars> And then you change the window config to:

Lars> ----
Lars> Win2


Lars> ----
Lars> Win3
Lars> ----

Lars> Before the redisplay, `window-displayed-height' would report the
Lars> previous Win2 window height.  A `(sit-for 0)' before the
Lars> `window-displayed-height' would result in the right value being
Lars> returned. 

Lars> I haven't tried any of this with the new betas.

-- 
  -mb-

