GNU bug report logs - #32932
27.0.50; render bugs on macOS Mojave

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: alan <at> idiocy.org, 32932 <at> debbugs.gnu.org, boris <at> d12frosted.io
Subject: bug#32932: 27.0.50; render bugs on macOS Mojave
Date: Sat, 03 Nov 2018 20:17:57 +0200

> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Sat, 3 Nov 2018 10:56:14 -0700
> Cc: alan <at> idiocy.org, boris <at> d12frosted.io, 32932 <at> debbugs.gnu.org
> 
> > Doesn't the latest GDB compile on macOS? I thought it did, but
> > perhaps that's only available in the GDB Git repo. 
> 
> It does, it just doesn’t recognize emacs as a valid binary. I’ve tried out a patch that’s supposed to help with
> that, but it didn’t work. I’ve give these instructions a shot: https://stackoverflow.com/a/24918436/11229 and no
> luck. I’ve tried for hours and cannot get GDB with emacs on Mojave. I have gdb working with other built
> programs (like gdb itself), but when attempting to run emacs, I either get the code signing error:
> 
> Starting program: /Users/aaronjensen/Source/emacs/src/emacs
> Unable to find Mach task port for process-id 9979: (os/kern) failure (0x5).
> 
> (I’ve code signed gdb, but it only works when running gdb as sudo for a reason I do not yet know.)
> 
> And when running as sudo:
> 
> (gdb) set startup-with-shell off
> No symbol table is loaded.  Use the "file" command.
> (gdb) run
> Starting program: /Users/aaronjensen/Source/emacs/src/emacs
> 
> Program terminated with signal SIGTRAP, Trace/breakpoint trap.
> The program no longer exists.

Maybe ask for help on the GDB mailing list.

> > In an Emacs configured with --enable-checking=yes,glyphs, you can also
> > use the dump-glyph-row command to the same effect.
> 
> Would doing this on the row that has the problem even if it is not currently flickering be useful?

If the same row _ever_ flickers, then yes, it will be useful.

> > The Y coordinate is measured from the top of the window.
> 
> In pixels?

Yes.

> > So the problem is with redrawing the cursor in a screen line that
> > shows a tall image? Is there any text before and/or after the image
> > in the same screen line?
> 
> No, the problem is with the redrawing the cursor on the row that in the active window *before* the image
> loads. See the attached gif. Frame 2 of the gif shows the blank. Frame 1 is before I press enter. When I press
> enter, which triggers a find-file on that image, it blanks the line, then loads the image.

Are you sure it blanks the line _before_ loading the image?  Could it
be that it blanks the line because it needs to display the image in
its stead?

And how is the cursor drawing involved in this?

Previous Next

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