Live data from Hacker News

We Have to Start Over: From Atom to Zed

zed.dev

181–190 of 243 posts

Re: We Have to Start Over: From Atom to Zed

#181
post #160

I don't use Zed, but I noticed José Valim using it when he was live streaming a coding session. I mostly use VSCode, but one feature he used in Zed was really compelling: he did a "Find All", which was similar to VSCode in that it opened a results pane with snippets from all the files that matched, but then he was able to edit the snippets directly from there, and was able to use multi-cursor editing and all the othe…

In VSCode if you do super-shift-f for find-in-project, at the top of the results pane, just right of where it's marked "x results in y files" there's a link button titled "Open in editor" which I believe does what you're describing. I'd actually forgotten about it until I read your comment so I'll start using it again now.

I don't seem to have that. There's nothing to the right of my "x results in y files" summary. Maybe you have an extension installed?

Re: We Have to Start Over: From Atom to Zed

#182

I don't use Zed, but I noticed José Valim using it when he was live streaming a coding session. I mostly use VSCode, but one feature he used in Zed was really compelling: he did a "Find All", which was similar to VSCode in that it opened a results pane with snippets from all the files that matched, but then he was able to edit the snippets directly from there, and was able to use multi-cursor editing and all the othe…

This sounds like it could be very useful. Does it work like this VSCode extension, "Search Editor: Apply Changes"? https://marketplace.visualstudio.com/items?itemName=jakearl....

Mmm, -ish. I searched for an extension in VSCode when I saw it in Zed, and that extension came up. But it looks like you still have to open the editor tab to save it and stuff. It was much more streamlined in Zed. You just made the change right there, and I think if you hit "save" on the search results it would save to all the files that you touched.

Re: We Have to Start Over: From Atom to Zed

#183

Their custom UI framework might be all fun and games for now, but that will probably change once they realize they need to implement accessibility. Doing this in a custom framework without sacrificing performance won't be easy and is going to require lots of messy, per-platform work. It's not like it's optional for them either. It would be for a simple editor that you can just decide not to use, but they're positioni…

Honest question out of curiosity-

Are there possibly AI-based solutions possible that can add assistance at a more generic level that doesn't require software that has "deep" knowledge of the window architecture (and the actual text in it etc.)? My understanding is that this is how tech like VoiceOver works- it knows the actual window definition and all the elements of it at a programmatic level and can take advantage of that.

I'm not asking if they're already available (although that would be a nice option), but for projects like this that wanted the speed of rendering on the GPU (at the possible cost of, as you said, VoiceOver seeing an "empty window"), it would be at least a fallback position.

(So does this mean that ALL content that renders through the GPU, such as games, are inaccessible to you? If so, I'm sorry...)

Not sure if this might help you but I have an Apple shortcut defined on my iPhone called "GPT Explains" that is activated by a double-tap on the back of the phone (which you can assign, as you probably know, in Accessibility settings)- it takes a screenshot, ships it off to OpenAI and returns with a description of what it's seeing, any to-English translation of non-English text, and any counterarguments to any claims made in a meme, etc. (yeah, the prompt for this is kinda wicked, lol). If this is helpful to you, I can give you a link after I remove my OpenAI key (you'd have to provide your own).

EDIT: I made a copy of it without the API key: https://www.icloud.com/shortcuts/0d063c6810d74a35a017e5a5f69...

Re: We Have to Start Over: From Atom to Zed

#184

Their custom UI framework might be all fun and games for now, but that will probably change once they realize they need to implement accessibility. Doing this in a custom framework without sacrificing performance won't be easy and is going to require lots of messy, per-platform work. It's not like it's optional for them either. It would be for a simple editor that you can just decide not to use, but they're positioni…

Honest question out of curiosity- Are there possibly AI-based solutions possible that can add assistance at a more generic level that doesn't require software that has "deep" knowledge of the window architecture (and the actual text in it etc.)? My understanding is that this is how tech like VoiceOver works- it knows the actual window definition and all the elements of it at a programmatic level and can take advantag…

iOS already has such a feature, but it's obviously not 100% accurate, not real time, and not great for battery life.

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.

Re: We Have to Start Over: From Atom to Zed

#185

Their custom UI framework might be all fun and games for now, but that will probably change once they realize they need to implement accessibility. Doing this in a custom framework without sacrificing performance won't be easy and is going to require lots of messy, per-platform work. It's not like it's optional for them either. It would be for a simple editor that you can just decide not to use, but they're positioni…

> I wish developers finally learned this lesson. 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…

There's also Zoom, which apparently uses an internal, heavily-modified fork of some Chinese UI framework on Windows (and QT on everything else). They did go the extra mile and add accessibility support though, their American clients, particularly the ones in government, healthcare and education, didn't really give them any other option.

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.

Re: We Have to Start Over: From Atom to Zed

#186

Earlier quoted context omitted.

It can take an instant to become disabled: there is no permanent and distinct set of "disabled and "not-disabled" people.

Not to defend GP, but if I suddenly went blind, I really don't know if it would take longer to learn how to use my existing tools with a screen reader or to learn new tools better designed for it. It would be a completely new and foreign workflow either way.

This is not about what tools you want to use, but what tools you're forced to use by your team.

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.

Re: We Have to Start Over: From Atom to Zed

#187

Earlier quoted context omitted.

Why bother with accessibility. If a disabled wants to use an IDE, use a different one??

I'm guessing this was downvoted for being rude, but I think there is a valid question here. It looks like Zed is putting a lot of work into minimizing the latency between a key being typed and feedback being displayed on a visual interface which is easily parsed by a sighted user. If a programmer is using audio for feedback, then there is probably be some impedance mismatch by translating a visual interface into an a…

This has been tried in Emacspeak[1] and doesn't work that well in practice. I'm in the blind community and know plenty of blind programmers, none of whom seriously use Emacspeak. VS Code is all the rage now, and for good reason, their accessibility story is excellent, they even have audio cues for important actions (like focusing on a line with an error) now.

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

Re: We Have to Start Over: From Atom to Zed

#188
post #159

Earlier quoted context omitted.

Accessibility helps all users, not just disabled users.

Which accessibility features are you most commonly using ? Just wondering, what are the most used accessibility features, that new GUI-s don't have.

> what are the most used accessibility features

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.

Re: We Have to Start Over: From Atom to Zed

#189

Earlier quoted context omitted.

> I wish developers finally learned this lesson. 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…

There's also Zoom, which apparently uses an internal, heavily-modified fork of some Chinese UI framework on Windows (and QT on everything else). They did go the extra mile and add accessibility support though, their American clients, particularly the ones in government, healthcare and education, didn't really give them any other option. There's also Google Docs, which uses weird tricks instead of rendering straight t…

Interesting, thanks! It looks like Figma (a clear success) also took the "just give me a canvas" route:

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

Re: We Have to Start Over: From Atom to Zed

#190
post #23

Fantastic interview where you really get into the mind and mindset of the developers for how they approach development from many different angles. Highly recommended. I only have one disagreement with them. . . > the perfect name for a text editor in Zig is already taken: Zed No, it’s “Zag”. ;)

> I only have one disagreement with them. . . > > 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…

ed is the standard text editor.
Post reply on HN