Interesting the decision[1] of building against glibc instead of musl. Any reason for not using musl instead (and doing a static binary)? This would avoid the compatibility issues e.g.: Alpine and Nix. [1]: https://zed.dev/docs/linux
[deleted]
Zed on Linux Is Here
201–210 of 703 posts
Re: Zed on Linux Is Here
#202Sadly I can't run it in WSL. thread 'main' panicked at crates/gpui/src/platform/linux/wayland/client.rs:143:51: called `Result::unwrap()` on an `Err` value: UnsupportedVersion note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
same. :(
Re: Zed on Linux Is Here
#203Anyone got this working in WSL? Using WSLg perhaps?
Trying but not succeeding
Re: Zed on Linux Is Here
#204Just a suggestion. One of the best features of pure text editors (and incredible, not all of them implement it) is autosave keeping the "unsaved" state of the file. For example, if you make some changes in a file (new or not), don't save the changes, close and open the editor, the state of the opened files are kept like I never had closed the editor. The unsaved files are still unsaved. New edited files are still the…
Is this if you close the entire editor? If you just close the file, do the changes remain next time you open it?
Re: Zed on Linux Is Here
#205Earlier quoted context omitted.
Did you have some plugins in vim? It is very odd if it was slower in this scenario.
Not to my knowledge, outside of whatever Debian comes with. Keep in mind this was on a Chromebook - so it would have been running in a VM on a rather memory restricted system. That said, VSCode would have been running in the same parameters. Just found the file. 42MB on a single line. Takes 5 seconds to open in vim, and about 3 seconds for the right arrow to move the cursor one char over. Nothing like gedit, but slow…
Just curious, what of you do the same with bare neovim, for science?
Re: Zed on Linux Is Here
#206Earlier quoted context omitted.
Did you have some plugins in vim? It is very odd if it was slower in this scenario.
Not to my knowledge, outside of whatever Debian comes with. Keep in mind this was on a Chromebook - so it would have been running in a VM on a rather memory restricted system. That said, VSCode would have been running in the same parameters. Just found the file. 42MB on a single line. Takes 5 seconds to open in vim, and about 3 seconds for the right arrow to move the cursor one char over. Nothing like gedit, but slow…
Might want to try https://github.com/LunarVim/bigfile.nvim
Re: Zed on Linux Is Here
#207Earlier quoted context omitted.
My question is why they didn't just make a Flatpak. Then they and their users wouldn't need to go through any of this hassle and distro fragmentation at all. Even if they didn't want to publish it on Flathub, Flatpak supports single file packages people can directly install as well.
Because then you have a dozen other people who say "why didn't they just make a ___"
But that's literally already true, and at least with Flatpak they'd only need to make a single package to support all distributions and system configurations, whereas what they're already doing is supporting 15 different packaging systems and distributing a fragile install script that more people will have problems with. So this objection makes literally zero sense.
Re: Zed on Linux Is Here
#208Earlier quoted context omitted.
I think people just have very different tolerances for latency and slowness. I keep trying different editors (including VS Code), and I always end up going back to Neovim because everything else just feels sluggish, to the point where it annoys me so much I'm willing to put up with all the configuration burden of Neovim because of it. I tried out Zed and it actually feels fast enough for me to consider switching.
Sublime Text 3 is still one of my favorite editors. I use VSCode lately because of its excellent "Remote SSH" integration - but when it comes to latency sublime has it beat. Zed does not feel fast on my machine, which is a 13900K/128gb ram. It is running in xwayland though, so that could be part of the problem. It feels identical to vscode.
Sublime Text gang, raise up.
I was always a fan of Sublime Text and I moved away from it once because VSC felt more "hassle-free". The extensions just worked, I didn't need to go through endless JSON files to configure things, I even uncluttered its interface but at the end of the day I returned to good old Sublime Text. Now with LSPs it requires way less tinkering with plugins. I only wish it had just a little bit more UI customizability for plugins to use (different panes etc). Maybe with Sublime Text 5 if that ever comes.
Also about the speed: VSC is fast but in comparison... Sublime Text is just insta-fast.
Re: Zed on Linux Is Here
#209Earlier quoted context omitted.
Fairly positive due to blurry cursors, but I have no way to verify.
If you run xeyes and the eyes follow your cursor when it's above the application you want to test, it's running under xwayland. If they don't follow your cursor, the application is running under native Wayland.
finally a use for xeyes?
Re: Zed on Linux Is Here
#210Earlier quoted context omitted.
My question is why they didn't just make a Flatpak. Then they and their users wouldn't need to go through any of this hassle and distro fragmentation at all. Even if they didn't want to publish it on Flathub, Flatpak supports single file packages people can directly install as well.
There is already some support to flatpak, but it's not distributed on flathub yet. You have to build by yourself https://github.com/zed-industries/zed/blob/main/docs/src/dev...
Were they not aware of `flatpak build-bundle`? They could have just built it once and ran that command on the result and then put that on the archives of their repository and been done with it. It's not like a regular package build where there are different system conditions to keep an eye on. It would work no matter what.