Skip to content
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

Allow to configure settings per file type #11879

Closed
rothskeller opened this issue Sep 12, 2016 · 13 comments
Closed

Allow to configure settings per file type #11879

rothskeller opened this issue Sep 12, 2016 · 13 comments
Labels
*duplicate Issue identified as a duplicate of another issue(s) feature-request Request for new features or functionality
Milestone

Comments

@rothskeller
Copy link

  • VSCode Version: 1.5.1
  • OS Version: OS-X 10.11.6

Currently, the configuration switches that control indentation (editor.tabSize, editor.insertSpaces) can be configured globally or per-workspace. But it's not unusual to work on different types of files within the same workspace that need different indentation styles. For example, Go source files always use tabSize=8, insertSpaces=false (it's a language standard), but the same workspaces very often contain other types of files (e.g. Markdown, HTML, JavaScript, etc.) where those are not the desired settings. It is irritating to have to set the indentation style manually whenever creating a new file. Instead, the indentation settings should be language-specific, rather like snippets.

@DanTup
Copy link
Contributor

DanTup commented Sep 12, 2016

This is a similar issue to #2765 where the response was for the Go extension to explicitly set the indent settings. I have to do the same for Dart but I think it's a bit naff and would be a good feature for Code to support natively.

@rothskeller
Copy link
Author

Well, there's two problems with that. First, I raised that request with the Go extension author. @lukehoban , (see here), and he indicated that he didn't think it was possible — or advisable — for an extension to override core customization settings in this way. So if the vscode maintainers think that's the right answer, it would be nice if they could connect with him and make sure he knows that and knows how.

More importantly, that might be a reasonable answer for Go where the language dictates the indentation style, but it's less desirable for other, more flexible languages. Suppose that I want to have my Python sources with four-space indent but by YAML sources with two-space indent. Does the author of every language extension need to provide ways to override the core settings for their language? Wouldn't it make more sense to centralize that — especially since the core already has a way to do language-specific things (e.g. snippets)?

@DanTup
Copy link
Contributor

DanTup commented Sep 12, 2016

Like I said, I completely agree. I think both users and extension authors should be able to set it (the current mechanism is absolutely a hack)!

@bpasero bpasero self-assigned this Sep 13, 2016
@bpasero bpasero changed the title indentation configuration should be customizable by file type Allow to configure settings per file type Sep 13, 2016
@bpasero bpasero added feature-request Request for new features or functionality workbench labels Sep 13, 2016
@bpasero bpasero added this to the Backlog milestone Sep 13, 2016
@bpasero bpasero removed their assignment Sep 13, 2016
@analogrelay
Copy link
Member

This is also essential when trying to edit Makefiles since they MUST use tabs, regardless of the user's preference.

@gwk
Copy link

gwk commented Oct 13, 2016

Another concrete example: I like the files.trimTrailingWhitespace option for most source files, but for some file types (e.g. patch files) stripping out whitespace introduces errors.

@nomaed
Copy link

nomaed commented Oct 14, 2016

I am using .editorconfig for this and it works great. Also compatible across different editors and IDEs.

Extension: https://github.com/editorconfig/editorconfig-vscode
Spec: http://editorconfig.org/

@bwinton
Copy link

bwinton commented Nov 15, 2016

I'm also running into this editing Javascript (2-space tabs), HTML (4-space tabs), and README.md (word-wrap on)… Sadly, editorconfig doesn't support wrapping yet, although it looks like it does most of the other stuff I want.

@mkurnikov
Copy link

It also could be helpful with disabling IntelliSense for the plain text files, like .txt and .md, it was mentioned here:
#10819

Or disable similar matches to the selection for the same files.
Plain text files aren't really semantically the same as source code files, there has to be a way to override settings specifically for them.

@fredrikaverpil
Copy link

fredrikaverpil commented Nov 25, 2016

It would be very useful to set vertical rulers like this only when working with *.py files:

{
    "editor.rulers": [72, 79]
}

...as this indicates row lenghts according to PEP8 which is a popular guideline among pythonistas.

@exdeniz
Copy link

exdeniz commented Dec 26, 2016

And another example: disable quickSuggestions for specific file types.

@eromoe
Copy link

eromoe commented Dec 29, 2016

I am using https://github.com/tzvetkoff/sublime_stupid_indent in sublime, which can force html,js ,css, scss , json in size 2, others in 4 by config, maybe vscode can take a similar way like that.

PS: though it can't not recognise current file is plain javascript or es6(babel), I hope vscode can do this too.

@eromoe
Copy link

eromoe commented Dec 29, 2016

I find vscode have a similar extention:
https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig
But it isn't global settings, need generate editorconfig for each project.

@sandy081
Copy link
Member

sandy081 commented Jan 4, 2017

Will be implemented by #1587.

@sandy081 sandy081 closed this as completed Jan 4, 2017
@sandy081 sandy081 added the *duplicate Issue identified as a duplicate of another issue(s) label Jan 4, 2017
@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 18, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
*duplicate Issue identified as a duplicate of another issue(s) feature-request Request for new features or functionality
Projects
None yet
Development

No branches or pull requests