Zed on Linux Is Here

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.

I use Helix and feel the same way. The pickers/fuzzy finder particularly have no equal for speed in any editor I’ve found. (Zed seems pretty fast but I didn’t get on well enough with it to find out how it performs with more serious use.)

fwiw I’ve also found the configuration overhead much lower with Helix than for pretty much any other editor I’ve seriously used.

Zed is still quite a bit slower than Neovim in my experience.

people just have very different tolerances for latency and slowness

I've honestly never considered this and it's genius. I have always been surprised when people recommend kitty as a "fast" terminal when it takes 200ms (python interpreter) to start up, which is unbearable to me.

But yeah, people sometimes just open a couple and see speed in other areas that I don't care about.

I think people just have very different tolerances for latency and slowness.

I wonder if it's because of a form of "touch typing". I'm not really looking at text appearing as I type. My fingers work off an internal buffer while my mind is planning the next problem. If not so deep in thought to almost be blind, I am reading other docs / code as I type. I am not an ultra fast typist but if I mistype, I can feel it and don't need the visual feedback to know it. I might be this way because I am old and have used tools with lag you measure in seconds.

I only care about latency if it interrupts me and I have to wait and that's typically not typing but heavier operations. I am utterly intolerant to animations. I don't want less I want zero, instant action. I don't want janky ass "smooth scrolling" I want crisp instant scrolling. I have no idea why animations are even popular.

Some of the text-editor latency discussion reminds me of high screen refresh rates for office work. When people "check the refresh rate" they have to do that violent wiggling of window to actually have large content moving faster enough to see a difference. You have to look for it to then get upset about it.

The worse case would be if it's more of an illusion like fancy wines - a fiction driven by context. Lie to someone that an editor is an electron app and they will complain about the latency. Software judgement also has toxic fashion and tribal aspects. Something unfashionable will accrue unjustified complaints and something cool or "on your team" will be defended from them. I'm reminded of Apple fans making all sorts of claims about rendering unaware that they were using Apple laptops that shipped not running at their natural resolution and visibly blurry. Your lying eyes can't beat what the heart wants to believe.

In summary: our modern computer's sheer power are camouflaging poor software performance. The difference between using native and Electron apps, is a huge reduction in the upper limit of how many things you can do at the same time in your machine, or having a lower ceiling on how many heavy-load work tasks your system can be doing before it breaks.

Same can be said about a lightweight web page and 'React' with tons routers all in SPA and vdom. Maybe the page is fine when it is the only page open, but when there are other SPA also open, then even typing becomes sluggish. Please don't use modern computer's sheer power to camouflaging poor software performance. Always make sure the code uses as little resource as possible.

Yeah, all I need to do to reliably show the drastic performance difference is open 5 different windows with 5 different versions of our monorepo. I frequently need to do that when e.g. reviewing different branches and, say, running some of the test suites or whatever — work where I want to leave the computer doing something in that branch, while I myself switch to reviewing or implementing some other feature.

When I start VS Code, it often re-opens all the windows, and it is slow as hell right away (on Linux 14900K + fast SSD + 64GB RAM, or on macOS on a Mac Studio M2 Ultra with 64GB RAM).

I'll save a file and it will be like jank...jank... File Save participants running with a progress bar. (Which, tbh, is better than just being that slow without showing any indication of what it is doing, but still.)

I've tried to work with it using one window at a time, but in practice I found it is better for my needs to just quit and relaunch it a few times per day.

I try Zed (and Sublime, and lapce, and any other purportedly performant IDE or beefed-up editor that I read about on this website or similar) like every couple months.

But VS Code has a very, very large lead in features, especially if you are working with TypeScript.

The remote development features are extremely good; you can be working from one workstation doing all the actual work on remote Linux containers — builds and local servers, git, filesystem, shell. That also means you can sit down at some other machine and pick up right where you left off.

