GNU bug report logs - #9771
24.0.90; Redisplay problems with control characters

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Johan Bockgård <bojohan <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.90; Redisplay problems with control characters
Date: Mon, 17 Oct 2011 00:24:30 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.