EmmyLua for IntelliJ: a Lua IDE plugin graded in checkmarks and numbers

The feature table is a progress report, not a checklist

The README's Features table has a progress column that mixes three notations: a checkmark, a bare number, and a percentage. That inconsistency turns out to be the most informative thing on the page.

Marked complete with a checkmark are the bulk of what an IDE plugin needs to be usable. Syntax highlighting, highlighter for globals, for locals and parameters, and for upvalues. Lua 5.3 support. Find usages. Rename on Shift+F6. Go to definition with Ctrl and mouse click. Go to symbol with Ctrl+Alt+Shift+N, go to class with Ctrl+N, go to file with Ctrl+Shift+N. Parameter name hints. Keyword completion, basic completion, structure view, brace matching, comment in and out, colour settings page. Comment-based type and class annotation. Method override line markers. Name suggestion for refactor. Quick Documentation on Ctrl+Q. Live templates. Code formatter. Region folding. Lua Standard Library and API. Lua Check.

Then the numbers. Postfix completion templates sit at 14, code intentions at 9, and code inspections at 7. These are partially implemented features, and the table is telling you so by giving a count rather than a tick.

Finally, one percentage: Embed Remote Debugger at 0%.

Reading those three notations together tells you the plugin is feature-complete for editing and navigation, partially built for guided refactoring and static checks, and unfinished for embedding a remote debugger somewhere.

The roadmap says the debugger is being rewritten

The Road map section is six items and the ordering is the story.

Attach debugger rewriting is unchecked. Remote debugger rewriting is checked. Data follow inspections is unchecked. Ctrl follow inspections is unchecked. `@interface` support is unchecked. API Hub is unchecked.

So the local attach debugger is the one large subsystem the project has not finished rewriting, and the remote debugger rewrite is already done. For a plugin whose stated purpose is Lua IDE and debugger, that ordering matters: the debugging story is asymmetric, with the remote path in better shape than the local one.

The four remaining unchecked items are all about inspection and annotation rather than debugging. Data follow inspections and Ctrl follow inspections would extend the existing inspection framework, of which seven exist today. `@interface` support suggests a type annotation form the plugin does not yet parse. API Hub is unexplained beyond its name.

None of this is a criticism of the project; a public roadmap with honest checkboxes is more useful than silence. It does mean the feature table and the roadmap have to be read together, because a tick in the table tells you something exists, not that it is finished.

Annotation-driven typing, which is how Lua is meant to be typed

Among the completed features, one deserves explanation because it shapes how you write your code: comment based type and class annotation.

Lua is dynamically typed, though code may use static type annotations, and the plugin takes the approach of reading types out of comments. That is consistent with the Lua ecosystem's own conventions and with the fact that the plugin ships a Lua Standard Library and API component, meaning the built-in library is described in that same annotation format so the tool understands standard functions without configuration.

The practical consequence is that type information lives adjacent to the code rather than in a separate definition file. Editing a signature and its type together in one file is convenient, and the downside is that any tool in your pipeline that does not parse comments sees untyped Lua.

Method override line markers, parameter name hints, and the method separators configuration screenshots in the README all sit on top of this model. Method separators in particular suggest the plugin reads your naming convention so it can decide which parameters are arguments and which are options, which only works if the annotation layer is doing real parsing.

Building against a specific IntelliJ platform version

Building requires JDK 11 and two environment variables:

JAVA_HOME="path to JDK 11"
IDEA_HOME_203="path to IDEA 203+"

Then the Gradle build:

./gradlew buildPlugin -DIDEA_VER=203

The `IDEA_VER` property is the platform version you are building against, and the variable name `IDEA_HOME_203` tells you the convention: the environment variable matches the platform you are targeting. IntelliJ platform 203 corresponds to a 2020.3-era IDE.

So there are two coupled constraints. A plugin built against 203 will not load into a much newer IDE without a corresponding rebuild.

The build itself is Gradle with Kotlin DSL, since the root has both `build.gradle.kts` and `settings.gradle`, plus `gradle.properties` and the wrapper scripts `gradlew` and `gradlew.bat` for Windows.

Users who do not build from source install from the JetBrains plugin marketplace, where the plugin is published under ID 9768, which the download and version badges both point at.

Where the project lives and who maintains it

The homepage is emmylua.github.io, with a separate Chinese-language documentation site at a zh_CN path. Both are linked from badges at the top of the README, so English and Chinese documentation are maintained in parallel rather than the English being a translation afterthought.

The community channels are Gitter and two QQ groups, with the group numbers given directly in the README: 1群 `29850775` and 2群 `529914962`. There is a note that the latest version and some video demonstrations are distributed through the group files, which is an unusual distribution path and worth knowing about if you are trying to get a specific build.

The authorship is a single primary developer, @tangzx, with a contributor list of named people. A donation page is linked as well.

The licence is Apache-2.0, in `LICENSE.txt` at the root. There is also a `license/` directory and a `build.gradle.kts`, so licensing is checked into the build configuration rather than left as a text file nobody reads.

Tags say 2018, commits say 2026

Here is the discrepancy worth resolving before you install anything.

The listed releases are 1.2.3 on 2018-03-22, 1.2.4 on 2018-05-03, and 1.2.6 on 2018-11-17. All three are from 2018.

But the repository is not archived, and the last push was on 2026-08-17.

The JetBrains marketplace badge points at plugin ID 9768, and the download badge reads from the marketplace rather than from GitHub releases. So the version most users actually install comes from JetBrains, and the GitHub tag history is not the authority on what is current. That is a normal arrangement for an IntelliJ plugin, where the marketplace is the distribution channel and the plugin's build number is what identifies a version.

The practical consequence is that you cannot determine what is installed from the GitHub tags. Check the marketplace listing or the plugin's own about dialog for the version, and check the plugin compatibility range against your IDE build before assuming it will load.

The repository structure also suggests how the code is organised: `src/` for sources, `gen/` for generated code, `design/` for design documents, `bunch/` alongside a `.bunch` config file, `snapshot/` holding the GIF and PNG assets the README embeds, and `gradle/`.

Editorial conclusion

Adopt EmmyLua for IntelliJ if your team develops Lua inside the JetBrains ecosystem and wants indexing, refactoring and a debugger in the same IDE, since the completed feature list covers the standard navigation and completion set. Do not adopt it if you depend on the attached local debugger in production workflows, because attach debugger rewriting is unchecked on the roadmap while remote debugger rewriting is already done. Verify first which IntelliJ platform version you are on, since the documented build targets IDEA 203 and later.

Frequently asked questions

Official sources

1. EmmyLua/IntelliJ-EmmyLua on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases