Incorrect indentation

[John-Colvin]

When I run editorconfig manually on a file, it shows the correct settings:

charset=utf-8
end_of_line=lf
insert_final_newline=true
trim_trailing_whitespace=true
indent_style=tab
indent_size=4
tab_width=4

but when I load the file in vim and try to indent some text, it indents by a single space.

I tried turning on verbose mode to get more info by adding let g:EditorConfig_verbose = 1 to my vimrc, but I don't seem to get any output, even when I e.g. run EditorConfigReload.

[xuhdev]

@John-Colvin The latest version has now added some more verbose info when you turn on verbose. Can you try with the latest version again? Thanks!

[John-Colvin]

I still don't get anything printed, either when loading files or manually running EditorConfigReload. Where am I expecting to see the verbose output?

[davidosomething]

check that editorconfig is the last thing to set your vim whitespace settings: command mode:

:verbose set tabstop?

should say last set by editorconfig

[John-Colvin]

  tabstop=4                                                            
        Last set from ~/.vim/bundle/editorconfig-vim/plugin/editorconfig.vim 

[davidosomething]

and what about the rest of the whitespace settings? expandtab, shiftwidth, softtabstop? was editorconfig the last to modify those too?

[John-Colvin]

yes, they are all set by editorconfig, to the right values

[xuhdev]

If they are all right values, why does it not work as expected? What if you disable EditorConfig and manually set these values?

[strk]

I get TAB indenting whenever "indent_size" is specified, even if "indent_style = space". Does it need a different ticket ? (as it's still about incorrect indentation).

The "editorconfig" command output when things work:

charset=utf-8
end_of_line=lf
trim_trailing_whitespace=true
insert_final_newline=true
indent_style=space

When it doesn't work:

charset=utf-8
end_of_line=lf
trim_trailing_whitespace=true
insert_final_newline=true
indent_style=space
indent_size=2
tab_width=2

I didn't write the "tab_width" myself, just the "indent_size", which according to http://editorconfig.org/ should determine the amount of spaces when used in conjunction with "indent_style=space".

[xuhdev]

@strk Your configuration should be fine (harset in your first example should be charset). So all you would say is that if you add indent_size, then it won't work, is it correct? Yes, tab_width is supposed to be there after being processed by the command line tool. What is your output of echo &l:expandtab in case it does not work?

[strk]

The harset was a paste error, now fixed. Yes, I'm saying it won't work correctly if I add indent_size as it would use tabs instead of spaces. Removing indent_size gives me space indent back. The presence of tab_width has no influence on the behavior, no matter what value it takes.

echo &l:expandtab returns 1 in both cases (when working and when not working)

[strk]

Wait, I just figured out I was WRONG, it's not TABS that I'm seeing, but rather just an automagic way of VIM to deal with soft tabs. Sorry for the confusion, with a binary editor I see they are still spaces, even if a single backspace removes all of them !

[xuhdev]

@strk Thanks for the clarification! @John-Colvin Maybe you actually have faced the same issue?

[strk]

@xuhdev still I wonder why "indent_size" itself does not give the same "single backspace deletes all spaces making up a tab", given it does insert multiple-spaces on a single TAB keypress. What's the rationale for making a distinction based on indent_size ? Isn't the lack of indent_size just a sign that a default size is used ?

[xuhdev]

@strk I don't quite understand your question. If indent_size is not set, then the indentation size would depend on your editor configuration---EditorConfig won't touch it. If indent_style is set, then expandtab is set accordingly.

[strk]

@xuhdev so what does indent_style = space do ?

[xuhdev]

@strk setl expandtab

[zakkudo]

This seems to work from what I've seen. However I've seen selectors like [*.{js}] fail as compared to [*.js]

[cxw42]

@zakkudo Thanks for reporting! If you find a repeatable test case for the selector problem, please open a new issue. Closing this issue.