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

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

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)
(screen is fully redrawn)
(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: