[vim/vim] ftplugin/scss.vim wrongly pulls shiftwidth setting from ftplugin/sass.vim (Issue #15366)
Renato Caldas
Steps to reproduce
- Put this anywhere in your vimrc:
set shiftwidth=4
- Create and edit a
test.scssfile with the following content:
html {
margin: 0;
}
- With the cursor over
margin: 0, pressShift+== to autoindent, the line will be indented to only 2 spaces.
Expected behaviour
Just like with css, the editor should keep indentation at 4 spaces.
Problem:
When editing scss files, vim ignores the global shiftwidth settings and overrides it to 2.
I've noticed that ftplugin/scss.vim just loads the full ftplugin/sass.vim, and in the latter uses the option sass_recommended_style to control whether or not to override the global setting.
I'd argue that scss is much closer to css than to sass, and forcing a specific shiftwidth for scss makes little sense. So perhaps defaulting sass_recommended_style to 0 for scss would be a simple fix.
That said, I couldn't find any official "recommended" style for sass, or any other reason to force shiftwidth to be 2 spaces. So honestly I think the following section should just go away:
if get(g:, 'sass_recommended_style', 1)
setlocal shiftwidth=2 softtabstop=2 expandtab
let b:undo_ftplugin .= ' sw< sts< et<'
endif
Version of Vim
9.1
Environment
OS: Linux (Arch)
Terminal: alacrity
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Clason
This was added in a907c91 by the maintainer, @tpope
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Tim Pope
This was added in a907c91 by the maintainer, @tpope. Upstream is https://github.com/tpope/vim-haml.
Note that this only added the option to disable. The 'shiftwidth' default was previously in the indent plugin, and had lived there since the file was first created in 2008. Back then, Sass was still firmly rooted in the Ruby community, and values other than 2 were basically unheard of.
Times change, but it's not clear to me they've changed enough to rip this default out entirely. I'd say Sass and SCSS are in the same bucket as Yaml, where 2 is still the most common default. And the Yaml ftplugin has a recommended_style option, just like Sass.
If I were to propose something, it would be to standardize on a fallback g:recommended_style option, so that people that hate this sort of thing can opt-out once and for all.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Renato Caldas
Times change, but it's not clear to me they've changed enough to rip this default out entirely.
I understand your point, and I agree with keeping the SASS defaults until a stronger case is made (if ever). From what I understood, it's being phased out in favor of SCSS anyway.
That said, SCSS is an entirely different beast: the official documentation states it is a superset of CSS:
Sass has two syntaxes! The SCSS syntax (.scss) is used most commonly. It’s a superset of CSS, which means all valid CSS is also valid SCSS. The indented syntax (.sass) is more unusual: it uses indentation rather than curly braces to nest statements, and newlines instead of semicolons to separate them. All our examples are available in both syntaxes.
In this case I'd say there's a strong argument for removing the defaults, keeping it close to CSS. The syntax bears little resemblance with ruby, and it doesn't have its own recommended_style.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Renato Caldas
Any news on this? Thanks!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
you want to discuss this on the upstream repo
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.