EditorConfig

[exalted]

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.

[joeldrapper]

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.

[maxbrunsfeld]

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

[maxbrunsfeld]

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.

[rschiang]

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.

[joeldrapper]

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.

[exalted]

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.

[jabr]

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.

[BuonOmo]

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

[steve-taylor]

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}"]
    }
  }
}

[exalted]

@steve-taylor sure, thanks.

[BuonOmo]

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 ?

[TheDaemoness]

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

[pzmosquito]

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

[nilskaspersson-imtf]

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.

[BuonOmo]

@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!

[Moshyfawn]

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]

@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.

[BuonOmo]

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.

[bdougherty]

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.

[joeldrapper]

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.

[Moshyfawn]

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.

[JosephTLyons]

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).

[dbarnett]

Just to summarize current status:

• in the PR it looks like @SomeoneToIgnore has an open concern about how to handle multiplayer support / remote workflows
• in August they said "It might take some time though, as LanguageSettings is quite a foundational thing in our codebase and there's another task I have to tackle first."

[SomeoneToIgnore]

The PR in question: #16349
To add on top, the PR now has a great single player part prototype and a nice test to check the correctness of the feature.

Two main problems with it that it new plugin API now needs to pass a file path to get a language setting for, which was not the case before; and the fact that the PR changes the place to make a recursive FS lookup in a method, that is called during rendering, potentially up 120 times per second...

To make it closer to amortisized O(1) without any FS checks, quite a different code has to be written, even the one in the code of the feature, related to parsing and merging the actual files.

I've described a way to implement this in one of the comments to the PR #16349 (comment)

and this has to wait before ssh remoting feature forms into some public form, otherwise the development work related to that ssh remoting might change things a lot, as it already did since the time the PR was open.

[Dev-cmyser]

it's already working ?

[Dev-cmyser]

How to use this ?
I can't find docs please help

[dwt]

What are you struggling with? You probably did follow this manual - there was no extra step for me, it just worked.

[tednaaa]

actually it should just work, but I faced with issue when for example there is 2 projects

foo/ # with .editorconfig
bar/ # without .editorconfig

if we open with zed project bar/ then open some file from project foo/ and format it, .editorconfig will not work

[feryardiant]

It's apparently working just fine, but there's no syntax highlighting?

[BuonOmo]

@feryardiant syntax highlighting was not the topic of this issue. It was about supporting it as a configuration tool. If you want to push this forward, you should have a look at https://github.com/zed-industries/extensions. This is the repository were language support is requested and added.

And there is already support for TOML, so I think it would just be a matter of adding .editorconfig files to the detection of TOML language

[feryardiant]

syntax highlighting was not the topic of this issue. It was about supporting it as a configuration tool.

I see, thanks for explanation.

[BuonOmo]

Sorry for the spam... I actually found that there is already support for it in the ini extension for Zed: https://github.com/bajrangCoder/zed-ini. It is just lacking detection of editorconfig files.

[shishkin]

.editorconfig gradually got partial support in Zed. However, Zed still doesn't always prioritize explicit .editorconfig settings over other formatters' default settings. E.g. if I set indent_style = space and indent_size = 2 in .editorconfig, I still get Rust code indented with 4 spaces.

[tednaaa]

about my issue, here I recorded video about that bug, the use case is, when I work in some project, then I wanna change some settings in dotfiles, as you can see, in ~/dotfiles project .editorconfig working, and I get json format with spaces, but when I format it from ~/projects/bcup it will use tabs

I guess the issue is coming from hard_tabs: true setting in my zed config?
I think zed should prefer .editorconfig instead of hard_tabs in this case

Screencast_20250203_195515.mp4

[teohhanhui]

However, Zed still doesn't always prioritize explicit .editorconfig settings over other formatters' default settings. E.g. if I set indent_style = space and indent_size = 2 in .editorconfig, I still get Rust code indented with 4 spaces.

If it did, it'd be undesired behaviour. I think it's a huge misunderstanding of EditorConfig's role. EditorConfig is the baseline. It shouldn't override specific formatting tools' configurations, e.g. rustfmt.

[shishkin]

If it did, it'd be undesired behaviour. I think it's a huge misunderstanding of EditorConfig's role. EditorConfig is the baseline. It shouldn't override specific formatting tools' configurations, e.g. rustfmt.

There are nuances. Completely ignoring the baseline is IMHO also undesirable. I think the following is a reasonable order of precedence for formatting options (from lowest to highest):

1. Hardcoded defaults
   a. from formatter
   b. from Zed
2. user config
   a. from ~/.editorconfig
   b. from formatter
   c. from Zed
3. project config
   a. project .editorconfig
   b. project Zed config
   c. project formatter config

This allows to specify a minimal baseline and override whatever is necessary at higher levels without duplicating the same configuration between the tools.

[heygarrett]

@teohhanhui is right. EditorConfig configures editor settings, not formatter settings. Coming from Neovim, which has built-in support for EditorConfig, specifying tabs in .editorconfig will not change a formatter's behavior unless that formatter specifically reads from the .editorconfig file (eg, Prettier, shfmt). But regardless of the formatter's prerogative, the editor will be configured to use tabs.

[heygarrett]

Not to mention that, if the .editorconfig file were to override formatter settings in the editor, you may end up with different results when formatting in the editor vs running the formatter on the command line.