default .editorconfig in home directory about editorconfig-vscode HOT 10 CLOSED

I'm wondering if this issue could be reconsidered. I agree that the main reason may be to preserve style consistency in projects. However, sometimes I just open up one-off or scratch files with VSCode (aren't part of a project) and it would be great for a 'default' .editorconfig file in the home directory to be applied. This is actually how EditorConfig is supposed to work. From the EditorConfig site:

Where are these files stored?
When opening a file, EditorConfig plugins look for a file named .editorconfig in the directory of the opened file and in every parent directory. A search for .editorconfig files will stop if the root filepath is reached or an EditorConfig file with root=true is found.

EditorConfig files are read top to bottom and the closest EditorConfig files are read last. Properties from matching EditorConfig sections are applied in the order they were read, so properties in closer files take precedence.

Also, I don't understand @SamVerschueren's comment that this feature request doesn't apply to the plugin. The way I understand it, EditorConfig is just a spec for configuring code styling and it's up to the code editors to implement that configuration, and the way VSCode implements it is via this plugin (note that the quoted passage above from the EditorConfig site states "EditorConfig plugins look for a file named .editorconfig...").

from editorconfig-vscode.

EditorConfig is meant to be present in every project to make sure every member of the team uses the same style.

This also isn't something that should be discussed in the VS Code plugin as it is a global EditorConfig feature request.

from editorconfig-vscode.

@tony-garcia Per my understanding, any file under the home directory, if no root=true is given, should follow what ~/.editorconfig has defined. Is this what you are requesting?

from editorconfig-vscode.

@tony-garcia I don't understand how we understand it is different... You often put most of your projects under your home directory, and for those projects who don't add root=true or don't contain any .editorconfig files, you automatically have ~/.editorconfig applied. What is your example out of your expecting?

from editorconfig-vscode.

Closing, as this is not a plugin-specific issue.

from editorconfig-vscode.

Not exactly. The way I understand the text I quoted in my prior comment (from the EditorConfig site), is that the plugin should first look for an .editorconfig file in the same directory as the opened file and then it should keep searching in parent directories (all the way to the root directory) until an .editorconfig file with root=true is found or the root directory is reached. It can then use all .editorconfig files found by first applying rules from the "furthest" .editorconfig file and then as they get closer to the file being edited, properties can override ones from other config files.
This enables someone to have a root .editorconfig that applies to all files and then if you want, you can apply more specific rules by having .editorconfig files closer in the directory structure to the file being edited.
The .editorconfig functionality in Jetbrains IDEs (for example WebStorm), work exactly this way, but unfortunately the VSCode plugin doesn't.

from editorconfig-vscode.

I understand that it's different because you seem to be talking about specific situations while I'm trying to get across how it should work in general.
For example, you asked if there is a project somewhere under the home directory that doesn't have an .editorconfig or one in which 'root=true' isn't specified whether ~/.editorconfig should automatically be applied. Well the answer to that is maybe and maybe not. Or maybe it's partially applied. Is there another .editorconfig file somewhere in the directory tree as you traverse from your project directory to your home directory? If so, then that one is one of the files that get applied. Then the plugin should keep going up the directory tree until it reaches the root of the filesystem (not your home directory) OR finds an .editorconfig with root=true. It then should take ALL of the .editorconfig files found before stopping and apply them starting from the furthest out and then overriding/adding settings as it gets closer to the file that you have open in the editor.
So, for example. Let's say you have a file in /home/xhudev/projects/myproject/app.js. First the plugin should check the ~/projects/myproject folder for an .editorconfig. If one is found there and it has root=true specified, then it stops and it uses that one. Let's say that it finds one but it doesn't have root=true. Does it then automatically go to try to find an ~/.editorconfig file (or, to be clear /home/xuhdev/.editorconfig)? No, it doesn't. It keeps traversing up and checking in the /home/xuhdev/projects folder. Then /home/xhuhdev (or ~/). You get the idea. And it shouldn't stop at ~/ (which is /home/xuhdev) -- it should keep going to the root of the filesystem. Let's say that it does happen to find one at ~/.editorconfig and that one has root=true. It should stop searching there. But it doesn't just simply apply that configuration. It should apply that one FIRST. Then it should apply the rules found in the /home/xuhdev/projects/myproject/.editorconfig file that it found earlier, adding and/or overriding any settings found in the 'root' ~/.editorconfig.
In this example, there were two .editorconfig files, one in the project folder and one in the home directory. But it doesn't have to be this way. There's nothing magical about the home directory. Someone could put the file at /.editorconfig (at the root of the filesystem). Or we could've found one in the ~/projects directory (without root=true), so the plugin would have 3 .editorconfig files to apply.
Hopefully this makes it more clear what I'm talking about. I think the passage I quoted directly from the EditorConfig site makes it pretty clear, so here it is again and let me know if you think I misinterpreted what it's saying:

