I wish developers finally learned this lesson. As a screen reader user, I'm sick of all these "modern" tools written in Rust (and yes, it's nearly always Rust) where Voice Over just sees an empty window. It's far easier to dig yourself out of the trap of no accessibility if all you need to do is to slap a few aria labels on your buttons and sort out some focus issues than when you need to expose every single control to every single OS.

At least there's AccessKit[1] now, which might make the work a bit easier, though I'm not sure how suitable it is for something as big as an editor.

[1] https://accesskit.dev/

> Currently, many of Zed's themes are largely inaccessible. We are working on a new accessible theme system, which will launch with Zed 1.0

> A11y (accessibility) in Zed will be a long project. Likely lasting far beyond 1.0. Due to GPUI being written from the ground up we don't have access to the same a11y features that Swift, Web-based apps or [insert other language] does.

> Making Zed accessible will be a joint effort between things on the Zed side, and building out features in GPUI.

> For now, you can join this discussion to talk further about a11y in Zed: Accessibility (a11y) in Zed [links to: https://github.com/zed-industries/zed/pull/1297]

And that link is useless, it goes to a Github issue about back and forward buttons.

https://zed.dev/docs/themes

https://github.com/zed-industries/zed/pull/1297 - the link they use that's supposed to be for accessibility discussions. It appears it's supposed to be a link to this: https://github.com/zed-industries/zed/discussions/6576

So they've thought about it, but they haven't actually done it yet.

In my experience, a11y shouldn't be an afterthought but baked-in from the beginning. Doing the latter results in hacky, harder-to-maintain code.

If you think about it, doing accessibility right -- in particular screen reader work -- requires thinking very carefully about the data model behind the presentation. What you need to declare and when. And doing that thinking actually could force engineers into building UI frameworks that not only are accessible for the visually or auditory impaired, but for broader systems as a whole.

It's hard work that has to get done, but it's not particularly sexy.

Not long ago there weren't any gui libraries that wouldn't be just binding to existing C framework or was in proof of concept state of lifecycle

I'm sure this situation will improve in the future and I understand frustration of someone that rely on a11y features, but you need to understand that everyone first will try to achieve solid gui library before will start adding accessable functionality

They are doing amazing job with whole desktop environment. I'm yet to check first hand their work, but so far looks very promising

From a product perspective, re-inventing the wheel for something that — at best, many years from now — will be at parity with native presentation layers in terms of performance, a11y support, user experience, etc. is normally considered a risky move. Many startups have failed in part from pouring resources into shiny non-differentiators.

The only examples of successful products that use non-native UIs either (1) leverage web technologies or mature frameworks like Qt, or (2) are Blender (age 30). Apple did this with iTunes, but iTunes felt unpleasant on Windows, and people used iTunes for Windows in spite of this. I understand the appeal of creating frameworks like GPUI, but the article doesn't explain the relationship to the problem Zed is trying to solve.

There's also Google Docs, which uses weird tricks instead of rendering straight to DOM. They didn't even bother implementing accessibility in that layer, something which would probably have been impossible back then. Instead, they offer an accessibility mode and mark their entire UI as hidden to assistive technologies. When the accessibility mode is on, all speech is generated by a micro screen reader implemented in Google Docs directly, and the generated messages are sent as text to be spoken by your real screen reader. This is an ugly hack that doesn't really support braille displays very well, so they later implemented yet another layer of ugly hacks that retrofits the document on top of an actual DOM.

Your point still stands though, these are exceptions that prove the rule.

"Pulling this off was really hard; we’ve basically ended up building a browser inside a browser. […] Instead of attempting to get one of these to work, we implemented everything from scratch using WebGL. Our renderer is a highly-optimized tile-based engine with support for masking, blurring, dithered gradients, blend modes, nested layer opacity, and more. All rendering is done on the GPU and is fully anti-aliased. Internally our code looks a lot like a browser inside a browser; we have our own DOM, our own compositor, our own text layout engine, and we’re thinking about adding a render tree just like the one browsers use to render HTML." https://www.figma.com/blog/building-a-professional-design-to...

The value proposition of a "boil the ocean" approach to UX frameworks is clearer for browser-based apps than native apps. That said, 7 years in, Figma apparently has a long way to go:

"To repeat a familiar refrain: We still have a lot of work to do! As we continue to improve access to our own products, we’re also advancing our understanding of what our users need to design accessibly." https://www.figma.com/blog/announcing-figjam-screen-reader-s...

Successful non-native UIs? Microsoft Office. Every single Adobe product, including the ones they got from Macromedia. I feel most professional software fall in this category. Spotify originally launched with completely custom UI. On Windows it is more difficult to name successful products that used native UI than those that did not.

I always assumed it was since the accessibility is there, but these are all Microsoft APIs after all, so they might just have implemented them on their own.

Something that works on any set of pixels and sees like a human does?

I.e parses text with OCR.

It's good enough if you have to click a broken "I accept your terms and conditions" checkbox, but nowhere near good enough to daily drive your phone with. In other words, a band-aid solution for when everything else fails, mostly for situations where the app you're trying to use is mostly usable, but has an accessibility barrier preventing you from carrying out a crucial step somewhere.

There's also vocr on Mac (and equivalent solutions on Windows), which recently got some AI features, but it doesn't even recognize control types (a very basic feature of any screen reader), just text. Again, good enough to get you through most installers where all you're doing is clicking "next" ten times, probably good enough to get you through the first-run experience in a VM that doesn't yet have a screen reader installed, at one tenth the speed of a sighted person, but that's about it.

If this were a simple, offline editor, a decision not to focus on accessibility would be far easier to swallow. They seem to be heavily promoting their collaboration feats. If those on your team collaborate using Zed and expect you to do the same, other tools aren't an option.

A11y isn't about helping one set of users (those who have completely lost their sight), it's about helping a whole spectrum of accessibility challenges - not by prescribing boxed solutions, but giving the user options customizable to their specific needs.

Disability isn't a permanent state that you start with. It's something that can happen to you 5 years into your career, or 15. It can also be temporary - you break your leg and now you need crutches, a cane or a wheelchair until you heal, for example.

Accessibility also helps people who you wouldn't traditionally classify as disabled: Designing UI to be usable one-handed is obviously good for people who have one hand, but some people may be temporarily or situationally one-handed. Not just because they broke an arm and it's in the cast, but perhaps they have to hold a baby in one arm, or their other hand is holding a grocery bag, or they're lying in bed on their side.

Closed captions in multimedia software or content are obviously helpful for the deaf, but people who are in a loud nightclub or on a loud construction site could also benefit from captions, even if their ears work fine.

So, ultimately: Why should someone who's used to using a given editor have to switch any time their circumstances change? The developers of the editor could just put the effort in to begin with.

ramps (by parents with babies in their strollers), subtitles (by people learning languages or in loud environments), audio description (by truck drivers who want to watch Netflix but can't look at the screen), audiobooks (initially designed for the blind, later picked up by the mainstream market), OCR (same story), text-to-speech, speech-to-text and voice assistants (same story again), talking elevators (because it turns out they're actually convenient), accessibility labels on buttons (in end-to-end testing, because they change far less often than CSS classes), I could go on for hours.

For user interfaces specifically, programmatic access is also used by automation tools like Auto ID or Autohotkey, testing frameworks (there's no way to do end-to-end testing without this), and sometimes even scrapers and ad blockers.

If a programmer is using audio for feedback, then there is probably be some impedance mismatch by translating a visual interface into an audio description. Shouldn't there be much better audio encoding of the document? There would also be many more wasted cycles pushing around pixels, which the programmer will never see. An editor made specifically for visually impaired programmers, unencumbered by the constraints of a visual representation, would be able to explore the solution space much better than Zed.

[1] https://emacspeak.blogspot.com

"Customer Data consisting of User content created while using the Solution is classified as "User Content". User Content is transmitted from Your environment only if You collaborate with other Zed users by electing to share a project in the Editor.

[...]Zed's access to such User Content is limited to debugging and making improvements to the Solution."

No commentary from me. Come to your own conclusions.

Of course if you choose to share your project with others for collaboration, the content of that project is transmitted from your machine, what else would you expect? How would it work otherwise?

Basically the Zed company also gets access to the code you're sharing with other users.

Is that right? If I understand that correctly I think that’s going to be an instant no for a lot of people.

Neither of those things are the same here.

They have already trust in place. Do they trust Zed too?

- Only if you explicitly consent we will store your code or parts of your code on our servers.

- Only if you explicitly consent we will read your code for improving our product.

- Otherwise your code will never be stored on our servers. Data may reside in memory during sessions, but will never be stored.

The issue is that you when using Zed you implicitly agree that they store and use your code the moment you use the flagship feature of the editor.

It's their product, they can do whatever they want. But this behavior is a big red flag for me.

The thing is every time you load company proprietary code and/or sensitive data you better make sure you don’t hit the share button as well.

Not the end of the world but also something we didn’t have to think about until recently. That pushing a button (other than delete) could potentially get you fired.

Are you concerned using email in general?

Because every-time you hit “send” sounds scary as well.

Joking aside, it seems fairly obvious that the risk is on you if your “share” your company’s sensitive code.

You're joking about email, but that's of course the reason why companies will pay a lot to host email on premise instead of relying on cheaper offsite solutions. I think Exchange Server is Microsoft's biggest foot in the door to access conpanies tbat otherwise wouldn't care much about the other Microsoft services.

Having a third party look at every email you're sending around is just a non starter for many businesses.

Getting the same setting in an editor where your code is shared with the editor company everytime you want to show it to a colleague is not trivial at all.

In addition to lag and a poor visual experience as others have mentioned, there's the issue of two (or more) operating systems with two separate shells/UIs. When using VMs or a VDI/remote desktop the cognitive overhead of remembering which OS shell I'm in for the purposes of keyboard shortcuts, clipboard, switching between programs and etc impacts my productivity significantly.

VSCode (or any other editor with similar features) shell is great because it completely separates the editor environment from the dev environment. I can run as many instances of VSCode as I want each with their isolated dev environment of the target host, but all managed by one shell, one window manager and one clipboard.

I only have one disagreement with them. . .

> the perfect name for a text editor in Zig is already taken: Zed

No, it’s “Zag”. ;)

> > the perfect name for a text editor in Zig is already taken: Zed

> No, it’s “Zag”. ;)

