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.
We Have to Start Over: From Atom to Zed
181–190 of 243 posts
Re: We Have to Start Over: From Atom to Zed
#182I 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....
Re: We Have to Start Over: From Atom to Zed
#183Their 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…
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
#184Their 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…
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
#185Their 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 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
#186Earlier 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.
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
#187Earlier 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…
Re: We Have to Start Over: From Atom to Zed
#188Earlier 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.
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
#189Earlier 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…
"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
#190Fantastic 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…