Impact of Nuclide extension being removed?


Ok, I think I got the idea. Thanks especially to @DamnedScholar for all the details (including the Etch component library I wasn’t aware of).

From my point of view an initial scope will be (in the order of sequence):

  1. Data Tips for types and functions
  2. Outline View
  3. Errors and Warnings (still investigating if the default linter/linter-ui can be used)
  4. Code Formatting
  5. Intentions and Hyperclick style navigation in text editor (reusing the intentions and hyperclick packages if possible)

Later: debugger integration (should use the debug adapter protocol and make reuse of existing vscode debuggers, check the node-debugger and python-debugger Module from Nuclide as an example)

Code will be on GitHub with an MIT license. Just checked availability of AtomIDE and/or Atom-IDE as GH organization name, but it’s already occupied :(. So will start with my own personal GH account with the option to move it later…


Post the GH link up here when possible, would like to follow the development on it.


My question still is, do we want to create/use a github organization or should these packages be scattered on different users?

I still like the idea of using the It already contains some repos for certain aspects like formatter (which was a former atom package but has been archived in favour of atom-ide-ui, what a coincidence).


Looks like the Atom folks already provide a Typescript compatible Typings file for the types and interfaces used in the Atom-IDE…


Just to let you know: I started with the data tip implementation today. Provider registration already done (ok was the easiest part, but anyway ;))


Some progress with console.log statements \o/


Will be the last check-in before x-mas, but already made some progress…

Initial DataTip View rendering via Etch component… Git repository here:

Code is a lot cleaner than the original Facebook one as I aligned the general concept of keeping track of position and editor buffers with the code used in autocomplete-plus.

Still some way to go… rendering is still pretty basic, and I also expect a couple of bugs :wink:


Very very cool! Awesome to see the progress / updates. Much appreciated! Really appreciate you doing this on your own time and hope that it is something that isn’t too terribly challenging.


Updated styling incl. rendering of Markdown content (if available):

Initial version published:


I have already started working on the “busy signal” part. It’s pretty much functional but there is already a package called busy-signal. It’s automatically installed when you install the linter package.
So I’m not sure if creating yet another package is a good idea. Maybe I should enhance this package.
What do you think?


Good question. I was investigating the linter services for the errors/warnings functionality of Atom-IDE as well, but looks like the API has been changed in a way that it is not compatible to the existing linter services. So you would have to figure out if that’s also the case for the busy-signal package / service and have to get in touch with the original maintainer to ask for the possibility to update it accordingly (and send him/her a pull request later).


It’s worth tagging @steelbrain in this in case he has thoughts.


As an alternative you could write a wrapper that provides the functionality of the atom-ide busy-signal by calling the original busy-signal package (eventually loosing some extended functionality).

Just tried this, but haven’t tested extensively yet:


Interesting approach!
Although I would prefer to extend busy-signal (I’m already working on it!) because it is already installed by a lot of people, so it would spread easily and therefore replace this part of atom-ide-ui super fast :slight_smile:
If @steelbrain does not like this idea I would create a new package (preferably with the name you already took)


Let me know your progress. Not very satisfied with the current solution as it has some serious limitations. Would be glad to have a joined effort to replace and maintain the atom-ide-ui package functionality…


busy-signal pull request:


I went through the whole list and made notes for myself about what has been or needs to be done, and what purpose each package has served. The ones that just display data from atom-languageclient will be the easiest to rescue, and are also arguably the most important, so that’s convenient. Let me know if you think that I’ve missed or misunderstood something.

  • :thinking: atom-ide-busy-signal - busy-signal is a recently maintained package that is a dependency for many others, and features could be smoothly integrated there.
  • :thinking: atom-ide-code-actions - Appears to be wholly subsidiary to atom-ide-diagnostics and should be integrated with it.
  • :thinking: atom-ide-code-format - formatter used to be a core dependency but was replaced by atom-ide-ui. The formatter package should probably be unarchived and updated with the new features.
  • :weary: atom-ide-code-highlight - Probably redundant with tree-sitter. I can’t find where it does anything distinctive or is used by any of the other modules.
  • :thinking: atom-ide-console - I’ve never used this. It seems to provide value in the form of a console service that can be consumed, and atom-ide-debugger uses it. It could be rolled into atom-ide-diagnostics as a service or kept as its own dependency.
  • :star_struck: atom-ide-datatip - Split off with a UI update.
  • :+1: atom-ide-debugger - Gets its data from atom-languageclient.
  • :+1: atom-ide-definitions - Gets its data from atom-languageclient.
  • :thinking: atom-ide-diagnostics - The successor to linter, important for being compatible with both the v2 linter API and the language server protocol via atom-languageclient and derivatives.
  • :thinking: atom-ide-diagnostics-ui - Should be combined with atom-ide-diagnostics so that users don’t have to download two packages. The one package can provide a default UI and a consumable service that correlates all of the error messages in JSON for other packages to display however they like.
  • :+1: atom-ide-find-references - Gets its data from atom-languageclient.
  • :weary: atom-ide-global - This module existed to maintain common keymaps and certain common behavior across the different components. It’s no longer useful.
  • :thinking: atom-ide-outline-view - To my knowledge this is superior to the other symbol view/outline packages out there. It could easily be a core package, and in fact the core symbols-view performs an older version of this task and might be able to take a renovation so that it can work with Ctags or language server package (atom-languageclient is dev-maintained, so increasing the scope of symbols-view would be keeping it up with the times as opposed to feature creeping).
  • :thinking: atom-ide-refactor - Exposes a service for refactor providers, could probably be spun off into its own thing.
  • :+1: atom-ide-signature-help - Gets its data from atom-languageclient.
  • :thinking: atom-ide-terminal - Should discuss to see if it has relevance compared to other terminal packages when it doesn’t come as part of a bundle.
  • :dizzy_face: hyperclick - The original hyperclick was deprecated in favor of the bundled version and is owned by the Facebook archive user. We should see if we can get in touch with someone who can transfer ownership of the old hyperclick repo so that we can preserve the name and compatibility if possible.

:thinking: - Work needs to be done to make the module into a stand-alone thing that will stand the test of time.

:+1: - The module relies on a dev-backed service and thus its logic can be rebuilt externally without a significant amount of new work being done and maintenance probably being limited to keeping up with changes to Atom’s API.

:weary: - The module isn’t meaningful in a world where atom-ide-ui gets disembundled.

:dizzy_face: - The best generic name for the module is owned by an archive user account, so it may take time to reach someone with permissions and interest in transferring the repo. If it takes too long, making an entirely new package might be necessary to avoid people losing out on features, but losing the original name would be unfortunate.


FYI, this specifies all the features a proper language client should support


Hey, just saw that @steelbrain gave you access to the busy-signal repo on GitHub and therefore I assume your pull request will be introduced shortly. So I removed my busy-signal wrapper project / package in favour of your implementation.

Still trying to figure out how to organise this best as the list of packages to take over or replace is huge (see post from @DamnedScholar on this thread). Would be great to have a GH organisation that bundles all the different packages imho.


Released a minor update to the datatip package with a couple of bugfixes and UI improvements.


Very cool. Does the datatip package work standalone or does it need some other packages installed first?