Atom revival/modernization

[mauricioszabo]

As mentioned specifically on this comment: #22847 (comment), Atom is not exactly dead, but sometimes it does not work properly or there are some other issues with the editor. There are some proposals on how to solve it, and I think it breaks down to some possible steps (in not any particular order, to be hones):

1. Make it easier for people to build from scratch, and to hack right away (easier to make PRs and changes)
2. Make the "text editor" more modern, maybe even replacing it 100% by Monaco or CodeMirror
3. Make it support the VSCode API so that VSCode plugins can run on Atom
4. Update Electron / make it easier to bump electron versions

I'll make threads with each of these points, if someone wants to contribute :)

[mauricioszabo]

Replace the text editor with Monaco

One idea is to replace the editor with Monaco. There's some work from @fabianfiorotto. Remains to be seem if it's plausible, and if the Atom API can be adapted to Monaco (even if we miss things like syntax highlighting) so plug-ins can keep working without changes

[mauricioszabo]

@fabianfiorotto Something I found out: some of the Atom API uses internal state from the editor (for example, editor.buffer instead of editor.getBuffer() ) so if we want to adapt things, we need to be aware of this situation too :(

[fabianfiorotto]

It should respect the object's encapsulation. That is something that needs to be fixed on Atom.
Also, I don't think we can implement the entire "API". Editor class is freaking huge only most used method should be implemented and then add more as bugs are reported.

[mauricioszabo]

Yeah, I agree. But there's also another issue: the entire editor "API", for it to be 100% pluggable, is also huge: I'm trying to do a "proxy" implementation (one that creates a new TextEditor class and delegates all methods to the current implementation in Atom) and it's still freaking huge.

There are also packages (like bracket-matcher) that depend on these internal states, don't respect the encapsulation, etc...

[fabianfiorotto]

@mauricioszabo I published my code https://atom.io/packages/monaco
it's kind of messy but it is just to test the concept.

[fabianfiorotto]

Another thing I found implementing git is that there isn't any marker.dispose() in Monaco. So there is no way to wrap it.

[icecream17]

Here's two ideas: #22517 that relate to the codebase itself

1. (ThatXliner) Use Jest for testing
   a. There was also a pr to use github actions instead of azure pipelines.
2. Use TypeScript because of the compiler and new javascript features
   a. Although if babel was updated, that would also be a way to allow new javascript features

[mauricioszabo]

I, to be honest, don't care for typescript. I was thinking about using ClojureScript mainly because of the wonderful hot-reload (like, save a file, the editor is already updated with the latest code - way easier to develop and experiment things).

[keevan]

+1 to being able to develop things WITHOUT needing to do a window:reload
(Hot reloading is definitely a nice bonus)

[mauricioszabo]

By the way, one problem with ClojureScript is that the language does not like circular dependencies. Unfortunately, Atom have a bunch of these :(

[AnthonyNeo]

The packages definately need some attention, but it's a BIG ask to adapt the VSCode API. I'm not even sure it would be possible.

[mauricioszabo]

One other idea is to replace packages that are made specifically for Atom to other versions, maybe ones that don't depend on native modules at all.

For now, I see:

• @atom/fuzzy-native
• @atom/nsfw
• @atom/source-map-support
• @atom/watcher
• fuzzaldrin
• fs-admin
• fs-plus
• nslog
• pathwatcher
• scandal
• keyboard-layout
• apm
• season
• superstring

As dependencies. If we want to maintain Atom (with a smaller team that Atom originally had) and allow for Electron upgrades, etc, keeping all these dependencies will be a nightmare - it would be best to replace them with libs that the community keeps, or even better - if we can, replace them with WASM versions (so no "native lib" will be needed)

[shaneknysh]

I would love Atom to strip down to the absolute bare bones and become the notepad replacement rather than retool and attempt to become the VSCode replacement.

VSCode is a great programming tool but it is not a great plain text editor. Its like using a sledge hammer to drive in a finishing nail.

If I needed to write code - I reached for VSCode, but if i needed to make notes, manage todo.txt, write content, etc I reached for Atom. I haven't reached for Atom like this in a long while, the editor keeps getting more and more features while the small number of packages I relied on slowly broke.

I recently rebuilt my work PC and installed VSCodium and created 2 workspaces - 1 for markdown and 1 for web dev ( I may add a third for ssh connection/development). So far opening the workspace for my specific task is working but a little awkward. And there is some bleed over of extensions enabled when I don't need them. I would jump all over an atom build that was targeted towards text editing focusing on the use cases beyond the reach of notepad but not at the level of VSCode, WebStorm, etc.

[keevan]

Thanks for relaying your experience. I was curious which packages in Atom were you using that slowly broke? Hearing that made me sad. 😢 , but I depending on the situation you might be able to salvage the package's functionality if it only broke due to a recent package update.

apm install <package_name>@<package_version> to install a specific version. (Source)

Your other issues / concerns are similar to what I've encountered as well, and I've been working on a package to see if it will solve that problem (still WIP).