>> Charles Hines(C) wrote on Tue, 3 Oct 1995 09:31:09 -0400:
>>>>>> "mb" == Mark Borges <mdb_at_cdc.noaa.gov> writes:
mb> I've just noticed some lossage using XEmacs-19.14b3 and
mb> fvwm-2pl35. If anyone has a similar combination, can you please
mb> verify or discount the following?
mb> After selecting the Restart option of fvwm (Restart fvwm), XEmacs
mb> redisplay of minibuffers is lost. \C-x\C-f doesn't echo in the
mb> minibuffer, and cursor movement keys do not appear to
mb> work. Fortunately, the (blind) input is still recognized so that I
mb> can \C-x 5 2 to get a new frame which works.
mb> Actually, the above happens with XEmacs-19.13 as well, so I'm
mb> inclined to think it's a problem with fvwm-2pl35.
mb> Does anyone else see this behavior after an fvwm Restart?
C> I just noticed something like this yesterday, actually, except for me
C> it was a big chunk of the XEmacs frame that was blanked out (the whole
C> lower & left hand quadrant). I haven't looked into it yet.
Just as another datum point ( :-) data points? ), I found that I get
the same problem using fvwm-2pl31.
However, I've also had personal e-mail indicating the problem does not
exist with XEmacs-19.11, though I don't know the platform/fvwm version
combination for this latter report. This prompted me to test
XEmacs-19.11 under fvwm-2pl35 here (Solaris-2.3), and I can verify it
works correctly. Unfortunately XEmacs-19.12 is not available to test
here anymore.
So, the problem appears to be related to the (more) hairy handling of
X and/or X events in XEmacs, if not an XEmacs bug itself.
This would be nice to fix (in either fvwm or XEmacs) but if time
pressures don't permit a fix, perhaps a note should be put in a BUGS
file in fvwm. I'd bet a lot of people are moving to XEmacs-19.13 or
later...
-mb-
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Tue Oct 03 1995 - 11:23:53 BST