Open
Conversation
Add s:SetIndent() so we can set our desired indentation consistently. It always sets expandtab and sets widths only if valid (positive nonzero). I'm following the advice laid out on the 'tabstop' help about when softtabstop is set and ensuring some settings have the same value. That documentation recommends using softtabstop with noexpandtab and not with expandtab. (Whereas detectindent used to do the opposite.) TODO: I'm no longer convinced that my reading is correct in this case since softtabstop isn't useful when tabstop and shiftwidth are the same. Maybe I should always set it?
shiftwidth=0 keeps it in sync with tabstop, but that breaks many indentation plugins that read 'sw' instead of calling the new shiftwidth(). See tpope/vim-sleuth#25 Or try indenting this vimscript file on Vim 7.4.
Always set softtabstop. This is more consistent with previous behavior and from reading the softtabstop help seems to make more sense that we set all of these values to the same thing. In the case where we find both tabs and spaces, now we set expandtab as described in ciaranm#2: 2. Set 'tabstop' and 'shiftwidth' to whatever you prefer and use 'expandtab'. This way you will always insert spaces. The formatting will never be messed up when 'tabstop' is changed. Alternatively, we could follow ciaranm#1 and set tabstop=8 (instead of guessing) and use noexpandtab: 1. Always keep 'tabstop' at 8, set 'softtabstop' and 'shiftwidth' to 4 (or 3 or whatever you prefer) and use 'noexpandtab'. Then Vim will use a mix of tabs and spaces, but typing <Tab> and <BS> will behave like a tab appears every 4 (or 3) characters. That's what vim-sleuth does, so why copy their recipe? Guessing is probably more useful to users.
Default detectindent_preferred_indent behavior (0) is to retain current
tabstop. But on a file containing only tabs, and user's default is to
use shiftwidth=4, we end up with
softtabstop=4, shiftwidth=4, tabstop=8, noexpandtabs
Which means we insert tabs, but indent with >> inserts only half a tab
(inserting 4 spaces). This madness occurs in python files containing
tabs with g:python_recommended_style undefined or 1.
Contributor
Author
|
I found a bug with tabs-only files and added the fix to this PR. |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Move applying indent settings into a single function to ensure we set them consistently.
Currently, there's some variance between which settings are applied. This ensures we always set values consistently. I'm trying to make us follow the guidelines in :help tabstop.
This PR changes behavior to set expandtab when we find both tabs and spaces. That case sets tabstop after calling SetIndent which is a bit weird, but presumably the guessing behavior is more useful than forcing tabstop=8.
Also, set softtabstop=-1 on supported versions of vim.