Ability to create different profiles.

[eznix86]

Check for existing issues

• Completed

Describe the feature

Currently we have only 1 default setting. The problem arises for people working on different projects which needs different settings.

Example; We can have Rust Profile (which has all the settings for the best experience for Rust). Laravel Profile, Django Profile. Python profile etc. It doesn't need to be specific. But we just need to have the ability to have different profiles.

If applicable, add mockups / screenshots to help present your vision of the feature

We can have prebuilt profiles (for specific languages/frameworks) or we can have custom profiles. Those profiles can be exported, imported, deleted, extended.

[jansol]

IIRC there are already some per-language settings, but there definitely is more that could be done with that.

[JosephTLyons]

We also have local settings as well - which can kind of act as a bandaid in this case, though, it isn't ideal in the context of the original request.

[ceopaludetto]

Personally, I think this should follow something like tsconfig.json does. So I want to introduce two new concepts:

1. The extends: string | string[] + name: string options, this will allow us to do:

{
  // The base profile
  "name": "base",

  "theme": "Catppuccin Mocha",
  "vim_mode": true,
}

And then:

{
  // The typescript profile
  "extends": ["base", ...],
  "name": "typescript",

  "languages": {
    "TypeScript": {
      "code_actions_on_format": {
        "source.fixAll.eslint": true
      }
    }
  }
}

Primitive options like string | number | boolean should be overwritten and object | array should be merged together

2. The extensions: string[] (or maybe extensions: { include: string[], exclude: string[] }) option. We need to disable/enable some extensions in different profiles. Nowadays VSCode allow us to disable in UI, but personally, I prefer to disable via settings.json

{
  // The base profile
  "name": "base",

  "theme": "Catppuccin Mocha",
  "vim_mode": true,
}

{
  // The swift profile
  "extends": ["base", ...],
  "name": "swift",
  
  "extensions": ["zed:sourcekit-lsp-extension"]
}

Some people also like the ability to disable all extensions in the base profile and only enable on specific ones, I think all this possibilities should be supported.

What you think?

[jansol]

Hmm... Should the profile also specify the github account and e.g. git author info to use (once we have git commit support)? I.e. separate "work" and "personal" profiles.

Formatting etc options should really be done via local settings IMHO, since different repos have different policies for that.

[shishkin]

Local settings work really well for a lot of use cases. However, since local settings are (usually) checked into source control, they are bad for personalization settings. E.g. setting fonts/themes for the whole team is not a good idea. Profiles can solve for that.

But the most need for profiles (as implemented in VS Code) I have is to selectively load extensions based on programming language. While performance concern might not (yet) be an issue for zed, but some extensions can start conflicting with other ones. Again, putting this in local settings may solve part of the problem, but I would hesitate to force all my non-essential extensions on the whole team.

[eznix86]

Hey, thanks for keeping this issue up.

Some feedback on my side:

I believe a profile is per project. we can have a .zed folder which takes the users configuration and merge it with the settings.json living inside of the .zed folder.

This allow teams to share extensions for example. I believe the .zed folder should allow a subset of the configuration, which means, you cannot change theme in a .zed folder.

Basically I believe for sanity, the word "Extending" is just a cloning of the json which technically another profile being duplicated.

So we can have settings.json, and even nvim.json, python.json or more.

[shishkin]

I believe a profile is per project.

That's something I strongly disagree. Profile is a user-specific and idiosyncratic set of extensions and preferences that are often used together. E.g. while working on devops automation I may prefer different layout from that when I work on mobile or web apps. And those preferences are not something I would impose on a team working on the same project. In addition, I would like to easily reuse such profiles for many projects, so initial project setup doesn't involve copying and tweaking zed config from a previous project. Again, project settings are shared, while profiles should be private.

[eznix86]

@shishkin I agree, but I wasn't explicit enough, what i meant was a profile can be reused by a project.

Example; you have 10 projects, you have 3 profile. But you open the 9th project in profile number 2, it should reopen with the same profile each time, unless you change it.

But we can have a profile per project. Example;

Let's say you have your current profile activated, since it has a .zed with settings.json inside it will merge your config with what we have in the .zed folder.

So it is user specific at its core, but if you open different projects on different profile, we should be able to memorize that this project was on which profile.

And in case the project has a project specific .zed/settings.json it should load and merge with your current profile but this project specific settings should not allow everything. Example, it should not override themes, or other user specific configuration.

I hope it clarified or even improved what i said earlier.

[amantuladhar]

Maybe zed can take some inspiration from VSCode profile feature
https://code.visualstudio.com/docs/editor/profiles

[cole-miller]

Thanks everyone for the feedback. I'm going to convert this to a discussion since that's a better venue for hashing out whether we want a feature along these lines and if so what the design should be.