Live data from Hacker News

You can now disable all AI features in Zed

zed.dev

141–150 of 277 posts

Re: You can now disable all AI features in Zed

#141
post #90

Total nitpick, but: Why would you name an option "disable_ai" with a default value of false instead of calling it "enable_ai" with a default value of true? Are there some mechanical semantics I'm missing here that make this beneficial? Negative booleans (ie that remove or suppress something when true) are generally a source of confusion and bugs and should be avoided like the plague in my experience.

It's good and predictable that all boolean settings to be false by default (when not set). And the default behavior is the one that is compatible with older version — changing the defaults is a breaking change that should usually be avoided.

Re: You can now disable all AI features in Zed

#142

Started using Zed about a year ago and, besides Magit, it has managed to completely replace Emacs for me. I was missing a good debugger for a long time, but that also went GA a month ago or so. One thing that goes underappreciated is the input latency and how light on resources the editor is overall. Whenever I switch tabs to a web browser (or any web app), I can feel the lag in typing now, despite the fact I use an…

I use Zed too, and as a longtime magit devotee, I've really been enjoying using gitu [0] in Zed. gitu doesn't have everything magit does, but there's not much I find myself missing.

I have it nicely integrated with Zed by defining the following task, which you can then add a keybinding for if you want:

    {
        "label": "gitu",
        "command": "gitu",
        "reveal_target": "center",
        "hide": "always",
        "env": {
          "VISUAL": "zed",
          "GIT_EDITOR": "vim"
        }
    }

[0] https://github.com/altsem/gitu

Re: You can now disable all AI features in Zed

#143
post #78
post #24

Sadly, I came back to using VS Code recently. There's a lot to like in Zed but imo that decision to write their own rendering framework is unfortunate, because of ridiculous problems in Linux still not resolved like poor font rendering, especially on low-DPI screens, or visible lags of UI which is being developed to be blazingly fast. So far, VS Code is faster for me.

I listened to a podcast interview with one of the cofounders of zed. One of the revealing things is that he went on and on about how important latency was and how they had to do their own rendering because of the problems they ran into with electron. He also admits that he never used vim, which already has imperceptible latency relative to the terminal emulator, which has already largely solved the text rendering pro…

Why does a text editor of all things need faster rendering, I have never seen this to be an issue

Re: You can now disable all AI features in Zed

#144
post #136

Earlier quoted context omitted.

I concur. Same thing in many UI frameworks where you’ll have a Boolean “isHidden” to control visibility. Makes it so hard to reason about.

IMHO, in this case it should not even be a boolean but an enum {Visible, Hidden}.

Even with working with an existing framework, we can define a constant `HIDDEN=true`

Re: You can now disable all AI features in Zed

#145
post #90

Total nitpick, but: Why would you name an option "disable_ai" with a default value of false instead of calling it "enable_ai" with a default value of true? Are there some mechanical semantics I'm missing here that make this beneficial? Negative booleans (ie that remove or suppress something when true) are generally a source of confusion and bugs and should be avoided like the plague in my experience.

I think AI-enabled is going to be the default for all future code development. Autocomplete is just so good, and I never want to go back. I spent 20 years without it. That's enough for one lifetime.

You spent 20 years without autocomplete? I started using Eclipse's autocomplete & shortcut macros in 2002.

It is fascinating to me how much of the enthusiasm around AI seems to be the result of people not knowing about/using the deterministic tools that already exist.

Re: You can now disable all AI features in Zed

#146
post #90

Total nitpick, but: Why would you name an option "disable_ai" with a default value of false instead of calling it "enable_ai" with a default value of true? Are there some mechanical semantics I'm missing here that make this beneficial? Negative booleans (ie that remove or suppress something when true) are generally a source of confusion and bugs and should be avoided like the plague in my experience.

The wording implies that disabling a default feature is used by a handful of edge cases and Zed has done their best to accommodate these users.

From a business perspective, investors want to hear that AI is indeed part of the shipped product.

It's all about optics.

"disable_user_tracking: false" vs "enable_user_tracking: true"

"disable_adverts: false" vs "enable_adverts: true"

Fewer people would actively _enable_ user tracking or adverts compared to those who would take extra steps to _disable_ them.

Re: You can now disable all AI features in Zed

#148
post #90

Total nitpick, but: Why would you name an option "disable_ai" with a default value of false instead of calling it "enable_ai" with a default value of true? Are there some mechanical semantics I'm missing here that make this beneficial? Negative booleans (ie that remove or suppress something when true) are generally a source of confusion and bugs and should be avoided like the plague in my experience.

Technically, "enable_ai" doesn't imply that all AI features are really turned off. Without context, it might imply that some basic AI features exist and "enable_ai" just enables further features. "disable_ai" is unambiguous.

My pet peeve is CGO_ENABLED compiler option in Go. It's set to 0 or 1 to enable/disable (can never remember which mapa to which)

If it was just CGO=true or CGO=false I think so much confusion could have been avoided.

I think similar thinking applies here. It's convoluted to disable something by setting ai_disable=true because I read it like: setting false true instead of just setting boolean.

Re: You can now disable all AI features in Zed

#149
post #124

Earlier quoted context omitted.

Not everyone wants to use a terminal editor and of those people, not everyone wants to use vscode.

Learning a terminal editor will save your ass at 3am when production goes down. No joke.

Learning a client-server editor will save your nerves when developing on a remote machine with 200ms ping

Re: You can now disable all AI features in Zed

#150

Earlier quoted context omitted.

Technically, "enable_ai" doesn't imply that all AI features are really turned off. Without context, it might imply that some basic AI features exist and "enable_ai" just enables further features. "disable_ai" is unambiguous.

Enable/disable are the only two dichotomies in the whole of all possible states regarding this AI feature, so I'll have to bite: What's your "Technically," referring to here?

First of all, enable/disable is a dichotomy, and is not a set of two dichotomies.

Second, imagine an editor that has AI running in the background, scanning your files. "Enable_AI" could just mean enable the visibility of the feature to actually use the results. On the other hand, it would sound more suspicious if there were some background AI tasks running, even for training purposes, if "disable_AI" were "True" as compared to "Enable_AI" to be false.

In other words, Enable_AI COULD have the connotation (to some) of just enabling the visibility of the feature, whereas Disable_AI gives more of a sense of shutting it off.

Imagine for example you're in a court of law. Which one sounds more damning?

======= Prosecutor: You still have AI tasks running in the background but AI_Enable is set to false?

Defendent: But Enable_AI just means enabling the use of the output! ====

==== Prosecutor: You still have AI tasks running in the background, but AI_Disable is TRUE?

Defendent: Uh.... ====

Post reply on HN