Subject: bug#9771: closed (Re: bug#9771: 24.0.90; Redisplay problems with control characters)

From: [email-masked] (GNU bug Tracking System)
Date: Wed, 19 Oct 2011 11:52:01 +0000

Your bug report

#9771: 24.0.90; Redisplay problems with control characters

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
9771: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9771
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#9771: 24.0.90; Redisplay problems with control characters
From: Eli Zaretskii <[email-masked]>
To: Johan Bockgård <[email-masked]>
Cc: [email-masked]
Date: Wed, 19 Oct 2011 13:49:54 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

> From: Johan Bockgård <[email-masked]>
> Cc: [email-masked],  [email-masked]
> Date: Wed, 19 Oct 2011 03:06:09 +0200
> 
> emacs -Q
> 
> C-u 2000 C-q 0 RET
> 
> Notice that the lines visible in the window start with "@^".
> 
> Press <up> until the top of the buffer just scrolls into view.
> 
> Notice that lines before point start with "^@", and lines after
> point start with "@^".

Thanks for the test case.

> Change BUFFER_POS_REACHED_P (or something) so that dpvec_index == 0 is
> an acceptable stop position and this problem doesn't happen.

I'm not sure a change in BUFFER_POS_REACHED_P is the right fix for
this particular problem.  Even if it is, I'm reluctant to make in
move_it_in_display_line_to a change that could have effect in many
unrelated places, since this function is such a central piece of the
display engine.  I'd rather make a change that targets this specific
problem, certainly while we are in a pretest.

I think I found such a change.  The problem is that when we start a
new redisplay cycle of a window, we begin drawing the window's first
line at the last glyph of the display vector used to display the first
character position visible in the window.  I made a simple change that
should fix this (in revision 106131), please see if it resolves the
issue.

Another problem I found was that one of the redisplay optimizations
would redraw too few lines of a window, when the last redrawn line
ends in glyphs from a display vector.  I fixed that in revision
106133.

With all the 4 parts of the original report being addressed now, I'm
closing this bug report.  If there are any left-overs, please submit
separate bug reports about them.

Thanks.

Subject: 24.0.90; Redisplay problems with control characters
From: Johan Bockgård <[email-masked]>
To: [email-masked]
Date: Mon, 17 Oct 2011 00:24:30 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

There are several redisplay problems with control characters
(GET_FROM_DISPLAY_VECTOR method).

1. Abort in move_it_by_lines (with bidi)

emacs -Q
C-u 2000 C-q 0 RET
M-<
M->

Fatal error (6)Aborted (core dumped)

(gdb) bt
#0  abort () at emacs.c:385
#1  0x0000000000451a48 in move_it_by_lines (it=0x7fffffffc620, dvpos=0)
    at xdisp.c:8907
#2  0x00000000004c0717 in Frecenter (arg=10) at window.c:5107
#3  0x000000000060ce90 in Ffuncall (nargs=<optimized out>, args=0x7fffffffd460)
    at eval.c:2974
[...]

The following assertion fails:

  [move_it_by_lines]

    if (dvpos == 0)
      {
        /* DVPOS == 0 means move to the start of the screen line.  */
        move_it_vertically_backward (it, 0);
        xassert (it->current_x == 0 && it->hpos == 0);

(gdb) p it->current_x
$1 = 10
(gdb) p it->hpos
$2 = 1

The non-zero values for it->hpos and it->current_x come from move_it_to
in this piece of code:

 [move_it_vertically_backward]

    /* The above code moves us to some position NLINES down,
       usually to its first glyph (leftmost in an L2R line), but
       that's not necessarily the start of the line, under bidi
       reordering.  We want to get to the character position
       that is immediately after the newline of the previous
       line.  */
    if (it->bidi_p && IT_CHARPOS (*it) > BEGV
        && FETCH_BYTE (IT_BYTEPOS (*it) - 1) != '\n')
      {
        EMACS_INT nl_pos =
          find_next_newline_no_quit (IT_CHARPOS (*it) - 1, -1);

        move_it_to (it, nl_pos, -1, -1, -1, MOVE_TO_POS);
      }

2. (Old) problem in BUFFER_POS_REACHED_P

The position hpos = 1 above is not just non-zero; it's also in the
middle of the ^@ control character (the screen line starts with ^). It's
produced by move_it_in_display_line_to:

    #define BUFFER_POS_REACHED_P()                                  \
    [...]
       && (it->method == GET_FROM_BUFFER                            \
           || (it->method == GET_FROM_DISPLAY_VECTOR                \
               && it->dpvec + it->current.dpvec_index + 1 >= it->dpend)))

According to the condition above, the position in column 0 before the
^ glyph (dpvec_index = 0) is not a possible stop point, but the position
between ^ and @ is.

Cf. in_display_vector_p:

    /* Return 1 if IT points into the middle of a display vector.  */
    in_display_vector_p (struct it *it)
    {
      return (it->method == GET_FROM_DISPLAY_VECTOR
              && it->current.dpvec_index > 0
              && it->dpvec + it->current.dpvec_index != it->dpend);
    }

3. Long lines with display vectors make Emacs really slow (with bidi)

emacs -Q
C-u 2000 C-q 0 RET
M-<
Type text...

4. Abort in push_display_prop

emacs -Q

(setq wrap-prefix "x")

C-u 100 C-q 0 RET

Fatal error (6)Aborted (core dumped)

(gdb) bt
#0  abort () at emacs.c:385
#1  0x0000000000477316 in push_display_prop (it=0x7fffffff8cd0, prop=24535585)
    at xdisp.c:18432
#2  0x0000000000477857 in handle_line_prefix (it=0x7fffffff8cd0)
    at xdisp.c:18536
#3  0x00000000004782d4 in display_line (it=0x7fffffff8cd0) at xdisp.c:18802

  xassert (it->method == GET_FROM_BUFFER
	   || it->method == GET_FROM_STRING);

(gdb) p it->method 
$1 = GET_FROM_DISPLAY_VECTOR