Upstreaming?

[WhyNotHugo]

First off, thanks for maintaining this!

I'm wondering if there are plans to upstream these improvements into the upstream Vim syntax highlighting, so that this is directly bundled with Vim.

It seems there's been a lot of improvements on this fork, so I'm curious why not merge them back.

I've looked around a bit and haven't seen mentions of this, so I'm not sure if this has been discussed or not.

It mostly feels odd that Vim ships a "less enhanced" version, and that there's a fork with further improvements -- maybe efforts could be unified?

[Lilja]

Also, what's the state of this project? Perhaps someone else should help out with maintaining this since it can take quite a while to get responses for pull requests.

[adrian5]

Ditto. In theory, the liberal license doesn't prevent one from just forking it, if necessary. The config toggles would have to be ripped out (and a default agreed upon), but that shouldn't be too hard. Vim already ships with other syntax files that have very fine grained rules.

I cannot judge whether the ruleset is robust enough in its current state, looking at those unresolved error reports.

Edit: Actually, the config toggles don't have to be ripped out – I looked at the file shipped with Vim and it has some too. But I nonetheless think a sane default is better than multiple toggles.

[nfnty]

If the upstream maintainers feel like this is a good addition, then I'd be all for it. But don't really feel like doing the leg work currently. If anyone wants to start the ball rolling, then I'd help out.

[adrian5]

NOTE: This was a reply to a now-deleted comment.

In some areas vim and neovim progress rapidly, and have been doing so for a long time, but in others there are these eternal deadlocks. See also: rust.vim. I use vim-polyglot, but for ubiquitous languages like Python, highlighting should be top out of the box imo.

For neovim there's promise ahead, since tree-sitter grammar should make it into the next stable release (0.5), offering superior syntax highlighting (and more) for the most popular languages.

[WhyNotHugo]

Yeah, I've moved onto tree-sitter on neovim-nightly, and I think that's the way to go in future.

It's honestly far simpler (and lighter) than having to keep track of a bunch of plugins (polyglot includes lots of highlight-unrelated features which get in the way for me).

[WhyNotHugo]

Why is it funny that grammar definitions are in JS? It's really the end result that counts, IMHO.

I agree on the amount of languages missing being pretty high -- however, we're specifically discussing python in this issue.

[adrian5]

@89z Well I didn't suggest it, but mentioned that nvim is taking another route. From what I can tell, the Node.js dependency–alluded to in the issue–applies to developers only; end-users can consume and build the (C) parsers directly. I've been using nvim-treesitter before and don't recall needing a JavaScript runtime for that. I dislike the whole JavaScript ecosystem as well, so I sympathize, but if the burden falls on developers alone, I think that's a fair tradeoff.

In term of highlighting quality, Tree-Sitter (in Atom) has been better than anything I've used before. Anyway, we're strongly veering off-topic, a better Python syntax in vanilla vim remains a worthwhile pursuit!

[WhyNotHugo]

You are correct, @adrian5. While the grammars are written in JS, that's just used as input to generate and build C code. Hence, the efficiency of it.

Having written a [very simple] grammar, I have to admit that it's very easy and simple, and provides incredibly efficient results.

Anyway, we're strongly veering off-topic, a better Python syntax in vanilla vim remains a worthwhile pursuit!

Since tree-sitter will be part of the next neovim stable release anyway, I don't feel very motivated to go through the whole process of upstreaming and then waiting for it to be merged back down.

I do appreciate all the work into maintaining vim-python for all these years, it's been great!

I'm okay with closing, unless someone wants to pick this up or a maintainer prefers to leave it open.