6 ms·

Nvim-treesitter (13K+ Stars) is Archived

178 points by RohanAdwankar 6mo ago

potatosalad99 6mo ago
Honestly this is just a case of open source software users expecting a free lunch. Firstly, the maintainers of this package don’t owe you anything, secondly the new version of neovim and treesitter-cli are already in Arch extra testing, and since they don’t break anything they’ll probably be in extra next week, so chill the fuck out. If you have a problem with how open source works just please head back to vscode.
bedroom_jabroni 6mo ago
Incredibly based response to the "I am the customer" energy in OSS.
porridgeraisin 6mo ago
This is why I built nvim from source, and git pull plugins into the pack directory. I think it's even a static binary. Whatever changes I need I git pull. After they added LSP I have not wished for anything else really, so I stopped pulling. I think I pulled LSP completion API in 0.11 era but that's it. Hate it when people break backwards compatibility. For me it's sacrosanct, more important than absolutely anything else. I only have a handful of plugins so the system works well. And I have a 500 line init.vim (and no other config). Some ecosystems like golang share this principle and so I can freely update packages without worrying about breakages. But other ecosystems(nvim, python, etc) I'm a lone warrior
anuramat 6mo ago
idgi, shitting on the maintainer takes 10x more time than forking the repo I guess he really needed the latest ci/chore commits
Valodim 6mo ago
This was probably near the breaking point before, it just needed an idiot to catalyze.
- shpx 6mo ago
  I had a similar emotional outburst where after contributing hundreds of hours to Stack Overflow, when I asked a question of my own, instead of answering an objective yes/no question people just argued with me in the comments about why I could possibly want to do whatever prompted me to ask my question. I delete my account and quit ever contributing to that site right then and there. I think I was just looking for an out and it was ultimately a good thing. No idea if this is the case here, but I hope the author sticks with this decision. Although, looking at https://github.com/nvim-treesitter/nvim-treesitter/graphs/contributors https://github.com/nvim-treesitter/nvim-treesitter/graphs/co... , it doesn't look like he started this project, so I'm not sure it's his place to archive it.
  - tasuki 6mo ago
    > doesn't look like he started this project, so I'm not sure it's his place to archive it. This is a very valid point. It indeed looks like it was done in affect rather than after careful discussion with the (at least) ten members of the nvim-treesitter org.
    - martin-t 6mo ago
      This is a common issue with tooling used by open source. Either you alone own the repo but then you're a single point of failure. Or you give those perms to others but then any one of them can abuse it (or get hacked). I'd like to see tooling which requires consensus or voting to make certain changes such as archiving a repo or publishing a new release.
  - martin-t 6mo ago
    If you had the option to also delete all your contributions to the side, would you have done it? If you had the option to exclude only certain people (e.g. those who argues with you) from seeing/using your contributions, would you have done it instead of deleting your account? I am asking because I've too been burned and it's very commonly how an open source contributor's journey ends. So I've been toying with the idea that contributors should be able to exclude certain people or perhaps even groups of people from using their work. Basically "I give away my work for free for anyone to use and build upon but if you don't appreciate it, if you treat me like shit, if you do any of X Y Z which hurts me or other people, then you're no longer allowed to use it".
sevg 6mo ago
I will never understand people like GitHub user “shushtain” in the linked issue. So obviously the guy is behaving like an entitled jerk, but it’s also surely counter-productive (volunteer maintainers are unlikely to respond well to plain rudeness)? Unless the goal isn’t a productive outcome, but just to be mean?
- correspondent 6mo ago
  [dead]
- cafebabbe 6mo ago
  Humans are notoriously bad at game theory.
- delusional 6mo ago
  > Unless the goal isn’t a productive outcome, but just to be mean? Some people are just mean. They spend their angry little lives walking around "outraged" by any minor inconvenience. They assume every single little happenstance was designed to make them miserable. The greatest thing about having a good education and working with other experts is that I generally don't meet this people that much, but I remember them all too well.
  - rolandog 6mo ago
    Agreed. However, I often wonder if people like that are deliberately (or inadvertently) being a psyop seeking to burn out people ala how "Jia Tan" tried to become maintainer of xz [0]. [0] https://youtu.be/aoag03mSuXQ?t=597 https://youtu.be/aoag03mSuXQ?t=597
  - faangguyindia 6mo ago
    Being rude is not effortless, it requires someone spending significant amount of energy on you And most people who wronged me were never really rude to me. So i don't even use someone's rudeness as filter for anything.
