bug#8874: Redisplay confusion in Info, due to recentering fix

bug#8874: Redisplay confusion in Info, due to recentering fix

[Chong Yidong]

Recipe to reproduce:

emacs -q
M-: (setq scroll-conservatively 300) RET
C-h i
m CC mode RET
C-s k&r
C-s C-s C-s C-s

Emacs redisplay now shows a garbage window with no cursor.  C-l redraws
the window correctly.

This is caused by the recentering changes from March (revision 103792).
Reverting it eliminates the bug.

bug#8874: Redisplay confusion in Info, due to recentering fix

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Wed, 15 Jun 2011 16:22:34 -0400
> 
> Recipe to reproduce:
> 
> emacs -q
> M-: (setq scroll-conservatively 300) RET
> C-h i
> m CC mode RET
> C-s k&r
> C-s C-s C-s C-s
> 
> Emacs redisplay now shows a garbage window with no cursor.  C-l redraws
> the window correctly.

Confirmed.

How urgent is it to fix this?  Can it be postponed until I'm done with
bidi reordering of display strings, and we enter code freeze?

bug#8874: Redisplay confusion in Info, due to recentering fix

[Stefan Monnier]

> bidi reordering of display strings, and we enter code freeze?

Feature freeze is close, but code freeze is still far.


        Stefan

bug#8874: Redisplay confusion in Info, due to recentering fix

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Chong Yidong <cyd@stupidchicken.com>,  8874@debbugs.gnu.org
> Date: Thu, 16 Jun 2011 22:58:57 -0400
> 
> > bidi reordering of display strings, and we enter code freeze?
> 
> Feature freeze is close, but code freeze is still far.

So is it a yes or a no to my question?

bug#8874: Redisplay confusion in Info, due to recentering fix

[Stefan Monnier]

>> > bidi reordering of display strings, and we enter code freeze?
>> Feature freeze is close, but code freeze is still far.
> So is it a yes or a no to my question?

I think it's OK to delay bug-fixing in order to get the missing
bidi-features installed sooner.


        Stefan

bug#8874: Redisplay confusion in Info, due to recentering fix

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> How urgent is it to fix this?  Can it be postponed until I'm done with
> bidi reordering of display strings, and we enter code freeze?

The bidi work is more urgent, so feel free to postphone the fix for this
until you have the time.

FWIW, I took a quick look, and it appears that the following should do
the trick.  But it can wait till you have time to double-check the code.

*** src/xdisp.c	2011-06-14 18:57:19 +0000
--- src/xdisp.c	2011-06-18 18:03:55 +0000
***************
*** 14391,14397 ****
  	      if (pt_offset)
  		centering_position -= pt_offset;
  	      centering_position -=
! 		FRAME_LINE_HEIGHT (f) * (1 + margin + (last_line_misfit != 0));
  	      /* Don't let point enter the scroll margin near top of
  		 the window.  */
  	      if (centering_position < margin * FRAME_LINE_HEIGHT (f))
--- 14391,14397 ----
  	      if (pt_offset)
  		centering_position -= pt_offset;
  	      centering_position -=
! 		FRAME_LINE_HEIGHT (f) * (2 + margin + (last_line_misfit != 0));
  	      /* Don't let point enter the scroll margin near top of
  		 the window.  */
  	      if (centering_position < margin * FRAME_LINE_HEIGHT (f))

bug#8874: Redisplay confusion in Info, due to recentering fix

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: 8874@debbugs.gnu.org
> Date: Sat, 18 Jun 2011 14:07:10 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How urgent is it to fix this?  Can it be postponed until I'm done with
> > bidi reordering of display strings, and we enter code freeze?
> 
> The bidi work is more urgent, so feel free to postphone the fix for this
> until you have the time.
> 
> FWIW, I took a quick look, and it appears that the following should do
> the trick.  But it can wait till you have time to double-check the code.

The problem was with the header line that Info uses by default, and
which was not accounted for when computing the new window start
position.  (If you set Info-use-header-line to nil, the bug goes
away.)

I fixed (in trunk revision 105541) the calculation of the window start
to account for the header line when it's present, and that solves the
bug.

Thanks.