Where are these files stored?
When opening a file, EditorConfig plugins look for a file named .editorconfig in the directory of the opened file and in every parent directory. A search for .editorconfig files will stop if the root filepath is reached or an EditorConfig file with root=true is found.

EditorConfig files are read top to bottom and the closest EditorConfig files are read last. Properties from matching EditorConfig sections are applied in the order they were read, so properties in closer files take precedence.

Again "EditorConfig plugins look for a file named .editorconfig in the directory of the opened file and in every parent directory" (not just the home directory). Also note that it should search until the root filepath (not stop at the home directory), or a config with root=true is found. The second passage is where it talks about how you can have multiple config files applied in an ascending order of preference as they get closer to the edited file. In your comments you didn't mention this and only talked about either a config file in the project folder or one in the user home directory being applied, so I wanted to make sure that was clear.

from editorconfig-vscode.

@tony-garcia, I realize you're trying to be more general than specific, but I think it's adding more confusion than clarity. In this case, I think it would help to give only ONE real-world example of which EditorConfig does not do "what you think it should do" and let that example serve as a "failing test", if you will.

I don't know the specifics of the JetBrains IDE support for EditorConfig, but I can tell you that this vscode plugin uses the js core, published as npm#editorconfig, so it might help to see if you can reproduce the issue first with just the core in your shell or terminal. If you can, please file an issue on the js core issues. If not, please file a new issue on this repo, as your issue is slightly different than the original post here.

I think the real-world example will also serve well in clarifying whether this is actually by design or not.

from editorconfig-vscode.

ok after further testing. It turns out that the editorconfig plugin is actually working the way it should (sort of). The reason I thought it wasn't working was this: I created/opened a javascript file in a 'scratch' directory (with no .editorconfig) using the command line:

code test.js

When I did this and just started writing code, I assumed that my .editorconfig settings in my home directory (~/.editorconfig) would apply, but they weren't. So I assumed that the plugin wasn't finding my 'base' editorconfig. But then after some testing I realized that, after opening a new file and then SAVING the file (before I started typing any code), then the .editorconfig settings were being applied. (I also did some tests to make sure that multiple .editorconfig files would be applied).
I guess this kind of makes sense because when creating a new file like this, the file doesn't actually exist on the file system until that initial save (it's just a file buffer loaded into the editor). So it seems like when EditorConfig it looks for what rules to apply to what files, it looks at the extension in the file system and without that it doesn't apply any of the rules.
Seems kind of weird and nonintuitive, but is likely an implementation detail of the editorconfig-core-js library you mentioned and not a problem with the plugin. Now that I know how to 'work around' it, I'll be fine.
Thanks for your work on this plugin and hearing me out and sorry for any confusion.

from editorconfig-vscode.

Glad you figured it out and that all sounds accurate to me. Without an actual file on the file system, EditorConfig definitely wouldn't know what to do.

from editorconfig-vscode.