Live data from Hacker News

You can now disable all AI features in Zed

zed.dev

271–277 of 277 posts

Re: You can now disable all AI features in Zed

#271
post #160

Earlier quoted context omitted.

This follows a convention that was well established and felt pretty ancient when I learned about environment variables in the nineties (i.e. 30 years ago). Variables that are flags enabling/disabling something use 1 to enable, and 0 to disable. I'd not be surprised if this has been pretty much standard behavior since the seventies. This is not unique to Go.

I always thought that an unset boolean env var should define the default behavior for a production environment and any of these set with a value of length>0 will flip it (AUTH_ DIS ABLED, MOCK_ EN ABLED, etc.). I thought env vars are always considered optional by convention.

At least in the case of cgo_enabled it does define the default behaviour

Re: You can now disable all AI features in Zed

#272

Earlier quoted context omitted.

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.

> It's set to 0 or 1 to enable/disable (can never remember which mapa to which) That's crazy. Boolean logic is the most fundamental notion of computer science, I can still remember learning that in my very first course on my very first year.

I've no issues with boolean logic (&&, ||) but unfortunately all my schooling has done those with the notion of true/false instead of bits iirc.

Re: You can now disable all AI features in Zed

#273
post #160

Earlier quoted context omitted.

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.

This follows a convention that was well established and felt pretty ancient when I learned about environment variables in the nineties (i.e. 30 years ago). Variables that are flags enabling/disabling something use 1 to enable, and 0 to disable. I'd not be surprised if this has been pretty much standard behavior since the seventies. This is not unique to Go.

I don't doubt any of that but why stick to such old conventions when there are explicit and immediately clear options?

I don't think me writing an if condition

if boolean != true

instead of

if boolean == false

should pass code review. I don't think my pet peeve is necessarily different from that. I understand there's a historical convention but I don't think there's any real reason for having to stick to it.

Hell, some of the other compiler options are flags with no 0 or 1, why could this not have been --static or any flag? I'm genuinely curious.

Moreover, 0 here maps to false but in program exit codes it maps to success which in my mind maps to true but then we have this discrepancy so it does not appear to be the right mental model.

Re: You can now disable all AI features in Zed

#275
post #204

Earlier quoted context omitted.

I seem to hear this a lot, but there's probably like 10 commands (maybe a few more if you want to be fancy with copy-paste). Note: great if you like nano however! For those that are interested, this will get you 90% there: exit without saving> :q! exit with saving> :wq beginning of line> 0 end of line and edit (enter insert mode)> shift-a delete line> dd insert mode> i stop insert mode> ESC undo> u show line numbers>…

It is easier to remember one command: `nano `

+1, nano even gives you a handy hint bar at the bottom in case you forget any of its' shortcuts

Re: You can now disable all AI features in Zed

#276
post #41

I went from VS Code to Cursor, then got frustrated with Cursor breaking keybindings and other things, tried to go back to VS Code but missed the superior tab completion. Then I gave Zed a long hard try, but after over a month of daily usage I went back to Cursor again, just for the tab completion quality. I don't use any of the chat or agent features, but for me Cursor's tab completion is a step forward in work effic…

I went slightly differently: I used Zed for about a year and a half exclusively, without using any AI features, and then switched to cursor to try AI features out. When Zed released its agent mode, I switched back to Zed. I absolutely agree that Cursor’s tab completion is far superior to Zeds. The difference is night and day. Cursor’s really is that good. But the Zed agent mode works very well for me and Zed is, IMHO…

nah, I've been using zed exclusively for a couple of months and Zed's agent mode is still worse than Cursor's, but I do agree the quality gap is smaller than on tab completion

Re: You can now disable all AI features in Zed

#277
post #183

Earlier quoted context omitted.

Vim and emacs both also support editing remote files.

"Support editing remote files" and "work with all plugins on remote that feels like editing on local machine" are different things

Just to clarify, for vim I'm talking about the scp:// thing, for emacs there is of course TRAMP. In both cases you're running a local editor and fetching the remote file, then sending it back when making changes. So your plugins and such should work just fine. I am not talking about sshing into the machine and running vim or emacs as a TUI on that remote machine, which is also possible with both editors.
Post reply on HN