-
-
Notifications
You must be signed in to change notification settings - Fork 160
Support 2025.2+ IDEs #3711
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Support 2025.2+ IDEs #3711
Conversation
adad16c
to
6fbfa00
Compare
This adds initial support for 2025.2, upgrades to Kotlin 2.2, fixes the SDK adding issue for Erlang/Elixir, and a bunch of other issues. Still much more writeActions to be converted.. |
Thank you! Some immediate feedback: I'm able to add my Elixir SDK back, which is great.
|
@Lutrome Great feedback - thanks so much for testing! Interesting re/ colour schemes, that seemed to work for me, will double check. 2/3 will hopefully be fixed with the deprecation changes (coming next). Will add these as bugs. |
Yeah, the coloring issue is a bit annoying (it still bolds and italicizes definitions), but definitely not a dealbreaker - grateful for all the work that's being put into this! However, the functionality is mostly intact, which is good. |
One more piece of feedback - I installed the EAP ZIP on my work machine and it works fine on my work projects, except that the Run/Test configs don't work well, or even at all... When trying to run some of my unit tests on a Phoenix application, the test runner just stayed hanging on "Initializing tests" and "The database for [redacted].Repo has been dropped" then nothing else happened. I checked the logs afterwards but couldn't immediately find anything that stood out. Then again, there were a lot of log lines to trudge through. Edited to add clarification: On the work machine, the Run/Test configs don't nag me about installing Hex, like it does on my personal machine. However, when I try a Run config (not a Test config) with a "Load this .env file" step pointing to an .env file in my project, it straight up does NOT load the .env file and gleefully runs anyways, causing my application to fail locally. I have to use the terminal instead for now. |
Hi! Thanks for the updated plugin zip! I've installed it and tested changing colors - works perfectly fine for me! However, when I set it back to the default color, it turns white/colorless again. Technically, the macro functionality is working in that it's appropriately bolded and indented, just not the coloring. I'm using the Catppuccin theme plugin, with the Catpuccin Macchiato theme loaded.
Also, I'm using |
I believe the colours have always been a bit finnicky, as I had dramas with getting them "just right" a few years ago, and just override everything. Can I also confirm that you can see your Erlang ebin's in the Erlang/Elixir SDK setup? Thanks so much for the testing! 👐 Edit: Also, I've submitted the EAP to JetBrains, right now it's manual for them to process the plugin, but we should have a "EAP" channel up soon that'll allow you to autoupdate to newer versions. |
Now that I look closer, it seems that no definition macros (defmodule, def, defp, really any def*) are colored unless overridden even though they are properly bolded and italicized... :/ Edit: I'll probably try reinstalling my IDE at some point. But also, the Run/Test config still seems to run from my home directory which causes it to nag me about installing Hex. |
Figured it out.. Clicking
![]()
![]()
![]()
![]() So unsure why it's for example orange by default, files are here: https://github.com/joshuataylor/intellij-elixir/tree/main/resources/colorSchemes |
Yeah, I just checked that directory and the file you pointed out, but looks like there are inconsistencies between For example, in the XML file, there is a foreground color (cc7832) for |
Great spot - we're missing: ELIXIR_INTERPOLATION |
Good news - this was a fairly easy fix, I've rewritten the main module SDK stuff a bit, and the "small" IDEs now also work.
I've added a new action that allows you to fix a broken Elixir SDK, though honestly you should just readd it, an action to delete Elixir SDKs that works on both the IntelliJ and small IDEs. This is because you can get your settings in a weird state that is confusing to recover from, and this should hopefully fix it. Behind the more experimental side is a new status bar that shows if your SDK is configured (inspired from PyCharm), and I've added the elixir heredoc HTML injection work in as well. (This will be used in future with the LSP work ). This is experimental features are controlled via the settings menu right now. There is no real way to figure out if we are breaking EDT, as AFAIK this is only via UI test, that need junit5? I'm also digging into the colours - this will be used for the LSP work, I'm sure, so it's worth it. New EAP shortly. Thanks for the reports sorry far, and testing on additional OSs |
I found yet another problem - the Credo inspection doesn't work and hangs. Won't even complete cancelling. In both cases, the logs have the exact same output:
|
Oh absolutely, there are so many subsystems being used that are now
completely broken, even though JetBrains considers them deprecated.
Certain things isn't worth the effort (especially as LSP/Expert will
probably solve a lot of it), and the current focus is to fix things to
atleast be usable , and hopefully then focus on taking what we can into
something more maintainable.
…On Sun, 7 Sept 2025, 9:07 am Nathan Olson, ***@***.***> wrote:
*Lutrome* left a comment (KronicDeth/intellij-elixir#3711)
<#3711 (comment)>
I found yet *another* problem - the Credo inspection doesn't work and
hangs. Won't even complete cancelling.
In both cases, the logs have the exact same output:
2025-09-06 18:04:44,684 [ 211854] WARN - #c.i.e.p.BaseOSProcessHandler - Process hasn't generated any output for a long time.
If it's a long-running mostly idle daemon process, consider overriding OSProcessHandler#readerOptions with 'BaseOutputReader.Options.forMostlySilentProcess()' to reduce CPU usage.
Command line: /Users/nathan/.asdf/installs/erlang/28.0.2/bin/erl -pa /Users/nathan/.asdf/installs/erlang/28.0.2/lib -pa /Users/nathan/.asdf/installs/elixir/1.18.4-otp-28/lib/logger/ebin -pa /Users/nathan/.asdf/installs/elixir/1.18.4-otp-28/lib/elixir/ebin -pa /Users/nathan/.asdf/installs/elixir/1.18.4-otp-28/lib/ex_unit/ebin -pa /Users/nathan/.asdf/installs/elixir/1.18.4-otp-28/lib/mix/ebin -pa /Users/nathan/.asdf/installs/elixir/1.18.4-otp-28/lib/eex/ebin -pa /Users/nathan/.asdf/installs/elixir/1.18.4-otp-28/lib/iex/ebin -pa /Users/nathan/.asdf/installs/erlang/28.0.2/lib/ftp-1.2.4/ebin -pa /Users/nathan/.asdf/installs/erlang/28.0.2/lib/parsetools-2.7/ebin -pa /Users/nathan/.asdf/installs/erlang/28.0.2/lib/eldap-1.2.16/ebin -pa /Users/nathan/.asdf/installs/erlang/28.0.2/lib/eunit-2.10/ebin -pa /Users/nathan/.asdf/installs/erlang/28.0.2/lib/runtime_tools-2.2/ebin -pa /Users/nathan/.asdf/installs/erlang/28.0.2/lib/dialyzer-5.4/ebin -pa /Users/nathan/.asdf/installs/erlang/28.0.2/lib/os_mon-2.11/eb ...
java.lang.Throwable: Process creation:
at com.intellij.execution.process.BaseOSProcessHandler.<init>(BaseOSProcessHandler.java:32)
at com.intellij.execution.process.OSProcessHandler.<init>(OSProcessHandler.java:45)
at com.intellij.execution.process.CapturingProcessHandler.<init>(CapturingProcessHandler.java:21)
at com.intellij.execution.util.ExecUtil.execAndGetOutput(ExecUtil.kt:81)
at org.elixir_lang.credo.inspection_tool.Global$runInspection$processOutput$1.compute(Global.kt:100)
at org.elixir_lang.credo.inspection_tool.Global$runInspection$processOutput$1.compute(Global.kt:78)
at com.intellij.openapi.progress.Task$WithResult.run(Task.java:380)
at com.intellij.openapi.progress.impl.CoreProgressManager.startTask(CoreProgressManager.java:498)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.startTask(ProgressManagerImpl.java:119)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcessWithProgressSynchronously$10(CoreProgressManager.java:588)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$new$0(ProgressRunner.java:88)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$4(ProgressRunner.java:252)
at com.intellij.openapi.progress.ProgressManager.lambda$runProcess$0(ProgressManager.java:98)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$1(CoreProgressManager.java:229)
at com.intellij.platform.diagnostic.telemetry.helpers.TraceKt.use(trace.kt:44)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:228)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$14(CoreProgressManager.java:681)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:756)
at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:712)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:680)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:78)
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:209)
at com.intellij.openapi.progress.ProgressManager.runProcess(ProgressManager.java:98)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$5(ProgressRunner.java:252)
at com.intellij.openapi.progress.impl.ProgressRunner$ProgressRunnable.run(ProgressRunner.java:515)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$launchTask$18(ProgressRunner.java:480)
at com.intellij.util.concurrency.ChildContext$runInChildContext$1.invoke(propagation.kt:167)
at com.intellij.util.concurrency.ChildContext$runInChildContext$1.invoke(propagation.kt:167)
at com.intellij.util.concurrency.ChildContext.runInChildContext(propagation.kt:173)
at com.intellij.util.concurrency.ChildContext.runInChildContext(propagation.kt:167)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$launchTask$19(ProgressRunner.java:476)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:735)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:732)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:732)
at java.base/java.lang.Thread.run(Thread.java:1583)
—
Reply to this email directly, view it on GitHub
<#3711 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABW626PN7VWFKZINYMGGSD3ROAO5AVCNFSM6AAAAACFGYYTYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENRTGMZDQNJVGU>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Agreed. Would we be building around elixir-ls, or the new Expert language server? |
Honestly, JB has made some bold moves the last month:
I had kind of lost faith in JB, and I really don't want to tie the plugin into a specific LSP integration, but I've got more faith in the LSP4IJ project than JB right now, especially for getting any weird bugs fixed, and we're not the first. I'm hoping we could create simple interfaces so we could change to the JB LSP. Everything else would just be kinda like "Elixir helpers", e.g |
I just read JB's blog post re: the LSP API becoming available (implementation is still closed-source, unfortunately). It's probably better if we start off building for LSP4IJ, and I think switching to JB's LSP later on if needed shouldn't be too difficult, especially since they both communicate via stdio. |
@joshuataylor I now see the class paths when selecting a elixir and erlang version ![]() ![]() but when I created a brand new mix project, I was unable to select the elixir facet for the project. The apply button does not work and the ok button does not apply the changes for the project ![]() ![]() |
FYI @joshuataylor I installed Mise - curious to see how it compares with asdf. I'd be happy to do some mise testing with the intellij-elixir plugin sometime down the road! I still have asdf installed side-by-side, though. |
Just to add a datapoint: I deleted SDKs and could not re-add them using the marketplace Elixir plugin (nothing would happen upon selecting an Erlang SDK directory path). I then removed the Elixir plugin, restarted IDE, installed
(also works after I've upgraded to IntelliJ IDEA 2025.2.1) |
intellij-elixir-eap2025-4-support-252.zip (2025.2 and below) -- The amount of time we've put into this, and now with 2025.3EAP breaking more things, honestly we've hit a point where I'm just pushing a boulder up a hill. 2025.3 EAP breaks further EDT, the project doesn't even open now (which I've fixed, for the sake of it). This is because most of the plugin is coded in the "old way", which JetBrains is moving away from - 2025.2 was a shitshow of a release, with a lot of their own plugins breaking, and they have the gal to say we needed to be ready/test. 🤷. EAP4 will be the last EAP (hopefully), then we will release v24. The really painful part is there are changed APIs in 2025.3, making it incompatible with 2025.2 and below... So, here are 2 versions, one for 2025.2.x, and one for 2025.3 (EAP). From now, 2025.3 (253.x) will be the only supported version, due to API changes. 2025.2 seems really broken now, so either use the previous EAP (EAP-4) or upgrade... sorry, but we can't maintain both without massiv effort. I recommend using:
Added to this release:
Tentative Plan
|
Yeah, I agree that this plugin should be scrapped - there's too much old code and it'd be a massive workload to rewrite, especially with only one person working on this. :/ I'd be glad to help out with the new LSP-based plugin! |
I'll keep you posted -- there is a lot the plugin will need that people don't normally consider, which we can extract for this plugin (e.g syntax highlighting, PSI, etc). |
I think this is a big and possibly difficult plan to propose, but it feels like a fundamentally healthy direction. I’m deeply appreciative of all the work that’s gone into this plugin (it's likely the reason I stuck with Elixir, since it let me keep using my preferred editor). At the same time, this pivot seems like the right way to tackle the technical challenges (and it’s clear JetBrains hasn’t made that part any easier). Thanks for staying involved, Joshua. An LSP-based approach feels like the best way to bring this plugin into parity with other editors and lower the barrier for others to adopt our preferred IDE. With Expert coming soon, the timing looks good for the community to rally into LSPs. I also hope a fresh start might make it easier for non-Java folks like me to contribute. Thanks again. What can I or others do to help move this forward? |
See #3704
Here is the current roadmap for supporting 2025.2+:
I believe this is the easiest approach, and let's users get going again.
Please report any bugs/weirdness, Ns please submit error reports - these REALLY help!
I'll update this post once the EAP releases have been uploaded.