GNU logs - #35797, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#35797: 26.2; Adaptive Wrap does not respect Whitespace Mode faces
Resent-From: Andrew T <summerfallsaway@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 19 May 2019 06:06:01 +0000
Resent-Message-ID: <handler.35797.B.155824590122130 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 35797 <at> debbugs.gnu.org
Message-ID: <8ec78d6f3e44bd3484c986dc2535a643536c499e.camel@HIDDEN>
From: Andrew T <summerfallsaway@HIDDEN>
Date: Sat, 18 May 2019 20:18:54 -0700
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.2 (3.32.2-1.fc30) 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Andrew T <summerfallsaway@HIDDEN>
Subject: bug#35797: Acknowledgement (26.2; Adaptive Wrap does not respect
 Whitespace Mode faces)
Message-ID: <handler.35797.B.155824590122130.ack <at> debbugs.gnu.org>
References: <8ec78d6f3e44bd3484c986dc2535a643536c499e.camel@HIDDEN>
X-Gnu-PR-Message: ack 35797
X-Gnu-PR-Package: emacs
Reply-To: 35797 <at> debbugs.gnu.org
Date: Sun, 19 May 2019 06:06:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 35797 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
35797: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D35797
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#35797: 26.2; Adaptive Wrap does not respect Whitespace Mode faces
In-Reply-To: <8ec78d6f3e44bd3484c986dc2535a643536c499e.camel@HIDDEN>
Resent-From: Stephen Berman <stephen.berman@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 19 May 2019 21:52:01 +0000
Resent-Message-ID: <handler.35797.B35797.155830267231784 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Andrew T <summerfallsaway@HIDDEN>
Cc: 35797 <at> debbugs.gnu.org
From: Stephen Berman <stephen.berman@HIDDEN>
References: <8ec78d6f3e44bd3484c986dc2535a643536c499e.camel@HIDDEN>
Date: Sun, 19 May 2019 23:50:59 +0200
Message-ID: <87h89q6rlo.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

On Sat, 18 May 2019 20:18:54 -0700 Andrew T <summerfallsaway@HIDDEN> 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

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#35797: 26.2; Adaptive Wrap does not respect Whitespace Mode faces
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 22 May 2019 06:05:02 +0000
Resent-Message-ID: <handler.35797.B35797.155850504814619 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Stephen Berman <stephen.berman@HIDDEN>
Cc: 35797 <at> debbugs.gnu.org, summerfallsaway@HIDDEN
Date: Wed, 22 May 2019 09:04:03 +0300
Message-Id: <83k1ej81po.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <87h89q6rlo.fsf@HIDDEN> (message from Stephen Berman on Sun, 19
 May 2019 23:50:59 +0200)
References: <8ec78d6f3e44bd3484c986dc2535a643536c499e.camel@HIDDEN>
 <87h89q6rlo.fsf@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> From: Stephen Berman <stephen.berman@HIDDEN>
> Date: Sun, 19 May 2019 23:50:59 +0200
> Cc: 35797 <at> debbugs.gnu.org
> 
> On Sat, 18 May 2019 20:18:54 -0700 Andrew T <summerfallsaway@HIDDEN> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#35797: 26.2; Adaptive Wrap does not respect Whitespace Mode faces
Resent-From: Andrew T <summerfallsaway@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 22 May 2019 20:14:01 +0000
Resent-Message-ID: <handler.35797.B35797.155855602922582 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 35797
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 35797 <at> debbugs.gnu.org, Stephen Berman <stephen.berman@HIDDEN>
Received: via spool by 35797-submit <at> debbugs.gnu.org id=B35797.155855602922582
          (code B ref 35797); Wed, 22 May 2019 20:14:01 +0000
Received: (at 35797) by debbugs.gnu.org; 22 May 2019 20:13:49 +0000
Received: from localhost ([127.0.0.1]:43032 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hTXcS-0005s9-JP
	for submit <at> debbugs.gnu.org; Wed, 22 May 2019 16:13:48 -0400
Received: from mail-it1-f195.google.com ([209.85.166.195]:53954)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <summerfallsaway@HIDDEN>) id 1hTXcO-0005rs-Pa
 for 35797 <at> debbugs.gnu.org; Wed, 22 May 2019 16:13:46 -0400