Except that `zed` contains `ed`, precursor to `ex`, `vi`, and `edlin` yet still around:

`ed` is a line editor for Unix and Unix-like operating systems. It was one of the first parts of the Unix operating system that was developed, in August 1969. It remains part of the POSIX and Open Group standards for Unix-based operating systems, alongside the more sophisticated full-screen editor `vi`.

https://en.wikipedia.org/wiki/Ed_(text_editor)

While `ag` (the silver searcher) is fantastic, Zed's more about editing code than searching code:

https://geoff.greer.fm/ag/

This is depressing, considering that ed is the linchpin of the contemporary I.T. environment.

more recently, interfaces to tools like ripgrep also have the ability to have an editable mode, super handy for refactoring.

(and of course you can edit file names in bulk, too ..)

https://www.masteringemacs.org/article/searching-buffers-occ...

https://rgel.readthedocs.io/en/latest/

https://www.gnu.org/software/emacs/manual/html_node/emacs/Wd...

It's absurd but one of the primary reasons I use Jetbrains over vscode is because i can search for a directory and open it in the navigation pane.

But the point is that "editor" is non-functional. It's nice for browsing the results and has syntax highlighting and surrounding context, but you can't actualy edit from there. You can only use it to open the source file and then edit the source file.

In Zed, the search results "editor" is actually functional. You can make changes to the text that you see from the surrounding context, right in the search results, and then hit save, and have those changes propagated to all the touched files.

