0

I've recently released vim-surround-funk, which was inspired by tpope's vim-surround. Originally, I was calling it surround-funk.vim, but I changed the name to be more consistent with vim-surround's naming.

Now I wonder whether existing users will still be able to update using their plugin managers, or if they will need to reinstall it? It's only been up for a few weeks, so I doubt there are a huge number using it, so I figured I should get the name changed asap.

Please enjoy this shameless plug: vim-surround-funk allows you to delete, change and yank a surrounding function call along with its additional arguments. With the surrounding function call in the unnamed register, you can 'grip' any text object with it (including a different function call). 'Gripping' will wrap/encompass a word or function call with the one you have in the unnamed register.

Improve this question
4
  • 1
    Github should forward the old name to the new one, but you may want to let folks know they can update their remotes or Plug commands to point to the new one.
    – D. Ben Knoble ♦
    Jan 22, 2022 at 3:24
  • 1
    if you use guards, like if exists("g:loaded_PLUGINAME") | finish | endif and some user depends on it -- this might bring minor issues to those users.
    – Maxim Kim
    Jan 22, 2022 at 11:08
  • @MaximKim I am using such a guard, but I didn't change that when I renamed the plugin: if exists("g:loaded_surround_funk") | finish | endif, but it's good for me to keep in mind that this global variable should stay consistent since it's exposed to the users (and thus they might be using it). Thanks
    – mattb
    Jan 22, 2022 at 11:21
  • @D.BenKnoble Thanks - I put a note near the top of the README
    – mattb
    Jan 22, 2022 at 11:22

1 Answer 1

Reset to default
1

My best guess is, there will not be any issues since the most common approach is to use git clone/git pull to manage plugins. Each plugin has as a separate runtime path. As long as the git repo can be reached then it should be good. It would likely be more of an issue in the bad ol' days before pathogen. Luckily for most of us that is behind us.

However, since you are thinking about breaking compatibility, it might be a good idea update your <Plug> mappings to the form <Plug>(DeleteSurroundingFunction) style. Using this format means you do not need to worry so much about ambiguous <Plug> names in the future. You can always support the old mappings as well, while updating the documentation with the newer style. Then the future issue a deprecation warning before you eventually remove them

Improve this answer
3
  • Hi and thanks for your answer - can you explain what you mean by updating the <Plug> mappings? At the moment the end of the plugin has nmap <silent> dsf <Plug>DeleteSurroundingFunction... Should I put parentheses around the function name like: nmap <silent> dsf <Plug>(DeleteSurroundingFunction) , and if so why? or have I missed your point about <Plug>?
    – mattb
    Jan 21, 2022 at 22:41
  • 1
    There is nothing wrong with you <Plug> definitions. However, using the <Plug>(...) definitions can sort of future proof. Say you have <Plug>Foo, then you want add <Plug>FooBar it will add a delay to your <Plug>Foo mappings. The surrounding parens help avoid this
    – Peter Rincker
    Jan 21, 2022 at 23:06
  • Aha! Yes ok I did actually come across this delay behaviour while making the plugin (and it took me like an hour to stumble across the <Plug>Foo vs <Plug>FooBar being the culprit for the delay!). It's good to know that there's a way to mitigate it. +1
    – mattb
    Jan 21, 2022 at 23:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.