Works like charm. Thanks for this little tutorial.
Im running FreeBSD, so to make elixir-ls to run and not quit on me at the startup, I had to change the #!/bin/sh to use #!/usr/local/bin/bash as ‘<<<’-operator isnt supported by sh.
It is typical to use env in portable scripts to locate the executable, in this case “bash” on the users path.
#!/usr/bin/env bash
It probably should be fixed upstream.
1 Like
Yeah that, but the greatest problem is the use of bash syntax but specifying (I assume) Bourne shell in the hashbang
If everything else is intended to work with sh - the upstream fix would perhaps be to use a ‘sh’ replacement for ‘<<<’-operator.
Hi there! Thanks for the guide, it was really useful. I’m relatively new to Elixir and Phoenix and I’m seriously considering them for my next big project… The ecosystem looks fantastic!
Anyways, if someone is using credo for linting I’d recommend using the nvim packages "mfussenegger/nvim-lint", "dgagn/diagflow.nvim" and "folke/trouble.nvim".
Together they provide a very nice coding experience.
I’ve never heard of any of these packages. I’m going to look into them, but would you mind explaining why they are particularly useful when paired with Credo?
EDIT: So I use coc.nvim and coc-elixir. I’ve been looking to ditch CoC for a while (because why have some bloated npm mess running in the background when I could avoid that), but it’s already set up so so I’ve kept it around. Plus, holy hell are there ever a lot of neo/vim plugins related to LSP/IDE stuff.
1 Like
nvim-lintyou can manage all your linters andcredois on the list of supported ones.
diagflowprovides a very nice UI to expose nvim’svirtual_text(text for diagnostics from the linterns / LSPs).troubleis great for showing in one place all your diagnostics.
This is how it looks on my setup:
Cheers
3 Likes
And I just switched from LazyVim to LunarVim and I think I like it more. It’s uzing Lazy.nvim as a plugin manager but it’s coming with less by default, less keymappings and plugins enabled and more vanilla Vim experience.
I’m sorry, but after 20 years of using mostly plain Vim, the default keybindings are embedded. LazyVim does too much. Also, LunarVim’s documentation is superior, the whole Lua thing is new to me and it’s been super helpful together with configuration videos. Also, it somehow installed Elixir language server on it’s own when I opened elixir file for the first time, it just works.
You can say I’m too lazy for LazyVim
1 Like
Haha, nice!
I actually switched the other way around two weeks ago. It seemed to me that LunarVim does more magic behind the scenes than LazyVim. But I can be wrong. It’s interesting to see the set of plugins being chosen, which helps developing your own taste on the matter.
Even more interesting than the difference between Lunar and Lazy was my discovery of the NVIM_APPNAME environment variable. It allows you to switch between vim distro’s easily, without moving your config files back and forth.
This is the magic behind how LunarVim isolates its own config, using the lvim command (instead of the default nvim binary).
This blogpost does a good job at explaining how this works: Switching Configs in Neovim • Michael Uloth
The neovim documentation about the variable: Starting - Neovim docs (afaik this was a new feature since last year).
This will lower the bar for trying even anotother vim flavour (like kickstart for example).
4 Likes
oh, nice tip, I’ll try it on the next switch. I already nuked my LazyVim setup, unfortunately, I’m too impulsive. 
But the set up kinda works out of the box for Elixir. I just added a few treesitter plugins and Copilot one within config.lua and I am happy for now:
lvim.builtin.treesitter.ensure_installed = { "comment", "markdown_inline", "regex", "eex", "elixir", "heex", "surface", "erlang", "html", "graphql" }
Also, I’m doing this b/c I will mess it up otherwise
alias vim=“nvim”
1 Like
I did the opposite of that over a year ago. LunarVim was a nightmare compared to the clean configuration and control of LazyVim.
I also much prefer the documentation of LazyVim by far, it is completely transparent and well documented. Every plugin and it’s default configuration is clearly defined.
If I was to do it myself I couldn’t imagine it being much different than what lazy does. No magic, explicit plugin configuration and not inventing a separate config system on top.
1 Like
we’ll see how it goes. I got tired disabling LazyVim features over and over again. Less is more.
Curious which plugins you needed to disable.
I disabled the following plugins:
- flash - can’t stand ‘/’ search being broken and 30+ years of using ‘s’ to substitute. The problem with “jump search” plugins is that when you type something that doesn’t match every character typed is interpreted as normal mode leading to random commands. Horrid.
- mini.indentscope - seemed to cause slow down navigating and scrolling through code.
- noice.nvim - it’s experimental and it broke command line :%s/search/replace plus some other command line weirdness. I much the traditional command line vs a goofy popup anyway.
My criticism of all vim distros and indeed LazyVim in this instance is including plugins that are highly experimental or plugins that break long standing vi/vim behaviours.
Even if it is trivial to disable a plugin it does create an issue of “discovery” as it’s not always obvious what plugin is responsible for the undesirable behaviour.
That grievance aside, LazyVim is very transparent with its configuration and there is no lock in to any particular set of plugins or plugin configuration. In that respect LazyVim is a clean starter config and still strikes a good balance vs boostraping nvim from scratch.
The thing I always consider is can I refer to any particular plugin documentation and apply it as described. Does my nvim distribution create its own special configuration “levers, settings and overrides” which has lots of magic and pre-canned defaults with limited overrides but still a lot of things that cannot be changed.
LazyVim is the only distribution I found other than bootstrapping myself that didn’t fall into the configuration tar pit.
4 Likes
This is very true. One does have to experiment with different plugins to work out what’s important or more to taste and what’s just fluff.
I think any vim user should really go though each plugin and assess if they actually need or use it. It’s better to err on the side of minimalist configuration and critically assess if a plugin is earning it’s rent in your configuration.
It’s better to develop the itch for something first, then actually understand if there’s a plugin that makes life better, understand how to use it and then actually use it to develop the muscle memory.
Adding a bunch of plugins all at once that you might use but don’t take the time to actually learn them is kind of pointless. We are all guilty of this.
2 Likes
That goes for every editor “distro” though. I’m deeply ashamed what huge chunk of my life and career I spent on Emacs’ arcane trickery but in all honesty, LazyVim and LunarVim are not hugely better; though they’re still much easier than Emacs.
I personally prefer Lunar simply because I get a lot out of the box. Contrary to the misguided “hacker” and wide-eyed philosophy of “make it 100% your own by tinkering with it all the time!” I actually want to spend time in the real world.
Lunar gives me that, though I have to admit that I had to peek under the hood more than I wanted to. Sigh.
I like explicitness and opting in to stuff so maybe I’ll migrate to Lazy at one point. But I started looking at these as billable hours and that changes the decision making process on whether to engage in such activities drastically.
Absolutely this. No need to just add everything to feel cool.
1 Like
oh yes that’s it! That’s super annoying. There was one thing I never figured out in LazyVim that it did for unknown rason and is that it didn’t work well within tmux environment. The way I am used to work is that I spawn Tmux, and within Tmux I spawn Vim.
For some reason, my LaziVim was in conflict with Tmux, and it’d move lines around when I didn’t want to, and often also wouldn’t catch the last character entered before going back to the normal mode with escape.
I am sure I will eventually just hand craft my own, like I did in the good old Vim 7/8 days, which may be for the best as these Vim distributions often are short-lived and stop being maintained.
1 Like
Fair enough, I might end up doing the same but in the meantime LunarVim has been around for a while and the maintainers really did seem like they care and listen (f.ex. they made a special effort to have the separate lvim executable so people can still tinker with nvim separately; they also made sure the stable releases don’t break [easily]).
1 Like
glad to hear it. How long you’ve been using it for? I’m literally on a third day or so xD
At least a year at this point. It was much more unstable at the beginning but in the last 6-ish months it’s much better. And you can stay on older releases for quite a while if you choose so.
1 Like
This isn’t misguided if you actually enjoy doing it, although expecting everyone to do is misguided… which is probably what you were saying now that I think about it!
I learned vim in a similar way as already described here: I installed Janus and used it for a bit while learning what I liked about it. Then I moved that over into my own config. I did spend a few years tweaking my setup to death but I barely touch it now. I also mostly know what every single line does! About twice a year I read through it and if there is anything I don’t use anymore I delete it. It’s possible for it to be a mostly one-time endeavour to build up a good vim config, you just can’t be a constant editor-switcher. But ya, as @adw632 said, you’re asking for pain if you install a plugin “just in case you want to use it”.
I found consistency in the vanilla Vim world by sticking to a certain “style” of plugin. I chose tpope as a base pretty early on and mostly only install plugins that either build off of his plugins or that follow similar ethos—junegunn, mhinz, AndrewRadev to name very few. For example, I only use plugins written solely in vimscript. The exception is when a compiled language is used for performance reasons, but if it’s a fairly simple plugin written in Python or Ruby then it’s usually a hard no. A little less important is that if a plugin defined leader mappings out of the box, that is red flag for me and requires some investigation. This probably seems a little obtuse, but the leader key is my key and if plugins are touching it that is signal that the authors are potentially willing to be cavalier about plugin-related things in general. In any event, this has given me a rock solid setup for years. I’ve only ever had one conflict that I can remember (I remember it because it was really bad and I dealt with the pain for an embarrassingly long time).
2 Likes
There was a nerdfont 3.0 update which was buggy with certain icon width issues and this caused problems with some plugins like lualine and cmp which happen to use the affected code points. It wasn’t just tmux but a number of terminals that were affected by the font update.
Some more info here:
https://www.reddit.com/r/neovim/comments/13glwed/anyone_else_having_issues_with_nerdfonts/
1 Like
