2

I had previously installed the mkdx markdown plugin for vim, via Vundle. I later decided to switch to vim-markdown, and uninstalled it. Initially, everything seemed fine, but when I attempted to insert a heading # character, it was immediately replaced with


<Plug>(mkdx-link-compl)

The Vundle :PluginList command does not show it is installed, nor does it appear in my .vimrc or anywhere in ~/.vim/*.

I have tried searching all vim-related directories on my machine, and selectively disabling all of my plugins, in Vundle, Pathogen, and Vim-Plug. :scriptnames returns nothing related to mkdx. My suspicion is that some other plugin had detected mkdx, and changed some settings somewhere, or mkdx did this itself. Is there any way to see what's going on 'behind the scenes' when I insert '#' on a markdown file?

cp1
  • 163
  • 6
  • "Vundle, Pathogen, and Vim-Plug" two plugin managers + one runtimepath manager. What could go wrong? – romainl May 01 '23 at 16:06

1 Answers1

2

Combining multiple plugin managers sounds like a recipe for disaster. Noting that, there are a couple of things that you can do.

It is likely that whatever is happening can be seen in one of :scriptnames, :commands, or :functions. I note that vundle and vim-plug also have their own status functions. Vundle has :PluginList and vim-plug has PlugStatus. I have no idea if they work when both are running. You can also check :set runtimepath? to see what runtime paths are currently in operation.

An alternative would be what I consider a nuclear option. If you profile vim, you can read off what things are called and then narrow your search appropriately. You can do this by starting vim and calling

:profile start vimprofile.log
:profile file *
:profile func *
:e foo.md

Now you edit your file, starting a line with # and getting the expansion. Then you quit and read what was called in vimprofile.log. It will definitely be there. I suggest going directly to the end of the profile, which shares all functions sorted by time.

davidlowryduda
  • 2,404
  • 1
  • 25
  • 29
  • It seemed there was some file-specific stuff left in `.vim/view` that was triggering it, which the log handily revealed. Thanks! – cp1 May 01 '23 at 20:08