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

[Eli Zaretskii]

> From: Andrew T <summerfallsaway@gmail.com>
> Date: Thu, 23 May 2019 13:27:10 -0700
> Cc: Stephen Berman <stephen.berman@gmx.net>, 35797@debbugs.gnu.org
> 
> > I think there's a misunderstanding here, due to the multitude of
> > faces and some implicit expectations that were never explicitly
> > described. Would you please describe what you expected to see in this
> > case, in terms of the appearance of the whitespace characters of
> > wrap-prefix?
> 
> For space characters, I only care if it's a *trailing* space -- since
> that is important for certain simplified markup languages like Pug and
> Markdown, and cleaning up trailing spaces is often required in
> different code style guides -- or if it's a "hard" (non-breaking)
> space.
> 
> I want normal spaces to be *invisible*, as long as they appear between
> words, or at the beginning of indented lines.
> 
> The Adaptive Wrap prefix shows all those dots representing spaces. I
> assume it's not using hard spaces, because that would be weird. And
> these spaces are added to the beginning of the soft-wrapped lines, not
> the end, so they aren't really trailing spaces either, right?
> 
> So it seems to me that those dots should be invisible, just like they
> would be if I hard-wrapped the lines, since hard-wrapping is the
> behavior Adaptive Wrap tries to simulate in its display.

Now I'm completely confused.  Whitespace mode doesn't just show the
trailing whitespace, it shows _all_ whitespace characters in a
distinct way, at least by default.  Just turn on that mode in
*scratch*, and you will see every SPC character displayed as a middle
dot with a distinct color.  If you want just the trailing spaces have
a distinct appearance, you need to customize whitespace-style to
include just 'trailing', I believe.

The wrap prefix produced by Adaptive Wrap is made of spaces, just not
spaces that come from the buffer.  And since by default Whitespace
mode displays _all_ space characters in that special way, you get the
wrap prefix displayed with those dots as well.

Am I missing something?

> In any case, the dots are not *colored* as if they were either hard
> or trailing spaces; the dots in the wrap prefix are instead rendered
> in the buffer default colors, for some reason.

More confusion: so you _do_ want to see those dots in the wrap prefix,
but expect them to have some colors?  Which colors did you expect to
see, and why?