You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rather than embarrassing myself by misstating details or misunderstanding how LSP integrates with clj-kondo, I'll start with my end goal:
I'm now using Babashka scripts everywhere I previously used shell scripts. For me, this means all over the place. I have maintenance scripts, scripts in source repos cloned to my machine, system scripts, small utilities to get things done for work, and so on. This has been awesome, and with recent enhancements to Babashka, these .bb scripts are completely stand-alone.
One thing that is not working well is that when editing these scripts in Emacs, LSP isn't recognizing them as Clojure and thus not providing completions. I do understand from the discussion we just had on the #lsp channel on the Clojurians Slack that this relates to LSP recognizing the "project" and building a classpath.
When I put a bb.edn file containing only an empty map {} in the same directory as my script, completions start working. I'm hoping for a way to avoid this and allow for completions even when there is no empty bb.edn file present.
My goal is to be able to "drop-in" replace shell scripts with Babashka scripts one-for-one (I don't want to have this extra empty file). My Babashka (previously shell) scripts, depending on their purpose, exist in many locations on my system. So trying to "keep them all in one place" is also not practical and causes other issues and difficulties.
[Feel free to rename this issue if a different name would be better.]
The text was updated successfully, but these errors were encountered:
ericdallo
changed the title
Provide LSP completions on stand alone babashka scripts
Infer project type during initialization without need of a empty dependency file (bb.edn)
Oct 4, 2023
What we want is: be able to open a foo.bb file and detect that we should run a bb print-deps --format classpath to then analyze babashka.process and other ns and provide analysis for LSP features like completion.
The problem is how to achieve that, some not that explored ideas:
During initialization, we try to spawn a bb print-deps --format classpath always, if the exit status code is 0 we consider that classpath, but that may always exit with 0 and we may merge bb classpath with other project classpath like lein, shadow-cljs, etc
During initialization, we grep for .bb files, if one found we spawn the command, that may work but that's a bb only solution, that doesn't work for deps.edn files which have the same problem, but that solves OP's issue.
Rather than embarrassing myself by misstating details or misunderstanding how LSP integrates with clj-kondo, I'll start with my end goal:
I'm now using Babashka scripts everywhere I previously used shell scripts. For me, this means all over the place. I have maintenance scripts, scripts in source repos cloned to my machine, system scripts, small utilities to get things done for work, and so on. This has been awesome, and with recent enhancements to Babashka, these .bb scripts are completely stand-alone.
One thing that is not working well is that when editing these scripts in Emacs, LSP isn't recognizing them as Clojure and thus not providing completions. I do understand from the discussion we just had on the #lsp channel on the Clojurians Slack that this relates to LSP recognizing the "project" and building a classpath.
When I put a bb.edn file containing only an empty map {} in the same directory as my script, completions start working. I'm hoping for a way to avoid this and allow for completions even when there is no empty bb.edn file present.
My goal is to be able to "drop-in" replace shell scripts with Babashka scripts one-for-one (I don't want to have this extra empty file). My Babashka (previously shell) scripts, depending on their purpose, exist in many locations on my system. So trying to "keep them all in one place" is also not practical and causes other issues and difficulties.
[Feel free to rename this issue if a different name would be better.]
The text was updated successfully, but these errors were encountered: