unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stephen Berman <stephen.berman@gmx.net>
To: Andrew T <summerfallsaway@gmail.com>
Cc: 35797@debbugs.gnu.org
Subject: bug#35797: 26.2; Adaptive Wrap does not respect Whitespace Mode faces
Date: Sun, 19 May 2019 23:50:59 +0200	[thread overview]
Message-ID: <87h89q6rlo.fsf@rub.de> (raw)
In-Reply-To: <8ec78d6f3e44bd3484c986dc2535a643536c499e.camel@gmail.com>

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





  reply	other threads:[~2019-05-19 21:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-19  3:18 bug#35797: 26.2; Adaptive Wrap does not respect Whitespace Mode faces Andrew T
2019-05-19 21:50 ` Stephen Berman [this message]
2019-05-22  6:04   ` Eli Zaretskii
2019-05-22 20:13     ` Andrew T
2019-05-23  4:09       ` Eli Zaretskii
2019-05-23 20:27         ` Andrew T
2019-05-23 20:41           ` Eli Zaretskii
2019-05-24  2:26             ` Andrew T
2019-05-24  6:59               ` Eli Zaretskii
2019-05-24 17:14                 ` Andrew T
2019-05-24 19:11                   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h89q6rlo.fsf@rub.de \
    --to=stephen.berman@gmx.net \
    --cc=35797@debbugs.gnu.org \
    --cc=summerfallsaway@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).