b0o / nvim-conf

[question]?? Don't really feel this is an 'issue', so feel free to delete once read; just didn't know how else to contact you. I'm not a twitter user.

Hi Maddison!

I've been poking around your nvim-config files the past few days, and I see all kinds of interesting/new ways of doing things I'd like to explore. And the way I typically do that is to install the config locally and hack. Problem is I can't seem to figure out how to bootstrap your config. Which is really annoying to me 😏 as I've worked through this same problem a kazillion times in the last 8 months and always managed to figure things out -- eventually. But today I'm officially stumped.

I've tried multiple renditions, but they all roughly look like this:

clone your nvim-conf repo into ~/.dotfiles/config/nvim (I'm on macOS).
nvim.
fails to load impatient (which it should); then fails on init.lua -- module feline not found.
OK, packer.nvim is not being installed for some reason, so I install it manually.
restart, try a PackerSync; nadda; packer's not being initialized.
initialize manually - :lua require('packer').init()
now I can PackerSync but packer first wants to uninstall itself. No packer, that's not what I want.
if I say 'ok' packer uninstalls itself (no, it does not move itself to opt; just uninstalls) and we're back to square one.
if I say 'no' packer goes off, trundles away for a spell, then dies with an obscure error I've never seen before.
the error is async.lua -- attempt to index local 'display-win' with a non-something-or-another

As noted, I've tried multiple different incantations on the above, but I always ultimately end up in the same spot.

Am I missing something simple? Is there a 'secret sauce' buried somewhere deep in your code's logic? Could use a little guidance.

TIA,
/tom

Hi Tom! Thanks for the report. I had not previously paid much attention to bootstrapping or portability. I've now gone through and tried to fix things up to make bootstrapping possible and to make things as portable as I can.

Mind giving it another try? Before running, please delete ~/.local/share/nvim, ~/.cache/nvim, and ~/.config/nvim/plugin/packer_compiled.lua (make backups if necessary).

Final note, my config requires nvim v0.7 or greater, and I've only tested with luajit > v2.0.5.

Oh, Maddison… Thank you so much for your efforts. I really didn’t intend for you to have to fuss with anything; just perhaps point me to where I was messing up ;-) But yes, I’ll give it a try — for sure. And yes, I have a system for evaluating others' nvim configs. I init them into clean ~/.local/share/nvim, ~/.cache/nvim , and ~/.config/nvim dirs, then once initialized and working, I move all the above elsewhere and symlink then back. Allows me to play with multiple nvim configs, as well as my own nvim-dev (which serves as a melting pot). Quick and easy with the magic of Makefiles. And yes, I’m on nightly-nvim. Thanks again, /tom

…

On Apr 26, 2022 at 21:35:24, Maddison Hellstrom ***@***.***> wrote: Hi Tom! Thanks for the report. I had not previously paid much attention to bootstrapping or portability. I've now gone through and tried to fix things up to make bootstrapping possible and to make things as portable as I can. Mind giving it another try? Before running, please delete ~/.local/share/nvim, ~/.cache/nvim, and ~/.config/nvim/plugin/packer_compiled.lua (make backups if necessary). Final note, my config requires nvim v0.7 or greater, and I've only tested with luajit > v2.0.5. — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGTYGQPRE2KXJ3QNFRBNOLVHC7YZANCNFSM5UJKJGRA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

No worries! It will save me time in the future when I need to set up a new machine.

OK, got it. Eventually. So thanks again for your efforts. They allowed me to get past those glorious “full-stop-wtf” moments we all run into occasionally. Here’s what you can expect if you, one day, need to do a clean install. Neither issue has any nice easy fixes at this time — to the best of my knowledge. And I’ve run into them both in many, many other nvim configs. So don’t feel alone ;-) The first is a timing issue. During initial config/bootstrap/setup, when you get over 60-70 plugins (or when you’re background compiling a plugin, as Mat Jones and I discovered with his dash.nvim plugin) packer has a tendency to timeout. You don’t get any messages, or warnings. Nada. It just sits there churning. Sometimes it’s thinking; sometimes the process has quietly failed. The fix is: (1) patience; resist the temptation to touch anything cuz you might trigger a fail, and (2) if you’re relatively confident it has quietly failed, press q to exit the packer window, and WITHOUT exiting yet, re-run PackerUpdate (or sync). Sometime, when you’re trying to load over 100 plugins, and the internet (and packer) are being finicky, you might end up repeating this step 4 or 5 times. After you exit and reset, if you get messages about plugin failures, re-run PackerSync until they go away. There’s some timing settings you can mess with in packer, but I’ve not had any success with them to date. The second issue is packer’s heavy reliance on caching to make everything work. When you’re dealing with setting up multiple configs in a day, or doing a lot of active config development (like moving big blocks of stuff around, adding lot’s of plugins in a short time, refactoring large chunks of code, etc) you have to keep this forefront all the time. A lot of weird setup issues can be solved by doing a simple PackerCompile. I use it so often I have an abbreviation set up (:pc). I bump into this one a lot lately cuz I’m exploring some pretty radical, disruptive changes in my nvim-dev branch every day. Sometime the only solution is to blow everything away, clear out ~/.cache/nvim, and ~/.local/share/nvim and re-bootstrap the works. Which is why I’m so familiar with bootstrap issues ;-) Once I’ve spent some time with your code, if there’s anything I discover that could possibly smooth any of the above, I’ll pass it along. Do you prefer I fork and send you a PR?, open an issue?, or just send you an email? Best, /tom

