Sunsetting Atom (opens in new tab)

Please don't forget about accessibility. Getting this right from day 1 will make your life a lot easier in the long run. If I remember correctly, I was never able to use Atom with a screen reader. Hearing custom UI already makes me nervous and I'm pretty sure I won't be able to use Zed with a screen reader either.

Blind developers exist. Please don't forget about us. It's one of the few areas where we can actually make a meaningful difference together with our peers on an equal playing field.

I started using atom pre-1.0, a long, long time ago. I immediately jumped to vscode when I realised it existed.

The reason is a bit weird; it's the find-in-files/project (c-s-F/Ctrl+Shift+F) sidebar search/replace feature. Compared to the Atom (and from what I can see in the youtube talk, zed has the same "problem") which opens c-s-F results in the main window, vscode opens them in the sidebar and doesn't clutter the main view with it.

The reason this is powerful to me is that I code mostly in domain-specific, esoteric, private languages that have no API documentation, no stdlib or docs, and no online resources to learn from. So the only way to learn is by example, or talk to someone who knows. Learning by example is usually much faster than talking.

So what I do is any new project is just a subfolder in a workspace that contains all known code in the language and the way I find out how to do something is c-s-F.

When the results cover the main view, or even parts of it (which is also possible with atom), it's just way too intrusive. The sidebar file list is useless to me at this point - where the result comes from is irrelevant. So why not use that space?

Also of course the fact that vscodes cross-file search was blazingly fast was an upside as well (I believe they used ripgrep for that since the start?)

Another thing I want to mention is (and you highlight the keyword search in that youtube talk around 18:54) the power of the command palette search method that is available in vscode: first-letter-matching. I don't know what the proper name of it is, but essentially "ps" matches "pub struct" for example. Obviously it matches it with a lower score than something that starts with "ps", but it's very powerful for matching in the command palette.

Thanks for listening.

* Do you already have a working editor I could test or is this merely an announcement?

* Is this an open source project or a proprietary product? Does it cost money? If yes how much?

"Real-time collaboration produces better software." At design level, ok. Programming is in most cases not a co-op operation. If it is, then you are probably creating solutions while writing code which is the best guarantee for bad solutions.

“Conversations should happen close to code.” Agree to some degree, this is a big flaw with GIT. It is also a flaw with many programming langs and tools. Even if I use collaboration features in VS and VSC many langs are simply not designed for presenting code to people not highly familiar with the specific code base. So, an editor may not solve the problem here.

“Your editor should disappear.” I mainly code in VS and what I can do in VS in 10 mins takes me a couple of hours in VSC. A tool should aim to be the default of a problem. The amount of time I have seen wasted over the years with people trying to master VIM or git from a prompt is just ridiculous.

Cool project, but this is clearly a contradiction.

wxWidgets? That offers a native UI. Wherever possible it uses the UI controls from the underlying OS/system to render the interface.

Looking at the project page it describes "a GPU-powered UI framework that met our needs."

That's not a native UI. That's a non-native UI compiled to native code, ala something like Flutter.

Best wishes for Zed's success!

I tried using VScode and Atom. Both were noticeably slow compared to sublime text. I can do silly, bad practice things like open a 50 meg log file in sublime and search for simple regex in the editor. Electron based editors stall and potentially crash.

Looking forward to its spiritual successor!

Since it's not mentioned on the website, what will be your roadmap regarding security?

I feel that all IDEs have security handled as an afterthought, VSCode made some progress but it's far from being there.

I just want to be able to use a code formatting / language extension without having to worry about it subverting my whole computer in a future update.

vscode is halfway there with containerized development, but apparently they didn't intend that to be security measure and they make it clear to only run trusted extensions. I'm guessing there are ways to access host files through the bridge.

It's obvious that we still have to trust extension authors, but an IDE with the correct security sandboxing can limit the blast zone if it gets compromised (leaking a source file vs getting a rootkit installed and ending up releasing compromised updates to production)

I hope you would have some solution to this conundrum.

I use live share all the time because it's the best thing we have for pair programming, but I often wish for a better solution. We often get disconnected for no reason, editors get out of sync, terminal sharing is near useless.

If you can produce something that doesn't feel like a hack, then I'm all in!

Features I would love to have:

- Terminal sharing should work like tmux with window size "smallest". It's the best solution I've found for having a shared terminal.

- Let us join a collaboration session from the terminal: `zed [URL]`. No annoying website that takes ages to open, or having to open the editor before joining the session.

