Vim version

[Konfekt]

The new plugin targets Neovim and has been rewritten in Lua to avoid restrictions of the old plugin:

I'm optimistic that these could also be implemented in Vim:

Avoid the use of temporary files in the same folder as the .ipynb files potentially clashing with paired scripts.
Added support for obtaining the notebook language from its metadata, enabling use of the "script" and "auto" format.
Added support for automatic synchronization with paired files.

Would you consider resurrecting the Vim repo if a PR eventually addressed these?

[goerz]

Yes, having done the Lua version, I agree that most of this could be translated back to vimscript for a "v2" of the original plugin. One caveat is that the Lua version uses Neovim's builtin JSON parser to get metadata from the original notebook file. That would probably have to be done via calls to the external jq tool in a vimscript version.

The only reason the vimscript repo is archived is that I'm not going to maintain it in the foreseeable future. That includes monitoring or merging PRs. If someone wanted to take over as a maintainer, I'd be open to adding them to the repo and un-archiving it. On the other hand, it might make more sense for a new maintainer to fork it to their account. If there's a maintained version that stands out, I'd be happy to link to it from the README.

[Konfekt]

Sounds reasonable. About the JSON, I am wondering if :help json_decode()

#  doc/builtin.txt (lines 6140-6143)
json_decode({string})				*json_decode()* *E491*
		This parses a JSON formatted string and returns the equivalent
		in Vim values.  See |json_encode()| for the relation between
		JSON and Vim values.

helps? I'd be open to overseeing PRs at the repo, but maybe someone else has higher stakes than I (who currently does not use it; it's just too useful to be abandoned).

[goerz]

Oh, that's interesting! I didn't know plain vim also had a json parser built in. So then, yeah, it should totally be possible to translate this back to vimscript.

In any case, if you or anyone else wants to continue maintenance of the vimscript version, the first step would definitely be to fork it and start working on it. After that, we can see if it makes sense to re-open the original repo and push changes from the fork back to the original.

If there is any future development of the vimscript version, I would probably want it to only move in a direction that is compatible with the new lua version. In theory, if I found myself in a situation where I had to use vim (not neovim), I could see myself wanting to resurrect the old plugin and translate the lua code back to vimscript 1-to-1. That seems very unlikely, though. I'm finding it hard to come up with a scenario where I (or anyone) would not be able to use Neovim, or why the original vim really still needs to exist. I feel like Bram's death would have been the point where vim should have moved into a feature freeze and minimum maintenance mode, just to keep it available for those legacy systems that Neovim dropped support for.

[Konfekt]

I'm finding it hard to come up with a scenario where I (or anyone) would not be able to use Neovim, or why the original vim really still needs to exist. I feel like Bram's death would have been the point where vim should have moved into a feature freeze and minimum maintenance mode

Bram might have died, but it's still a long way from Neovim replacing Vim on most installations. First step would be Debian dropping it, and that doesn't seem imminent.
True though that it lacks new features like Treesitter as it is in maintenance mode.