Redisplay bug in latest CVS

Redisplay bug in latest CVS

[Kim F. Storm]

This is with latest CVS emacs on GNU/Linux 2.4 (redhat 7.2)
with Xfree 4.(something) running under X:

Save this file in x.c:

-------------------------------------------------
f()
{
  switch (a)
    {
    case 1:
		break;
    case 1:
		break;
    }
}
------------------------------------------------

[Notice that the "break;" lines are indented by two TABs].

Start emacs -q and do C-x C-f x.c RET

Now move the cursor _below_ the space in "case 1:", ie.

    case 1:
	X	      break;
here....^

Hit TAB.

The screen now looks like (cursor is on the `b'):

    case 1:
      br ak;
?.......^

Doing C-l brings back the missing `e'.


My guess is that if the cursor was on a TAB, the position
occupied by that TAB will be left blank after redisplay.

To see this, indent the "break;" by "TAB SPACE TAB" and
put the cursor on the SPACE and press TAB => correct redisplay.

.. but there must be more to it than that.

I don't have time to investigate this further right now.

-- 
Kim F. Storm  <storm@cua.dk>      http://www.cua.dk

[FOUND CAUSE] Redisplay bug in latest CVS

[Kim F. Storm]

"Kim F. Storm" <storm@cua.dk> writes:

> 
> Now move the cursor _below_ the space in "case 1:", ie.
> 
>     case 1:
> 	X	      break;
> here....^
> 
> Hit TAB.
> 
> The screen now looks like (cursor is on the `b'):
> 
>     case 1:
>       br ak;
> ?.......^
> 
> Doing C-l brings back the missing `e'.

I've tracked this bug down to a problem with x_erase_phys_cursor.

When it calls get_phys_cursor_glyph to get the glyph under the (old)
cursor, the contents of w->phys_cursor.hpos is 1 - corresponding to
the character position of the TAB the cursor was on before hitting
tab... but in the updated line, row->glyphs[][1] contains a SPACE --
so that is what x_erase_phys_cursor prints to erase the old cursor.

I'm not quite sure whether this is really the problem, or whether
some earlier code should have cleared w->phys_cursor_on_p (in
case the cursor position has been written over -- which it has
been in this case -- but that may not be true in other cases).

There are more places in the code where w->phys_cursor.hpos
is compared to row->used[TEXT_AREA] ... which seems completely
bogus to me, as hpos does not in any way take the width of
the old and new glyphs in the line into account.
To me, it seems better to compare w->phys_cursor.x
to row->x + row->pixel_width, but that doesn't account for
the widths of the old and new character(s) that were / will be
displayed at that position.

I'll try to work out a proper fix for this.  Any ideas will
be appreciated...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [FOUND CAUSE] Redisplay bug in latest CVS

[Gerd Moellmann]

storm@cua.dk (Kim F. Storm) writes:

> I'm not quite sure whether this is really the problem, or whether
> some earlier code should have cleared w->phys_cursor_on_p

I think that should be the case.  Normally, bugs aside, the flag
should have been cleared.

Re: Redisplay bug in latest CVS [FIXED]

[Kim F. Storm]

"Kim F. Storm" <storm@cua.dk> writes:

> This is with latest CVS emacs on GNU/Linux 2.4 (redhat 7.2)
> with Xfree 4.(something) running under X:
> 
> Save this file in x.c:
> 
> -------------------------------------------------
> f()
> {
>   switch (a)
>     {
>     case 1:
> 		break;
>     case 1:
> 		break;
>     }
> }
> ------------------------------------------------
> 
> [Notice that the "break;" lines are indented by two TABs].
> 
> Start emacs -q and do C-x C-f x.c RET
> 
> Now move the cursor _below_ the space in "case 1:", ie.
> 
>     case 1:
> 	X	      break;
> here....^
> 
> Hit TAB.
> 
> The screen now looks like (cursor is on the `b'):
> 
>     case 1:
>       br ak;
> ?.......^
> 
> Doing C-l brings back the missing `e'.
> 


I have committed a fix for this problem (to xterm.c).

I suspect that the fix should be merged to w32term.c and
macterm.c, but I haven't got any indications of whether
the problem exists on those platforms.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk