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: https://github.com/appelgriebsch/atom-ide-datatip.
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
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: https://atom.io/packages/atom-ide-datatip
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).
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: https://atom.io/packages/atom-ide-busy-signal
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
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…
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.
busy-signalis a recently maintained package that is a dependency for many others, and features could be smoothly integrated there. https://github.com/steelbrain/busy-signal/pull/63
atom-ide-code-actions- Appears to be wholly subsidiary to
atom-ide-diagnosticsand should be integrated with it.
formatterused to be a core dependency but was replaced by
formatterpackage should probably be unarchived and updated with the new features.
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.
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-debuggeruses it. It could be rolled into
atom-ide-diagnosticsas a service or kept as its own dependency.
atom-ide-datatip- Split off with a UI update. https://github.com/appelgriebsch/atom-ide-datatip
atom-ide-debugger- Gets its data from
atom-ide-definitions- Gets its data from
atom-ide-diagnostics- The successor to
linter, important for being compatible with both the v2
linterAPI and the language server protocol via
atom-ide-diagnostics-ui- Should be combined with
atom-ide-diagnosticsso 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.
atom-ide-find-references- Gets its data from
atom-ide-global- This module existed to maintain common keymaps and certain common behavior across the different components. It’s no longer useful.
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-viewperforms 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-languageclientis dev-maintained, so increasing the scope of
symbols-viewwould be keeping it up with the times as opposed to feature creeping).
atom-ide-refactor- Exposes a service for refactor providers, could probably be spun off into its own thing.
atom-ide-signature-help- Gets its data from
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.
hyperclick- The original
hyperclickwas 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
hyperclickrepo so that we can preserve the name and compatibility if possible.
- Work needs to be done to make the module into a stand-alone thing that will stand the test of time.
- 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.
- The module isn’t meaningful in a world where
atom-ide-ui gets disembundled.
- 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?
its standalone. and it only implements the api given by the atom-languageclient (nuclide has an extended variant for internal usage; so it’s not a one-to-one replacement for that). but it works without atom-ide-ui package installed!
atom-languageclient already does the work of translating the diagnostic messages from language servers into the
linter v2 API for any package that supports that service. This means that you don’t need to know about language servers for diagnostics/linter as they are already hooking into the existing ecosystem.
atom-ide-diagnostics was simply acting as a consumer of this service in the exact same manner that
atom-ide-diagnostics-ui I’d argue that this should remain separate if the community is going to keep it around.
linter actually has its UI completely isolated as well in
linter-ui-default. All interactions between the two are done via services. This means that any other package that so desires can hook into that service as well and get a unified view on all currently known linter messages. This is used for example in atom-minimap-linter to be able to get the exact same information that any other
linter UI does. Using this setup entirely different UI’s can be built, such as linter-ui-plus.
Note: I’m not sure where you got the idea that Facebook had done anything with the Linter API, possibly from looking at some v1 provider that hadn’t been updated several years ago when v2 was released?
What do I need to do to start using the new package instead of the atom-ide-ui one? I’m hoping I can disable datatips from atom-ide-ui and use the standalone package.