- Let me start a server on a port and let others join that server. I can forward that port if I need to.

- Let me start a headless server on a shared dev env, and let me and others connect to collaborate

I'm asking because I like to use my laptop Acer Aspire One most because of the size and because it the incredibly good feeling keyboard. BUT the system is 32-bit and running Intel Atom which means that before VSCode moved away from 32-bit I could use it, but it would take some time to open and I wouldn't really call it writing in real time, if you know what I mean~ :D

But I love the keyboard shortcuts and the multiple cursor functionality, which is why I stuck with it for as long as I could!

Very excited about where this new collaborative editor goes!

I was dreaming of taking Vibe.d and CodeMirror and making something you could install as a daemon on any machine and code from anywhere. When Atom came out I was obsessed with it for a while, it was a whole other approach from what I was thinking of!

Did you ever do a write up on how you came to the thought of just taking a browser engine and turning it into your own sandbox and what that entailed in the earlier days? That seems like a fun story. Because of Atom we got great innovations that followed, for example Slack, Discord, VS Code, and the list goes on... and on... Heck POSTMAN! Which is probably used or has been used by every developer under the sun.

As for lightweight alternatives to Atom, there is also Lite-XL (https://lite-xl.com).

If you can make editor in Rust pluggable or scriptable with JS, Lua, C#, Python and whatever someone knows and is comfortable with you got a winner.

Pairing in VS Code over Zoom has gotten a lot better over the last year or two, to the point that I choose it for simplicity over more purpose-specific tools like VS Code Live Share (which is a bit slow/glitchy but fine, and overall "neat") or Tuple (which is great).

Would I pay money for "VSCode, but faster"? Absolutely. I'm waiting multiple seconds for keystrokes to apply sometimes and don't know why. But the extensions are what make it VS Code – if I just wanted "a faster text editor" I'd uninstall all my extensions and just keep using VS Code (it'd blaze), or switch to Sublime.

I'm excited to see more people working in this space, so I certainly wish you luck!

https://v2.onivim.io/

https://helix-editor.com/

>When you move the cursor or type a character, you should see pixels on the next refresh of your display—every time. Even sub-perceptual pauses add up over the course of a day to create unnecessary stress.

I remember there were lots of research for this in Next-Generation Atom during the Atom era, before VSCode came along. Having a UI and text responsiveness within 16ms on a 60Hz Monitor is a tall order which I believe even Sublime is incapable of.

Considering 95% if not 99% of developers on HN thinks VSCode is very fast or fast enough, I am not sure this point is worth pursuing. Personally I really want to see it happen. As I hate latency.

I tried Atom for a while, but it didn't cope well with other IDEs renaming files before overwriting them. I tried to fix it, but the response I got from the community was rather dismissive. It was quite irritating to present obviously wrong behavior and be told that it was correct.

My attempts to dive into the code myself lead me down a rabbit hole of dependencies of dependencies of dependencies, to the point that I just gave up. I switched to vscode and it has mostly stayed out of my way.

Is Zed related to Xi in history or as inspiration? Why are you confident that Zed will be able to overcome the issues that blocked Xi's advancement?

Sounds like this won't have that. It's only a successor in the sense that it's built by the same people and tackles some of its challenges.

Looking forward to innovations in UI. Cause otherwise, VIM is comparable if not better in performance than modern text editors.

Interesting. I think a major reason for VS Code's success is their usage of web-stack, which is stable, powerful and well documented, enabling easy access to higher customizations for anyone. It will be interesting to see how much a custom UI can emulate this without html&css.

Of course, they share the problem that I can’t yet use either :)

If there is vscode that was written natively. I'd be so happy. Even if there is a new branch of vscode that is 6 months behind in features but is built in native it'd be huge for me.

For me Sublime seems to hit all the same spots without the web assembly plug in feature.

I know it's not the main point of the DevXConf presentation but I really like the look of that multi-buffer feature.

As a wishlist item, can we get a native vim mode with .vim.rc support? :D

I'm holding thumbs, I have been massively excited about your elevator pitch since your original announcement. Good luck!

Is Zed web-based or not? Would it be able to be hosted in the browser like the web-based version of Github Codespace (Visual Studio Code Online)?

For Julia, Atom+Juno was excellent. It was the first time I could select+run on a proper IDE (I was coming from python+notebook). To me this was revolutionary. Then I discovered VS Code, so Atom+Juno stopped making sense. You seem to be a very competent developer, so why not just contribute to VS Code?

