That's great news. I actually like their zed font [1] which is custom-built from Iosevka. [2]. [1] https://github.com/zed-industries/zed-fonts [2] https://github.com/be5invis/Iosevka
Where I can download those fonts from without installing Zed?
Zed, a collaborative code editor, is now open source
501–510 of 642 posts
Re: Zed, a collaborative code editor, is now open source
#502Earlier quoted context omitted.
> (no one does this! it’s got a heap-size from the 80s!) Shouldn't the devs do this? We're in 2024, embedded systems have more RAM, IO, etc than anything from the 80s.
The, uh, GNU folks, are a little conservative in some ways that surprise the mainstream developers. But there are always flags for it. Well, except stupid-ass dynamic-linking of `glibc`.
> are a little conservative in some ways that surprise the mainstream developers
Conservative is one thing, but having the default be something that's detrimental to 99.999% of your users in 99.95% of situations feels like bad defaults/design, not being conservative. My worthless 2 eurocents :-)
Re: Zed, a collaborative code editor, is now open source
#503Earlier quoted context omitted.
I’m really picky about my tools in general and latency in particular, and I give Zed a spin from time to time, it’s sweet. Clean, minimal design aesthetic, tree-sitter, tight code, it’s a nice bit of work and I dig it a lot. But emacs 29 with the right flags and a tuned GC (no one does this! it’s got a heap-size from the 80s!) is just as snappy and has more amazing packages than VSCode. There’s a market for people wh…
> But emacs 29 with the right flags and a tuned GC (no one does this! Please share how.
Both @darthrupert and @natyrys on the thread have said most of what I know. It's a little machine dependent to get the true sweet spot, but raising it from the like, megabyte (slight hyperbole) or whatever that it defaults to is the 80/20.
Re: Zed, a collaborative code editor, is now open source
#504Earlier quoted context omitted.
Much of that is latency added by the design of modern compositors (see "the compositor is evil"). The good-ish news is that as the frame rate goes up, compositor latency goes down, as it's usually an integer multiple of frame refresh time. I'm also interested in influencing the design of next gen systems to reduce compositor latency, but I'm apparently pretty much alone in that interest.
Xilem seems to be heavily focused on using WebGPU. One doubt I have is: is it possible to have tight integration with the system's compositor using such an abstraction? For example, on Windows looking at the documentation for the DirectComposition, it seems that things are designed precisely to work optimally with DirectX. So my impression is that one would really need to use the native graphics APIs on each system t…
It's a good question and one we're looking into. We're not planning tight integration with the system compositor on our 2024 roadmap, partly because it's extremely platform dependent, and presents compatibility challenges (you basically don't get it on X). But even for damage regions, which is on the roadmap, we're going to need to extend wgpu.
Re: Zed, a collaborative code editor, is now open source
#505Launched it on Macbook Pro Mid 2015. I can't say that I noticed any speed difference in comparison to the VSCode.
Re: Zed, a collaborative code editor, is now open source
#506It's interesting that the #2 selling point on the landing page (the Copilot integration) relies purely on Microsoft's goodwill. There is no official API for Copilot but instead a (non-standard) LSP implementation embedded into the proprietary Copilot Neovim plugin. Zed seems to trust under the hood that a release of the plug-in exists on Github, pulls the minified-js language server from there and integrates with tha…
> the Copilot integration) relies purely on Microsoft's goodwill
Given that the founders and several employees are former GitHub employees, I have to imagine they know how to do this integration in a proper & officially allowed way.
Re: Zed, a collaborative code editor, is now open source
#507Earlier quoted context omitted.
Since you are here I'll hijack the thread :) What about remote support ala vscode-server over SSH.
Please not ala vscode-server over SSH. Do it proper like emacs tramp so it will connect to any platforms/architectures.
What's the architectural difference between the two?
Re: Zed, a collaborative code editor, is now open source
#508[flagged]
Re: Zed, a collaborative code editor, is now open source
#509Earlier quoted context omitted.
Give straight.el (among others) a shot. Combined with use-package you don’t have to worry about that these days.
Ah ok. Last time I used straight it still blocked input on straight-update-all, didn’t realize they changed this.
There's a little tweaking sometimes.
Most examples you'll see of `straight.el`/`use-package` configurations will have some version of: `(use-package something-cool :ensure t :config ...`. The `:ensure t` clause will cause it to fall back on `package-install` in the event it's not bolted into your local Cargo-style-own-the-world-and-dont-break repo mirror. Disks are big, it's like the right default now.
But if you've got a package that's mis-specified in terms of where on `github` or wherever that `striaght` is supposed to find it, you can find it tapping `elpa.org` on the shoulder at a time when the UI thread is also doing blocking network IO.
The `Messages` and/or `straight` buffers will have warnings about this, so it's fixable to find the offending package and it'll stay fixed, but in fairness what you're describing is possible.
Re: Zed, a collaborative code editor, is now open source
#510Interesting to see how they are gonna approach integrating plugins/extensions system, because this is likely gonna be one of the major factors affecting adoption and ecosystem growth.
Helix devs, for instance, lean towards a Scheme-like implementation. [1]
[1]: https://github.com/helix-editor/helix/discussions/3806#discu...