- faangguyindia 6mo ago
yu3zhou4 6mo ago
Good for the maintainer, hope they find peace and do things just for their fun, without needing to deal with comments like that anymore
- thayne 6mo ago
  Stepping away from the project would be fine. Archiving a project which has other maintainers is an overreaction.
  - streetfighter64 5mo ago
    Not really. If there are other maintainers who have ownership of the project they can just unarchive it themselves. If not, then he'd have to appoint a successor first, which would mean doing more work for free. So the best solution is just to archive it and let the community fork it if they're interested in continuing development. Also your phrasing of "would be fine" implies that there are things that are not "fine" to do when doing work for free for the public benefit, which is exactly the sort of entitled attitude that makes many (myself included) uninterested in open sourcing their own projects.
edem 6mo ago
So what will happen now? Who will take over? Abandoning a project because 1 person is kinda extreme.
- Scandiravian 6mo ago
  I'm pretty sure this is not over a single user, but this was simply the straw that broke the camels back
- fancyfredbot 6mo ago
  What will happen now is not clasons problem anymore I guess. The point they seem to be making is that it never was their problem, but they were just solving it for everyone for free anyway, and in return they were doing it wrong and they should stop interacting with people. Honestly even when people are being paid to work for you and their job is to do what you ask them to, speaking to them like that is never going to work out.
- maleldil 6mo ago
  It's not one person. The maintainer's been getting abuse over their decision to rewrite the plugin for quite some time now, despite being very clear about what they're doing. It's fine for users to be upset, but not to treat the author like this.
bulbar 6mo ago
Genuine question: Why not just close such derailing and burdensome issues and/or block mean people? My guess: People would freak out if FOSS maintainers actually did this.
- andwur 6mo ago
  From personal experience that usually results in the person on the attack opening two additional issues: 1) the original issue recreated, maybe with a childish flourish added e.g. "because we're apparently in the DPKR for this project" 2) a new issue claiming baseless censorship and attacking the maintainer(s) motivation and governance A variation on this is the above plus they get a hoard of friends/wellwishers/bots etc to raise more issues claiming censorship and it devolves into a massive ad hominem flame war, doxxing, death threats and the usual rubbish that ruin a good thing.
