emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#9771: closed (24.0.90; Redisplay problems with con


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#9771: closed (24.0.90; Redisplay problems with control characters)
Date: Wed, 19 Oct 2011 11:52:01 +0000

Your message dated Wed, 19 Oct 2011 13:49:54 +0200
with message-id <address@hidden>
and subject line Re: bug#9771: 24.0.90; Redisplay problems with control 
characters
has caused the debbugs.gnu.org bug report #9771,
regarding 24.0.90; Redisplay problems with control characters
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
9771: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9771
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 24.0.90; Redisplay problems with control characters Date: Mon, 17 Oct 2011 00:24:30 +0200 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)
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



--- End Message ---
--- Begin Message --- Subject: Re: bug#9771: 24.0.90; Redisplay problems with control characters Date: Wed, 19 Oct 2011 13:49:54 +0200
> From: Johan Bockgård <address@hidden>
> Cc: address@hidden,  address@hidden
> 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.



--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]