From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#35797: 26.2; Adaptive Wrap does not respect Whitespace Mode faces Date: Fri, 24 May 2019 22:11:05 +0300 Message-ID: <83sgt34qie.fsf@gnu.org> References: <8ec78d6f3e44bd3484c986dc2535a643536c499e.camel@gmail.com> <87h89q6rlo.fsf@rub.de> <83k1ej81po.fsf@gnu.org> <83imu17qwa.fsf@gnu.org> <83lfyw6h08.fsf@gnu.org> <97660ab83d90006fadc72992d2be7cfd0b47d47e.camel@gmail.com> <83d0k85odj.fsf@gnu.org> <7e4bab27142fe6cacba21f0ad411369fa0f0dda3.camel@gmail.com> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="197407"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35797@debbugs.gnu.org, stephen.berman@gmx.net To: Andrew T Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 24 21:12:12 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 1hUFbv-000p8i-Ii for geb-bug-gnu-emacs@m.gmane.org; Fri, 24 May 2019 21:12:11 +0200 Original-Received: from localhost ([127.0.0.1]:59129 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUFbu-0000Cl-9G for geb-bug-gnu-emacs@m.gmane.org; Fri, 24 May 2019 15:12:10 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46077) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUFbn-0000CO-Ez for bug-gnu-emacs@gnu.org; Fri, 24 May 2019 15:12:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hUFbm-00065Y-4F for bug-gnu-emacs@gnu.org; Fri, 24 May 2019 15:12:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33806) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hUFbm-00065P-0l for bug-gnu-emacs@gnu.org; Fri, 24 May 2019 15:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hUFbl-0001RJ-Nu for bug-gnu-emacs@gnu.org; Fri, 24 May 2019 15:12:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 May 2019 19:12: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.15587250835479 (code B ref 35797); Fri, 24 May 2019 19:12:01 +0000 Original-Received: (at 35797) by debbugs.gnu.org; 24 May 2019 19:11:23 +0000 Original-Received: from localhost ([127.0.0.1]:47350 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUFb9-0001QJ-3f for submit@debbugs.gnu.org; Fri, 24 May 2019 15:11:23 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59824) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUFb7-0001Q6-2c for 35797@debbugs.gnu.org; Fri, 24 May 2019 15:11:21 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45438) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUFb1-0005fW-MI; Fri, 24 May 2019 15:11:15 -0400 Original-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 ) id 1hUFay-0005XG-4D; Fri, 24 May 2019 15:11:15 -0400 In-reply-to: <7e4bab27142fe6cacba21f0ad411369fa0f0dda3.camel@gmail.com> (message from Andrew T on Fri, 24 May 2019 10:14:48 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:159726 Archived-At: > From: Andrew T > 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.