siva7 6mo ago
I get anxiety publishing open source because of things like this.
- altairprime 6mo ago
  The one GitHub repository of original work I publish right now is kept in Archived at rest; I unarchive it to push commits and then rearchive it, every time. It has been perfectly quiet and my anxiety associated with working on it has dropped to zero. Highly recommended.
  - el_io 6mo ago
    Can't you just disable issues? I've seen DRF did that. Not sure if that is not possible for normal accounts.
    - altairprime 6mo ago
      I couldn’t when I started out doing that. But I don’t want PRs, either, so this works out for the best: I contribute a benefit and if someone forks it then I can consider merging their work unbothered by their expectations that their ‘request’ be granted.
      - thayne 6mo ago
        You can disable PRs as well
        altairprime 5mo ago
        Overlooking your repeated assumptions of my incompetence at GitHub administration, neither of the 'why not just' steps you countered with will result in the banner that says 'This project is archived', which is a key component of my intentions. (For those who overlook it, the other characteristics of archival of course still suffice; I get all three for one UX interaction rather than three!) Which of these projects is more likely, relative to the other in its pair, to be targeted by users whose expectations are presented disrespectfully by whatever means (let's assume email) the users can discover? 1a) A project that has recent commits, but has pull requests and issues disabled. 1b) That exact same project, with the banner "This repository was archived by the owner" shown on all pages and objects within it. 2a) A project that left a work in progress unfinished six months ago, but has pull requests and issues disabled. 2b) That exact same project, with the banner "This repository was archived by the owner [six months ago]" shown on all pages and objects within it. As one can reasonably predict, archiving when I'm not actively pushing commits turns out to be an effective way to stem the tide of jerks who otherwise pick a fight by email/irc / discord/forum / blah/blah / etc., in hopes of persuading me to commit further resources to their unpaid benefit or to finish something I don't care to work on finishing right now / this week/month / quarter/semester / year/decade / ever. It's archived, so clearly it'll never be finished, which helps enforce an appropriate calibration of expectations upon those desiring the outcome — and if I someday finish it, hooray, but no one has any plausible way to justify any expectations to the contrary, no matter how hard they wish otherwise. Thus why I recommend using archiving to remove the social pressure component of working in public on GitHub. Of course, if you have a better solution than you've offered so far here, I'm certainly willing to consider it.
ivanjermakov 6mo ago
This is a bane of all such aggregator libraries, that suck maintetance from other projects into themself. Null-ls suffered from this, too: https://github.com/jose-elias-alvarez/null-ls.nvim/issues/1621 https://github.com/jose-elias-alvarez/null-ls.nvim/issues/16... The source of a library needs an update every time there is a configuration change in _any_ tree-sitter parser supported. The only sustainable option is not use these helpers and manage editor dependencies manually: tree-sitter parsers, LSP servers (looking at you Mason), and plugins (looking at you neovim distros).
- fredrikaverpil 6mo ago
  Managing the parsers yourself is fairly easy and could rely on running the tree-sitter CLI in each parser repo to build them. Other options exists like installing via Nix. And in a similar vein, if queries (.scm files) were hosted in each parser repo, it would also be fairly easy to handle. I think it’s the latter part with the query files that is the challenge here.
  - ivanjermakov 6mo ago
    Queries are a part of tree-sitter, but unfortunately neovim extended those with more predicates and operators, making most nvim-sitter incompatible with tree-sitter API. For my text editor I had to yank nvim-treesitter queries and rewrite them. https://github.com/ivanjermakov/hat-tree-sitter https://github.com/ivanjermakov/hat-tree-sitter
- thayne 6mo ago
  I think it would make a big difference even if the aggregation of queries was separated out into a separate repo from the other code, so that you can pin the code for installing and updating parsers while still being able to get updates to the queries, and it isn't as much of a problem if the installation code make major breaking changes (like requiring you to use 0.12)
cjbayliss 6mo ago
The Fandom Menace strikes again. But seriously, this is messed up. People need to learn to treat others with respect and kindness. Hopefully the maintainer is able to simply move on after archiving the repo, and isn't dealing with any mental struggles from dealing with years of entitled users demanding things for free. In popular open source projects this is a recurring issue. I suspect the only way to deal with it is to either shift to a platform that has better tools for moderation, or end the project like the maintainer has done. Let someone else fork it and deal with the users. To clason: Thank you for all the work you did maintaining nvim-treesitter!
- 2716057 6mo ago
  I would not worry too much about the maintainer - judging by his GitHub profile he does a bit of professoring as a side hustle ;) Thank you Christian Clason for giving us nvim-treesitter! And always remember, for each idiot insulting you there are thousands of happy, silent users.