No migration, sunsetting, "this is legacy, let s redo it all" will ever fix anything. Fix what doesnt work.

As someone that loved Atom, and have been screwed over by Facebook's Nuclide, and now Github's Atom, I have to think about my options.

(No emacs isn't an option.)

But winding down the project is still a major event, and I think that it is appropriate to call that sunsetting. The existing project organization will go away. The team will presumably dissolve, with any people being paid to work on it going on to other things. I've seen this happen enough times to know that it is, indeed, an end of sorts. "The community" is almost never large and organized enough to keep a project like this vital. At best, they can only slow its descent into obscurity.

Instead of letting it slowly bleed out and randomly catching stragglers with outdated marketing materials lingering on the web, they give it a swift death. Atom can go into the history books as an open source project that defined the industry for a decade.

1. I need feature X

2. I find library WeLoveX

3. Is WeLoveX a good investment for my larger product?

4. Ambiguity happens here

The ambiguity happens because I have one prominent indicator: release activity. If it's changing lots, does that mean it's active and a solid foundation? Or does it mean it's actually probably not quite ready for prime time yet and hasn't found stability? On the flip, if there's very little release activity, does that mean it's dead, the developers have moved on and maybe there's something better out there? Or does it mean it just does its job really really well and doesn't need a constant stream of tweaks?

It's nice to have a general statement of disposition towards the product by the original authors.

Honestly, it kind of sucks that at this point you might as well call a project sunset if it has ASF stewardship, and that we seem to practically need the resources of a large company to keep an open source project "truly" afloat.

I vastly prefer the honesty in saying "sunset"; it helps bring more light to this situation, and will perhaps drive new approaches to funding foundations like the ASF.

For the most part, when a different organization picks up the development of the project (if one does) it's a completely new project at this point (there are exceptions, such as a backing organization continuing to back the project, but deciding that it's better supported by an independent trust, and therefore building a transition plan for that).

The best example of this is looking at any Apache supported project today. There are very few projects that were handed over to the Apache foundation that people would want to continue using in their post Apache handover date, even if they were amongst the lucky few that still have active development (OpenOffice, for example).

Sunsetting is absolutely the right term/approach to use.

Especially, if there isn't a dedicated community to maintain it.

I'll take honesty over corp-speak any day.

That said we probably only get honesty, because they want us using vscode instead.

Speaking of packages - of the six featured packages I get offered on atom.io, only one had a release in the last two years, and half have been unchanged for half a decade. Atom's already dead.

We should be counting down the days till they sunset VS Code to focus on VS Code "Pro".

The point of MS/Github announcing that they are sunsetting the project is that they are basically no longer spending time and money on the project. Projects this size have a lot of things that need attention like security fixes, legal stuff, trademarks/branding, etc. Basically, they do the right thing here by giving people some time to deal with this in whatever form they care to do that before pulling the plug.

Anyone interested in taking ownership of atom now has six months to get organized; I'm sure if somebody steps up, Github would end up doing the right thing and e.g. support them by e.g. transferring domain names, and other things they control. But somebody would need to step up for that to happen.

Apache taking ownership of a project would require that there is some community still there to work on it. They have an incubation process for this kind of thing. But there's also a thing called the attic in Apache where dead projects go after they stop being maintained.

It’s not GitHub anymore though. It’s Microsoft and Microsoft must advance the Visual Studio brand.

They use open source as a marketing buzzword, not as a philosophy, and it shows.

I think perhaps TypeScript is the only counterexample.

fork the code and start a new project with resources to take care of those and many other artifacts if you are so inclined . you have the license to do so

I don't know if it started when MS bought them, but it's when I think the decline became very apparent.

One could imagine a world where strong standards have been established which would allow you to easily deploy lean native applications across a wide variety of platforms.

Instead we ended up in this bizzare world where if you want to maintain a desktop GUI app, you either need a large team to support multiple platforms, or you need to target minified javascript of all things, and run your software on top of a large, arcane compatibility layer.

This. This always has been and always will be a critical ecosystem mistake.

The principle of one msi/exe installing everything you need on Windows, one click downloading an entire app from a store on Android or iOS is seamless and almost always error free. Or in your example with VSCode having self contained encapsulated plugins that install with one click.

