'bad' spaces are not shown in red color until I disable and re-enable the ethan-wspace mode

[rkachach]

First of all, thanks for this great module. In my configuration (see below) I have the mode enabled by default, but when I'm working on a buffer it doesn't show whitespaces (bad ones) in red color untill I disable and re-enable the mode in the following buffer. Please let me know if you need an further information.

My current setup:

GNU Emacs 27.2
Os: Fedora 35

My conf:

(use-package ethan-wspace
  :ensure t
  :demand
  :preface (require 'helm-config)
  :config
  (setq mode-require-final-newline nil) 
  (global-ethan-wspace-mode 1))

ethan-wspace:

Status: Installed in ‘ethan-wspace-20201106.2059/’ (unsigned). Delete
Version: 20201106.2059
Commit: 035c7d698c99e3891a522d6e6f8fde23c6267c15
Summary: whitespace customizations for emacs
Keywords: whitespace tab newline trailing clean 
Maintainer: Ethan Glasser-Camp <ethan@betacantrips.com>
Author: Ethan Glasser-Camp <ethan@betacantrips.com>
Other versions: 20201106.2059 (melpa).

[glasserc]

Hi, sorry for the delayed response! When you say "disable and re-enable the mode in the following buffer", what does "following" mean? Is it just a typo for "the existing buffer" or "the same buffer"?

I could be wrong but I don't think you need :demand block since you are already directly invoking global-ethan-wspace-mode upon loading. Similarly I don't think you need the :prefix block because ethan-wspace doesn't require helm-config and neither does anything else in this block. But neither of these things should prevent ethan-wspace from working effectively.

To troubleshoot, here are some things I would check:

• Are we sure that the :config section is running correctly? Can you confirm that the *Messages* buffer shows Global Ethan-Wspace mode enabled?
• ethan-wspace turns on different "helper" minor modes to check for individual failures of whitespace. Are those on? You can tell by looking at the modeline lighter for ethan-wspace, which will show something like ew:mnlt. Those letters which are capitalized represent whitespace which was detected as dirty. You can also check the value of variables ethan-wspace-highlight-tabs-mode, ethan-wspace-highlight-no-nl-eof-mode, ethan-wspace-highlight-many-nls-eof-mode, and ethanw-space-highlight-eol-mode, which should be true for the categories which are dirty.
• What does the face ethan-wspace-face look like? It might be possible that it's getting initialized to a color that isn't visible or something. You can see it using M-x describe-face RET ethan-wspace-face RET. Typically it should be the same as normal text but with a background that has a red tinge.

Do you have a repository with a complete .emacs.d that I can try to debug?

[rkachach]

@glasserc thanks for taking care of this. Inline replies. Please let me know if any further info is needed.

Hi, sorry for the delayed response! When you say "disable and re-enable the mode in the following buffer", what does "following" mean? Is it just a typo for "the existing buffer" or "the same buffer"?

I mean in the current buffer. Basically I run M-x ethan-wspace-mode twice to disable and then re-enable the mode. Once re-enabled the white-space is highlighted correctly (in red color, which is the default ethan-wspace-face configuration).

I could be wrong but I don't think you need :demand block since you are already directly invoking global-ethan-wspace-mode upon loading. Similarly I don't think you need the :prefix block because ethan-wspace doesn't require helm-config and neither does anything else in this block. But neither of these things should prevent ethan-wspace from working effectively.

To be honest, I just copied this configuration and wasn't sure of what it does. I remove these entries but still running in the same issue.

To troubleshoot, here are some things I would check:

• Are we sure that the :config section is running correctly? Can you confirm that the *Messages* buffer shows Global Ethan-Wspace mode enabled?

I put some (message "xxx") in the init file and I can see that the config section is executed correctly.

• ethan-wspace turns on different "helper" minor modes to check for individual failures of whitespace. Are those on? You can tell by looking at the modeline lighter for ethan-wspace, which will show something like ew:mnlt. Those letters which are capitalized represent whitespace which was detected as dirty. You can also check the value of variables ethan-wspace-highlight-tabs-mode, ethan-wspace-highlight-no-nl-eof-mode, ethan-wspace-highlight-many-nls-eof-mode, and ethanw-space-highlight-eol-mode, which should be true for the categories which are dirty.

I can see that ew:mnlt appears in my modeline. For the other variables I'm using the default configuration so I didn't change anything in the def configuration.

• What does the face ethan-wspace-face look like? It might be possible that it's getting initialized to a color that isn't visible or something. You can see it using M-x describe-face RET ethan-wspace-face RET. Typically it should be the same as normal text but with a background that has a red tinge.

I checked it and it's Red (the default value). I think the problem is not in the face since when I disable/re-enable the mode the bad spaces are shown correctly (red color).

Do you have a repository with a complete .emacs.d that I can try to debug?

Sure: https://github.com/rkachach/my-setup/tree/main/.emacs.d

[glasserc]

To be honest, I just copied this configuration and wasn't sure of what it does.

Out of curiosity, do you remember where you copied it from? if you copied it from someone else's configuration then maybe it's fine, but if it's from something "official" then maybe I should try to get it fixed.

I can see that ew:mnlt appears in my modeline. For the other variables I'm using the default configuration so I didn't change anything in the def configuration.

Does it appear literally like ew:mnlt? If the characters mnlt are lower-case, that would suggest that the file read as "clean" when ethan-wspace-mode initialized, which would explain why it wasn't highlighting the whitespace.

https://github.com/rkachach/my-setup/tree/main/.emacs.d

I cloned your my-setup repository to my laptop and ran it using env HOME=/home/ethan/tmp/software/rkachach-my-setup/ emacs. Then I used C-x C-f to find a file which I had just created using echo 'hi ' > trailing-whitespace. It seems like the eol whitespace is getting highlit correctly.

I do notice that the t in the modeline lighter is missing, which indicates that ethan-wspace-mode is not checking tabs, but that doesn't change when I disable and re-enable the mode, so I don't think that's related to what you're experiencing. (I guess it's because indent-tabs-mode is on, and ethan-wspace-mode disables treating tabs as errors when that's the case.)

Otherwise this seems normal to me. Maybe I misunderstood the behavior you were reporting. Are you talking about an existing file with pre-existing errors or something else?

[rkachach]

To be honest, I just copied this configuration and wasn't sure of what it does.

Out of curiosity, do you remember where you copied it from? if you copied it from someone else's configuration then maybe it's fine, but if it's from something "official" then maybe I should try to get it fixed.

Upss not really, I don't remember if it was the official place or someone else config. It's more likely to be the second but I'm not sure.

I can see that ew:mnlt appears in my modeline. For the other variables I'm using the default configuration so I didn't change anything in the def configuration.

Does it appear literally like ew:mnlt? If the characters mnlt are lower-case, that would suggest that the file read as "clean" when ethan-wspace-mode initialized, which would explain why it wasn't highlighting the whitespace.

yes, it's literally ew:mnlt.

https://github.com/rkachach/my-setup/tree/main/.emacs.d

I cloned your my-setup repository to my laptop and ran it using env HOME=/home/ethan/tmp/software/rkachach-my-setup/ emacs. Then I used C-x C-f to find a file which I had just created using echo 'hi ' > trailing-whitespace. It seems like the eol whitespace is getting highlit correctly.

Maybe I didn't explain my self clearly. Sorry, my bad. So the sequence to reproduce the issue is:

1. open a file (my init.el for example: rkachach/my-setup/blob/main/.emacs.d/init.el)
2. add a bad space at the end of some line
3. --> now the mode should highlight the bad spaces but it doesn't
4. disable/enable the mode in the current buffer --> bad spaces now are shown correctly in red face.

I do notice that the t in the modeline lighter is missing, which indicates that ethan-wspace-mode is not checking tabs, but that doesn't change when I disable and re-enable the mode, so I don't think that's related to what you're experiencing. (I guess it's because indent-tabs-mode is on, and ethan-wspace-mode disables treating tabs as errors when that's the case.)

BTW: all my tests are with spaces, I don't use tabs

Otherwise this seems normal to me. Maybe I misunderstood the behavior you were reporting. Are you talking about an existing file with pre-existing errors or something else?

[glasserc]

Thanks for the clearer steps to reproduce! Based on your description, I think what we're talking about is a feature, not a bug ;). The design of ethan-wspace-mode is to decide whether the whitespace in a file is "clean" or "dirty" already when the mode is activated. If the whitespace is "clean", we should keep it clean by automatically cleaning bad whitespace, and since we're automatically cleaning it, it doesn't need to be indicated in any specific way, since that whitespace will not be a part of the file when it is eventually saved. We only show whitespace when it's "dirty" (indicated by capital letters on the modeline). Under rare circumstances you may want to take a clean file and make it dirty for some category of whitespace, and you can do that by clicking on the letter for that kind of whitespace (or by invoking e.g. ethan-wspace-highlight-eol-mode).

So that's why it does the thing it does. Does that make sense? Does it cover your use cases? Or are you saying that even when bad whitespace is being cleaned automatically, it should show in red?

I think the central issue here is about documentation. I just reread the README for this package and I think it could be a lot more direct (and, well, a little more humble. I wrote it 12 years ago).

[rkachach]

I see, this is clearly a misunderstanding from my side of how the mode should work. I re-read more carefully the docs and this behavior is clearly described.

In practice I think the way it works right now is effective in the sense once you save the file it will clean-up all the "bad" spaces that were introduced while typing/introducing new changes in the file. And it should be OK as far as the mode is cleaning up correctly the spaces. At the same time, it may be confusing since the mode shows the spaces or not depending on the original state of the buffer (which is a smart behavior BTW). A user may think (as it happened to me) that the mode is not showing the bad spaces correctly. But again, no issues because docs are clear in this sense :)

I agree it's a feature since it doesn't affect the the mode and it's something that would be nice to have it as configurable. This way, the user can opt to activate this behavior or not.

In summary, I think we can close this issue or convert it to a feature-request.

PD: the doc intro is not humble but I like it: at least it put a good emphasis on how the author cares about spaces handling :)