bug#9771: 24.0.90; Redisplay problems with control characters

[Eli Zaretskii <eliz@gnu.org>]

> From: Johan Bockgård <bojohan@gnu.org>
> Date: Mon, 17 Oct 2011 00:24:30 +0200
> 
> 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.

Okay, but what is the practical problem with this?

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

It's not the display vectors in general that cause this.  It's
specifically the display of control characters.  E.g., the following
test case, which is a small variation of yours, shows no visible
slowdown:

  emacs -Q
  M-: (require 'disp-table) RET
  M-: (aset standard-display-table ?x (vconcat "^A")) RET
  C-u 2000 x
  M-<
  Type text...

I'll look into this, but is there some real-life use case behind your
recipe?  Binary nulls in a file generally cause Emacs to make the
buffer unibyte, where bidi reordering is disabled.  If some
optimizations are in order to speed up redisplay in this situation, it
would help to have a real-life use case handy, to make sure the
optimizations really make a difference.

The other parts of the report are more or less clear.

Btw, in the future please make a separate bug report for each issue,
it makes references to bugs in log messages more straightforward.

Thanks.