Re: Emacs Mac port

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

>>>>> On Mon, 15 Apr 2013 11:55:34 +0300, Eli Zaretskii <eliz@gnu.org> said:

>> No, it's not an abuse at all.  Invalidating the area that needs to
>> be updated and let the "expose" handler draw is a very standard
>> (sometimes only) way of drawing even on GTK+.

> I was talking specifically about invalidating fractions of screen
> lines (a.k.a. "glyph rows").

> I'm still interested to know why this cannot be done entirely in the
> display back-end.

I'm using the "expose" handler for recovering the display contents
through invalidation, because that is really what it is for.

On Mac, the "expose" handler is called in many situations than you
might expect including outside the control of application code: e.g.,
creating a snapshot of the window image for icons or "Exposé"
(http://support.apple.com/kb/HT2503).  I'm not sure about other
platforms/toolkits, but I wouldn't be surprised if similar things
happen there for providing some fancy features.  Nowadays, drawing
outside the "expose" handler is exceptional and subject to several
restrictions.

>> The similar inconsistency in Emacs display can also happen on other
>> platforms in principle, depending on the timing of the "expose"
>> event.  The only difference is the invalidation happens
>> internally/actively or externally/passively.  That's why the latter
>> is difficult to reproduce.

> I suspect that triggering the event internally is the only situation
> where this can happen, because it might cause the expose event be
> delivered between two successive redisplay cycles that would
> normally take care of the change in the value of
> cursor_in_echo_area.

What about this example?

(progn
  (let ((cursor-in-echo-area t))
    (message "foo")
    (sit-for 0))
  (sleep-for 10))

If the "expose" event happen for the echo area during the execution of
sleep-for, would the cursor be correctly recovered?

>> The reason is simple: the expose handler should recover the
>> contents of the previous redisplay with respect to the requested
>> rectangle.

> And yet we don't see the result on any other platform.

You don't agree the principle for the "expose" handler above (i.e., it
should recover the contents of the previous redisplay)?  Then what is
your expected behavior of the "expose" handler?

I don't insist my patch is correct.  But I'd say the current behavior
is wrong and the fix should be done in the platform-independent part
rather than in the code for a particular platform where the problem
happens to easily emerge.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp