Great work @oliverbarnes! I've pushed up a commit that adds a second helper to the DisableAiSettings, just because I realized we were doing the buffer.read(cx).file() thing everywhere. It all seems to work on my end, once you give me the word I'd be happy to merge this

Thanks @probably-neb! That's good to hear, and I like the refactor too - it's cleaner this way.

Ship it :) 🚢 🇮🇹

Projects can only further restrict AI, not grant it

As a developer working across dozens–hundreds of repositories of which only a few can currently accept changes made with AI, I regret this implementation detail (as described) undermines your change.

It was safest to leave Zed's AI support disabled beforehand, and it strikes me it's still safest to leave Zed's AI support disabled now.

I'm happy to be straightened out: what do I put in the global and project settings so it's only enabled for projects in which I opt-in with .zed/settings.json?

Hey @garthk, I can see where you're coming from, it's not a scenario I had considered.

I have the opposite situation: on most projects I want to use AI, but on a couple, like repos with manual coding exercises, I want to disable it.

I guess my interpretation of disable_ai is that it signals opting-out rather than opting-in, too.

I think this deserves a larger discussion, as it involves a strategic decision by the Zed team if it were to change. I suggest opening a feature request discussion, or opening a thread on Discord, to kick it off.

No worries. I've painted myself into a corner with Boolean config variables before, too. They're so often intuitive, obvious, and wrong. :)

Note: SaturatingBool ensures that if user globally disables AI, projects cannot re-enable it. Projects can only further restrict AI, not grant it.

Why? I mean, isn't better to just let project settings override globals?

I think this way both scenarios are covered:

• globally off, but can enable on specific projects
• globally on, but can disable on specifc projects

Note: SaturatingBool ensures that if user globally disables AI, projects cannot re-enable it. Projects can only further restrict AI, not grant it.

Why? I mean, isn't better to just let project settings override globals?

I think this way both scenarios are covered:

* globally off, but can enable on specific projects

* globally on, but can disable on specifc projects

It being a SaturatingBool ensures that projects can't violate a user's preference not to use AI.

This is clear, my question was about the behavior, not the implementation.

Let's consider three possible scenarios:
a) globally off, but can enable on specific projects
b) globally on, but can disable on specifc projects
c) forced off, cannot enable (global)

The current implementation covers scenarios b and c.
I think the behavior of being allowed to override the option per-project only to turn off the feature, but not turn on, is not intuitive.

Using different values such as on | off | force_off all the scenarios would be covered.
Alternatively a seperate setting could be used to force off.

I was wondering if those options have been considered and then discarded for some reasons.

@davc0n those are also valid possibilities, I hadn't considered those when implementing this.

But like I explained to Garth above, I think expanding the functionality needs some discussion and a decision from the Zed team, and the best way is to kick it off is as a feature request. Another option is to post on Discord to see what the community thinks there.

Comments on merged PRs aren't very likely to get noticed.

Thank you @oliverbarnes