Darwin's Theories Blog

New Theories for a New Time

Defeating IDEA's Dreary Defaults

2022-06-19
How to work more smoothly by becoming a Settings Explorer

As a long-time user of the Eclipse IDE, I’ve always been impressed by how well it is optimized for developer productivity. Google a few years ago foisted on us the switch of Android Studio from being Eclipse-based to being IntelliJ IDEa-based. So it’s time to learn some new dance steps. Here’s some of what I’ve learnt so far in terms of developer settings.

First, there’s an issue with code completion. For some reason, if you want a completion like SemanticThingaMe, you have to type capital S followed by e, m, etc. Other IDEs realize that most devs don’t have time to hit the shift key for obvious completions, but IDEA defaults the opposite way. The fix is in Settings→Editor→General→Code Completion. Un-check the box at the top labelled Match Case. While on this page, you might or might not want to eliminate the over-descriptive Documentation Popup that takes over a big chunk of the screen - canonically the part you need to see and work on - if you hesitate for a big chunk of a second. This popup forces you to close it, it doesn’t die when you mouse away. Very annoying. Should not be the default.

idea settings m
Figure 1. Code Completion

The next annoying setting is imports. Eclipse has a nice "Organize Imports" feature that provides all missing imports, automatically if it can, prompting if there are ambiguities. It also sorts the imports, expands any imports ending in * to show the actualy imports used, and generally does a nice job. IDEA on the other hand requires you to either do Alt-Enter, or mouse down and click Import Class, for every missing import. This, too, is amenable to repair. Go into Settings→Editor→General-Auto Import→Java. Check Add unambigious imports on the fly. Also check Optimize Imports on the fly, but note the anoyingly-minuscule caveat beside it - this is a per-project setting and will have to be re-applied on every project, which may be a nice safety feature but is a pain if like me you may work on 20 to 40 different projects every week. You can still do Optimize Imports from the menu whenever you want, but enabling the "on the fly" options probably obviates doing so.

idea settings n
Figure 2. Optimize Imports

There’s one more setting you might want to tweak, but it only kicks in if you are writing Swing/AWT code. These two packages are singled out for being always displayed as import javax.swing.; and import java.awt.; If you prefer to actually see what imports you are using, you can disable that. Look under Editor→Code Style→Java→Imports. Click each package and click the minus sign to delete it.

Alternately, you can enable "starring" for selected packages, or even have it applied automatically if you import more than a certain number of imports from a given package (default is five).

idea import star
Figure 3. Imports with Stars

That’s it. If you are lucky, you now have IntelliJ working nicely for completions and imports. Now, if you also use Android Studio or PyCharm or any of the other different-plugin-different-brand IDEs produced from the same codebase, repeat the above steps.

You might ask why I don’t suggest, at this point, using Settings export and re-import, which is available under File→Manage IDE Settings. First, because the export is a binary Zip file and I don’t trust it. Second, because there’s no documentation on what happens if you export settings from one of these IDEs and import into another: what happens to settings that don’t exist, or are missing? If you try it, let me know.

One thing that doesn’t work and can’t really be fixed: if you have a project with a main() class, and there’s an error anywhere else in the project, you can’t run anything, even if doing so would help you fix the project in the other file! Eclipse, OTOH, just asks if you want to run anyway, and optionally remembers this on a per-project basis. There’s a theoretical way of doing it in IDEA, setting Settings→Build→Compiler→Java Compiler→Use Compiler to the Eclipse compiler, which adds the option "Proceed on errors" (and even defaults it to checked). However the version of the Eclipse compiler shipped with IntelliJ IDEA 2022.1 only supports ancient Java (up to Java 14), so you can not use this option to get by these days.

Well, at least now I have a few things working better in IntelliJ IDEA. Maybe next week there’ll be more annoyances to clear up, but these are the ones that have bothered me most in coming from Eclipse. Your mileage may vary!