So, say you update a function to take another argument, and you want to update your codebase appropriately. Well then you do a global search for that function name, and then scan down the results list. The irrelevant search results (maybe you mention the function in a comment, but aren't actually invoking it) you can skip. The complicated updates you can open the source file like you do in VSCode. But the trivial ones where you can see what you need to pass as the new argument, you can just update right then and there.

I've had a look though, and you were right: it's due to an extension that I can save from the scratch file:

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

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

One of my favourite tricks is multi cursor, edit and use end of line or next word shortcuts to make bulk edits.

Doing that across files would be cool!

How does that follow from the rest of your comment?

(Notably, communication coming out or through legal counsel cannot be assumed to be good-faith, the premise of the court system being that the best we can achieve is two bad-faith adversaries and a neutral arbiter. But that’s not what we are dealing with here.)

Pedantry aside, I think I remember one of the developers saying they do plan on Linux support at some point in one of the previous Zed threads here. There were also some “small team” and “laser-focused” and “best possible experience” in that comment, but they did say outright they were planning on it. Though plans change, I think that’s the best we could hope for at this point, as I doubt even they themselves know more about their future.

[1] https://en.wikipedia.org/wiki/Cooperative_principle

And so far Linux support has been a big community effort. I think more community member contributed to Linux support than Zed teammates. Very cool to see.

So: Linux is in the works. Windows will probably happen after that, or if someone in the community wants to emulate what the Linux users are doing and start before that.

As a side note, Linux is going pretty strong!

Love how much thought is being put into what you “gold-plate”. I’ve always felt that my best work comes around on round two (or three or four…).

Curious what you are planning for the ability to script the configuration? I haven’t played with zed much yet; is it possible today? Would something like Neon [1] help bridge the gap from VSCode and old Atom users?

[1]: https://github.com/neon-bindings/neon

- Brooks, Mythical Man Month

It is always interesting to see v2. I have witnessed cases where they are catastrophic due to feature overload but also cases where they are phenomenal because they are streamlined and lean.

I also wonder, with all the tooling available now at least in the space of web apps, if this quote notion of danger applies as much to v1s as I have seen v1s remarkably bloated these days. I often have to purposefully seek out tools that do less.

I went from Atom to Pycharm to Vscode. Both transitions were fairly easy. Though I’ve never had any complex configurations.

I would be more inclined to use Zed if it could displace XCode. It pains me to use it from deleting derived data or cleaning the build folder to random crashes.

Contrasting the DX to Android Studio, it's night and day. I always wanted an Android studio-like experience for iOS development.

Apart from package managers, I like the auto-import features for frameworks in Android Studio. As well as the "fix it" UX, which is similar to VSCodes. Having an integrated terminal is something Xcode still lacks, and maybe a better UX than a Plist to configure projects; I know XcodeGen/Tuist and other tools exist, but something built-in would be nice for fast project config.

This is somewhat exacerbated by the need to import so many libraries in Android projects. My Mac/iOS projects have between a fourth and sixth as many dependencies as their Android counterparts.

CocoaPods though… ugh. Horrible. Was thrilled to part ways with it several years ago.

VS Code came up out of nowhere pretty recently, and is used by a lot of people, so that shows that there is (or was, but still post-vim) opportunity for a new editor. Whether Zed is able to gain momentum to cater for the long-tail that other developers do remains to be seen, but I'm pretty keen to see more products trying to compete for users.

[0] https://insights.stackoverflow.com/survey/2021#most-popular-...

Also, you know, insert Emacs joke here assuming if you still have enough RAM to post, etc.

All composed commands. Like Repeat. As in `repeat the following command 5 times`.

Like `d5` in Vim (delete 5lines).

Or y30 (Copy 30 lines).

Or `V?^func` (select text from current cursor position to the beginning of the function).

None of those are memorised commands. They're simply one command composed with another.

Composability is the real killer feature in Vim. Even in Emacs, I don't get the same ease of composability as I do in Vim.

Well, that changes things. I replied to the 'programming text editor' part.

The editor wars are over and everyone won because of separation of concerns. Yay!

I also use either vim or nano when viewing/editing files on the command line (either msys2 wsl, or headless linux).

Re: IDEs, I mainly use IntelliJ, with VSCode being used for a few things.

The folks I know who use Emacs or vim (including me) are by and large still using those tools since before Atom and Sublime got popular. We just have LSP, now, like VSCode does.

It was a really slick play. Still, it was an overall positive for the profession, and you can still use VSCodium without the telemetry.

I've tried to switch to neovim twice since and gave up. Lua is nice and I did get into that the first time. Crashing and errors were rife though. The second time, which was very recently, it seemed like everything had changed again, all completely new plugins etc. And I struggled to do some basic stuff, I guess I've just forgotten the more in-depth file/window management. So it goes.

I'm thinking it would be nice if my Lazarus IDE supported Vim commands.

https://github.com/neovim/neovim/wiki/Related-projects#gui

There's also the GitHub topic:

https://github.com/topics/neovim-guis

They did not seem applicable when I first saw them, so ... Mea Culpa?

Feature parity with Vim is not meaningful in my opinion. LSP evened the playing field enough for all editors to the point where you can daily drive anything and be no less productive than most.

Use whatever you like and helps you get the job done. That includes Vim too, but I'm getting sick and tired of people acting like using Vim is some kind of irreplaceable boon. Becoming a better thinker will make you an exponentially better programmer than any tool.

Vim's understanding of tokens makes some reasonable assumptions, but unless you've configured the textobjects plugin to talk to a properly configured language server, you're working on vim's presumed tokenization and not a tokenization that's native to whatever the underlying language is. Helix tries to bundle this in by default, but it still doesn't feel like a first class citizen.

As for turning machines, not since the 80's have the tokens that appear in our editors been the tokens that are manipulated by our processors. There are typically a myriad of bytecode translations or compiler optimizations or parser hijinks between what you're editing and what you're running. It's the AST that matters to the code author, and the AST is a tree, not a string.

We need to get to the point where you can directly annotate on a function parameter:

> this function is slow when this parameter is > 100

...such that the annotation sticks to that parameter, however the viewer has chosen to render the text.

The best we can do at present is to sprinkle some text nearby leave the problem of deciding which parameter and which function are referenced an exercise for the reader. This then necessitates that we preserve the way the text appears, which prevents us from presenting it differently based on the view context (e.g. maybe the reader prefers different units, timezones, or a language which flows their text differently than the author).

LSP can be the foundation to a paradigm of code editing instead of text editing. I want the kind of integration we have with Smalltalk IDE like Pharo and the SLIME plugin for Common Lisp and Emacs.

> It's the AST that matters to the code author, and the AST is a tree, not a string.

I'd take variable inspection (not sure it's the real term) before AST manipulation. More often than not, I'm more worried about the result of data processing than the processing itself. Such capability exists in live programming, such as the system itself. And I believe this kind of rapid feedback is a much better experience.

