Overzalous whitespace cleanup despite settings in `init.el`

[grendello]

Description :octocat:

Spacemacs appears to ignore the dotspacemacs-whitespace-cleanup setting for some files in a number of modes.

Reproduction guide :beetle:

• Set dotspacemacs-whitespace-cleanup to changed
• Start Emacs
• Open a file with extra whitespace throughout it (e.g. https://github.com/xamarin/xamarin-android/blob/master/src/Xamarin.Android.Build.Tasks/Xamarin.Android.Common.targets)
• Type something (anything) on any line
• Save file

Observed behaviour: :eyes: :broken_heart: The extra whitespace outside the line that was just change is stripped on save. Additionally, the save removes the BOM from the start of the file. My Emacs is configured to open the .targets file in nxml mode, but the stripping also happens in C++, C# and plain text modes. It is a regression, however I cannot tell when it was introduced :( I noticed it a month or so ago. As much as I don't like the extra whitespace :), the behavior is a real annoyance when dealing with files like the one linked to above since any edit introduces lots of noise irrelevant to the actual changes.

Expected behaviour: :heart: :smile: Whitespace on lines not touched by editing is left intact.

System Info :computer:

• OS: gnu/linux
• Emacs: 26.3
• Spacemacs: 0.300.0
• Spacemacs branch: develop (rev. b25526149)
• Graphic display: t
• Distribution: spacemacs
• Editing style: emacs
• Completion: helm
• Layers:

  (yaml javascript helm
    (auto-completion :variables auto-completion-complete-with-key-sequence-delay 0.4 auto-completion-enable-sort-by-usage t auto-completion-enable-snippets-in-popup t)
    better-defaults emacs-lisp emoji dash asm
    (c-c++ :variables c-c++-adopt-subprojects t c-c++-enable-clang-support nil c-c++-backend 'lsp-ccls c-c++-lsp-sem-highlight-method 'font-lock c-c++-lsp-sem-highlight-rainbow nil)
    semantic csharp dart
    (cmake :variables cmake-enable-cmake-ide-support nil)
    (lsp :variables lsp-enable-indentation nil lsp-enable-on-type-formatting nil lsp-ui-sideline-enable nil lsp-auto-guess-root t)
    git gpu markdown multiple-cursors treemacs org
    (python :variables python-backend 'lsp)
    (shell :variables shell-default-height 30 shell-default-position 'bottom shell-default-term-shell "/bin/bash")
    syntax-checking shell-scripts themes-megapack version-control windows-scripts groovy treemacs)

• System configuration features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS LIBSYSTEMD LCMS2

[humanfactors]

Is the behavior occurring because your Emacs config/settings are default saving to UTF-8 without BOM (i.e., check your settings), in effect changing all lines in the file, so whitespace cleanup cleans everything?

[grendello]

All the config/settings values pertaining to UTF-8/Unicode are at their default values (whatever the config variables are, I couldn't find any :D), I don't have any settings modifying that behavior in my init.el

[Blaisorblade]

I have the same issue, at least on LaTeX files: dotspacemacs-whitespace-cleanup, even set to changed, cleans up all whitespace as soon as the file is saved (after any change).

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

[Blaisorblade]

Still observing this with dotspacemacs-whitespace-cleanup 'changed — (as of spacemacs 76301564c5fa6fbd4a9a07ef35529d931aecd367); later commits messages don't mention "whitespace".

[Blaisorblade]

Seems either @github-actions is buggy, or admins have to react to comments by hand. I accept the defacto bug bankruptcy.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!