vim-utils: remove vim-addon-manager support

[teto]

Description of changes

It's hard to maintain this complex software and I dont see the advantages yet, now that vim supports "packages". Even if that were the case it could live somewhere else than nixpkgs, e.g., a vim-specific flake.
#56338

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.11 Release Notes (or backporting 22.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[teto]

@MarcWeber You are the main one concerned. You've invested some time in this implementation so I dont want to remove it without your consent. My reason for removing this is that it's the second time I can't do some modification because we support 4 plugins systems for vim. See my first post too.

[teto]

@rlupton20 @vquintin I search github with "vam.knownPlugins" and found out you were using vam https://github.com/rlupton20/dotfiles/blob/e81ee1ec9623ee3d0eda99345f0b0e36ce617c16/vim.nix and https://github.com/vquintin/dotfiles/blob/bbd100b999024001ff0021f06b3a5869c8388aa0/nix/.nixpkgs/packages/dev/vim_custom/default.nix . Any hindsight ? you dont seem to use any vam specific feature so would you be fine with me discarding vam to ease the maintainance of vim-related infra in nixpkgs ?

[teto]

I am going ahead and we can revert if it proves to nag too many users but I would like to avoid that.

[vquintin]

This is an old dotfiles repository. I moved it off github.
Now I use https://nixos.wiki/wiki/Vim#Using_Home_Manager. I don't use vam.knownPlugins anymore.

[MarcWeber]

You need to understand that maintaining 4+ managers should be no brainer
if plugins are standard plugins thus just augment runtimepath+= and are happy.

MarcWeber/vim-addon-manager#188
MarcWeber/vim-addon-manager#189
-> :packadd does what VAM does, but VAM was about much more

Having an addon-info.json file allowing dependencies to be declared
Having a vim-pi repository to turn the mess on vim.org (the scripts .tar.gz)
into a machine readable format with patches to allow making the work on
installing by name - also trying to disambiguate if names have been chosen
multiple times.

However packadd fails on differentiating install / load time.
After installing you might want to generate tags by using :helptags

The nix code allows having vim-for-user-x and many x.
So Using_Home_Manager is not a replacement for such use case.
Eg if you maintain multiple servers having to manage HOME for many accounts is
just ...

So what exactly is your issue with VAM - why is it causing trouble ?

When I created VAM there was no community lead there was no manager.
There was no sane way to activate plugins once you open a .py file
but loading .py related viml code slowed vim down. The lazy loading thing.
Autolad etc appeared later if I recall correctly.

VAM has flaws:

• viml only (thus no paralell installs). Could be wmorked around by using a
  json based file

• not many users

The json based file I thought might look like this.
And it already kinda works.

call vam#Scripts(expand('~/.vim-scripts'), {})
contents like

{'name': 'vim-addon-surround'}
{'name': 'vim-addon-toc'}
{'filename_regex': '\%(\%(l\)hs\|cabal\)$', 'name': 'vim-addon-haskell'}
{'filename_regex': '\%(php\|inc\|php.inc\|hsc\|lhs\)$', 'names': ['phpcomplete','vim-addon-xdebug', 'vim-addon-php-manual']}
{'filetype_regex': '\%(cabal\|hs\|hsc\|lhs\)$', 'name':  'vim-addon-haskell'}
{'filetype_regex': '\%(rb)$', 'names': ['vim-ruby', 'vim-addon-rdebug', 'vim-addon-ruby-debug-ide', 'textobj-rubyblock' ]}

My past is like

• packaging Haskell (hack-nix) trying to reinvent cabal's dependency resolution
  within Nix dumpnig hackage to nix format. Of course performance issues and
  more turned it into 'lets try latest version and' .. yeah

• failing with cabal2nix this year thus rewrtiing my code using typescirpt

• nixpkgs-ruby-overlay

• trying Python packages, failing , causing damage no master that time
  since then I stopped committing. Todays consensus is always use PR
  cause things turned too complex

• vim-addon-vim2nix or such

Each time wasting time and pain to write the code.

Summing up:

https://github.com/MarcWeber/nix-comment-updater
That's a simple way to keep packages up to date for the future.
Its a complete rewrite of my old haskell based code simple but good enough.

So check it out provide feedback.

But how to package YouCompleteMe correctly ?
With steam-run you can install --rust-completer
But the python code downloads rust and runs a shell file.

So its kind of nightmare. The fix is creating a new platform which
allows source to be put on like github with custom dev env like vscode or vim
with derived contetns like the compliaction result.

Then people would 'fix' the packages and it would just work.

If you're intersted on discussing this level let me know.

I don't mind VAM being removed. I'll keep local patches.
But I doubt VAM is your problem so point me to the issues
so that we can get to the root of it and understand it.

And if you want to unify the mess you need to start on a different level.
You're welcome to discuss this with me.

Pathogen didn't run helptags at the beginning but its what more users knew.

I also tried making it easier for the Vim community to organize itself
by providing a wiki everybody can simply join using git in the background
to allow fast editing:
http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html

But reality is that Shougas manager was written cause he didnn't know about
VAM. Vundle hat different design goals (let's try ..) and Pathogen I forgot.
Didn't implement all of VAM's features like :helptags or added them later.
All missing out on vim-pi's idea providing human friendly usable names for
plugins having different numbers but same names.

[teto]

thanks for taking the time to reply.

You need to understand that maintaining 4+ managers should be no brainer
if plugins are standard plugins thus just augment runtimepath+= and are happy.

I've helped with maintaining the (neo)vim nixpkgs infra for a few years and I find this untrue. I've changed (ie., shortened) the path towards nixpkgs-installed and it broke vim-plug. Now I want to associate a specific config to a plugin but it meant updating the 4 package managers which is painful for me. I tried to do so and was able for the others but because vam is so confidential (sorry but I've never met anyone using it, and there was no nixpkgs complaint since its removal, there might be in the next stable release though), I could not muster the courage to do so. So much choice is also not great for
the users : why 4 different package managers ? when in the end I won't leverage these plugin managers features because nix already does everything.

if these plugin managers were just maintaing runtimepath then nixpkgs doesn't need them.
vam does a lot more than maintaining runtimepath though as shown in the doc: {'filetype_regex': '\%(vim)$', 'names': ['reload', 'vim-dev-plugin']}. The nixpkgs vam doc shows it's a magnitude more complex than the other approaches (since it does more).
I would like to maintain a single "vimrcContent" path, and then your vam code could just generate the inputs for "vimrcContent".

Like you I am also interested in plugin dependencies, and I have something working that I presented here:
https://teto.github.io/posts/2022-06-22-neovim-plugin-luarocks-2.html
One thing to help maintainers create a package out of their plugin is https://github.com/teto/vim2rockspec; it generates a rockspec from their plugin repository. There is an extracost for the maintainer who now has to maintain a package on luarocks (it doesn't have to be lua, a viml plugin could be hosted there) but the whole community could enjoy plugin dependency resolution with an existing working infrastructure.
For this to be successful I would need packer.nvim to better support luarocks install though but I am hopeful.

[virusdave]

@teto sorry for the thread necromancy, but i just wanted to point out that the vim-utils.nix comments still (as of both nixos-22.11 and master) reference adding plugins via vam. Might want to update those examples. I'm willing to try, but i admittedly don't understand how the current plugin options work, so it'll take me some time to learn it.

(Ran into this updating my (private repo) system flake to nixos-22.11 and it suddenly is warning about my use of vam).

[MarcWeber]

BTW: I recently updated vim-addon-manager to allow loading plugin/*.lua code at runtime after startup. Works great :) VAM is simple. It allows defining a function where plugins are found. And it allows giving plugins a name. So you can install by name or by github:name/foo and you can use VAMActivate at any time startup or lazily after having started up. The only problem is that it doesn't install in parallel.
I can keep private matches.
VAM despite having been influenced by nix it never took off.

But the questions are somewhat different I have. What's the best way to manage Vim on windows without Nix :-)

The reason why VAM was cool in the past was allowing to activate stuff as needed at runtime.
So if you had bad written time consuming plugins they only slowed startup down when you needed them.

And that feature still works and also works with neovim and lua files now.

But what plugins are that slow today and still in use ?

So what's the minimal plugin manager ? Why use one at all ? Why not just set runtimepath and be done then?

What I enjoyed was being able to install by name without having to lookup url cause VAM gets vim-pi which translates names to known github urls (which is biased maybe hard to maintain)

Whats left eventually is mappings. Activate plugins and mappings only when you need.

So the only main use case which is left is like activating vim-addon-sql to run sql queries but had autoload UI
so it was more about the completion overwrite.

Back to you: Do you have use cases for loading plugins at runtime ?

I will / can keep vam as private patch. Don't worry about me.

Now I have tons of small plugins where I use VAM to activate the others.
because there is lack of alterantives. like cmp-tsserver activates my-cmp-mappings.

So I use it as modular sharable vimrc snippets today I can activate by name at runtime.
But its me only and somewhat personal.

[MarcWeber]

The minmial plugin support for to support loading plugins is 1) set runtime path (For startup activation) 2) glob -> source for activation after startup. The glob lines in vim-addon-manager can be found easily. And :helptags is important for documentation (must be run at installation ?). That's all I know which is needed basically.

There is another case for lazy activating plugins: Its snippets. Sometimes depending on template engine you use you might want to use and activate different snippet files. That's something which can be done by rtp or by the addon manager cause many engines just look at &rtp and add /snippets.

And the question would be how shoud a user be able to activate a referenced plugins installed to store without having to type /nix/store/... ? use github:foo/bar like syntax or even what VAM provides -> name rewriting :)

But is it a use case worth taking care of ?

So the minimal VIML or lua code to make this all work can be looked up at VAM handling RTP.
Its also about adding the after/* directories lateer. So its like 20 lines which can be implemented in both viml and lua to have a 'nix' version of a manager to be good enough.

The big question is: Is it worth having aliases for cases like snippets. Are there cases you activate code at runtime and how do you as user want to call it.

And I totally kinda agree that how managers handle post installation hooks (each in his own way) is kinda complicated. And that YCM on Windows eventually requires to be recompiled for each virtual env (?) is yet another story. Does it apply to Linux as well ? .. and ...

I feel its not about VAM. Its more about discussing what features are worth preserving / keeping rather than dropping/adding one addon manager.

https://github.com/MarcWeber/vim-addon-manager/blob/master/autoload/vam.vim#L315
https://github.com/MarcWeber/vim-addon-manager/blob/master/autoload/vam.vim#L422
https://github.com/MarcWeber/vim-addon-manager/blob/master/autoload/vam.vim#L435

Are the most relevant lines to reimplement a nix-vim-plugin manager stripped down to the bare minimum. So its less than 25 lines probably.

Additionally to that VAM maps a plugin name to a file location to find out whether it exists.
So it calls a function which can look up multiple destitanions like ~/vim then dictionary telling about /nix/* locations if all files (ask to) install.

So what's important to me is

1. be able to give VIM a name because my settings are not what others are used to
2. eventually being able to allow additional stuff in ~/.vimrc or ~/.vimrc-name
3. eventually being able to load lazily (how to name plugins)
4. Sometimes being able to overwrite (cause nixos-rebuild could take more time or be not possible)

And VIM kinda allows all. But I agree that the minimal features and the extended features
eventually could be split into 2 pieces. Currently its close by having separate files to be autoloaded as needed.

There could be some more cases. Like opening .nim files with Vim says its filetype is .conf. Even for .ts I didn't get typescript. So if you want to change Vim's behavior for filetypes cause the extension is used by multiple languages doing so in a local vimrc (eg vim-addon-local-vimrc) or at runtime eg using VAMActivate might be helpful to some.