101–110 of 703 posts
Earlier quoted context omitted.
You can just read the script that you're curling rather than pipe it into sh directly. It seems like it just extracts the binary from a tar.gz and puts it into ~/.local.
"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.
Earlier quoted context omitted.
My only problem with VSCode is that it's owned by Microsoft. I'm willing to put up with some extra friction if it allows me to escape their ecosystem even a little bit. My general rule is if I can get at most of what I need from the open source version of something, I use it. Even if it's less user friendly.
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/
Cool to see a new editor in the arena with a lot of resources behind it, but I'm trying to find the selling point besides "it's really quick". Great feature but there's a lot more stuff I need for a truly outstanding editor, what are the novel pieces? The bar is ridiculously for editors (vim & emacs configurability, vscode just works, jetbrains can do it all) - what will/does it bring to the table to compete?
> To install Zed on most Linux distributions, run the shell script below. This is not an acceptable way to install anything on Linux. If you want to target Linux users you can't distribute with a shell script for installation. I get that the idea is to reduce friction to installation and trying it out, but most Linux users - the ones you want filing bug reports anyway - are ones who will do due diligence and inspect…
You might want to tell the rest of the software world how unnacceptable it is, because a huge amount of software, and especially dev tooling, is installed in this exact way.
It's especially hard for young or fast moving projects, most distro packaging just isn't very compatible with this velocity.
I'm personally on NixOS , which usually makes it easy to always get the latest and greatest, but eg would I really want to add a third party apt repository for Zed, which introduces complications and also can make changes to my whole system, rather than just having zed install itself in a local user-owned directory? I don't want to end up with 15 different third party apt repositories... adding those actually provides a higher amount of trust than shell scripts that only run with user permissions.
And there are similar considerations for most other distros. Arch is probably the only other one, next to nix, where it's quite easy to stay up to date.
(zed is already an official Arch package, btw, and before that it already was in aur, and of course it is in nixpkgs already)
It's not ideal, but whenever some pattern propagates across the ecosystem, there are probably valid reasons why.
Earlier quoted context omitted.
> you can't distribute with a shell script for installation Why not? It worked for me.
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 (pi…
...
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.*
I often have trouble articulating this at work. I will steal this and use something like it when advocating for correctness as opposed to shitty short sighted solutions. Thanks
Looks like they're developing their own Apache-licensed GUI framework for this, called GPUI. I think of text handling as one of the trickier parts of building such a framework, so one specifically made to support a text editor would seem to be a pretty good foundation for a general purpose GUI toolkit. I wonder if they (or someone else) will pursue it as an alternative to Qt.
https://zed.dev/blog/videogame
Many UI libraries being built today want to be very forward-focused, so they focus on being as general as possible. This does make some sense, especially considering that, for better or worse, using a web browser engine as a UI has become increasingly popular of a decision. However, in the end this leads to almost all new "greenfield" UI projects trying to develop scalable vector UI rendering engines that need advanced and highly optimized vector rendering libraries like Skia and Pathfinder. Having everything in vector all the way through is elegant, but it's complicated.
The insight with GPUI is that it's not really necessary to be that general, the vast majority of UIs are made up of a relatively small number of different primitives that you can build on to basically do anything. So instead the vast majority of what's going on in GPUI is layers of roundrects. Text rendering is the classic approach of rendering into glyph atlases. I think this is a vastly more sustainable model for a UI library.
I don't know if GPUI is ready to be used on its own, but it does have a spiffy if brief website.
Given that Zed actually has good "UI-feel", it tells me they are focused on the right things. A lot of new greenfield UI frameworks are spending a ton of time on trying to build extremely generic vector graphics systems but the actual widgets feel bad and are missing all kinds of tweaks and nuance. Here's a good litmus test for text editors: what happens if you double click and drag? In most good UI frameworks, this should result in word selection and then expanding that selection left or right. In a lot of smaller greenfield UI libraries, something vastly less useful will happen :(
Anyone else get ~60-70% CPU usage when moving the mouse around? And no GPU usage.
Earlier quoted context omitted.
My only problem with VSCode is that it's owned by Microsoft. I'm willing to put up with some extra friction if it allows me to escape their ecosystem even a little bit. My general rule is if I can get at most of what I need from the open source version of something, I use it. Even if it's less user friendly.
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/
You can't connect to the Marketplace and some extensions outright can't be used with a custom build.
I tried zed for a few weeks because I'm generally sympathetic to the "use a native app" idea vs Electron. I generally liked it and its UX but: 1. VSCode is pretty damn fast to be honest. Very rarely is my slowdown in my work VSCode loading. Maybe I don't open very large files? Probably 5k lines of typescript at most. 2. Integration with the Typescript language server was just not as good as VSCode. I can't pin down e…
There were a bunch of decisions that felt strange, although I can imagine getting used to them eventually. For example, ctrl-click (or jump to usages) on a definition that is used in multiple places opens up a new tab with a list of the results. In most other editors I've used, it's instead opened up a popover menu where I can quickly select which really I want to jump to. Opening those results in a new tab (and having that tab remain open after navigating to a result) feels like it clutters up my tabs with no benefit over a simple popover.
Like you, I'll probably try again in a few releases' time, but right now the editor has so much friction that I'm not sure I actually save any time from the speed side of things.