Meanwhile I'm having issues installing things and resolving dependencies with pip in python, apt in linux, npm, etc. basically all the time. It's a shit system that only pretends to be elegant and it's time we fucking admit it to ourselves. Designed by elitist morons for elitist morons and everyone else is paying the price.

Depending on what you consider the "category" to be, Sublime Text (2) was well-established for years before Atom came out, with BBEdit and TextMate before it.

Not to mention Kate, Geany, and the various other "lightweight extensible code editors" that have been out there for years and years.

Mozilla actually had that in early 2000 or so; their whole UI (before Firefox existed, even) was a webby. Except it was their own weird sort of webby and not normal HTML, most of the time.

Using normal HTML would be around IE4 with their .hta files, I think. Didn't seem to have too much uptake though.

There was prior art in the form of Bespin. GitHub’s innovation was electron and turning it into a desktop app. I think it’s amusing that VSCode has recently come full-circle and introduced a browser-based version.

https://en.wikipedia.org/wiki/Mozilla_Skywriter

Wasn't brackets and atom released pretty much at the same time, both built on CEF?

I've been using VS Code for years to write JavaScript/TypeScript, Python, Go, Terraform, and CSS. My settings file is 60 lines, 42 of which are "for file extension X use autoformatter Y" configs.

When I first switched to VS Code I was frustrated trying to make it conform to random expectations I had. Eventually I learned that it's easier to embrace VS Code's defaults for 99% of things. I just want an IDE that works well (nearly) out-of-the-box and VS Code gives me that

As a pure editor I prefer VSCode. It's fast and has a great plugin ecosystem. Another great feature is that it's config is just a JSON file that I can put into git and push it to my dotfiles repo making it easy to share config on all of my machines.

However, there's just some functionality in IntelliJ that I miss in VSCode like running tests. Of course there are plugins but they are all clunky and don't give you the great UX that IntelliJ does. I want the IDE to figure out where all the tests are and give me an easy way to run a single test/file/suite/feature. IMHO this is the killer IntelliJ feature for me.

I'm kind of surprised you did a deploy from VS Code. I would have assumed there was another tool for that. I do most of my git and ssh/scp stuff from the command line because I'm never quite sure what the tool will try to do to "help me out"

I strongly recommend everyone spend their first ~5 years coding in vim or some other basic text editor (preferably through the terminal), before leaning on an IDE to solve their problems for them.

That said, VSCode is now my go-to IDE, and I haven't opened WebStorm in probably ~6 months. It's lighter weight than the IDEA suite of IDEs, and gives me ~80% of the functionality, so it's been a pretty good tradeoff.

Everyone who uses VSCode has surely used an IDE before. It just turns out they aren’t better in every way, and possibly not in the ways that matter.

VSCode plug-ins just have more eyeballs and work done on them for various ecosystems, for example. Especially for less common languages and features.

I was about to give up WebStorm the other day, but eventually got around it.

Jetbrains products are very good, but they feel a little "French" just like Macs: beautiful, but be aware that on some models the handbrake is on the same side as the door so you might end up tearing up your pants or bruising your thigh until you learn to be careful :-/

VS Code by comparison is very straightforward, but not always as sophisticated.

Personally I'd use NetBeans for backend and VS Code for frontend but because of Kotlin (which is great) I'm stuck with IntelliJ anyways.

So I end up using IDEA if I'm working with Scala and Java at a job, Emacs if using Clojure, vim for those tasks that are kind of like using sed and awk but not quite, and for everything else, like Terraform, Python, shell, SQL, there's VS Code.

