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

Previous Next

Package: emacs;

Reported by: Aaron Jensen <aaronjensen <at> gmail.com>

Date: Thu, 4 Oct 2018 13:07:02 UTC

Severity: minor

Tags: fixed

Merged with 31904, 33891, 34127, 34710, 36302

Found in versions 26.1.90, 26.1.91, 26.2.90, 27.0.50

Fixed in version 28.1

Done: Alan Third <alan <at> idiocy.org>

Bug is archived. No further changes may be made.

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 11:23:08 +0200
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Thu, 1 Nov 2018 13:29:40 -0700
> Cc: alan <at> idiocy.org, 32932 <at> debbugs.gnu.org, boris <at> d12frosted.io
> 
> On November 1, 2018 at 1:13:05 PM, Eli Zaretskii
> (eliz <at> gnu.org(mailto:eliz <at> gnu.org)) wrote:
> 
> > Thanks, but this is not enough info, I need also to see the actual
> > contents of the current and the desired rows. If they are different,
> > then clearing is justified. You can display a glyph row in GDB using
> > the command pgrowx defined in src/.gdbinit.
> 
> Unfortunately, I’m on a Mac, so AFAIK I can only use lldb.

Doesn't the latest GDB compile on macOS?  I thought it did, but
perhaps that's only available in the GDB Git repo.

> I’ll see what I can figure out.

You can, of course, manually type the equivalents of the commands that
GDB uses in pgrowx.

In an Emacs configured with --enable-checking=yes,glyphs, you can also
use the dump-glyph-row command to the same effect.

> > And which row is the problematic one: the one at Y = 0 or at Y = 637?
> 
> I don’t understand Y=0, is that 0 from where the point is? It’s
> probably the 16th row or so from the top.

The Y coordinate is measured from the top of the window.

> > The large numbers for the desired row in the 3rd sample look bogus to
> > me, unless you have a very tall image there.
> 
> It’s a relatively tall image, yeah.

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?

> > > So, the ascent and physics_ascent on the current row are coming back
> > > as 0. Also, the height is different.
> >
> > Sounds improbable to me. Are you sure you caught the right rows?
> 
> Those are the only things emitted when I pressed enter on the image
> file to open it (in this case, from the home buffer with a recent file
> list).

If you want to reproduce the flickering, you need to do whatever
causes redisplay after opening the file.  For example, does it flicker
when you move cursor?  Does cursor blinking cause flickering?  Each
one of these should show you the output that tells which parts of the
glyph row is Emacs actually redrawing.




This bug report was last modified 5 years and 94 days ago.

Previous Next


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