-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should only touch modified lines? #106
Comments
I somewhat agree with you, but it seems like all other plugins (AFAIK) implement as what this one is doing. In this case, should we correct the FAQ? For your case, I think it is better to add a new value, say |
I'm not really sure if such a setting belongs in editorconfig, or should be plugin-specific. You could say that editorconfig contains the preferences of a project about how the files should look, while this is a preference of a user that indicates how (aggresive) to get to this ideal state. Also, this does not seem like a setting limited to the the Looking at the rest of the settings, there are more settings where this distinction (fix-everything or only fix-changed-lines) could be relevant, though none of them seem as clear-cut:
Again, I'm not sure how much of this stuff belongs in editorconfig and how much is plugin-specific, but it might be useful if the editorconfig spec makes some recommendations about how to implement this. I would argue for a conservative fix-changed-lines approach by default, while also recommending editors to offer an explicit "fix-everything-now" command as well. |
I've gotten around this via |
I'm not sure if mixed-indent model makes sense, otherwise what's the purpose of Full file |
For indents, this indeed does not make too much sense (ideal would be to match the indent to the surroundings if it does not match However, for trailing whitespace, it can make sense to fix lines incrementally, when these lines are edited for other changes anyway (perhaps followed by a small cleanup-only commit after a while). |
LOL, it's what happens when I try to look smart before the morning coffee 👍 Yep, I would agree, trailing whitespace can be handled incrementally. Even though...
still ftw, maybe? One-shot codebase cleanup (mod extension whitelist to suit your needs). |
I've hit this sometimes but I didn't expect to change plugin or standard, if a project provides a |
FWIW, this can be achieved using https://github.com/ntpeters/vim-better-whitespace, which supports stripping only modified lines (relies on external diff command to identify modified lines)... " Disable editorconfig trim_trailing_whitespace, use better_whitespace
let g:EditorConfig_disable_rules = ['trim_trailing_whitespace']
" Automatically strip whitespace on save using better_whitespace plugin
let g:strip_whitespace_on_save = 1
" Only strip whitespace on modified lines and don't ask for confirmation
let g:strip_only_modified_lines = 1
let g:strip_whitespace_confirm = 0
" Use editorconfig hook to automatically enable/disable whitespace stripping
function! <SID>EditorConfigHook(config)
try
let l:trim_trailing_whitespace = a:config->get('trim_trailing_whitespace')
if l:trim_trailing_whitespace == 'true'
exec 'EnableStripWhitespaceOnSave'
elseif l:trim_trailing_whitespace == 'false'
exec 'DisableStripWhitespaceOnSave'
endif
catch
echo 'EditorConfigHook Failed: ' . v:exception
endtry
return 0 " Return 0 to show no error happened
endfunction
call editorconfig#AddNewHook(function('<SID>EditorConfigHook')) |
I just opened a file in a project that uses
trim_trailing_whitespace=true
. I made some changes to the file, and after saving it found that all lines had been stripped of trailing whitespace, not just the ones that I touched.This is of course very annoying when you have files in version control, where you do not want to be faced with a lot of unrelated changes (of course files should be ok in the repo to begin with, but it's not an ideal world we live in).
It seems this is also the intention of the editorconfig spec. Their FAQ says:
Could something like this be implemented? Perhaps the current behaviour could be enabled by an option (or an explicit command that does a one-off run to fix all formatting)?
The text was updated successfully, but these errors were encountered: