text in minibuffer often fails to display
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| emacs23 (Ubuntu) |
Undecided
|
Unassigned |
Bug Description
Commands that use the minibuffer and that display a prompt (e.g., C-x C-f to find file) often do not fully display their prompt text, although the text is present as far as emacs is concerned. That is, the text isn't displayed, but the blinking cursor has advanced correctly, and if I don't look, the behavior is correct. It is usually enough to kill and yank the text to make it visible (C-a C-k C-y).
This seems not seem to occur when the window is maximized.
ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: emacs (not installed)
ProcVersionSign
Uname: Linux 3.0.0-15-generic x86_64
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
Date: Sat Jan 28 16:00:50 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
ProcEnviron:
PATH=(custom, user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: emacs23
UpgradeStatus: Upgraded to oneiric on 2012-01-09 (19 days ago)
Jeff Abrahamson (jeff-purple) wrote : | #1 |
Jeff Abrahamson (jeff-purple) wrote : | #2 |
I had been launching emacs via "emacs -fn 9x15". Even "emacs -fn 9x15 -q" exhibits this bug for me. Removing the font selection either works around or at least substantially reduces incidence of this bug.
For documentation, today I am using 23.3.1:
jeff@london:~ $ emacs --version
GNU Emacs 23.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
jeff@london:~ $
It happens less when maximized, but it turns out it does happen some.
It happens less (or maybe not at all) on my Acer 1410 netbook than on the machine from which I reported the bug. On that host, I sometimes see drawing errors (i.e., missing glyphs) even in the main buffers.