Preliminary Roadmap #3
Comments
|
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. |
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). |
|
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. |
|
Hi, great progress on bringing Nuclide/Atom IDE back to live; blazing fast response to the official shut down.
Since Hyperclick is still functional, I put together a provider package for 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. |
|
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 😊 |
|
Regarding atom-ide-outline, could tree-sitter be used to generate the outline automatically? |
|
Hi! I was annoyed with conflicts between atom-ide-datatip and linter-ui-default popups. 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 I split package into popup-view-behavior-related (mouse/keyboard tracking, pulling data from providers) and data providers packages. 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. |
|
Hi, |
|
@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. |
|
@appelgriebsch, thanks for idea with priority.
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.
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 |
|
What’s the best way to contribute ? |
|
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 |
|
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. |
|
how about node debugger? |
Instead of a single debug interface would be worth to look into the Debug Adapter Protocol that is heavily used in VSCode and its extensions. This DAP is kind of intermediate layer such as the LSP for programming language semantics, and would allow to reuse existing debug adapter implementations easily. Nevertheless I assume the DAP kind of implementation might be easiest part. As the experience with the atom-ide-ui showed having a proper UI/UX for debugging is more crucial (and more effort). As of this it is not mentioned in the initial set of features / roadmap, but if someone want to take the challenge, I'm open to discuss it :) |
|
Is there any chance that the project will migrate to typescript? |
|
I am so glad to see a community effort to pickup where facebook left off. Is there any intent or interest in a package that allows for seeing/navigating the inheritance structure of JS ES6 classes and which class in the chain provides which methods? Internally we have fiddled with extending some of the Atom Lupa project's work but the upstream project has not seen much active development in quite some time. I see some mention in the roadmap of implementing a structure view, but it appears to be scoped to the current open file (similar to the Outline view from the facebook atom ide days). |
|
Are you thinking about adding the terminal back in? |
Currently there are no organization-wide guidelines established, each package is living its own live, so decision about "flavour of JS" is with maintainer.
The roadmap is a general idea and projects listed are more of a baseline, based on the old Took a quick look at the Atom Lupa (never used it) and it doesn't support outline view provided by an LSP (pretty much core of the Atom IDE), which is/was the main purpose of the original outline module. Would it conflict or be redundant if support for LSP outline was added to a Lupa-like package?
I don't know the full scope of the original terminal package in |
|
@Belar I have looked at the Atom Lupa package and even toyed with some extension to do what I am looking for with some decent early wins, however my concern with that package is that it does not seem to be actively maintained much if at all... |
|
Are |
ghost
mentioned this issue
As I see it there is no meaningful code yet. I think a lot of work. |
|
It's been a year since the publication of the roadmap, which seems now is a great time for an update. It may also give a positive signal that the project is not dead, although it got a bit stale for a part of 2019. StatusRegarding packages released under Atom IDE Community umbrella or with started development, statuses are as follows:
Work on ideas mentioned in the roadmap,
If you know about existing, maintained packages that functionality wise fit any of the above, please share. It would be great to build a list of available alternatives to recommend, and focus development on missing solutions. For example, there are active terminal packages available in the registry, like ContributingTo continue on the question of contribution. It's very hard to give a meaningful answer or strict instructions that would be universal for an entire project, and it often gives a "somebody is working on it already" impression; which is usually false. Since Atom IDE has wide variety of needs, it may be better to take it on a case by case basis. If you would like to contribute, reach out (here or through Atom's Slack in #ide channel - feel free to DM me if you are unsure about a contribution) with:
Let's see if this will provide a better experience for everyone who wants to participate in the project. |
|
There is an atom plugin for Kite (https://github.com/kiteco/atom-plugin) which provides:
Is there any chance to use this plugin (or its features) for other languages too? It is now limited to Python. The AI part depends on the individual language clients, but the front end is totally usable, right? Maybe different sections can be implemented on separate packages. For example,
|
|
Is there a plan to have a package to add support for inlay hints, like intellij and vscode? |
I think this is already possible using Linter. https://atom.io/packages/search?q=linter |
|
No, it's not, inlay hints are like this grayish areas where it show in screen (not on hover), I found no way to do the same on atom, using ide-ui or linter
|
|
@aminya Kite is interesting. If I remember correctly, they are working on adding support for other languages. Front-end/UI wise, based on plugin's description (I didn't use Kite), we are not far away. Hover info is done by Documentation looks nice, a bit like a code browser - search + cursor + signature etc. Definitely possible to do as a standalone package, with "How others used this" feeling a bit tricky (depending on source, it seems to be more than a data tip example). When it comes to the "intelligent" part, @GrayJack Inlay hints look very handy. Unfortunately, I don't know about anything like that being available in Atom. There is currently no plan for it on IDE Community "roadmap", with signature package already providing this info and many core packages still missing. However, it would be a great enhancement, and if someone would like to work on it, it will be a very welcome contribution. |
Ah, meant that I don't know about any package from "atom ide category" that does inlay hints. Of course, it's possible, and I agree 100% that it would be a great addition to
Saw Juno and Ink, would be nice to be able to recommend their UI packages. However, maybe I'm wrong, it's a different approach, not modular, doesn't support IDE packages, not LSP and DAP oriented. There is a room for collaboration here actually, Ink and Atom IDE have a common goal. |
I have a question here. Does this modularity affect the performance or loading time? If everything was in a single package, inter-package connections could be done using JavaScript modules, but now it is done over services (correct me if I am wrong). Actually, there is a plan to merge Ink to Julia-Client. They think this helps the loading performance.
Definitely both (and the whole Atom ecosystem) can benefit from this collaboration! I look forward to helping with that. |
|
Looking forward to the development of atom-ide-community |
@Belar I wouldn't mind helping maintain a new hyperclick package. Would it be better for me to start it in a separate repo or maintain it in atom-ide-community? |
@UziTech It's a good repo for atom-ide-community. That said, I would like to do an update, I won't be active within the organization any more. It will be best to take all the cases with the maintainer or whoever will offer a support in the future. |
|
Okay, I have a question. Is this a ground-up from-scratch reimplementation or are you reusing bits of code/styles/etc from https://github.com/facebookarchive/atom-ide-ui? Because if it's the former, this seems like effort duplication, which might not be entirely necessary, and if it's the latter, you have some issues with licensing, i.e. you can't just relicense bits you're using. Disclaimer: IANAL |
|
I think it's the former |
Now, I am the active admin. If anyone wants to contribute or maintain a package please let me know.
@UziTech I have given you proper access. 😉 |
The packages that we have right now are mostly a modernized re-implementation. The packages are in separate repositories, and the communication is only through services. For example, We have a markdown-service package, which is used by a couple of others.
Even if you wanted to just reuse the exact software, it is OK as long as you keep the original license in the new repository. BSD License allows distribution of any kind if you retain the license notice (atom-ide-community will check for the license inclusion for distribution of this kind). Check here to know more: https://en.wikipedia.org/wiki/BSD_licenses: You don't need to be a lawyer. 😉
|
|
I am pleased to say that we now have a parallel fork of Atom, which plans to speed up the process of development and improvements. We will release the builds under the You can check the projects to see more details about the plan: https://github.com/atom-ide-community/atom/projects Here is the discussion place for that project. Come chat with us! 😀 |
|
Glad to see such activity... may be I will return to Atom someday.
|
@tonn I invited you to the organization. Those are useful! Thanks. We should consolidate these packages with atom-ide-datatip to prevent duplication. Then we can include them in our atom-community builds as well. |
|
The licenses for all the repositories are updated to point to the BSD notice for atom-ide-ui software, just in case a repository uses code from that. This will not remain in any room for ambiguity. cc: @lierdakil P.S: I cleared our comments per this resolution to keep the discussion focused on the roadmap. |
|
Is there any support for remote development? |
@paulchill do you have any pointers on getting remote development to work in Atom in this day and age ? The "nuclide" package is not found when I go to the Install tab, so I'm not sure how to get this to work... |
Atom already has a good remote development support. It is officially supported by Github itself. |
|
@aminya I think @paulchill was talking of this https://nuclide.io/docs/features/remote/ (at least that's what I understand). This is equivalent to the "Remote - SSH" extension in VS Code. |
|
Perhaps the |
|
@sbrl thats on the right track, but sadly its still a pretty far shot from the Remote - SSH in VS Code. Its going to be tough to get something like that running. I'd say remote SSH, the docker extension, and the IDE-like stuff are the "killer-apps" of VS Code that are going to take the most work to replicate. |
|
Is there a link to the #atom-ide Slack that I could join with? |
|
You can join using this link: |
@h3imdall provides a great package for remote development. Check it out! |
|
@aminya that looks like an awesome extension! I think something like that could compete to some degree with vscodes remote ssh. |
|
Hey everyone! I am closing this issue in favor of the new feature of GitHub, "discussions". |
and others
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:
There is the planning for those:
There is one new project having started right now:
There are also a couple of ideas for packages to be written next:
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.
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.
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.
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).
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).
The text was updated successfully, but these errors were encountered: