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

[Andrew T]

> I don't think there's anything special about wrap-prefix
> implementation: it just acts as if a display string was specified at
> the proper buffer location.
>
> I think the problem here is entirely different: both the whitespace-
> space face used for the space characters and the whitespace-line face
> used for the wrapped line specify background colors.  When we merge
> these faces, the background of one of them must win. You can see that
> if you avoid specifying the background color for the whitespace-line
> face, the whitespace in the wrap-prefix has the expected face.
>
> So I don't think there's a problem here.  Emacs behaves as expected.

Thanks guys, for taking a look at this with me.

I'm having a hard time trying to do my original bug reproduction
starting from the `emacs -Q` command, because GNU ELPA keeps timing
out or something. `M-x package-refresh-contents` reports "Failed to
download ‘gnu’ archive." Not sure if my network is acting screwy or if
the ELPA server is down. `M-x package-list` actually says
adaptive-wrap 0.7 is already installed(??) even though it's not
included with the Emacs packages installed from Fedora -- yet the
`adaptive-wrap-prefix-mode` command is unavailable. So at the moment,
I can't test your suggestion of setting the whitespace-line face
background, at least not starting from a pristine environment.

...However, the default colors for the `whitespace-line` face is sort
of a purple foreground on dark gray background, while in the
screenshots from my previous test (second image at
<https://imgur.com/a/znbU0s3>), the wrap prefix is black on white --
same as the buffer default colors for text that hasn't yet gotten any
syntax or other highlighting.

And in my actual configuration (the third image in the Imgur album),
it's the same behavior, except there the default colors are white on
very dark gray. I actually have Whitespace Mode configured *not* to do
highlighting for long lines anyway. In Customize, under the Whitespace
Style options, both of the "(Face) Lines" checkboxes are unchecked.

So if it *is* just a clash in my face configurations, I don't think
the `whitespace-line` face is the one winning out here. In fact,
*none* of my Whitespace faces have a white foreground color.

I thought for a moment to try `M-x describe-text-properties` or
something similar but I can't move the point onto the wrap prefix, so
I can't figure out how to get properties on the prefix itself.

It's certainly possible I've done something wrong in my configuration,
but I can't think of what it would be. You can see my current init.el
file here <https://gitlab.com/snippets/1859536>. I've tried to include
plenty of comments to make it easy to skim.


On Tue, May 21, 2019 at 11:04 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Stephen Berman <stephen.berman@gmx.net>
> > Date: Sun, 19 May 2019 23:50:59 +0200
> > Cc: 35797@debbugs.gnu.org
> >
> > On Sat, 18 May 2019 20:18:54 -0700 Andrew T <summerfallsaway@gmail.com> 
> > wrote:
> >
> > > Appears to be similar to bug #15155: "24.3; wrap-prefix in adaptive-
> > > wrap-prefix-mode with variable-pitch has wrong face"
> >
> > That bug was fixed, but the fix does not prevent your problem, so it
> > seems to be a different issue.
>
> Yes, I think it's a different issue.
>
> > >   emacs -Q
> > >   M-x package-install RET adaptive-wrap RET
> > >   M-x adaptive-wrap-prefix-mode RET
> > >   M-x whitespace-mode RET
> > >
> > > ...Then write a long indented line so that it will wrap, and see see
> > > how the wrap prefix is a different color from the default whitespace
> > > display characters.
> > >
> > > I'll also include some screenshots here:
> > > <https://imgur.com/a/znbU0s3>
> >
> > Whitespace mode displays dots where there are spaces by altering the
> > buffer's display table.  This also affects the spaces added by
> > adaptive-wrap-prefix-mode, but as you have seen, those spaces are not
> > affected by customizing whitespace-mode faces.  I suspect this has to do
> > with how wrap-prefix is implemented in the display engine and may not be
> > easy to fix.
>
> I don't think there's anything special about wrap-prefix
> implementation: it just acts as if a display string was specified at
> the proper buffer location.
>
> I think the problem here is entirely different: both the
> whitespace-space face used for the space characters and the
> whitespace-line face used for the wrapped line specify background
> colors.  When we merge these faces, the background of one of them must
> win.  You can see that if you avoid specifying the background color
> for the whitespace-line face, the whitespace in the wrap-prefix has
> the expected face.
>
> So I don't think there's a problem here.  Emacs behaves as expected.