Preliminary Roadmap

[appelgriebsch]

With the Atom IDE Community project getting more traction we would like to share our roadmap / planning for it here. This roadmap is in a preliminary state, and has been briefly outlined on the #atom-ide Slack channel a couple of days ago.

We provide this as an issue here, so the community can take part of the decision making process and give their direct feedback to the planning.

At the moment of writing the Atom IDE Community project hosts the following released packages:

• atom-ide-datatip
• atom-ide-definitions
• atom-ide-signature-help

There is the planning for those:

1. polish atom-ide-datatip, which is already in version 0.9; 1.0 can be delivered as soon as we have diagnostic tooltips in place and fix the potential bugs with multiple overlays
2. polish atom-ide-signature-help. Here we are only working on bug reports and issues at the moment; looks like not many lsp have signature help implemented anyway.
3. polish atom-ide-definitions , in which we want to add hyperclick style functionality to jump to the source on cmd/ctrl+click.

There is one new project having started right now:

4. progress on atom-ide-diagnostics and provide initial set of features incl. gutter, highlighter, panel and overlay for issues in the source code. It also supports Code Actions on those issues (if available).

There are also a couple of ideas for packages to be written next:

5. start atom-ide-console, which can be used to stream log and diagnostic messages (error, warn, info) into a panel from various sources and optionally allows to jump to the source of the issue. Console can be used by various atom-ide packages to show output and process in a panel on the bottom of the screen.

6. start atom-ide-outline, which shows an outline view of the structure of the current file in the editor, and allows you to jump around easily. Project wide symbol search is also a topic we would like to cover and support.

7. start atom-ide-formatter, which uses the lsp to format a file or a section in a document. It provides also capabilities for automatic formatting of a file on save.

8. start atom-ide-tester, which offers testing features not found in the lsp, but are still required for a decent IDE experience. It automatically scans your workspace for unit test cases and can execute them on your behalf. Any issues or the status is displayed in a panel so you will always know if your source code behaves as desired. It provides language specific tester plugins and will be developed on concepts and ideas of the original Atom Tester package(s).

9. start atom-ide-builder, which offers build features not found in the lsp, but are still required for a decent IDE experience. It can build your project via various build providers and shows the status of the current / recent build in a panel. It provides language specific build extensions and will be developed on concepts and ideas of the original Atom Build package(s).

[exploide]

Cool, thanks for filling the gap after Facebook retired. 🎉

One question regarding atom-ide-diagnostics: How would it be different from linter-ui-default? Can't this one be reused?

Another thing: Are there plans to deliver kind of a meta package that pulls in all the other packages as dependencies? I think it would be a suboptimal user experience if one has to search and install a ton of packages manually. Besides, if one installs the packages now and then you come up with a new fancy package, the user woudn't be aware. A meta package could just deliver it as a new dependency on the next update.

[appelgriebsch]

One question regarding atom-ide-diagnostics: How would it be different from linter-ui-default? Can't this one be reused?

Hey, thank you for your nice feedback. Yes, at the moment we are going with linter and linter-ui-default, but whereas the former has proper support for Language Server Protocol messages the ui-default is lacking some features we would like to see (such as integration with code-actions on issues).

As the linter-ui-default project hasn‘t seen any significant update for more than 12 months it would eventually be easier to just start with a drop-off that has the main features of linter-ui-default plus the missing pieces and is more consistent with our UI overall.

That said the first investigation was quite interesting as the LinterV2 and Intention package already support pluggable UIs, so we only have to take care about those parts (via provideLinterUI and provideIntentions services).

[ryanolsonx]

Great ideas regarding things unrelated to LSP (Language Server Protocol). It would awesome to have some packages related to testing/building a project.

I agree with the direction. Something to be clear on with this project in general is that we want this to be a very open community. If you're a developer and you'd love to make improvements to any of these existing packages that we've created OR wish to take up one of these initiatives (namely 5-9), we'd love to have your help. This is going to be a big endeavor and it's going to make developing in Atom an incredible experience.

If you have any ideas for a way to improve any of these ideas, this is a great place to talk through features and what would be ideal for you. If you have any other ideas, we'd love to here them. It's almost like we have a nice blank slate where we, as a community, can choose the direction.