The TypeScript completion and project-wide checking is indeed way slower than we want it to be, but it's also a lot better than any other editor I've seen (in terms of picking up the right completions, jumping to definition, suggesting automatic imports, and flagging errors). It works in monorepos containing many different projects, without explicit config.

And then there's the extensions. I don't use many (because I suspect they make it even slower). But the few I do use I wouldn't want to be without (e.g. Deno, Astro, dprint). Whatever your sweet set is, the odds are they'll have a VS Code extension, but maybe not the less popular editors.

So there is this huge gravity pulling me back to VS Code. It is slow. It is, in fact, hella fucking slow. Like 100x slower than you want, at many basic day-to-day things.

But for me so far just buying the absolute fastest machine I can is still the pragmatic thing to do. I want Zed to succeed, I want lapce to succeed, I want to use a faster editor and still do all these same things — but not only have I failed so far to find a replacement that does all the stuff I need to have done, it also seems to me that VS Code's pace of development is pretty amazing, and it is advancing at a faster clip than any of these others.

So while it may be gated in some fundamental way on the performance problem, because of its app architecture, on balance the gap between VS Code and its competitors seems to be widening, not shrinking.

In summary: our modern computer's sheer power are camouflaging poor software performance

I somewhat disagree. Features sell the product, not performance[1], and for most of the software development you could count on the rising CPU tide to lift all poorly performing apps. But now the tides have turned to drought and optimizing makes a hell of a lot of sense.

[1] They are more of a negative sell and relative to other feature parity products. No one left Adobe Photoshop for Paint, no matter how much faster Paint was. But you could if feature parity is closer, e.g. Affine vs Photoshop.*

It's a Prisoners's Dilemma. Since apps are evaluated in an isolated fashion there is an incentive to use all the resources available to appear as performant as possible. There is further incentive to be as feature-rich as possible to appeal to the biggest audience reachable.

That this is detrimental to the overall outcome is not unfortunate.

I have had to open the parent folder of all the different code bases I need in a single VSCode window, instead of having an individual window for each.

I much prefer having individual windows for each code base, but the 32G of ram for my laptop is not enough to do that.

If I were to run multiple instances of VSCode, then the moment I need to share my screen or run specs some of them will start crashing due to OOM.

but vscode is open source: https://github.com/microsoft/vscode

and there are third-party builds from the community that disable things like telemetry: https://vscodium.com/

I, too, prefer to cut off my nose to spite my face.

Did you have some plugins in vim? It is very odd if it was slower in this scenario.

I believe VsCode has told me several times that the file i want to open is too big.

I work with giant jsons every day and always have to fall back to nvim as vscode is terrible. Vscode even has a default size limit where it disables editor features for json files larger than a few megabytes.

Nvim works flawlessly tho even with syntax highlight and folding.

Weird, I had the exact opposite experience. I had a large Markdown file I was editing and VSCode would simply hang or crash when opening it. Neovim on the other hand actually was able to navigate and edit just fine.

For this kind of stuff Sublime has always been extremely good.

But I still struggle to find a reason to not use neovim, it's replaced all my editors.

A typical 60 Hz screen refresh is 16.7 ms

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.

I just want to point out that most keyboards hav a latency at 10-20 ms[1], so 1 ms is impossible.

[1]https://danluu.com/keyboard-latency/

I grew up a damn good HPB Q1 player at 250ish ms.

If you type and wait for the letter, I could see that being annoying. My brain works more in waves, my hands type a block and it's there on the screen. I've never once thought of character latency, but maybe that's my HPB roots.

Honestly I don't think that the problem with VSCode is speed, even. It's bloat. It uses gobs of RAM just to open up a few text files. I compared it to Sublime Text a while back and it was something like 500 MB (for Sublime) to 1-1.5 GB (VSCode). That's not acceptable in my view.

TS itself is lock-in. I mean, the entire point of JS is that it's portable, and there's certainly no lack of compile-to-JS languages that are already finished and have much more powerful type systems and existing libs/ecosystems.

