What IDE/Editor do you use for Elixir?

Null-logic-0

What IDE or editor are you using for Elixir development?

Personally, I use Zed, and I really like it, but sometimes I wish there were a more dedicated IDE/editor specifically for Elixir.

Something built around Elixir, OTP, Phoenix, LiveView, Mix, IEx, etc.

Do you think there is a need for something like this?

And if someone started an open-source Elixir-first editor, would you be interested in helping build it?

Also, what features do you feel are missing from your current editor?

36 comments

/phoenix #code-editors #development #learning-elixir

2 2293 36

2026-10-05 18:44:51 UTC

Showing Posts 1 to 10

Show Best Posts
Show All (oldest first)
Show All (newest first)

dimitarvp

Neovim. The LazyVim “distro” with my own preferences on top (not many, the thing is great out of the box).

Amazingly fast and bug-free. Rarely have I seen such a good work done with editor plugins collection (distro). Very happy with it.

Post #1

NobbZ

Hi,

there exists Which code editor or IDE do you use? (Poll) (2022 Edition), and I thought there would be '23, '24, and so on editions as well, though my search-fu isn’t strong today…

To add to the actual topic:

I do use neovim, with a handcrafted config, not any distribution.

The config is public at https://github.com/nobbz/nobbz-vim, in case you are interested.

In case you are a nix user and have flakes enabled, you can even testrun it using nix run github:nobbz/nobbz-vim.

Post #2

DaAnalyst

IntelliJ IDEA

Post #3

kevinschweikert

For me it’s just missing automatic file reload.
I don’t feel the need for any plugins because it hat LSP/Treesitter/Fuzzy Search builtin but there is an open PR for an embedded Scheme plugin language which is eagerly awaited

github.com/helix-editor/helix