Also the default editor of the IDEA family is just unbearable (but there's the vim plugin for that, I guess), while Monaco is fine.

The only area where vscode is downright embarassing is interfacing with databases. In pycharm I can have a complete view of the database I'm connected to, run queries, get warnings and errors from inline SQL, and so on. Vscode has... strings?

If the remote capabilities get better, though, I'd admittedly have no reason to stay in the vscode camp.

I used it for a year or so around 2015. It was a huge improvement over Eclipse, which is what I'd been using since this was at a Java shop, but even then I knew it was sluggish. I just assumed back then that you couldn't have IDE features without sluggishness. Now I know better

(To be clear I have no idea how VSCode's Java experience, specifically, compares with IDEA these days; I haven't written Java since 2015)

far better and faster than sftp

But I just can't. My fingers are just too used to vscode, and I can do everything I need to. I feel like vscode is better at everything, and faster, except for the IntelliSense stuff. But lately I've tried GitHub Copilot and that just compensates it sooooo much, to the point I think it is even better than IDEA at suggesting stuff.

Also, working mostly with JavaScript and Typescript makes the difference go away (for me at least) as it is damn good at it.

Being free and open source also is a big plus for using it. And I love also how easy it is to configure... just a JSON with autocompletion for any setting you want to tweak. So much easier than having to mess with a ton of tabs and sections and search for settings, etc, etc.

But, if your language is not well supported in vscode, I agree Jetbrain's IDES are great and probably the best option out there. Specially IntelliJ if you're doing Java/Kotlin etc...

I know a few people like this. More or less, they all got burned by some technical issue that made IDEA unusable for them one day, so they quickly cobbled together a bunch of extensions in VS Code just to get their work done and stayed.

Java IDEs seem to be living in their own world, but for everything else VSCode works well thanks to LSP. For example rust-analyzer works best with VSCode, and this makes VSCode the best Rust IDE.

But one is free, the other is paid...

Also, as of lately, copilot is saving me an insane amount of time especially when it comes to boilerplate and testing.

I really wish the VS Code SQL/Postgres plugins would get there, but it’s a lot of work so I get that it probably will never happen unless Microsoft puts in the effort.

What does this mean? Setting it up so you can deploy through GUI?

With gopls, vscode is MUCH faster than goland, especially on big repos, and I don’t need to watch the dreaded “Indexing…” all the time.

It misses some features, but honestly it’s so much snappier, so that wins for me.

Yep, I've tried Intellij several times over the past 5-6 years, but I've never really had an experience I liked. It's interesting that you mention SFTP and remote server deploys as a pain point for you in VS Code, because I've actually had a huge amount of frustration trying to do development over SSH in Intellij.. As of Intellij 2021 edition, I was completely unable to get ssh working from my work laptop to an EC2 instance; it could not parse my `~/.ssh/config`, and manually putting in the username, hostname, path to the private key, and even port 22 (because it literally required putting the port manually rather than defaulting to 22 unless stated otherwise), it would just say it failed to connect. The 2022 version has a "remote ssh" beta feature which also required manually putting in info that I felt like it should just be able to parse from my ssh config file, but it did connect and work for a week or two. One day it randomly started disconnecting a few seconds into loading a file continuously, which made it impossible to even scroll down into the file before it just zoomed me back up to the top. I gave up on it and just decided to stick with VS code for everything rather than try to get Intellij to work for the small amount of Java code I occasionally have to write.

Setting up ssh development with VS Code, on the other hand, was a breeze. The first plugin that came up when I searched "ssh" was Microsoft's own for ssh development, and running the command to connect to a server after installing it popped up with a list of my servers parsed from my ~/.ssh/config, which I could just select and it would connect (or prompt for a password if the ssh key required one). From there, I could easily open any project on my remote server, and VS Code even was able to detect which plugins I had installed for use with the project needed to be installed server-side rather than locally (e.g. the `rust-analyzer` plugin was installed remotely since it needed to run the daemon on the machine where the code existed). When I close my VS code window, shut down my laptop, and then the next day boot it up and open VS code, it still has the same files opened to the exact same spot (compared to Intellij's "scroll to the top of a file on connection" I mentioned before). I'm sure there are ways to get Intellij to work like I'd want, and I'm by no means a fan of Microsoft in general (I avoid Windows whenever possible and overall have a pretty negative opinion of them), but VS Code just absolutely nails the UX I want in an editor without needing that much custom configuration compared to what I've tried in the past with emacs/vim.

Last blog? 2019.

None of the releases did anything interesting. I work in Vue.js and needed that toolchain to work well, it never did with Atom.

So they're blaming the community for something they decided years ago and kept deciding every week when no resources were allocated.

Also, Zed isn't filling the void Atom left. Rust is interesting. Collaborative editing, not so much. Electron's lack of speed doesn't prevent VS code from fading into my workflow and being the most popular editor. I would still like an alternative because I don't think Microsoft should have the whole market.

Emacs can go from this: https://emacshints.files.wordpress.com/2013/09/spash1.png

to this: https://github.com/rougier/nano-emacs

https://code.visualstudio.com/docs/getstarted/themes#_custom...

You have to package it if you want to make it easy for other people to install, but if you just want to play with it, just open settings.json and start feeding it colors.

https://marketplace.visualstudio.com/items?itemName=be5invis...

For the colors at least, there are VSCode themes that will try to mimic it for you

