Don't highlight +/- columns in patches (configurable) (take 2) #7
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Now a BadWhitespace highlight is always created independently of the filetype and the configuration of the file you start with. Fix error about missing color.
You can now suppress highlighting of the first (and second in case of a combined
diff) column for selected filetypes, by setting the following variable
let g:bad_whitespace_patch_filetypes = ['diff', 'git']
The given value is the default.
If you like to toggle colors by re-linking, you can now specify the
default highlight for trailing whitespace in:
let g:bad_whitespace_color_default = 'BadWhitespaceDefaultState
The given value is the default link target if you don't create that
variable.
In the hunk header, Git uses a count of '@' characters that is equal to the number of parents plus one. That seems to be generally sensible. Count those characters and start the bad-whitespace match after that column.
If the +/- column width could not be derived from the hunk header, the value of g:bad_whitespace_patch_column_width_fallback will be used. The default is 0. This could be useful if a patch is build up programmatically.
Add a command that writes the bad-whitespace pattern to the '/'
register. This way you can jump to an error by creating a mapping like
this:
nnoremap <Leader>W :<C-U>SetSearchPatternToBadWhitespace<CR>n
One assumes that only the highlighted whitespace will be removed by that command.
There might be further pattern getters. Rename the original function to s:SetBufferSpecificPatternPrefix() which indicates that it does not set the full pattern.
It is now possible to specify filetypes for which no trailing space will
be highlighted initially. An example for the new variable:
let g:bad_whitespace_off_filetypes = ['text', 'markdown']
Clear autocommands when hiding whitespace.
Do that also before creating new ones to always have a clean slate.
This works for buffers loaded retroactively.
This is getting a bit experimental, but it looks like it works. A use case is to have a faint color in files where you don't care about trailing highlights that much (notes). Or maybe files that require trailing whitespace (although the filetype specific coloring should handle that). It can be used in 'gitcommit' buffers created with 'git commit --amend --verbose' where you don't want to be distracted by the patch column but still want to see whitespace errors in the message.
This is generally cleaner. Use lists to hold both patterns for a buffer. Rename functions and the variable accordingly
Trailing lines look a bit ugly because the newline on the last non-empty line is highlighted instead of the very last line.
This message can bother a bit. When zero there is no bad whitespace hidden from the user.
|
Thanks, I'll try to look at this when I have some time |
It was never a colorscheme
This frees the :match highlighting for ad-hoc usage and will generally facilitate adding other matches independently from bad-whitespace.
Every buffer has a variable that determines if bad whitespace should be displayed or not. The display will be synced on WinEnter. I expect the common use case is to either permanently view them or not. So this should work out fine in most cases. A window-specific variable would be initialized with the default on each split which is presumably not what is wanted.
Obtain the default during buffer-init instead of turning the display off later. Rename accordingly.
This will now also sync toggling of unmodifiable buffers
Remove the force argument from some functions. Show/Hide does now always change the display state. Previously, it was used do differentiate an explicit change request by the user from window/buffer setup, but the buffer setup is now only done once and windows are synced on enter.
This will apply the on/off setting when the filetype is set retroactively.
Vim-Bad-Whitespace can be replaced with Vim-Match-Control. The latter offers a more general solution and allows you to have multiple highlighting control units, as it were.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The highlighting of the +/- column was bothering me to the point where I turned it off completely. You often see patches when using vim-fugitive. So this will allow you to configure filetypes where the first and second column won't get highlighted.
I use the color link to switch to faint colors in sessions where it doesn't matter and to toggle between colors. I think it's useful, too.