← Back to context

Comment by ibejoeb

1 day ago

I love Zed, but I hear you. It's a very fast and capable editor with lots of IDE features, but it's lacking comfortable ways of tuning it for specific projects. (This is a problem with every general purpose, everything-to-everyone kind of IDE versus stack "native" IDEs that are geared toward the one true way of developing for particular target.) The configuration file structure is arcane, and it certainly not clear what the boundaries are between language feature configuration, LSPs, built-in and third-party code quality tools, etc.

I eat the cost of configuring it manually when I start up something new because it's just not that big of deal, even when you're like me, working across myriad languages and frameworks and organization with varying standards. It's not ideal, but it's not deal-breaker.

I do wish that there was a better way to definitively set it up a particular way and know that it is doing what you want it to do. I want something like presets/profiles. If I'm working with typescript, I want to be able to set it up to use a specific version of tsc, eslint, prettier; I also want to be able to create a different one with biome; I want it to work correctly whether I have my source in the project root or in a sub directory or in a monorepo tree.

Fairness to Zed: it is difficult to support all of these permutations, but I do think that they ought to be able to do something better to abstract these things and make the reusable.

The standard approach these days is to have all of those declared in a config file somewhere in your project. That way, other contributors (and the CI) can lint/format consistently.

Even if it's for solo projects, it's nice that you don't have to update them in lockstep. As in, you revisit an older repo, you don't get bombarded with squiggly lines from your latest user profile, instead you can upgrade it at your leisure.

  • True, and not disputing that. Two points:

    1. I want to be able to readily duplicate that configuration for another similar project.

    2. It's not always appropriate to co-locate those specific files within the project source itself, especially within a source repository. Notable cases are if we're working on different platforms with different binary paths, or if we're not standardized on a particular editor. I should be able to configure my editor without polluting the common source.