>>>> "kkm" == Kirill 'Big K' Katsnelson
<kkm(a)dtmx.com> writes: 
    kkm> Some time ago, Stephen J. Turnbull wrote...
> I don't understand; the check at l. 6457 looks OK.  Comment
in
> redisplay_frame() indicates this is intentional.  Or do you
> just mean all frames on the current device?  That's bad enough
> to justify this patch, though. 
    kkm> Stephen, what comment are you referring to? 
There's a comment at line 6281
  if (preemption_check)
    {
      /* The preemption check itself takes a lot of time,
	 so normally don't do it here.  We do it if called
	 from Lisp, though (`redisplay-frame'). */
      int preempted;
      REDISPLAY_PREEMPTION_CHECK;
      if (preempted)
	return 1;
    }
An identical check is done in redisplay_device() at l 6457, basically
the first thing that redisplay_device() does:
  REDISPLAY_PREEMPTION_CHECK;
  if (preempted)
    return 1;
    kkm> I may have modified the file, so line numbers are off.
The lines in your patch were exact, so I assumed redisplay.c is the
same in 21.4.3 and 21.5 (the above excerpts are from 21.4.3).
    kkm> because there was obvious nonsense in the above lines:
As I say, it appears to be intentional.  A misjudgement, I think after
light testing, but intentional.
    kkm> r_f() never gets preempted, and thus never returns non-zero when
    kkm> its second parameter equal 0.
    kkm> That is, preemption never happened!  CVS revision 1.1.1.1,
    kkm> the oldest one, also has the preemption check turned off.
AFAICT it happens once per call of redisplay_device().
> Maybe you should post patches of this type to xemacs-beta?
    kkm> What I meant by testing was that I wanted everybody to keep
    kkm> an eye open on glitches in display appearance.
Oh I understood that.  What I meant is that "count(everybody)" is a
lot bigger on xemacs-beta.  Everybody on xemacs-beta (pretty much) can
read patches; with that and the description they can probably give it
a lot more thorough workout than the few on xemacs-review.
Especially with the commit-for-review policy, it's important to keep
the testers aware of changes where the developers don't fully
understand the consequences.
    kkm> Thank you for checking it, in any case!
I'm in swap now, and VM still seems faster.  :-)  I like this patch, a
lot!
-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."