Larger types are supported, there is A notion of tearing. According to JVM spec even long and double could tear, not sure about practical implications though
I have converged on a workflow that is just what I was doing before, but use LLMs just for boring or tedios parts. General guidelines are: only single agent at a time, small targeted queries, understand what you are building, if something would seem like a fun task, do it yourself. I use LLMs for bug hunting, to trace the flow, to build quick visualizatios (paste csv, ask to generate visualization), to search in the code of the dependencies using github mcp, to write 100 line scripts (deno + ts + zx was a game changer for me). Even "dumber" opensource models are good for this kind workflow, more tokens per second is generally more benefitial than plain intelligence. I would use LLMs more or less, sometimes even full vibecoding if the task is something like quick tooling web app and the flow is just firing of the next LLM query every 30 seconds. But, depending on the type of task or domain that you work in, YMMV
Not sure why people praise Minecraft for this. This is huge feat of Wayland, and was possible because devs took time to consider use cases outside of current norm, and why it took so long to migrate the ecosystem. People liked to bitch about the "Gnome blocking/not implementing essential protocols" part, but even that partially made this possible
This is the idea I had in mind since initial wasm release but wasm wasn't ready then but now it is. Glad to see somebody is working on this. If executed properly this could be the last windows manager that people will ever need
I was more thinking in terms of creating a benchmark which would optimized during training. For regular projects, I agree, you have to count that anyway
Pantograph[0] seems to be a more recent attempt to implement the same idea. It is still not a general editor but generalizing it to ranges of tree selections looks promising
There are certainly different possibilities of where the line would be drawn. I am not that familiar with vim internals, but I don't consider file management to be part of vim editing model. And we are only talking about editing model (e.g. b being beginning of a word), not the whole editor (plugin system, ui, lsp and treesitter integration, etc). Though it is true that some parts are more tightly related to "vim". There some cases were Neovim already wants to disconnect itself from vim legacy like allowing to scroll viewport without moving the cursor
By "recreating everything" I was also referring to the ecosystem around the editor
I didn't really spent time thinking about it, because from reading their issue tracker, I very much doubt neovim would consider something like that. Partially because of how much of it is already vim specific and it would be very difficult to abstract that away, but mostly because of ideology.
You can already to a lot in Neovim with plugins, including recreating Helix, Ki, whatever. But the problem is that the vim state machine is always present underneath it, resulting in unwanted behaviors or impossibility to implement some things. I would envision it to pretty much allow to listen on raw keyboard and mouse events. However cursed it sounds, it should be possible to fully implement vscode or any other editing model in neovim
It's a shame that editors are build around the editing model, so much time has been wasted by recreating everything. Neovim is a perfect editor in many aspects but editing model is not one of them, in my opinion. Helix or even Ki would not be needed if Neovim allowed to completely replace the vim part of it with plugins
To some extend that is true for any opinionated piece of software. But that is a beauty of opensource don't use it if it doesn't match your idea of how that software should look like
Having been in the community for some time, it is just how the authors are, very enthusiastic about the wording. They like to come up with some wild terms explaining different behaviors and reasoning behind those behaviors, like "positional coherence" or "behavioral asymmetry", and the term "kimmunity" to reference to ki editor community. On a surface level, sure, it looks LLM generated, but I would be very surprised if they used LLM to generate that sentence. I choose to look at the actual meaning of the content and what they are trying to do differently
Have you tried Ki Editor[0]? It seems to be more into direction that you are looking for. It is not as mature as the rest of the editors but the editing model is definitely an improvement from ux perspective