Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

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

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.

> 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.  I
think it is natural and the expected behavior actually.  The current
code uses wrong information (i.e., the value of `cursor-in-echo-area'
as of "expose") in this respect.  Again, the bug itself is not
specific to a single platform.

> Also, there are several details that need to be figured out:

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

>  . should this flag of the current_matrix be cleared after the
> cursor is displayed?  If not, how can we be sure that during the
> next redisplay cycle, optimizations that bypass most of glyph matrix
> construction will not use a stale value?

>  . what if redisplay was preempted? in that case,
> set_window_cursor_after_update is not called, and the flag keeps its
> previous value even if cursor_in_echo_area has changed.

> etc., etc.

> IOW, I'm unhappy with this change, and would like much better a
> solution that doesn't affect every platform out there (including
> text-mode display, btw).

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.

                                     YAMAMOTO Mitsuharu
                                address@hidden