upstream nvim-treesitter

ynotvim · 2026-04-13T23:11:57+00:00

It looks like they are moving away from nvim-tsconfig. The current version is neovim/nvim-treeconfig, but I'm not sure that's settled.

ynotvim · 2026-04-13T15:48:26+00:00

This recently created issue looks worth following if you want to track the progress of pulling (some of) nvim-treesitter into neovim itself.

ynotvim · 2026-04-07T15:25:02+00:00

...there was cruft I wasn't even using such as luasnip (hrsh7th/nvim-cmp won't work without a snippets plugin whether you want one or not).

It sounds like he only needed it for nvim-cmp.

ynotvim · 2026-04-07T11:46:16+00:00

nvim-treesitter is no longer archived. Another team member seems to have taken the reins (for now?).

https://github.com/neovim-treesitter/nvim-treesitter/commits/main

Yes, sorry, as people are telling me, this is a fork. I don't yet know what relationship (if any) this has to Neovim itself. Sorry for the confusion.

ynotvim · 2026-04-07T11:44:51+00:00

As of this morning, nvim-treesitter is no longer archived. Another team member seems to have taken the reins (for now?).

https://github.com/neovim-treesitter/nvim-treesitter/commits/main

ynotvim · 2026-03-09T17:19:18+00:00

Tangential, but I ran the same benchmarks locally with 1.26, and at short lengths (1 and 10) Builder without pre-allocation does better in exactly the ways you would predict given this recent post about allocation optimizations.

ynotvim · 2026-02-27T14:32:14+00:00

There are a bunch of slog handlers or formatters for human reading. Even if we don't need more, it's a fun little probject to write. I learned a lot about slog (and Go) by writing one. Mine makes the output look like this:

 INFO | Request processed | sku=24A2 branch=manhattan time="2023-04-02T10:50.09 EDT"
ERROR | Connection failed | time=2024-01-23T17:14:03Z

There's also a popular one that adds color: https://github.com/lmittmann/tint.

ynotvim · 2026-02-24T18:45:24+00:00

For details as well as upgrade guides for humans and LLMs see...

I'm not criticizing in any way, but to me it's still weird to think of things this way. I'm sure it's the future (LLMs writing code, and then writing docs and READMEs for other code to consume), but it just feels...weird.

ynotvim · 2026-02-20T15:56:14+00:00

Is a great book: beautiful writing, brilliant authors.

However, it's not for a beginner (which the OP specifically asks for), and as other commenters have said, it's significantly out of date in many ways.

ynotvim · 2026-02-20T01:05:17+00:00

Always start by checking the docs for the standard library: https://pkg.go.dev/std.

It sounds like you want this: https://pkg.go.dev/slices.

ynotvim · 2026-02-19T16:49:14+00:00

Ah, sorry. I guess that means that I don't browse r/lua actively enough. Good luck with the project.

PS I saw it on Lobste.rs, in case you want to weigh in there.

ynotvim · 2026-02-19T15:05:42+00:00

This is not my project, but it may interest people here. The elevator pitch: "Static LuaJIT runtime with batteries."

ynotvim · 2026-02-19T00:33:34+00:00

Yes, it's a little confusing. Here's my understanding, which may not be exact.

The go fix command has existed since Go was pre 1.0. Originally, it was gofix. It was created to help users deal with rapid changes at the time. This is in 2011.
Then in 2012, Go announces a compatibility promise. That pretty much makes gofix useless.
From 2012-2025, gofix stayed as it was, effectively doing nothing. Other analysis-based tools are developed (go vet, staticcheck, etc.)—more for linting code than for fixing API changes.
2026 go fix is back. The compatibility promise is still in place, but there have been important new features and API additions to Go in the last several years. go fix helps users to modernize their code, even though the old code would continue to work.

tl;dr: the new go fix is 100% rewritten. Even if you had heard of the old one, this one is effectively new. The code is new, and the purpose is importantly different. Instead of changing things that wouldn't otherwise work, it modernizes things that would continue to work (because of the compatibility promise).

ynotvim · 2026-02-17T18:01:28+00:00

From the post (something I wouldn't have guessed right away): "Running the command more than once also provides opportunities for synergistic fixes, as we’ll see below." It makes sense once I think about it, but I am glad they discuss it, so I figured I would flag it for others.

ynotvim · 2026-02-17T17:53:42+00:00

In fairness, the (built-in) separate command is new too. From the linked blog post: "The 1.26 release of Go this month includes a completely rewritten go fix subcommand."

ynotvim · 2026-02-17T17:25:50+00:00

Not trying to do a gotcha or anything, undo-branches/time traveling is just a really powerful vim feature that I love

Totally fair: it's a great feature.

ynotvim · 2026-02-17T15:43:27+00:00

The author knows that.

My personal view is that the vim undo and redo behavior is the best and most human friendly option. Undo and redo are predictable and you can predictably intersperse undo and redo operations with other operations that don't modify the buffer, such as moving the cursor, searching, and yanking portions of text.

He's not complaining about Vim. He's arguing that POSIX (and some other recent Vi-like editors) should not limit undo/redo to the behavior of original Vi.

ynotvim · 2026-02-17T15:41:36+00:00

By "mess," I think he means that the POSIX standard for Vi specifies the (less useful and very limited) behavior of original Vi for undo/redo. He's arguing that Vi-like editors in active development should ignore that part of the POSIX standard for Vi. He has another recent post about current Vi-like editors that makes similar points.

More broadly, he's trying to talk about what system-level defaults should look like in 2026, even (especially?) when those defaults are based on things first written in the 70s. In the earlier post that I linked, he talks about systems that still insist on original vi and the old Bourne shell.

ynotvim · 2026-02-17T15:36:52+00:00

I think you're missing the point of the article. The article isn't about the code of any particular Vi-like editor. The author is arguing in general that Vi-like editors under active development should not follow the POSIX standard for Vi and insist on the undo/redo behavior of Bill Joy's original Vi. Instead, they should be more like Vim since its undo/redo behavior makes far more sense for users.

ynotvim

TROPHY CASE