From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Andrew T Newsgroups: gmane.emacs.bugs Subject: bug#35797: 26.2; Adaptive Wrap does not respect Whitespace Mode faces Date: Wed, 22 May 2019 13:13:27 -0700 Message-ID: References: <8ec78d6f3e44bd3484c986dc2535a643536c499e.camel@gmail.com> <87h89q6rlo.fsf@rub.de> <83k1ej81po.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="253605"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35797@debbugs.gnu.org, Stephen Berman To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 22 22:14:15 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hTXcs-0013na-S3 for geb-bug-gnu-emacs@m.gmane.org; Wed, 22 May 2019 22:14:15 +0200 Original-Received: from localhost ([127.0.0.1]:50775 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hTXcr-0002WJ-Sf for geb-bug-gnu-emacs@m.gmane.org; Wed, 22 May 2019 16:14:13 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:52755) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hTXch-0002WE-Dj for bug-gnu-emacs@gnu.org; Wed, 22 May 2019 16:14:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hTXcf-0003Bx-Tm for bug-gnu-emacs@gnu.org; Wed, 22 May 2019 16:14:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57721) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hTXcf-0003Bb-Pt for bug-gnu-emacs@gnu.org; Wed, 22 May 2019 16:14:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hTXcf-0005sh-Ke for bug-gnu-emacs@gnu.org; Wed, 22 May 2019 16:14:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andrew T Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 May 2019 20:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35797 X-GNU-PR-Package: emacs Original-Received: via spool by 35797-submit@debbugs.gnu.org id=B35797.155855602922582 (code B ref 35797); Wed, 22 May 2019 20:14:01 +0000 Original-Received: (at 35797) by debbugs.gnu.org; 22 May 2019 20:13:49 +0000 Original-Received: from localhost ([127.0.0.1]:43032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hTXcS-0005s9-JP for submit@debbugs.gnu.org; Wed, 22 May 2019 16:13:48 -0400 Original-Received: from mail-it1-f195.google.com ([209.85.166.195]:53954) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hTXcO-0005rs-Pa for 35797@debbugs.gnu.org; Wed, 22 May 2019 16:13:46 -0400 Original-Received: by mail-it1-f195.google.com with SMTP id m141so5789952ita.3 for <35797@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) In-Reply-To: <83k1ej81po.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:159658 Archived-At: > 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 ), 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 . 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 wrote: > > > From: Stephen Berman > > 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 = 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: > > > > > > > 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.