I experience a similar phenomenon to what Andrew Cooper recently reported. In my case, the VirtualBox version is 4.3.20 r96997; the host is Windows 8.1; the guest is Debian Wheezy:
$>uname -a Linux vm-wheezy-amd64 3.16.0-0.bpo-4-amd64 #1 SMP Debian 3.16.7-ckt2-1~bpo70+1 (2014-12-08) x86_64 GNU/Linux I can reliably reproduce redraw failures using /usr/bin/emacs (GNU Emacs 23.4.1, according to "emacs --version") when editing source code files, simply using page up, page down, ESC >, and ESC <. The failure to redraw is always fixable via ctrl-l (lower-case ell). When editing a certain file, the same sequence of keystrokes after invoking "emacs -nw filename.txt" appears to lead to the same redraw each time, for example: Invoke "emacs -nw filename.txt" (a 151-line file I happen to be editing at the moment, but this bug is reproducible with files containing arbitrary content of sufficient length to require screen repaints during file navigation) ESC > (screen is fully redrawn) ESC < (on all ten attempts when invoking this sequence of actions, only the last seven lines were redrawn at this point -- all lines above those last seven lines remain unchanged) At this point, an immediate ctrl-l (ell) will redraw the entire screen. Alternatively, subsequent manipulation of the buffer shows that it is a repaint issue rather than internal buffer corruption within emacs. This failure to redraw exhibits whether I use TERM=xterm-256color or TERM=linux from within the xterm. Furthermore, following the gist of https://wiki.debian.org/SimpleBackportCreation, I just rolled my own xterm upgrade to 312 (current jessie) from 278 (current wheezy) and installed it. Despite a full shutdown and reboot of the wheezy VM, the same redraw failures occur. Dave Gomboc -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ca+dwz-05xg3axpmihqwv0uy7vgqdn717d_7jejkz09t_zhq...@mail.gmail.com
