bug#21500: 24.5; Graphical glitch with display property lines in GUI Emacs

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 17 Sep 2015 08:34:16 +0200
> From: Vasilij Schneidermann <v.schneidermann@gmail.com>
> Cc: 21500@debbugs.gnu.org
> 
> > That's the default Emacs implementation of cursor display on GUI
> > frames: we erase the character at point, then draw that character
> > again with cursor colors (normally, in reverse video).  For
> > "white-space" characters, such as TAB and the stretch of white space
> > created by the 'space' display property, Emacs by default draws the
> > cursor using the width of the font's SPC character.  And that's
> > exactly what you saw.
> 
> Interesting.  Now that I've checked again, it's indeed that a terminal
> frame does not show any reverse video effects at all with the cursor, so
> that explains this display oddity.

Emacs doesn't draw the cursor on text-mode frames.  It only moves it
to the proper place, and can turn it off if needed.  But the cursor
drawing and blinking is something done by the terminal itself.  By
contrast, on GUI frames, it's Emacs that draws the cursor, in the way
I described.

> > Yes.  But the face needs to have that as part of its definition.
> 
> OK, which face would it be in this case, the cursor or the line face?

The line, of course.  That's the face you want to see, even when its
foreground and background colors are identical.

> > Anyway, I see no relation between what you were wondering about and
> > the effect of cursor display that I believe was the trigger for this
> > bug report.  If you have questions about face rendering, I suggest to
> > ask them on emacs-devel.
> 
> Well, I do.  If putting the cursor on a special space has a different
> effect in GUI than in textual frames, I'd like to know what's causing it
> and whether there is any way of fixing it.

See above: what's causing it is the fact that Emacs doesn't draw the
cursor on text-mode frames.  And I see no way of "fixing" it.  Nor do
I think there's a problem here: this surprising effect happens only
when you have a stretch of white space wider than a single SPC
character, and then only when the cursor is at that buffer position.
E.g., in your scenario add some character, say 'x', before the
whitespace, and move point to that character -- you will see the rest
of the line displayed constantly with no "glitches".

> > Can we now close the bug?
> 
> I still don't have a tangible solution at hand for fixing this display
> glitch.  Altering `x-stretch-cursor` is a workaround, but not as good as
> altering, say, the line face to be displayed under every condition by
> altering its definition.

I don't think there's a glitch here, and I see no way of "fixing" that
without losing the important indication of the cursor position.