Pete Forman writes:
>
> I'm still using 2.0.43 and occasionally see your symptoms. My
> workaround is to iconify and deiconify the XEmacs windows. At this
> stage it is apparent that that XEmacs had acted on the input but that
> no output had happened (or maybe the input was queued somewhere).
I use xemacs. I had this problem under 2.0.43. It seems to be better
since 2.0.44. I can't say that it's fixed, as I've only used .44 for
two days. I _can_ say that it _appears_ to be much worse (ie., happen
more often) when I have tkGoodStuff running (as a module). I've
stopped using tkGoodStuff (for other reasons), and it has not happened
as often (even under .43). One clue to this is that I was using a
win95-style taskbar config with tkGoodStuff, and also had a FvwmPager
running. I don't know if tkGoodStuff launches its own FvwmPager, but
might there be a problem with two pagers running?
>
> Should anyone be interested I see two other problems with XEmacs. In
> Ediff the controlling window is often too big. Sometimes hitting ?
> twice (making the box "larger", then "normal" again) will fix it. It
> looks like there is some sort of race condition.
Noticed this one also.
>
> The second was reported by me on 29 Oct 1996. XEmacs is initially
> slow and may misinterpret a single mouse click as multiple. Switching
> to and from twm works around the problem.
Havn't seen this, but I don't have much to compare it with. I can
only compare my linux/fvwm system to an HP /712, but the two systems
are substantially different (ie., the HP does only 8 bpp, the linux
system does 16, etc.)
- Jim
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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 Jan 21 1997 - 08:54:22 GMT