Use 'comments' to ignore lines in block comments #31
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
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.
Previously when a file doesn't support C-style comments, we didn't detect any comments. Now we try hard to detect comments in all languages with syntax support. Using syntax means we don't need new code for new languages. However, syntax checking is very slow. Vim may take seconds to load large vimscript files (HasCommentSyntax was called 3000 times and it took like 8 seconds). Navigating Gblame was unacceptably slow since each revision was a new buffer that had to be re-detected. So syntax checking is a buffer-local option that can be turned on when you don't have a better way for checking comments (and they're always confusing DetectIndent).
Replace c-style comments special case with 'comments' vim variable and blacklist. 'comments' is very useful since it covers so many languages cases. If something doesn't work correctly, we can add it to the blacklist. The "&comments aren't reliable" comment comes from the initial import of detectindent, so I can't tell what problem was being worked around.
idbrii
changed the title
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.
You had a comment that
&comments aren't reliable, so I'm not sure if you want this feature. If you are interested in merging, then let me know and I'll do the work to remove the syntax detecting code. (From #3, I can tell you don't want to use syntax.)Builds on my PR #22. The last commit is the one I'm proposing here.