GNOME Bugzilla – Bug 589366
Show whitespace differences in inline highlighting
Last modified: 2017-12-13 18:51:28 UTC
It would be nice if the file diff view could (optionally) highlight trailing whitespace, so that users notice if they made a change that would introduce this. Some kind of "squiggly underline" or bold red text could be used for highlighting. Personally, I use Meld for reviewing changes before committing, so it is the last stage where such mistakes could be caught. Some editors already show trailing whitespaces, but some don't; so I always check for trailing whitespace "manually" in the diff view, and it would be neat if Meld would help there.
Created attachment 139032 [details] [review] highlite trailing whitespace at EOL This is absolutely brute-force-y, if someone has a better idea or patch...
TO MAYBE DO: preferences to control the behavior (and maybe avoid the costs) * enable / disable * only inside diffs / everywhere
Presumably we don't want to just highlight EOL whitespace, but rather *changes* in whitespace at EOL. This would involve messing with the inline diff mechanics.
Created attachment 139033 [details] [review] fix occurrences of trailing ws inside meld code If we want to fix the bug, we should fix meld source code not to show red line endings everywhere... There's a few totally legitimates fixes in this could-have-been-made-with-sed patch, but also a bunch in comments or docstrings, do we want them all or should I filter a bit ?
Applying such patches just pollutes the git history with meaningless changes. A better approach is to fix trailing whitespace whenever you modify the offending bit of code. e.g., before you push, make sure you pipe your patches through 'git diff | git apply --whitespace=fix -' Alternatively, you can turn on a git pre-commit hook so that it won't *let* you commit EOL whitespace changes. I believe that the sample pre-commit hook shipped with git does exactly this.
In bug 744179, GtkSourceView has added the ability to toggle draw whitespace based on tagged text. The easiest and best way to fix this bug (and other requests) would be to toggle the draw-whitespace property in our GtkTextTag that we already use for doing inline highlighting. This should be trivial once we require GtkSourceView 3.20 (or we can add it conditionally with a feature detect). The only extra thing we might want to do would be to also apply a new tag to insert chunks to highlight whitespace that's been *added*. I'm not sure whether that makes as much sense though.
I've just pushed a change to master that does the above. I'm not certain whether this will stay in, because the contrast issues between the coloured background and the low-contrast foreground used for the whitespace are... pretty bad. If we can figure out a sane way to make the whitespace drawing be more obvious then I imagine this will stay.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/meld/issues/18.