Discussion about Atom-community

[aminya]

👋 Welcome!

I am pleased to say that we now have a parallel fork of Atom that plans to include atom-ide packages in our atom-community builds by default, speed up the development process, etc. We will release the builds under the atom-community name. The core contributions will eventually become available in the upstream atom builds.
https://github.com/atom-ide-community/atom

You can check the projects to see more details about the plan: https://github.com/atom-ide-community/atom/projects

Join our discord server here: https://discord.gg/deuBJaqVud

This discussion is the follow up of what was already discussed in

• this issue: Discussion about Atom-community #4
• this issue: https://github.com/atom-ide-community/atom-ide-community.github.io/issues/3
• and our discord server: https://discord.gg/deuBJaqVud

[aminya]

Have long-lived branches here, which we merge upstream master into continually

• I think we should have one master branch that we merge everything into that.
• We should make separate pull requests from the master of this repository to upstream master for each change we make
• They can merge our pull requests sequentially. So ideally, each pull request we make to upstream will only contain one feature/improvement.
• I also added the pull bot to make pull requests from upstream. We should use rebase as long as there are no conflicts. I will need to approve the pull requests it makes, so a human review will happen.
• This way we can both stay in sync.

I will tag the upstream developers so they know about our plan @lkashef @darangi @smashwilson.

[DeeDeeG]

@lkashef @darangi if you have thoughts about this fork, I am also all ears/interested to know what you would have to say.

---

@aminya I think we can't necessarily expect our pull requests to be gotten to in any particular order. Also, our commit history will have strange stuff like merging their upstream master into our master -- if we open a PR from our master, they would have to accept all of the strange merge commits and essentially this is like them becoming a downstream of us. I don't think it makes much sense unless they "squash and merge" our PRs, which is something I haven't seen them doing.

I think we should give upstream just the commits containing the changes for the PR we are proposing, directly on top of their master branch, and then accept whatever their commit history is into ours by merging (their master --> out upstream_master --> merge into our master).

Open to discussing it more. Just that the underlying git software needs to be capable of it, whatever it is.

[aminya]

@lkashef @darangi if you have thoughts about this fork, I am also all ears/interested to know what you would have to say.

@aminya I think we can't necessarily expect our pull requests to be gotten to in any particular order. Also, our commit history will have strange stuff like merging their upstream master into our master -- if we open a PR from our master, they would have to accept all of the strange merge commits and essentially this is like them becoming a downstream of us. I don't think it makes much sense unless they "squash and merge" our PRs, which is something I haven't seen them doing.

Draft pull requests cannot be merged until marked as ready. We should only mark the first one in the sequence, and that is the only one they can merge.

I think we should give upstream just the commits containing the changes for the PR we are proposing, directly on top of their master branch, and then accept whatever their commit history is into ours by merging (their master --> out upstream_master --> merge into our master).

Open to discussing it more. Just that the underlying git software needs to be capable of it, whatever it is.

The commit history is not important here. The point is to improve the code itself. Although rebasing will keep the history clean to a good extent. If we diverged too much, we will just merge upstream as commits.
Pull bot brings us upstream regularly which we merge, and also in the worst-case scenario, the compare button is always there: https://github.com/atom-ide-community/atom/compare

[aminya]

I'd like to point out something: we can't post more than one PR from our master branch at the same time -- All PRs from the same branch will point to the same commit (the one at the tip).

We will make separate branches. That's how we want to release! See the upstream branches, each one is a version:
https://github.com/atom/atom/branches/all. We will do the same. One pull request for each release.

[aminya]

I have updated many of the atom/npm packages that are in the atom organization or widely used by atom packages. We should also integrate those into our atom builds. I should register them under a new name for doing that.

A list of those that I remember now:
atom/packages:

• status-bar Decaffeinate atom/status-bar#236
• line ending selector Line ending selector update atom/atom#20542
• tree-view (tests remaining): Rollup atom/tree-view#1341
• less-cache: Less 3 atom/less-cache#17

npm:

• underscore-plus: Modernize (decaffeinate + rollup) atom/underscore-plus#21
• atom-select-list TypeScript atom/atom-select-list#28
• fs-plus (WIP) Decaffeinate atom/fs-plus#48
• space-pen: https://github.com/aminya/space-pen
• atom-space-pen-views using space-pen-plus atom/atom-space-pen-views#23
• mixto: Add support for JavaScript classes (ES6) atom/mixto#2
• etch (WIP): Adding Types atom/etch#82
• electron-link: Update the dependencies and CI to match Atom's versions atom/electron-link#26 Lazy require fix atom/electron-link#27

