Cursor disappears on C-d

[William Brower]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing
list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.1.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2001-10-31 on monkeyboy.kmr.ll.mit.edu
Important settings:
  value of $LC_ALL: C
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Original bug report claimed the following:

---begin---
Hello. This is an interesting bug.  Amazing as it sounds,
if you put your cursor here ------^ on the above line
and hit C-d, the cursor disappears.  Strangely, it only
seems to occur if a sentence starts with 'A' and there are
two spaces between the '.' and the 'A'. 
----end----

I've since done some more experimentation.

1)
The bug is not present with 'emacs -q --no-site-file' but only because
'blink-cursor-mode' is set to 't' by default.  If I start emacs with
'-q --no-site-file' then turn off blink-cursor-mode, the bug
reappears. Actually, even if blink-cursor-mode is 't', there is an
elongated pause during which time the cursor is absent after the
deletion sequence in that special location compared with any other.

2)
I've traced the problem to the following line in my .Xdefaults file:

emacs*font: -adobe-courier-medium-r-*-*-14-*-*-*-*-*-*-*

Commenting that line (and re-loading with 'xrdb --load .Xdefaults')
makes the bug go away.

I can also reproduce the bug (subject to (1) above) after clearing
out my .Xdefaults completely and then typing:
% emacs -q --no-site-file --font
"-adobe-courier-medium-r-*-*-14-*-*-*-*-*-*-*"


3)
The bug occurs on only one of two machines runing emacs version
21.1.1. (both have same version of .Xdefaults)
Then, assuming 'machB' is machine with Bug and 'machN' is with No bug:

machB% emacs -q --no-site-file     # I see the problem (subject to (1)
above)

machN% emacs -q --no-site-file     # No problem

machB% export DISPLAY=machN:0
machB% emacs -q --no-site-file     # No problem

machN% export DISPLAY=machB:0
machN% emacs -q --no-site-file     # I see the problem (subject to (1)
above)

So, it appears to be an "X"/font problem on 'machB'?
It is not an important bug (to me) but what else could should I check
to help? Here are some machine details....


machB% uname -a
Linux machB.my.domain 2.4.2-2smp #1 SMP Sun Apr 8 20:21:34 EDT 2001 i686
unknown

machB% XFree86 -version

XFree86 Version 4.0.3 / X Window System
(protocol Version 11, revision 0, vendor release 6400)
Release Date: 16 March 2001
        If the server is older than 6-12 months, or if your card is
        newer than the above date, look for a newer version before
        reporting problems.  (See http://www.XFree86.Org/FAQ)
Operating System: Linux 2.2.17-8smp i686 [ELF] 
Module Loader present


machN% uname -a
Linux machN.my.domain 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686
unknown
machN% XFree86 -version

XFree86 Version 4.0.3 / X Window System
(protocol Version 11, revision 0, vendor release 6400)
Release Date: 16 March 2001
        If the server is older than 6-12 months, or if your card is
        newer than the above date, look for a newer version before
        reporting problems.  (See http://www.XFree86.Org/FAQ)
Operating System: Linux 2.2.17-8smp i686 [ELF] 
Module Loader present


4) 
Not too surprsingly, the bug does not occur with
% emacs -nw