Enjoy your VScode projects exclusively on Windows a couple years down the road, or rather, contribute to MS' coding ML models to make yourself obsolete even before. Windows already posts home everything it has gathered on you the second it connects to the net, and I'd expect vscode to as well.

But the infanterists in our profession manage to get it wrong, every single time.

And the remote SSH and C++ extensions, though that actually has a good alternative in the Clangd extension.

I'm kind of ok with it tbh. As a monetisation strategy it's not the worst, and I have no expectation that they just do all this for free.

Have to agree on the VCS story. I’d switched over to using Zed more or less permanently, but I eventually moved back because I kept having to open Intellij to resolve conflicts.

+1 for the Jetbrains gang.

I've never experienced this. Have you tried disabling all your extensions to see if one of them is causing it?

There are two schools of thought. One strives for correctness, even if that requires extra effort. Another is "anything goes as long as it somehow kind of works more than it doesn't."

(Actually it's most probably a spectrum rather than a binary division, but I'm no philosopher or sociologist, so for example's sake I'll operate with this simplified model here.)

The world en masse is generally preferring the latter (picking the easiest solutions, no matter how shitty they are - that's how we ended up with what we have today*), but among the engineers there are a significant number of people who believe that's how things should be.

There are numerous issues with copying and pasting `curl | bash` invocations from random webpages: all sorts of potential security issues, the installed software (if it works) could be installed in a way different from how your OS/distribution does things (or from your personal preferences), leading to all sorts of future issues, etc etc. Someone probably has a good write-up on this already. But - yeah - on the other hand, it works for number of people.

___

*) And, of course, the opinions if what we have today is "good progress" or "unbearable crap" also vary.

I sympathize with the situation that Zed developers are in. They are thinking of the user experience first and foremost, and when trying to distribute on Linux, faced with an overgrown, chaotic landscape that utterly fails to provide the basic needs of application developers, such as the ability to distribute a binary that has no dependencies on any one particular distribution and can open a window and interact with the graphics driver, or the ability to require permissions from the user to do certain things.

I do think that my work contributes to help with this use case. Looking elsewhere on this thread I see that they are having problems fetching and running a nodejs binary successfully. Fortunately, nodejs is a piece of software that can be built and distributed statically. I have not packaged up this one in such a manner but I have done a proof of concept with CPython: https://github.com/allyourcodebase/cpython

That said, if they want to allow users to install Zed through a system package manager, they will need to cooperate with the system and rely on system nodejs instead of trying to fetch it at runtime. Fetching and running software at runtime is fundamentally incompatible with the core mission of Linux distributions (curation, vetting, and compatibility patching of all software that is to be run on the system).

Flatpak is just yet another form of fragmentation though.

Because then you have a dozen other people who say "why didn't they just make a ___"

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...

The same criticisms apply to Tailscale, Homebrew, Pi-hole and all those others.

While it is fairly common way, it does not mean that it is good way.

Not an argument.

My interest is not in using this text editor as a consumer, but in guiding software development culture in general, particularly when it comes to installation of Linux applications.

Some talks I have given on this topic:

https://www.youtube.com/watch?v=pq1XqP4-qOo

https://www.youtube.com/watch?v=CwXixVcliP0

So, I think "entitled" is the wrong insult. "arrogant" would be more accurate.

I don't want to end up with 15 different third party apt repositories

I would love to add 15 different third party apt repositories, I wish more projects used them, you're running whatever binary they give you anyway

I guess this is just another example of how hard it is to please all linux users!

Almost 70% of the male population in my country smokes. Should I take up smoking because everybody else does it?

This also includes the link to the tar files, so, you dont need to read the bash file to download tar file. The ones who are interested in this issue will spot this page, anyways. Maybe, they can make it more convenient for visitors to check this page.

Pipe to sh is simple, transparent