cherioo 6mo ago
It’s like the law of big numbers. Once a project grows large enough, some entitled free-riders are bound to pop up. What to do as maintainer? Can everyone of them find piece?
kzrdude 6mo ago
Nvim treesitter is kind of taken for granted even if nvim maintainers say it's experimental. So I think the community will have to find a solution and replacement project.
- burnt-resistor 6mo ago
  The fork button exists. That's the technically easiest solution.
  - eqvinox 5mo ago
    Unfortunately this is a social problem, requiring a social solution, not a technical one. (Which isn't to say that the solution won't involve pressing the fork button. But just pressing that button doesn't solve anything.)
    - burnt-resistor 5mo ago
      That's true. Good governance, initiative, and leadership are rare and nonzero cost. The big plus is that the code is FOSS rather than closed source. It would really suck way more if it were closed and suddenly went away.
hacker_homie 6mo ago
Honestly I missed the neovim 12.0 being marked stable, and just updated when this happened.
xvilka 6mo ago
Will this mean the end to NeoVim, whose main (one of) selling point is the tree-sitter out of the box? I hope not, as I am the long time user and supporter of the project.
- maleldil 6mo ago
  tree-sitter still works. Many features are implemented in neovim itself. This project provides an easy way to set up parsers for various languages (including installation and retrieval of necessary queries), along with some quality-of-life features. You can just fork it, and it will work perfectly fine for the 0.12 cycle (barring any underlying parser changes), or you can fork the previous version on the master branch if you want to keep using 0.11. Considering this is a very common plugin in the neovim ecosystem, it will probably get forked and maintained by someone else, like null-ls was forked into none-ls.
- streetfighter64 5mo ago
  Very strange attitude towards open source. One guy decides to stop working for free, leaving all of his work publicly accessible for anyone to continue to build upon, and the response is "well, I guess that's the end of that project". I'm guessing the attitude of "users and supporters" of the project such as shushtain complaining and wanting clason to do all the work instead of just doing it themselves, was a factor in him deciding to step away from the project.
xiphias2 6mo ago
Isn't treesitter integrated to nvim anyways at this point, even if it's experimental support?
- maleldil 6mo ago
  You could probably make things work without nvim-treesitter, but it's an additional maintenance burden you're taking on. As the repo itself says, it's an abstraction layer. You don't _need_ it, but it's nice to have.
onehair 6mo ago
> since people apparently can't read I know Free and OpenSource software is only available thanks to maintainers who spend their time and money to make it available. This type of sentence though, makes all I just mentioned easy to forget, when they take that tone with you.
- mongrelion 6mo ago
  It's clear to me that the maintainer is referring to "shushtain" and those type of people > when they take that tone with you. This makes it sound as if you took it personally?
loeschzwerg 5mo ago
"dont be a shushtain" will now be part of my vocabulary. honestly, i think one of the main reasons why large projects like kernel.org survive shushtains are guard dogs like linus torvalds. only if people have a decent amount of respect maintainers will actually scald them for saying smth utterly stupid, entitlement is kept at bay through being nudged towards going the extra mile themselves. after all, people do not apologize for acting entitled.
shushtain 5mo ago
[dead]

178 points by RohanAdwankar 6mo ago

Honestly this is just a case of open source software users expecting a free lunch. Firstly, the maintainers of this package don’t owe you anything, secondly the new version of neovim and treesitter-cli are already in Arch extra testing, and since they don’t break anything they’ll probably be in extra next week, so chill the fuck out. If you have a problem with how open source works just please head back to vscode.

bedroom_jabroni 6mo ago

Incredibly based response to the "I am the customer" energy in OSS.

porridgeraisin 6mo ago

This is why I built nvim from source, and git pull plugins into the pack directory. I think it's even a static binary. Whatever changes I need I git pull. After they added LSP I have not wished for anything else really, so I stopped pulling. I think I pulled LSP completion API in 0.11 era but that's it. Hate it when people break backwards compatibility. For me it's sacrosanct, more important than absolutely anything else. I only have a handful of plugins so the system works well. And I have a 500 line init.vim (and no other config). Some ecosystems like golang share this principle and so I can freely update packages without worrying about breakages. But other ecosystems(nvim, python, etc) I'm a lone warrior

anuramat 6mo ago

idgi, shitting on the maintainer takes 10x more time than forking the repo I guess he really needed the latest ci/chore commits

Valodim 6mo ago

This was probably near the breaking point before, it just needed an idiot to catalyze.

shpx 6mo ago
I had a similar emotional outburst where after contributing hundreds of hours to Stack Overflow, when I asked a question of my own, instead of answering an objective yes/no question people just argued with me in the comments about why I could possibly want to do whatever prompted me to ask my question. I delete my account and quit ever contributing to that site right then and there. I think I was just looking for an out and it was ultimately a good thing. No idea if this is the case here, but I hope the author sticks with this decision. Although, looking at https://github.com/nvim-treesitter/nvim-treesitter/graphs/contributors https://github.com/nvim-treesitter/nvim-treesitter/graphs/co... , it doesn't look like he started this project, so I'm not sure it's his place to archive it.
- tasuki 6mo ago
  > doesn't look like he started this project, so I'm not sure it's his place to archive it. This is a very valid point. It indeed looks like it was done in affect rather than after careful discussion with the (at least) ten members of the nvim-treesitter org.
  - martin-t 6mo ago
    This is a common issue with tooling used by open source. Either you alone own the repo but then you're a single point of failure. Or you give those perms to others but then any one of them can abuse it (or get hacked). I'd like to see tooling which requires consensus or voting to make certain changes such as archiving a repo or publishing a new release.
- martin-t 6mo ago
  If you had the option to also delete all your contributions to the side, would you have done it? If you had the option to exclude only certain people (e.g. those who argues with you) from seeing/using your contributions, would you have done it instead of deleting your account? I am asking because I've too been burned and it's very commonly how an open source contributor's journey ends. So I've been toying with the idea that contributors should be able to exclude certain people or perhaps even groups of people from using their work. Basically "I give away my work for free for anyone to use and build upon but if you don't appreciate it, if you treat me like shit, if you do any of X Y Z which hurts me or other people, then you're no longer allowed to use it".

sevg 6mo ago

I will never understand people like GitHub user “shushtain” in the linked issue. So obviously the guy is behaving like an entitled jerk, but it’s also surely counter-productive (volunteer maintainers are unlikely to respond well to plain rudeness)? Unless the goal isn’t a productive outcome, but just to be mean?

correspondent 6mo ago
[dead]
cafebabbe 6mo ago
Humans are notoriously bad at game theory.
delusional 6mo ago
> Unless the goal isn’t a productive outcome, but just to be mean? Some people are just mean. They spend their angry little lives walking around "outraged" by any minor inconvenience. They assume every single little happenstance was designed to make them miserable. The greatest thing about having a good education and working with other experts is that I generally don't meet this people that much, but I remember them all too well.
- rolandog 6mo ago
  Agreed. However, I often wonder if people like that are deliberately (or inadvertently) being a psyop seeking to burn out people ala how "Jia Tan" tried to become maintainer of xz [0]. [0] https://youtu.be/aoag03mSuXQ?t=597 https://youtu.be/aoag03mSuXQ?t=597
- faangguyindia 6mo ago
  Being rude is not effortless, it requires someone spending significant amount of energy on you And most people who wronged me were never really rude to me. So i don't even use someone's rudeness as filter for anything.
faangguyindia 6mo ago

yu3zhou4 6mo ago

Good for the maintainer, hope they find peace and do things just for their fun, without needing to deal with comments like that anymore

thayne 6mo ago
Stepping away from the project would be fine. Archiving a project which has other maintainers is an overreaction.
- streetfighter64 5mo ago
  Not really. If there are other maintainers who have ownership of the project they can just unarchive it themselves. If not, then he'd have to appoint a successor first, which would mean doing more work for free. So the best solution is just to archive it and let the community fork it if they're interested in continuing development. Also your phrasing of "would be fine" implies that there are things that are not "fine" to do when doing work for free for the public benefit, which is exactly the sort of entitled attitude that makes many (myself included) uninterested in open sourcing their own projects.

edem 6mo ago

So what will happen now? Who will take over? Abandoning a project because 1 person is kinda extreme.

Scandiravian 6mo ago
I'm pretty sure this is not over a single user, but this was simply the straw that broke the camels back
fancyfredbot 6mo ago
What will happen now is not clasons problem anymore I guess. The point they seem to be making is that it never was their problem, but they were just solving it for everyone for free anyway, and in return they were doing it wrong and they should stop interacting with people. Honestly even when people are being paid to work for you and their job is to do what you ask them to, speaking to them like that is never going to work out.
maleldil 6mo ago
It's not one person. The maintainer's been getting abuse over their decision to rewrite the plugin for quite some time now, despite being very clear about what they're doing. It's fine for users to be upset, but not to treat the author like this.

bulbar 6mo ago

Genuine question: Why not just close such derailing and burdensome issues and/or block mean people? My guess: People would freak out if FOSS maintainers actually did this.

andwur 6mo ago
From personal experience that usually results in the person on the attack opening two additional issues: 1) the original issue recreated, maybe with a childish flourish added e.g. "because we're apparently in the DPKR for this project" 2) a new issue claiming baseless censorship and attacking the maintainer(s) motivation and governance A variation on this is the above plus they get a hoard of friends/wellwishers/bots etc to raise more issues claiming censorship and it devolves into a massive ad hominem flame war, doxxing, death threats and the usual rubbish that ruin a good thing.

