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

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

[Andrew T]

Appears to be similar to bug #15155: "24.3; wrap-prefix in adaptive-
wrap-prefix-mode with variable-pitch has wrong face"

  <
https://lists.gnu.org/archive/html/bug-gnu-emacs/2013-08/msg00716.html>

I normally use `adaptive-wrap-prefix-mode` via hook to `visual-line-
mode`.

And I use `global-whitespace-mode` to subtly show any tabs and newline
characters in general (displayed in a color close to the background
color). Spaces are normally invisible (exactly same color as
background), except trailing spaces are highlighted.

When putting these settings together and soft-wrapping a long indented
line, the wrap prefix shows a bunch of white dots for all the space
characters being displayed. These are not trailing spaces, so these
dots are not highlighted as such, but they normally shouldn't be
visible at all with my whitespace face configurations.

You can see the effect even without messing around with faces or
visual-line-mode hooks, though:

  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>


The below was generated while doing my `emacs -Q` test. Let me know if
you need any other information to help debug this issue.

In GNU Emacs 26.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version
3.24.8)
 of 2019-04-30 built on buildvm-06.phx2.fedoraproject.org
Windowing system distributor 'Fedora Project', version 11.0.12004000
System Description:	Fedora release 30 (Thirty)

Recent messages:
You can run the command ‘whitespace-mode’ with M-x whit-m RET
Whitespace mode enabled in current buffer
Adaptive-Wrap-Prefix mode enabled in current buffer
Adaptive-Wrap-Prefix mode disabled in current buffer
Making completion list...
Quit
Adaptive-Wrap-Prefix mode enabled in current buffer
Making completion list... [2 times]
delete-backward-char: Text is read-only [3 times]
Making completion list...

Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-
png
 --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
 --with-gpm=no --with-xwidgets --with-modules
 build_alias=x86_64-redhat-linux-gnu host_alias=x86_64-redhat-linux-gnu
 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g -pipe -Wall -Werror=format-security
 -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
 -fstack-protector-strong -grecord-gcc-switches
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
 -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
 LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS GLIB NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS LCMS2

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  whitespace-mode: t
  adaptive-wrap-prefix-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug sendmail disp-table whitespace
adaptive-wrap compile comint ansi-color ring easy-mmode autoload
radix-tree lisp-mnt mm-archive message dired dired-loaddefs format-spec
rfc822 mml mml-sec epa derived epg gnus-util rmail rmail-loaddefs
mailabbrev gmm-utils mailheader mm-decode mm-bodies mm-encode mail-
utils
network-stream starttls url-http tls gnutls mail-parse rfc2231 rfc2047
rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm rmc puny url-cache
url-auth url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util mailcap cus-edit cus-start cus-load
wid-edit finder-inf package easymenu epg-config url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache url-vars seq byte-opt gv bytecomp byte-compile cconv
cl-loaddefs cl-lib elec-pair time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-
readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting xwidget-internal move-toolbar
gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 144118 30183)
 (symbols 48 24599 2)
 (miscs 40 57 170)
 (strings 32 43177 2424)
 (string-bytes 1 1138616)
 (vectors 16 24993)
 (vector-slots 8 1274945 189176)
 (floats 8 61 278)
 (intervals 56 525 68)
 (buffers 992 13))

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

[Stephen Berman]

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.

> I normally use `adaptive-wrap-prefix-mode` via hook to `visual-line-
> mode`.
>
> And I use `global-whitespace-mode` to subtly show any tabs and newline
> characters in general (displayed in a color close to the background
> color). Spaces are normally invisible (exactly same color as
> background), except trailing spaces are highlighted.
>
> When putting these settings together and soft-wrapping a long indented
> line, the wrap prefix shows a bunch of white dots for all the space
> characters being displayed. These are not trailing spaces, so these
> dots are not highlighted as such, but they normally shouldn't be
> visible at all with my whitespace face configurations.
>
> You can see the effect even without messing around with faces or
> visual-line-mode hooks, though:
>
>   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.