The merge conflict resolver is so intuitive and easy to use. I have colleagues who come to me for fixing merge conflicts even though I'm pretty mediocre at git in general :p My secret is I do it in IntelliJ

I typically do this when tidying up / amending >1 commit at a time (anything I can't do easily with git rebase interactive mode), or to resolve merge conflicts.

Definitely is a software you can bet on.

VSCode's "Source Control" on the other hand is a such a big UX dumpster-fire that I cannot bring myself to even try using it any more....

Edit: Fixed typo (thanks torstenvl!).

The second big innovation was the language server protocol.This allowed any language to be supported by VS Code.

It also sounds like VS Code took a much more measured approach to extension APIs than Atom did. In Atom nearly every part of the product was an extension, which is a great approach to dogfooding extension APIs and making sure everything including the kitchen sink has an extension API, but getting that performant is tough. Whereas VS Code was very careful in the early days in what extension APIs they declared and started from a place of performance first. In many cases if only a single extension doesn't perform well in VS Code you almost don't notice because it's mostly isolated from the rest of application performance. Atom had a lot more situations, from what I heard, where one badly performing extension brought everything to a crawl.

On the topic of performance - one of the architecture decisions that VSCode nailed was the 'extension host' (https://code.visualstudio.com/api/advanced-topics/extension-...): all VSCode extensions are sandboxed in a child Node process, and can only communicate back with the main IDE process via the VSCode API. This has huge benefits for performance:

(1) extensions can never block editor startup. this was a huge problem for Atom as package loads were startup blocking and it wasn't uncommon to have multi-second startup times with lots of packages installed - especially due to the fact that JS packages typically repeat dependencies, resulting in tons of bloat. Also extension authors are rarely performance-conscious

(2) extension code can never block the core rendering thread, another huge problem in Atom - you'd often have stuttering/frame drops if extensions were doing blocking work on character or cursor changes, which was more often the case than not..

The tradeoff of course is that VSCode extensions are very limited in the set of UI customizations they can make but MS did a very good job of designing their APIs to be sufficiently extensible in this aspect (i.e. having APIs for extensions to hook into all core IDE features). Atom's extension ecosystem was much more fragmented resulting in dependency/versioning hell.

As a side note, another benefit of the extension host model is how it enables extensions to semi-magically work on remote filesystems (including inside WSL) without needing complete rewrites.

Reminds me of how Adobe killed off FreeHand (the only competitor to Illustrator at the time) by buying the parent company and then halting development.

Of course, Microsoft likely gave zero shits about Atom as a competitive threat since it was effectively dead at the time anyways, but I still think it’s interesting to see the similarities to the Adobe situation.

It seemed to me that there would always be an endless cycle of boom and bust with editors. It was a cycle with more in common with fashion than craft, and I wondered if I might end up wasting an inordinate amount of time switching editors throughout my career without any upside. So rather than switch to Atom, only to switch again a few years later, I set about with adopting Vim.

The choice seems to have been correct as there will always be a new editor (that's more or less the same as the old editor) that catches hold, but I wanted stability. Vim gives me stability, and the only other editor I'd consider would be Emacs for similar reasons.

If you are coding: Unless you are using IntelliJ (which a ton of of my colleagues do, and love) - it's a vscode world. Everyone at every company I've seen bangs away using that. It's kind of amazing how much inertia it's picked up (currently).

If you are working with text: 90% of the time if I have a couple gigabytes of text I need to do a lot of work with - it's Sublime Text. Actively Developed. A really solid text plugin architecture. The other 10% of the time I still use vim - mostly because it's in my finger DNA. Emacs is the obvious alternative which lots of smart people I know use.

I'd be interested in knowing if there are people who have used all five of these for > 100 hours that would recommend something else - (I haven't used Emacs that much - but I have well over a couple hundred hours on each of intelliJ/vscode/vim/Sublime. Probably close to 1000+ hours on the last three). (okay, small fib - close to 5,000+ hours on Sublime. I spend almost as much time in that tool as I do bash).

https://www.sublimetext.com/

    vim -> Sublime -> Emacs -> VSCode -> Emacs
                                         ^^^^^ I am here.

But realistically? A significant majority of developers use Visual Studio Code; Atom is still only being used by absolute diehards. Visual Studio Code's complete supplantation of Atom (with which it competes for resources in the same organization) is why we're having this discussion.

I think I’ll try it again after seeing the news about Atom.

[1]: https://nova.app/