Add Steel as an optional plugin system (#8675)

master ← mattwparas:steel-event-system

opened 04:12AM - 31 Oct 23 UTC

mattwparas

+19486 -821

Notes: * I still need to rebase up with the latest master changes, however doi…ng so causes some headache with the lock file, so I'll do it after some initial feedback. Also, this depends on the event system in #8021. * The large diff size is a combination of lock file changes + the dependency on the event system PR. The diff has ended up quite large with all of the other stuff * I'm currently pointing to the master branch of steel as a dependency. This will point to a stable release on crates once I cut a release. ----- Opening this just to track progress on the effort and gather some feedback. There is still work to be done but I would like to gather some opinions on the direction before I continue more. You can see my currently functioning helix config [here](https://github.com/mattwparas/helix-config/tree/master) and there are instructions listed in the `STEEL.md` file. The main repo for steel lives [here](https://github.com/mattwparas/steel), however much documentation is in works and will be added soon. The bulk of the implementation lies in the `engine.rs` and `scheme.rs` files. # Design Given prior conversation about developing a custom language implementation, I attempted to make the integration with Steel as agnostic of the engine as possible to keep that door open. The interface I ended up with (which is subject to change and would love feedback on) is the following: ```rust pub trait PluginSystem { /// If any initialization needs to happen prior to the initialization script being run, /// this is done here. This is run before the context is available. fn initialize(&self) {} fn engine_name(&self) -> PluginSystemKind; /// Post initialization, once the context is available. This means you should be able to /// run anything here that could modify the context before the main editor is available. fn run_initialization_script(&self, _cx: &mut Context) {} /// Allow the engine to directly handle a keymap event. This is some of the tightest integration /// with the engine, directly intercepting any keymap events. By default, this just delegates to the /// editors default keybindings. #[inline(always)] fn handle_keymap_event( &self, _editor: &mut ui::EditorView, _mode: Mode, _cxt: &mut Context, _event: KeyEvent, ) -> Option<KeymapResult> { None } /// This attempts to call a function in the engine with the name `name` using the args `args`. The context /// is available here. Returns a bool indicating whether the function exists or not. #[inline(always)] fn call_function_if_global_exists( &self, _cx: &mut Context, _name: &str, _args: &[Cow<str>], ) -> bool { false } /// This is explicitly for calling a function via the typed command interface, e.g. `:vsplit`. The context here /// that is available is more limited than the context available in `call_function_if_global_exists`. This also /// gives the ability to handle in progress commands with `PromptEvent`. #[inline(always)] fn call_typed_command_if_global_exists<'a>( &self, _cx: &mut compositor::Context, _input: &'a str, _parts: &'a [&'a str], _event: PromptEvent, ) -> bool { false } /// Given an identifier, extract the documentation from the engine. #[inline(always)] fn get_doc_for_identifier(&self, _ident: &str) -> Option<String> { None } /// Fuzzy match the input against the fuzzy matcher, used for handling completions on typed commands #[inline(always)] fn available_commands<'a>(&self) -> Vec<Cow<'a, str>> { Vec::new() } /// Retrieve a theme for a given name #[inline(always)] fn load_theme(&self, _name: &str) -> Option<Theme> { None } /// Retrieve the list of themes that exist within the runtime #[inline(always)] fn themes(&self) -> Option<Vec<String>> { None } /// Fetch the language configuration as monitored by the plugin system. /// /// For now - this maintains backwards compatibility with the existing toml configuration, /// and as such the toml error is exposed here. #[inline(always)] fn load_language_configuration(&self) -> Option<Result<Configuration, toml::de::Error>> { None } } ``` If you can implement this, the engine should be able to be embedded within Helix. On top of that, I believe what I have allows the coexistence of multiple scripting engines, with a built in priority for resolving commands / configurations / etc. As a result, Steel here is entirely optional and also remains completely backwards compatible with the existing toml configuration. Steel is just another layer on the existing configuration chain, and as such will be applied last. This applies to both the `config.toml` and the `languages.toml`. Keybindings can be defined via Steel as well, and these can be buffer specific, language specific, or global. Themes can also be defined from Steel code and enabled, although this is not as rigorously tested and is a relatively recent addition. Otherwise, I have been using this as my daily driver to develop for the last few months. I opted for a two tiered approach, centered around a handful of design ideas that I'd like feedback on: The first, there is a `init.scm` and a `helix.scm` file - the `helix.scm` module is where you define any commands that you would like to use at all. Any function exposed via that module is eligible to be used as a typed command or via a keybinding. For example: ```scheme ;; helix.scm (provide shell) ;;@doc ;; Specialized shell - also be able to override the existing definition, if possible. (define (shell cx . args) ;; Replace the % with the current file (define expanded (map (lambda (x) (if (equal? x "%") (current-path cx) x)) args)) (helix.run-shell-command cx expanded helix.PromptEvent::Validate)) ``` This would then make the command `:shell` available, and it will just replace the `%` with the current file. The documentation listed in the `@doc` doc comment will also pop up explaining what the command does: ![image](https://github.com/helix-editor/helix/assets/34500476/b45b942e-9edd-406f-ba1c-0fc2cf8ee72e) Once the `helix.scm` module is `require`'d - then the `init.scm` file is run. One thing to note is that the `helix.scm` module does _not_ have direct access to a running helix context. It must act entirely stateless of anything related to the helix context object. Running `init.scm` gives access to a helix object, currently defined as `*helix.cx*`. This is something I'm not sure I particularly love, as it makes async function calls a bit odd - I think it might make more sense to make the helix context just a global inside of a module. This would also save the hassle that every function exposed has to accept a `cx` parameter - this ends up with a great deal of boilerplate that I don't love. Consider the following: ```scheme ;;@doc ;; Create a file under wherever we are (define (create-file cx) (when (currently-in-labelled-buffer? cx FILE-TREE) (define currently-selected (list-ref *file-tree* (helix.static.get-current-line-number cx))) (define prompt (if (is-dir? currently-selected) (string-append "New file: " currently-selected "/") (string-append "New file: " (trim-end-matches currently-selected (file-name currently-selected))))) (helix-prompt! cx prompt (lambda (cx result) (define file-name (string-append (trim-start-matches prompt "New file: ") result)) (temporarily-switch-focus cx (lambda (cx) (helix.vsplit-new cx '() helix.PromptEvent::Validate) (helix.open cx (list file-name) helix.PromptEvent::Validate) (helix.write cx (list file-name) helix.PromptEvent::Validate) (helix.quit cx '() helix.PromptEvent::Validate))) (enqueue-thread-local-callback cx refresh-file-tree))))) ``` Every function call to helix built ins requires passing in the `cx` object - I think just having them be able to reference the global behind the scenes would make this a bit ergonomic. The integration with the helix runtime would make sure whether that variable actually points to a legal context, since we pass this in via reference, so it is only alive for the duration of the call to the engine. ### Async functions Steel has support for async functions, and has successfully been integrated with the tokio runtime used within helix, however it requires constructing manually the callback function yourself, rather than elegantly being able to use something like `await`. More to come on this, since the eventual design will depend on the decision to use a local context variable vs a global one. ## Built in functions The basic built in functions are first all of the function that are typed and static - i.e. everything here: * [Typed](https://github.com/helix-editor/helix/blob/d171e23f72e9ada8ba5cd39516f91aa95392cea9/helix-term/src/commands/typed.rs#L3013) * [Static](https://github.com/helix-editor/helix/blob/d171e23f72e9ada8ba5cd39516f91aa95392cea9/helix-term/src/commands.rs#L224) However, these functions don't return values so aren't particularly useful for anything but their side effects to the editor state. As a result, I've taken the liberty of defining functions as I've needed/wanted them. Some care will need to be decided what those functions actually exposed are. # Examples Here are some examples of plugins that I have developed using Steel: ## File tree Source can be found [here](https://github.com/mattwparas/helix-config/blob/master/cogs/file-tree.scm) [filetree.webm](https://github.com/helix-editor/helix/assets/34500476/57a91523-1da1-4dd5-af84-86263731d370) ## Recent file picker Source can be found [here](https://github.com/mattwparas/helix-config/blob/master/cogs/recentf.scm) [recent-files.webm](https://github.com/helix-editor/helix/assets/34500476/e6a13314-9c65-48e6-9069-3f5d85d9add4) This persists your recent files between sessions. ## Scheme indent Since steel is a scheme, there is a relatively okay scheme indent mode that only applied on `.scm` files, which can be found [here](https://github.com/mattwparas/helix-config/blob/master/cogs/scheme-indent.scm). The implementation requires a little love, but worked enough for me to use helix to write scheme code :smile: ### Terminal emulator I did manage to whip up a terminal emulator, however paused the development of it while focusing on other things. When I get it back into working shape, I will post a video of it here. I am not sure what the status is with respect to a built in terminal emulator, but the one I got working did not attempt to do complete emulation, but rather just maintained a shell to interact with non-interactively (e.g. don't try to launch helix in it, you'll have a bad time :smile: ) ## Steel as a choice for a language I understand that there is skepticism around something like Steel, however I have been working diligently on improving it. My current projects include shoring up the documentation, and working on an LSP for it to make development easier - but I will do that in parallel with maintaining this PR. If Steel is not chosen and a different language is picked, in theory the API I've exposed should do the trick at least with matching the implementation behavior that I've outlined here. ## Pure rust plugins As part of this, I spent some time trying to expose a C ABI from helix to do rust to rust plugins directly in helix without a scripting engine, with little success. Steel supports loading dylibs over a stable abi (will link to documentation once I've written it). I used this to develop the proof of concept terminal emulator. So, you might not be a huge fan of scheme code, but in theory you can write mostly Rust and use Steel as glue if you'd like - you would just be limited to the abi compatible types. ## System compatibility I develop off of Linux and Mac - but have not tested on windows. I have access to a windows system, and will get around to testing on that when the time comes.

Post #4

mudasobwa

Creator of Cure

NeoVim/LunarVim

Last 15 years people tend to resolve different languages in editors via LSP (and MCP nowadays.) The last language-specific IDE I can recall was MS Visual Studio.

That being said, I honestly see zero sense in creating new editor, that effort might be better put into improving your LSP/MCP, which I already did with ragex for my own happiness.

Post #5

webofbits

Neovim with my own lua files. Simple and fast! GitHub - ccarvalho-eng/nvim-elixir-config: Opinionated Neovim config for Elixir · GitHub

Post #6

webofbits

I used LazyVim, but after a while it began to feel slow and bloated with features I never used. I also had to add my own Elixir test plugin because the built-in one didn’t pause the output for debugging, at least the last time I used it. A minimal configuration also makes me more comfortable since I can customize it exactly to my liking without reading Lazyvim documentation.

Post #7

dimitarvp

Interesting – I never once used debugging so I am blind to those defects.

To me it’s still super fast and I use it on an aging Intel Mac, a Ryzen laptop, and a WSL VM inside a mid-range gaming machine – it’s practically instant for anything I need from it on all places.

Bloat I am not too worried about. As long as the editor is snappy, which it is.

Post #8

webofbits

I see. The thing is that you dont need much with Neovim. I even had a one file config with all I needed for work so at some point plugins become mostly cosmetic stuff for better visual/UX

Post #9

AndyL

What IDE or editor are you using for Elixir development?

Neovim - great editor, strong community, steady improvement. Claude is good at editing Neovim config files and lua scripts.

Also, what features do you feel are missing from your current editor?

IMO, biggest bang for the buck would be contributions to Expert (code actions eg rename module, extract variable, etc.)

Post #10

Load more posts (26 remaining)

Where Next?

View thread on forum (has 36 replies!)

phoenix

code-editors

development

learning-elixir

Home Chat & Discussions>Discussions

61 2124 36

Last post

REPLY VIEW THREAD WITH 36 POSTS

What IDE/Editor do you use for Elixir?

Null-logic-0

Showing Posts 1 to 10 Show Best PostsShow All (oldest first)Show All (newest first)

dimitarvp

NobbZ

DaAnalyst

kevinschweikert

mudasobwa

webofbits

webofbits

dimitarvp

webofbits

AndyL

Where Next?

Trending in Discussions

I genuinely hate programming now

Remote Elixir Book Club (takes place on Discord)

Stack Overflow Developer Survey 2026

Emacs like text editor in Elixir

How does Elixir keep going?

Adding a handle_info callback to LiveComponents

What IDE/Editor do you use for Elixir?

Other Trending Topics

Mob - Native BEAM / Elixir on Native Mobile

State of developing agents with Elixir (not coding agents)

Yoke - the DeepSeek Harness (former DSH)

ExRatatui - Elixir bindings for the Rust ratatui terminal UI library

Emily - A new MLX-based backend for Nx

Why AI dream is a non sense and will die

Latest Phoenix Threads

Chat & Discussions>Discussions

Latest on Elixir Forum

Sponsor Spotlight

Our Sponsors

Categories:

Sub Categories:

Forums

Popular Tags

Our Sponsors

We're in Beta

Options

Thread Display Mode

Thread Preview

Showing Posts 1 to 10

Show Best Posts
Show All (oldest first)
Show All (newest first)