Not so transparent[1]. Packages from a package repo are signed, usually with keys not stored on the same server so if someone nefarious breached a server they can easily replace a bash script, they can't re-sign and replace a package.

Sure it's safe if you download the script then review it then install it, but hey, you reviewed it last time, it's probably unchanged, what's the harm of piping it directly to bash next time you need to get set

https://web.archive.org/web/20240228190305/https://www.idont...

I agree they probably don't have bad intentions. But other options still seen better than the one liner.

Even just as a two liner leaves people a copy of what they ran if something goes awry.

Yep, it's the same as running random code with root permissions.

It doesn't require root. You can read it before you run.

I am less concerned about it being malicious and more concerned about it doing something I do not want re: how the software is installed. Installing software from the distributions package manager is always preferred to doing something manual. When it comes time to update the app, I would prefer to not have to do that in a roundabout way.

"reading a script" is actually a worse user experience on Linux than just using repositories or flatpak, though. It's pretty rude of software developers to put the onus on users to verify that they're not doing something outright malicious in terms of the installer.

A lot of the backlash is around the tool downloading and running an arbitrary shell script which could contain anything, and overlooks the fact that that shell script then downloads an opaque binary which could also contain anything. If you're paranoid about security read the code and build it from source, otherwise curl | bash is trusting the authors just as much as any other method.

Sure, but that convenience will come to bite you later. What happens when you want to update it?

Their full install docs is like 5 lines of code so it is much preferred to do it that way. Every distribution is different. The ideal install here would be to add a unique apt repo for zed and then it becomes part of my normal update process. Updating a binary in a directory is not the end of the world... but I would prefer to know that upfront versus needing to hunt down where it was placed in order to do the updates.

edit its 4 lines. seeing this is much preferred to parsing a bash script that is intended to support all distributions:

    wget https://zed.dev/api/releases/stable/latest/zed-linux-x86_64.tar.gz
    mkdir -p ~/.local
    tar -xvf zed-linux-x86_64.tar.gz -C ~/.local
    ln -sf ~/.local/bin/zed ~/.local/zed.app/bin/zed

Suggesting that users install software outside of official repos isn't more convenient than using a repo and standard package management tools. As soon as there's an update, you'll learn exactly why that is the case.

Am I missing something? NixOS has had it since April https://github.com/NixOS/nixpkgs/commits/nixos-unstable/pkgs...

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.

macOS for example checks the crypto signatures of downloaded apps, so it’s much better than randomly executing code from the internet. I think even Windows does this nowadays.

Because you don't know how the script is going to try to install the program. A double-click installer on Windows has a standard approach that results in the program being placed in C\Program Files and the files being tracked and an uninstaller being placed in a centralized location. On Linux, any random "installer script" could spew files all over your /usr or anywhere else with no way to clean them up. This could even break your OS.

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.

But linux [1] has absolutely zero security measures, and this has basically free reign over your computer to send off your .ssh folder, your browser cache, to install a permanent keylogger, etc.

[1] Standard “GNU”/linux desktops

Obviously most distributions provide package managers that should be used for unified automated update mechanisms and gpg signing. Superior to curl | sh in every way.

Versus what?

Can Linux have something like the Mac App Store where apps don't have access to the whole system by default?

Do you know difference between alpha, beta, and quality software? Linux distros have different goals, or different channels for different qualities of software, while vendors wants their users to be free alpha or beta testers.

Very different levels of trust though. And different levels of effort for malware (burning zero-days is expensive).

Also, cleaner uninstalls. If the software only has access to specific directories, I can be reasonably optimistic that removal will be clean.

Furthermore, it is much more convenient. E.g., I can just winget install vscode instead of having to google download links.

