631–640 of 703 posts
I downloaded ZED for a quick play-around, but was quite shocked to find out that editing and saving a file runs an auto-formatter on it _by default_... Whoever thought that was a great idea obviously has never worked with version control, with other people on a project? Sorry, but this is such an obviously wrong default setting, I'm surprised nobody pointed this out before?
On one end of the spectrum, you have programmers who use Visual Studio Code or Atom or one of the other Electron-based code editors ( https://en.wikipedia.org/wiki/Electron_(software_framework) ), and at the other, you have programmers who use vim or even vi ( https://en.wikipedia.org/wiki/Vi_(text_editor) ). Now, me personally (and this is just one man's tiny and insignificant opinion in a sea of billions of people!…
The same team behind Zed created Atom and the Electron framework. But that doesn't say anything about Zed either. The only thing that's shared between Zed and Atom is tree-sitter ( https://en.wikipedia.org/wiki/Tree-sitter_(parser_generator) ).
Zed looks like it holds promise on several fronts -- most notably that its code (to the best of my knowledge at this point in time, and kindly correct me if I am wrong) is decoupled from JavaScript, Electron, and Chrome/Chromium and other browsers (and other slowness/bloatedness) in general...
My comment, if it was directed, was directed to all of the (posters?/bots?) that claimed directly or indirectly, expressed or implied, that one or more of the Electron-based editors are faster than one or more of the non-Electron based editors, when clearly Electron adds a whole lot of unecesary bloat and slowdown to editors that use it (which is one of the reasons why Zed was apparently written: "Engineered for performance Zed efficiently leverages every CPU core and your GPU to start instantly, load files in a blink, and respond to your keystrokes on the next display refresh. Unrelenting performance keeps you in flow and makes other tools feel slow." (from the Zed website: https://zed.dev/))
Whether or not the same team worked on Electron in the past is not relevant.
What is relevant to Zed is only its codebase, and whether or not that codebase is tightly coupled or decoupled to other software that bloats it and slows it down or not.
So to recap -- I am not against Zed in any way.
Earlier quoted context omitted.
Enforcing auto-formatting is a common practice in my experience. Currently working on a project where the repo will refuse commits that are not following the repo-specific formatting settings. I think it is a sane default in 2024.
No, it isn't. And anyway, I downloaded a generic text editor which has no idea of what autoformatting settings are applicable to my repos (maybe it differs per repo?), yet is trying to autoformat anyway? For example, it decided to replace ' characters in a YAML file with ". WTF? The _default_ setting should be to save as-is.
The zed complaint is purely about it be auto enabled. For each language there is usually a standard and at least one tool. Most people want formatting and can’t stands code bases where sometimes it’s a single quote, sometimes a double quote.
Earlier quoted context omitted.
I agree with you -- but aiming for 1ms performance is pretty hard. That is 1/1000th of a second. Your keyboard probably has higher latency than that. Physics cannot be defeated in this regard.
There are keyboards with 1kHz polling.
I've kept my neovim config, vscode, and zed configs in parity for a while now. To the point that the keybinds and behaviors are the same (or as simliar as they can be) across all three. In my personal experience zed is eating into the time I use vscode, but not really touching neovim as much. It really has come a long way, and I'm excited I'll be able to use it on my Linux machine without having to jump through hoops…
Earlier quoted context omitted.
Completely agree. Furthermore, you could always just not pipe it to sh, read it first if you care so much. Releasing and maintaining packages across a range of distros is extremely hard and time consuming, and they just released the linux version.
I don't see how maintaining a 150 lines script is more convenient and less of a hassle to maintain than having a pipeline building a flatpak, an rpm, a deb and a plain tarball with binaries. In 2024, everyone looking for a code editor knows how to extract a tar.gz right?
I'll raise my hand and say I still get the `tar` terminal command options confused and have to pause and figure out the file format I'm dealing with and the options. So, no, I usually don't know, and have to look it up in the manpage/help. "Was it -xvfz for this one? Shit I just did this recently..."
Earlier quoted context omitted.
Of course, nobody forces author to do anything, but insecure installation method will continue to generate loud warning about insecurity.
What makes it insecure?
> To install Zed on most Linux distributions, run the shell script below. > curl https://zed.dev/install.sh | sh Please stop telling people to curl pipe scripts into their shell...
Why? I’m going to run their software anyways. And this is a really easy way to run an installer. This is basically the Linux equivalent of download and double click which is a user flow that is underrated for simplicity and usability.
The Linux equivalent to double-click installer is ... a double-click installer, Flatpak. Or for even more bonus points, make the app fully portable as an AppImage. In the rare case I can't find what I'm looking for in my distribution repos, I look for an AppImage.