Error when loaded with lazy.nvim package manager

[Oleksandr Babak]

When I was using Packer, everything was fine, but when I switched to lazy.nvim I started getting this error:

Error detected while processing BufReadPost Autocommands for "*.{md,mdown,mkd,mkdn,markdown,mdwn}"..FileType Autocommands for "*"..function <SNR>1 _LoadFTPlugin[17]..script /home/user/.local/share/nvim/lazy/vim-markdown/ftplugin/mkd.vim: line 467: E128: Function name must start with a capital or "s:": b:Markdown_GetUrlForPosition(lnum, col) line 468: E121: Undefined variable: a:lnum line 469: E121: Undefined variable: a:col line 470: E121: Undefined variable: l:lnum E116: Invalid arguments for function synID E116: Invalid arguments for function synIDattr line 472: E121: Undefined variable: l:syn line 487: E133: :return not inside a function line 490: E133: :return not inside a function line 493: E121: Undefined variable: l:lnum E116: Invalid arguments for function <sid>FindCornersOfSyntax line 494: E133: :return not inside a function line 495: E193: :endfunction not inside a function

[Caleb Maclennan]

I'll be honest I have no idea what this is about and am unlikely to be able to dig into it any time soon. I use Packer myself and am swamped at the moment. That being said I'll make an effort to review a PR if you or somebody figures out there is something wrong with this plugin that can be fixed. Otherwise maybe somebody else has an idea what is up and can suggest something. I've never used lazy.nvim and don't have anything to suggest off the top of my head.

[B4rc1]

This is caused by lazy looking for releases and finding the 2.0.0 version released back in 2015. This can be easily fixed by making a new release.

As a temporary workaround, use the latest commit:

{'plasticboy/vim-markdown',
  commit = "df4be8626e2c5b2a42eb60e1f100fce469b81f7d",
  require = {'godlygeek/tabular'},
},

[Caleb Maclennan]

Is there a syntax to stick with a branch HEAD? Something like branch = "master"? This (and many other vim plugins) don't typically cut releases and expect each commit to HEAD or the default branch to be the defacto version to use. Most vim plugins (with a few exceptions like vim-clap or firenvim or others that involve matching native code builds) only cut releases as a concession to package management systems and basically just arbitrarily add tags periodically.

[B4rc1]

sorry for taking so long to respond, but yes it is exactly branch = "master":

{
  'plasticboy/vim-markdown',
  branch = 'master',
  require = {'godlygeek/tabular'},
},

It would be nice if this could be added to the readme to avoid people running into the same issue.

[Caleb Maclennan]

I'm not opposed to adding a note to our readme that suggests we don't typically do releases and expect people to run HEAD, but individual instructions for every package manager gets a bit wordy. In this case most default to what we expect anyway. Can I suggest submitting this to lazy.nvim as something they should document aggressively since many plugins anticipate HEAD usage over tags?

Also we'd be happy to see a PR with this noted in our readme too. I'll leave this issue open to track that getting documented.

[B4rc1]

vim plugins don't typically cut releases and expect each commit to HEAD or the default branch to be the defacto version to use.

I have 77 plugins installed and only vim-markdown breaks in this way because it has releases but they are very outdated. If the repo does not have semver tags this is indeed the default behavior of lazy.nvim.

I think this is completely reasonable behavior on lazy.nvims part. I do not understand however why there are releases of vim-markdown that are ancient. Is this some relic of the past like a change in development model or a change in the way the plugin used to be distributed (things like the vim-scripts site come to mind)? Will something break if you now, 8 years after the last release release version 3.0.0? It does not seem like the repo sees that much activity so it does not seem like a lot of work to release a new minor version after every fix.

I personally would like a future where my vim plugins are versioned properly so I can better track what changed and go back to a known good version if something breaks. (I know this can be done by commits but it is hard to remember git commits and bisecting your plugins just to find a working version does not sound like fun)