IntelliJ-based IDE Features Roadmap for 2020

Dmitry Jemerov

This is the second part of the roadmap of IntelliJ IDEA and IntelliJ-based IDEs for 2020. The first part of the roadmap was focused mostly on low-level features in the platform. In this post we’ll be talking about higher-level features, ones that the users will directly interact with. Some of these features will roll out in 2020.1, and others will appear in releases later during the year.

Localization

Last year, we localized the JetBrains Website and made it available in 8 different languages. Now we’re happy to announce that we’re working on localizing IntelliJ-based IDEs. We’re working on IDE localization for the Asian markets and planning to provide initial support in Chinese Simplified. Korean and Japanese are next on the list. It will be possible to install translations as plugins, so the community will be able to provide translations for other languages.

Using the IDE as a General-purpose Editor

A long-standing user request is for the ability to use our IDEs as general-purpose text editing tools, for viewing logs, editing configuration files, and other non-code-editing use cases. To some degree, this is already supported – for example, you can open files from the command line. However, opening a file outside of a directory containing an IntelliJ project (the .idea directory) always created a temporary project, which cluttered your disk with useless project files and caused other inconveniences.

With the recent startup performance improvements, the possibility of using our IDEs as lightweight text editors has become more plausible, so we’re now building a dedicated mode for editing non-project files. In this mode, the IDE will work more like a simple text editor. It will open even faster, it won’t store any project configuration, and it will use the same workflow as a regular text editor for creating, opening, and saving files.

The set of features available in this mode will also be very limited. However, you’ll be able to easily switch to the full project mode if you need to use features such as refactoring or debugging.

Git Staging Support

Support for the Git staging area is the most voted for feature request for our Git integration. Historically, the Git integration in IntelliJ Platform has been built on top of the same framework as other version control integrations (such as Subversion and Perforce), and instead of the staging area, it supports the concept of changelists. Changelists are more flexible than the staging area because they allow you to manage multiple sets of independent changes that you aren’t ready to commit. With the recently added support for moving parts of a file between changelists, we’ve basically covered the main use cases of the staging area.

However, support for changelists in Git is specific to the IntelliJ Platform. The command line Git and all other clients, support the staging area instead. People new to our IDEs don’t always understand how to work with changelists or how to use them to handle the scenarios that they currently use the staging area for.

Because of this, we plan to implement two different modes for the Git integration in future IDE versions. You’ll be able to choose whether to use the current UI, based on changelists, or a new UI that supports the staging area but does not support changelists. (Combining the two doesn’t seem to be feasible because the combined UI would be far too complex conceptually.)

Machine Learning-based Completion

We’ve been exploring the use of machine learning for improving code completion for quite some time already, and the results of some of this work are already in production. Current versions of IntelliJ IDEA use machine learning to improve the ranking of completion variants. Language plugins tag each produced completion variant with various attributes, and ML is used to determine which attributes should contribute to item ranking so that most relevant items are shown at the top of the list.

This year, we’re going to roll out additional ML-based completion features. We’re teaching ML completion to make better use of the context for ranking completion suggestions and to generate completion variants that go beyond a single identifier (full-line completion). Of course, it’s essential for us to ensure that the variants we suggest always make sense, so it may take a while before full-line completion appears in the product. But in any case, this is a major area where we are investing our efforts.

Onboarding and Environment Setup

One additional area of focus is to make it easier to get from a clean machine to a fully working development environment. Once the user has installed the IDE, it will be able to take care of installing everything else required to develop and run the user’s projects – Git, the JDK, and so on. We’re also simplifying the initial configuration of the IDE and the workflow for importing or creating a project.

This work matters not only for novice developers, but also for people new to a specific set of technologies – even if you have many years of experience with a language, getting familiar with a completely different language and environment can sometimes be quite baffling. We want to ensure that our IDEs can assist you on your journey and help you become productive as quickly as possible.

Refactoring Autodetection

For us, the support of automated refactorings has always been one of the strongest elements of our IDEs. However, our usage statistics show that a significant percentage of our users do not use them. Rename is used fairly broadly, but more advanced refactorings such as Extract Method and Change Signature are not among the 50 most commonly invoked actions. To unlock the value of the IDEs for our users, we’re putting a lot of effort into making refactorings more discoverable.

For example, we’re adding the possibility to detect changes in the declaration of a method and adjust its usages accordingly. If you rename a method, or add, remove, or reorder its parameters, IntelliJ IDEA will show a tip that will make the corresponding changes to its calls. This gives you the benefit of our rich refactorings without requiring you to learn how to invoke the refactoring explicitly.

Code Vision

Some time ago Rider, our .NET IDE, introduced support for Code Vision: displaying rich contextual information directly in the code editor. We plan to extend this support to IntelliJ IDEA, so that you’ll be able to see this information, such as the author of each method and the number of its usages, directly in the editor. The annotations are interactive. For example, clicking on the number of usages will allow you to navigate to the list of usages.

Summary

All of this is subject to change, and it’s quite possible that some of the work described above will not be released, in which case we’ll have other awesome stuff for you, instead.
Feel free to leave your feedback in the comments below. And please stay tuned for Early Access Program announcements, which will let you know when some of this work is ready for you to try.
Happy Developing!

Subscribe to IntelliJ IDEA Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!