We also need to integrate atom-ide-community and other useful packages as I mentioned in https://github.com/atom-ide-community/atom/projects/4

[aminya]

@bennypowers Hi Benny! Why don't you use atom-typescirpt? Actually you can use atom-ide-javascript which sets up typescript as well.

We will look into those PRs, but the packages I mentioned are up to date and under active development.

[jeff-hykin]

Treat our work as a series of patches or changes that we continually rebase on upstream master
Have long-lived branches here, which we merge upstream master into continually

Was there ever a resolution to the merging strategy? @DeeDeeG

Speaking from (moderate) experience, I think continually merging in upstream master is the way to go.

[DeeDeeG]

@jeff-hykin This was discussed here: #28, and we came to essentially the same conclusion.

Practically speaking: We have been using plain merges (the kind that generates a merge commit -- no rebase or squash) to bring in updates from upstream master branch lately, and plan to continue to do so.

[aminya]

Speaking from (moderate) experience, I think continually merging in upstream master is the way to go.

Exactly. That's what we found. Rebasing (any force-push) makes a lot of problems for our pull requests.

[jeff-hykin]

@jeff-hykin This was discussed here: #28, and we came to essentially the same conclusion.

Great to hear! Sorry I looked for the conclusion but didn't see one.

[jeff-hykin]

Also just as an FYI, I'm here because I'm interested parallel work: creating a refresh of Atom. I've used VS Code for many years and contributed a decent bit (I maintain their C++ syntax), but after exploring the VS Codebase and seeing how unmaintainable it is, I've switched back to Atom for good.

A standard IDE interface would be part of the refresh, which is why I'm mentioning this here. I'm curious if you guys are opposed or interested in a re-branded Atom (not an extension, but also not a hard fork).

The main goal is standardization; How can an IDE debugger use a terminal, when it doesn't know which terminal(s) you have? How can a theme customize terminal-colors when there is no standard for a terminals (and no standard terminal)? Even beyond extension-interactions, I think the lack of standardization is killing community maintenance. Looking at terminals themselves; there's platformio (a fork), teminus (a fork of that), terminal-tab using Xterm.js (a fork of term.js used by platformio), and the most up-to-date is a fork of terminal-tab: iv-terminal. Yet platformio is the most common. The community can't update/maintain iv-terminal if they don't even know it exists, and new coder's won't know to pick it over platformio.

However, part of the refresh is UI layout changes, different default settings & extensions, and a reduction of node-gyp dependencies.

[DeeDeeG]

That sounds beyond my skill level, personally. I am invested in making Atom's infrastructure sustainable, and updating dependencies, mostly. Even when that takes substantial care, updating uses of dependencies' APIs, substantial re-writes of sections of code, whatever it takes. I'm interested in keeping Atom modern and just "alive" and current. (Part of my calculation is that upstream is still interested in working on features, but a lot of their work hours are caught up in basic maintenance. I want to ease the burden for maintenance tasks and free up work hours for features and other concerns.) I'm self-taught and not an expert, but I can figure out a fair amount of Atom if I get an evening or two to stare at the code and do research, and read the PRs and past discussion that led to the current code and designs.

That said, part of the work we're doing is to pave the bumps in the road for forks of Atom. A project is healthier when downstream contributors can fork you, run the infrastructure that supports you, and make changes/propose them back to upstream when needed.

If upstream hasn't merged one of our PRs yet aiming to improve the forking experience, we will have the answers for any of the problems we've solved. (For example, we have CI 100% working, if you count remaining open PRs to fix Release Branches and Nightly). Ideally we will have those manual interventions needed written as documentation, and where possible stuff should "just work" at upstream and forks with no intervention, and we will do that if and where there's a readily apparent way to do so. But also, we're so far quite happy to answer the volume of questions we've been getting, which has been low in these early days.

None of what we're doing is proprietary, from the code to the ethos. There is plenty of room for more than one, and even many players in this space. Where there is something of interest to this fork and another fork, I know I'd be interested in that, and out of encouraging the health of the ecosystem, I'd like to put effort into working together. Whether that needs to happen in this repo or another one is IMO kind of down to something more specific than you've mentioned, IMO. Decide feature by feature.