Some pretty full-featured editors already exist that people are happy with or, perhaps, have at least gotten used to. Where does a new editor fit in?

It's neat that it's "multiplayer" but that's an edge case.

I'm also not convinced by the business model. Do people really want channels, calls and chat integrated with their code editor? Personally, I have an almost visceral negative reaction to the idea but maybe that's just me.

Chat is similar.

I think of something like grep, where if I tried to grep a large hierarchy it'd be really slow and I'd sorta reason to myself "well yeah it's a lot of files in a large tree, of course it'll be slow!". Then I installed ripgrep and suddenly what I thought was a reasonable speed was shown to be unreasonably slow!

A few months ago I switched to WezTerm and, after some config wrestling, I've been very happy using it (https://github.com/bbkane/dotfiles/tree/master/wezterm).

edit: see this comment for a much better explanation than mine of what I originally meant https://news.ycombinator.com/item?id=39409763

VS Code starts in under a couple of seconds, and I have it open all day long; once open, other windows open even faster than that.

If it took any longer than a couple of seconds, I'd start blaming the extensions other editors won't have.

If I'm opening a codebase with thousands of files, I don't mind to wait a couple of seconds, as long as it's responsive afterwards.

that's just the first noticeable difference.

but there have been instances lately where opening, editing and saving the file took me less time with zed than just open it in VS Code and waiting for it to be ready for inputs

