1) if it's a bootstrap, the config stops executing after the plugins are used (taking packer.sync() out of packer.startup() ensures that they run in series): if there are plugin-specific options down the file, no user wants seeing errors for currently non-existent commands
2) the bootstrap-only autocmd re-sources init.lua after PackerSync completes
The long windo command is more of an eyecandy: since on bootstrap the window with the file is completely undecorated (no line numbers and stuff), init.lua is sourced on all windows but the one created by PackerSync (I don't like how it looks with line numbers and a signcolumn on). Then the cursor is returned to that window by its ID.
Restriction: this snippet only works when in init.lua and not in a module (from where it's unable to stop parsing init.lua)
Actions in the execution order:
1) if it's a bootstrap, the config stops executing after the plugins are
used (takingpacker.sync()out ofpacker.startup()ensures that they run in series): if there are plugin-specific options down the file, no user wants seeing errors for currently non-existent commands 2) the bootstrap-only autocmd re-sources init.lua afterPackerSynccompletesThe long
windocommand is more of an eyecandy: since on bootstrap the window with the file is completely undecorated (no line numbers and stuff), init.lua is sourced on all windows but the one created byPackerSync(I don't like how it looks with line numbers and a signcolumn on). Then the cursor is returned to that window by its ID.Restriction: this snippet only works when in init.lua and not in a module (from where it's unable to stop parsing init.lua)