Received: by mail-it1-f195.google.com with SMTP id m141so5789952ita.3
 for <35797 <at> debbugs.gnu.org>; Wed, 22 May 2019 13:13:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=E4W8tSeEuMF06fFjr1mQP7bZxlvqkLcv+JHkbIGDHEc=;
 b=uEL1WHbV6DOIQ8S96OH1UFvKZjBCttJhDy/7IR8AuaCiiC05MshX0fKFi6ZsAhV7o+
 L+HKN93fo08LnoxSeENRCNkyy7COFqEYnMdthEUQ0yusAl0kwf+KwbrSQU0DKq3FQHL9
 yyK+yTJoahWMlwfDGLEax2gq+zDatdz5tu3fo1Ue9stx7iJbibaFtC6g0B+MxgQsY7q4
 jAdoIfsYzSNldQhAa421ujpWszcX2bYbcnmNbS+8z7F6BV/IYXmncKBRJiBQcrw25FbS
 cFZX5Db5m1Hsh938zC74o3J3TmKCgrbbbx77MkKTqc+0Tysik3lGG35bgFd3rR4dqHNo
 oTQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=E4W8tSeEuMF06fFjr1mQP7bZxlvqkLcv+JHkbIGDHEc=;
 b=VtwU4k3DkkKvqnRtaTPaW7TFai+6KeNHFO4QUSp6UnScApfpEB0EW44D4/dh0uGnhw
 VukIaNGLaMCZXxeopirrlmz4TbKR1pHHCzJjb2JZuv6MU7pnM+1SSllnWT1MYMEaZkSk
 /GfHM6xm7p23Sa6LcAFqf46E6ZZpOW9pZfkEk+uV7T2pwcO79yPvZmRNQKy7J6WZwNwO
 68SSG3dDtaQP6FtFuotluX1RO5G9gkjWS2GHH0IJArQ3JN436OQ2htYW6Lpi9w1J4KjK
 rmmqB53flCLe/fjV6URWoiSkc+hL18cgX3OB2X20XHDVGdEdIg9mzbQhFumESjTt/g+6
 P/FQ==
X-Gm-Message-State: APjAAAWqbgj+zyD3ieJuUFqm4Q2s7yos5IM/PEofkJz2nbRTH3QKyTjF
 PeenF3ul/8jwIrNZ6IzDvhrT2clqo/fOESx6tbo=
X-Google-Smtp-Source: APXvYqwc+RW5WvAvadCQMSdcJb2lE7sNpaCcjMfIOth2a5sLmM1jBby92TfRl3TU0MBtLg+r9hEa4HT9eM/PVO0M4qA=
X-Received: by 2002:a02:b38e:: with SMTP id p14mr12575299jan.43.1558556017912; 
 Wed, 22 May 2019 13:13:37 -0700 (PDT)
MIME-Version: 1.0
References: <8ec78d6f3e44bd3484c986dc2535a643536c499e.camel@HIDDEN>
 <87h89q6rlo.fsf@HIDDEN> <83k1ej81po.fsf@HIDDEN>
In-Reply-To: <83k1ej81po.fsf@HIDDEN>
From: Andrew T <summerfallsaway@HIDDEN>
Date: Wed, 22 May 2019 13:13:27 -0700
Message-ID: <CALxGmcgo55ajDOtTuEJEsV5NPyYePsq_WUsO4Rqxg7cHee1XtQ@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.4 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.4 (-)

> 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 =E2=80=98gnu=E2=80=99 archive." Not sure if my network is acting s=
crewy 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@HIDDEN> wrote:
>
> > From: Stephen Berman <stephen.berman@HIDDEN>
> > Date: Sun, 19 May 2019 23:50:59 +0200
> > Cc: 35797 <at> debbugs.gnu.org
> >
> > On Sat, 18 May 2019 20:18:54 -0700 Andrew T <summerfallsaway@HIDDEN>=
 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 d=
