vim-emoji-icon-theme
vim-emoji-icon-theme copied to clipboard
plugin load order, e.g. call gitgutter#highlight#define_signs()
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:
- 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.
-
:call gitgutter#highlight#define_signs()
to redefine the signs- This should be inside an
if
or atry
/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.
- This should be inside an
-
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.
- I don't know that this is any better than just using an
-
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
.
- This would ensure this plugin loads before gitgutter. But it would need to be documented. And it'll need to be installed to
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 let
s 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. 😉
@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.