Nat

Yes, that is correct. I will hack on it a bit and pester you later if I fail to make headway. It's a nice-to-fix, cf. https://www.w3.org/TR/2014/REC-html5-20141028/sections.html#headings-and-section

The better solution is to maintain your own fork of the plugin and do your git operations there. Packer is not the place for arbitrary git scripting.

I have never used a package manager that supports making arbitrary modifications to packages on-the-fly. You cannot `apt install foo --pre-install="git revert xyz"`. That doesn't make any sense. Your issue...

So looking at `./lua/packer/plugin_utils.lua` briefly it seems possible to rework the `plugin_utils.post_update_hook` function to become a `pre_update_hook` function by reordering some of the logic. Look at the first few lines:...

@HawkinsT I won't do the work to implement this feature, but if you submit a PR and it gets merged, great.

Can you reproduce this bug using a stock neovim with minimal configuration? If not it might be better to close this issue and take it up with lunarvim.

@syntaxman in that case it would be good to close the issue, since there is nothing anyone can do to debug or investigate your problem.

Per the README: ``` use { 'myusername/example', -- The plugin location string -- The following keys are all optional disable = boolean, -- Mark a plugin as inactive as =...

This is already possible using the `opt` feature of Packer and builtin Neovim functionality. See this issue for more details: https://github.com/wbthomason/packer.nvim/discussions/946 .

@koalagang you can already lazy-load `opt` plugins per directory using autocommands, just like you can load them per filetype: ```VimL autocmd BufRead */home/user/Documents/vimwiki* ```