[Belar]

Hi, great progress on bringing Nuclide/Atom IDE back to live; blazing fast response to the official shut down.

polish atom-ide-definitions , in which we want to add hyperclick style functionality to jump to the source on cmd/ctrl+click.

Since Hyperclick is still functional, I put together a provider package for atom-ide-definitions - https://github.com/Belar/atom-ide-click

No idea what's the current plan; if there will be standalone, alternative Hyperclick package from community project or will it end up as a built-in, but would be happy to add/publish above to atom-ide-community packages, if it would help and fits the development scheme of course.

[ryanolsonx]

Nice! That's awesome. Would you mind integrating that into atom-ide-definitions? It really fits there. If you make a PR, I can merge it and then make you a contributor to the community 😊

[sbrl]

Regarding atom-ide-outline, could tree-sitter be used to generate the outline automatically?

[tonn]

Hi! I was annoyed with conflicts between atom-ide-datatip and linter-ui-default popups.
Like this:

So I was tried to add linter messages to atom-ide-datatip popup and... and I have rewrote whole atom-ide-datatip.

Result:

https://github.com/tonn/atom-ide-hover
https://github.com/tonn/atom-ide-hover-datatip
https://github.com/tonn/atom-ide-hover-linter

I split package into popup-view-behavior-related (mouse/keyboard tracking, pulling data from providers) and data providers packages.
It is written on Typescript/Etch with full strict mode.

I will not publish this packages to apm with current names by myself.

And I have no idea how make pull request for this to your community ))... I think the best option if somebody clone my repositories into atom-ide-community, and mark atom-ide-datatip as obsolete.... of course if you want.

[michaelkonecny]

Hi,
is there going to be a package like atom-ide-refactor?
It seems like this wasn't finished in atom-ide-ui, but somebody has done some work on supporting textDocument/rename so maybe this could be used for a start?

[appelgriebsch]

@tonn hey, thanks for your input / idea on the diagnostics and data tip package improvements... I was heavily looking into it myself a couple of days ago. After first trying to fix it in the data tip package (as soon as it discovers that there is already an overlay shown at the given position, don't display the data tip) I was searching for a way to combine the information of rather loosely coupled components / packages.

As of this I figured out that the data tip service already provide a mechanism to set a priority for the provider... so the current plan is to have the diagnostic package register as a data tip provider itself, but with an higher priority than the ide-... implementation usually do for the data tip feature (they mainly register with priority == 1).

So as soon as the data tip package is checking for a data tip at a given position it will query the diagnostics package first, and if there is an issue will report this as usual.

This makes it possible to (easily) integrate the feature in the existing packages without having to do a huge rework / restructure of it (as you did) without loosing any existing functionality.

[tonn]

@appelgriebsch, thanks for idea with priority.

This makes it possible to (easily) integrate the feature in the existing packages without having to do a huge rework / restructure of it (as you did)

There was another reasons to rewrite exiting code: make it more readable (and migrate to typescript), remove strange magic-string operations with html layout (partially, there is still md-service and signature-helper), separate popup-behavior logic from popup-content logic, make more robust and predictable popup show/hide behavior on mouse events.

without loosing any existing functionality.

As I can see I had implemented whole functional from atom-ide-datatip package... or did I miss something?

ps: I'm going to work on atom-ide-* when I will have free time. It will be great if I can benefit the community

[soriyath]

What’s the best way to contribute ?

[mallardduck]

Agree with @soriyath - it'd be nice to know more about how to contribute. I have a sense that there's a largely untapped community of old atom-ide-ui users that might be able to help accelerate the development process.

[appelgriebsch]

Hey everyone, as we have just started this community approach we don’t have a formal process for contributing right now. Nevertheless we highly appreciate and welcome any kind of support: testing and writing bug reports or feature request, help with spreading the word and making our community approach more widely available, making PRs for bug fixes or additional features, checking out the roadmap and get in touch with us on the atom-ide channel on the atomio slack group in case you want to take over some of the not yet existing parts. The atom-ide channel on the slack group is also a good way to discuss with us on further topics that are not mentioned here.

[quanru]

how about node debugger?