If this happens with Zed 0.129 or later, could you open an issue? We had a problem at one point where there was a delay in macOS verifying our app’s code signature because we weren’t attaching the code signature correctly.
> It has created a culture in which checking in enormous generates files is common.
You're not required to do that, and never have been. We're going to move the grammars away from checking the generated `parser.c` in, but early in the project, it was a pretty pragmatic solution, given that many consumers of the grammars weren't using a particular package registry like NPM or crates.io.
> It abdicates common and important features in popular languages like significant whitespace to error-prone external scanners.
External scanners are the right tool for this. Nobody has proposed a better solution for this that actually works, and I don't think there is one, because every programming language with significant implements it differently.
> The GLR algorithm sometimes fails inexplicably and is essentially impossible to debug (not sure if the bugs are in the algorithm or the implementation)
It sounds like you personally have had trouble with debugging a grammar you've tried to develop, but it solves a problem.
> It bizarrely uses rust and node.
Tree-sitter isn't very coupled to node. We just shell out to a JS engine because we use JS (the most popular programming language, period) as a grammar DSL, rather than inventing our own language. Node is the most common one.
> the generated c files are insanely (probably a consequence of the GLR algorithm)
No, it's not because of GLR. A lot of the reason for the C code size is that we want to generate nice, readable, multi-line C expressions to represent data structures like parse tables, rather than encoding it in some cryptic, unreadable way. Also, incremental parsing requires that a bit more data be present in the parse table than would be required for a batch-only parser. What really matters is the code size of the final binaries. The generated `.so` or `.wasm` files for a Python parser are 503k, and 465k, respectively. The wasm gzips down to 69k. I would love to make it smaller, but there are pretty good reasons why it occupies the size that it does, and it's currently pretty manageable.
> It also uses (unless it's been updated in the last six months) a terrible algorithm for unicode lexing.
I'm not sure what you're referring to here. UTF8 and UTF16 are decoded into code points using standard routines from `libicu`.
I don't understand how you can say the code size has nothing to do with GLR and the explain that it is due to the formatting of the parse tables. The point is that table driven parsers are almost always huge compared to their recursive descent based alternatives (and, yes, recursive descent does have problems). The code size of the final binary is not all that matters because the huge c programs cause insanely slow compile times that make development incredibly painful. So that statement only holds if the time of grammar writers doesn't matter.
I was too vague on unicode. I meant unicode character class matching. Last I checked, tree-sitter seemed to use a binary search on the code point to validate whether or not a character was in a unicode character class like \p{Ll} rather than a table lookup. This lead to a noticeable constant slowdown of like 3x at runtime if I recall correctly for the grammar I was working on compared to an ascii set like [a-z].
Did you open an issue for the segfault you got, on the Tree-sitter repo or the repo for the particular parser you were using?
It's not really accurate to say that Tree-sitter segfaults constantly. The Tree-sitter CI performs randomized fuzz testing based on a bunch of popular grammars, randomly mutating entries from their test corpus. If you have a reproduction case for the segfault, it'd be useful to report.
Since you mention NPM, it sounds like you may be talking about a segfault that's specific to the Tree-sitter Node.js bindings, but it's hard to be sure.
No, I did not open an issue. When I checked the issues for tree-sitter-javascript, I saw the most recent issue was one reporting the same thing (segfault) from some weeks ago, with no attention. It still has had no attention, so I don't think reporting would have done much.
Anyways, since you're here, I dug a bit more into this to make a more useful report. Starting with v0.20.2, the following file will cause a segfault when parsed using tree-sitter-javascript: https://github.com/tursodatabase/libsql/blob/main/libsql-sql... . It worked fine in v0.20.1, and it's still broken with the latest v0.20.4. Based on the diff here: https://github.com/tree-sitter/tree-sitter-javascript/compar..., I don't on the surface see a way to dig deeper into this than trying to read through a 170,000 line (!!!) diff to parser.c.
And looking at that diff raises another complaint: the names of parser nodes must be considered part of the public API, as they are exposed in descendantsOfType, .type, etc., but they are 100% not documented anywhere, and are liable to change without notice in patch version bumps. This makes developing against it a massive pain, as any version increase is liable to break any code expecting a particular nomenclature.
I don't mean to dunk on your project, I'm sure it solves some problems very well. But it is remarkably difficult to confidently depend on in a production environment.
EDIT: I just don’t trust promises for things to be open source. Notch said Minecraft would be open source, and look where that went. A promise let’s you skip out on releasing the code if it turns out to be a convenient or profitable options.
I completely agree and think it should be legally enforced but I also recognize that consensus has not yet developed in business culture, so I recognize I'm not going to have as much persuasive firepower as I'd like to make this argument. VSC is also opt-out and doesn't ask you.
Thanks for pointing this out.
Our whole terms-of-service is just standard boilerplate provided by our lawyers, but this part doesn't really apply to Zed. Obviously, there's no "content moderation" for project code that you collaborate on with Zed.
We'll look into adjusting this to make it clearer that we don't do anything remotely concerning or invasive.
Also: the thing looks really compelling. I would really like to try it out. But I can't use it. Not with irrevocable consent. If I make something that turns into billions of dollars...well, there are people that would exploit these terms. It's an absolute no-go.
> Obviously, there's no "content moderation" for project code that you collaborate on with Zed.
Not only is it non-obvious, it's explicitly stated that you can do what you want with any content that you are exposed to, which is all of it, because you've granted yourself the ability to surveil everything. And not only what the "Application" or "Tool" sees, but by any means available to you by the "Service."
I'm glad to hear you'll be addressing this. To an unsophisticated reader like myself, it sounds like you guys are planning to examine the code I edit in Zed, maybe even keep copies of it. Aside from the general creepiness, many programmers are bound by contract to protect their employer's codebase.
> License: Zed will do so for Zed’s benefit, not yours.
Never in my life have I seen such a boisterous "fuck you" in a legal document. Who are your lawyers, and what on Earth (or off Earth for that matter) are they smoking? In what alternate reality is this a "boilerplate" EULA?
I do check that it fits and that he's delivering what I've asked him to deliver. And if I don't know what a good custom suit should be, then I should not buy one, or I should seek assistance in its purchase.
I don't own a custom suit but I assume I'd be in the room when they were taking my measurements and I my eyes would be open, so I could see the tape. And then I'd try it own before agreeing to taking it home. I'm not sure which side of the argument your analogy is on.
I do a lot of back and forth with our lawyers on terms. I read all of it and give feedback.
This sounds like a jab at people that are raising this as a concern. Maybe I'm looking at it wrong.
What I've seen is that lawyers or anyone drafting agreements generally likes to overstate their position, or put another way take as much as they can get away with. It's rarely done with explicit malicious intent, more with negotiation in mind. Ask for more than you want and then go back and forth to arrive at something that works.
It's just sort of an added bonus if people agree with the terms.
So anyway, it's incumbent on those negotiating and agreeing to contracts to read what they're signing up for and discuss to arrive at an actual agreement that serves everybody. What happened in the discussion above is actually a great example of that happening, even if it was inadvertent.
You might also want to consider only asking the user to agree to it when initiating use of the collaborative service rather than when they install the app.
Right now, this is just used for the screen-sharing feature.
> The binary is pretty big by itself
It is. One major reasons is that we're shipping a "fat binary" (x86_64 and arm64 build in a single file). We did this to simplify the download process for users, but now that the app is getting bigger, we should probably start shipping two separate DMGs, to reduce the download time. That would cut the binary size in half.
Our plan is for the core editor to be free and open-source.
We'll charge money for our backend service that powers collaboration in Zed. We have ambitious plans to improve the way that people work together on code. So far, on that front, we've been focused on real-time collaboration, but we have a lot of ideas for how we can improve asynchronous collaboration as well, by having discussions take place directly in the code editor.
A lot of us have been following along with Zed hoping that the clarity and action on the open sourcing front would be done or at least in the process of happening before the public beta but from what was shared in the podcast, it doesn't sound like any progress has been actually made on this front.
Especially, since Zed does have a very clear distinction/dividing line of "completely functional local editor" == permissive open source vs. "all of the real-time & async collaboration features" == proprietary that is easy to explain.
Frankly, I would happily pay for great, fully supported, high-quality real-time collaboration for my teams.
Anyway, as you can see, not having any useful progress on this front instantly shuts down lots of people and there's many of us who won't even consider doing more than checking it out until this is done.
Yeah, the plan is to open-source the editor itself before we release 1.0. We will probably keep some part of the collaboration system closed-source, so that we can build our business around that feature set.
We have some work to do to decide exactly what will be closed source and separate that out from the rest of the application code.
The first thing I always do when I go into any new editor is set up the "Select All Instances of highlighted word". So like how there is cmd-d for the next occurrence, I also like having a shortcut to select _all_ occurrences. Would love for this to be added.
More generally, this looks really awesome and also really enjoyed your team's blog post detailing the GPUI implementation (even though large parts of it went over my head)
Yes, these are an absolute must :) Came here looking specifically if this was possible. The cool thing is that is currently the only thing I've been missing after playing for a couple hours! I've tried vscode yearly to see if it had become tolerable, but alas. This is the first time I've tried something that might steal me away from Sublime.
I haven't played enough with it to give good feedback, I've edited my comment to be more fair.
* Seems to me that a lot of the keyboard shortcuts are chords or require hitting an arrow key, sometimes even both. Example: VS Code's default mapping for vertical split is cmd+backslash, but Zed requires cmd+k -> arrow key.
* The project panel (file tree) doesn't support hjkl for navigation. The website says Vim mode is still under construction, but in my mind that applies to actual buffer editing, not general UI interactions. My impression is that today most editors, hell even a lot of websites, support hjkl or similar for navigation in cases where it doesn't conflict with anything else.
My perspective is that "keyboard-focused" implies "ergonomic shortcuts and UI navigation without leaving the home row". If I'm gonna move my hand from the home row to reach the arrow keys, I might as well just reach for the mouse and get 10x the possible interactions. Anecdotally, I tested myself just now and I'm pretty sure it takes me more time to "find my footing" when I move my fingers to the arrow keys than it does to just grab a mouse and click something.
This might be wrong expectations on my end, but my hope is that Zed can bring the powerful navigation of Doom Emacs/Spacemacs minus the bugginess and terrible performance of Emacs. Whenever the devs talked about Zed, I just imagined VSpaceCode without the jank that comes when you override 90% of an editor's default bindings. What I'm seeing from an hour of usage doesn't feel that much more powerful than VS Code in terms of keyboard navigation (kudos on the snappy performance though, it really is night and day). I'm aware this is an early beta, I just hope you folks agree and are going to push more in this direction.
Yeah, they don't seem to have any serious Emacs person in their team. So, like so many people who try and build editors in the last few decades, they seem to miss some fundamental things (while focusing on other worthy things like the core rope+crdt enabling fast local & collaborative editing).
They talk about things like having a plug-in type system in the future based on e.g. WASM but, as you're pointing out, their fundamental perspective is built around the simplistic notion of a control panel with fixed functionality that's primarily accessed via a bizarre set of keymaps. On this front, might as well stick with JetBrains.
Having some kind of leader keybinding would be great along with something like "which-key" for discoverability.
Checking out Spacemacs or Doom Emacs would give a clear idea of what I'm talking about.
If unfamiliar with emacs, VSpaceCode is a VSCode extension that ports Spacemacs-style keybindings pretty successfully, although the UI is suboptimal due to limitations of VSCode extensions.
I couldn't find a way to show/hide various panels. e.g. line numbers, the bars with the (<- ->) arrows etc.
Would be great to allow toggling visibility of each of these pieces via an action to maximize screen real estate. Really annoying in VSCode that they force you to go into settings for some of the visibility toggles. Of course, didn't spend very long investigating.
Also after selecting VSCode keybindings, CMD+\ does not split the editor as it does in VSCode. Seems like a bug
