I'm enjoying the explosion in editor software going on right now. Even if most of them don't survive or gain a large audience, I'm sure the cross-pollination of ideas will lead to some great improvements in those that do.
I think it'll be a long time before something replaces emacs given that emacs is extremely niche and most text editors don't seem to be after the vim/emacs market
emacs already does everything-- no tool is ever going to do more than emacs (before you say it, i know this isn't literally true.)
so when i already have a tool that does everything (actually multiple tools), what might i want in a different tool? to extend the metaphor of a tool: i'd want a tool that feels better in my hand, or a tool that does a specific job very well, or a tool that can fit better into tight and awkward spaces, or a tool that works by a different principle, or just a more beautiful specimen of the same tool that does everything. or maybe i'd want a different tool for one of the many reasons i'm sure i haven't thought of.
just some stray thoughts, nothing original, but it makes me realize that i'm always looking for tools that work on a different principle to the ones i've got, and that's never occurred to me before now.
A new tool can certainly do things better. Emacs has many quirks, that are partly because of its age, and partly because it needs to remain compatible with its extensive ecosystem. A new editor that, for example, prioritizes performance, while not sacrificing extensibility, and maybe does it in a more mainstream language, could always start small and eventually gain traction.
The team behind Pulsar is a community that came about naturally after the announcement of Atom's Sunset and decided that they needed to do something about it to keep their favorite editor alive.
Your comment is almost irrelevant to the original post. It's not in README which is what most people look at. I never look at "about us" unless I am really interested in what's going on. And this is just very strange when the entire foundation of the code is based on another project but they don't mention it in a visible way.
Honestly we thought we had covered it enough without flying too close to any trademark misuse claims from GitHub but it appears not so we are going to look at seeing what we can do to make it more obvious.
Edit - Have another look, we edited the readme to make it more obvious. The readme is due a massive branding overhaul but hopefully this addresses the immediate concern.
This is the community attempt to continue / revive atom right? Interesting that atom doesn't really get mentioned in the docs anymore- hopefully a sign that it's finding its feet and direction as a project in its own right.
I don't know, seems a bit weird not to mention Atom at all. At least "This project was forked from Atom" or whatever.
Besides it being nice, it's also a requirement of the Atom license, that the copyright and license notices are preserved. Seems the only mention of their heritage is "Original work copyright (c) 2011-2022 GitHub Inc." in the LICENSE file but again, no mention of Atom.
Shouldn't matter "who" prefers the credit, the project is a fork from Atom and should be mentioned as such. Right now, going to the website or the repository makes it seem like a brand new editor, which it is clearly not, but not so clear based on what information they willingly provide you with.
So IMO, they are pretty much fulfilling the requirements of the MIT license it looks like.
Depends on whether the copyright notice and license is also presented somewhere (such as under the About menu) in distributed copies of the modified program as well. But I have no interest in installing Pulsar just to see if they do that or not.
"The team behind Pulsar is a community that came about naturally after the announcement of Atom's Sunset and decided that they needed to do something about it to keep their favorite editor alive. This is a true community-led project to modernize, update and improve the original Atom project into a contemporary, hackable and fully open editor."
I don't think that's enough. It's not mentioned in github repository README. I actually thought this is a brand new editor until someone pointed out this is a fork of Atom. I have browsed at least hundreds of open source repositories and this stands out as very strange.
We have it in a bunch of places around the GH org (literally the first two lines on the org readme), docs and blog posts. In no way do we want to hide it but we also made a decision that we didn't want any trademark disputes from GitHub's lawyers from misusing their Atom trademark anywhere. We very much acknowledge the Atom legacy (including hosting the full original Atom flight manual before the website went down alongside the rebranded docs).
Edit - We have updated the main repo readme with the info to hopefully address some of these concerns
I haven’t read the docs lately but when I was hacking on Atom years ago, the plugin model was TOO freeform, and with plugins all running on the main thread, it was easy for a plugin to kill performance and slow down the editor. The vscode model strikes a better tradeoff between extensibility and performance. Extensions have less power but my editing experience is never ruined by a rogue extension.
One of the last things I remember about Atom was that by the time they’d figured out all the stuff they needed to fix, VSCode had come in and stolen all the eyeballs, so to speak. So they have a good roadmap, they just need to do the implementation.
Atom was unbelievably slow. How will the performance be improved? Visual Studio Code somehow managed to surpass the awful Electron performance just enough to make it usable, and it's pretty unbelievable this project will come close to that.
Why couldn't they take the optimizations from vs code and integrate them? VS code is open source, it's only their proprietary extensions like remote dev that aren't open.
I remember Atom in its later releases had significantly improved performance to the point I never noticed problems.
Looking at both projects vscode uses typescript heavily while this project mainly uses coffeescript. So that might be a hindrance. So I guess that might be part of it.
We are actually looking to "decaffeinate" back to vanilla JavaScript. Unfortunately there is rather a lot of it still even after the Atom team's attempt to remove some of it.
For those who want fast and lightweight without falling all the way back to emacs/vim, I’m really digging Lite-XL.
Lua for customization, thin accelerated rendering layer in SDL2+freetype, zero nonsense. Binary packages are like 2MB. The code itself is clean and readable.
The plugin collection is still young and won’t have everything you’d find in the Electron-family of editors, but that’s also a plus when it comes to it staying lightweight and streamlined like some might want in these tools.
I reluctantly switched from Sublime Text to VSCode about four years ago, but now it's simply unimaginable to go back. It's heavier, but fast enough to have four or five different workspaces open, in very large projects. The language support, intellisense, and plug-in ecosystem are miles ahead.
Sublime performance can't be beat, but I'm seeing the end of the road for active plugin development. It's getting harder and harder to adopt new tools without farting around with configs all day.
At least, this was my experience trying to get Deno development to feel "right". It feels like vim and VSCode are the platforms that get plugin support nowadays, and the rest are a hack.
native frontend (Rust/druid), LSP support, tree sitter syntax highlighting, command pallette, vim key bindings, modal editing, plugins in any language with WASI target, remote development, community led, open source plugin registry, it checks a lot if boxes. https://lapce.dev
That was very enjoyable. I think the tldr is that they use custom scrolling via translate3d, limit any computation on the file to just the visible lines, and they split the text into lines with regex to leverage native loops instead of trying to split the next manually via JS. Mono-spaced font probably makes this problem a lot easier as measuring text is pretty trivial.
Electron is rarely the cause of performance problems itself. It's more that JavaScript makes it really easy to write slow memory bloated code. But it's possible to write really fast and efficient apps in JS.
There are a few fundamental limitations with web/js. No shared memory concurrency, no reasonable storage layer, no integer types. Those can make some things hard to make performant but most apps I see are not limited by this.
Most apps are slow due to a few common mistakes.
- React/Anglular diff based rendering cycle.
- Garbage collection due to careless allocation of objects in tight loops.
- Poor client side data models, resulting in blocking on the network for simple things.
- Careless use of the bad storage abstractions (bleh indexeddb) which requires copying data for every operation leading to GC pressure and wasted CPU.
- V8 is a moving target in what it chooses to optimize well and what it fails to optimize.
tl;dr fast electron apps are possible but the platform makes it easy to write slow apps by default.
It's interesting to see this coming out of the atom community. I've been really impressed with Zed (https://zed.dev/) which is from the original atom folks and focused on speed and collaboration. Rapid improvements since initial launch.
Care to share a binary or some other project that is actually beyond a closed alpha? Otherwise not a lot of point in sharing it as an alternative, it's not available to the public.
Edit: signed up for the waiting list and received "Zed currently only targets macOS" so sounds like they only target ~10% of the actual market. Interesting strategy.
If they're building a native macOS UI, how is it ever possible it'll be worthwhile to port that into native Windows UI or "native" Linux UI? If you wanna go cross-platform, you usually consider that from the start, not once you're 50% done, as you're gonna have to redo a lot of work you could have gotten "for free".
Rendering a platform native GUI and what you render it on are two different things. In the case of Zed, its a combination of
- metal is quite easy to work with
- apple has clear design guidelines and nice toolkits
The Xi editor team quickly found out how much of a mess "native" gui's were on windows. Zed will hopefully add support for vulkan and linux/windows later, but it makes sense to start off on macOS
Metal is not a platform native GUI, it is Apple's graphics API. The native UI on the platform is Cocoa (which calls Metal for some things, but isn't being used here).
If it's still Mac only, I don't have any real use for it, can only use editors that works across Windows, Linux and macOS, otherwise there is no real point in me trying them out :/ But I thank you for the offer, might reach out in the future if I hear it's available on more platforms.
It's kind of maddening that both VSCode's remote dev extension AND Zed (which aims to be better than VSCode) AND JetBrains's remote dev AND repl.it AND <some other stuff> are all closed source.
What's the state of art open source editor/extension/protocol/whatever that enables two or more persons work on the same open files in real time? Something better than the ssh access which forces one person to work at time, then save, then the other person reloads.
Emacs with crdt.el, or neovim with instant.nvim are both open source and free implementations of collaborative editing with crdt's. Its going to be a bit of a struggle getting your coworkers to use emacs/neovim though
a combination of "there is no standard", "selling collaboration to businesses is way to make money", and that how editors handle files changes from editor to editor, so its a bit hard to sync
- zed.dev has crdt's/collaborative editing as one of its selling points, but they're planning to offer this collaboration as part a paid service to businesses.
- vscode has its own sycronous collaboration plugin, but its proprietary and they declined to release the source code or offer to port it to other editors
- you could probably build a plugin that bridges emacs and neovim, but it might be a bit slow as you'd have to "translate" the buffer from one editor to the other
There is an inherent difficulty in implementing it, getting asycronous collaborative editing right is hard. Combine that with how few people on emacs/neovim actually use collaborative editing (emacs still has a mailing list and does code via patches) and the chance for a "universal" version is practically nil.
Getting Teletype working properly again is one of our tangible goals for Pulsar - which is of course entirely open source. The question is of hosting so hopefully we can make it really easy to host your own instance or go peer to peer rather than just relying on a server.
Speaking with some of the devs, yes (asterisk). From what I understand, they are working out what they can open source while also retaining the ability to make money from the editor (mostly from the collaboration features)
I’ve been using Zed for a couple of months. It has replaced eMacs and VSCode for writing Rust. The integration is so well done, it’s like a constant conversation with the compiler. I’ve got ten invites by the way.
One thing I worry about a little is the business model. They want to target teams and charge for the cooperative features. But as a single user I’d love a way to just buy a lifetime license and feel that I can expect at least five years of use. I don’t like when software I love treats me like a casual fling.
Does Pulsar support terminals over SSH? The reason I (only) use emacs and vi, is that they're available *everywhere* and work in literally every environment.
Folks who know Pulsar and Zed internals: which one of them is more likely to gain support for Atom packages? I find Hydrogen[1] invaluable as a data science scratchpad since it supports python/r/julia/etc under a common interface via jupyter, and have been unable to construct a comparable workflow in vscode or any other editor [using scripts as opposed to notebooks, which i find far too bloated].
Pulsar already supports (nearly) all the Atom packages and has a brand new backend reverse engineered from the closed source Atom.io packages backend.
I think it is unlikely you will get any Atom support in Zed any time soon.
Some packages had to be removed due to incompatible licenses
I'm done with these JS/Electron editors. They are Ok (for the most part), but using Neovim in 2023 is such a huge step above everything else if you have the inclination to learn it. I'm integrating my workflow into Nixos and it's pretty incredible what is possible if you constrain your development to the terminal.
90 comments
[ 3.5 ms ] story [ 54.5 ms ] threademacs already does everything-- no tool is ever going to do more than emacs (before you say it, i know this isn't literally true.)
so when i already have a tool that does everything (actually multiple tools), what might i want in a different tool? to extend the metaphor of a tool: i'd want a tool that feels better in my hand, or a tool that does a specific job very well, or a tool that can fit better into tight and awkward spaces, or a tool that works by a different principle, or just a more beautiful specimen of the same tool that does everything. or maybe i'd want a different tool for one of the many reasons i'm sure i haven't thought of.
just some stray thoughts, nothing original, but it makes me realize that i'm always looking for tools that work on a different principle to the ones i've got, and that's never occurred to me before now.
https://emacs-ng.github.io/emacs-ng/js/getting-started/
https://emacs-ng.github.io/emacs-ng/js/getting-started/
Maybe this project will help emacs move into the browser someday.
It's funny the README doesn't mention it.
The team behind Pulsar is a community that came about naturally after the announcement of Atom's Sunset and decided that they needed to do something about it to keep their favorite editor alive.
Edit - Have another look, we edited the readme to make it more obvious. The readme is due a massive branding overhaul but hopefully this addresses the immediate concern.
Besides it being nice, it's also a requirement of the Atom license, that the copyright and license notices are preserved. Seems the only mention of their heritage is "Original work copyright (c) 2011-2022 GitHub Inc." in the LICENSE file but again, no mention of Atom.
> Copyright (c) 2011-2022 GitHub Inc.
IANAL but the terms of the MIT license says:
> […]
> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
> […]
And they did preserve it all.
https://github.com/pulsar-edit/pulsar/blob/master/LICENSE.md
So IMO, they are pretty much fulfilling the requirements of the MIT license it looks like.
Depends on whether the copyright notice and license is also presented somewhere (such as under the About menu) in distributed copies of the modified program as well. But I have no interest in installing Pulsar just to see if they do that or not.
"The team behind Pulsar is a community that came about naturally after the announcement of Atom's Sunset and decided that they needed to do something about it to keep their favorite editor alive. This is a true community-led project to modernize, update and improve the original Atom project into a contemporary, hackable and fully open editor."
Edit - We have updated the main repo readme with the info to hopefully address some of these concerns
I remember Atom in its later releases had significantly improved performance to the point I never noticed problems.
Lua for customization, thin accelerated rendering layer in SDL2+freetype, zero nonsense. Binary packages are like 2MB. The code itself is clean and readable.
The plugin collection is still young and won’t have everything you’d find in the Electron-family of editors, but that’s also a plus when it comes to it staying lightweight and streamlined like some might want in these tools.
Sublime so soo superior, it's not even fair. Haven't tried vscode but I understand it's a resource hog.
At least, this was my experience trying to get Deno development to feel "right". It feels like vim and VSCode are the platforms that get plugin support nowadays, and the rest are a hack.
There are a few fundamental limitations with web/js. No shared memory concurrency, no reasonable storage layer, no integer types. Those can make some things hard to make performant but most apps I see are not limited by this.
Most apps are slow due to a few common mistakes.
- React/Anglular diff based rendering cycle.
- Garbage collection due to careless allocation of objects in tight loops.
- Poor client side data models, resulting in blocking on the network for simple things.
- Careless use of the bad storage abstractions (bleh indexeddb) which requires copying data for every operation leading to GC pressure and wasted CPU.
- V8 is a moving target in what it chooses to optimize well and what it fails to optimize.
tl;dr fast electron apps are possible but the platform makes it easy to write slow apps by default.
Edit: signed up for the waiting list and received "Zed currently only targets macOS" so sounds like they only target ~10% of the actual market. Interesting strategy.
It’s likely quicker to develop for a single OS and then build the additional UIs with a more feature-complete app.
The Xi editor team quickly found out how much of a mess "native" gui's were on windows. Zed will hopefully add support for vulkan and linux/windows later, but it makes sense to start off on macOS
What's the state of art open source editor/extension/protocol/whatever that enables two or more persons work on the same open files in real time? Something better than the ssh access which forces one person to work at time, then save, then the other person reloads.
Can this made to work with a GUI editor? Like neovide or emacs but in X11/wayland not tty
Is there some inherent difficulty is this, or is it just "there is no standard" -> "nobody implements one"?
- zed.dev has crdt's/collaborative editing as one of its selling points, but they're planning to offer this collaboration as part a paid service to businesses. - vscode has its own sycronous collaboration plugin, but its proprietary and they declined to release the source code or offer to port it to other editors - you could probably build a plugin that bridges emacs and neovim, but it might be a bit slow as you'd have to "translate" the buffer from one editor to the other
There is an inherent difficulty in implementing it, getting asycronous collaborative editing right is hard. Combine that with how few people on emacs/neovim actually use collaborative editing (emacs still has a mailing list and does code via patches) and the chance for a "universal" version is practically nil.
One thing I worry about a little is the business model. They want to target teams and charge for the cooperative features. But as a single user I’d love a way to just buy a lifetime license and feel that I can expect at least five years of use. I don’t like when software I love treats me like a casual fling.
Thanks in advance! Looks cool
No, thanks.
This one on the other hand, looks very promising
https://lapce.dev/
Save your comment for when you believe the opposite (that something for sure will become mainstream), that's when it gets interesting.
We don't need a new editor. Just make a spacemacs layer or doom plug-in.
[1] https://learn.microsoft.com/en-us/visualstudio/ide/how-to-tr...
[1]: https://github.com/nteract/hydrogen
Some packages had to be removed due to incompatible licenses