…

On Apr 26, 2022 at 22:57:59, Maddison Hellstrom ***@***.***> wrote: No worries! It will save me time in the future when I need to set up a new machine. — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGTYGRLQRF6JDEGZQHHMTLVHDJONANCNFSM5UJKJGRA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

Glad you got it working!

During initial config/bootstrap/setup, when
you get over 60-70 plugins (or when you’re background compiling a plugin,
as Mat Jones and I discovered with his dash.nvim plugin) packer has a
tendency to timeout

Yes I noticed this too when testing on my MacBook! Very annoying. I was able to fix (or at least mitigate) it by setting packer's config.max_jobs lower. I have updated it to use $(nproc) concurrent jobs:

nvim-conf/lua/user/plugins.lua

Lines 255 to 258 in 0980b28

    
           packer.startup { 
        
             startup, 
        
             config = { 
        
               max_jobs = tonumber(vim.fn.system 'nproc 2>/dev/null || echo 8'),

When I was testing on my MacBook with no job limit, I saw a few error messages relating to 'too many file descriptors'. I haven't experienced that issue on my desktop even with no max_jobs limit, maybe because I've upped my file descriptor limit.

On your second point, I have set up an autocommand that runs PackerCompile whenever lua/user/plugins.lua is written:

nvim-conf/lua/user/autocmds.lua

Lines 43 to 48 in 0980b28

    
           autocmd('BufWritePost', { 
        
             pattern = vim.fn.stdpath 'config' .. '/lua/user/plugins.lua', 
        
             callback = function() 
        
               vim.schedule(require('user.fn').packer_compile) 
        
             end, 
        
           })

Do you prefer I fork and send you a PR?, open an issue?, or just send you an email?

Any of the above!

Retested this morning. Flawless. Started with a blank slate (rm -rf {~/.config/nvim,~/.local/share/nvim,~/.cache/nvim}. Pulled yesterday’s changes. Dropped your nvim-conf dir into my ~/.dotfiles/config/ dir. Typed nvim. Ta and Da. Not a single error or issue. Everything I’ve looked at/tested so far works cleanly. Now I just have to figure out what all your magic does. Since I first bumped into your config a few days ago I’ve been looking through the plugins you use and added a bunch to my config, plus a few snippets of code here and there. But in doing so, I’ve bumped my plugin count over that magic 60-70 mark and now MY bootstrap/plugin sync runs like a sloth and craps out unexpectedly. Sigh. Thanks again for you efforts; Up to you, but from my side of the fence I think you can close this issue. On Apr 27, 2022 at 20:08:33, Tom Syroid ***@***.***> wrote: I did end up forking your nvim-conf, so I’ll pull your latest changes and

…

see if they make a difference to my bootstrap here. > Message ID: ***@***.***> >

Awesome, glad it’s working!

By the way, one thing I’ve noticed is that, on my Mac, using any luarocks packages caused the Packer sync to hang. Works fine on Linux so not sure what that’s about.

Below changes Good on you Maddison. I’ve hacked various different timing issues before, but never heard of config.max_jobs. I’ll go do some homework. Perhaps you’re on to something with your MBP thing. That’s my sole platform: a MBP 13”. And multiple times in the past I’ve complained to Mat (mrjones2014) about timeouts with his plugins that he could not reproduce. He’s on a maxed out min, thoughi; I’m on my MBP. So maybe an I/O or bus issue? It still all goes back to (IMHO) processing of cache and timings. Perhaps his system is better with simple I/O? The problem with all my mentioned issues is that they don’t come with nicely defined error messages, and depending on the day-of-the-week and direction-of-the-wind are hard to reproduce. Which makes them oh-so-difficult to debug. On both sides. I did end up forking your nvim-conf, so I’ll pull your latest changes and see if they make a difference to my bootstrap here. Best, /tom

…

On Apr 27, 2022 at 19:38:14, Maddison Hellstrom ***@***.***> wrote: Glad you got it working! During initial config/bootstrap/setup, when you get over 60-70 plugins (or when you’re background compiling a plugin, as Mat Jones and I discovered with his dash.nvim plugin) packer has a tendency to timeout Yes I noticed this too when testing on my MacBook! Very annoying. I was able to fix (or at least mitigate) it by setting packer's config.max_jobs lower. I have updated it to use $(nproc) concurrent jobs: https://github.com/b0o/nvim-conf/blob/0980b28bd25340e67eebec725a5c607ab114d77a/lua/user/plugins.lua#L255-L258 When I was testing on my MBP with no job limit, I saw a few error messages relating to 'too many file descriptors'. I haven't experienced that issue on my desktop even with no max_jobs limit, maybe because I've upped my file descriptor limit. On your second point, I have set up an autocommand that runs PackerCompile whenever lua/user/plugins.lua is written: https://github.com/b0o/nvim-conf/blob/0980b28bd25340e67eebec725a5c607ab114d77a/lua/user/autocmds.lua#L43-L48 — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGTYGXHWHQVXZ5WAXO5EEDVHH2ZNANCNFSM5UJKJGRA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

	packer.startup {
	startup,
	config = {
	max_jobs = tonumber(vim.fn.system 'nproc 2>/dev/null \|\| echo 8'),

	autocmd('BufWritePost', {
	pattern = vim.fn.stdpath 'config' .. '/lua/user/plugins.lua',
	callback = function()
	vim.schedule(require('user.fn').packer_compile)
	end,
	})

Help with bootstrap