bug#71763: [PATCH] Inconsistency in bitmap overlay drawing for macOS

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Daniel Pettersson <daniel@dpettersson.net>,  71763@debbugs.gnu.org
> Date: Sun, 27 Oct 2024 14:23:49 +0100
> 
> > Thanks, but maybe Gerd (CCed) will agree to look at this?
> 
> The struct draw_fringe_bitmap_params is not documented very well, so
> I've looked at fringe.c for what its overlay_p member means. I landed in
> draw_fringe_bitmap_1, where draw_fringe_bitmap_params::overlay_p is set
> if that function is called with an overlay parameter that fits some
> criterion, which one can try to figure out in its caller
> draw_fringe_bitmap. It apparently has something to do with drawing a
> cursor in a fringe, and then also drawing an overlay arrow.

Thanks for taking a look.

> Didn't even know until a few minutes ago that the cursor can land in
> the fringe.

See overflow-newline-into-fringe.  It was added in Emacs 22 (and is ON
by default, as you can see by typing enough characters on a line and
ending the line with a newline, such that the last character before
the newline fits completely on the screen line).

> And I'm wondering if that ever happens in the left fringe,

It can, if the window shows RTL text, which starts at the right edge
of the window.

> and/or if the overlay arrow appears only on the left.

In an RTL buffer, the arrow should appear on the right.

> Anyway. Assuming that I read the code correctly, that we are drawing a
> cursor and overlay arrow on top of each other, then I think Daniel's
> patch makes sense, because drawing the overlay arrow should not clear
> under it and erase what was drawn for the cursor before.
> 
> That's about what I could find out. NS should do something different if
> overlay_p is set or not, I think that's for sure. And if Daniel says it
> works, that's goog enough for me I guess.

Thanks.  If possible, can you also tell what the current code does
wrong, that this patch fixes?