GNU bug report logs - #71866
30.0.50; [macOS] Cursor hiding char behind it with certain theme customization

Previous Next

Package: emacs;

Reported by: Dmitry Gutov <dmitry <at> gutov.dev>

Date: Mon, 1 Jul 2024 03:15:02 UTC

Severity: normal

Found in version 30.0.50

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 71866 <at> debbugs.gnu.org
Subject: Re: bug#71866: 30.0.50; [macOS] Cursor hiding char behind it with
 certain theme customization
Date: Sat, 06 Jul 2024 11:56:10 +0300
> Date: Tue, 2 Jul 2024 04:07:11 +0300
> Cc: 71866 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> On 01/07/2024 14:36, Eli Zaretskii wrote:
> > On other platforms, the code which draws the cursor is in draw_glyphs,
> > called from XXX_draw_window_cursor function (where XXX is the GUI
> > backend, in your case probably XXX = ns).  If the same is true on
> > macOS, you could try stepping through that code.
> 
> I can try following some more detailed instructions. I.e. I can set up a 
> breakpoint, but would there be anything to look out for when stepping 
> through the code?

For starters, put a breakpoint in ns_draw_window_cursor and see if it
gets called in the scenario where you see the problem.

If it does get called, it should call draw_phys_cursor_glyph in this
case (because the cursor type is FILLED_BOX_CURSOR).  If it calls that
function, step through it.  You should see there that it calls
draw_glyphs to draw the single character under the cursor.  The actual
drawing happens here:

  /* Draw all strings.  */
  for (s = head; s; s = s->next)
    FRAME_RIF (f)->draw_glyph_string (s);

where the draw_glyph_string method is a function in nsterm.m,
ns_draw_glyph_string.  AFAICT, it should draw a character with the
foreground taken from the frame's background color and background
color taken from the cursor color.

Something in this chain of calls doesn't happen in the scenario which
shows the problem.

> BTW, this happens only right after I switch frames. Things start looking 
> right again if I simply move point.

Then step through the code after switching frames.




This bug report was last modified 326 days ago.

Previous Next


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