> VS Code starts in under a couple of seconds

I am talking about relative speed differences. Imagine you open the same code base and the editor is ready in half a second. going back to the "slower" one would be unbearable.

now admittedly zed is no way near to the extensibility of VS Code so it is probably doing less and that's where probably much of the speed difference comes from, but it can't really be overlooked once you experienced it.

There’s some talk in the Mac world about “Mac-assed Mac apps”. I use BBEdit as my main editor because it feels right. The default shortcuts are like every other Mac app. You can use standard Mac tools like AppleScript to automate it. It uses the same fonts, widgets, and menu systems as everything else. It’s made for that environment and it shows in a million ways.

VSCode is a marvel of engineering and I love that it exists. It also feels uncanny-valley “off” on my Mac in ways that make my brain itch, so I don’t use it. Same with Obsidian: it’s a brilliant app, but it bugs me. It’s not bad in any way, it’s just not the right choice for me.

Unfortunately Zed lacks good defaults (like a way to change tabs without the mouse) and certain vs code features like snippets. Makes it difficult to transition a team which has been dependent on Vscode and which has absolutely no interest in spending our days configuring tools

Community usually wins

>I don't know about zero cost — every abstraction has a cost, I guess

Part of the cost Rust incurs is the compile time. But thanks to LLVM it seems you can in general have zero-cost abstractions, if we mean high level syntax with low level performance. Feels like a golden age of language design atm.

