bug#35797: 26.2; Adaptive Wrap does not respect Whitespace Mode faces

[Eli Zaretskii <eliz@gnu.org>]

> From: Andrew T <summerfallsaway@gmail.com>
> Cc: stephen.berman@gmx.net, 35797@debbugs.gnu.org
> Date: Fri, 24 May 2019 10:14:48 -0700
> 
> > So, AFAIU, your problem is that you don't like whitespace-mode
> > displaying the whitespace in the wrap-prefix as "normal" space
> > characters, i.e. as "dots", and not as whitespace in
> > indentation.  And the exact face in which these "dots" are displayed
> > is not the issue. Is my understanding correct?
> 
> Technically, the wrap prefix is *not* being displayed like normal space
> characters. The wrap prefix gets displayed in the buffer's default
> foreground and background colors, even though *none* of the configured
> Whitespace faces use this these colors.

That's because whitespace-mode uses faces to highlight certain classes
of whitespace, but it also modifies the way a SPC character is
displayed via the buffer's display-table.  In the display-table, the
glyphs that are used to display SPC are defined without a face, as
whitespace-mode expects the face to come from text properties.
However, text properties on buffer text affect only characters from
buffer text, whereas the display-table affects any character Emacs
displays, whether it comes from the buffer or any other source.  So
when the display-table is used to display SPC characters which come
from the wrap-prefix, they have the default colors.

IOW, this is how whitespace-mode was designed and implemented, and
this is one reason why it is incompatible with adaptive-wrap-mode (or
vice versa, depending on your POV).

> > If my understanding is correct, then whitespace.el cannot do that: it
> > only recognizes indentation by looking at characters in the buffer
> > that follow a newline.  By contrast, wrap-prefix doesn't come from
> > the buffer, and doesn't follow a newline.  So whitespace-mode simply
> > doesn't understand that the wrap-prefix is indentation of sorts.
> 
> That's a plausible theory.

Sorry, that's not a theory.  That's how stuff actually works
internally.

> Adaptive Wrap doesn't actually modify the buffer contents, so
> Whitespace Mode doesn't see the wrap prefix...  Except then it seems
> odd to me that the dots appear at all, instead of merely using the
> default (wrong) colors.

The dots appear because the display-table set up by whitespace-mode
affects display of characters regardless of their source, whether they
come from buffer, display string, overlay string, or wrap-prefix.

> Like, I would expect the opposite situation: Say, if I left the special
> colors representing indentation or mid-line spaces enabled, I might
> expect Whitespace Mode *not* to apply those at all to the wrap prefix,
> so that they appear as regular unhighlighted spaces even if I did want
> them highlighted. Yet even when testing from `emacs -Q`, where all I do
> is disable long lines in Whitespace Style, the Adaptive Wrap prefix
> still shows in the buffer default colors, which matches none of the
> default colors in the Whitespace Mode faces.

I hope you understand the reasons now.