Live data from Hacker News

Zed on Linux Is Here

zed.dev

561–570 of 703 posts

Re: Zed on Linux Is Here

#562
post #300

Earlier quoted context omitted.

> Of course, zed has always felt like an osx first project with linux/windows being second class citizen. Unless I'm missing something, it doesn't even run on Windows... https://zed.dev/docs/#download-zed

You can build it yourself for Windows iirc

True, but the fact that they don't build and package it means I'd be a beta tester, at best. Most likely alpha tester.

Re: Zed on Linux Is Here

#563
post #352

The only reason why I dropped (and Im not alone) using Zed is the arcaic UI sublime-like search functionality. Please revisit that part because I really want to use ZED.

This is actually the first time I’ve seen someone unhappy with search - can you tell me a bit more what you are looking for? There is lots of room for improvement of course, but I’d love to hear what your desired search experience is.

This example can illustrate the point easier, one scrolls through lines, while having a preview on the right: https://miro.medium.com/v2/resize:fit:1400/1*1cwOdRcJ_Ix9RR4...

Re: Zed on Linux Is Here

#564
post #482

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?

> besides "it's really quick" I can see the appeal, as the demo looks really smooth; then again, I'm a terrible slow developer, so personally I find saving few ms here and there irrelevant to my daily workflow

i definitely agree, and Id LOVE a snappy editor, but I struggle to trade thay off with everything else other editors provide

Re: Zed on Linux Is Here

#565
post #5

Now they just need a flatpak…

We have a flatpak build! It's not on flathub yet though :) https://github.com/zed-industries/zed/blob/main/docs/src/dev...

Great! I am way more likely to try out software when it's available as a regular package that I already know how to manage.

Re: Zed on Linux Is Here

#566

Earlier quoted context omitted.

Sublime's focused/minimalist UI is nice. VS Code sometimes feels like it tries to do too much. My ideal editor would probably be something like a variation on Sublime Text that's modeled more closely after TextMate while keeping the bits that make Sublime better (like the command palette).

Sublime is the better Textmate. What would you do to subl to make it more like mate? I used textmate for years and years before switching to ST and it was a drop-in replacement.

Not that this was necessarily better in terms of capabilities, but TextMate had a very pleasing Unix-style extension model where there was no mandated language and extension commands used scripts/executables written in any language. There was even a nice graphical editor for fine-tuning exactly what input they would be given and how their output would be acted upon.

TextMate was very much "Mac OS X UI sensibilities combined with Unix power", whereas ST pretty much has its own self-contained philosophy that's then brought to Mac/Windows/Linux in a slick way.

Re: Zed on Linux Is Here

#567
post #88

Man, I'm conflicted. I mean, Zed works pretty damn well. So far my biggest annoyance with Zed though is that it's constantly trying to download language servers and other tools and run them. And sure, that's handy, but 1. I don't really want it, I'd much rather only use distribution-provided tools. 2. It doesn't work at all on NixOS, so it's just wasting its time and our bandwidth constantly downloading and trying to…

If any zed devs are in this thread: I highly highly suggest that any auto-download or upload (be it telemetry, plugins being downloaded, and worse: plugins uploading god knows what) is opt-in or at the very least easy to opt-out . The eagerness to download stuff without my consent at the moment precludes me from using this e.g. in a job that touches a sensitive proprietary codebase.

This is a non-starter for many larger companies. With supply chain attacks being what they are currently, this would directly prompt Security teams to block this outright.

Re: Zed on Linux Is Here

#568
post #389

Earlier quoted context omitted.

Have to agree on the VCS story. I’d switched over to using Zed more or less permanently, but I eventually moved back because I kept having to open Intellij to resolve conflicts.

As I don't use either, can't you just open the file and look for >>>> and <<<< and resolve them in whatever editor you need ? or do these editors do something else that helps with merge conflicts ?

A lot of IDEs these days offer a three-way-merge interface that massively improves on the conflict resolution process. Different tools have different interfaces, but generally you have three panes visible: one showing the diff original->A, one showing the diff original->B, and third showing the current state of the merged file, without conflicts. You can typically add chunks from either of the two diffs, or free edit your resolution based on a combination of the different options.

I find resolving conflicts through this sort of system tends to be a lot more intuitive than trying to mess around with conflict markers - it also helps with protecting against mistakes like forgetting conflicts or wanting to undo changes. If you're not used to it, I really recommend finding a good three-way merge plugin for your editor/IDE of choice.

Re: Zed on Linux Is Here

#569

I'm never using this editor unless it can install itself and work completely offline, without going for downloads and making web requests , it is crucial, especially after totally not related xz fiasco and the white house praise for rust.

> especially after ... the white house praise for rust What's the threat model here, that Rust is a trojan language from the feds?

I recommend reading this paper, as it gives some understanding of the things that are possible with an infected toolchain: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

Some modern compiled languages such as Zig and Go can be officially bootstrapped from a C toolchain. And a C toolchain can be bootstrapped with Guix using only a 357-byte blob. This gives some good confidence that you can bootstrap a malware free toolchain using auditable source artifacts.

Rust however, does not have an official way to be bootstrapped from a C compiler, which means developers must use a previous version of the compiler to build a new version. In this situation, you can never be sure a malware was not injected in a previous version of the compiler (see the Ken Thompson paper for an example). There's no way to know because you are using a unauditable blob to create another blob.

This is why someone created mrustc, a Rust compiler implemented in pure C++, so that Rust can be bootstrapped from a C toolchain (see also: https://users.rust-lang.org/t/understanding-how-the-rust-com...).

The mrustc solution is not good because there are essentially 2 implementations of the same compiler that have to be kept in sync. It would be much better if Rust used a solution like Zig's: https://ziglang.org/news/goodbye-cpp/

Re: Zed on Linux Is Here

#570

Earlier quoted context omitted.

Sorry, I should have been more specific and said FOSS. VSCode is still encumbered by the weight of a mega corp. It's like saying Chrome is open source. Sure it is, but it still exists to serve the corporation that owns it.

It's MIT licensed. So it's more FOSS than FOSS

It's not F/OSS at all. It's proprietary software with some open-source components, which together comprise VSCodium.
Post reply on HN