KronicDeth/intellij-elixir

Elixir plugin for JetBrain's IntelliJ Platform (including Rubymine)

1,897

stars

6,370

commits

Kotlin

primary language

Sep 9, 2026

updated

androidstudio

appcode

clion

datagrip-ide

editor

editor-plugin

elixir

elixir-mix

elixir-plugin

gogland

hacktoberfest

ide

intellij-plugin

java

jetbrains

mix

pycharm

rubymine

webstorm

Browse cluster: JVM Languages and Android Development →

README

Elixir plugin

Elixir plugin

This is a plugin that adds support for Elixir to JetBrains IDEs.

The plugin works both in the rich IDEs that allow alternative language SDK selection and small IDEs that are language specific. The rich IDEs work best for IntelliJ Elixir because only in the rich IDEs can have an Elixir SDK set as the Project SDK. In all small IDEs, the native language SDK is always there, which makes anything that uses the SDK, such as running elixir, erl, or mix more complicated both internally and externally in the configuration you have to setup.

IDEs

The plugin is free to use in all JetBrains IDEs. The Cost column in the below table is what JetBrains charges for the IDE itself. IntelliJ Elixir is maintained by @KronicDeth who does not get any of the subscription money. If you want to support the plugin itself, make a donation.

IDE	Rich/Small	Languages	Cost	Trial	License	Source
IntelliJ IDEA Community Edition	Rich	Java	Free	N/A	Apache 2.0	JetBrains/intellij-community
IntelliJ IDEA Ultimate Edition	Rich	Java	Subscription	30-days	Commercial	N/A
AppCode	Small	Objective-C	Subscription	30-days	Commercial	N/A
CLion	Small	C/C++	Subscription	30-days	Commercial	N/A
DataGrip	Small	SQL	Subscription	30-days	Commercial	N/A
GoLand	Small	Go	Subscription	30-days	Commercial	N/A
PHPStorm	Small	PHP	Subscription	30-days	Commercial	N/A
PyCharm Community Edition	Small	Python	Free	N/A	Apache 2.0	JetBrains/intellij-community subdirectory
PyCharm Professional Edition	Small	Python	Subscription	N/A	Commercial	N/A
Rider	Small	.NET	Subscription	N/A	Commercial	N/A
RubyMine	Small	Ruby	Subscription	30-days (90-day for whole team)	Commercial	N/A
WebStorm	Small	JavaScript	Subscription	30-days	Commercial	N/A

Once you have your IDE of choice installed, you can install this plugin

Features

Feature	Rich	Small	Alternative
Project	Yes	No	1. Open directory 2. Setup the SDK
Project Structure	Automatic	Manual
Project Settings	Yes	No
Module Settings	Yes	No
New Elixir File	Yes	Yes
Syntax Highlighting and Semantic Annotation	Yes	Yes
Grammar Parsing	Yes	Yes
Inspections	Yes	Yes
Quick Fixes	Yes	Yes
Code Folding	Yes	Yes
Commenter	Yes	Yes
Debugger	Yes	Yes
Delimiters	Yes	Yes
Embedded Elixir (EEx) Templates	Yes	Yes
Building/Compiling	Yes	No	Build/compile as part `mix` run configurations only
Live Templates	Yes	Yes
Documentation	Yes	Yes
Run Configurations	Yes	Yes
Completion	Yes	Yes
Decompilation	Yes	Yes
Go To Declaration	Yes	Yes
Formatting	Yes	Yes
Go To Related	Yes	Yes
Go To Symbol	Yes	Yes
Go To Test	Yes	Yes
Go To Test Subject	Yes	Yes
Find Usage	Yes	Yes
Live Embedded Elixir (LEEx) Templates	Yes	Yes
HEEx Templates	Yes	Yes
Refactor	Yes	Yes
SDK	Yes	Yes
Structure	Yes	Yes

Project

NOTE: This feature only works in Rich IDEs as it depends on an extension point unavailable in Small IDEs. To setup a project in a Small IDE

Open Directory of the project

Setup the SDK

From Existing Sources

Import project from external model

If you've already created a mix project, you can load it as an Elixir project into the plugin.

File > New > Project From Existing Sources...
Select the root directory of your project.
Select "Import project from external model"
Select Mix
Click Next
Select a Project SDK directory by clicking Configure.
The plugin will automatically find the newest version of Elixir installed. (NOTE: SDK detection only works for Linux, homebrew installs on OSX, and Windows. Open an issue with information about Elixir install locations on your operating system and package manager to have SDK detection added for it.)
If the automatic detection doesn't find your Elixir SDK or you want to use an older version, manually select select the directory above the bin directory containing elixir, elixirc, iex, and mix. (On Windows it is the directory containing elixir.bat, elixirc.bat, iex.bat, and mix.bat.)
Click Finish after you select SDK name from the Project SDK list.
The "Mix project root" will be filled in with the selected directory.
(Optional) Uncheck "Fetch dependencies with mix" if you don't want to run mix deps.get when importing the project
- If "Fetch dependencies with mix" is checked both mix local.hex --force and mix deps.get will be run.
Click Next
All directories with mix.exs files will be selected as "Mix projects to import". To import just the main project and not its dependencies, click Unselect All.
Check the box next to the project root to use only its mix.exs. (It will likely be the first checkbox at the top.)
Click Finish

Create project from existing sources

If you've already created a (non-mix) project, you can load it as an Elixir project into the plugin.

File > New > Project From Existing Sources...
Select the root directory of your project.
Leave the default selection, "Create project from existing sources"
Click Next
Project name will be filled with the basename of the root directory. Customize it if you like.
Project location will be the root directory.
Click Next.
If you previously opened the directory in IntelliJ or another JetBrains IDE, you'll be prompted to overwrite the .idea directory. Click Yes.
You'll be prompted with a list of detected Elixir project roots to add to the project. Each root contains a mix.exs. Uncheck any project roots that you don't want added.
Click Next.
Select a Project SDK directory by clicking Configure.
The plugin will automatically find the newest version of Elixir installed. (NOTE: SDK detection only works for Linux, homebrew installs on OSX, and Windows. Open an issue with information about Elixir install locations on your operating system and package manager to have SDK detection added for it.)
If the automatic detection doesn't find your Elixir SDK or you want to use an older version, manually select select the directory above the bin directory containing elixir, elixirc, iex, and mix.
Click Next after you select SDK name from the Project SDK list.
Click Finish on the framework page. (No framework detection is implemented yet for Elixir.)
Choose whether to open in a New Window or in This Window.

New

If you want to create a basic (non-mix) Elixir project with a lib directory, perform the following steps.

File > New > Project
Select Elixir from the project type menu on the left
Click Next
Select a Project SDK directory by clicking Configure.
Select a Project SDK directory by clicking Configure.
The plugin will automatically find the newest version of Elixir installed.
- macOS / OSX
  - Homebrew (/usr/local/Cellar/elixir)
  - Nix (/nix/store)
- Linux
  - /usr/local/lib/elixir
  - Nix and NixOS (/nix/store)
- Windows
  - 32-bit (C:\Program Files\Elixir)
  - 64-bit (C:\Program Files (x86)\Elixir)
  - (NOTE: SDK detection only works for Open an issue with information about Elixir install locations on your operating system and package manager to have SDK detection added for it.)
If the automatic detection doesn't find your Elixir SDK or you want to use an older version, manually select select the directory above the bin directory containing elixir, elixirc, iex, and mix. If the bin, lib, or src directory is incorrectly selected, it will be corrected to the parent directory.
Click Next after you select SDK name from the Project SDK list.
Change the Project name to the name your want for the project
(Optionally) change the Project location if the directory does not match what you want
(Optionally) expand More Settings to change the Module name, Content root, Module file location, and/or Project format. The defaults derived from the Project name and Project location should work for most projects.
Click Finish
Choose whether to open in a New Window or in This Window.

Project Structure

Project View

Excluded
- .elixir_ls (Elixir Language Server cache)
- assets/node_modules/phoenix (Phoenix symlink back to deps)
- assets/node_modules/phoenix_html (Phoenix HTML symlink back to deps)
- cover (Test coverage output)
- deps (Dependencies -- re-exposed as Libraries for Go-to-Declaration)
- doc (Documentation generated by ex_doc)
- logs (Conventional log directory)
Sources
- lib
- web (legacy Phoenix layout compatibility)
Test Sources
- spec (ESpec)
- test

Project Settings

The Project Settings include

Project Name
Project SDK

SDK Setup Known Limitations

When setting up Elixir and Erlang SDKs for the first time:

Setup SDKs before importing your Elixir project
Auto-detect SDKs: The plugin will attempt to automatically detect the SDKs based on the currently open project directory, not the directory that you are importing. To setup SDKs on a WSL instance, open any project, or even an empty directory in WSL first.
Click OK directly after configuring Erlang, then reopen the Project Structure dialog to configure Elixir - this will properly save all settings
Avoid clicking Apply then OK - this workflow has a known issue where the project SDK may not be saved correctly

Windows Subsystem for Linux (WSL) Support

The plugin supports running Elixir, Mix, and IEx commands within WSL. This includes:

Run Configurations: All Mix, ExUnit, ESpec, Elixir, and IEx run configurations are fully compatible with WSL.
External Tools: background tools like Credo inspections, Dialyzer, Mix Format, and the New Project Wizard automatically use WSL when your project is located on a WSL partition.
Path Conversion: Windows UNC paths (e.g., \\wsl$\Ubuntu\...) and Windows drive paths are automatically converted to POSIX paths when executing commands in WSL.

WSL Limitations

New Project Wizard: SDK selection is based on the location of the currently open project, not the new project. To select a WSL based SDK during the New Project Wizard, open any WSL project or directory in the IDE first.
SDKs and Project must all be on the same WSL Distribution: You cannot use a WSL based SDK with a non-WSL project, and vice versa. You can use the /mnt/c drive to access Windows files from WSL, but the performance is terrible.
Build system (Ctrl+F9): The IDE build system only works when the Project SDK is set to a JDK 21+ in the same WSL distribution, and all Module SDKs are set to the correct Elixir SDK.
Performance: Running the IDE in Windows with a WSL project is slower than running the IDE directly in the WSL instance. This is a limitation of the IDE, not specific to the Elixir plugin.

Module Settings

Sources

Module Settings > Sources

The Module Settings include Marking directories as

Excluded
Sources
Tests

Paths

Module Settings > Paths

Module paths list the output directories when compiling code in the module. There is a an "Output path" for dev MIX_ENV and "Test output path" for the test MIX_ENV.

Dependencies

Module Settings > Dependencies

Module dependencies include the SDK and the module's own sources. Mix dependencies from deps/ are automatically detected and registered as IDE Libraries by processes that run in the background and monitor file changes:

Trigger: File system events in deps/ and _build/ (after mix deps.get, mix compile or folder deletions).
What it creates: For each dependency, an IDE Library with source roots from deps/APP/lib and class roots from _build/ENV/lib/APP/ebin.
Result: Dependencies appear under "External Libraries" in the Project tool window, providing Go-to-Declaration, completion, and Find Usages into dependency source code.
Troubleshooting: If libraries don't appear after mix deps.get, try running mix compile to generate _build/ output, then wait a few seconds for the file watcher to pick up changes. You can also use Tools → Elixir → Install Mix Dependencies.

The status bar can display an Elixir SDK status widget in the bottom-right corner of the IDE. It shows the current SDK version and warns about configuration problems. It will only display when you have an Elixir file open in the editor.

Enabling the widget:

Open Settings (Ctrl+Alt+S / ⌘,)
Navigate to Languages & Frameworks → Elixir
Check "Enable Status Bar Widget showing if the Elixir SDK is correctly configured"
Click OK -- the widget appears in the status bar when you have Elixir files open.

Widget states:

Display	Meaning
`Elixir: 1.17.3`	SDK configured correctly
`Elixir: 1.17.3 !`	Classpath issues (missing ebin paths or Erlang SDK classpath entries)
`Elixir: 1.17.3 ⚠ OTP`	Elixir SDK was compiled against a different OTP major than the paired Erlang SDK
`Elixir: 1.17.3 ⚙`	Folder marks are suboptimal (e.g., `test/` not marked as Test Sources)
`Elixir: SDK Error`	Module `.iml` files reference an SDK that no longer exists
`Elixir: Issues`	SDK is invalid or missing its Erlang SDK dependency
`No Elixir SDK`	No Elixir SDK configured for the project

Click the widget to open a popup with quick actions:

Configure Elixir SDKs... -- open Project Structure to add or edit SDKs
Detected Elixir SDKs -- if no SDK is configured and a tool manager (e.g. mise) detects valid installations, they are listed here. Click one to register it as the project SDK.
Refresh Elixir SDKs -- re-scan SDK home paths and update classpath entries
Install Mix Dependencies -- run mix deps.get for the project
Reconfigure Elixir Module Setup -- re-apply canonical folder marks (lib/ → Sources, test/ → Test Sources, deps/ → Excluded, etc.) and fix dangling module SDK references

Notifications: When the widget detects a problem, it fires a notification with actionable buttons:

"Reconfigure Now" -- one-click fix for folder mark warnings and module SDK errors
"Open Project Structure" -- navigate to SDK/module settings
"Don't Warn for This SDK" -- suppress OTP mismatch warnings for a specific SDK

Notifications auto-expire when the issue is resolved (e.g., after running "Reconfigure Now"). Rapid project structure changes (such as importing multiple modules) are debounced to avoid notification spam.

Reconfigure Elixir Module Setup is also available from Tools → Elixir → Reconfigure Elixir Module Setup and via the action search (Ctrl+Shift+A / ⌘⇧A). It is additive -- it applies missing canonical marks without removing any user-customized source roots or exclusions.

New Elixir File

Right-click a directory (such as lib or test in the standard mix new layout)
Select New > Elixir File.
Enter an Alias for the Module name, such as MyModule or MyNamespace.MyModule.
Select a Kind of Elixir File to use a different template.

Empty module

An underscored file will be created in an underscored directory lib/my_namespace/my_module.ex) with the given module name with be created:

defmodule MyNamespace.MyModule do
  @moduledoc false

end

Elixir Application

An underscored file will be created in an underscored directory lib/my_namespace/my_module.ex) with the given module name with be created. It will have a start/2 function that calls MyNamespace.MyModule.Supervisor.start_link/0.

defmodule MyNamespace.MyModule do
  @moduledoc false

  use Application

  def start(_type, _args) do
    MyNamespace.MyModule.Supervisor.start_link()
  end
end

Elixir Supervisor

An underscored file will be created in an underscored directory lib/my_namespace/my_module.ex) with the given module name with be created. It will have a start_link/1 function that calls Supervisor.start_link/0 and init/1 that sets up the child specs. It assumes a MyWorker child that should be supervised :one_for_one.

defmodule MyNamespace.MyModule.Supervisor do
  @moduledoc false

  use Supervisor

  def start_link(arg) do
    Supervisor.start_link(__MODULE__, arg)
  end

  def init(arg) do
    children = [
      worker(MyWorker, [arg], restart: :temporary)
    ]

    supervise(children, strategy: :one_for_one)
  end
end

Elixir GenServer

An underscored file will be created in an underscored directory lib/my_namespace/my_module.ex) with the given module name with be created. It will have a start_link/2 function that calls GenServer.start_link/3 and the minimal callback implementations for init/1, handle_call/3, and handle_cast/2.

The Elixir use GenServer supplies these callbacks, so this template is for when you want to change the callbacks, but would like the stubs to get started without having to look them up in the documentation.

defmodule MyNamespace.MyModule do
  @moduledoc false

  use GenServer

  def start_link(state, opts) do
    GenServer.start_link(__MODULE__, state, opts)
  end

  def init(_opts) do
    {:ok, %{}}
  end

  def handle_call(_msg, _from, state) do
    {:reply, :ok, state}
  end

  def handle_cast(_msg, state) do
    {:noreply, state}
  end
end

Elixir GenEvent

An underscored file will be created in an underscored directory lib/my_namespace/my_module.ex) with the given module name with be created. The minimal callback implementations for init/1, handle_event/2, and handle_call/2, handle_info/2.

The Elixir use GenEvent supplies these callbacks, so this template is for when you want to change the callbacks, but would like the stubs to get started without having to look them up in the documentation.

defmodule MyNamespace.MyModule do
  @moduledoc false

  use GenEvent

  # Callbacks

  def init(_opts) do
    {:ok, %{}}
  end

  def handle_event(_msg, state) do
    {:ok, state}
  end

  def handle_call(_msg, state) do
    {:ok, :ok, state}
  end

  def handle_info(_msg, state) do
    {:ok, state}
  end
end

Syntax Highlighting and Semantic Annotation

Syntax highlighting of lexer tokens and semantic annotating of parser elements can be customized in in the Color Settings page for Elixir (Preferences > Editor > Color & Fonts > Elixir).

Text Attribute Key Display Name			Tokens/Elements	Scheme
Text Attribute Key Display Name			Tokens/Elements	Default	Darcula
Alias			`String`
Atom			`:one` `<<>>:`
Braces and Operators	Bit		`<<` `>>`
Braces and Operators	Braces		`{` `}`
Braces and Operators	Brackets		`[` `]`
Braces and Operators	Character Token		`?`
Braces and Operators	Comma		`,`
Braces and Operators	Dot		`.`
Braces and Operators	Interpolation		`#{` `}`
Braces and Operators	Maps and Structs	Maps	`%{` `}`
Braces and Operators	Maps and Structs	Maps	`%` `{` `}`
Braces and Operators	Operation Sign		`=` `+` `*` `==` `!` `&&` `\|\|` `\|>` `^`
Braces and Operators	Parentheses		`(` `)`
Braces and Operators	Semicolon		`;`
Calls	Function		`inspect`	*Only the Italic attribute	*Only the Italic attribute
Calls	Macro		`inspect`	*Only the Bold and Italic attributes	*Only the Bold and Italic attributes
Calls	Predefined		`Kernel` functions macros `Kernel.SpecialForms` macros	*Only the Foreground attribute	*Only the Foreground attribute
Comment			`# Numbers`
Keywords			`end`
Module Attributes			`@custom_attr`
Module Attributes	Documentation		`@doc`
Module Attributes	Documentation	Text	`Simple module docstring`
Module Attributes	Types	Callback	`func`
Module Attributes	Types	Specification	`func`
Module Attributes	Types	Type	`parameterized`
Module Attributes	Types	Type Parameter	`type_parameter`
Numbers	Base Prefix	Non-Decimal	`0b` `0x` `0o`
Numbers	Base Prefix	Obsolete Non-Decimal	`0B` `0X`
Numbers	Decimal Exponent, Mark, and Separator		`e` `.` `_`
Numbers	Digits	Invalid	`2` `o` `r` `888`
Numbers	Digits	Valid	`1234` `1A` `beef` `123`
Textual	Character List		`'This is a list'`
Textual	Escape Sequence		`\x{12}`
Textual	Sigil		`~r//` `~R''` `~w()` `~W()`
Textual	String		`"Hello world"`
Variables	Ignored		`_`
Variables	Parameter		`a` `b`
Variables	Variable		`pid`

Grammar parsing

Built on top of highlighted tokens above, the parser understands the following parts of Elixir grammar as valid or allows the grammar because they contain correctable errors:

Empty Parentheses (())
Keyword Lists
- Keyword Keys - Aliases, identifiers, quotes, or operators when followed immediately by a colon and horizontal or vertical space.
- Keyword Values - Empty parentheses (()) and matched expressions.
Matched Expressions, in other words, unary and binary operations on variable, function, and macro names and values (numbers, strings, char lists, sigils, heredocs, true, false, and nil).
No Parentheses expressions, which are function calls with neither parentheses nor do blocks that have either (1) a positional argument and keyword arguments OR (2) two or more positional arguments with optional keyword arguments.
Anonymous function calls .() with either no arguments; a no parentheses arguments expression as an argument; keywords as an argument; positional argument(s); or positional arguments followed by keywords as arguments.
Remote function calls (Alias.function, :atom.function, etc) and local function calls (function) with...
- No Parentheses with...
  - No Arguments (Alias.function)
  - Keywords (Alias.function key: value)
  - Nested No Parentheses Call (Alias.function Inner.function positional, key: value)
  - Positional and Keyword arguments (Alias.function positional, key: value)
  - Matched Expression (Alias.function 1 + 2)
