Re: Emacs Mac port

[Eli Zaretskii]

> Date: Mon, 15 Apr 2013 16:59:31 +0900
> From: YAMAMOTO Mitsuharu <address@hidden>
> Cc: address@hidden
> 
> >>>>> On Mon, 15 Apr 2013 08:44:04 +0300, Eli Zaretskii <address@hidden> said:
> 
> > I wish that platform-specific display tricks would not abuse
> > platform-independent display mechanisms in this way.  I mean, making
> > the window edges round by triggering expose events as result of
> > previous redisplay.  Can't this be done in the Mac display back-end
> > instead?
> 
> 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.

> 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.

> > While adding a flag to the glyph matrix looks like a no-brainer at
> > first sight, doing so for a benefit of a single platform is
> > something that at the very least should be heavily commented
> > (including the above sequence).  Otherwise, a few years from now,
> > when this issue is no longer relevant, how can we even start
> > thinking whether this flag is still needed or not?
> 
> 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.

> >  . what about the same flag of the desired_matrix -- should it be
> > cleared explicitly, and if so, where?
> 
> The same question probably applies to the existing `begv' and 'zv'
> members of `struct glyph_matrix': they are meaningful/used only for
> the current matrix and never cleared.

Those members are only tested to see whether the last redisplay cycle
ran to completion, and whether the displayed buffer changed behind
redisplay's back.  A stale value here can at worst cause redundant
redisplays.  By contrast, the flag you are suggesting, if stale, will
cause the cursor be redrawn incorrectly, IIUC.

> If someone proposes more appropriate way and/or place to record the
> status of the cursor so that the subsequent "expose" handler call can
> recover the result of previous redisplay, I would really appreciate
> it.

I'm still interested to know why this cannot be handled in the Mac
specific display back-end code.