o
> > with how wrap-prefix is implemented in the display engine and may not b=
e
> > 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#35797: 26.2; Adaptive Wrap does not respect Whitespace Mode faces
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 23 May 2019 04:10:01 +0000
Resent-Message-ID: <handler.35797.B35797.155858459810765 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 35797
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrew T <summerfallsaway@HIDDEN>
Cc: 35797 <at> debbugs.gnu.org, stephen.berman@HIDDEN
Received: via spool by 35797-submit <at> debbugs.gnu.org id=B35797.155858459810765
          (code B ref 35797); Thu, 23 May 2019 04:10:01 +0000
Received: (at 35797) by debbugs.gnu.org; 23 May 2019 04:09:58 +0000
Received: from localhost ([127.0.0.1]:43649 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hTf3F-0002nZ-PJ
	for submit <at> debbugs.gnu.org; Thu, 23 May 2019 00:09:58 -0400
Received: from eggs.gnu.org ([209.51.188.92]:43499)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hTf3E-0002nM-IR
 for 35797 <at> debbugs.gnu.org; Thu, 23 May 2019 00:09:56 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:52561)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hTf38-00029p-C1; Thu, 23 May 2019 00:09:50 -0400
Received: from [176.228.60.248] (port=1174 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hTf37-0005JW-Q1; Thu, 23 May 2019 00:09:50 -0400
Date: Thu, 23 May 2019 07:09:57 +0300
Message-Id: <83imu17qwa.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CALxGmcgo55ajDOtTuEJEsV5NPyYePsq_WUsO4Rqxg7cHee1XtQ@HIDDEN>
 (message from Andrew T on Wed, 22 May 2019 13:13:27 -0700)
References: <8ec78d6f3e44bd3484c986dc2535a643536c499e.camel@HIDDEN>
 <87h89q6rlo.fsf@HIDDEN> <83k1ej81po.fsf@HIDDEN>
 <CALxGmcgo55ajDOtTuEJEsV5NPyYePsq_WUsO4Rqxg7cHee1XtQ@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Andrew T <summerfallsaway@HIDDEN>
> Date: Wed, 22 May 2019 13:13:27 -0700
> Cc: Stephen Berman <stephen.berman@HIDDEN>, 35797 <at> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#35797: 26.2; Adaptive Wrap does not respect Whitespace Mode faces
Resent-From: Andrew T <summerfallsaway@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 23 May 2019 20:28:01 +0000
Resent-Message-ID: <handler.35797.B35797.155864325021902 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 35797
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 35797 <at> debbugs.gnu.org, Stephen Berman <stephen.berman@HIDDEN>
Received: via spool by 35797-submit <at> debbugs.gnu.org id=B35797.155864325021902
          (code B ref 35797); Thu, 23 May 2019 20:28:01 +0000
Received: (at 35797) by debbugs.gnu.org; 23 May 2019 20:27:30 +0000
Received: from localhost ([127.0.0.1]:45388 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hTuJF-0005hC-Gt
	for submit <at> debbugs.gnu.org; Thu, 23 May 2019 16:27:29 -0400
Received: from mail-it1-f173.google.com ([209.85.166.173]:37720)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <summerfallsaway@HIDDEN>) id 1hTuJD-0005gx-Eu
 for 35797 <at> debbugs.gnu.org; Thu, 23 May 2019 16:27:28 -0400
Received: by mail-it1-f173.google.com with SMTP id m140so10474158itg.2
 for <35797 <at> debbugs.gnu.org>; Thu, 23 May 2019 13:27:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=rCcLdueFK9tHiNDxuU3H3jV41kwU2UmsIflP99nxYTY=;
 b=NoOLeqy8kGGuAjayengTlZ1gObFayC/UxDTlRd4tqOlbsRNybAspha/svX+S/CADzI
 z3nw0E5Mb5GEz0NGlnESEdSgx9FjyCEldslvokBwNzSB3LR0Y9xUcb3rajcTXOEzsy+7
 EKVr9xkTaB9R2XhUO9YJoKui1BqXMnb3hog3sVqBeCXxTqUj8X0Gi2jASB101Uam0hy1
 XajZ7sLxz/WNGtKea5WgiSioPvPPiwUB9CXtDyqv4XUKd+rg/Um2p+7ogLFkT/bFMkxj
 lfJ9RHXcNPf1VNTlg+wYsPNGp9kCXbtCv/uAitB1qUQH0oxenfp4CjwkCb4jnSo416aF
 VekQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=rCcLdueFK9tHiNDxuU3H3jV41kwU2UmsIflP99nxYTY=;
 b=mE5pXSuW3pmgYkc1TzWAFQA4EYi5gi0KU0NAKRQAlzBmqEJMlWcyGGzgYQ80/0FLww
 FFnmoe7Q883f3PoqEmgO32hK5IOtCOjOmz7rOgPYuwJGJQ1jvVEXqLmfCKvlqz9U7m/6
 A1VJxiBpHLmp5Xz6vsUaWhLjb/ZEB0baE3ABPvfBLAZvvwPJ192DgqNVRYJ0+bUnApnI
 SWMndNF0v75DW9fjdz2r/QnM+7GH5eQMjxMEvAQOz9B9e11dNR0cIsIdEAVOtnHNkFM6
 YMOgdCkQ4J/UlktYRu+JtgyfOj7EDGcLLX0XUemLtaQoZhJHDsjnVzUgXIMtcXFZugMY
 ou8A==
X-Gm-Message-State: APjAAAWLOLs3BoXGXhIqp0llFlLebcd7hRYhBh/1S4IvO/d74pJGDs5+
 4qbrH3GI73mCUcjZdmy10DAbqhc74fV+91MT9gc=
X-Google-Smtp-Source: APXvYqzM8XuhbpCJ9lUD2oNkNtiovW2PaWE5wVb4G/g8PMq0BKVYFMi2JaneiG4A0z2JNTSTf5/vDzexnIvNUrSP05k=
X-Received: by 2002:a24:a943:: with SMTP id x3mr2365146iti.64.1558643241668;
 Thu, 23 May 2019 13:27:21 -0700 (PDT)
MIME-Version: 1.0
References: <8ec78d6f3e44bd3484c986dc2535a643536c499e.camel@HIDDEN>
 <87h89q6rlo.fsf@HIDDEN> <83k1ej81po.fsf@HIDDEN>
 <CALxGmcgo55ajDOtTuEJEsV5NPyYePsq_WUsO4Rqxg7cHee1XtQ@HIDDEN>
 <83imu17qwa.fsf@HIDDEN>
In-Reply-To: <83imu17qwa.fsf@HIDDEN>
From: Andrew T <summerfallsaway@HIDDEN>
Date: Thu, 23 May 2019 13:27:10 -0700
Message-ID: <CALxGmci8ZSQ+88uEEKAtUebL0wDDGsQ_yh0Q4ZyMdcLbXGsfHA@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

> 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@HIDDEN> wrote:
>
> > From: Andrew T <summerfallsaway@HIDDEN>
> > Date: Wed, 22 May 2019 13:13:27 -0700
> > Cc: Stephen Berman <stephen.berman@HIDDEN>, 35797 <at> 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 =E2=80=98gnu=E2=80=99 archive." Not sure if my network is acti=
ng 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#35797: 26.2; Adaptive Wrap does not respect Whitespace Mode faces
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 23 May 2019 20:42:02 +0000
Resent-Message-ID: <handler.35797.B35797.155864407323125 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 35797
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrew T <summerfallsaway@HIDDEN>
Cc: 35797 <at> debbugs.gnu.org, stephen.berman@HIDDEN
Received: via spool by 35797-submit <at> debbugs.gnu.org id=B35797.155864407323125
          (code B ref 35797); Thu, 23 May 2019 20:42:02 +0000
Received: (at 35797) by debbugs.gnu.org; 23 May 2019 20:41:13 +0000
Received: from localhost ([127.0.0.1]:45404 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hTuWW-00060u-VA
	for submit <at> debbugs.gnu.org; Thu, 23 May 2019 16:41:13 -0400
Received: from eggs.gnu.org ([209.51.188.92]:50256)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hTuWS-00060f-QX
 for 35797 <at> debbugs.gnu.org; Thu, 23 May 2019 16:41:11 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:41423)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hTuWM-0000Bc-PX; Thu, 23 May 2019 16:41:03 -0400
Received: from [176.228.60.248] (port=2914 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hTuWM-0006hd-2d; Thu, 23 May 2019 16:41:02 -0400
Date: Thu, 23 May 2019 23:41:11 +0300
Message-Id: <83lfyw6h08.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CALxGmci8ZSQ+88uEEKAtUebL0wDDGsQ_yh0Q4ZyMdcLbXGsfHA@HIDDEN>
 (message from Andrew T on Thu, 23 May 2019 13:27:10 -0700)
References: <8ec78d6f3e44bd3484c986dc2535a643536c499e.camel@HIDDEN>
 <87h89q6rlo.fsf@HIDDEN> <83k1ej81po.fsf@HIDDEN>
 <CALxGmcgo55ajDOtTuEJEsV5NPyYePsq_WUsO4Rqxg7cHee1XtQ@HIDDEN>
 <83imu17qwa.fsf@HIDDEN>
 <CALxGmci8ZSQ+88uEEKAtUebL0wDDGsQ_yh0Q4ZyMdcLbXGsfHA@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Andrew T <summerfallsaway@HIDDEN>
> Date: Thu, 23 May 2019 13:27:10 -0700
> Cc: Stephen Berman <stephen.berman@HIDDEN>, 35797 <at> 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?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#35797: 26.2; Adaptive Wrap does not respect Whitespace Mode faces
Resent-From: Andrew T <summerfallsaway@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 24 May 2019 02:28:01 +0000
Resent-Message-ID: <handler.35797.B35797.155866482922817 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 35797
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 35797 <at> debbugs.gnu.org, stephen.berman@HIDDEN
Received: via spool by 35797-submit <at> debbugs.gnu.org id=B35797.155866482922817
          (code B ref 35797); Fri, 24 May 2019 02:28:01 +0000
Received: (at 35797) by debbugs.gnu.org; 24 May 2019 02:27:09 +0000
Received: from localhost ([127.0.0.1]:45775 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hTzvI-0005vx-K6
	for submit <at> debbugs.gnu.org; Thu, 23 May 2019 22:27:08 -0400
Received: from mail-wr1-f53.google.com ([209.85.221.53]:42127)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <summerfallsaway@HIDDEN>) id 1hTzvG-0005vS-MM
 for 35797 <at> debbugs.gnu.org; Thu, 23 May 2019 22:27:07 -0400
Received: by mail-wr1-f53.google.com with SMTP id l2so8269160wrb.9
 for <35797 <at> debbugs.gnu.org>; Thu, 23 May 2019 19:27:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=message-id:subject:from:to:cc:date:in-reply-to:references
 :user-agent:mime-version:content-transfer-encoding;
 bh=2R6MwQFPPWKPlHuW8vGIPsO5UO2E2Rg7huwKCfggm1c=;
 b=KJBRcqmS24Xo4l4+YafmKb5q4Cyxx8FTFOnvF4MsZINGjIpKTVDQ0z+t3b3Sb/AHVX
 ZHvCLxXGtFwihtKuL91OqRDVe+PLA1wzC7DEEOpnLlxWbTS93+73eIo8q/4f2Z9dD0VV
 QRJsOLC7ORJkSQe7s8OvHV4hvTpCTujczzOdX4QVFm21oET950vMNdgUwbsI/xSbRbfP
 Y8EaMFFq+q6c03aVfw50kdBZtrJbXWe4BdFA5lKCzkLEjTLkTwDcX3PxmereVzEjqhNa
 Dy8yB0C1AG/DPZvOB2zp4Wq7nT/UtWcjpUE+URBewE/kFa7pNjwGD8o1tXIveHolHoVc
 ALyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to
 :references:user-agent:mime-version:content-transfer-encoding;
 bh=2R6MwQFPPWKPlHuW8vGIPsO5UO2E2Rg7huwKCfggm1c=;
 b=TygIj4BA5Mlk46qi+qemWFb93OkdsE3iOSubdi/Y1RFzRZET9He3Mfor0EZ/IKJFMd
 Ti84ys6DjbsKJeffe0tJbCMuy8RRteHy+0QglMkcLxDCex5CpSLpMkjGrbTbTwfhkd5N
 UdHEiHtBjyQuMf5V1XUVpd9+dBdibRIoWhQSVUiliueWj3QZjLB/8Z9aq6jOAoOvs3WZ
 Om75/Glit9g5LXX+36c1oE3lzmyA9tLQGwhP6bNZkjG91gx1cLg7E3Nv+Leuvaz44uJb
 5AXajJt3Udr3K8YSu736uPcFW60fAaaRRhFGouBEMXZyqRJroN3h5UHModKUrPU5a4eS
 rm9g==
X-Gm-Message-State: APjAAAWLEVxgoSJ9XDqUuEsWhX+hLvvIcFn2jBAjavDeaZmmOlJyIGuF
 SGIYD88J4jjGO/dKHrsa7F4=
X-Google-Smtp-Source: APXvYqxizh1WiGIH0OY2MSl+dA426uHP6CRZJtGK4oY6Baiz/JHAYj3KdUMwFgpB5Qc5OZnqL75M7w==
X-Received: by 2002:a5d:4d84:: with SMTP id b4mr17935451wru.102.1558664820540; 
 Thu, 23 May 2019 19:27:00 -0700 (PDT)
Received: from mars.localdomain (50-37-25-247.grdv.nv.frontiernet.net.
 [50.37.25.247])
 by smtp.gmail.com with ESMTPSA id y18sm992732wmi.37.2019.05.23.19.26.57
 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256);
 Thu, 23 May 2019 19:26:59 -0700 (PDT)
Message-ID: <97660ab83d90006fadc72992d2be7cfd0b47d47e.camel@HIDDEN>
From: Andrew T <summerfallsaway@HIDDEN>
Date: Thu, 23 May 2019 19:26:45 -0700
In-Reply-To: <83lfyw6h08.fsf@HIDDEN>
References: <8ec78d6f3e44bd3484c986dc2535a643536c499e.camel@HIDDEN>
 <87h89q6rlo.fsf@HIDDEN> <83k1ej81po.fsf@HIDDEN>
 <CALxGmcgo55ajDOtTuEJEsV5NPyYePsq_WUsO4Rqxg7cHee1XtQ@HIDDEN>
 <83imu17qwa.fsf@HIDDEN>
 <CALxGmci8ZSQ+88uEEKAtUebL0wDDGsQ_yh0Q4ZyMdcLbXGsfHA@HIDDEN>
 <83lfyw6h08.fsf@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.2 (3.32.2-1.fc30) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#35797: 26.2; Adaptive Wrap does not respect Whitespace Mode faces
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 24 May 2019 07:00:02 +0000
Resent-Message-ID: <handler.35797.B35797.155868117316119 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 35797
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrew T <summerfallsaway@HIDDEN>
Cc: 35797 <at> debbugs.gnu.org, stephen.berman@HIDDEN
Received: via spool by 35797-submit <at> debbugs.gnu.org id=B35797.155868117316119
          (code B ref 35797); Fri, 24 May 2019 07:00:02 +0000
Received: (at 35797) by debbugs.gnu.org; 24 May 2019 06:59:33 +0000
Received: from localhost ([127.0.0.1]:45988 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hU4Au-0004Bv-V0
	for submit <at> debbugs.gnu.org; Fri, 24 May 2019 02:59:33 -0400
Received: from eggs.gnu.org ([209.51.188.92]:58951)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hU4At-0004Bi-6c
 for 35797 <at> debbugs.gnu.org; Fri, 24 May 2019 02:59:31 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:49163)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hU4Ao-0003z0-0O; Fri, 24 May 2019 02:59:26 -0400
Received: from [176.228.60.248] (port=1028 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hU4An-0006iG-Jl; Fri, 24 May 2019 02:59:25 -0400
Date: Fri, 24 May 2019 09:59:36 +0300
Message-Id: <83d0k85odj.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <97660ab83d90006fadc72992d2be7cfd0b47d47e.camel@HIDDEN>
 (message from Andrew T on Thu, 23 May 2019 19:26:45 -0700)
References: <8ec78d6f3e44bd3484c986dc2535a643536c499e.camel@HIDDEN>
 <87h89q6rlo.fsf@HIDDEN> <83k1ej81po.fsf@HIDDEN>
 <CALxGmcgo55ajDOtTuEJEsV5NPyYePsq_WUsO4Rqxg7cHee1XtQ@HIDDEN>
 <83imu17qwa.fsf@HIDDEN>
 <CALxGmci8ZSQ+88uEEKAtUebL0wDDGsQ_yh0Q4ZyMdcLbXGsfHA@HIDDEN>
 <83lfyw6h08.fsf@HIDDEN>
 <97660ab83d90006fadc72992d2be7cfd0b47d47e.camel@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Andrew T <summerfallsaway@HIDDEN>
> Cc: stephen.berman@HIDDEN, 35797 <at> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#35797: 26.2; Adaptive Wrap does not respect Whitespace Mode faces
Resent-From: Andrew T <summerfallsaway@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 24 May 2019 17:16:01 +0000
Resent-Message-ID: <handler.35797.B35797.155871810318217 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 35797
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 35797 <at> debbugs.gnu.org, stephen.berman@HIDDEN
Received: via spool by 35797-submit <at> debbugs.gnu.org id=B35797.155871810318217
          (code B ref 35797); Fri, 24 May 2019 17:16:01 +0000
Received: (at 35797) by debbugs.gnu.org; 24 May 2019 17:15:03 +0000
Received: from localhost ([127.0.0.1]:47239 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hUDmY-0004jl-Qz
	for submit <at> debbugs.gnu.org; Fri, 24 May 2019 13:15:03 -0400
Received: from mail-vs1-f43.google.com ([209.85.217.43]:42342)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <summerfallsaway@HIDDEN>) id 1hUDmW-0004iv-7V
 for 35797 <at> debbugs.gnu.org; Fri, 24 May 2019 13:15:00 -0400
Received: by mail-vs1-f43.google.com with SMTP id z11so6312813vsq.9
 for <35797 <at> debbugs.gnu.org>; Fri, 24 May 2019 10:15:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=message-id:subject:from:to:cc:date:in-reply-to:references
 :user-agent:mime-version:content-transfer-encoding;
 bh=z97v708iYq9UvroFKbjMNSII1YyhQMt20eaPWxffBpE=;
 b=nOTXlRccaX1DX7dJHaKh7IPgUhSbEozZLpQO+KHFf4lsG3eKbRAgzv7kvGHq8LLmFB
 QvvWOVJfpiHcw88AEGz8aX2QUOwxB9AEb8uL1UbS6IM5kBKFLFk56V1DUXQlS4lJc674
 3uDMMf3jg3QKG8VCMDc3tSZWS/5EeB7dYQLFO1XHHTj/rfGDmp6J9fMCrBUz0U/lePCm
 gQGabrN+EQP6jHf3BX3vDvsWXOk4O8ai3JeB+ldFfrs3S3E3ctiM4cM+qQO6GShfs5jg
 khAW4DxBU8zZf0G4lpGIE95DTR2xU03937jbxEzhS1dN4+MQhoqCrpmNb+cZCebOpcgT
 xIWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to
 :references:user-agent:mime-version:content-transfer-encoding;
 bh=z97v708iYq9UvroFKbjMNSII1YyhQMt20eaPWxffBpE=;
 b=l31J+qxkBHDghaD3a4b2N7vW06hxEVy+XQ2QTNXEl2cVsSLtS/LxnW1IwyzvXmCGVv
 xHF7Iy/3BFBHaRRSoOSvL29hmZJozg5NsXs2BbBRPD5QbzgfHGvSC7RKUH/Silkxs52A
 gjVWf7BEkg41NzhSxDyKacUZ1u84KANgp3Y263NtHI3zJiqNwJIf9exuMDOEoRNE6Vjb
 U1xafQgfHVkRSmdh2KV09pgv3GPqljlymvv7ykz5nATmsEvMJy8EWMYmbFFCP+WXGkTg
 gXMTH6ILCsGbifWMNeteMv40Xxie4uU4OPtmwB4txkiK55r4urc4FpsxtUFEACCYGqgu
 jVpQ==
X-Gm-Message-State: APjAAAX8Oj3ynRdvHW8eYc0CeLbmyl8kQSBPqh6z4PuG3Lpzh3F1lbq0
 nI2yKOjNcCDiukhaqaJAW/g=
X-Google-Smtp-Source: APXvYqwSiOjjF8xFhMA/B3p8oMss3ievxEQ+nN1fVZCW6Keyh0HeN63d5eg5XYZc84WIjsPTBmi5iA==
X-Received: by 2002:a67:1205:: with SMTP id 5mr18163570vss.156.1558718094483; 
 Fri, 24 May 2019 10:14:54 -0700 (PDT)
Received: from mars.localdomain ([207.244.109.181])
 by smtp.gmail.com with ESMTPSA id p70sm1397431vsd.25.2019.05.24.10.14.52
 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256);
 Fri, 24 May 2019 10:14:53 -0700 (PDT)
Message-ID: <7e4bab27142fe6cacba21f0ad411369fa0f0dda3.camel@HIDDEN>
From: Andrew T <summerfallsaway@HIDDEN>
Date: Fri, 24 May 2019 10:14:48 -0700
In-Reply-To: <83d0k85odj.fsf@HIDDEN>
References: <8ec78d6f3e44bd3484c986dc2535a643536c499e.camel@HIDDEN>
 <87h89q6rlo.fsf@HIDDEN> <83k1ej81po.fsf@HIDDEN>
 <CALxGmcgo55ajDOtTuEJEsV5NPyYePsq_WUsO4Rqxg7cHee1XtQ@HIDDEN>
 <83imu17qwa.fsf@HIDDEN>
 <CALxGmci8ZSQ+88uEEKAtUebL0wDDGsQ_yh0Q4ZyMdcLbXGsfHA@HIDDEN>
 <83lfyw6h08.fsf@HIDDEN>
 <97660ab83d90006fadc72992d2be7cfd0b47d47e.camel@HIDDEN>
 <83d0k85odj.fsf@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.2 (3.32.2-1.fc30) 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

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

¯\_(ツ)_/¯

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#35797: 26.2; Adaptive Wrap does not respect Whitespace Mode faces
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 24 May 2019 19:12:01 +0000
Resent-Message-ID: <handler.35797.B35797.15587250835479 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 35797
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrew T <summerfallsaway@HIDDEN>
Cc: 35797 <at> debbugs.gnu.org, stephen.berman@HIDDEN
Received: via spool by 35797-submit <at> debbugs.gnu.org id=B35797.15587250835479
          (code B ref 35797); Fri, 24 May 2019 19:12:01 +0000
Received: (at 35797) by debbugs.gnu.org; 24 May 2019 19:11:23 +0000
Received: from localhost ([127.0.0.1]:47350 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hUFb9-0001QJ-3f
	for submit <at> debbugs.gnu.org; Fri, 24 May 2019 15:11:23 -0400
Received: from eggs.gnu.org ([209.51.188.92]:59824)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hUFb7-0001Q6-2c
 for 35797 <at> debbugs.gnu.org; Fri, 24 May 2019 15:11:21 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:45438)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hUFb1-0005fW-MI; Fri, 24 May 2019 15:11:15 -0400
Received: from [176.228.60.248] (port=2711 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hUFay-0005XG-4D; Fri, 24 May 2019 15:11:15 -0400
Date: Fri, 24 May 2019 22:11:05 +0300
Message-Id: <83sgt34qie.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <7e4bab27142fe6cacba21f0ad411369fa0f0dda3.camel@HIDDEN>
 (message from Andrew T on Fri, 24 May 2019 10:14:48 -0700)
References: <8ec78d6f3e44bd3484c986dc2535a643536c499e.camel@HIDDEN>
 <87h89q6rlo.fsf@HIDDEN> <83k1ej81po.fsf@HIDDEN>
 <CALxGmcgo55ajDOtTuEJEsV5NPyYePsq_WUsO4Rqxg7cHee1XtQ@HIDDEN>
 <83imu17qwa.fsf@HIDDEN>
 <CALxGmci8ZSQ+88uEEKAtUebL0wDDGsQ_yh0Q4ZyMdcLbXGsfHA@HIDDEN>
 <83lfyw6h08.fsf@HIDDEN>
 <97660ab83d90006fadc72992d2be7cfd0b47d47e.camel@HIDDEN>
 <83d0k85odj.fsf@HIDDEN>
 <7e4bab27142fe6cacba21f0ad411369fa0f0dda3.camel@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Andrew T <summerfallsaway@HIDDEN>
> Cc: stephen.berman@HIDDEN, 35797 <at> 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.

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.