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

[jabr]

a workaround could be a .editorconfig -> .zed/settings.json script to help meanwhile.

BuonOmo posted such a script in a comment up above.

[jabr]

Is it possible to write an extension for this feature ?

This kind of functionality can't currently be added through a Zed extension.

Extensions only allow adding grammars, languages, and themes.

[bersace]

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

I created a more elaborate solution at https://gitlab.com/bersace/zeditorconfig

$ go run gitlab.com/bersace/zeditorconfig@latest

This will handle braces, brackets and directory prefix.
It fallbacks language to file extension. Which works well for CSS, JSON, C, PHP, etc.

🇫🇷 Merci @BuonOmo pour le script original en Ruby, je m'en suis inspiré !

It's my first project wrote entirely using Zed & lazygit, under Linux. It's awesome !!

[PedroHLC]

Sorry guys, but .editorconfig fills like native for most text-editors and IDEs out there. No way I'm converting them all just to randomly edit a project in Zed. I have been using them since always and never had to care about an app not supporting them, until now:

╰─λ find ~/ -name '.editorconfig' -type f | wc -l
327

Nothing worse than opening a PR and the project leader telling you “your PR is breaking our indentation and EOF that we have enforced on .editorconfig, configure your IDE” -- something I have not encountered in years

[BuonOmo]

I think there's enough traction on this... I'll open a PR during next week! If any of you would like to pair on that during the week, email me :)

[shellscape]

@BuonOmo looking forward to that!

[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