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.
I am also curious.
If you already have atom-ide-ui installed there is no (additional) benefit of running the datatip package. Actually it has less features than in the original atom-ide-ui and rather targets scenarios in which you don’t want atom-ide-ui or want to replace the whole package with dedicated, selected features based on atom-languageclient… still some way to go to reach the full feature set of atom-ide-ui (see post from @DamnedScholar above)
EDIT: if you take a look at my dotFiles (https://github.com/appelgriebsch/dotFiles/blob/master/atom/apm.packages) you can already use a lot of ide- packages w/o atom-ide-ui installed, but still face the features and benefits of atom-languageclient (aka LangServer) integration.
Makes sense. It would have been nice to be able to partially disable atom-ide-ui as the replacements get developed but I understand that’s not really feasible/possible. I’ll play with it more over the weekend
It’s actually feasible from your end if you don’t mind living a little dangerously. The modules in
atom-ide-ui are all distinct, most operate independently, and in some cases it would be possible to just delete some of the code to prevent Atom from loading it. Since Facebook has abandoned the project, I don’t imagine it will be getting many updates, so you’re safe to mess around inside the package folder. And since you can always re-download the package, you have a reset button in case you really screw things up.
You’re right! I disabled the atom-id-ui using the ‘datatip’ service and it worked. The problem for me is I use the ‘atom-typescript’ package and the content it sends to the datatip service is a react component. I might create a PR to conform to the API the ide-* use.
Ohhhh, now I got the comment in the typings definition saying the DataTip declaration omits the React one… . Sorry I’ve only tested it with langserver so far, so if you can give me more info or make a PR that would be very appreciated…
I can confirm that the diagnostic feat of atom-ide is working with the latest linter/linter-ui combo. Not sure what happened, but Atom suddenly shows errors and warnings in my code (actually limited to the open file(s) and not the whole workspace, but I can remember there is an issue for that on the linter repo already)… // cc @steelbrain
Thanks for reporting @appelgriebsch
So linter has three types of linters, there are “file” scoped linters, that only lint files that are opened and their linting results go away once you close them (imagine ESLint), then there’s “project” scoped linters that lint the entire project (imagine Flowtype), finally we have the “Indie” linters that set set results for any file and are file-save or user-is-typing independent, they tell linter their results whenever, this is used by external watcher programs that lint files.
Linter supports and works with all three of them, so if you’re experiencing file-specific issues then you should contact the maintainer of the linter provider. If you’re experiencing this with LSP packages, then they use Indie API (IIRC) and are free to do whatever. So this is more of a misconfiguration on the provider’s end than a bug in linter.
linter-ui-default also has a setting that controls what the panel shows between:
- Entire project
- Current file
- Current line
The default is “Current File”, but you are free to change it to whichever you prefer .
So from the initial list:
- partially done; next step would be to integrate the signature-help functionality while typing. I will set up a new project for that soon
- tbd: not sure if someone already started that, or if there is something we can extend or reuse. Opinions welcomed.
- the existing linter/linter-default-ui can be used; you will have to configure linter-default-ui to show project-wide linting in the settings if desired
My guess is if we have these missing pieces in place we already cover more than 80% of what ppl use from Atom-IDE (correct me if I’m wrong).
Already some progress with the signature-help… as usual starting with console.log to understand the protocol
Huge update to the Data Tip Provider thanks to the help of @lloiser and the folks at Atom-TypeScript (where I found the final hint how to make use of the Atom-Text-Editor for the syntax highlighting of the Code Snippets)…
Next: move focus to the signature help extension again (and re-use things learned from the data tip implementation)
well done y’all!