siva7 6mo ago

I get anxiety publishing open source because of things like this.

altairprime 6mo ago
The one GitHub repository of original work I publish right now is kept in Archived at rest; I unarchive it to push commits and then rearchive it, every time. It has been perfectly quiet and my anxiety associated with working on it has dropped to zero. Highly recommended.
- el_io 6mo ago
  Can't you just disable issues? I've seen DRF did that. Not sure if that is not possible for normal accounts.
  - altairprime 6mo ago
    I couldn’t when I started out doing that. But I don’t want PRs, either, so this works out for the best: I contribute a benefit and if someone forks it then I can consider merging their work unbothered by their expectations that their ‘request’ be granted.
    - thayne 6mo ago
      You can disable PRs as well
      - altairprime 5mo ago
        Overlooking your repeated assumptions of my incompetence at GitHub administration, neither of the 'why not just' steps you countered with will result in the banner that says 'This project is archived', which is a key component of my intentions. (For those who overlook it, the other characteristics of archival of course still suffice; I get all three for one UX interaction rather than three!) Which of these projects is more likely, relative to the other in its pair, to be targeted by users whose expectations are presented disrespectfully by whatever means (let's assume email) the users can discover? 1a) A project that has recent commits, but has pull requests and issues disabled. 1b) That exact same project, with the banner "This repository was archived by the owner" shown on all pages and objects within it. 2a) A project that left a work in progress unfinished six months ago, but has pull requests and issues disabled. 2b) That exact same project, with the banner "This repository was archived by the owner [six months ago]" shown on all pages and objects within it. As one can reasonably predict, archiving when I'm not actively pushing commits turns out to be an effective way to stem the tide of jerks who otherwise pick a fight by email/irc / discord/forum / blah/blah / etc., in hopes of persuading me to commit further resources to their unpaid benefit or to finish something I don't care to work on finishing right now / this week/month / quarter/semester / year/decade / ever. It's archived, so clearly it'll never be finished, which helps enforce an appropriate calibration of expectations upon those desiring the outcome — and if I someday finish it, hooray, but no one has any plausible way to justify any expectations to the contrary, no matter how hard they wish otherwise. Thus why I recommend using archiving to remove the social pressure component of working in public on GitHub. Of course, if you have a better solution than you've offered so far here, I'm certainly willing to consider it.

ivanjermakov 6mo ago

This is a bane of all such aggregator libraries, that suck maintetance from other projects into themself. Null-ls suffered from this, too: https://github.com/jose-elias-alvarez/null-ls.nvim/issues/1621 https://github.com/jose-elias-alvarez/null-ls.nvim/issues/16... The source of a library needs an update every time there is a configuration change in _any_ tree-sitter parser supported. The only sustainable option is not use these helpers and manage editor dependencies manually: tree-sitter parsers, LSP servers (looking at you Mason), and plugins (looking at you neovim distros).

fredrikaverpil 6mo ago
Managing the parsers yourself is fairly easy and could rely on running the tree-sitter CLI in each parser repo to build them. Other options exists like installing via Nix. And in a similar vein, if queries (.scm files) were hosted in each parser repo, it would also be fairly easy to handle. I think it’s the latter part with the query files that is the challenge here.
- ivanjermakov 6mo ago
  Queries are a part of tree-sitter, but unfortunately neovim extended those with more predicates and operators, making most nvim-sitter incompatible with tree-sitter API. For my text editor I had to yank nvim-treesitter queries and rewrite them. https://github.com/ivanjermakov/hat-tree-sitter https://github.com/ivanjermakov/hat-tree-sitter
thayne 6mo ago
I think it would make a big difference even if the aggregation of queries was separated out into a separate repo from the other code, so that you can pin the code for installing and updating parsers while still being able to get updates to the queries, and it isn't as much of a problem if the installation code make major breaking changes (like requiring you to use 0.12)

cjbayliss 6mo ago

The Fandom Menace strikes again. But seriously, this is messed up. People need to learn to treat others with respect and kindness. Hopefully the maintainer is able to simply move on after archiving the repo, and isn't dealing with any mental struggles from dealing with years of entitled users demanding things for free. In popular open source projects this is a recurring issue. I suspect the only way to deal with it is to either shift to a platform that has better tools for moderation, or end the project like the maintainer has done. Let someone else fork it and deal with the users. To clason: Thank you for all the work you did maintaining nvim-treesitter!

2716057 6mo ago
I would not worry too much about the maintainer - judging by his GitHub profile he does a bit of professoring as a side hustle ;) Thank you Christian Clason for giving us nvim-treesitter! And always remember, for each idiot insulting you there are thousands of happy, silent users.

