Re: Emacs terminal corruption in Debian virtualbox guests
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
Reply to: