🚀 go-pugleaf

In GNU Emacs 19.25.92.2 (sparc-sun-sunos4shr) of Wed Aug  3 1994 on naggum.no

the x_sync loop at the end of x_make_frame_visible is causing occasional
delays when new frames are created.  special-display-buffer-frames is bound
to '("*compilation*" "*Help*")), and it sometimes takes a noticeable amount
of time from when a frame is created and displayed until it is filled with
the desired text.  "noticeable" is in the 200-500 ms range.  since this is
obviously a timing issue, I have been unable to reproduce it consistently
enough to find out if x_sync() itself is the culprit, but in the course of
searching, I noticed that Emacs will (sleep-for 1 0) or (sleep-for 0 250)
the first time through the x_sync loop.  at least this has a simple fix:

*** src/xterm.c.~1~	Tue Jul 26 23:56:48 1994
--- src/xterm.c		Wed Aug  3 03:57:02 1994
***************
*** 5684,5692 ****
       so that incoming events are handled.  */
    {
      Lisp_Object frame;
!     int one_in_four = 0;
      XSET (frame, Lisp_Frame, f);
      while (! f->async_visible)
        {
--- 5684,5692 ----
       so that incoming events are handled.  */
    {
      Lisp_Object frame;
!     int one_in_four = 1;
      XSET (frame, Lisp_Frame, f);
      while (! f->async_visible)
        {

I don't know what problem the original x_sync loop fixed, since I didn't
experience anything wrong on my system before it.  if I comment out the
code, *Help* doesn't show up in the tab for the window under twm until I do
something else, but no other problem occurs; display is fast.  I didn't
have any problems before this even over a 14.4K SLIP link, but the new
x_sync() (or the loop) adds another three seconds to the time it takes to
get a *Help* window up.  this isn't so nice.

what were the conditions under which this was necessary?  can these be
determined so that other systems without those conditions do not need the
x_sync()?

best regards,
</Erik>

--
Microsoft is not the answer.  Microsoft is the question.  NO is the answer.