Zed editor: Linux when?
(zed.dev)
from Vincent@feddit.nl to linux@lemmy.ml on 09 May 2024 12:39
https://feddit.nl/post/14907212
from Vincent@feddit.nl to linux@lemmy.ml on 09 May 2024 12:39
https://feddit.nl/post/14907212
In this episode of Zed Decoded, Thorsten talks to Mikayla, who’s been leading the effort to Zed working on Linux, about the Zed’s Linux version and how it’s taking shape
threaded - newest
I’ve been waiting for this. Been using Kate on Windows and Linux, which is great, but running Zed is just so lightweight. It’s like a truly open source Sublime Text.
been using WHAT??
A wild username reference appears!
There's an editor called Kate. It's probably not named after you, but if you're young enough and the person who named you was into tech, you might be named after it.
I named myself but im into tech does that count
Programmer error: I totally missed a bunch of edge cases there. Cases 32 to 35 for sure
Buuut I'm guessing you didn't name yourself after the editor.
GOOD article
Is Zed a text editor?
It is a lifestyle.
So, it's trying to replace Emacs?
Emacs is more of a religion.
I don’t think Zed has an email client and window manager built-in.
… yet.
A vibe
You are thinking of Xed
Thank goodness these things aren’t confusingly named.
Yes, a code-oriented one meant to be very fast and responsive. It’s pre-alpha on Linux but compiles without any fuss for me. I haven’t spent much time with it, but the only bug I’ve seen so far is an uncommanded theme change when switching between files.
Some random one that appeared out of nowhere for mac only, seems the be from some company and because of that people are hyping the shit out of it.
Many places that never mentioned the other more known and editors like helix now suddenly are mentioning this one. It smells as a huge ad/marketing campaign. Not sure what the plans are for monetisation and the business plan.
It’s a lot more than a random text editor.
It’s a text editor from (at least some of) the people that made Atom at GitHub (with the explicit premise of learning from Atom/building a faster, better, Atom).
The business plan is to sell collaboration features (e.g., remote pair programming).
.
vscodium doesn't run at 120 FPS and isn't native (as in Electron), which are Zed's goals
Edit: it doesn't seem like native widgets are a development focus of Zed, though
So it doesn’t run at a wastefully high FPS for a text editor? Is that supposed to be a selling point for Zed that it renders many, many more frames than a text editor needs?
Letters appearing when you type them improves user experience dramatically
Agreed, anything below 5 FPS is probably a bit slow for a text editor.
Yeah I find it impossible to program at 60fps.
The selling point is performance and speed... frames don't get rendered above your refresh rate.
.
Especially when you have a bunch of extensions and a large-enough file, you want it to parse, highlight, and suggest fast.
Gotta type first. Everyone knows thats the bottleneck for productivity.
Can we do Emacs vs. Vi next?
Does zed have helix keybindings?
If Zed goes wrong, can we just fork it? If yes, I’d like to use it.
It’s open source, so theoretically, yes.
The CLA stuff made me suspicious but probably you’re right.
If they’re using a CLA, that would only be used if you want them to merge your code into their codebase. If you’re running a fork, that shouldn’t be a problem.
Compiled it yesterday on endeavourOS, it's just 3 or 4 commands so give it a try if you're interested. Still have to use it for coding but I set it as default for some source files and it does immediately open on click, with syntax highlight (I was searching for something like this)
Well, you got me to give it a try. The process seemed simple enough, but unfortunately my laptop hangs when I run
cargo run --release, so looks like no Zed for me for a while (until someone builds a Flatpak).I feel like they’ve got couple of things wrong or they base of outdated information.
The packaging, yeah it’s still a mess if you absolutely have to put it in a native system package, but building something like Flatpak would generally be better. Or just build binaries against some common runtime like Ubuntu LTS and other distros will figure out, there’s really not much more here. It really sounds like someone wrote it in 2000’s about all distros being completely different and it’s expected to fall apart if you attempt to run it on say Fedora. They’re really not that different today. Also, universal package formats exist.
They completely skip XDG desktop portals that can provide at least huge chunk of functionality they need. There’s really no need to talk to GTK or QT directly. simply require portals and use its function for choosing file or directory. That’s it, you’ve got native file picker that also works in sandboxes.
They’re showing the native file picker which using XDG desktop portals.
I’m also fairly sure that the “(but of course there are competing standards)” line referred to Flatpak vs. Snap (vs. AppImage).
I built it on Linux , Arch … takes forever because of rust and the 1000’s of depends. Works though.