This week sees the release of IntelliJ IDEA 2019.2 Beta 2, which means we are getting pretty close to the big day – the release of v2019.2!
We are giving the upcoming releases a final polish, adding more improvements here and there. We’ve improved the Terminal and now it soft-wraps long lines better, so all the links are gently kept in a working state. Previously, the Terminal could occasionally break links when wrapping lines.
The idea of Inline Method Refactoring is simple – replace a method call with its contents. Still, it is really powerful. But to appreciate its power, you need to know its use cases.
Let’s understand why, when, and how to apply the Inline Method refactoring and how IntelliJ IDEA can help you get started.
Welcome to summer! In Europe we had a huge heatwave in June, except, apparently, here in Seville (Spain). Looks like we donated our unwanted heat to the rest of you. You’re welcome!
This month we’ve got a bit of light reading for the beach. Or, you know, you could read a novel. Or try to stop the kids from drowning. Whatever works for you.
As we announced a short while ago, in the upcoming version 2019.2, IntelliJ IDEA and other IntelliJ-based IDEs are extending EditorConfig support, thus allowing you to manage all code style settings for each set of files individually. All you need to do is place an
.editorconfig file in the root directory containing the files whose code style you want to define. You can have as many
.editorconfig files within a project as needed, so you can specify different code styles for different modules. All options from the
.editorconfig file are applied to the directory where it resides as well as all of its sub-directories on top of the current project code style defined in Settings/Preferences | Editor | Code Style. If anything is not defined in
.editorconfig, it’s taken from the project settings.
In v2019.2, in addition to the standard EditorConfig options, we are adding a bunch of custom IntelliJ IDEA options, so now you can conveniently manage all you code style settings on the directory level.
Over the years, IntelliJ IDEA has accumulated support for a large array of technologies, and many of the technologies are no longer being actively maintained. We know that there are still people using these technologies, and up until now, we’ve been maintaining the plugins for them as part of the main IntelliJ IDEA source repository. However, our project has been growing, and carrying around this excess baggage is getting more and more difficult both for our users (as the plugins affect the size of the installation and potentially the performance of the IDE) and for our development team. At the same time, we’ve established procedures for maintaining a stable third-party plugin API, so we’re confident that moving the plugins out of the main repository will not affect their stability as the IDE evolves.