GNU bug report logs - #71763
[PATCH] Inconsistency in bitmap overlay drawing for macOS

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 71763 in the body.
You can then email your comments to 71763 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Daniel Pettersson <daniel <at> dpettersson.net>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Inconsistency in bitmap overlay drawing for macOS
Date: Tue, 25 Jun 2024 00:04:27 +0200

[Message part 1 (text/plain, inline)]

On macOS overlay-arrow is not draw on top of bitmaps already present
in the fringe, like its done on X Window System (src/xterm.c).  This is
to the detriment of gdb-mi.el where the overlay-arrow hides the
breakpoint when they exist on the same row.

It can be reproduced with the following:
(require 'gdb-mi)
(defvar overlay-arrow (make-marker))
(add-to-list 'overlay-arrow-variable-list 'overlay-arrow)
(setq fringe-indicator-alist '((overlay-arrow . hollow-right-triangle)))
(overlay-put (make-overlay (pos-bol) (1+ (pos-bol))) 'before-string
             (propertize " " 'display
                         `(left-fringe breakpoint warning)))
(move-marker overlay-arrow (pos-bol))

I expect that macOS is not using overlay_p param as intended as fixed by
attached patch.  But I was having an hard time finding any documentation
proving my point other then the implementation of it's X Window System
sibling in src/xterm.c.

[0001-Fix-inconsistency-in-bitmap-overlay-drawing-for-macO.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

In GNU Emacs 30.0.50 (build 1, aarch64-apple-darwin23.1.0, NS
 appkit-2487.20 Version 14.1.1 (Build 23B81)) of 2024-06-24 built on
 Daniels-Air
Windowing system distributor 'Apple', version 10.3.2487
System Description:  macOS 14.1.1

Configured using:
 'configure --with-xwidgets'

Configured features:
ACL DBUS GLIB GNUTLS LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER PNG
RSVG SQLITE3 THREADS TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM XWIDGETS
ZLIB

Message #8 received at 71763 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Pettersson <daniel <at> dpettersson.net>
Cc: 71763 <at> debbugs.gnu.org
Subject: Re: bug#71763: [PATCH] Inconsistency in bitmap overlay drawing for
 macOS
Date: Thu, 27 Jun 2024 12:35:19 +0300

> From: Daniel Pettersson <daniel <at> dpettersson.net>
> Date: Tue, 25 Jun 2024 00:04:27 +0200
> 
> On macOS overlay-arrow is not draw on top of bitmaps already present
> in the fringe, like its done on X Window System (src/xterm.c).  This is
> to the detriment of gdb-mi.el where the overlay-arrow hides the
> breakpoint when they exist on the same row.
> 
> It can be reproduced with the following:
> (require 'gdb-mi)
> (defvar overlay-arrow (make-marker))
> (add-to-list 'overlay-arrow-variable-list 'overlay-arrow)
> (setq fringe-indicator-alist '((overlay-arrow . hollow-right-triangle)))
> (overlay-put (make-overlay (pos-bol) (1+ (pos-bol))) 'before-string
>              (propertize " " 'display
>                          `(left-fringe breakpoint warning)))
> (move-marker overlay-arrow (pos-bol))
> 
> I expect that macOS is not using overlay_p param as intended as fixed by
> attached patch.  But I was having an hard time finding any documentation
> proving my point other then the implementation of it's X Window System
> sibling in src/xterm.c.

Can some macOS expert please review the proposed patch?

Message #11 received at 71763 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Pettersson <daniel <at> dpettersson.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71763 <at> debbugs.gnu.org
Subject: Re: bug#71763: [PATCH] Inconsistency in bitmap overlay drawing for
 macOS
Date: Sun, 27 Oct 2024 11:26:50 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Can some macOS expert please review the proposed patch?
Seems like they are hard to come by.

I have been using this patch since I reported the bug, how can I help
move this along?

Message #14 received at 71763 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Pettersson <daniel <at> dpettersson.net>,
 Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 71763 <at> debbugs.gnu.org
Subject: Re: bug#71763: [PATCH] Inconsistency in bitmap overlay drawing for
 macOS
Date: Sun, 27 Oct 2024 14:02:16 +0200

> From: Daniel Pettersson <daniel <at> dpettersson.net>
> Cc: 71763 <at> debbugs.gnu.org
> Date: Sun, 27 Oct 2024 11:26:50 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Can some macOS expert please review the proposed patch?
> Seems like they are hard to come by.
> 
> I have been using this patch since I reported the bug, how can I help
> move this along?

Thanks, but maybe Gerd (CCed) will agree to look at this?

Message #17 received at 71763 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71763 <at> debbugs.gnu.org, Daniel Pettersson <daniel <at> dpettersson.net>
Subject: Re: bug#71763: [PATCH] Inconsistency in bitmap overlay drawing for
 macOS
Date: Sun, 27 Oct 2024 14:23:49 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Daniel Pettersson <daniel <at> dpettersson.net>
>> Cc: 71763 <at> debbugs.gnu.org
>> Date: Sun, 27 Oct 2024 11:26:50 +0100
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Can some macOS expert please review the proposed patch?
>> Seems like they are hard to come by.
>> 
>> I have been using this patch since I reported the bug, how can I help
>> move this along?
>
> 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.

Didn't even know until a few minutes ago that the cursor can land in
the fringe. And I'm wondering if that ever happens in the left fringe,
and/or if the overlay arrow appears only on the left. Questions upon
questions, as usual.

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.

Message #20 received at 71763 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 71763 <at> debbugs.gnu.org, daniel <at> dpettersson.net
Subject: Re: bug#71763: [PATCH] Inconsistency in bitmap overlay drawing for
 macOS
Date: Sun, 27 Oct 2024 15:41:16 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Daniel Pettersson <daniel <at> dpettersson.net>,  71763 <at> 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?

Message #23 received at 71763 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71763 <at> debbugs.gnu.org, daniel <at> dpettersson.net
Subject: Re: bug#71763: [PATCH] Inconsistency in bitmap overlay drawing for
 macOS
Date: Sun, 27 Oct 2024 15:03:32 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

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

Indeed, never noticed, thanks!

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

Yeah, of course :-).

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

diff --git a/src/nsterm.m b/src/nsterm.m
index 794630de1c1..fc9133071ed 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -2961,24 +2961,28 @@ Hide the window (X11 semantics)
   NSTRACE_MSG ("which:%d cursor:%d overlay:%d width:%d height:%d period:%d",
                p->which, p->cursor_p, p->overlay_p, p->wd, p->h, p->dh);
 
-  /* Work out the rectangle we will need to clear.  */
-  clearRect = NSMakeRect (p->x, p->y, p->wd, p->h);
+  /* Clear screen unless overlay.  */
+  if ( !p->overlay_p )
+    {
+      /* Work out the rectangle we will need to clear.  */
+      clearRect = NSMakeRect (p->x, p->y, p->wd, p->h);

If I read the diff correctly, this puts the clearing under the bitmap in
an if-statement so that it is only done if we do not draw intentionally
on top something drawn before.

Right, Daniel?

Message #26 received at 71763 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Pettersson <daniel <at> dpettersson.net>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 71763 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#71763: [PATCH] Inconsistency in bitmap overlay drawing for
 macOS
Date: Tue, 29 Oct 2024 20:59:32 +0100

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> If I read the diff correctly, this puts the clearing under the bitmap in
> an if-statement so that it is only done if we do not draw intentionally
> on top something drawn before.

> Right, Daniel?

Yup, w/o this we clear fringe on draw when I we should keep it intact
and draw over.

The only example I found and the reason for this fix is that we clear
fringe of overlays before drawing overlay-arrow.  Such that breakpoint
bitmap is removed when overlay-arrow is on the same line in gdb-mi.el.

Message #29 received at 71763 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Daniel Pettersson <daniel <at> dpettersson.net>
Cc: 71763 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#71763: [PATCH] Inconsistency in bitmap overlay drawing for
 macOS
Date: Wed, 30 Oct 2024 08:11:17 +0100

Daniel Pettersson <daniel <at> dpettersson.net> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> If I read the diff correctly, this puts the clearing under the bitmap in
>> an if-statement so that it is only done if we do not draw intentionally
>> on top something drawn before.
>
>> Right, Daniel?
>
> Yup, w/o this we clear fringe on draw when I we should keep it intact
> and draw over.
>
> The only example I found and the reason for this fix is that we clear
> fringe of overlays before drawing overlay-arrow.  Such that breakpoint
> bitmap is removed when overlay-arrow is on the same line in gdb-mi.el.

From my POV, it could be installed. Eli will decide that.

Message #34 received at 71763-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 71763-done <at> debbugs.gnu.org, daniel <at> dpettersson.net
Subject: Re: bug#71763: [PATCH] Inconsistency in bitmap overlay drawing for
 macOS
Date: Sat, 02 Nov 2024 13:18:17 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  71763 <at> debbugs.gnu.org
> Date: Wed, 30 Oct 2024 08:11:17 +0100
> 
> Daniel Pettersson <daniel <at> dpettersson.net> writes:
> 
> > Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> >
> >> If I read the diff correctly, this puts the clearing under the bitmap in
> >> an if-statement so that it is only done if we do not draw intentionally
> >> on top something drawn before.
> >
> >> Right, Daniel?
> >
> > Yup, w/o this we clear fringe on draw when I we should keep it intact
> > and draw over.
> >
> > The only example I found and the reason for this fix is that we clear
> > fringe of overlays before drawing overlay-arrow.  Such that breakpoint
> > bitmap is removed when overlay-arrow is on the same line in gdb-mi.el.
> 
> >From my POV, it could be installed. Eli will decide that.

OK, thanks.  I installed this on the master branch, and I'm closing
this bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.