adelarsq / vim-emoji-icon-theme

Emoji/Unicode Icons Theme for Vim and Neovim with support for 40+ plugins and 380+ filetypes πŸŽ¨πŸ’™πŸ’›πŸ€πŸ’š
MIT License
87 stars 4 forks source link

plugin load order, e.g. call gitgutter#highlight#define_signs() #14

Open nevans opened 2 years ago

nevans commented 2 years ago

Hi, thanks for compiling this great mapping of emoji ↔️ plugin settings into a single handy plugin!

I recently updated my plugins and re-organized them using multiple pack directories, and the emoji for gitgutter stopped working. I didn't see anything in the docs for either plugin, but after a little searching, it seems that the gitgutter signs are only defined when the plugin is loaded. By moving gitgutter to pack/git/start/gitgutter and this plugin to pack/ui/start/emoji-icon-theme, I accidentally made this plugin load after gitgutter's signs had already been created.

I found a few workarounds:

  1. Rename the plugin directory to an early sorting value, e.g. pack/00-init/start/emoji-icon-theme
    • This is simple for users to do, but a little bit annoying. It would need to be documented.
  2. :call gitgutter#highlight#define_signs() to redefine the signs
    • This should be inside an if or a try/catch, in case this plugin loads before gitgutter.
    • It could be added to after/plugin/vim-emoji-icon-theme.vim, letting it run after gitgutter has loaded. No new vimrc config necessary.
  3. autocommand VimEnter * call gitgutter#highlight#define_signs() could run after plugins have loaded.
    • I don't know that this is any better than just using an after dir.
  4. packadd vim-emoji-icon-theme inside the user's vimrc
    • This would ensure this plugin loads before gitgutter. But it would need to be documented. And it'll need to be installed to opt. Annoying
    • However, as an added benefit, this would let the user override this plugin's emoji inside their own vimrc, without needing to add anything to after/plugin.

I'm using the second option in my own ~/.vim/after/plugin dir. But, IMO, the best approach would be second option (in this plugin's after/plugin dir), because that will work without adding anything new to documentation or the user's vimrc. Additionally, to get the benefits of the last option, user overrides could be handled by replacing the lets like so:

let g:gitgutter_sign_added = 'πŸ”Ή'                                  " current
let g:gitgutter_sign_added = get(g:, 'gitgutter_sign_added', 'πŸ”Ή') " updated

What do you think? If you're interested, I should be able to put together a PR... but it might not happen this week. πŸ˜‰

adelarsq commented 2 years ago

@nevans Nice! Thanks for the report!

What do you think? If you're interested, I should be able to put together a PR... but it might not happen this week. πŸ˜‰

Will help a lot if you can. I am also really busy this week, with work, new home and kids. I also think that the second option is the best.