but then I will need curl | sh to install snap :(

Snap is never the answer. Every time I use snap I always get really sad, it could've been great but instead its incredibly slow. Like unusably slow

Just an fyi, I have shot myself in the foot with Sublime's version of this. I became dependent on using unnamed/unsaved documents for quick notes, then at some interval I would clean up. And because Sublime would remember, I could rest safe that they would be there even if closed and reopened until I cleaned them up myself. Well, I also got so hooked on Sublime, I set it as my default system text editor. Then, (more than once), I would click a downloaded text file or something that would open in another window. Then after browsing or something I would be back in my original Sublime window. Close it for the day and as I was closing other windows realize there is another Sublime window still open with that document that I read early ... and all my other temp notes were gone! If you are good at grepping you can still find the files cached on your system with a little work, but something to watch out for. Or just get used to saving files somewhere.

I have a tab in Sublime Text for my todo list, which I created several years ago and never bothered to save. It's a great feature for indecisive procrastinators.

While I love Emacs it's not like this. Scratch buffer? C-c C-x and all is gone without any warning.

Emacs definitely does this. I have saved many files from power outages. M-x recover-file, but the user has to recover the file right away when he opens it again or else a new auto-save will overwrite the old one. I think that's the case.

Just if you close the entire editor. Editors with this feature, if you close the file it will ask if you want to save changes, click no and the changes are lost.

What are your undo settings? I set undofile and undodir, but not sure if it's unlimited.

One issue I have is if nvim is closed and the file is touched by some outside process (say git pull) it clobbers the history. Do you know if there's a fix to that?

And dark mode! And tabs! I love notepad.exe of the future. What a time to be alive

> I'm also very much enjoying the modal editing, which VSCode lacks.

The VSCode Vim plugin works great:

https://marketplace.visualstudio.com/items?itemName=vscodevi...

FWIW Emacs also fits that bill.

Wait, Zed is a modal editor? All i've seen is that it has vim mode, which most editors have and i generally find it insufficient.

Granted these days i still prefer Kakoune style modal editing (i use Helix, currently), so not sure i could move back to Vim style anyway. Nonetheless if Zed has real, first class support i'd be interested... but a second class compat layer is not sufficient in my view.

How's it work for you?

edit: https://news.ycombinator.com/item?id=40929169 this post suggests it's lacking. Which is always the problem to me with emulation :/

Do you find it to be faster than vim/neovim?

Do you use it for Rust? Does it do "Show usages" well when the usages are through a macro?

What motivated you to switch to it from vim?

Have you had much success with VS Code's multiplayer extensions? I've found them buggy to the point of useless, but maybe things have improved. Zed, on the otherhand, is developed by people who understand pair programming, which is my priority.

That seems a bit rude. You get the QA you paid for - zero.

And nevertheless, whenever Windows software doesn't work in Wine, you shouldn't think "Wow, how did you fuck that up?". They never promised it'd work in WSL.

Of course, zed has always felt like an osx first project with linux/windows being second class citizen.

Unless I'm missing something, it doesn't even run on Windows...

https://zed.dev/docs/#download-zed

Maybe they didn't do any on Windows, because this is for Linux, not Windows. WSL is still not Linux. They do appear to have Windows build instructions, though[0]?

[0] https://zed.dev/docs/development/windows

I've not heard of QA in open-source projects... unless it's something peddled by a big corp (eg. Chrome, Go, VSCode etc.)

You are lucky if there's some automated unit testing, but that's as far as these things go. Programmers don't like, don't know and don't want to know how to QA. Also, they generally look at QA with contempt... so, unless forced to, they won't do it.

I just tried it on NixOS 24.05. It starts, but nothing happens when I click "Open a project" or Ctrl+O. It's as if it lacks the ability to show a file selection dialog.

Oh, thank goodness. Yeah, that's going to be a major quality of life improvement for me. I had a feeling it'd eventually make its way into Zed eventually, but when I initially read the issue I was under the impression that there was no plans to add options around this, which I found confusing.

Oh sure, you can create an FHS and have it work, though personally I wouldn't. After all, Zed itself actually does work without an FHS, it's just that any binaries it tries to download will not. Which is actually not a huge problem in my case.

This is a non-starter for many larger companies. With supply chain attacks being what they are currently, this would directly prompt Security teams to block this outright.

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.

If I have to change one character, but the autoformatter reformats the whole file instead... that is a problem. My actual change will be lost in the formatting changes. And who says that I want to reformat anyway?

EDIT: I usually work on projects with a long history. File endings, tab/spaces, etc. are usually all over the place, and we haven't touched actual code yet. I usually have no authority and time to fix formatting issues, especially in "miscellaneous" files like yaml. And the PRs in most places I'd worked at are rejected if they contain something other than what is relevant to the topic of the PR. And then there is the issue of the hidden change, when you reformat a 1000 line long file, and also make an actual change - this will be very easy to overlook.

And finally, I might be using another tool for 99% of the editing (I use IDEA), yet sometimes I just want to edit a file quickly, outside this tool. So I do have an autoformatting setup in IDEA, should that mean that I can't use another editor for quick changes?

But this is the _default_ setting. If you want autoformat on save, that's perfectly fine. Just do not make it default. I can't think of any other editor that does this.

I do believe one can join collab sessions from https://vscode.dev/ as well? So no need to install anything, it runs well and officially in the browser

And for those with installed VSCode they need to add the Live Share extension to get this functionality, it’s not built in from the start, but offered through that official extension? https://marketplace.visualstudio.com/items?itemName=MS-vsliv...

As someone who hates Microsoft, I just wish that other colleagues wouldn’t force me to use their editor to collaborate. I wish there was more effort to build something editor agnostic.

My experience with the VS Code implementation has been constant desyncs between the editor state on the different users computers. At least some of them I could reliably reproduce by using language server commands.

The main reason I'm excited for zed is for an editor that built this in from the beginnings and has the same feature with less bugs.

Indeed, Tuple is a better solution. That said, I think Zed is a great text editor.

There's the relative number line etc, but I've never actually encountered a situation where I felt the need to make a jump to a line number on the screen and didn't do it with basic vim motions instead. Every time I'm going to a specific line number, it's because I'm following an error message that references a file and line number.

I think lots of people are comfortable with smaller fonts, but I find myself genuinely straining my eyes too much and getting headaches if I go smaller than this, and I already wear glasses (although I should probably update my prescription).

I would damn hope you can configure/disable this. But why is it the default?

And if the answer is "discoverability" then where is the default-on fuzzy find, default-on command palette, default-on context menu, etc?

My point was not to claim Zed was bad because I had the ignorant misapprehension that it was incapable of being cleaner, my point was to ask why people desire such a cluttered workspace by default? Most people I see using these editors _don't_ disable all this clutter.

This might seem funny until you read Ken Thompson's "trusting trust" paper and realize that bootstrapping Rust is a so overwhelming task that someone implemented a Rust compiler in C++ for this purpose: https://github.com/dtolnay/bootstrap

I mean, who knows what kind of malware is transparently being injected in all Rust programs out there.

Correction: written in C plus some LISP, as God intended.

I recommend reading this paper, as it gives some understanding of the things that are possible with an infected toolchain: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

Some modern compiled languages such as Zig and Go can be officially bootstrapped from a C toolchain. And a C toolchain can be bootstrapped with Guix using only a 357-byte blob. This gives some good confidence that you can bootstrap a malware free toolchain using auditable source artifacts.

Rust however, does not have an official way to be bootstrapped from a C compiler, which means developers must use a previous version of the compiler to build a new version. In this situation, you can never be sure a malware was not injected in a previous version of the compiler (see the Ken Thompson paper for an example). There's no way to know because you are using a unauditable blob to create another blob.

This is why someone created mrustc, a Rust compiler implemented in pure C++, so that Rust can be bootstrapped from a C toolchain (see also: https://users.rust-lang.org/t/understanding-how-the-rust-com...).

The mrustc solution is not good because there are essentially 2 implementations of the same compiler that have to be kept in sync. It would be much better if Rust used a solution like Zig's: https://ziglang.org/news/goodbye-cpp/

Now see, I'm the opposite. I would like to pay a reasonable fee to drive a silver-and-oaken stake through the heart of the collab features. I will pay real money to just make it all go away. As others have said, I work in an environment with lots of different tools so collab stuff like this is just visual noise, let me turn it all off.

i.e. very similar to how other editors approach it

e.g. vscode uses network features to make people use the non fully open source version instead of codium (and it's otherwise subventioned by MS to reach the part of the editor/programmer market visual studio can't reach but IMHO if it wouldn't be that is also how they would bring in the money)

that is actually really cool - I always felt like (and surely am not the only one) that vim is great keybindings but an okay editor. If someone addresses this that'd be incredible.

I was watching thorsten and the primeagen's chat yesterday https://www.youtube.com/watch?v=8XweSqTYdMQ and thorsten was describing a few challenges with translating vim's functionality into zed.

Part of it being that zed doesn't have an intermediate layer between keyboard input and keybindings, so by the time the vim layer is hit it has been translated to a keybindings - that limitation kind of put me off.

i definitely agree, and Id LOVE a snappy editor, but I struggle to trade thay off with everything else other editors provide

I'm not sure how much of it is people being (irrationally) scared vs. looking into native APIs and making the call that it just isn't worth it, given how much messing around you have to do to get basic functionality working vs. the web where you can throw a UI together very quickly to validate an idea.

I've looked into native Linux development a few times, for example, and haven't even been sure what's the best toolkit to use. It feels like you'd have to invest quite a lot in a particular toolkit to even see if it can do what you need, coming fresh from web dev like a lot of people who go for Electron obviously are (myself included).

Hey! Nate from Zed here - have you had issues with proportional fonts in Zed?

Let us know if so - they should just work™, but would love to know if that is not the case.

That's amazing, thanks for sharing this. Native desktop UIs are an area of interest for me so this will be an exciting read for me

nvim+lazyvim+telescope (which uses ripgrep and/or fzf). Fantastic, that's the gold standard for finding files, grepping, looking for references to variables etc. Love it.

When searching I get almost entire file snippets with the search content and scrolling through them would take forever. In comparison see Lazyvim or IntelliJ products search UI, (even vscode is OK, though it requires mouse a bit), you should be able to scroll through found lines, and while you do that you can see the surrounding context of the selected line.

This example can illustrate the point easier, one scrolls through lines, while having a preview on the right: https://miro.medium.com/v2/resize:fit:1400/1*1cwOdRcJ_Ix9RR4...

Lazyvim or pycharm search functionality. Even vscode is better in that regard, though it kinda requires using mouse. (I love sublime btw, except for searching)

Its actually pretty obvious advantage if you are often ctrl+b hide sidebar because instead of jarringly moving start of the line you are revealing code without moving it.

Same. It also mean when toggling the bar what moves is the bar not the code.

Same here! Also, when it’s on the right toggling it doesn’t move the code panes left and right.

Lots of the app’s UI right now is a layer of components on top of gpui (check out the ui crate!) that are pretty Zed-specific at the moment.

Some of these things will likely be made more general and have dedicated gpui elements built for them (button, input…)

I think not rushing to cover everything right out the gates is giving us the time to feel out apis that feel good to write and work well for us. Hopefully in the near future that translates to a UI library that is awesome for the whole rust community to use.

Thanks for the links. The approach described in that blog post seems like it could actually achieve crisp, native-looking text. What a welcome improvement that would be compared to the blurry, misshapen, overlapping, or poorly laid out results I've seen from other new GUI frameworks.

Today, sure. That doesn't preclude it from maturing into something more generally useful, nor from eventually getting its own repo. I've built more than a few libraries that started out as functions and data structures within application code.

Indexing maybe. But there's more: IntelliJ understands your code, and this make more sense for static/strong typed langs. We do a lot of Kotlin and IntelliJ is indispensable.

IMO for a graphical program that's fine, but in general I really hate hard requirements for a GPU which I've seen in the wild multiple times. Just simulate the darn thing in software, I don't care if it takes 10x longer, I have all the time in the world.

yes. it's working fine for me on 9 y/o integrated intel graphics.

but it's kind of still a weird statement to make. i thought it was generally the OS's job to supply the vulkan layer, and that mesa -- which just about every linux OS will be using -- provides pretty robust software implementations of those things as fallback. what would cause them to require a "physical" anything?

Wait, added 2 months ago? This isn't new then, i take it? Interesting. Linux release announcement now i wonder?

I expected this just was released today, so it definitely wouldn't be in Nixpkgs yet lol

Tried the advice, but wasn't able to change behavior. Added a [comment](https://github.com/zed-industries/zed/issues/13552#issuecomm...) to an existing issue

Great! I am way more likely to try out software when it's available as a regular package that I already know how to manage.

I really don't have much to say, just wanted to thank you for officially releasing a Linux build, and supporting us at all. We, the silent majority, very much appreciate your work. Every release of every application brings out the moaners, this is to be expected. Thanks.

Absolutely.

It doesn't really matter, it's open source with a growing community already, so it can only keep going if the company dies

Komodo had some promise, in kind of the same way the original hype about Perl 6 had promise. For its time, it had features that were not widely available in other editors. However, I found it to be slow and buggy. And that was compared to Eclipse which was notoriously clunky. (Note: a quick look at the modern Komodo Editor, which appears to still be actively developed, looks much closer to a Visual Studio Code clone and is nothing like I recall the original)

I recall it was pitched as a slightly lighter alternative to eclipse and intellij but initially geared towards Perl development (with plugin support for all languages). However, that kind of middle-ground wasn't popular at the time and devs mostly split into the full featured IDE camp or the stripped down editor camp.

Editor hype cycles come and go. That's part of the reason I am so jaded when I see a new cycle start for a new editor.

Yeah, right on! We Linux users love dicking around getting software to work on our multi-variant systems. Why maintain a universal package when you can sit and read through issues from nerds trying to get your software to work on insert trendy distro here

I am not against Zed in any way -- note that I have upvoted and favorited this article.

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.

This is a good question. It is not like the current `zed` binary is linked to anything that is needed for 3D rendering:

    $ ldd zed.app/bin/zed
        linux-vdso.so.1 (0x00007ffed63f6000)
        libgcc_s.so.1 => /nix/store/bihw7p4zdqwyxmnc8h67c06lnjkvdan8-xgcc-13.3.0-libgcc/lib/libgcc_s.so.1 (0x00007fb5def3c000)
        libpthread.so.0 => /nix/store/m71p7f0nymb19yn1dascklyya2i96jfw-glibc-2.39-52/lib/libpthread.so.0 (0x00007fb5def37000)
        libdl.so.2 => /nix/store/m71p7f0nymb19yn1dascklyya2i96jfw-glibc-2.39-52/lib/libdl.so.2 (0x00007fb5def32000)
        libc.so.6 => /nix/store/m71p7f0nymb19yn1dascklyya2i96jfw-glibc-2.39-52/lib/libc.so.6 (0x00007fb5ded3b000)
        /lib64/ld-linux-x86-64.so.2 => /nix/store/m71p7f0nymb19yn1dascklyya2i96jfw-glibc-2.39-52/lib64/ld-linux-x86-64.so.2 (0x00007fb5df05d000)

lol. Of course they would change the one thing i thought was great. and they bumped ligatures to eleven on top of the change. sigh.

future generations will look at our silly use of ligatures like we look at comic sans.