cherioo 6mo ago

It’s like the law of big numbers. Once a project grows large enough, some entitled free-riders are bound to pop up. What to do as maintainer? Can everyone of them find piece?

kzrdude 6mo ago

Nvim treesitter is kind of taken for granted even if nvim maintainers say it's experimental. So I think the community will have to find a solution and replacement project.

burnt-resistor 6mo ago
The fork button exists. That's the technically easiest solution.
- eqvinox 5mo ago
  Unfortunately this is a social problem, requiring a social solution, not a technical one. (Which isn't to say that the solution won't involve pressing the fork button. But just pressing that button doesn't solve anything.)
  - burnt-resistor 5mo ago
    That's true. Good governance, initiative, and leadership are rare and nonzero cost. The big plus is that the code is FOSS rather than closed source. It would really suck way more if it were closed and suddenly went away.

hacker_homie 6mo ago

Honestly I missed the neovim 12.0 being marked stable, and just updated when this happened.

xvilka 6mo ago

Will this mean the end to NeoVim, whose main (one of) selling point is the tree-sitter out of the box? I hope not, as I am the long time user and supporter of the project.

maleldil 6mo ago
tree-sitter still works. Many features are implemented in neovim itself. This project provides an easy way to set up parsers for various languages (including installation and retrieval of necessary queries), along with some quality-of-life features. You can just fork it, and it will work perfectly fine for the 0.12 cycle (barring any underlying parser changes), or you can fork the previous version on the master branch if you want to keep using 0.11. Considering this is a very common plugin in the neovim ecosystem, it will probably get forked and maintained by someone else, like null-ls was forked into none-ls.
streetfighter64 5mo ago
Very strange attitude towards open source. One guy decides to stop working for free, leaving all of his work publicly accessible for anyone to continue to build upon, and the response is "well, I guess that's the end of that project". I'm guessing the attitude of "users and supporters" of the project such as shushtain complaining and wanting clason to do all the work instead of just doing it themselves, was a factor in him deciding to step away from the project.

xiphias2 6mo ago

Isn't treesitter integrated to nvim anyways at this point, even if it's experimental support?

maleldil 6mo ago
You could probably make things work without nvim-treesitter, but it's an additional maintenance burden you're taking on. As the repo itself says, it's an abstraction layer. You don't _need_ it, but it's nice to have.

onehair 6mo ago

> since people apparently can't read I know Free and OpenSource software is only available thanks to maintainers who spend their time and money to make it available. This type of sentence though, makes all I just mentioned easy to forget, when they take that tone with you.

mongrelion 6mo ago
It's clear to me that the maintainer is referring to "shushtain" and those type of people > when they take that tone with you. This makes it sound as if you took it personally?

loeschzwerg 5mo ago

"dont be a shushtain" will now be part of my vocabulary. honestly, i think one of the main reasons why large projects like kernel.org survive shushtains are guard dogs like linus torvalds. only if people have a decent amount of respect maintainers will actually scald them for saying smth utterly stupid, entitlement is kept at bay through being nudged towards going the extra mile themselves. after all, people do not apologize for acting entitled.

shushtain 5mo ago

[dead]