Yes that’s exactly it, sorry for not clarifying. I mean that almost everyone who makes developer tools expects you to tinker with their thing. Extremely short-sighted, not to mention annoying. You do get burned out after doing it 5000+ times, you know. But the youngsters don’t know that yet.
Uses a hackable editor, advocates against hacking
My $.02 - learn nvim/lua (couple hours), learn how to write nvim plugins (couple hours), install telescope with vim/help search (couple hours). Now you can put your new super power to work when you want it. IMO it’s about as difficult as writing bash scripts. Also FWIW I’ve found ChatGPT4 is great to generate code snippets for nvim/lua.
ps with ‘old vim’ (vimscript ) I was also anti-hacking. For me, lua and easy doc lookup (telescope and GPT4) change the equation.
Not precisely:
- I use what I perceive as the best editor in the terminal. It being hackable is a side effect, one that I don’t view very favorably.
- I don’t advocate against hacking per se or in totality; I am annoyed at having to hack everything. One of the good things mentioned above about LazyVim is that you just open a new file type and the proper LS just gets installed and started. Why aren’t ALL editors like this?! Do I really have to edit Lua hashtables for this? This should be a baseline functionality unless you enable Offline Mode or something.
It’s not about Lua being hard. I actually like Lua and I would use it more if it if it had proper parallelism.
I don’t use GPT but maybe I should. And yeah, I don’t mind hacking on Lua too much; I get angry if I have to do it often.
What that being said, LunarVim actually does really well there. I grumbled and was annoyed but after I nailed a good config I haven’t touched it in months. That’s the ideal state of things for me.
advocates against hacking in vimscript, his github username is in my vanilla vimc
thanks a ton for this post, it gave me starting point for redoing my - quite crappy tbh - Vim configuration in Neovim using Lua.
I also took at look at LunarVim, following your recommendation, but it does too many things for my taste, and also I have irrational aversion towards Vim package managers, so I preferred to add what I needed myself.
I’ve ended up with many pieces of Lua you shared; it was fun poking around LSes too.
For anyone interested, I have set up my LunarVim config.lua, it’s pretty minimal, here:
Nobody asked me, but here’s some plugins I added on top of my LazyVim’s config:
GitHub - jmbuhr/otter.nvim: Just ask an otter! 🦦 : Otter allows me to lint @moduledoc as Markdown and even use LanguageTools to check english grammar.
GitHub - Wansmer/symbol-usage.nvim: Display references, definitions and implementations of document symbols : Nice way to surface LSP info.
GitHub - sindrets/diffview.nvim: Single tabpage interface for easily cycling through diffs for all modified files for any git rev. : has a really nice way of checking the history of a file. I use that a lot on unknown codebases.
GitHub - emmanueltouzery/agitator.nvim : has a Git Blame command like fugitive.vim has.
Let me give my love to LazyVim (the Neovim distro) here too.
I used to use LunarVim, but switched to LazyVim when I saw that LazyVim (the distro) used lazy.nvim (the package manager). That was the killer feature. Now everybody is using lazy.nvim, even LunarVim and even the creator of packer (another package manager for nvim) has switched over to lazy.nvim.
lazy.nvim (the package manager) makes super easy to merge config options, so you can declare options for the same plugin in different files or stages. That may sound problematic but I found that’s actually more useful to organize your config files in a more ‘thematic’ way than to have a single point of configuration for each file.
LazyVim (the distro) takes this philosophy a step further and makes it super easy to add a config file for a new language. You “add” options (a lua table) to plugins (treesitter, lspconfig, linters, etc) that are probably already declared that will be merged by lazy.nvim (the package manager) and things work and are still organized.
To add Elixir to LazyVim, it was as simple as this: Add Elixir support and config by georgeguimaraes · Pull Request #993 · LazyVim/LazyVim · GitHub
Let me give you another example. I wanted to change Telescope to search for all hidden files, because I want to open .formatter.exs
, for instance. I created a new file in my neovim config called plugins/editor.lua:
return {
{
"nvim-telescope/telescope.nvim",
opts = {
pickers = {
find_files = {
hidden = true,
file_ignore_patterns = { ".git/" },
},
},
},
},
}
That was it. All the other defaults from the Telescope project, and all the other config that LazyVim adds to Telescope are still there.
In LunarVim, I was not fond searching if I needed to overwrite something in the lvim.builtin
namespace or not. More overhead. (At least that was the case before they moved to lazy.nvim).
Btw, lua is a joy to use. Really enjoying it.
Anyway, my nvim-config is in GitHub - georgeguimaraes/nvim-config: My ~/.config/nvim files. I love trying new plugins and new stuff on my config.
Your links end with :
and are giving 404s on GitHub, you might want to fix them.
Thanks for adding the elixir plugin.extras
option to LazyVim. Tried it over the weekend, and was up and running in minutes!
Also, now I understand why neotest works out of the box, without adding the elixir adapter. I used to set up vim-test for running tests in another tmux panel, but neotest seems to integrate very nicely.
nice catch, tks
A question regarding nvim-neotest in LazyVim:
I’m really liking neotest, but I can’t seem to get “Run All Test Files” working (mapped to require("neotest").run.run(vim.loop.cwd()
by default in LazyVim). It seems to run all tests from the root, which also includes stuff in /deps
and _build
, which doens’t work. My fix is to explicitly pass "test"
as the root folder into the run command. But maybe I’m missing something obvious here. Does triggering this keymapping fail in every elixir project right now?
Yes, I think so. I guess you could open up an issue on neotest-elixir. Or maybe we can get a workaround in the setup for it directly in neotest.
The prime LunarVim maintainer admitted to moving to AstroNvim and not maintaining LunarVim much (posted 2024-MAR-31): Release policy · LunarVim/LunarVim · Discussion #4518 · GitHub
I’ll be moving to AstroNvim as well then. Or LazyVim.
A Neovim one-liner helping me use a guess-and-check spec cycle, employing Mneme v0.6.0 — Documentation
yeah and it probably makes sense to move to something else already. My set up has been a few times broken by new builds of Neovim, the lunarvim eventually caught up but not without a significant delay.
Oh absolutely, in fact all this drama of mine started with me asking myself “why hasn’t LunarVim gotten a major release in a year now?” about a week ago and I then went ahead to dig up info, leading me to the GitHub discussion linked above.
I am 99% migrated to AstroNvim at this point and I like it much more. Only some small details and customizations on Golang and Rust LSP / post-processing tooling remains, everything else is covered and tested.
As an example: I have two separate formatters enabled on Golang and it leads to them both stepping on each others’ toes and weirdly split only some function calls (not even all) into this:
doStuff(
firstArg,
secondArg
)
…which it really shouldn’t do because I only wish line splitting if the line goes above 100 characters. But I’ll fix these idiosyncrasies pretty soon.
After years of being happy and productive with VS Code, I’m back to experimenting with (neo)vim as my editor because I hate myself… I kid, I kid. I used to use vim back in the mid 2000’s, I remember using Janus.
Anyway, I wish I read this entire thread first instead of just the first post cuz I wasted time on LunarVim. I’m on AstroNvim now, but am having problems…
do<enter>
does not autocomplete anend
- Indentation only works sometimes
- Sometimes starting a tuple
{
will automatically unindent fn -><enter>
does not autocomplete anend
- neo-tree’s root only gets set properly ~20% of the time, but only when shown via toggle (
<leader>e
)
My AstroNvim is pretty vanilla, I just added elixir-ls and heex. Any tips?
Edit: what color theme do yall use? Dracula looks great in VS Code but leaves some to be desired in neovim for some reason.
To get end
you likely have to add treesitter endwise
Knock yourself out, no promises though. I am still working on the config but it’s like 95% there for me.
Note: I give zero fraks about do<Enter>
autocompleting end
.