- Parentheses with...
  - No arguments (Alias.function())
  - No Parentheses Call (Alias.function(Inner.function positional, key: value)
  - Keywords (Alias.function(key: value))
  - Positional and Keyword arguments (Alias.function(positional, key: value))
  - Trailing parentheses for quoting (def unquote(variable)(positional))
Bracket expression (variable[key])
Block expressions (function do end)
Unmatched expressions, in other words combinations of block expressions and matched expressions.

Inspections

Inspections mark sections of code with warnings and errors. They can be customized from the Preferences > Inspections > Elixir.

Elixir Inspections

Ambiguous nested calls

Detects when compiler will throw unexpected comma. Parentheses are required to solve ambiguity in nested calls. Function calls with multiple arguments without parentheses cannot take as arguments functions with multiple arguments without parentheses because which functional gets which arguments is unclear as in the following example:

outer_function first_outer_argument,
               # second argument is another function call without parentheses, but with multiple arguments
               inner_function first_inner_argument,
               ambiguous_keyword_key: ambiguous_keyword_value

To fix the ambiguity if first_inner_keyword_key: first_inner_keyword_value should be associated, add parentheses around the inner function's arguments:

# keywords are for inner function
outer_function first_outer_argument
               inner_function(
                 first_inner_argument
                 ambiguous_keyword_key: ambiguous_keyword_value
               )

# keywords are for outer function
outer_function first_outer_argument
               inner_function(
                 first_inner_argument
               ),
               ambiguous_keyword_key: ambiguous_keyword_value

Preferences > Inspections > Elixir > Ambiguous nested calls Ambiguous nested calls error

Ambiguous nested call inspection marks the error on the comma that causes the ambiguity. Ambiguous nested calls inspection

Mousing over the comma marked as an error in red (or over the red square in the right gutter) will show the inspection describing the error.

Ambiguous parentheses

Detects when compiler will throw unexpected parenthesis. If you are making a function call, do not insert spaces in between the function name and the opening parentheses. Function calls with space between the function name and the parentheses cannot distinguish between function calls with parentheses, but with an accidental space before the ( and function calls without parentheses where the first positional argument is in parentheses.

Empty Parentheses

function ()

To fix the ambiguity remove the space or add outer parentheses without the space if the first argument should be ():

# extra space, no arguments to function
function()

# first argument is `()`
function(())

Keywords in Parentheses

function (key: value)

Keywords inside parentheses is not valid, so the only way to fix this is to remove the space

function(key: value)

Positional arguments in Parentheses

function (first_positional, second_positional)

A list of positional arguments in parenthenses is not valid, so the only way to fix this is to remove the space

function(first_positional, second_positional)

Preferences > Inspections > Elixir > Ambiguous parentheses Ambiguous parentheses error

Ambiguous parentheses inspection marks the error on the parenthetical group surrounded by the parentheses that are ambiguous due to the preceding space.

Mousing over the parenthetical group marked as an error in red (or over the red square in the right gutter) will show the inspection describing the error.

Keyword pair colon (`:`) used in type spec instead of type operator (`::`)

Type specifications separate the name from the definition using ::.

@type name: definition

Replace the : with ::

@type name :: definition

Keywords appear before the end of list.

one.(
  one,
  two positional, key: value,
  three
)

Keywords can only appear at the end of an argument list, so either surround the no parentheses expression argument with parentheses, or move the the keywords to the end of the list if it wasn't meant to be a no parentheses expression.

one.(
  one
  two(positional, key: value),
  three
)

one.(
  one,
  two,
  three,
  key: value
)

Preferences > Inspections > Elixir > Keywords Not At End Keywords Not At End error

Keywords Not At End inspection marks the error over the keywords that need to be surrounded by parentheses or moved to the end of the list.

Mousing over the keywords marked as an error in red (or over the red square in the right gutter) will show the inspection describing the error.

Match operator (`=`) used in type spec instead of type operator (`::`)

Type specifications separate the name from the definition using ::.

@type name = definition

Replace the = with ::

@type name :: definition

Quick Fixes

Quick Fixes are actions IntelliJ can take to change your code to correct errors (accessed with Alt+Enter by default).

Convert `:` to `::` in type specs

If a type specification uses a single : instead of ::, then hit Alt+Enter on the : to change it to :: and fix the type spec.

Convert `=` to `::` in type specs

If a type specification uses = instead of ::, then hit Alt+Enter on the = to change it to :: and fix the type spec.

Remove space in front of ambiguous parentheses

If a set of parentheses is marked as ambiguous then the space before it can be removed to disambiguate the parentheses with Alt+Enter. (Will vary based on keymap.)

Remove spaces before ambiguous parentheses

Hitting Alt+Enter on ambiguous parentheses error will bring up the Local Quick Fix, "Remove spaces between function name and parentheses". Hit Enter to accept and remove the space.

Code Folding

You can collapse (fold) pre-defined regions of your Elixir code to make it easier to quickly scroll through files or hide details you don't care about right now.

Controls

Collapsing

Position cursor between lines with with downward facing - arrow and upward facing - arrow.
Cmd+-

Expanding

Position cursor on the collapsed line with the square +
Cmd++

Regions

Expanded	Collapsed	Folded By Default?
`do end`	`do: ...`	No
`->` and right operand	`-> ...`	No
`@doc VALUE`	`@doc "..."`	No
`@moduledoc VALUE`	`@moduledoc "..."`	No
`@typedoc VALUE`	`@typedoc "..."`	No
alias ALIAS1 alias ALIAS1	`alias ...`	Yes
import ALIAS1 import ALIAS2	`import ...`	Yes
require ALIAS1 require ALIAS2	`require ...`	Yes
use ALIAS1 use ALIAS2	`use ALIAS1`	Yes
`@for`	`FOR` in `defimpl PROTOCOL, for: FOR`	Yes
`@protocol`	`PROTOCOL` in `defimpl PROTOCOL, for: FOR`	Yes
@MODULE_ATTRIBUTE	VALUE in `@MODULE_ATTRIBUTE VALUE`	No

Commenter

You can comment or uncomment the current line or selected block of source. By selecting a block of source first you can quickly comment out and entire function if you're trying to track down a compiling or testing error that's not giving a helpful line number.

Using the menus

Highlight one or more lines
Comment (or Uncomment) with one of the following: a. Code > Comment with Line Comment b. On OSX the key binding is normally Cmd+/.

Credo

Inspection

Batch Mode

If you'd like to run mix credo use can run it as a global Inspection.

Analyze > Run Inspection By Name... (⌥⇧⌘I)
Type "Credo"
Select "Credo" from the shortened list
Hit Enter.

You'll be presented with a "Run 'Credo'" dialog

Run 'Credo'

Change the "Inspection scope" from "Whole project", which would include the deps to "Custom scope"
Select "Project Production Files" from the "Custom scope" dropdown
Click "OK"

The Inspections Result Tool Pane will open and show results as each file is processed.

Click the ▶ to expand the Credo section to show all warnings
Click an entry for the details of an individual warning with a code highlighting.

The view will show the parts of the file that aren't annotated as collapsed with the discontinuous line number indicating the jumps.

If you click on + collapse markers, you can expand the collapsed sections to see the full context

Or you can hover over the collapsed section to see a tooltip preview of the expansion

Configuration

Preferences > Editor > Inspections	Preferences > Editor > Inspections > Credo	Editor					Inspections
Elixir > Credo	Include Explanation	Highlight	Message	Explanation in tooltip	`mix credo` Runs		Highlight	Message	`mix credo` Runs	Action
Elixir > Credo	Include Explanation	Highlight	Message	Explanation in tooltip	Per File	Per Issue	Highlight	Message	Working Directory	Inspect Code	Run Inspection By Name
☑	☑	Yes	Yes	Yes	1	1	Yes	Yes	1	Yes	Yes
☑	☐	Yes	Yes	No	1	0	Yes	Yes	1	Yes	Yes
☐	ⁿ/ₐ	No	No	No	0	0	Yes	Yes	1	No	Yes

Annotator

If you want to limit the performance impact of the credo annotator because mix credo spikes your CPU, you can limit the number of mix credo runs to 1 per open file by disabling the Explanation tooltip

Disable Explanation

Preferences > Editor > Inspections > Credo
Uncheck "Include Explanation"

Disable inspection

If you don't want the annotator to run at all on open editors, then you can disable the paired inspection

Preferences > Editor > Inspections
Uncheck Elixir > Credo

Once the annotator is disabled, you can still run the inspection in batch mode

Debugger

IntelliJ Elixir allows for graphical debugging of *.ex files using line breakpoints.

Line breakpoints can added by clicking in the left-hand gutter of an editor tab. A red dot will appear marking the breakpoint. When a Run Configuration is Run with the Debug (bug) instead of Run (arrow) button, execution will stop at the breakpoint and you can view the local variables (with Erlang names) and the stackframes.

Steps

Define a run/debug configuration
Create breakpoints in the *.ex files
Launch a debugging session
During the debugger session, step through the breakpoints, examine suspended program, explore frames, and evaluate code when suspended.

Basics

After you have configured a run configuration for your project, you can launch it in debug mode by pressing Ctrl+D.

Keyboard Shortcuts

Action	Keyword Shortcut
Toggle Breakpoint	`Cmd+F8`
Resume Program	`Alt+Cmd+R`
Step Over	`F8`
Step Into	`F7`
View breakpoint details/all breakpoints	`Shift+Cmd+F8`

Excluding Modules

By default, the debugger will scan all the load paths and build path for .beam files and the corresponding modules will be interpreted which causes the Module's Erlang abstract code chunk to be interpreted in Erlang instead of the bytecode chunk being executed in the C parts of the BEAM. This interpretation is much slower than execution, so by default all of the Elixir standard library and the common modules installed in Phoenix projects are excluded from being interpreted when the debugger starts. The modules can be still be stepped into or have breakpoints explicitly set.

Preferences > Build, Execution, Deployment > Debugger > Stepping
Scroll to Elixir

Do Not Step Into The Modules

You can customize these module patterns as an application setting.

Disabling Existing Module Patterns

Preferences > Build, Execution, Deployment > Debugger > Stepping
Scroll to Elixir
Click the Checkbox next to the pattern you want to disable
Click Apply to save or OK to save and close Preferences

Disable

Editing Existing Module Patterns

Preferences > Build, Execution, Deployment > Debugger > Stepping
Scroll to Elixir
Click the pattern text box
Click Apply to save or OK to save and close Preferences

Edit

Removing Existing Module Patterns

Preferences > Build, Execution, Deployment > Debugger > Stepping
Scroll to Elixir
Click the row of the pattern you want to remove
Click the "-" Remove button.
Click Apply to save or OK to save and close Preferences

Remove

Removed

Adding New Module Patterns

Preferences > Build, Execution, Deployment > Debugger > Stepping
Scroll to Elixir
Click the "+" Add button
Click the default "*" pattern to edit it
Click Apply to save or OK to save and close Preferences

Add

Added

Environment Variables

If you want to customize the modules to ignore on a per-Run-Configuration basis, you can set an environment variable in the Run Configuration.

Variable	Example	Description
INTELLIJ_ELIXIR_DEBUG_BLACKLIST	iconv,some	Excluding modules from debugger

Notice: If you want non Elixir. module in blacklist, write it with: :. This rule applies only to module atoms.

Breakpoints

When a breakpoint is set, the editor displays a breakpoint icon in the gutter area to the left of the affected source code. A breakpoint icon denotes status of a breakpoint, and provides useful information about its type, location, and action.

The icons serve as convenient shortcuts for managing breakpoints. Clicking an icon removes the breakpoint. Successive use of Alt - click on an icon toggles its state between enabled and disabled. The settings of a breakpoint are shown in a tooltip when a mouse pointer hovers over a breakpoint icon in the gutter area of the editor.

Status	Icon	Description
Enabled		Indicates the debugger will stop at this line when the breakpoint is hit.
Disabled		Indicates that nothing happens when the breakpoint is hit.
Conditionally Disabled		This state is assigned to breakpoints when they depend on another breakpoint to be activated.

When the button Red dot surrounded by crossed-out circle is pressed in the toolbar of the Debug tool window, all the breakpoints in a project are muted, and their icons become grey: Grey dot .

Accessing Breakpoint Properties

Viewing all breakpoints

To view the list of all breakpoints and their properties, do one of the following:

Run > View Breakpoints
Shift+Cmd+F8
Click the
Breakpoints are visible in the Favorites tool window.

Viewing a single breakpoint

To view properties of a single breakpoint

Right-Click a breakpoint icon in the left gutter of the editor.

Configuring Breakpoints

To configure actions, suspend policy and dependencies of a breakpoint

Open the Breakpoint Properties
- Right-click a breakpoint in the left gutter, then click the More link or press Shift+Cmd+F8
- Open the Breakpoints dialog box and select the breakpoint from the list
- In the Favorites tool window, select the desired breakpoint, and click the pencil icon.
Define the actions to be performed by IntelliJ IDEA on hitting breakpoint:
- To notify about the reaching of a breakpoint with a text message in the debugging console, check the "Log message to console" check box. A message of the format *DBG* 'Elixir.IntellijElixir.DebugServer' got cast {breakpoint_reached, PID} will appear in the console.
- To set a breakpoint the current one depends on, select it from the "Disabled until selected breakpoint hit" drop-down list. Once dependency has been set, the current breakpoint is disabled until selected one is hit.
  - Choose the "Disable again" radio button to disable the current breakpoint after selected breakpoint was hit.
  - Choose the "Leave enabled" radio button to keep the current breakpoint enabled after selected breakpoint was hit.
- Enable suspending an application upon reaching a breakpoint by checking the "Suspend" check box.

Creating Line Breakpoints

A line breakpoint is a breakpoint assigned to a specific line in the source code.

Line breakpoints can be set on executable lines. Comments, declarations and empty lines are not valid locations for the line breakpoints. Line break points can be set in .ex and .eex files.

.eex line breaks will only work on Elixir code that is used in Phoenix view modules.

eex

.eex breakpoints only work if a .beam file using the template's relative can be found. This means that the Phoenix view module .beam file must exist in _build prior to setting a breakpoint. Run the Run Configuration once, before debugging to complete the build if setting a breakpoint does not work.

Place the caret on the desired line of the source code.
Do one of the following:
- Click the left gutter area at a line where you want to toggle a breakpoint
- Run > Toggle Line Breakpoint
- Cmd+F8

Describing Line Breakpoints

Open the Breakpoints dialog
Right-click the breakpoint you want to describe
Select "Edit description" from the context menu
In the "Edit Description" dialog box, type the desired description.

Searching for Line Breakpoints

Open the Breakpoints dialog
Start typing the description of the desired breakpoint

Jump to Breakpoint Source

To view the selected breakpoint without closing the dialog box, use the preview pane.
To open the file with the selected breakpoint for editing, double-click the desired breakpoint.
To close Breakpoints dialog, press Cmd+Down. The caret will be placed at the line marked with the breakpoint in question.

Disabling Line Breakpoints

When you temporarily disable or enable a breakpoint, its icon changes from Enabled breakpoint icon to Disabled breakpoint icon and vice versa.

Place the caret at the desired line with a breakpoint.
Do one of the following:
- Run > Toggle Breakpoint Enable
- Right-click the desired breakpoint icon, select or deselect the enabled check box, and then click Done.
- Alt-click the breakpoint icon

Deleting Line Breakpoints

Do one of the following:

In the Breakpoints dialog box, select the desired line breakpoint, and click the red minus sign.
In the editor, locate the line with the line breakpoint to be deleted, and click its icon in the left gutter.
Place caret on the desired line and press Cmd+F8.

Starting the Debugger Session

Select the run/debug configuration to execute
Do one of the following
- Click on the toolbar
- Run > Debug
- Ctrl+D

Debug quick menu

Ctrl+Alt+D
Select the configuration from the pop-up menu
Hit Enter

It takes awhile, once the debugged process is started to configure the debugger in BEAM. To ensure that breakpoints are setup before allow the debugged code to run, the debugger blocks until setup is complete.

The debugged process will wait for the debugger to attach
Breakpoints will be set
The debugger will mark modules to be interpreted
1. The code paths will be scanned for .beam files
  - Code paths from the Elixir SDK will be skipped
  - .beam files will be interpreted unless they match the Module Filter Pattern
The debugger attaches (so it can receive breakpoint events) and allows the debugged process to continue.

Examining Suspended Program

Processes

The "Thread" drop-down lists the current processes in the local node. Only the current process is suspended. The rest of the processes are still running.

Frames

The Frames for the current process can be navigated up and down using the arrow keys or clicking on the frame.

Press Up or Down to change frames
Click the stack_frame from the list

Jump to Current Execution Point

When changing frames or jumping to definitions, you can lose track of where the debugger is paused. To get back to the current execution point, do one of the following:

Run > Show Execution Point.
Alt+F10
Click on the stepping toolbar of the Debug tool window.

Variables

Binaries show each byte at the byte's offset.

Bitstrings show each byte with any partial byte annotated with its bitwidth.

Boolean variables are rendered as their value.

Charlists show the integer values because they're treated as lists

Functions don't have literal representation, so the inspect form starting with #Fun<...> is shown

Lists render differently based on whether the list is improper or not. Improper lists show the head and tail while proper lists show their element by offset.

Maps render differently based on the key type. If the map uses all atom keys, the key will equal the value in the nested children while non-atom keys are shown as entries at a specific offset with the key and value. This is done, so that complex keys that have subterms can be expanded or collapsed, which is not possible for the simpler atom rendering.

Floats and integers are rendered as literals.

Pids are broken up into their hidden node, id, and serial`.

Strings show their literal value and unicode is fully supported.

Tuples show their elements at their offsets.

While Elixir allows rebinding variable names, Erlang does not, so when viewed in the Variables pane, rebound variables will have an @VERSION after their name indicating which rebinding of a the variable is.

Evaluate

When stopped at a breakpoint, you can use the Evaluate button (it looks like a simple pocket calculator) to open an editor to type code to be executed in the current stack frame.

The evaluator supports the full syntax.

The result of evaluating the code with be shown as the value of result below the entered "Expression".

Errors in the code will report back as a result tuple with an :EXIT tag. This reflects that the error has crashed the process that was evaluating the code. Thankfully, due to how how the interpreter is written, this does not lose the current stack frame and stepping or other evaluation can continue.

Stepping

Action	Shortcut	Description
Show Execution Point	`Alt+F10`	Click this button to highlight the current execution point in the editor and show the corresponding stack frame in the Frames pane.
Step Over	`F8`	Click this button to execute the program until the next line in the current function or file, skipping the function referenced at the current execution point (if any). If the current line is the last one in the function, execution steps to the line executed right after this function.
Step Into	`F7`	Click this button to have the debugger step into the function called at the current execution point.
Step Out	`Shift+F8`	Click this button to have the debugger step out of the current function, to the line executed right after it.

Delimiters

Auto-inserting

The right-delimiter will be automatically inserted when the left delimiter is typed. In some cases, to prevent false positives, the the delimiter is only completed if when used for sigils.

Preceded By	Left	Right
	`do`	`end`
	`fn`	`end`
	`[`	`]`
	`{`	`}`
	`(`	`)`
	`'`	`'`
	`'''`	`'''`
	`"`	`"`
	`"""`	`"""`
	`<<`	`>>`
`~<sigil-name>`	`<`	`>`
`~<sigil-name>`	`/`	`/`
`~<sigil-name>`	`\|`	`\|`

Matching

All delimiters that are auto-inserted are also matched for highlighting

Left	Right
`do`	`end`
`fn`	`end`
`[`	`]`
`{`	`}`
`(`	`)`
`'`	`'`
`'''`	`'''`
`"`	`"`
`"""`	`"""`
`<<`	`>>`
`<`	`>`
`/`	`/`
`\|`	`\|`

Dialyzer

Inspection

Batch Mode

Analyze > Run Inspection by Name... (⌥⇧⌘I)
Type "Dialyzer"
Select "Dialyzer based inspections (Elixir)" from the shortened list
Hit Enter.

You'll be presented with a "Run 'Dialyzer based inspections (Elixir)'" dialog

Run 'Dialyzer based inspections (Elixir)'

Change the scope if you want.
Click "OK"

The Inspections Result Tool Pane will open and show results as each file is processed.

Click the ▶ to expand the Credo section to show all warnings
Click an entry for the details of an individual warning with a code highlighting.

Embedded Elixir (EEx) Templates

Any file with .eex as the final extension will be treated as Embedded Elixir (EEx) templates. To determine the Template Data Language, the .eex extension will be stripped and any remaining extension will be looked up to get the File Type and its associated Language. For example, *.txt.eex will be EEx with Plain Text (.txt) as the Data Template Language. Likewise, *.html.eex will be EEx with HTML as the Data Template Language. There's no need to register *.txt.eex or *.html.eex or any other *.DATA_TEMPLATE_LANGUAGE_EXTENSION.eex pattern explicitly: the nested extension will be looked up using the normal extension setup.

Form Template

Parameter Usage in Form Template

Advanced configuration

If you need more file-by-file configuration of the Template Data Language than can be achieved with a file extension/pattern, IntelliJ IDEA (Community or Ultimate Edition) has support for setting the Template Data Language on a specific path.

Preferences > Languages and Frameworks > Template Data Languages

See JetBrains Documentation for more details.

Live Embedded Elixir (LEEx) Templates

Any file with .leex as the final extension will be treated as Live Embedded Elixir (LEEx) templates. To determine the Template Data Language, the .leex extension will be stripped and any remaining extension will be looked up to get the File Type and its associated Language. For example, *.txt.leex will be EEx with Plain Text (.txt) as the Data Template Language. Likewise, *.html.leex will be EEx with HTML as the Data Template Language. There's no need to register *.txt.leex or *.html.leex or any other *.DATA_TEMPLATE_LANGUAGE_EXTENSION.leex pattern explicitly: the nested extension will be looked up using the normal extension setup.

Index

Advanced configuration

Preferences > Languages and Frameworks > Template Data Languages

See JetBrains Documentation for more details.

HEEx Templates

Any file with .heex as the final extension will be treated as HEEx - Phoenix LiveView's HTML-aware, component-friendly template language. Unlike EEx/LEEx, the Template Data Language is always HTML; it isn't guessed from the rest of the file name, since HEEx's own compiler (Phoenix.LiveView.HTMLEngine) always renders to HTML.

~H sigils in .ex files use the same HEEx language, with separate HTML and Elixir PSI for the sigil's contents, once enabled - see ~H Sigil HEEx Language Injection Support below.

<.component> and <Module.component> tags navigate (Go To Declaration) to the def/defp that defines them, whether the component is defined in the same view module, brought in with an explicit import, or brought in via use MyAppWeb, :html (including a use nested inside it, such as use Phoenix.Component). Find Usages and Rename on the def/defp include its tags, Rename also works with the caret on the tag, and Quick Docs on a tag shows the function's documentation. All of this applies in .heex files and inside ~H sigils. A dotted name that is not valid component syntax is flagged the same way an unknown HTML tag is.

HEEx's special attributes (:let, :if, :for, :key, :type) and phx-* bindings are recognized on HTML tags, and <:slot> tags are not validated as HTML elements.

Building/Compiling

Settings

Build, Execution, Deployment > Compiler > Elixir Compiler

Compile project with mix (use mix compile instead of elixirc directly)
Attach docs (don't use --no-docs elixirc flag)
Attach debug info (don't use --no-debug-info elixirc flag)
Warnings as errors (use --warnings-as-errors elixirc flag)
Ignore module conflict (use --ignore-module-conflict elixirc flag)

Build Messages

Source

If a file has errors and warnings, they are group together in Build Messages under that file.

Errors and Warnings

Jump To Source

You can jump to errors and warnings in the Build Messages

Highlight the error or warning you want to jump to source
Do one of the following
1. Right-Click the error or warning
2. Select Jump to Source from the context menu
OR
1. Click the error or warning
2. Press Cmd+Down

You can also turn on Autoscroll to Source, which will Jump To Source whenever you Click or select an error or warning.

Autoscroll to Source

Warnings as Errors

Setting

If you enable Warnings as Errors in the settings, then the Warnings will be treated as Errors by elixirc and mix and the Build Messages will show the Warnings as Errors.

Messages

If only warnings remain in the source.

Source

With Warnings as Errors On, all the Warnings will appear as Errors and still fail the build

Errors

With Warnings as Errors Off, the Warnings will appear as Warnings and the build will succeed

Warnings

Individual File

Have a file selected in Project view with the Project view in focus OR have an Editor tab in focus
Build > Compile 'FILE_NAME'
Build results will be shown
- If compilation is successful, you'll see "Compilation completed successfully" in the Event Log
- If compilation had errors, you'll see "Compilation completed with N errors and M warnings" in the Event Log and the Messages Compile tab will open showing a list of Errors

Project

Build > Build Project
Build results will be shown
- If compilation is successful, you'll see "Compilation completed successfully" in the Event Log
- If compilation had errors, you'll see "Compilation completed with N errors and M warnings" in the Event Log and the Messages Compile tab will open showing a list of Errors

Live Templates

Live Templates are snippets of code that can be inserted quickly and have placeholder locations that the cursor will automatically jump to when using the template. Whenever you start typing, Live Templates will start matching against the shortcuts. A template can be selected with Tab.

Live Templates can be customized in Preferences > Editor > Live Templates > Elixir.

Metasyntactic variables are locations where the cursor will jump to. END is the final location of the cursor.

Shortcut	Code
`@doc`	`@doc """ ONE """ END`
`case`	`case ONE do TWO -> END end`
`cond`	`cond do END end`
`def`	`def NAME do END end`
`def,`	`def NAME, do: END`
`defi`	`defimpl PROTOCOL, for: TYPE do END end`
`defm`	`defmodule ALIAS do END end`
`defmac`	`defmacro MACRO_NAME do END end`
`defmacp`	`defmacrop MACRO_NAME do END end`
`defover`	`defoverridable [NAME: END]`
`defp`	`defp NAME do END end`
`defpro`	`defprotocol PROTOCOL do END end`
`defs`	`defstruct [END]`
`do`	`do END end`
`doc`	`@doc """ ONE """ END`
`fn`	`fn ARGS -> END end`
`for`	`for A <- B do END end`
`if`	`if TRUE do END end`
`ife`	`if TRUE do OK else END end`
`ii`	`IO.inspect(END)`
`mdoc`	`@moduledoc """ ONE """ END`
`rec`	`receive do ONE -> END end`
`test`	`test "TESTDESC" do END end`
`try`	`try do ONE rescue TWO -> END`

Documentation

Editor

Documentation in @moduledoc, @typedoc or @doc module attribute values are marked as Markdown language, so that the JetBrains supplied Markdown support works in documentation.

Code Blocks

Code in code blocks (indented 4 spaces) are marked as Elixir language, so all the normal language support works in code examples and doctests.

This includes highlighting reads and writes of variables

and Go To Definition for calls

Toggling Editor to Rendered

Start with the Editor
Click the "Toggle Rendered View" button in the gutter next to the editor.
Rendered View will be shown

Rendered View

Markdown documentation in @moduledoc, @typedoc or @doc can be toggled back and forth from the editable Markdown view and the rendered HTML view.

Aliases link to Modules

In the rendered view, aliases are clickable and navigatable.

Clicking the links will show the documentation for module.

Using Go To Definition (Cmd+Click) on the link will take you to the module definition.

Toggling Rendered to Editor

Start with the Rendered View
Click the "Toggle Rendered View" button in the gutter next to the editor.
Editor will be shown

Quick Documentation

You can get documentation for functions and macros that have a @doc, aliases of modules that have a @moduledoc or types that have a @typedoc in a pop-up using Quick Documentation.

For a function

Place the cursor over the name of callback being referenced.
Display the documentation with either:
- A keyboard shortcut: F1 to show rendered @doc
- From the menu: View > Quick Documentation

For a function

Place the cursor over the name of function being called.
Display the documentation with either:
- A keyboard shortcut: F1 to show rendered @doc
- From the menu: View > Quick Documentation

For a module

Place the cursor on a fully-qualified module name
Display the documentation with either:
- A keyboard shortcut: F1 to show rendered @moduledoc
- From the menu: View > Quick Documentation

For a type

Place the cursor over the name of a type being used.
Display the documentation with either:
- A keyboard shortcut: F1 to show rendered @typedoc
- From the menu: View > Quick Documentation

For an Erlang module or function

Quick Documentation also works for Erlang modules and functions referenced via atom syntax (e.g. :math, :lists.any/2). The plugin reads documentation from the EEP-48 Docs chunk embedded in .beam files, or from external .chunk files at <app>/doc/chunks/<module>.chunk.

For this to work, your Erlang/OTP installation must have been built with documentation.

Checking if docs are available:

If hovering over :lists or :math shows "No Documentation found", your OTP was built without docs. Many mise/asdf/kerl installations omit docs by default.

Installing Erlang with documentation via mise:

KERL_BUILD_DOCS=yes MISE_ERLANG_COMPILE=true mise install erlang@X.Y.Z

Replace X.Y.Z with your desired OTP version (e.g. 27.3.3). The key variables are:

KERL_BUILD_DOCS=yes -- tells kerl to build documentation (including .chunk files)
MISE_ERLANG_COMPILE=true -- forces a source build (pre-built binaries may not include docs)

Installing Erlang with documentation via asdf:

KERL_BUILD_DOCS=yes asdf install erlang X.Y.Z

After reinstalling Erlang with docs, restart the IDE so it re-indexes the .beam files.

OTP 23 and earlier: You may need to add CFLAGS="-O2 -g -Wno-error=implicit-function-declaration" to the install command to avoid compilation errors on newer toolchains.

Run/Debug Configurations

Distillery Release CLI

Distillery's mix release produces a CLI for running the release.

Build the release: mix release

==> Release successfully built!
    You can run it in one of the following ways:
      Interactive: _build/ENV/rel/NAME/bin/NAME console
      Foreground: _build/ENV/rel/NAME/bin/NAME foreground
      Daemon: _build/ENV/rel/NAME/bin/NAME start

Run > Edit Configurations...
Click +
Select "Distillery Release CLI"
Fill in the "Release CLI Path" with the full path to the _build/ENV/rel/NAME/bin/NAME path produed by mix release above.
Fill in the "Release CLI arguments".
- console runs a shell with the release loaded similar to iex -S mix.
- foreground to runs the release without a shell, like mix or mix run. The available commands are controlled by your release config rel/config.exs that Distillery uses.
(Optionally) fill in "erl arguments" with arguments to erl before it runs elixir. This is the same as the ERL_OPTS environment variable supported by Distillery.
(Optionally) fill in "elixir -extra arguments" with arguments to pass to elixir before it run the release. This is the same as the EXTRA_OPTS environment variable supported by Distillery.
(Optionally) change the Code Loading Mode This is the same as the CODE_LOADING_MODE environment variable supported by Distillery.
- Use Default - use whatever is configured in rel/config.exs. Don't set CODE_LOADING_MODE environment variable.
- embedded - load all code immediately on boot. Set CODE_LOADING_MODE=embedded.
- interactive - load code on-demand as it is needed/referenced. Set CODE_LOADING_MODE=interactive.
(Optionally) set the "Log Directory" This is the same as the RUNNER_LOG_DIR environment variable supported by Distillery.
(Optionally) change "Replace OS Vars" This is the same as the REPLACE_OS_VARS environment variable supported by Distillery.
- Use Default - use whatever is configured in rel/config.exs. Don't set REPLACE_OS_VARS environment variable.
- false - don't replace "${A_VAR_NAME}" in the generated configuration with A_VAR environment variable at runtime. Set REPLACE_OS_VARS=false.
- true - replace "${A_VAR_NAME}" in the generated configuration with A_VAR environment variable at runtime. Set REPLACE_OS_VARS=true.
(Optionally) set "sys.config File" This is the same the SYS_CONFIG_PATH environment variable supported by Distillery.
(Optionally) set "Release Config Directory". This is the same as the RELEASE_CONFIG_DIR environment variable supported by Distillery.
(Optionally) set "Pipe directory". This is the same as the PIPE_DIR environment variable supported by Distillery.
(Optionally) set "Use Pseudo-terminal (PTY). If checked use PTY for interactive shells. Automatically on when "Release CLI Arguments" starts with one of the known interactive commands (attach, console, console_boot, console_clean, or remote_console).
Fill in the "Working directory.
- Type the absolute path to the directory.
- Select the path using directory picker by clicking the ... button
(Optionally) click the ... button on the "Environment variables" line to add environment variables.
Click "OK" to save the Run Configuration and close the dialog

Running

Click the Run Arrow in the Toolbar to run the _build/ENV/rel/NAME/bin/NAME
The Run pane will open
- If the either "Use Pseduo-terminal (PTY)" is checked of the "Release CLI Arguments" are known to need a PTY, an interactive shell will appear in the Run pane where you can enter iex commands.
- Otherwise, the output of running the command will be shown.

Debugging

(Optionally) before debugging, customize the modules that will be interpreted.
1. Run > Edit Configurations...
2. Click the "Interpreted Modules" tab next to default "Configuration" tab.
3. Enable/Disable "Inherit Application Module Filters". Will change the Module Filters show in the below "Do not interpreter modules matching patterns" list.
4. Uncheck any inherited module filters that you would rather be interpreted and therefore debuggable
5. Click + to add module filters that are specific to this configuration. This can be useful if you know interpreting a specific module in your project's dependencies or project leads to too much slowdown when debugging or causes the debugger to hang/crash.
6. Click - to remove configuration-specific module filters added with +. Inherited module filters cannot be removed with -, they can only be disabled by unchecking.

Add the :debugger application to your release

Open rel/config.exs

In the release NAME block, in the set :applications block add :debugger:

--- a/rel/config.exs
+++ b/rel/config.exs
@@ -41,6 +41,8 @@ end
 release :intellij_elixir do
   set version: current_version(:intellij_elixir)
   set applications: [
+    # needed for IntelliJ Elixir debugger
+    :debugger,
     :runtime_tools
   ]
 end

For how to use the debugger, including how to set breakpoints see the Debugger section.
Click the Debug bug in the Toolbar to debug the mix tests

Elixir

Although it is exceedingly rare, as most Elixir projects use mix, it is supported to run/debug elixir directly, such as when doing elixir script.exs.

Run > Edit Configurations...
Click +
Select "Elixir"
Fill in the "elixir arguments".
(Optionally) fill in "erl arguments" with arguments to erl before it runs elixir.
Fill in the "Working directory"
- Type the absolute path to the directory.
- Select the path using directory picker by clicking the ... button
(Optionally) click the ... button on the "Environment variables" line to add environment variables.
Click "OK" to save the Run Configuration and close the dialog

With the Run Configuration defined, you can either Run or Debug elixir

Running

Click the Run arrow in the Toolbar to run elixir.
The Run pane will open, showing the results of elixir.

Debugging

(Optionally) before debugging, customize the modules that will be interpreted.
1. Run > Edit Configurations...
2. Click the "Interpreted Modules" tab next to default "Configuration" tab.
3. Enable/Disable "Inherit Application Module Filters". Will change the Module Filters show in the below "Do not interpreter modules matching patterns" list.
4. Uncheck any inherited module filters that you would rather be interpreted and therefore debuggable
5. Click + to add module filters that are specific to this configuration. This can be useful if you know interpreting a specific module in your project's dependencies or project leads to too much slowdown when debugging or causes the debugger to hang/crash.
6. Click - to remove configuration-specific module filters added with +. Inherited module filters cannot be removed with -, they can only be disabled by unchecking.
For how to use the debugger, including how to set breakpoints see the Debugger section.
Click the Debug bug in the Toolbar to debug elixir

IEx (Interactive Elixir)

iex run configurations allow you to run iex with IntelliJ Elixir attached. It is most useful when debugging, but it also allows you save customizations in the configuration when it is more complicated than just iex.

Run > Edit Configurations...
Click +
Select "IEx"
(Optionally) fill in "iex arguments" with arguments to iex.
(Optionally) full in "erl arguments" with arguments to erl before it runs iex.
Fill in the "Working directory"
- Type the absolute path to the directory.
- Select the path using directory picker by clicking the ... button
(Optionally) click the ... button on the "Environment variables" line to add environment variables.
Click "OK" to save the Run Configuration and close the dialog

With the Run Configuration defined, you can either Run or Debug the iex configuration.

Running

Click the Run arrow in the Toolbar to run iex

Debugging

(Optionally) before debugging, customize the modules that will be interpreted.
1. Run > Edit Configurations...
2. Click the "Interpreted Modules" tab next to default "Configuration" tab.
3. Enable/Disable "Inherit Application Module Filters". Will change the Module Filters show in the below "Do not interpreter modules matching patterns" list.
4. Uncheck any inherited module filters that you would rather be interpreted and therefore debuggable
5. Click + to add module filters that are specific to this configuration. This can be useful if you know interpreting a specific module in your project's dependencies or project leads to too much slowdown when debugging or causes the debugger to hang/crash.
6. Click - to remove configuration-specific module filters added with +. Inherited module filters cannot be removed with -, they can only be disabled by unchecking.
For how to use the debugger, including how to set breakpoints see the Debugger section.
Click the Debug bug in the Toolbar to debug iex.

Mix Tasks

Much like rake tasks in Rubymine, this plugin can run mix tasks.

Run > Edit Configurations...
Click +
Select "Elixir Mix"
Fill in the "mix arguments" starting with the name of the mix task followed by any arguments to that task.
(Optionally) fill in "elixir arguments" with arguments to elixir before it runs mix.
(Optionally) fill in "erl arguments" with arguments to erl before it runs elixir.
Fill in the "Working directory"
- Type the absolute path to the directory.
- Select the path using directory picker by clicking the ... button
(Optionally) click the ... button on the "Environment variables" line to add environment variables.
Click "OK" to save the Run Configuration and close the dialog

With the Run Configuration defined, you can either Run or Debug the Mix Task

Running

Click the Run arrow in the Toolbar to run the mix task
The Run pane will open, showing the results of the mix task.
- If there is an error with a FILE:LINE stack stack_frame, it will be a clickable link that will take you to that location

Debugging

(Optionally) before debugging, customize the modules that will be interpreted.
1. Run > Edit Configurations...
2. Click the "Interpreted Modules" tab next to default "Configuration" tab.
3. Enable/Disable "Inherit Application Module Filters". Will change the Module Filters show in the below "Do not interpreter modules matching patterns" list.
4. Uncheck any inherited module filters that you would rather be interpreted and therefore debuggable
5. Click + to add module filters that are specific to this configuration. This can be useful if you know interpreting a specific module in your project's dependencies or project leads to too much slowdown when debugging or causes the debugger to hang/crash.
6. Click - to remove configuration-specific module filters added with +. Inherited module filters cannot be removed with -, they can only be disabled by unchecking.
For how to use the debugger, including how to set breakpoints see the Debugger section.
Click the Debug bug in the Toolbar to debug the mix task

IEx Mix

If you want to run iex in the context of the project, you need to run iex -S mix, but if you don't want to have to worry about forgetting whether it's -s or -S or if it is mix -S iex or iex -S mix, you can use an IEx Mix configuration.

Run > Edit Configurations...
Click +
Select "IEx Mix"
(Optionally) fill in "mix arguments", such as phx.server if you want to launch Phoenix inside of iex.
(Optionally) fill in "iex arguments" with arguments to iex before -S mix.
(Optionally) full in "erl arguments" with arguments to erl before it runs iex.
Fill in the "Working directory"
- Type the absolute path to the directory.
- Select the path using directory picker by clicking the ... button
(Optionally) click the ... button on the "Environment variables" line to add environment variables.
Click "OK" to save the Run Configuration and close the dialog

With the Run Configuration defined, you can either Run or Debug iex -S mix

Running

Click the Run Arrow in the Toolbar to run iex -S mix

Debugging

(Optionally) before debugging, customize the modules that will be interpreted.
1. Run > Edit Configurations...
2. Click the "Interpreted Modules" tab next to default "Configuration" tab.
3. Enable/Disable "Inherit Application Module Filters". Will change the Module Filters show in the below "Do not interpreter modules matching patterns" list.
4. Uncheck any inherited module filters that you would rather be interpreted and therefore debuggable
5. Click + to add module filters that are specific to this configuration. This can be useful if you know interpreting a specific module in your project's dependencies or project leads to too much slowdown when debugging or causes the debugger to hang/crash.
6. Click - to remove configuration-specific module filters added with +. Inherited module filters cannot be removed with -, they can only be disabled by unchecking.
For how to use the debugger, including how to set breakpoints see the Debugger section.
Click the Debug bug in the Toolbar to debug iex -S mix.

`mix espec`

The mix espec task gets a special type of Run Configuration, Elixir Mix Espec. Using this Run Configuration type instead, of the basic Elixir Mix Run Configuration will cause the IDE to attach a special formatter to mix espec, so that you get the standard graphical tree of Test Results.

The Run pane will show Test Results. If there is a compilation error before or during mix espec, it will be shown as a test failure. If the compilation failure is in a _spec.exs file can it can be inferred from the stacktrace, the compilation error will show up as a test failure in that specific module.

Using graphical formatter

If you override the default formatters you will need to add the following code to your spec_helper.exs.

If you override formatters similar to below

ESpec.configure fn(config) ->
  config.formatters ...

ESpec.configure fn(config) ->
  config.formatters [
      {ESpec.Formatters.Json, %{out_path: "results.json"}},
      {ESpec.Formatters.Html, %{out_path: "results.html"}},
      {ESpec.Formatters.Doc, %{details: true, out_path: "results.txt"}},
      {ESpec.Formatters.Doc, %{details: true, diff_enabled?: false, out_path: "results-no-diff.txt"}},
      {ESpec.CustomFormatter, %{a: 1, b: 2}},
    ]
end

Replace them with code that checks for the graphical formatter TeamCityESpecFormatter and uses only it when available.

ESpec.configure fn(config) ->
  config.formatters(if Code.ensure_loaded?(TeamCityESpecFormatter) do
    [{TeamCityESpecFormatter, %{}}]
  else
    ...
  end)
end

ESpec.configure fn(config) ->
  config.formatters(if Code.ensure_loaded?(TeamCityESpecFormatter) do
    [{TeamCityESpecFormatter, %{}}]
  else
    [
      {ESpec.Formatters.Json, %{out_path: "results.json"}},
      {ESpec.Formatters.Html, %{out_path: "results.html"}},
      {ESpec.Formatters.Doc, %{details: true, out_path: "results.txt"}},
      {ESpec.Formatters.Doc, %{details: true, diff_enabled?: false, out_path: "results-no-diff.txt"}},
      {ESpec.CustomFormatter, %{a: 1, b: 2}},
    ]
  end)
end

Creating `mix espce` Run Configurations Manually

Run > Edit Configurations...
Click +
Select "Elixir Mix ESpec"
Fill in the "mix espec arguments" with the argument(s) to pass to mix espec. Normally, this will be list of *_spec.exs files, relative to the "Working directory".

NOTE: Unlike mix test, mix espec does not support directories as arguments.
(Optionally) fill in "elixir arguments" with the arguments to elixir before it runs mix test.
(Optionally) fill in "erl arguments"with the arguments toerlbefore it runselixir`.
Fill in the "Working directory"
- Type the absolute path to the directory.
- Select the path using directory picker by clicking the ... button
(Optionally) click the ... button on the "Environment variables" line to add environment variables.
Click "OK" to save the Run Configuration and close the dialog

With the Run Configuration defined you can either Run or Debug the mix especs

Running

Click the Run arrow in the Toolbar to run the mix test task
The Run pane will open showing the Test Results

Debugging

(Optionally) before debugging, customize the modules that will be interpreted.
1. Run > Edit Configurations...
2. Click the "Interpreted Modules" tab next to default "Configuration" tab.
3. Enable/Disable "Inherit Application Module Filters". Will change the Module Filters show in the below "Do not interpreter modules matching patterns" list.
4. Uncheck any inherited module filters that you would rather be interpreted and therefore debuggable
5. Click + to add module filters that are specific to this configuration. This can be useful if you know interpreting a specific module in your project's dependencies or project leads to too much slowdown when debugging or causes the debugger to hang/crash.
6. Click - to remove configuration-specific module filters added with +. Inherited module filters cannot be removed with -, they can only be disabled by unchecking.
For how to use the debugger, including how to set breakpoints see the Debugger section.
Click the Debug bug in the Toolbar to debug the mix tests

While you can create Elixir Mix ESpec run configurations manually using the Run > Edit Configurations... menu, it is probably more convenient to use the context menu.

Creating `mix espec` Run Configurations from context

The context menu must know that the the directory, file, or line you are right-clicking is a test. It does this by checking if the current directory or an ancestor is marked as a Test Sources Root and contains or is a *_spec.exs file(s)

In the Project pane, ensure your OTP application's espec directory is marked as a Test Sources Root
Check if the espec directory is green. If it is, it is likely a Test Sources Root. This color may differ in different themes, so to be sure you can check the context menu
Right-click the test directory.
Hover over "Mark Directory As >"
- If "Unmark as Test Sources Root" is shown, then the directory is already configured correctly, and create from context will work.
- If "Test Sources Root" is shown, then the directory need to be configured by clicking that entry

Creating/Running `mix espec` Run Configurations from directory

Right-click the directory in the Project pane
Click "Run Mix ExUnit", which will both create the Run Configuration and Run it.
- If you want to only create the Run Configuration, select "Create Mix ESpec" instead

Alternatively, you can use keyboard shortcuts

Select the directory in the Project pane.
Ctrl+Shift+R will create the Run Configuration and Run it.

Creating/Running `mix espec` Run Configurations from file

Right-click the file in the Project pane
Click "Run Mix ESpec", which will both create the Run Configuration and Run it.
- If you want to only create the Run Configuration, select "Create Mix ESpec" instead

Alternatively, you can use keyboard shortcuts

Select the directory in the Project pane.
Ctrl+Shift+R will create the Run Configuration and Run it.

Finally, you can use the editor tabs

Right-click the editor tab for the test file you want to run
Click "Run Mix ESpec", which will both create the Run Configuration and Run it.
- If you want to only create the Run Configuration, select "Create Mix ESpec" instead

Creating/Running `mix espec` Run Configurations from line

If you want to be able to run a single test, you can create a Run Configuration for a line in that test

Right-click a line in the test file
Click "Run Mix ESpec", which will both create the Run Configuration and Run it.
- If you want to only create the Run Configuration, select "Create Mix ESpec" instead

Alternatively, you can use keyboard shortcuts

Place the cursor on the line you want to test
Ctrl+Shift+R will create the Run Configuration and Run it.

`mix test`

The mix test task gets a special type of Run Configuration, Elixir Mix ExUnit. Using this Run Configuration type instead, of the basic Elixir Mix Run Configuration will cause the IDE to attach a special formatter to mix test, so that you get the standard graphical tree of Test Results

The Run pane will show Test Results. If there is a compilation error before or during mix test, it will be shown as a test failure. If the compilation failure is in a _test.exs file can it can be inferred from the stacktrace, the compilation error will show up as a test failure in that specific module.

doctest names are rearranged to emphasize the function being tested: "test doc at MODULE.FUNCTION/ARITY (COUNT)" becomes "MODULE.FUNCTION/ARITY doc (COUNT)". If MODULE is the same as the test case without the Test suffix, then MODULE is stripped too and the test name becomes only FUNCTION/ARITY doc (COUNT).

Creating `mix test` Run Configurations Manually

Run > Edit Configurations...
Click +
Select "Elixir Mix ExUnit"
Fill in the "mix test arguments" with the argument(s) to pass to mix test. Normally, this will be a directory like test, relative to the "Working directory"
(Optionally) fill in "elixir arguments" with the arguments to elixir before it runs mix test.
(Optionally) fill in "erl arguments"with the arguments toerlbefore it runselixir`.
Fill in the "Working directory"
- Type the absolute path to the directory.
- Select the path using directory picker by clicking the ... button
(Optionally) click the ... button on the "Environment variables" line to add environment variables.
Click "OK" to save the Run Configuration and close the dialog

With the Run Configuration defined you can either Run or Debug the mix tests

Running

Click the Run arrow in the Toolbar to run the mix test task
The Run pane will open showing the Test Results

Debugging

(Optionally) before debugging, customize the modules that will be interpreted.
1. Run > Edit Configurations...
2. Click the "Interpreted Modules" tab next to default "Configuration" tab.
3. Enable/Disable "Inherit Application Module Filters". Will change the Module Filters show in the below "Do not interpreter modules matching patterns" list.
4. Uncheck any inherited module filters that you would rather be interpreted and therefore debuggable
5. Click + to add module filters that are specific to this configuration. This can be useful if you know interpreting a specific module in your project's dependencies or project leads to too much slowdown when debugging or causes the debugger to hang/crash.
6. Click - to remove configuration-specific module filters added with +. Inherited module filters cannot be removed with -, they can only be disabled by unchecking.
For how to use the debugger, including how to set breakpoints see the Debugger section.
Click the Debug bug in the Toolbar to debug the mix tests

While you can create Elixir Mix ExUnit run configurations manually using the Run > Edit Configurations... menu, it is probably more convenient to use the context menu.

Creating `mix test` Run Configurations from context

The context menu must know that the the directory, file, or line you are right-clicking is a test. It does this by checking if the current directory or an ancestor is marked as a Test Sources Root.

In the Project pane, ensure your OTP application's test directory is marked as a Test Sources Root
Check if the test directory is green. If it is, it is likely a Test Sources Root. This color may differ in different themes, so to be sure you can check the context menu
Right-click the test directory.
Hover over "Mark Directory As >"
- If "Unmark as Test Sources Root" is shown, then the directory is already configured correctly, and create from context will work.
- If "Test Sources Root" is shown, then the directory need to be configured by clicking that entry

Creating/Running `mix test` Run Configurations from directory

Right-click the directory in the Project pane
Click "Run Mix ExUnit", which will both create the Run Configuration and Run it.
- If you want to only create the Run Configuration, select "Create Mix ExUnit" instead

Alternatively, you can use keyboard shortcuts

Select the directory in the Project pane.
Ctrl+Shift+R will create the Run Configuration and Run it.

Creating/Running `mix test` Run Configurations from file

Right-click the file in the Project pane
Click "Run Mix ExUnit", which will both create the Run Configuration and Run it.
- If you want to only create the Run Configuration, select "Create Mix ExUnit" instead

Alternatively, you can use keyboard shortcuts

Select the directory in the Project pane.
Ctrl+Shift+R will create the Run Configuration and Run it.

Finally, you can use the editor tabs

Right-click the editor tab for the test file you want to run
Click "Run Mix ExUnit", which will both create the Run Configuration and Run it.
- If you want to only create the Run Configuration, select "Create Mix ExUnit" instead

Creating/Running `mix test` Run Configurations from line

If you want to be able to run a single test, you can create a Run Configuration for a line in that test

Right-click a line in the test file
Click "Run Mix ExUnit", which will both create the Run Configuration and Run it.
- If you want to only create the Run Configuration, select "Create Mix ExUnit" instead

Alternatively, you can use keyboard shortcuts

Place the cursor on the line you want to test
Ctrl+Shift+R will create the Run Configuration and Run it.

`.beam` Files

.beam files are the compiled version of modules on the BEAM virtual machine used by Elixir and Erlang. They are the equivalent of .class files in Java.

.beam files are not detected purely by their file extension: the BEAM file format starts with a magic number, FOR1, that is checked for before decompiling.

.beam files have 2 editors registered: decompiled Text and BEAM Chunks

.beam file Editor Tabs

Decompression

If the .beam module was compiled with the compressed compiler directive, which in Erlang looks like

-compile([compressed])

and in Elixir looks like

@compile [:compressed]

then the outer file format is GZip (which is detected by checking for the gzip magic number, 1f 8b, at the start of the file) and the .beam will be (stream) decompressed before the .beam header is checked and the chunks decoded.

BEAM Chunks

.beam files are composed of binary chunks. Each chunk is formatted

Offset	+0	+1	+2	+3
0	Name (ASCII Characters)
4	Length (`unsigned-big-integer`)
8+	Chunk-Specific

This format is generically referred to as Type-Length-Value

The BEAM Chunks editor tab is subdivided into further tabs, one for each chunk in the .beam file.

BEAM Chunks editor chunk tabs

The tabs are listed in the order that the chunks occur in the .beam file.

`Atom` / `AtU8`

The Atom chunk holds LATIN-1 encoded atoms while AtU8 chunk holds UTF-8 atoms. There will only be one of these atom-related chunks in any given .beam file. AtU8 is used in newer versions of OTP that support UTF-8 atoms. AtU8 was introduced in OTP 20.

Format

Offset	+0	+1
0	atom count (`unsigned-big-integer`)
4	length₁ (`unsigned-byte`)	bytes (for length₁)
4+length₁+...+length_n-1	length_n (`unsigned-byte`)	bytes (for length_n)

Tab

The Atom/AtU8 tab shows a table with the columns

Column	Description	Source
Index	1-based to match Erlang convention. In the `Code` chunk, `atom(0)` is reserved to always translate to `nil`	Derived
Byte Count	The byte count for the atom's bytes	Raw
Characters	From encoding the bytes as LATIN-1 for `Atom` chunk or UTF-8 for `AtU8` chunk	Derived

AtU8 Table

`Attr`

The Attr chunk holds the module attributes, but only those that are persisted. Erlang module attributes are persisted by default, but in Elixir module attributes need to be marked as persisted with Module.register_attribute/3

Format

The Attr chunk uses External Term Format (term_to_binary's output) to encode a proplist, which is similar to, but not quite the same an Elixir Keyword list

All modules will have a :vsn attribute that is either set explicitly or defaults to the MD5 of the module.

Tab

The Attr tab shows a table with the columns

Column	Description	Source
Key	Attribute name	Raw
Value	Attribute value. Note: The value always appears as a list as read from the binary format. I don't know why.	Raw

Attr Table

`CInf`

The CInf chunk is the Compilation Information for the Erlang or Erlang Core compiler. Even Elixir modules have it because Elixir code passes through this part of the Erlang Core compiler

Format

The CInf chunk uses External Term Format (term_to_binary's output) to encode a proplist, which is similar to, but not quite the same an Elixir Keyword list

Tab

The CInf tab shows a table with the columns

Column	Description	Source
Key	Option name	Raw
Value	Inspected value	Raw

CInf Table

`Code`

The Code chunk contains the byte code for the module.

Format

It is encoded in BEAM Compact Term Encoding, which differs from the binary format produced by term_to_binary.

Tab

The Code tab shows a read-only editor with one byte code operation on each line. For ease of reading, operations are grouped by function and then label block with indentation indicating scope.

Code Chunk Read-Only Editor

By default as many references to other chunks and references to other parts of Code chunk are inlined to ease understanding. If you want to see the raw byte code operations, you can turn off the various inliners.

####### Controls

Control	On	Off
Inline Atoms	`atom(0)` is inlined as `nil`	`atom(N)` if "Inline Integers" is Off
Inline Atoms	`atom(n)` looks up index `n` in `Atom`/`AtU8` chunk and inlines its `inspect`ed version	`N` if "Inline Integers" is On and the argument supports "Inline Integers"
Inline Functions	`literal(n)` looks up index `n` in `FunT` chunk and inlines the name if the argument supports "Inline Functions"	`literal(n)` if "Inline Integers" is Off
Inline Functions		`n` if "Inline Integers" is On and the argument supports "Inline Integers"
Inline Imports	`literal(n)` looks up index `n` in `ImpT` and inlines it as a function reference: `&module.name/arity` if argument supports "Inline Functions"	`literal(n)` if "Inline Integers" Is Off
Inline Imports		`n` if "Inline Integers" is On and the argument supports "Inline Integers"
Inline Integers	`atom(n)` and `literal(n)` inline as `n` if argument supports "Inline Integers"	`atom(n)`, `integer(n)`, and `literal(n)`
Inline Integers	`integer(n)` inlines as `n`	`atom(n)`, `integer(n)`, and `literal(n)`
Inline Labels	`label(n)` inlines as `n` if argument supports "Inline Labels"	`label(n)`
Inline Lines	`line(literal(n))` looks up index `n` in the "Line Reference" table in the `Lines` chunk. The Line Reference contains a file name index and line. The file name index is looked up in the "File Name" table in the `Lines` chunk. The line from the Line Reference and the File name from the "File Name" table are inlined as `line(file_name: file_name, line: line)`.	`line` operations are left as is
Inline Literals	`literal(n)` looks up index `n` in `LitT` chunk and inlines its `inspect`ed version if the argument supports "Inline Literals"	`literal(n)`
Inline Local Calls	`label(n)` finds `label(n)` in `Code` chunk, then searches back for the previous `func_info` operation, then inlines it as a function reference: `&module.name/arity` if argument supports "Inline Local Calls"	`label(n)`
Inline Strings	Looks up `bit_length` and `byte_offset` into `StrT` chunk as their CharList value if supported by operation as value to `string` argument name	`bit_length` and `byte_offset`arguments are left as is
Show Argument Names	Adds keyword argument names before each argument value	Leaves values as positional arguments

If any of the inliners are incorrect or you have an argument name that makes more sense, please open an issue.

`Dbgi`

The Dbgi chunk contains Debug Info. It was introduced in OTP 20 as a replacement for the Abst chunk. While the Abst chunk was required to contain the Erlang AST, the Dbgi format can contain the debug info for other languages, such as Elixir quoted form AST.

Format

Because the format is language neutral, the format is a set of nested, versioned formats. The outer most layer is

{:debug_info_v1, backend, metadata | :none}

For :debug_info_v1, Elixir's backend is :elixir_erl. The metadata for :elixir_erl is further versioned: {:elixir_v1, map, specs}.

map contains the bulk of the data.

Key	Value
`:attributes`	Attributes similar to the `Attr` chunk, but at the Elixir, instead of Core Erlang level. Usually they match with the exception that `attributes` doesn't contain `vsn` when `Attr` contains the `MD5` version
`:compile_opts`	Compilation options similar to `CInf` chunk's `options` key, but at for Elixir, instead of Core Erlang level.
`:definitions`	The Elixir `quoted` AST for reach function clause.
`:file`	The name of the file the module was generated from.
`:line`	The line in `:file` where the module was defined, such as the line `defmodule` occurred.
`:module`	The name of the module as an `atom`
`:unreachable`	Unreachable functions

Tab

The Dbgi tab appearance varies based on whether it was created with Erlang or Elixir, reflecting the fact that the Dbgi format is dependent on the backend that wrote it.

####### Elixir (:elixir_erl backend)

The Dbgi tab show the single value map entries: :file, :line, and :module.

Singletons

For the multi-value keys: :attributes, :compile_opts, and :definitions, there are individual tabs.

Multivalue Tabs

######## Attributes

The Attributes tab has the same format as the Attrs chunk.

Dbgi Attributes Table

######## Compile Options

The Compile Options tab is usually empty, much like the CInf options key for Erlang.

Table

######## Definitions

The Definitions tab is split between a tree of Module, Function/Arity and clauses.

Tree

Clicking on a clause will show only that clause, but clicking on a higher level in the tree will show all clauses in the function or the entire Module.

Clause Function Module

The AST stored in the definitions tab and the process of converting it back to code is not format preserves, so it will not look precisely like the source code as the AST has undergone some macro expansion before its put in the Dbgi chunk. As common idioms are understood, reversals will be add to the renderer.

######## Type Specifications

The Type Specifications tab is split between a tree of the Module, Module Attribute, and type specifications.

Clicking on a type specification will show only that type specification, but clicking on a higher in the tree will show all type specifications for the same module attribute or the entire Module.

Optional Callback.png Optional Callbacks.png

####### Erlang (:erlang_abstract_code backend)

The Dbgi tab has Abstract Code and Compile Options tabs.

Dbgi Tabs

######## Abstract Code

The Abstract Code tab is split between a tree of Attributes, Functions, Function/Arity, and clauses.

Tree

Clicking on a clause will show only that clause, but clicking on a higher level in the tree will show all clauses in the function or the entire Module.

Clause Function Module

The abstract code stored in the :erlang_abstract_code backend format is the Erlang Abstract Format. Instead of converting the Erlang Abstract Format back to Erlang, which would require IntelliJ Erlang to highlight and annotate and for you to be used to reading Erlang, the Erlang Abstract Format is translated back to Elixir. Using the BEAM Chunk Dbgi viewer can be a way to convert compiled Erlang code to Elixir source automatically.

`ExDc`

The ExDc chunk stores ExDoc. Not the rendered HTML from the ex_doc package, but the the @doc, @moduledoc, and @typedoc attribute values that work even without ex_doc installed. This chunk is what is consulted when the h helper is used in iex.

Format

The ExDc chunk is the encoded with term_to_binary. The term format is a versioned as {version, versioned_format}. The current version tag is :elixir_docs_v1 and the versioned_format is a Keyword.t with keys matching the Code.get_docs/2 tags :callback_docs, :docs, :moduledoc, and :type_docs keys.

Tab

Like Dbgi, the ExDc tab is split between a tree to navigate and an editor to show the decompiled value.

ExDc Tree Function selected in ExDc tree

Click on a node in the tree will show all docs at that level and any descendants.

Node	Description
Root	All docs
Module	`@moduledoc`
Types	All `@typedoc`s
Types child	A specific `@typedoc`
Callbacks	All `@callback` `@doc`s
Callbacks child	A specific `@callback`'s `@doc`
Functions/Macros	All `@doc`s for functions/macros
Functions/Macros child	A specific function/macro's `@doc`

`ExpT`

The ExpT chunk is the Export Table. The name "Export" derives from the Erlang module attribute -export, which is used to "export" functions from a module. It is the equivalent of making a function or macro public with def and defmacro as opposed to making it private with defp and defmacrop in Elixir.

Format

The BEAM format and the ExpT chunk, being made for Erlang, has no concept of macros. It only understands functions, so Elixir macros, like __using__/1 called by use are compiled to plain Erlang functions with MACRO- prefixed to their name and an extra argument (the __CALLER__ environment) as the first argument, which increases the arity, yielding a full MFA of MACRO-__using__/2 as seen above.

Tab

The ExpT tab shows a table with the columns

Column	Description	Source
Atom Index	Index into the `Atom` or `AtU8` chunk for the function's name	Raw
Name	The atom referenced by "Atom Index"	Derived
Arity	The arity (argument count) of the function	Raw
Label	Label index in the `Code` chunk where the function is defined. This label is usually immediately after the `func_info` operation and before the first pattern match or guard operation.	Raw

ExpT Table

`ImpT`

The ImpT chunk is the Import Table. It DOES NOT encode just the Erlang -import attributes or Elixir import macro calls: it tracks any external function or macro called from another module. call_ext_* operations in the Code chunk don't store the Module and Function (MF) of the function they will call directly in the bytecode, instead, one of the arguments is an index into the ImpT chunk. This way, all external calls are normalized into the ImpT chunk instead of being denormalized to the call site. The arity still appears at the call site to help with checking the argument count.

Format

You may notice that erlang.byte_size/1 is included in the table. This is because even BIFs are referenced by MFA and not a pre-assigned number as would be the case for system calls in operating systems like Linux. BEAM is like an Operation System, but not in all ways.

Tab

The ImpT tab shows a table with the columns

Column	Description	Source
Index	0-based index used by references in the `Code` chunk.	Derived
Module Atom Index	Index into the `Atom` or `AtU8` chunk for the Module's name	Raw
Module Atom	The atom referenced by "Module Atom Index".	Derived
Function Atom Index	Index into the `Atom` or `AtU8` chunk for the functon's name	Raw
Function Atom	The atom referened by "Function Atom Index".	Derived

ImpT Table

`LitT`

The LitT chunk contains literals loaded as arguments in Code chunk.

Format

Confusingly, in the Code chunk sometimes the literal(N) term is used to encode integer N, an index into another chunk, or an actual index into the LitT. How literal terms are handled is completely dependent on the specific operation, so without having outside knowledge about the bytecode operation arguments for BEAM, the best way to figure out if literal terms are an integer or an index is to toggle the various controls in the Code tab to see if literal with no inlining turns into a LitT literal, FunT function reference, ImpT function reference, or integer.

Tab

The LitT tab shows a table with the columns

Column	Description	Source
#	0-based index used by references in the `Code` chunk.	Derived
Term	The equivalent of `raw \|> binary_to_term() \|> inspect()`	Raw

LitT Table

`Line`

The Line chunk encodes both the file name and line number for each line(literal(n)) operation in the Code chunk. The n in line(literal(n)) is an index in to the Line References table in the Line chunk. This is used in Phoenix view modules to show where code from templates comes from.

Format

The Line chunk is composed of 2 subsections: (1) Line References and (2) File Names. First there is a header setting up the number of each entry to expect.

Offset	+0	+1	+2	+3
0	emulator version (`unsigned-big-integer`)
4	flags (`unsigned-big-integer`)
8	Line Instruction Count (`unsigned-big-integer`)
12	Line Reference Count (`unsigned-big-integer`)
16	File Name Count (`unsigned-big-integer`)

####### Line References

This uses the Compact Term Format used for the Code chunk. The format ends up producing {file_name_index, line} pairs using the following algorithm:

Term	Interpretation
`atom(n)`	Change `file_name_index` to `n`
`integer(n)`	Add `{file_name_index, n}` to end of Line References

####### File Names

Offset	+0	+1	+2	+3
0	Byte Count (`unsigned-big-integer`)		Bytes

Tab

The Line tab has one subtab for each subsection in the tab. Each subsection has its own table.

Line References Table File Names TableTable

`LocT`

The LocT chunk is the dual to the ExpT chunk: it contains all private functions and macros.

Format

You'll notice entries like -__struct__/1-fun-0-, starts with - and have a / suffix with fun in it. This naming scheme is used for anonymous functions such as those defined with fn or the capture operator (&) in Elixir. Much like how macros don't really exist and use a MACRO- suffix, anonymous functions/lambdas don't exist, and instead use a distinct naming scheme -<PARENT_FUNCTION>/*fun*. Unlike MACRO-, which is an Elixir invention, anonymous functions/lambdas really being local named functions with derived names is also done in pure Erlang modules. Erlang's anonymous functions are defined with fun, which is where the fun part of the naming scheme comes from.

Tab

The LocT tab shows a table with the columns

Column	Description	Source
Atom Index	Index into the `Atom` or `AtU8` chunk for the function's name	Raw
Name	The atom referenced by "Atom Index"	Derived
Arity	The arity (argument count) of the function	Raw
Label	Label index in the `Code` chunk where the function is defined. This label is usually immediately after the `func_info` operation and before the first pattern match or guard operation.	Raw

LocT Table

`StrT`

The StrT chunk contains all Erlang strings (that is, Elixir charlists) used in the Code chunk.

Format

The StrT chunk contains a single contiguous pool. These strings are used for byte code operations like bs_put_string. Not all strings appear in StrT. Some strings, including most Elixir strings (Erlang binaries) appear in the LitT chunk that holds literals. I'm not sure how the compiler determines whether to use StrT or LitT. I think it all depends on the byte code operation.

Instead of encoding the start and length of each string in the chunk itself, the start and length for any given string is passed as arguments to the byte code operations in the Code chunk. By doing this, shared substrings can be efficiently encoded in StrT.

Tab

StrT Pool

Decompilation (Text)

.beam files, such as those in the Elixir SDK, the Elixir SDK's Internal Erlang SDK, and in your project's build directory will be decompiled to equivalent def and defmacro calls. The bodies will not be decompiled, only the call definition head and placeholder parameters. These decompiled call definition heads are enough to allow Go To Declaration, the Structure pane, and Completion to work with the decompiled .beam files.

Call definition macros

It turns out that in the .beam binary format there are no macros. This makes sense since the BEAM format was made for Erlang, which does not have macros, and only has functions. Elixir marks its macros in the compiled .beam by prefixing them with MACRO-.

There are 2 chunks in the BEAM format for function references: ExpT, which is for exports (because in Erlang module they are from -export), which are the public functions and macros; and LocT, which is for locals (anything not exported in Erlang), which are private functions and macros.

BEAM Chunk	Atom Prefix	Macro
`ExpT`	`MACRO-`	`defmacro`
`ExpT`	N/A	`def`
`LocT`	`MACRO-`	`defmacrop`
`LocT`	N/A	`defp`

`defp` with `/` in name

Much like there are no macros in BEAM, there are no anonymous functions either. Any anonymous function (using fn in Elixir or fun in Erlang) ends up being a named function in the LocT chunk. Anonymous functions names start with -, then the parent function's name, a / and a unique number for that scope.

As an example, Kernel has

defp unquote(:"-MACRO-binding/2-fun-0-")(p0, p1, p2, p3) do
  # body not decompiled
end

which is generated from the for in

 defmacro binding(context \\ nil) do
    in_match? = Macro.Env.in_match?(__CALLER__)
    for {v, c} <- __CALLER__.vars, c == context do
      {v, wrap_binding(in_match?, {v, [generated: true], c})}
    end
  end

-- Kernel.binding/1

Special handling of call definition names

Functions and macros can have names that aren't valid identifier names, so the decompiler has special handlers to detect these invalid identifiers and escape them to make decompiled code that is parsable as valid Elixir.

Handler	Name/Arity	Decompiled	Reason
Infix Operator	`!=/2`	`left != right`	Infix operators are defined in infix position
	`!==/2`	`left !== right`
	`&&/2`	`left && right`
	`&&&/2`	`left &&& right`
	`*/2`	`left * right`
	`=+/2`	`left + right`
	`=++/2`	`left ++ right`
	`-/2`	`left - right`
	`--/2`	`left -- right`
	`->/2`	`left -> right`
	`../2`	`left .. right`
	`//2`	`left / right`
	`::/2`	`left :: right`
	`</2`	`left < right`
	`<-/2`	`left <- right`
	`<<</2`	`left <<< right`
	`<<~/2`	`left <<~ right`
	`<=/2`	`left <= right`
	`<>/2`	`left <> right`
	`<\|>/2`	`left <\|> right`
	`<~/2`	`left <~ right`
	`<~>/2`	`left <~> right`
	`=/2`	`left = right`
	`==/2`	`left == right`
	`===/2`	`left === right`
	`=>/2`	`left => right`
	`=~/2`	`left =~ right`
	`>/2`	`left > right`
	`>=/2`	`left >= right`
	`>>>/2`	`left >>> right`
	`\\/2`	`left \\\\ right`
	`^/2`	`left ^ right`
	`^^^/2`	`left ^^^ right`
	`and/2`	`left and right`
	`in/2`	`left in right`
	`or/2`	`left or right`
	`\|>/2`	`left \|> right`
	`\|\|/2`	`left \|\| right`
	`\|\|\|/2`	`left \|\|\| right`
	`~=/2`	`left ~= right`
	`~>/2`	`left ~> right`
	`~>>/2`	`left ~>> right`
Prefix Operator	`+/1`	`(+value)`	To prevent precedence errors, unary prefix operators, which also have binary infix operators of the same name need to be defined inside parentheses
Prefix Operator	`-/1`	`(-value)`
Unquoted	`%/2`	`unquote(:%)(p0, p1)`	Special forms need to defined as atom passed to unquote, as special forms are handled before macros defining the calls are applied
	`%{}/1`	`unquote(:%{})(p0)`
	`&/1`	`unquote(:&)(p0)`
	`./2`	`unquote(:.)(p0, p1)`
	`<<>>/1`	`unquote(:<<>>)(p0)`
	`do/n`	`unquote(:do)(p0, ...)`	Keywords need to be escaped
	`fn/1`	`unquote(:fn)(p0)`	Special forms need to defined as atom passed to unquote, as special forms are handled before macros defining the calls are applied
	`unquote/1`	`unquote(:unquote)(p0)`
	`unquote_splicing/1`	`unquote(:unquote_splicing)(p0)`
	`{}/n`	`unquote(:{})(p0, ...)`
	`Capitalized/n`	`unquote(:Capitalized)(p0, ...)`	Part of the Corba libraries in OTP have functions starting with a capital letter, which would be parsed as an Alias in Elixir if not unquoted.
	`#text#/1`	`unquote(:"#text#")(p0)`	Part of the XML libraries in OTP have functions that start with or contain `#`, which would parse as a comment in Elixir if not unquoted in a double quoted atom.
Default	`name/n`	`name(p0, ...)`	If no specialized handler is required, functions and macros are defined normally with pN for each parameter in the Nth position

Completion

Aliases and Modules

When you start typing an Alias, completion will look in three locations:

alias aliased names in the current file
1. Suffix for alias Prefix.Suffix
2. MultipleAliasA or MultipleAliasB for alias Prefix.{MultipleAliasA, MultipleAliasB}
3. As for alias Prefix.Suffix, as: As
Indexed module names (as available from Go To Symbol)
1. Prefix.Suffix from defmodule Prefix.Suffix
2. MyProtocol from defprotocol MyProtocol
3. MyProtocol.MyStruct
  1. defimpl MyProtocol, for: MyStruct
  2. defimpl MyProtocol nested under defmodule MyStruct
Nested modules under aliased names
1. Suffix.Nested for alias Prefix.Suffix where Prefix.Suffix.Nested is an indexed module, implementation or protocol name.
2. MultipleAliasA.Nested for alias Prefix.{MultipleAliasA, MultipleAliasB} where Prefix.MultipleAliasA.Nested alias Prefix.{MultipleAliasA, MultipleAliasB} is an indexed module, implementation or protocol name.
3. As.Nested for alias Prefix.Suffix, as: As where Prefix.Suffix.Nested is an indexed module, implementation, or protocol name.

Aliases inside `{ }`

When you start typing inside { } for alias Prefix.{} or import Prefix.{}, completion will look for nested modules under Prefix and then remove the Prefix., so completion will look like Suffix.

Function and Macro Calls

Completion uses the same presentation as Structure, so you can tell whether the name is function/macro (Time), whether it is public/private (Visibility) and the Module where it is defined. Between the icons and the Modules is the name itself, which is highlighted in bold, the parameters for the call definition follow, so that you can preview the patterns required for the different clauses.

Function and Macro Calls Completion

Qualified

Qualified functions and macro calls will complete using those functions and macros defined in the qualifying Module (defmodule), Implementation (defimpl) or Protocol (defprotocol). Completion starts as shown as . is typed after a qualifying Alias.

Unqualified

Function and macro calls that are unqualified are completed from the index of all function and macro definitions, both public and priva

Truncated — view the full README on GitHub.

Contributors

(top 30 of 56)

5,282 commits

649 commits

287 commits

25 commits

Similar repos

judasn/IntelliJ-IDEA-Tutorial

IntelliJ IDEA 简体中文专题教程

22,066

shared topics

Kotlin/kotlin-lsp

Kotlin Language Server and plugin for Visual Studio Code

3,496

similar language mix

JetBrains/intellij-plugins

Open-source plugins included in the distribution of IntelliJ IDEA Ultimate and other IDEs based on…

2,269

similar language mix

DetachHead/rebased

A git client based on the IntelliJ platform

5,509

similar language mix

JetBrains/intellij-community

IntelliJ IDEA & IntelliJ Platform

20,522

similar language mix

ZalithLauncher/ZalithLauncher2

A Minecraft: Java Edition Launcher for Android

1,817

similar language mix

mishka-group/mishka_chelekom

Mishka Chelekom is a fully featured components and UI kit library for Phoenix & Phoenix LiveView

750

similar language mix

sghpjuikit/player

Audio player and management application.

similar language mix

Languages

Kotlin

47.2%

Elixir

32.9%

Java

18.3%

KronicDeth/intellij-elixir

Elixir plugin for JetBrain's IntelliJ Platform (including Rubymine)

1,897

stars

6,370

commits

Kotlin

primary language

Sep 9, 2026

updated

androidstudio

appcode

clion

datagrip-ide

editor

editor-plugin

elixir

elixir-mix

elixir-plugin

gogland

hacktoberfest

ide

intellij-plugin

java

jetbrains

mix

pycharm

rubymine

webstorm

Browse cluster: JVM Languages and Android Development →

README

Elixir plugin

Elixir plugin

This is a plugin that adds support for Elixir to JetBrains IDEs.

IDEs

IDE	Rich/Small	Languages	Cost	Trial	License	Source
IntelliJ IDEA Community Edition	Rich	Java	Free	N/A	Apache 2.0	JetBrains/intellij-community
IntelliJ IDEA Ultimate Edition	Rich	Java	Subscription	30-days	Commercial	N/A
AppCode	Small	Objective-C	Subscription	30-days	Commercial	N/A
CLion	Small	C/C++	Subscription	30-days	Commercial	N/A
DataGrip	Small	SQL	Subscription	30-days	Commercial	N/A
GoLand	Small	Go	Subscription	30-days	Commercial	N/A
PHPStorm	Small	PHP	Subscription	30-days	Commercial	N/A
PyCharm Community Edition	Small	Python	Free	N/A	Apache 2.0	JetBrains/intellij-community subdirectory
PyCharm Professional Edition	Small	Python	Subscription	N/A	Commercial	N/A
Rider	Small	.NET	Subscription	N/A	Commercial	N/A
RubyMine	Small	Ruby	Subscription	30-days (90-day for whole team)	Commercial	N/A
WebStorm	Small	JavaScript	Subscription	30-days	Commercial	N/A

Once you have your IDE of choice installed, you can install this plugin

Features

Feature	Rich	Small	Alternative
Project	Yes	No	1. Open directory 2. Setup the SDK
Project Structure	Automatic	Manual
Project Settings	Yes	No
Module Settings	Yes	No
New Elixir File	Yes	Yes
Syntax Highlighting and Semantic Annotation	Yes	Yes
Grammar Parsing	Yes	Yes
Inspections	Yes	Yes
Quick Fixes	Yes	Yes
Code Folding	Yes	Yes
Commenter	Yes	Yes
Debugger	Yes	Yes
Delimiters	Yes	Yes
Embedded Elixir (EEx) Templates	Yes	Yes
Building/Compiling	Yes	No	Build/compile as part `mix` run configurations only
Live Templates	Yes	Yes
Documentation	Yes	Yes
Run Configurations	Yes	Yes
Completion	Yes	Yes
Decompilation	Yes	Yes
Go To Declaration	Yes	Yes
Formatting	Yes	Yes
Go To Related	Yes	Yes
Go To Symbol	Yes	Yes
Go To Test	Yes	Yes
Go To Test Subject	Yes	Yes
Find Usage	Yes	Yes
Live Embedded Elixir (LEEx) Templates	Yes	Yes
HEEx Templates	Yes	Yes
Refactor	Yes	Yes
SDK	Yes	Yes
Structure	Yes	Yes

Project

NOTE: This feature only works in Rich IDEs as it depends on an extension point unavailable in Small IDEs. To setup a project in a Small IDE

Open Directory of the project

Setup the SDK

From Existing Sources

Import project from external model

If you've already created a mix project, you can load it as an Elixir project into the plugin.

File > New > Project From Existing Sources...
Select the root directory of your project.
Select "Import project from external model"
Select Mix
Click Next
Select a Project SDK directory by clicking Configure.
The plugin will automatically find the newest version of Elixir installed. (NOTE: SDK detection only works for Linux, homebrew installs on OSX, and Windows. Open an issue with information about Elixir install locations on your operating system and package manager to have SDK detection added for it.)
If the automatic detection doesn't find your Elixir SDK or you want to use an older version, manually select select the directory above the bin directory containing elixir, elixirc, iex, and mix. (On Windows it is the directory containing elixir.bat, elixirc.bat, iex.bat, and mix.bat.)
Click Finish after you select SDK name from the Project SDK list.
The "Mix project root" will be filled in with the selected directory.
(Optional) Uncheck "Fetch dependencies with mix" if you don't want to run mix deps.get when importing the project
- If "Fetch dependencies with mix" is checked both mix local.hex --force and mix deps.get will be run.
Click Next
All directories with mix.exs files will be selected as "Mix projects to import". To import just the main project and not its dependencies, click Unselect All.
Check the box next to the project root to use only its mix.exs. (It will likely be the first checkbox at the top.)
Click Finish

Create project from existing sources

If you've already created a (non-mix) project, you can load it as an Elixir project into the plugin.

File > New > Project From Existing Sources...
Select the root directory of your project.
Leave the default selection, "Create project from existing sources"
Click Next
Project name will be filled with the basename of the root directory. Customize it if you like.
Project location will be the root directory.
Click Next.
If you previously opened the directory in IntelliJ or another JetBrains IDE, you'll be prompted to overwrite the .idea directory. Click Yes.
You'll be prompted with a list of detected Elixir project roots to add to the project. Each root contains a mix.exs. Uncheck any project roots that you don't want added.
Click Next.
Select a Project SDK directory by clicking Configure.
The plugin will automatically find the newest version of Elixir installed. (NOTE: SDK detection only works for Linux, homebrew installs on OSX, and Windows. Open an issue with information about Elixir install locations on your operating system and package manager to have SDK detection added for it.)
If the automatic detection doesn't find your Elixir SDK or you want to use an older version, manually select select the directory above the bin directory containing elixir, elixirc, iex, and mix.
Click Next after you select SDK name from the Project SDK list.
Click Finish on the framework page. (No framework detection is implemented yet for Elixir.)
Choose whether to open in a New Window or in This Window.

New

If you want to create a basic (non-mix) Elixir project with a lib directory, perform the following steps.

File > New > Project
Select Elixir from the project type menu on the left
Click Next
Select a Project SDK directory by clicking Configure.
Select a Project SDK directory by clicking Configure.
The plugin will automatically find the newest version of Elixir installed.
- macOS / OSX
  - Homebrew (/usr/local/Cellar/elixir)
  - Nix (/nix/store)
- Linux
  - /usr/local/lib/elixir
  - Nix and NixOS (/nix/store)
- Windows
  - 32-bit (C:\Program Files\Elixir)
  - 64-bit (C:\Program Files (x86)\Elixir)
  - (NOTE: SDK detection only works for Open an issue with information about Elixir install locations on your operating system and package manager to have SDK detection added for it.)
If the automatic detection doesn't find your Elixir SDK or you want to use an older version, manually select select the directory above the bin directory containing elixir, elixirc, iex, and mix. If the bin, lib, or src directory is incorrectly selected, it will be corrected to the parent directory.
Click Next after you select SDK name from the Project SDK list.
Change the Project name to the name your want for the project
(Optionally) change the Project location if the directory does not match what you want
(Optionally) expand More Settings to change the Module name, Content root, Module file location, and/or Project format. The defaults derived from the Project name and Project location should work for most projects.
Click Finish
Choose whether to open in a New Window or in This Window.

Project Structure

Project View

Excluded
- .elixir_ls (Elixir Language Server cache)
- assets/node_modules/phoenix (Phoenix symlink back to deps)
- assets/node_modules/phoenix_html (Phoenix HTML symlink back to deps)
- cover (Test coverage output)
- deps (Dependencies -- re-exposed as Libraries for Go-to-Declaration)
- doc (Documentation generated by ex_doc)
- logs (Conventional log directory)
Sources
- lib
- web (legacy Phoenix layout compatibility)
Test Sources
- spec (ESpec)
- test

Project Settings

The Project Settings include

Project Name
Project SDK

SDK Setup Known Limitations

When setting up Elixir and Erlang SDKs for the first time:

Setup SDKs before importing your Elixir project
Auto-detect SDKs: The plugin will attempt to automatically detect the SDKs based on the currently open project directory, not the directory that you are importing. To setup SDKs on a WSL instance, open any project, or even an empty directory in WSL first.
Click OK directly after configuring Erlang, then reopen the Project Structure dialog to configure Elixir - this will properly save all settings
Avoid clicking Apply then OK - this workflow has a known issue where the project SDK may not be saved correctly

Windows Subsystem for Linux (WSL) Support

The plugin supports running Elixir, Mix, and IEx commands within WSL. This includes:

Run Configurations: All Mix, ExUnit, ESpec, Elixir, and IEx run configurations are fully compatible with WSL.
External Tools: background tools like Credo inspections, Dialyzer, Mix Format, and the New Project Wizard automatically use WSL when your project is located on a WSL partition.
Path Conversion: Windows UNC paths (e.g., \\wsl$\Ubuntu\...) and Windows drive paths are automatically converted to POSIX paths when executing commands in WSL.

WSL Limitations

New Project Wizard: SDK selection is based on the location of the currently open project, not the new project. To select a WSL based SDK during the New Project Wizard, open any WSL project or directory in the IDE first.
SDKs and Project must all be on the same WSL Distribution: You cannot use a WSL based SDK with a non-WSL project, and vice versa. You can use the /mnt/c drive to access Windows files from WSL, but the performance is terrible.
Build system (Ctrl+F9): The IDE build system only works when the Project SDK is set to a JDK 21+ in the same WSL distribution, and all Module SDKs are set to the correct Elixir SDK.
Performance: Running the IDE in Windows with a WSL project is slower than running the IDE directly in the WSL instance. This is a limitation of the IDE, not specific to the Elixir plugin.

Module Settings

Sources

Module Settings > Sources

The Module Settings include Marking directories as

Excluded
Sources
Tests

Paths

Module Settings > Paths

Module paths list the output directories when compiling code in the module. There is a an "Output path" for dev MIX_ENV and "Test output path" for the test MIX_ENV.

Dependencies

Module Settings > Dependencies

Trigger: File system events in deps/ and _build/ (after mix deps.get, mix compile or folder deletions).
What it creates: For each dependency, an IDE Library with source roots from deps/APP/lib and class roots from _build/ENV/lib/APP/ebin.
Result: Dependencies appear under "External Libraries" in the Project tool window, providing Go-to-Declaration, completion, and Find Usages into dependency source code.
Troubleshooting: If libraries don't appear after mix deps.get, try running mix compile to generate _build/ output, then wait a few seconds for the file watcher to pick up changes. You can also use Tools → Elixir → Install Mix Dependencies.

Enabling the widget:

Open Settings (Ctrl+Alt+S / ⌘,)
Navigate to Languages & Frameworks → Elixir
Check "Enable Status Bar Widget showing if the Elixir SDK is correctly configured"
Click OK -- the widget appears in the status bar when you have Elixir files open.

Widget states:

Display	Meaning
`Elixir: 1.17.3`	SDK configured correctly
`Elixir: 1.17.3 !`	Classpath issues (missing ebin paths or Erlang SDK classpath entries)
`Elixir: 1.17.3 ⚠ OTP`	Elixir SDK was compiled against a different OTP major than the paired Erlang SDK
`Elixir: 1.17.3 ⚙`	Folder marks are suboptimal (e.g., `test/` not marked as Test Sources)
`Elixir: SDK Error`	Module `.iml` files reference an SDK that no longer exists
`Elixir: Issues`	SDK is invalid or missing its Erlang SDK dependency
`No Elixir SDK`	No Elixir SDK configured for the project

Click the widget to open a popup with quick actions:

Configure Elixir SDKs... -- open Project Structure to add or edit SDKs
Detected Elixir SDKs -- if no SDK is configured and a tool manager (e.g. mise) detects valid installations, they are listed here. Click one to register it as the project SDK.
Refresh Elixir SDKs -- re-scan SDK home paths and update classpath entries
Install Mix Dependencies -- run mix deps.get for the project
Reconfigure Elixir Module Setup -- re-apply canonical folder marks (lib/ → Sources, test/ → Test Sources, deps/ → Excluded, etc.) and fix dangling module SDK references

Notifications: When the widget detects a problem, it fires a notification with actionable buttons:

"Reconfigure Now" -- one-click fix for folder mark warnings and module SDK errors
"Open Project Structure" -- navigate to SDK/module settings
"Don't Warn for This SDK" -- suppress OTP mismatch warnings for a specific SDK

New Elixir File

Right-click a directory (such as lib or test in the standard mix new layout)
Select New > Elixir File.
Enter an Alias for the Module name, such as MyModule or MyNamespace.MyModule.
Select a Kind of Elixir File to use a different template.

Empty module

An underscored file will be created in an underscored directory lib/my_namespace/my_module.ex) with the given module name with be created:

defmodule MyNamespace.MyModule do
  @moduledoc false

end

Elixir Application

defmodule MyNamespace.MyModule do
  @moduledoc false

  use Application

  def start(_type, _args) do
    MyNamespace.MyModule.Supervisor.start_link()
  end
end

Elixir Supervisor

defmodule MyNamespace.MyModule.Supervisor do
  @moduledoc false

  use Supervisor

  def start_link(arg) do
    Supervisor.start_link(__MODULE__, arg)
  end

  def init(arg) do
    children = [
      worker(MyWorker, [arg], restart: :temporary)
    ]

    supervise(children, strategy: :one_for_one)
  end
end

Elixir GenServer

defmodule MyNamespace.MyModule do
  @moduledoc false

  use GenServer

  def start_link(state, opts) do
    GenServer.start_link(__MODULE__, state, opts)
  end

  def init(_opts) do
    {:ok, %{}}
  end

  def handle_call(_msg, _from, state) do
    {:reply, :ok, state}
  end

  def handle_cast(_msg, state) do
    {:noreply, state}
  end
end

Elixir GenEvent

defmodule MyNamespace.MyModule do
  @moduledoc false

  use GenEvent

  # Callbacks

  def init(_opts) do
    {:ok, %{}}
  end

  def handle_event(_msg, state) do
    {:ok, state}
  end

  def handle_call(_msg, state) do
    {:ok, :ok, state}
  end

  def handle_info(_msg, state) do
    {:ok, state}
  end
end

Syntax Highlighting and Semantic Annotation

Syntax highlighting of lexer tokens and semantic annotating of parser elements can be customized in in the Color Settings page for Elixir (Preferences > Editor > Color & Fonts > Elixir).

Text Attribute Key Display Name			Tokens/Elements	Scheme
Text Attribute Key Display Name			Tokens/Elements	Default	Darcula
Alias			`String`
Atom			`:one` `<<>>:`
Braces and Operators	Bit		`<<` `>>`
Braces and Operators	Braces		`{` `}`
Braces and Operators	Brackets		`[` `]`
Braces and Operators	Character Token		`?`
Braces and Operators	Comma		`,`
Braces and Operators	Dot		`.`
Braces and Operators	Interpolation		`#{` `}`
Braces and Operators	Maps and Structs	Maps	`%{` `}`
Braces and Operators	Maps and Structs	Maps	`%` `{` `}`
Braces and Operators	Operation Sign		`=` `+` `*` `==` `!` `&&` `\|\|` `\|>` `^`
Braces and Operators	Parentheses		`(` `)`
Braces and Operators	Semicolon		`;`
Calls	Function		`inspect`	*Only the Italic attribute	*Only the Italic attribute
Calls	Macro		`inspect`	*Only the Bold and Italic attributes	*Only the Bold and Italic attributes
Calls	Predefined		`Kernel` functions macros `Kernel.SpecialForms` macros	*Only the Foreground attribute	*Only the Foreground attribute
Comment			`# Numbers`
Keywords			`end`
Module Attributes			`@custom_attr`
Module Attributes	Documentation		`@doc`
Module Attributes	Documentation	Text	`Simple module docstring`
Module Attributes	Types	Callback	`func`
Module Attributes	Types	Specification	`func`
Module Attributes	Types	Type	`parameterized`
Module Attributes	Types	Type Parameter	`type_parameter`
Numbers	Base Prefix	Non-Decimal	`0b` `0x` `0o`
Numbers	Base Prefix	Obsolete Non-Decimal	`0B` `0X`
Numbers	Decimal Exponent, Mark, and Separator		`e` `.` `_`
Numbers	Digits	Invalid	`2` `o` `r` `888`
Numbers	Digits	Valid	`1234` `1A` `beef` `123`
Textual	Character List		`'This is a list'`
Textual	Escape Sequence		`\x{12}`
Textual	Sigil		`~r//` `~R''` `~w()` `~W()`
Textual	String		`"Hello world"`
Variables	Ignored		`_`
Variables	Parameter		`a` `b`
Variables	Variable		`pid`

Grammar parsing

Built on top of highlighted tokens above, the parser understands the following parts of Elixir grammar as valid or allows the grammar because they contain correctable errors:

Empty Parentheses (())
Keyword Lists
- Keyword Keys - Aliases, identifiers, quotes, or operators when followed immediately by a colon and horizontal or vertical space.
- Keyword Values - Empty parentheses (()) and matched expressions.
Matched Expressions, in other words, unary and binary operations on variable, function, and macro names and values (numbers, strings, char lists, sigils, heredocs, true, false, and nil).
No Parentheses expressions, which are function calls with neither parentheses nor do blocks that have either (1) a positional argument and keyword arguments OR (2) two or more positional arguments with optional keyword arguments.
Anonymous function calls .() with either no arguments; a no parentheses arguments expression as an argument; keywords as an argument; positional argument(s); or positional arguments followed by keywords as arguments.
Remote function calls (Alias.function, :atom.function, etc) and local function calls (function) with...
- No Parentheses with...
  - No Arguments (Alias.function)
  - Keywords (Alias.function key: value)
  - Nested No Parentheses Call (Alias.function Inner.function positional, key: value)
  - Positional and Keyword arguments (Alias.function positional, key: value)
  - Matched Expression (Alias.function 1 + 2)
- Parentheses with...
  - No arguments (Alias.function())
  - No Parentheses Call (Alias.function(Inner.function positional, key: value)
  - Keywords (Alias.function(key: value))
  - Positional and Keyword arguments (Alias.function(positional, key: value))
  - Trailing parentheses for quoting (def unquote(variable)(positional))
Bracket expression (variable[key])
Block expressions (function do end)
Unmatched expressions, in other words combinations of block expressions and matched expressions.

Inspections

Inspections mark sections of code with warnings and errors. They can be customized from the Preferences > Inspections > Elixir.

Elixir Inspections

Ambiguous nested calls

outer_function first_outer_argument,
               # second argument is another function call without parentheses, but with multiple arguments
               inner_function first_inner_argument,
               ambiguous_keyword_key: ambiguous_keyword_value

To fix the ambiguity if first_inner_keyword_key: first_inner_keyword_value should be associated, add parentheses around the inner function's arguments:

# keywords are for inner function
outer_function first_outer_argument
               inner_function(
                 first_inner_argument
                 ambiguous_keyword_key: ambiguous_keyword_value
               )

# keywords are for outer function
outer_function first_outer_argument
               inner_function(
                 first_inner_argument
               ),
               ambiguous_keyword_key: ambiguous_keyword_value

Preferences > Inspections > Elixir > Ambiguous nested calls Ambiguous nested calls error

Ambiguous nested call inspection marks the error on the comma that causes the ambiguity. Ambiguous nested calls inspection

Mousing over the comma marked as an error in red (or over the red square in the right gutter) will show the inspection describing the error.

Ambiguous parentheses

Empty Parentheses

function ()

To fix the ambiguity remove the space or add outer parentheses without the space if the first argument should be ():

# extra space, no arguments to function
function()

# first argument is `()`
function(())

Keywords in Parentheses

function (key: value)

Keywords inside parentheses is not valid, so the only way to fix this is to remove the space

function(key: value)

Positional arguments in Parentheses

function (first_positional, second_positional)

A list of positional arguments in parenthenses is not valid, so the only way to fix this is to remove the space

function(first_positional, second_positional)

Preferences > Inspections > Elixir > Ambiguous parentheses Ambiguous parentheses error

Ambiguous parentheses inspection marks the error on the parenthetical group surrounded by the parentheses that are ambiguous due to the preceding space.

Mousing over the parenthetical group marked as an error in red (or over the red square in the right gutter) will show the inspection describing the error.

Keyword pair colon (`:`) used in type spec instead of type operator (`::`)

Type specifications separate the name from the definition using ::.

@type name: definition

Replace the : with ::

@type name :: definition

Keywords appear before the end of list.

one.(
  one,
  two positional, key: value,
  three
)

one.(
  one
  two(positional, key: value),
  three
)

one.(
  one,
  two,
  three,
  key: value
)

Preferences > Inspections > Elixir > Keywords Not At End Keywords Not At End error

Keywords Not At End inspection marks the error over the keywords that need to be surrounded by parentheses or moved to the end of the list.

Mousing over the keywords marked as an error in red (or over the red square in the right gutter) will show the inspection describing the error.

Match operator (`=`) used in type spec instead of type operator (`::`)

Type specifications separate the name from the definition using ::.

@type name = definition

Replace the = with ::

@type name :: definition

Quick Fixes

Quick Fixes are actions IntelliJ can take to change your code to correct errors (accessed with Alt+Enter by default).

Convert `:` to `::` in type specs

If a type specification uses a single : instead of ::, then hit Alt+Enter on the : to change it to :: and fix the type spec.

Convert `=` to `::` in type specs

If a type specification uses = instead of ::, then hit Alt+Enter on the = to change it to :: and fix the type spec.

Remove space in front of ambiguous parentheses

If a set of parentheses is marked as ambiguous then the space before it can be removed to disambiguate the parentheses with Alt+Enter. (Will vary based on keymap.)

Hitting Alt+Enter on ambiguous parentheses error will bring up the Local Quick Fix, "Remove spaces between function name and parentheses". Hit Enter to accept and remove the space.

Code Folding

You can collapse (fold) pre-defined regions of your Elixir code to make it easier to quickly scroll through files or hide details you don't care about right now.

Controls

Collapsing

Position cursor between lines with with downward facing - arrow and upward facing - arrow.
Cmd+-

Expanding

Position cursor on the collapsed line with the square +
Cmd++

Regions

Expanded	Collapsed	Folded By Default?
`do end`	`do: ...`	No
`->` and right operand	`-> ...`	No
`@doc VALUE`	`@doc "..."`	No
`@moduledoc VALUE`	`@moduledoc "..."`	No
`@typedoc VALUE`	`@typedoc "..."`	No
alias ALIAS1 alias ALIAS1	`alias ...`	Yes
import ALIAS1 import ALIAS2	`import ...`	Yes
require ALIAS1 require ALIAS2	`require ...`	Yes
use ALIAS1 use ALIAS2	`use ALIAS1`	Yes
`@for`	`FOR` in `defimpl PROTOCOL, for: FOR`	Yes
`@protocol`	`PROTOCOL` in `defimpl PROTOCOL, for: FOR`	Yes
@MODULE_ATTRIBUTE	VALUE in `@MODULE_ATTRIBUTE VALUE`	No

Commenter

Using the menus

Highlight one or more lines
Comment (or Uncomment) with one of the following: a. Code > Comment with Line Comment b. On OSX the key binding is normally Cmd+/.

Credo

Inspection

Batch Mode

If you'd like to run mix credo use can run it as a global Inspection.

Analyze > Run Inspection By Name... (⌥⇧⌘I)
Type "Credo"
Select "Credo" from the shortened list
Hit Enter.

You'll be presented with a "Run 'Credo'" dialog

Run 'Credo'

Change the "Inspection scope" from "Whole project", which would include the deps to "Custom scope"
Select "Project Production Files" from the "Custom scope" dropdown
Click "OK"

The Inspections Result Tool Pane will open and show results as each file is processed.

Click the ▶ to expand the Credo section to show all warnings
Click an entry for the details of an individual warning with a code highlighting.

The view will show the parts of the file that aren't annotated as collapsed with the discontinuous line number indicating the jumps.

If you click on + collapse markers, you can expand the collapsed sections to see the full context

Or you can hover over the collapsed section to see a tooltip preview of the expansion

Configuration

Preferences > Editor > Inspections	Preferences > Editor > Inspections > Credo	Editor					Inspections
Elixir > Credo	Include Explanation	Highlight	Message	Explanation in tooltip	`mix credo` Runs		Highlight	Message	`mix credo` Runs	Action
Elixir > Credo	Include Explanation	Highlight	Message	Explanation in tooltip	Per File	Per Issue	Highlight	Message	Working Directory	Inspect Code	Run Inspection By Name
☑	☑	Yes	Yes	Yes	1	1	Yes	Yes	1	Yes	Yes
☑	☐	Yes	Yes	No	1	0	Yes	Yes	1	Yes	Yes
☐	ⁿ/ₐ	No	No	No	0	0	Yes	Yes	1	No	Yes

Annotator

Disable Explanation

Preferences > Editor > Inspections > Credo
Uncheck "Include Explanation"

Disable inspection

If you don't want the annotator to run at all on open editors, then you can disable the paired inspection

Preferences > Editor > Inspections
Uncheck Elixir > Credo

Once the annotator is disabled, you can still run the inspection in batch mode

Debugger

IntelliJ Elixir allows for graphical debugging of *.ex files using line breakpoints.

Steps

Define a run/debug configuration
Create breakpoints in the *.ex files
Launch a debugging session
During the debugger session, step through the breakpoints, examine suspended program, explore frames, and evaluate code when suspended.

Basics

After you have configured a run configuration for your project, you can launch it in debug mode by pressing Ctrl+D.

Keyboard Shortcuts

Action	Keyword Shortcut
Toggle Breakpoint	`Cmd+F8`
Resume Program	`Alt+Cmd+R`
Step Over	`F8`
Step Into	`F7`
View breakpoint details/all breakpoints	`Shift+Cmd+F8`

Excluding Modules

Preferences > Build, Execution, Deployment > Debugger > Stepping
Scroll to Elixir

Do Not Step Into The Modules

You can customize these module patterns as an application setting.

Disabling Existing Module Patterns

Preferences > Build, Execution, Deployment > Debugger > Stepping
Scroll to Elixir
Click the Checkbox next to the pattern you want to disable
Click Apply to save or OK to save and close Preferences

Disable

Editing Existing Module Patterns

Preferences > Build, Execution, Deployment > Debugger > Stepping
Scroll to Elixir
Click the pattern text box
Click Apply to save or OK to save and close Preferences

Edit

Removing Existing Module Patterns

Preferences > Build, Execution, Deployment > Debugger > Stepping
Scroll to Elixir
Click the row of the pattern you want to remove
Click the "-" Remove button.
Click Apply to save or OK to save and close Preferences

Remove

Removed

Adding New Module Patterns

Preferences > Build, Execution, Deployment > Debugger > Stepping
Scroll to Elixir
Click the "+" Add button
Click the default "*" pattern to edit it
Click Apply to save or OK to save and close Preferences

Add

Added

Environment Variables

If you want to customize the modules to ignore on a per-Run-Configuration basis, you can set an environment variable in the Run Configuration.

Variable	Example	Description
INTELLIJ_ELIXIR_DEBUG_BLACKLIST	iconv,some	Excluding modules from debugger

Notice: If you want non Elixir. module in blacklist, write it with: :. This rule applies only to module atoms.

Breakpoints

Status	Icon	Description
Enabled		Indicates the debugger will stop at this line when the breakpoint is hit.
Disabled		Indicates that nothing happens when the breakpoint is hit.
Conditionally Disabled		This state is assigned to breakpoints when they depend on another breakpoint to be activated.

When the button Red dot surrounded by crossed-out circle is pressed in the toolbar of the Debug tool window, all the breakpoints in a project are muted, and their icons become grey: Grey dot .

Accessing Breakpoint Properties

Viewing all breakpoints

To view the list of all breakpoints and their properties, do one of the following:

Run > View Breakpoints
Shift+Cmd+F8
Click the
Breakpoints are visible in the Favorites tool window.

Viewing a single breakpoint

To view properties of a single breakpoint

Right-Click a breakpoint icon in the left gutter of the editor.

Configuring Breakpoints

To configure actions, suspend policy and dependencies of a breakpoint

Open the Breakpoint Properties
- Right-click a breakpoint in the left gutter, then click the More link or press Shift+Cmd+F8
- Open the Breakpoints dialog box and select the breakpoint from the list
- In the Favorites tool window, select the desired breakpoint, and click the pencil icon.
Define the actions to be performed by IntelliJ IDEA on hitting breakpoint:
- To notify about the reaching of a breakpoint with a text message in the debugging console, check the "Log message to console" check box. A message of the format *DBG* 'Elixir.IntellijElixir.DebugServer' got cast {breakpoint_reached, PID} will appear in the console.
- To set a breakpoint the current one depends on, select it from the "Disabled until selected breakpoint hit" drop-down list. Once dependency has been set, the current breakpoint is disabled until selected one is hit.
  - Choose the "Disable again" radio button to disable the current breakpoint after selected breakpoint was hit.
  - Choose the "Leave enabled" radio button to keep the current breakpoint enabled after selected breakpoint was hit.
- Enable suspending an application upon reaching a breakpoint by checking the "Suspend" check box.

Creating Line Breakpoints

A line breakpoint is a breakpoint assigned to a specific line in the source code.

Line breakpoints can be set on executable lines. Comments, declarations and empty lines are not valid locations for the line breakpoints. Line break points can be set in .ex and .eex files.

.eex line breaks will only work on Elixir code that is used in Phoenix view modules.

eex

Place the caret on the desired line of the source code.
Do one of the following:
- Click the left gutter area at a line where you want to toggle a breakpoint
- Run > Toggle Line Breakpoint
- Cmd+F8

Describing Line Breakpoints

Open the Breakpoints dialog
Right-click the breakpoint you want to describe
Select "Edit description" from the context menu
In the "Edit Description" dialog box, type the desired description.

Searching for Line Breakpoints

Open the Breakpoints dialog
Start typing the description of the desired breakpoint

Jump to Breakpoint Source

To view the selected breakpoint without closing the dialog box, use the preview pane.
To open the file with the selected breakpoint for editing, double-click the desired breakpoint.
To close Breakpoints dialog, press Cmd+Down. The caret will be placed at the line marked with the breakpoint in question.

Disabling Line Breakpoints

When you temporarily disable or enable a breakpoint, its icon changes from Enabled breakpoint icon to Disabled breakpoint icon and vice versa.

Place the caret at the desired line with a breakpoint.
Do one of the following:
- Run > Toggle Breakpoint Enable
- Right-click the desired breakpoint icon, select or deselect the enabled check box, and then click Done.
- Alt-click the breakpoint icon

Deleting Line Breakpoints

Do one of the following:

In the Breakpoints dialog box, select the desired line breakpoint, and click the red minus sign.
In the editor, locate the line with the line breakpoint to be deleted, and click its icon in the left gutter.
Place caret on the desired line and press Cmd+F8.

Starting the Debugger Session

Select the run/debug configuration to execute
Do one of the following
- Click on the toolbar
- Run > Debug
- Ctrl+D

Debug quick menu

Ctrl+Alt+D
Select the configuration from the pop-up menu
Hit Enter

The debugged process will wait for the debugger to attach
Breakpoints will be set
The debugger will mark modules to be interpreted
1. The code paths will be scanned for .beam files
  - Code paths from the Elixir SDK will be skipped
  - .beam files will be interpreted unless they match the Module Filter Pattern
The debugger attaches (so it can receive breakpoint events) and allows the debugged process to continue.

Examining Suspended Program

Processes

The "Thread" drop-down lists the current processes in the local node. Only the current process is suspended. The rest of the processes are still running.

Frames

The Frames for the current process can be navigated up and down using the arrow keys or clicking on the frame.

Press Up or Down to change frames
Click the stack_frame from the list

Jump to Current Execution Point

When changing frames or jumping to definitions, you can lose track of where the debugger is paused. To get back to the current execution point, do one of the following:

Run > Show Execution Point.
Alt+F10
Click on the stepping toolbar of the Debug tool window.

Variables

Binaries show each byte at the byte's offset.

Bitstrings show each byte with any partial byte annotated with its bitwidth.

Boolean variables are rendered as their value.

Charlists show the integer values because they're treated as lists

Functions don't have literal representation, so the inspect form starting with #Fun<...> is shown

Lists render differently based on whether the list is improper or not. Improper lists show the head and tail while proper lists show their element by offset.

Floats and integers are rendered as literals.

Pids are broken up into their hidden node, id, and serial`.

Strings show their literal value and unicode is fully supported.

Tuples show their elements at their offsets.

Evaluate

When stopped at a breakpoint, you can use the Evaluate button (it looks like a simple pocket calculator) to open an editor to type code to be executed in the current stack frame.

The evaluator supports the full syntax.

The result of evaluating the code with be shown as the value of result below the entered "Expression".

Stepping

Action	Shortcut	Description
Show Execution Point	`Alt+F10`	Click this button to highlight the current execution point in the editor and show the corresponding stack frame in the Frames pane.
Step Over	`F8`	Click this button to execute the program until the next line in the current function or file, skipping the function referenced at the current execution point (if any). If the current line is the last one in the function, execution steps to the line executed right after this function.
Step Into	`F7`	Click this button to have the debugger step into the function called at the current execution point.
Step Out	`Shift+F8`	Click this button to have the debugger step out of the current function, to the line executed right after it.

Delimiters

Auto-inserting

The right-delimiter will be automatically inserted when the left delimiter is typed. In some cases, to prevent false positives, the the delimiter is only completed if when used for sigils.

Preceded By	Left	Right
	`do`	`end`
	`fn`	`end`
	`[`	`]`
	`{`	`}`
	`(`	`)`
	`'`	`'`
	`'''`	`'''`
	`"`	`"`
	`"""`	`"""`
	`<<`	`>>`
`~<sigil-name>`	`<`	`>`
`~<sigil-name>`	`/`	`/`
`~<sigil-name>`	`\|`	`\|`

Matching

All delimiters that are auto-inserted are also matched for highlighting

Left	Right
`do`	`end`
`fn`	`end`
`[`	`]`
`{`	`}`
`(`	`)`
`'`	`'`
`'''`	`'''`
`"`	`"`
`"""`	`"""`
`<<`	`>>`
`<`	`>`
`/`	`/`
`\|`	`\|`

Dialyzer

Inspection

Batch Mode

Analyze > Run Inspection by Name... (⌥⇧⌘I)
Type "Dialyzer"
Select "Dialyzer based inspections (Elixir)" from the shortened list
Hit Enter.

You'll be presented with a "Run 'Dialyzer based inspections (Elixir)'" dialog

Run 'Dialyzer based inspections (Elixir)'

Change the scope if you want.
Click "OK"

The Inspections Result Tool Pane will open and show results as each file is processed.

Click the ▶ to expand the Credo section to show all warnings
Click an entry for the details of an individual warning with a code highlighting.

Embedded Elixir (EEx) Templates

Form Template

Parameter Usage in Form Template

Advanced configuration

Preferences > Languages and Frameworks > Template Data Languages

See JetBrains Documentation for more details.

Live Embedded Elixir (LEEx) Templates

Index

Advanced configuration

Preferences > Languages and Frameworks > Template Data Languages

See JetBrains Documentation for more details.

HEEx Templates

~H sigils in .ex files use the same HEEx language, with separate HTML and Elixir PSI for the sigil's contents, once enabled - see ~H Sigil HEEx Language Injection Support below.

HEEx's special attributes (:let, :if, :for, :key, :type) and phx-* bindings are recognized on HTML tags, and <:slot> tags are not validated as HTML elements.

Building/Compiling

Settings

Build, Execution, Deployment > Compiler > Elixir Compiler

Compile project with mix (use mix compile instead of elixirc directly)
Attach docs (don't use --no-docs elixirc flag)
Attach debug info (don't use --no-debug-info elixirc flag)
Warnings as errors (use --warnings-as-errors elixirc flag)
Ignore module conflict (use --ignore-module-conflict elixirc flag)

Build Messages

Source

If a file has errors and warnings, they are group together in Build Messages under that file.

Errors and Warnings

Jump To Source

You can jump to errors and warnings in the Build Messages

Highlight the error or warning you want to jump to source
Do one of the following
1. Right-Click the error or warning
2. Select Jump to Source from the context menu
OR
1. Click the error or warning
2. Press Cmd+Down

You can also turn on Autoscroll to Source, which will Jump To Source whenever you Click or select an error or warning.

Autoscroll to Source

Warnings as Errors

Setting

If you enable Warnings as Errors in the settings, then the Warnings will be treated as Errors by elixirc and mix and the Build Messages will show the Warnings as Errors.

Messages

If only warnings remain in the source.

Source

With Warnings as Errors On, all the Warnings will appear as Errors and still fail the build

Errors

With Warnings as Errors Off, the Warnings will appear as Warnings and the build will succeed

Warnings

Individual File

Have a file selected in Project view with the Project view in focus OR have an Editor tab in focus
Build > Compile 'FILE_NAME'
Build results will be shown
- If compilation is successful, you'll see "Compilation completed successfully" in the Event Log
- If compilation had errors, you'll see "Compilation completed with N errors and M warnings" in the Event Log and the Messages Compile tab will open showing a list of Errors

Project

Build > Build Project
Build results will be shown
- If compilation is successful, you'll see "Compilation completed successfully" in the Event Log
- If compilation had errors, you'll see "Compilation completed with N errors and M warnings" in the Event Log and the Messages Compile tab will open showing a list of Errors

Live Templates

Live Templates can be customized in Preferences > Editor > Live Templates > Elixir.

Metasyntactic variables are locations where the cursor will jump to. END is the final location of the cursor.

Shortcut	Code
`@doc`	`@doc """ ONE """ END`
`case`	`case ONE do TWO -> END end`
`cond`	`cond do END end`
`def`	`def NAME do END end`
`def,`	`def NAME, do: END`
`defi`	`defimpl PROTOCOL, for: TYPE do END end`
`defm`	`defmodule ALIAS do END end`
`defmac`	`defmacro MACRO_NAME do END end`
`defmacp`	`defmacrop MACRO_NAME do END end`
`defover`	`defoverridable [NAME: END]`
`defp`	`defp NAME do END end`
`defpro`	`defprotocol PROTOCOL do END end`
`defs`	`defstruct [END]`
`do`	`do END end`
`doc`	`@doc """ ONE """ END`
`fn`	`fn ARGS -> END end`
`for`	`for A <- B do END end`
`if`	`if TRUE do END end`
`ife`	`if TRUE do OK else END end`
`ii`	`IO.inspect(END)`
`mdoc`	`@moduledoc """ ONE """ END`
`rec`	`receive do ONE -> END end`
`test`	`test "TESTDESC" do END end`
`try`	`try do ONE rescue TWO -> END`

Documentation

Editor

Documentation in @moduledoc, @typedoc or @doc module attribute values are marked as Markdown language, so that the JetBrains supplied Markdown support works in documentation.

Code Blocks

Code in code blocks (indented 4 spaces) are marked as Elixir language, so all the normal language support works in code examples and doctests.

This includes highlighting reads and writes of variables

and Go To Definition for calls

Toggling Editor to Rendered

Start with the Editor
Click the "Toggle Rendered View" button in the gutter next to the editor.
Rendered View will be shown

Rendered View

Markdown documentation in @moduledoc, @typedoc or @doc can be toggled back and forth from the editable Markdown view and the rendered HTML view.

Aliases link to Modules

In the rendered view, aliases are clickable and navigatable.

Clicking the links will show the documentation for module.

Using Go To Definition (Cmd+Click) on the link will take you to the module definition.

Toggling Rendered to Editor

Start with the Rendered View
Click the "Toggle Rendered View" button in the gutter next to the editor.
Editor will be shown

Quick Documentation

You can get documentation for functions and macros that have a @doc, aliases of modules that have a @moduledoc or types that have a @typedoc in a pop-up using Quick Documentation.

For a function

Place the cursor over the name of callback being referenced.
Display the documentation with either:
- A keyboard shortcut: F1 to show rendered @doc
- From the menu: View > Quick Documentation

For a function

Place the cursor over the name of function being called.
Display the documentation with either:
- A keyboard shortcut: F1 to show rendered @doc
- From the menu: View > Quick Documentation

For a module

Place the cursor on a fully-qualified module name
Display the documentation with either:
- A keyboard shortcut: F1 to show rendered @moduledoc
- From the menu: View > Quick Documentation

For a type

Place the cursor over the name of a type being used.
Display the documentation with either:
- A keyboard shortcut: F1 to show rendered @typedoc
- From the menu: View > Quick Documentation

For an Erlang module or function

For this to work, your Erlang/OTP installation must have been built with documentation.

Checking if docs are available:

If hovering over :lists or :math shows "No Documentation found", your OTP was built without docs. Many mise/asdf/kerl installations omit docs by default.

Installing Erlang with documentation via mise:

KERL_BUILD_DOCS=yes MISE_ERLANG_COMPILE=true mise install erlang@X.Y.Z

Replace X.Y.Z with your desired OTP version (e.g. 27.3.3). The key variables are:

KERL_BUILD_DOCS=yes -- tells kerl to build documentation (including .chunk files)
MISE_ERLANG_COMPILE=true -- forces a source build (pre-built binaries may not include docs)

Installing Erlang with documentation via asdf:

KERL_BUILD_DOCS=yes asdf install erlang X.Y.Z

After reinstalling Erlang with docs, restart the IDE so it re-indexes the .beam files.

OTP 23 and earlier: You may need to add CFLAGS="-O2 -g -Wno-error=implicit-function-declaration" to the install command to avoid compilation errors on newer toolchains.

Run/Debug Configurations

Distillery Release CLI

Distillery's mix release produces a CLI for running the release.

Build the release: mix release

==> Release successfully built!
    You can run it in one of the following ways:
      Interactive: _build/ENV/rel/NAME/bin/NAME console
      Foreground: _build/ENV/rel/NAME/bin/NAME foreground
      Daemon: _build/ENV/rel/NAME/bin/NAME start

Run > Edit Configurations...
Click +
Select "Distillery Release CLI"
Fill in the "Release CLI Path" with the full path to the _build/ENV/rel/NAME/bin/NAME path produed by mix release above.
Fill in the "Release CLI arguments".
- console runs a shell with the release loaded similar to iex -S mix.
- foreground to runs the release without a shell, like mix or mix run. The available commands are controlled by your release config rel/config.exs that Distillery uses.
(Optionally) fill in "erl arguments" with arguments to erl before it runs elixir. This is the same as the ERL_OPTS environment variable supported by Distillery.
(Optionally) fill in "elixir -extra arguments" with arguments to pass to elixir before it run the release. This is the same as the EXTRA_OPTS environment variable supported by Distillery.
(Optionally) change the Code Loading Mode This is the same as the CODE_LOADING_MODE environment variable supported by Distillery.
- Use Default - use whatever is configured in rel/config.exs. Don't set CODE_LOADING_MODE environment variable.
- embedded - load all code immediately on boot. Set CODE_LOADING_MODE=embedded.
- interactive - load code on-demand as it is needed/referenced. Set CODE_LOADING_MODE=interactive.
(Optionally) set the "Log Directory" This is the same as the RUNNER_LOG_DIR environment variable supported by Distillery.
(Optionally) change "Replace OS Vars" This is the same as the REPLACE_OS_VARS environment variable supported by Distillery.
- Use Default - use whatever is configured in rel/config.exs. Don't set REPLACE_OS_VARS environment variable.
- false - don't replace "${A_VAR_NAME}" in the generated configuration with A_VAR environment variable at runtime. Set REPLACE_OS_VARS=false.
- true - replace "${A_VAR_NAME}" in the generated configuration with A_VAR environment variable at runtime. Set REPLACE_OS_VARS=true.
(Optionally) set "sys.config File" This is the same the SYS_CONFIG_PATH environment variable supported by Distillery.
(Optionally) set "Release Config Directory". This is the same as the RELEASE_CONFIG_DIR environment variable supported by Distillery.
(Optionally) set "Pipe directory". This is the same as the PIPE_DIR environment variable supported by Distillery.
(Optionally) set "Use Pseudo-terminal (PTY). If checked use PTY for interactive shells. Automatically on when "Release CLI Arguments" starts with one of the known interactive commands (attach, console, console_boot, console_clean, or remote_console).
Fill in the "Working directory.
- Type the absolute path to the directory.
- Select the path using directory picker by clicking the ... button
(Optionally) click the ... button on the "Environment variables" line to add environment variables.
Click "OK" to save the Run Configuration and close the dialog

Running

Click the Run Arrow in the Toolbar to run the _build/ENV/rel/NAME/bin/NAME
The Run pane will open
- If the either "Use Pseduo-terminal (PTY)" is checked of the "Release CLI Arguments" are known to need a PTY, an interactive shell will appear in the Run pane where you can enter iex commands.
- Otherwise, the output of running the command will be shown.

Debugging

(Optionally) before debugging, customize the modules that will be interpreted.
1. Run > Edit Configurations...
2. Click the "Interpreted Modules" tab next to default "Configuration" tab.
3. Enable/Disable "Inherit Application Module Filters". Will change the Module Filters show in the below "Do not interpreter modules matching patterns" list.
4. Uncheck any inherited module filters that you would rather be interpreted and therefore debuggable
5. Click + to add module filters that are specific to this configuration. This can be useful if you know interpreting a specific module in your project's dependencies or project leads to too much slowdown when debugging or causes the debugger to hang/crash.
6. Click - to remove configuration-specific module filters added with +. Inherited module filters cannot be removed with -, they can only be disabled by unchecking.

Add the :debugger application to your release

Open rel/config.exs

In the release NAME block, in the set :applications block add :debugger:

--- a/rel/config.exs
+++ b/rel/config.exs
@@ -41,6 +41,8 @@ end
 release :intellij_elixir do
   set version: current_version(:intellij_elixir)
   set applications: [
+    # needed for IntelliJ Elixir debugger
+    :debugger,
     :runtime_tools
   ]
 end

For how to use the debugger, including how to set breakpoints see the Debugger section.
Click the Debug bug in the Toolbar to debug the mix tests

Elixir

Although it is exceedingly rare, as most Elixir projects use mix, it is supported to run/debug elixir directly, such as when doing elixir script.exs.

Run > Edit Configurations...
Click +
Select "Elixir"
Fill in the "elixir arguments".
(Optionally) fill in "erl arguments" with arguments to erl before it runs elixir.
Fill in the "Working directory"
- Type the absolute path to the directory.
- Select the path using directory picker by clicking the ... button
(Optionally) click the ... button on the "Environment variables" line to add environment variables.
Click "OK" to save the Run Configuration and close the dialog

With the Run Configuration defined, you can either Run or Debug elixir

Running

Click the Run arrow in the Toolbar to run elixir.
The Run pane will open, showing the results of elixir.

Debugging

(Optionally) before debugging, customize the modules that will be interpreted.
1. Run > Edit Configurations...
2. Click the "Interpreted Modules" tab next to default "Configuration" tab.
3. Enable/Disable "Inherit Application Module Filters". Will change the Module Filters show in the below "Do not interpreter modules matching patterns" list.
4. Uncheck any inherited module filters that you would rather be interpreted and therefore debuggable
5. Click + to add module filters that are specific to this configuration. This can be useful if you know interpreting a specific module in your project's dependencies or project leads to too much slowdown when debugging or causes the debugger to hang/crash.
6. Click - to remove configuration-specific module filters added with +. Inherited module filters cannot be removed with -, they can only be disabled by unchecking.
For how to use the debugger, including how to set breakpoints see the Debugger section.
Click the Debug bug in the Toolbar to debug elixir

IEx (Interactive Elixir)

Run > Edit Configurations...
Click +
Select "IEx"
(Optionally) fill in "iex arguments" with arguments to iex.
(Optionally) full in "erl arguments" with arguments to erl before it runs iex.
Fill in the "Working directory"
- Type the absolute path to the directory.
- Select the path using directory picker by clicking the ... button
(Optionally) click the ... button on the "Environment variables" line to add environment variables.
Click "OK" to save the Run Configuration and close the dialog

With the Run Configuration defined, you can either Run or Debug the iex configuration.

Running

Click the Run arrow in the Toolbar to run iex

Debugging

(Optionally) before debugging, customize the modules that will be interpreted.
1. Run > Edit Configurations...
2. Click the "Interpreted Modules" tab next to default "Configuration" tab.
3. Enable/Disable "Inherit Application Module Filters". Will change the Module Filters show in the below "Do not interpreter modules matching patterns" list.
4. Uncheck any inherited module filters that you would rather be interpreted and therefore debuggable
5. Click + to add module filters that are specific to this configuration. This can be useful if you know interpreting a specific module in your project's dependencies or project leads to too much slowdown when debugging or causes the debugger to hang/crash.
6. Click - to remove configuration-specific module filters added with +. Inherited module filters cannot be removed with -, they can only be disabled by unchecking.
For how to use the debugger, including how to set breakpoints see the Debugger section.
Click the Debug bug in the Toolbar to debug iex.

Mix Tasks

Much like rake tasks in Rubymine, this plugin can run mix tasks.

Run > Edit Configurations...
Click +
Select "Elixir Mix"
Fill in the "mix arguments" starting with the name of the mix task followed by any arguments to that task.
(Optionally) fill in "elixir arguments" with arguments to elixir before it runs mix.
(Optionally) fill in "erl arguments" with arguments to erl before it runs elixir.
Fill in the "Working directory"
- Type the absolute path to the directory.
- Select the path using directory picker by clicking the ... button
(Optionally) click the ... button on the "Environment variables" line to add environment variables.
Click "OK" to save the Run Configuration and close the dialog

With the Run Configuration defined, you can either Run or Debug the Mix Task

Running

Click the Run arrow in the Toolbar to run the mix task
The Run pane will open, showing the results of the mix task.
- If there is an error with a FILE:LINE stack stack_frame, it will be a clickable link that will take you to that location

Debugging

(Optionally) before debugging, customize the modules that will be interpreted.
1. Run > Edit Configurations...
2. Click the "Interpreted Modules" tab next to default "Configuration" tab.
3. Enable/Disable "Inherit Application Module Filters". Will change the Module Filters show in the below "Do not interpreter modules matching patterns" list.
4. Uncheck any inherited module filters that you would rather be interpreted and therefore debuggable
5. Click + to add module filters that are specific to this configuration. This can be useful if you know interpreting a specific module in your project's dependencies or project leads to too much slowdown when debugging or causes the debugger to hang/crash.
6. Click - to remove configuration-specific module filters added with +. Inherited module filters cannot be removed with -, they can only be disabled by unchecking.
For how to use the debugger, including how to set breakpoints see the Debugger section.
Click the Debug bug in the Toolbar to debug the mix task

IEx Mix

Run > Edit Configurations...
Click +
Select "IEx Mix"
(Optionally) fill in "mix arguments", such as phx.server if you want to launch Phoenix inside of iex.
(Optionally) fill in "iex arguments" with arguments to iex before -S mix.
(Optionally) full in "erl arguments" with arguments to erl before it runs iex.
Fill in the "Working directory"
- Type the absolute path to the directory.
- Select the path using directory picker by clicking the ... button
(Optionally) click the ... button on the "Environment variables" line to add environment variables.
Click "OK" to save the Run Configuration and close the dialog

With the Run Configuration defined, you can either Run or Debug iex -S mix

Running

Click the Run Arrow in the Toolbar to run iex -S mix

Debugging

(Optionally) before debugging, customize the modules that will be interpreted.
1. Run > Edit Configurations...
2. Click the "Interpreted Modules" tab next to default "Configuration" tab.
3. Enable/Disable "Inherit Application Module Filters". Will change the Module Filters show in the below "Do not interpreter modules matching patterns" list.
4. Uncheck any inherited module filters that you would rather be interpreted and therefore debuggable
5. Click + to add module filters that are specific to this configuration. This can be useful if you know interpreting a specific module in your project's dependencies or project leads to too much slowdown when debugging or causes the debugger to hang/crash.
6. Click - to remove configuration-specific module filters added with +. Inherited module filters cannot be removed with -, they can only be disabled by unchecking.
For how to use the debugger, including how to set breakpoints see the Debugger section.
Click the Debug bug in the Toolbar to debug iex -S mix.

`mix espec`

Using graphical formatter

If you override the default formatters you will need to add the following code to your spec_helper.exs.

If you override formatters similar to below

ESpec.configure fn(config) ->
  config.formatters ...

ESpec.configure fn(config) ->
  config.formatters [
      {ESpec.Formatters.Json, %{out_path: "results.json"}},
      {ESpec.Formatters.Html, %{out_path: "results.html"}},
      {ESpec.Formatters.Doc, %{details: true, out_path: "results.txt"}},
      {ESpec.Formatters.Doc, %{details: true, diff_enabled?: false, out_path: "results-no-diff.txt"}},
      {ESpec.CustomFormatter, %{a: 1, b: 2}},
    ]
end

Replace them with code that checks for the graphical formatter TeamCityESpecFormatter and uses only it when available.

ESpec.configure fn(config) ->
  config.formatters(if Code.ensure_loaded?(TeamCityESpecFormatter) do
    [{TeamCityESpecFormatter, %{}}]
  else
    ...
  end)
end

ESpec.configure fn(config) ->
  config.formatters(if Code.ensure_loaded?(TeamCityESpecFormatter) do
    [{TeamCityESpecFormatter, %{}}]
  else
    [
      {ESpec.Formatters.Json, %{out_path: "results.json"}},
      {ESpec.Formatters.Html, %{out_path: "results.html"}},
      {ESpec.Formatters.Doc, %{details: true, out_path: "results.txt"}},
      {ESpec.Formatters.Doc, %{details: true, diff_enabled?: false, out_path: "results-no-diff.txt"}},
      {ESpec.CustomFormatter, %{a: 1, b: 2}},
    ]
  end)
end

Creating `mix espce` Run Configurations Manually

Run > Edit Configurations...
Click +
Select "Elixir Mix ESpec"
Fill in the "mix espec arguments" with the argument(s) to pass to mix espec. Normally, this will be list of *_spec.exs files, relative to the "Working directory".

NOTE: Unlike mix test, mix espec does not support directories as arguments.
(Optionally) fill in "elixir arguments" with the arguments to elixir before it runs mix test.
(Optionally) fill in "erl arguments"with the arguments toerlbefore it runselixir`.
Fill in the "Working directory"
- Type the absolute path to the directory.
- Select the path using directory picker by clicking the ... button
(Optionally) click the ... button on the "Environment variables" line to add environment variables.
Click "OK" to save the Run Configuration and close the dialog

With the Run Configuration defined you can either Run or Debug the mix especs

Running

Click the Run arrow in the Toolbar to run the mix test task
The Run pane will open showing the Test Results

Debugging

(Optionally) before debugging, customize the modules that will be interpreted.
1. Run > Edit Configurations...
2. Click the "Interpreted Modules" tab next to default "Configuration" tab.
3. Enable/Disable "Inherit Application Module Filters". Will change the Module Filters show in the below "Do not interpreter modules matching patterns" list.
4. Uncheck any inherited module filters that you would rather be interpreted and therefore debuggable
5. Click + to add module filters that are specific to this configuration. This can be useful if you know interpreting a specific module in your project's dependencies or project leads to too much slowdown when debugging or causes the debugger to hang/crash.
6. Click - to remove configuration-specific module filters added with +. Inherited module filters cannot be removed with -, they can only be disabled by unchecking.
For how to use the debugger, including how to set breakpoints see the Debugger section.
Click the Debug bug in the Toolbar to debug the mix tests

While you can create Elixir Mix ESpec run configurations manually using the Run > Edit Configurations... menu, it is probably more convenient to use the context menu.

Creating `mix espec` Run Configurations from context

In the Project pane, ensure your OTP application's espec directory is marked as a Test Sources Root
Check if the espec directory is green. If it is, it is likely a Test Sources Root. This color may differ in different themes, so to be sure you can check the context menu
Right-click the test directory.
Hover over "Mark Directory As >"
- If "Unmark as Test Sources Root" is shown, then the directory is already configured correctly, and create from context will work.
- If "Test Sources Root" is shown, then the directory need to be configured by clicking that entry

Creating/Running `mix espec` Run Configurations from directory

Right-click the directory in the Project pane
Click "Run Mix ExUnit", which will both create the Run Configuration and Run it.
- If you want to only create the Run Configuration, select "Create Mix ESpec" instead

Alternatively, you can use keyboard shortcuts

Select the directory in the Project pane.
Ctrl+Shift+R will create the Run Configuration and Run it.

Creating/Running `mix espec` Run Configurations from file

Right-click the file in the Project pane
Click "Run Mix ESpec", which will both create the Run Configuration and Run it.
- If you want to only create the Run Configuration, select "Create Mix ESpec" instead

Alternatively, you can use keyboard shortcuts

Select the directory in the Project pane.
Ctrl+Shift+R will create the Run Configuration and Run it.

Finally, you can use the editor tabs

Right-click the editor tab for the test file you want to run
Click "Run Mix ESpec", which will both create the Run Configuration and Run it.
- If you want to only create the Run Configuration, select "Create Mix ESpec" instead

Creating/Running `mix espec` Run Configurations from line

If you want to be able to run a single test, you can create a Run Configuration for a line in that test

Right-click a line in the test file
Click "Run Mix ESpec", which will both create the Run Configuration and Run it.
- If you want to only create the Run Configuration, select "Create Mix ESpec" instead

Alternatively, you can use keyboard shortcuts

Place the cursor on the line you want to test
Ctrl+Shift+R will create the Run Configuration and Run it.

`mix test`

Creating `mix test` Run Configurations Manually

Run > Edit Configurations...
Click +
Select "Elixir Mix ExUnit"
Fill in the "mix test arguments" with the argument(s) to pass to mix test. Normally, this will be a directory like test, relative to the "Working directory"
(Optionally) fill in "elixir arguments" with the arguments to elixir before it runs mix test.
(Optionally) fill in "erl arguments"with the arguments toerlbefore it runselixir`.
Fill in the "Working directory"
- Type the absolute path to the directory.
- Select the path using directory picker by clicking the ... button
(Optionally) click the ... button on the "Environment variables" line to add environment variables.
Click "OK" to save the Run Configuration and close the dialog

With the Run Configuration defined you can either Run or Debug the mix tests

Running

Click the Run arrow in the Toolbar to run the mix test task
The Run pane will open showing the Test Results

Debugging

(Optionally) before debugging, customize the modules that will be interpreted.
1. Run > Edit Configurations...
2. Click the "Interpreted Modules" tab next to default "Configuration" tab.
3. Enable/Disable "Inherit Application Module Filters". Will change the Module Filters show in the below "Do not interpreter modules matching patterns" list.
4. Uncheck any inherited module filters that you would rather be interpreted and therefore debuggable
5. Click + to add module filters that are specific to this configuration. This can be useful if you know interpreting a specific module in your project's dependencies or project leads to too much slowdown when debugging or causes the debugger to hang/crash.
6. Click - to remove configuration-specific module filters added with +. Inherited module filters cannot be removed with -, they can only be disabled by unchecking.
For how to use the debugger, including how to set breakpoints see the Debugger section.
Click the Debug bug in the Toolbar to debug the mix tests

While you can create Elixir Mix ExUnit run configurations manually using the Run > Edit Configurations... menu, it is probably more convenient to use the context menu.

Creating `mix test` Run Configurations from context

The context menu must know that the the directory, file, or line you are right-clicking is a test. It does this by checking if the current directory or an ancestor is marked as a Test Sources Root.

In the Project pane, ensure your OTP application's test directory is marked as a Test Sources Root
Check if the test directory is green. If it is, it is likely a Test Sources Root. This color may differ in different themes, so to be sure you can check the context menu
Right-click the test directory.
Hover over "Mark Directory As >"
- If "Unmark as Test Sources Root" is shown, then the directory is already configured correctly, and create from context will work.
- If "Test Sources Root" is shown, then the directory need to be configured by clicking that entry

Creating/Running `mix test` Run Configurations from directory

Right-click the directory in the Project pane
Click "Run Mix ExUnit", which will both create the Run Configuration and Run it.
- If you want to only create the Run Configuration, select "Create Mix ExUnit" instead

Alternatively, you can use keyboard shortcuts

Select the directory in the Project pane.
Ctrl+Shift+R will create the Run Configuration and Run it.

Creating/Running `mix test` Run Configurations from file

Right-click the file in the Project pane
Click "Run Mix ExUnit", which will both create the Run Configuration and Run it.
- If you want to only create the Run Configuration, select "Create Mix ExUnit" instead

Alternatively, you can use keyboard shortcuts

Select the directory in the Project pane.
Ctrl+Shift+R will create the Run Configuration and Run it.

Finally, you can use the editor tabs

Right-click the editor tab for the test file you want to run
Click "Run Mix ExUnit", which will both create the Run Configuration and Run it.
- If you want to only create the Run Configuration, select "Create Mix ExUnit" instead

Creating/Running `mix test` Run Configurations from line

If you want to be able to run a single test, you can create a Run Configuration for a line in that test

Right-click a line in the test file
Click "Run Mix ExUnit", which will both create the Run Configuration and Run it.
- If you want to only create the Run Configuration, select "Create Mix ExUnit" instead

Alternatively, you can use keyboard shortcuts

Place the cursor on the line you want to test
Ctrl+Shift+R will create the Run Configuration and Run it.

`.beam` Files

.beam files are the compiled version of modules on the BEAM virtual machine used by Elixir and Erlang. They are the equivalent of .class files in Java.

.beam files are not detected purely by their file extension: the BEAM file format starts with a magic number, FOR1, that is checked for before decompiling.

.beam files have 2 editors registered: decompiled Text and BEAM Chunks

.beam file Editor Tabs

Decompression

If the .beam module was compiled with the compressed compiler directive, which in Erlang looks like

-compile([compressed])

and in Elixir looks like

@compile [:compressed]

BEAM Chunks

.beam files are composed of binary chunks. Each chunk is formatted

Offset	+0	+1	+2	+3
0	Name (ASCII Characters)
4	Length (`unsigned-big-integer`)
8+	Chunk-Specific

This format is generically referred to as Type-Length-Value

The BEAM Chunks editor tab is subdivided into further tabs, one for each chunk in the .beam file.

BEAM Chunks editor chunk tabs

The tabs are listed in the order that the chunks occur in the .beam file.

`Atom` / `AtU8`

Format

Offset	+0	+1
0	atom count (`unsigned-big-integer`)
4	length₁ (`unsigned-byte`)	bytes (for length₁)
4+length₁+...+length_n-1	length_n (`unsigned-byte`)	bytes (for length_n)

Tab

The Atom/AtU8 tab shows a table with the columns

Column	Description	Source
Index	1-based to match Erlang convention. In the `Code` chunk, `atom(0)` is reserved to always translate to `nil`	Derived
Byte Count	The byte count for the atom's bytes	Raw
Characters	From encoding the bytes as LATIN-1 for `Atom` chunk or UTF-8 for `AtU8` chunk	Derived

AtU8 Table

`Attr`

Format

The Attr chunk uses External Term Format (term_to_binary's output) to encode a proplist, which is similar to, but not quite the same an Elixir Keyword list

All modules will have a :vsn attribute that is either set explicitly or defaults to the MD5 of the module.

Tab

The Attr tab shows a table with the columns

Column	Description	Source
Key	Attribute name	Raw
Value	Attribute value. Note: The value always appears as a list as read from the binary format. I don't know why.	Raw

Attr Table

`CInf`

The CInf chunk is the Compilation Information for the Erlang or Erlang Core compiler. Even Elixir modules have it because Elixir code passes through this part of the Erlang Core compiler

Format

The CInf chunk uses External Term Format (term_to_binary's output) to encode a proplist, which is similar to, but not quite the same an Elixir Keyword list

Tab

The CInf tab shows a table with the columns

Column	Description	Source
Key	Option name	Raw
Value	Inspected value	Raw

CInf Table

`Code`

The Code chunk contains the byte code for the module.

Format

It is encoded in BEAM Compact Term Encoding, which differs from the binary format produced by term_to_binary.

Tab

The Code tab shows a read-only editor with one byte code operation on each line. For ease of reading, operations are grouped by function and then label block with indentation indicating scope.

Code Chunk Read-Only Editor

####### Controls

Control	On	Off
Inline Atoms	`atom(0)` is inlined as `nil`	`atom(N)` if "Inline Integers" is Off
Inline Atoms	`atom(n)` looks up index `n` in `Atom`/`AtU8` chunk and inlines its `inspect`ed version	`N` if "Inline Integers" is On and the argument supports "Inline Integers"
Inline Functions	`literal(n)` looks up index `n` in `FunT` chunk and inlines the name if the argument supports "Inline Functions"	`literal(n)` if "Inline Integers" is Off
Inline Functions		`n` if "Inline Integers" is On and the argument supports "Inline Integers"
Inline Imports	`literal(n)` looks up index `n` in `ImpT` and inlines it as a function reference: `&module.name/arity` if argument supports "Inline Functions"	`literal(n)` if "Inline Integers" Is Off
Inline Imports		`n` if "Inline Integers" is On and the argument supports "Inline Integers"
Inline Integers	`atom(n)` and `literal(n)` inline as `n` if argument supports "Inline Integers"	`atom(n)`, `integer(n)`, and `literal(n)`
Inline Integers	`integer(n)` inlines as `n`	`atom(n)`, `integer(n)`, and `literal(n)`
Inline Labels	`label(n)` inlines as `n` if argument supports "Inline Labels"	`label(n)`
Inline Lines	`line(literal(n))` looks up index `n` in the "Line Reference" table in the `Lines` chunk. The Line Reference contains a file name index and line. The file name index is looked up in the "File Name" table in the `Lines` chunk. The line from the Line Reference and the File name from the "File Name" table are inlined as `line(file_name: file_name, line: line)`.	`line` operations are left as is
Inline Literals	`literal(n)` looks up index `n` in `LitT` chunk and inlines its `inspect`ed version if the argument supports "Inline Literals"	`literal(n)`
Inline Local Calls	`label(n)` finds `label(n)` in `Code` chunk, then searches back for the previous `func_info` operation, then inlines it as a function reference: `&module.name/arity` if argument supports "Inline Local Calls"	`label(n)`
Inline Strings	Looks up `bit_length` and `byte_offset` into `StrT` chunk as their CharList value if supported by operation as value to `string` argument name	`bit_length` and `byte_offset`arguments are left as is
Show Argument Names	Adds keyword argument names before each argument value	Leaves values as positional arguments

If any of the inliners are incorrect or you have an argument name that makes more sense, please open an issue.

`Dbgi`

Format

Because the format is language neutral, the format is a set of nested, versioned formats. The outer most layer is

{:debug_info_v1, backend, metadata | :none}

For :debug_info_v1, Elixir's backend is :elixir_erl. The metadata for :elixir_erl is further versioned: {:elixir_v1, map, specs}.

map contains the bulk of the data.

Key	Value
`:attributes`	Attributes similar to the `Attr` chunk, but at the Elixir, instead of Core Erlang level. Usually they match with the exception that `attributes` doesn't contain `vsn` when `Attr` contains the `MD5` version
`:compile_opts`	Compilation options similar to `CInf` chunk's `options` key, but at for Elixir, instead of Core Erlang level.
`:definitions`	The Elixir `quoted` AST for reach function clause.
`:file`	The name of the file the module was generated from.
`:line`	The line in `:file` where the module was defined, such as the line `defmodule` occurred.
`:module`	The name of the module as an `atom`
`:unreachable`	Unreachable functions

Tab

The Dbgi tab appearance varies based on whether it was created with Erlang or Elixir, reflecting the fact that the Dbgi format is dependent on the backend that wrote it.

####### Elixir (:elixir_erl backend)

The Dbgi tab show the single value map entries: :file, :line, and :module.

Singletons

For the multi-value keys: :attributes, :compile_opts, and :definitions, there are individual tabs.

Multivalue Tabs

######## Attributes

The Attributes tab has the same format as the Attrs chunk.

Dbgi Attributes Table

######## Compile Options

The Compile Options tab is usually empty, much like the CInf options key for Erlang.

Table

######## Definitions

The Definitions tab is split between a tree of Module, Function/Arity and clauses.

Tree

Clicking on a clause will show only that clause, but clicking on a higher level in the tree will show all clauses in the function or the entire Module.

Clause Function Module

######## Type Specifications

The Type Specifications tab is split between a tree of the Module, Module Attribute, and type specifications.

Clicking on a type specification will show only that type specification, but clicking on a higher in the tree will show all type specifications for the same module attribute or the entire Module.

Optional Callback.png Optional Callbacks.png

####### Erlang (:erlang_abstract_code backend)

The Dbgi tab has Abstract Code and Compile Options tabs.

Dbgi Tabs

######## Abstract Code

The Abstract Code tab is split between a tree of Attributes, Functions, Function/Arity, and clauses.

Tree

Clicking on a clause will show only that clause, but clicking on a higher level in the tree will show all clauses in the function or the entire Module.

Clause Function Module

`ExDc`

Format

Tab

Like Dbgi, the ExDc tab is split between a tree to navigate and an editor to show the decompiled value.

ExDc Tree Function selected in ExDc tree

Click on a node in the tree will show all docs at that level and any descendants.

Node	Description
Root	All docs
Module	`@moduledoc`
Types	All `@typedoc`s
Types child	A specific `@typedoc`
Callbacks	All `@callback` `@doc`s
Callbacks child	A specific `@callback`'s `@doc`
Functions/Macros	All `@doc`s for functions/macros
Functions/Macros child	A specific function/macro's `@doc`

`ExpT`

Format

Tab

The ExpT tab shows a table with the columns

Column	Description	Source
Atom Index	Index into the `Atom` or `AtU8` chunk for the function's name	Raw
Name	The atom referenced by "Atom Index"	Derived
Arity	The arity (argument count) of the function	Raw
Label	Label index in the `Code` chunk where the function is defined. This label is usually immediately after the `func_info` operation and before the first pattern match or guard operation.	Raw

ExpT Table

`ImpT`

Format

Tab

The ImpT tab shows a table with the columns

Column	Description	Source
Index	0-based index used by references in the `Code` chunk.	Derived
Module Atom Index	Index into the `Atom` or `AtU8` chunk for the Module's name	Raw
Module Atom	The atom referenced by "Module Atom Index".	Derived
Function Atom Index	Index into the `Atom` or `AtU8` chunk for the functon's name	Raw
Function Atom	The atom referened by "Function Atom Index".	Derived

ImpT Table

`LitT`

The LitT chunk contains literals loaded as arguments in Code chunk.

Format

Tab

The LitT tab shows a table with the columns

Column	Description	Source
#	0-based index used by references in the `Code` chunk.	Derived
Term	The equivalent of `raw \|> binary_to_term() \|> inspect()`	Raw

LitT Table

`Line`

Format

The Line chunk is composed of 2 subsections: (1) Line References and (2) File Names. First there is a header setting up the number of each entry to expect.

Offset	+0	+1	+2	+3
0	emulator version (`unsigned-big-integer`)
4	flags (`unsigned-big-integer`)
8	Line Instruction Count (`unsigned-big-integer`)
12	Line Reference Count (`unsigned-big-integer`)
16	File Name Count (`unsigned-big-integer`)

####### Line References

This uses the Compact Term Format used for the Code chunk. The format ends up producing {file_name_index, line} pairs using the following algorithm:

Term	Interpretation
`atom(n)`	Change `file_name_index` to `n`
`integer(n)`	Add `{file_name_index, n}` to end of Line References

####### File Names

Offset	+0	+1	+2	+3
0	Byte Count (`unsigned-big-integer`)		Bytes

Tab

The Line tab has one subtab for each subsection in the tab. Each subsection has its own table.

Line References Table File Names TableTable

`LocT`

The LocT chunk is the dual to the ExpT chunk: it contains all private functions and macros.

Format

Tab

The LocT tab shows a table with the columns

Column	Description	Source
Atom Index	Index into the `Atom` or `AtU8` chunk for the function's name	Raw
Name	The atom referenced by "Atom Index"	Derived
Arity	The arity (argument count) of the function	Raw
Label	Label index in the `Code` chunk where the function is defined. This label is usually immediately after the `func_info` operation and before the first pattern match or guard operation.	Raw

LocT Table

`StrT`

The StrT chunk contains all Erlang strings (that is, Elixir charlists) used in the Code chunk.

Format

Tab

StrT Pool

Decompilation (Text)

Call definition macros

BEAM Chunk	Atom Prefix	Macro
`ExpT`	`MACRO-`	`defmacro`
`ExpT`	N/A	`def`
`LocT`	`MACRO-`	`defmacrop`
`LocT`	N/A	`defp`

`defp` with `/` in name

As an example, Kernel has

defp unquote(:"-MACRO-binding/2-fun-0-")(p0, p1, p2, p3) do
  # body not decompiled
end

which is generated from the for in

 defmacro binding(context \\ nil) do
    in_match? = Macro.Env.in_match?(__CALLER__)
    for {v, c} <- __CALLER__.vars, c == context do
      {v, wrap_binding(in_match?, {v, [generated: true], c})}
    end
  end

-- Kernel.binding/1

Special handling of call definition names

Handler	Name/Arity	Decompiled	Reason
Infix Operator	`!=/2`	`left != right`	Infix operators are defined in infix position
	`!==/2`	`left !== right`
	`&&/2`	`left && right`
	`&&&/2`	`left &&& right`
	`*/2`	`left * right`
	`=+/2`	`left + right`
	`=++/2`	`left ++ right`
	`-/2`	`left - right`
	`--/2`	`left -- right`
	`->/2`	`left -> right`
	`../2`	`left .. right`
	`//2`	`left / right`
	`::/2`	`left :: right`
	`</2`	`left < right`
	`<-/2`	`left <- right`
	`<<</2`	`left <<< right`
	`<<~/2`	`left <<~ right`
	`<=/2`	`left <= right`
	`<>/2`	`left <> right`
	`<\|>/2`	`left <\|> right`
	`<~/2`	`left <~ right`
	`<~>/2`	`left <~> right`
	`=/2`	`left = right`
	`==/2`	`left == right`
	`===/2`	`left === right`
	`=>/2`	`left => right`
	`=~/2`	`left =~ right`
	`>/2`	`left > right`
	`>=/2`	`left >= right`
	`>>>/2`	`left >>> right`
	`\\/2`	`left \\\\ right`
	`^/2`	`left ^ right`
	`^^^/2`	`left ^^^ right`
	`and/2`	`left and right`
	`in/2`	`left in right`
	`or/2`	`left or right`
	`\|>/2`	`left \|> right`
	`\|\|/2`	`left \|\| right`
	`\|\|\|/2`	`left \|\|\| right`
	`~=/2`	`left ~= right`
	`~>/2`	`left ~> right`
	`~>>/2`	`left ~>> right`
Prefix Operator	`+/1`	`(+value)`	To prevent precedence errors, unary prefix operators, which also have binary infix operators of the same name need to be defined inside parentheses
Prefix Operator	`-/1`	`(-value)`
Unquoted	`%/2`	`unquote(:%)(p0, p1)`	Special forms need to defined as atom passed to unquote, as special forms are handled before macros defining the calls are applied
	`%{}/1`	`unquote(:%{})(p0)`
	`&/1`	`unquote(:&)(p0)`
	`./2`	`unquote(:.)(p0, p1)`
	`<<>>/1`	`unquote(:<<>>)(p0)`
	`do/n`	`unquote(:do)(p0, ...)`	Keywords need to be escaped
	`fn/1`	`unquote(:fn)(p0)`	Special forms need to defined as atom passed to unquote, as special forms are handled before macros defining the calls are applied
	`unquote/1`	`unquote(:unquote)(p0)`
	`unquote_splicing/1`	`unquote(:unquote_splicing)(p0)`
	`{}/n`	`unquote(:{})(p0, ...)`
	`Capitalized/n`	`unquote(:Capitalized)(p0, ...)`	Part of the Corba libraries in OTP have functions starting with a capital letter, which would be parsed as an Alias in Elixir if not unquoted.
	`#text#/1`	`unquote(:"#text#")(p0)`	Part of the XML libraries in OTP have functions that start with or contain `#`, which would parse as a comment in Elixir if not unquoted in a double quoted atom.
Default	`name/n`	`name(p0, ...)`	If no specialized handler is required, functions and macros are defined normally with pN for each parameter in the Nth position

Completion

Aliases and Modules

When you start typing an Alias, completion will look in three locations:

alias aliased names in the current file
1. Suffix for alias Prefix.Suffix
2. MultipleAliasA or MultipleAliasB for alias Prefix.{MultipleAliasA, MultipleAliasB}
3. As for alias Prefix.Suffix, as: As
Indexed module names (as available from Go To Symbol)
1. Prefix.Suffix from defmodule Prefix.Suffix
2. MyProtocol from defprotocol MyProtocol
3. MyProtocol.MyStruct
  1. defimpl MyProtocol, for: MyStruct
  2. defimpl MyProtocol nested under defmodule MyStruct
Nested modules under aliased names
1. Suffix.Nested for alias Prefix.Suffix where Prefix.Suffix.Nested is an indexed module, implementation or protocol name.
2. MultipleAliasA.Nested for alias Prefix.{MultipleAliasA, MultipleAliasB} where Prefix.MultipleAliasA.Nested alias Prefix.{MultipleAliasA, MultipleAliasB} is an indexed module, implementation or protocol name.
3. As.Nested for alias Prefix.Suffix, as: As where Prefix.Suffix.Nested is an indexed module, implementation, or protocol name.

Aliases inside `{ }`

Function and Macro Calls

Function and Macro Calls Completion

Qualified

Unqualified

Function and macro calls that are unqualified are completed from the index of all function and macro definitions, both public and priva

Truncated — view the full README on GitHub.

Similar repos

judasn/IntelliJ-IDEA-Tutorial

IntelliJ IDEA 简体中文专题教程

22,066

shared topics

Kotlin/kotlin-lsp

Kotlin Language Server and plugin for Visual Studio Code

3,496

similar language mix

JetBrains/intellij-plugins

Open-source plugins included in the distribution of IntelliJ IDEA Ultimate and other IDEs based on…

2,269

similar language mix

DetachHead/rebased

A git client based on the IntelliJ platform

5,509

similar language mix

JetBrains/intellij-community

IntelliJ IDEA & IntelliJ Platform

20,522

similar language mix

ZalithLauncher/ZalithLauncher2

A Minecraft: Java Edition Launcher for Android

1,817

similar language mix

mishka-group/mishka_chelekom

Mishka Chelekom is a fully featured components and UI kit library for Phoenix & Phoenix LiveView

750

similar language mix

sghpjuikit/player

Audio player and management application.

similar language mix

Contributors

(top 30 of 56)

5,282 commits

649 commits

287 commits

25 commits

Languages

Kotlin

47.2%

Elixir

32.9%

Java

18.3%

KronicDeth/intellij-elixir

README

Table of Contents

Elixir plugin

IDEs

Features

Project

From Existing Sources

Import project from external model

Create project from existing sources

New

Project Structure

Project Settings

SDK Setup Known Limitations

Windows Subsystem for Linux (WSL) Support

WSL Limitations

Module Settings

Sources

Paths

Dependencies

SDK Status Widget

New Elixir File

Empty module

Elixir Application

Elixir Supervisor

Elixir GenServer

Elixir GenEvent

Syntax Highlighting and Semantic Annotation

Grammar parsing

Inspections

Ambiguous nested calls

Ambiguous parentheses

Empty Parentheses

Keywords in Parentheses

Positional arguments in Parentheses

Keyword pair colon (:) used in type spec instead of type operator (::)

Keywords appear before the end of list.

Match operator (=) used in type spec instead of type operator (::)

Quick Fixes

Convert : to :: in type specs

Convert = to :: in type specs

Remove space in front of ambiguous parentheses

Code Folding

Controls

Collapsing

Expanding

Regions

Commenter

Credo

Inspection

Batch Mode

Configuration

Annotator

Disable Explanation

Disable inspection

Debugger

Steps

Basics

Keyboard Shortcuts

Excluding Modules

Disabling Existing Module Patterns

Editing Existing Module Patterns

Removing Existing Module Patterns

Adding New Module Patterns

Environment Variables

Breakpoints

Accessing Breakpoint Properties

Viewing all breakpoints

Viewing a single breakpoint

Configuring Breakpoints

Creating Line Breakpoints

Describing Line Breakpoints

Searching for Line Breakpoints

Jump to Breakpoint Source

Disabling Line Breakpoints

Deleting Line Breakpoints

Starting the Debugger Session

Examining Suspended Program

Processes

Frames

Keyword pair colon (`:`) used in type spec instead of type operator (`::`)

Match operator (`=`) used in type spec instead of type operator (`::`)

Convert `:` to `::` in type specs

Convert `=` to `::` in type specs

`mix espec`

Creating `mix espce` Run Configurations Manually

Creating `mix espec` Run Configurations from context

Creating/Running `mix espec` Run Configurations from directory

Creating/Running `mix espec` Run Configurations from file

Creating/Running `mix espec` Run Configurations from line

`mix test`

Creating `mix test` Run Configurations Manually

Creating `mix test` Run Configurations from context

Creating/Running `mix test` Run Configurations from directory

Creating/Running `mix test` Run Configurations from file

Creating/Running `mix test` Run Configurations from line