Anyway, the “let’s do it right, and do it ourselves” philosophy is attractive and I’ll be downloading Zed to check it out.

Anyway, development kind of died off on it, it had insane potential in my eyes.

Hopefully Zed can achieve a similar feat (more likely targetting VS Code plugins?) or some other rich plugin ecosystem.

https://github.com/onivim/oni2

I hate VS Code so much for many reasons, but performance or memory usage are not among them. It starts in some seconds, never been a problem. Runs fast enough. At work I got a MacBook Pro, performance is even less of an issue, of course.

So, I'm not sure all the work done regarding performance is the most efficient way to get into the market. It's features, like their collab stuff, I'd say.

Or usability features. What I hate most about VS Code are the clunky editor navigation shortcuts. Code navigation is fine, but moving around the editor, opening files, command palette, ... if you ever have used neovim with telescope or JetBrains IDEs then VS Code feels so cumbersome.

I wonder if Zed uses SIMD, to read in text from a file or write out text to the display.

Mitchell recently wrote about how he got a massive reduction in latency, by implementing SIMD in his terminal app (which is analogist to an editor)

https://mitchellh.com/writing/ghostty-devlog-006

https://hachyderm.io/@mitchellh/111919642467789362

> Unfortunately, compilers are notoriously bad at autovectorization and with the exception of relatively trivial loops, compilers rarely autovectorize effectively.

from the article

> JavaScript is... You think you have an array of objects, but you really have an array of pointers to objects. So every single time you're walking over that, you're chasing it down.

Sorry for being that guy, but vim. Nvim specifically.

So, I had to decide on an IDE to live for the next few decades or for as long as I needed one. The final battle was between Emacs and Vim. I had played around with both in my prior developer life. I took time to read up, play around, and realize I'm not living in an IDE (Emacs), so I ended up with MacVim. I set it up enough to my liking.

Just as I was getting around, a recent release of Zed surfaced on Hacker News. This is my go-to IDE for now. I still fire up MacVim for quick edits and to keep learning in case I need to settle down on it.

Disclaimer: I'm not a regular developer no more.

VS Code and Atom have different code bases with different decisions and that makes a difference despite them both using Electron and JS. (Hopefully I have understood your question properly.)

However, the tech stack itself isn't the solution to latency. Doing an unbounded operation before responding to input will cause it, so will overusing memory and/or cache.

It's their call, but I feel like I've seen this story play out the same way you describe hundreds of times. I'll never forget when the warp.dev people came to HN looking for feedback and got torn to tatters by the community. A single-platform POC editor is cool, but not really a functional replacement (or even comparison) to what Atom did and the community it garnered. I'm glad they're making what they want, but they're absolutely trapped in bubble-vision afaict.