Yes, it is annoying and I agree that it seems that the shells output takes priority over your input. I made sure that font-lock was not on in case it was a regexp problem (actually I don't use font-lock in shell-mode ever). I looked at the 20.4 shell.el and the new package style shell.el and there isn't that much difference. If, from a shell buffer, I rlogin into another box I can break a program right away. If I exit the rlogin, the bad behaviour returns. I am guessing that since shell is on the same box the pipes are treated different than a pipe to a different machine. This could be a change to the process C code in XEmacs or it can be a un?x issue. ================================ Rodney Stromlund Southwest Airlines Co. Systems Department Sales & Revenue Accounting Group mailto:rstromlu＠wnco.com (214) 792-6484 ================================ On Wed, 28 Jul 1999, Rodney Stromlund wrote: That happens to me too, and it is really annoying. My guess is that input is arriving too fast for xemacs to process the input, making xemacs the bottleneck. Then, maybe X events are not handled while there is non-X pipe input to process. Maybe include display updates in there somewhere. Maybe non-X input is being considered a higher priority than X input and/or X display refresh has very low priority. I think both may be true. Maybe the process-input path is shorter in those modes? Does telnet do fontification? Maybe it can be turned off in shell modes to at least help with the input flood? -Justin vallon(a)mindspring.com