zed

zed copied to clipboard

EditorConfig is somewhat of an industry-standard these days. Although not a priority for me, you might want to take into consideration being compatible with existing EditorConfig configurations.

I switch between a project that uses tabs and a project that uses spaces multiple times a day and I have to remember to jump into my Zed config and change the global setting each time.

For what it's worth, Zed now supports folder-specific configuration (via a .zed/settings.json file). https://docs.zed.dev/configuration/configuring-zed#folder-specific-settings

The reason we implemented that instead of EditorConfig, is that EditorConfig is pretty limited in what it can express, whereas with our own settings.json file, we can add local support for any Zed setting, in a way that is consistent with the global settings file. EditorConfig also uses an idiosyncratic, bespoke file format that is slightly different than TOML, whereas with settings.json, we can use the normal JSON autocomplete and in-editor diagnostics.

Implementing .editorconfig is less of a user customization problem but more of a cross-editor collaboration issue.

I understand that it makes more sense to implement project-specific .zed/setting.json, but projects impose .editorconfig in their source code repo to enforce a coherent code style. As .editorconfig is almost an industrial standard now, Zed users would need to config each project manually every time if there are no builtin .editorconfig support.

Supporting .zed/settings.json is great. I agree it would be nice to have .editorconfig support to save time when working with open-source projects, but it looks like this has been tagged as a potential plugin. I hope this means we'll soon be able to develop plugins for Zed.

Folder-specific configuration is handsome! 👏

However, for all the good reasons above, I'd still keep this issue open as something to consider to implement at some point in future.

Lack of editorconfig support is now the only blocker for me to start using this as my default editor. I work with too many shared repos to "just" set up custom settings for each to mirror its editorconfig.

I got a really small ball rolling with this script (gist) that intents to generate a .zed/settings file from a local .editorconfig file.

If you're using Prettier, .editorconfig is still a nice to have, but you can live without it for now and configure Zed to format with Prettier upon saving:

{
  "formatter": {
    "external": {
      "command": "node_modules/.bin/prettier",
      "arguments": ["--stdin-filepath", "{buffer_path}"]
    }
  }
}

@steve-taylor sure, thanks.

There is already a lib that could handle the parsing: https://github.com/TheDaemoness/ec4rs. I don't know if it is well known enough for Zed, but might worth a shot. And now that Zed is OSS, maybe @TheDaemoness would even be interested in that contribution ?

If there's interest from the maintainers, I could look into integrating ec4rs into zed (as a plugin? Please advise).

+1 for supporting .editorconfig. It's important for working with multiple projects and teams.

I would like to use Zed as my daily driver, and the lack of support for .editorconfig is the only thing preventing me from doing so.

@JosephTLyons do you plan on having rust interaction capable extensions ?

Also TBH it still feels like it should be out of the box to me (as it is in many places). This is kind of a standard, and it would help a lot to have it not being an extension to ensure people are following project guidelines correctly!

Also TBH it still feels like it should be out of the box to me (as it is in many places).

The aim is to move the majority of languages to extensions, separating development and improvements from Zed. Then, pick multiple language extensions that can be used out of the box.

@JosephTLyons do you plan on having rust interaction capable extensions ?

Also TBH it still feels like it should be out of the box to me (as it is in many places). This is kind of a standard, and it would help a lot to have it not being an extension to ensure people are following project guidelines correctly!

It still could be a language we ship directly - we havent fully decided which languages will be ultimately shipped and which ones will be made into extensions - I just moved all language requests into this repo to clean up the issues in the Zed repo. We can always move things into Zed, if it makes sense.

I think there is a confusion here. The support of the editor config language is not the most important. What matters most is that it is used by zed to properly format the code. Hence I'm not sure it is about the language more than it is about the integration into Zed's settings.

I don't want to talk for everyone, but for me that's the most important part.

Yes, it's about supporting the editorconfig file for defining editor settings.

As far as the language goes, I'm pretty sure it is just standard ini.

Yes, this issue is about making .editorconfig act like a .zed/settings.json file. Support for the INI language is, in my opinion, a much lower priority, and it’s not what this issue is about.

I see what you're saying. The fact that it was moved to this extensions repo confused me. I'm not sure this can be made into a plugin if we're talking about Zed inheriting the .editorconfig config, but I might be wrong.

Ok, I understand this a bit more now. I've moved the issue back to the Zed repository. Thanks for bringing these details up (I've never messed with editorconfig myself).

Is there any plan to support .editorconfig until now? Once again, I have to mention its importance.

Is there any plan to support .editorconfig until now? Once again, I have to mention its importance.

I'm sure if you send a PR the Zed team would be happy to review it!

I've started working on it with a friend of mine, there is already one design question we had: what configuration should we prioritize?

There are basically three configs:

• zed local
• zed global
• editor config

I'd go for editor config being first priority as if there is one in a repo, it is likely that contributions to this repo would require following it...

This is also the least effort implementation seing how the configuration is implemented related to language for zed and related to glob paths for editorconfig, intertwining both would mean having to make wider changes in the hashmaps used to load configs, thus also maybe resulting in a slower implementation

.editorconfig files should always take precedence. Also note that .editorconfig files need to be checked for in the same directory as each opened file, and every parent directory until you find one that has root=true in it. So every directory in a repo could have its own configuration. See https://editorconfig.org/#file-location

@plinss yes I know about that ! Fortunately, there is already a rust lib that does all the parsing (see above in this thread. Thank you for your opinion on precedence, may I know the reasoning?

The precedence rule is a consequence of the sub-directory support. Consider the following, I have a Python application and my coding convention is for 4 space indents and Unix line endings. Now in my application I include a local copy of an external module in a subdirectory (maybe a git submodule/subrepo) that I need to tweak. That module uses 2 space indents and Windows line endings. I'm editing files from both my application and the submodule within the same project/editing session. I need the editor to respect the .editorconfig in the submodule and use those settings for files in that directory. Therefore .editorconfig settings always override the editor's global or per-project settings.

Thanks toy so much @BuonOmo for working on this! would love to help if I can.

I agree with @plinss in that .editorconfig should take precendence by default.

It's not polite to not respect what .editoconfig specifies, so enabling it by default makes unaware devs not step on anyone's toes. Even if you don't really know what .editorconfig does, and don't really care about tabs vs. spaces, to just be able to work on that codebase.

+1 for supporting .editorconfig as it could be compatible with our existed projects