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: Thu, 23 May 2019 13:27:10 -0700 Message-ID: References: <8ec78d6f3e44bd3484c986dc2535a643536c499e.camel@gmail.com> <87h89q6rlo.fsf@rub.de> <83k1ej81po.fsf@gnu.org> <83imu17qwa.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="149745"; 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 Thu May 23 22:35:04 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 1hTuQZ-000ckz-Og for geb-bug-gnu-emacs@m.gmane.org; Thu, 23 May 2019 22:35:03 +0200 Original-Received: from localhost ([127.0.0.1]:42911 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hTuQY-0003IZ-PG for geb-bug-gnu-emacs@m.gmane.org; Thu, 23 May 2019 16:35:02 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34927) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hTuQR-0003Ez-G2 for bug-gnu-emacs@gnu.org; Thu, 23 May 2019 16:34:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hTuJv-00015N-26 for bug-gnu-emacs@gnu.org; Thu, 23 May 2019 16:28:15 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60079) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hTuJl-00011H-Q5 for bug-gnu-emacs@gnu.org; Thu, 23 May 2019 16:28:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hTuJl-0005hy-ME for bug-gnu-emacs@gnu.org; Thu, 23 May 2019 16:28: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: Thu, 23 May 2019 20:28: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.155864325021902 (code B ref 35797); Thu, 23 May 2019 20:28:01 +0000 Original-Received: (at 35797) by debbugs.gnu.org; 23 May 2019 20:27:30 +0000 Original-Received: from localhost ([127.0.0.1]:45388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hTuJF-0005hC-Gt for submit@debbugs.gnu.org; Thu, 23 May 2019 16:27:29 -0400 Original-Received: from mail-it1-f173.google.com ([209.85.166.173]:37720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hTuJD-0005gx-Eu for 35797@debbugs.gnu.org; Thu, 23 May 2019 16:27:28 -0400 Original-Received: by mail-it1-f173.google.com with SMTP id m140so10474158itg.2 for <35797@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) In-Reply-To: <83imu17qwa.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:159688 Archived-At: > 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 wrote: > > > From: Andrew T > > Date: Wed, 22 May 2019 13:13:27 -0700 > > Cc: Stephen Berman , 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 =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 > > ), 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.