However, in case you are not aware of it, whitespace mode provides two
mechanisms that may be good enough for you.  To temporily suppress the
dots, type `M-x whitespace-toggle-options' and then at the prompt type
`S' (capital s).  To permanently suppress the dots you can customize
whitespace-display-mappings by either changing or deleting the character
mapping for spaces (the first entry in the Customize buffer when you
type `M-x customize-option RET whitespace-display-mappings RET').

(However, there currently appears to be a problem with this defcustom:
when you make the change I just referred to and then try to apply or
save it, this raises the error "This field should contain a single
character".  The problem here is with the newline character mapping: if
you delete that entry, then applying or saving other changes works.  The
newline entry somehow runs afoul of the character editable-field widget,
but I don't immediately see why and don't have time right now to pursue
it.  But as a workaround, in the Customize buffer you can press the
state button, select "Show Saved Lisp Expression", and then either
delete the sexp (space-mark 32 [183] [46]) or change it to (space-mark
32 [32] [32]), then apply or save the change.)

Steve Berman

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

[Eli Zaretskii]

> 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.

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.

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

[Eli Zaretskii]

> From: Andrew T <summerfallsaway@gmail.com>
> Date: Wed, 22 May 2019 13:13:27 -0700
> Cc: Stephen Berman <stephen.berman@gmx.net>, 35797@debbugs.gnu.org
> 
> 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.

You don't need to install anything, just load adaptive-wrap.el
manually with "M-x load-file", after downloading the file to your
system.

> ...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.

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?
The whitespace characters elsewhere in the display you show have 2
different appearances: one in the initial comment of the *scratch*
buffer, the other in the long line you typed.  Which one of them did
you expect to see in the wrap-prefix?  Or maybe you expected to see
something that is neither one?  Please state the expectations as
clearly and unambiguously as you possible can, okay?

> 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.

Likewise, in this last use case: please describe your expectations.

Thanks.

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

[Andrew T]

> 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? 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.

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.


On Wed, May 22, 2019 at 9:09 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Andrew T <summerfallsaway@gmail.com>
> > Date: Wed, 22 May 2019 13:13:27 -0700
> > Cc: Stephen Berman <stephen.berman@gmx.net>, 35797@debbugs.gnu.org
> >
> > 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.
>
> You don't need to install anything, just load adaptive-wrap.el
> manually with "M-x load-file", after downloading the file to your
> system.
>
> > ...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.
>
> 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?
> The whitespace characters elsewhere in the display you show have 2
> different appearances: one in the initial comment of the *scratch*
> buffer, the other in the long line you typed.  Which one of them did
> you expect to see in the wrap-prefix?  Or maybe you expected to see
> something that is neither one?  Please state the expectations as
> clearly and unambiguously as you possible can, okay?
>
> > 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.
>
> Likewise, in this last use case: please describe your expectations.
>
> Thanks.

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?

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

[Andrew T]

> 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.

Right, that's why I described in my first message how, for the types of
whitespace I'm not interested in, I either disable the option or set
the foreground color to be the same as the background color, so that
the dots are invisible.

I don't personally need Whitespace Mode to tell me when lines are
overly long, because I can already see how long the lines are just by
looking at them. So in Customize, in the list of checkboxes under
Whitespace Style, I've unchecked "(Face) Lines" and "(Face) Lines, only
overlong part".

I think empty lines are also already self-evident, so in Whitespace
Style, I've unchecked "(Face) Empty Lines..."

In my own projects, I usually indent with spaces instead of tabs, but I
think all the dots that appear by default for indentation are a little
ugly. I only need to know when I'm using spaces versus tabs, so "(Face)
TABs" is checked, but all three "(Face) Indentation..." options are
unchecked.

I do care about trailing spaces, as I've said, so "(Face) Trailing
TABs, SPACEs and HARD SPACEs" is checked.

I considered disabling *all* space faces, except I do want to see when
it's a "hard" non-breaking space instead of a normal space, and the
Whitespace Style checkboxes do not separate these. So what I did was
leave "(Face) SPACEs and HARD SPACEs" checked, but set the Whitespace
Space face to inherit its background color, and have its foreground
color be the same as the buffer default background.

The Whitespace Hspace and Whitespace Trailing faces have unique
background and foreground colors to make them stand out.

This all adds up to the dots representing *normal non-trailing* space
characters being invisible... EXCEPT in the Adaptive Wrap soft-wrap
prefix.

With my current Whitespace Mode configurations, I don't see the dots
for real indentation, so I don't think it should show the dots for
simulated indentation while soft-wrapping either.

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

[Eli Zaretskii]

> From: Andrew T <summerfallsaway@gmail.com>
> Cc: stephen.berman@gmx.net, 35797@debbugs.gnu.org
> Date: Thu, 23 May 2019 19:26:45 -0700
> 
> With my current Whitespace Mode configurations, I don't see the dots
> for real indentation, so I don't think it should show the dots for
> simulated indentation while soft-wrapping either.

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?

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.

Perhaps this problem could be solved in adaptive-wrap-prefix mode, by
creating a wrap-prefix not just as a string of space characters, but
something else, like using a special 'display' spec or something.  In
any case, the feature you are looking for wasn't implemented yet.

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

[Andrew T]

> 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.

> 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. 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.

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.

¯\_(ツ)_/¯

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

[Eli Zaretskii]

> 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.