I might lean against changing the UI, personally, or adding a lot of features to core, but I think I'm the more conservative about changes among the two of us who have been mainly working on this fork at the moment. And if it can be justified and discussed to come to a consensus, I can be swayed on things. But more specifics would be good before I would want to say yea or nay.

tl;dr I'm open to anything, but there's only so far my expertise will go and so far I can think to go with features and drastic changes before I get a bit skeptical or concerned about it. But I would encourage and support efforts to fork upstream, us, or use code from both upstream and us as a base for new features. We still aim to coordinate with upstream where possible, so I think the right person to ask about a given piece of tech can be looped in to the discussion. If not, hopefully the state we're leaving the ecosystem in is vital enough, and pleasant enough to work on top of, so forking is a fruitful endeavor despite us/without having to ask us anything :P. And yeah, this fork is designed to be able to have more people working on it and so far we have (extremely informally) been using a consensus-like model. And I defer somewhat to the last person who made the feature "work," or who knows it best at the moment, even moreso if they can explain their work and its value to others working in the fork/upstream/wherever-it-is-to-be-merged.

P.S. this is my opinion off the top of my head and I do not speak for anybody else by posting this. (Also, I am away for the week. So if I don't seem to be doing much around here... I'm away for the week! That's why.)

[aminya]

Also just as an FYI, I'm here because I'm interested parallel work: creating a refresh of Atom. I've used VS Code for many years and contributed a decent bit (I maintain their C++ syntax), but after exploring the VS Codebase and seeing how unmaintainable it is, I've switched back to Atom for good.

A standard IDE interface would be part of the refresh, which is why I'm mentioning this here. I'm curious if you guys are opposed or interested in a re-branded Atom (not an extension, but also not a hard fork).

The main goal is standardization; How can an IDE debugger use a terminal, when it doesn't know which terminal(s) you have? How can a theme customize terminal-colors when there is no standard for a terminals (and no standard terminal)? Even beyond extension-interactions, I think the lack of standardization is killing community maintenance. Looking at terminals themselves; there's platformio (a fork), teminus (a fork of that), terminal-tab using Xterm.js (a fork of term.js used by platformio), and the most up-to-date is a fork of terminal-tab: iv-terminal. Yet platformio is the most common. The community can't update/maintain iv-terminal if they don't even know it exists, and new coder's won't know to pick it over platformio.

However, part of the refresh is UI layout changes, different default settings & extensions, and a reduction of node-gyp dependencies.

@jeff-hykin Thanks for the interest.

VsCode is taking a closed approach in their codebase and extensions. They don't allow any extension to add any UI which keeps the extensions mostly simple. However, Atom gives the real power of improving the environment to the developers. That's why I think Atom is the superior choice for me.

Check these issues and see the lack of freedom in VsCode. People are seeking simple toolbar, float windows, etc. The things that can be added "very simply" in Atom.
microsoft/vscode#41309
microsoft/vscode#10121
https://github.com/microsoft/vscode/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Alayout

We think we can easily cover the VsCode API by adding wrapper functions, and we have started this in our atom-vscode package. Since VsCode does not allow adding any UI, having such a compatibility layer will allow any extension to work without adjusting much of the code!
https://github.com/atom-ide-community/atom-vscode

There are plans for standardization. It is undergoing in atom-ide-language-client and atom-ide-base.

I have started with improving the old packages. We can achieve so much just by optimizing and modernizing the JavaScript packages. See this list for example #4 (comment).

In addition, for the hot parts of the code that we cannot optimize in JavaScript, I plan to use AssemblyScript or Rust to convert them to WASM. We can compile many existing C++/Rust packages to Wasm for our needs. atom-archives/X-ray also includes some useful code. The good part about wasm (compared to native modules) is that the code works most of the time without changing it.

Regarding the modernization of the native modules, replacing @atom/nsfw with nsfw 2 is in my todo lists (#76 ). I think there are so many modern native modules that we can use right away. We just need to update the API a bit. sack.vfs is one the native-modules I like to integrate. It allows using JSOX (to replace CSON).

Multi-threading is my other big thing. Many things can run in parallel without affecting the main GUI thread. #74

By the way, regarding Terminals, X-terminal is the Atom's best terminal right now and I plan to include it in our Atom builds.

I might lean against changing the UI, personally, or adding a lot of features to core,

@DeeDeeG I do not think we need to follow what upstream wants, and I am not concerned with that much. They have taken a stable approach which prevents most of the improvements. For sure, the changes made here can be useful for the upstream repository, but the fact that they have not merged our PRs so far shows their different view.

With that being said, we will continue to make pull requests for upstream. However, at some point, if they do not catch up, the changes will be so much that making isolated pull requests will become very hard or impossible.

[jeff-hykin]

Oh I 200% agree with you @aminya about VS Code, I hate their philosophy and I have never stared the repo because of it. I don't want to VS Code-ify Atom, I just want to take Atom to the next level. So when I say standards I only mean universally agreed on communication (ex: preventing overlapping keybindings), but still fully maintaining the proactively-hackable nature of Atom.

We think we can cover the VS Code API

That would be a game changer! I hadn't even considered that. Sadly, I don't think it will be easy though, the API is quite large. Some actions use tools that don't exist in Atom by default. But it is doable and a large number of them can be done quite easily.

That's great to hear about Javascript package updates, I've been planning on doing the same.

I 100% agree with the move to WASM. I was actually the first person to get the Tree Sitter running in VS Code with WASM 😅. I want to compile the fuzzy-native to wasm and bundle all the language packs into one repo.

Looks like we're going to be working together haha

By the way, regarding Terminals, X-Terminal

Thanks! I missed that one.

[jeff-hykin]

Also good to hear from you @DeeDeeG Being skeptical is fair, and being open is more than enough for me. Atoms UI style is great IMO and I want to keep that, but some things (like URI handling having an entire tab for 1 setting) don't make much sense at all.

I have a rough outline so I will go over it in more detail later. There's certainly more questionable parts to the outline, and I certainly would be happy for feedback on it.

And just for reference, I'm considering calling the refresh "Neodymium" or "Neo" for short. Both because Neodymium is an element (a 'flavor' of Atom), and Neo being a form of 'new'.

[DeeDeeG]

Just for context, the atom-ide-community org here on GitHub has been around for a while, significantly longer than this forked copy of Atom core. There are a lot of passionate and talented people who have been active with that. @aminya and I recently decided to fork atom core and requested/were invited to have access to do so under this org.

I hope that's stating it accurately. Point being, this whole thing is bigger than atom-ide-community/atom. I am active at the forked Atom core (this repo) but others have been digging deeper into the code and writing/re-writing extensions, IDE-related features, etc. for some time now, so they know more about all that than I do.

Whatever happens, I personally want to see that Atom core is in good health and active.

[aminya]

I just found a way to convert an issue to a discussion. 😄 So, we can continue talking here instead of moving to a new thread.

[lockieluke]

i seriously have high hopes on this project, keep up the good work guys

[lockieluke]

github has retired atom its time to get this started

[lockieluke]

I don't think TypeScript is the answer. Atom is already 90% Javascript, I'm hoping it keeps this way. So, IMHO, we could remove CoffeeScript, modernize some JS code to be easier to hack, separate things that make sense, join things that also make sense and now live in different repos, and that would already help a lot.

Adding another different language to the code may be too much, honestly...

better nothing, it's difficult to work with CoffeeScript

[meadowsys]

I would love to see it migrated to typescript myself. However, best to first get rid of all coffeescript, and typescript would be something more of a wish list item to be done later down the line. I do see babel thrown around a lot, not entirely sure how it is used in atom (I get the impression it is JIT transpiling code to be run?), but I will note here that babel does support transpiling typescript.

[aminya]

In the long run, we should try to migrate to TypeScript. I did a lot of work to make the types for each separate src file. So, we should at least install @types/atom and add a tsconfig.json file to get started.
https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/atom/src

I also update Babel to 7 in #67. Its config file is babel-preset-atomic, which already supports transpiling TypeScript. That means, transpilation happens on the fly as part of Atom's transpilation engine.

Since Babel 7 supports things like optional chaining ?, we can get very readable code out of decaffeinate:
https://decaffeinate-project.org/
example

[mauricioszabo]

Yeah, I completely disagree on TypeScript. But again, I fundamentally disagree with the whole "static vs dynamic" types, so no surprises here.

I, for one, would prefer the solve the current feedback cycle of hacking on Atom's core; but priorities differ for different people.

[sbrl]

Sounds like some amazing changes coming down the line! Looking forward to the first release :D

I'd perhaps suggest here that the debate on Typescript vs Javascript is put down as a "later" thing, since either way there seems to be a bunch of stuff that needs doing as a prerequisite task.