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
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
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
> I would envision it to pretty much allow to listen on raw keyboard and mouse events.
This is pretty much how the BRIEF editor for programmers worked, which was used in MS-DOS around 1990. In my opinion this was one of the best programs that I have ever encountered and I have never encountered again some of the good UI features that existed in the BRIEF text editor and in the XTree file manager, both for MS-DOS.
BRIEF had a tiling-window user interface with optional menus and it came with a default behavior, but it could be customized extremely. For each kind of key press or mouse event you could bind a function to be executed, which replaced the default behavior. For instance, the default behavior for pressing most keys was to invoke a function "self_insert", which inserted in the current text buffer and the current cursor position the character corresponding to the pressed key, but it was easy to change the behavior to anything else, e.g. to do auto-completion or inserting some program template.
The functions bound to events were written in a custom language similar to LISP, so in this respect BRIEF resembled Emacs. A great number of text manipulation functions were provided, so it was easy to describe complex actions in the event handling functions.
This was what I liked most at BRIEF, that by rewriting all the event handling functions it was very easy to convert it in an editor that no longer resembled the default BRIEF editor at all, but which behaved in whatever way you believed that an editor for program sources should behave.
So the text editor provided an extensive library of functions for handling text, text buffers, windows and files and a LISP-like language for gluing all these into a text editor. It also had a default implementation of a text editor, to be able to use it immediately, but that could be replaced partially or totally, when you had more experience and you knew what kind of behavior you want.
I assume that Emacs can be customized in a similar manner with BRIEF, but when I looked at Emacs it required a much greater initial effort than BRIEF, to reach a stage where you are able to modify it.
The default editing mode of BRIEF was very intuitive, at least for someone familiar with the IBM PC keyboard, so you could use it easily out of the box, before learning to customize it. Then, like most MS-DOS programs of that time, it came with excellent documentation, so it was very easy and fast to learn how to rewrite its event handling functions. With Emacs, both learning how to just edit texts with it, and then how to modify it according to what you prefer, is much steeper and more time consuming than it was with BRIEF.
I'm not sure how that's not "recreating everything". What's still shared if you replace the whole state machine (handling file management, etc) and also replace the whole input handling system? A terminal emulator and a copy of Lua?
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 think the idea's good, but I don't think you could modify Neovim to support it while retaining the ecosystem – not without also modifying much of the ecosystem, at which point it may be easier to do a straight port to a different editor, or construct a compatibility layer (essentially reimplementing enough of Neovim in the new editor that the ecosystem still works).
> And we are only talking about editing model (e.g. b being beginning of a word)
nmap can shadow the built-in commands, replacing them with whatever function you want.
> There some cases were Neovim already wants to disconnect itself from vim legacy like allowing to scroll viewport without moving the cursor
I think you mean beyond where the cursor is so it's hidden, but you can jump the screen so the cursor's current position is at the top/middle/bottom without moving the cursor using zt/zz/zb.
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
Hadn't heard of this. So I looked at the docs for Ki.
I see the "Why Ki?", and then it has this:
> Being first-class means that it is not an extra or even sidekick; it is the protagonist.
Eh.
I find it quite off putting.
I guess my expectation is that someone enthusiastic enough to write a text editor with a value proposition of "it's got good tree-sitter-based navigation" would want to discuss why they thing syntactic selection is neat.
Seeing cliche LLMisms doesn't signal the same level of care to me.
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
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
It's not generated by LLM, it was actually my idea, but grammar-corrected by LLM, but you are not wrong either, the docs are really subpar in a lot of ways, and not clearly explaining why is one of them, and of course, the potentially cringey sentences too, someone complained the docs read like a Vogue magazine before lol
I sincerely respect your humility, it's refreshing. I doubt I'll have time to try out Ki any time soon, but it's been bumped up the infinite TODO list :)
Agreed, creating pretty UIs is not my strongest suit if I am completely honest, and could use a help with that. But I have been polishing it up steadily, though sometimes it is an uphill battle with iced-rs.
> The Video could probably show more practical examples than Game of Life
Also agreed. Game of Life demo was supposed to show the interactivity of a view and was easy to implement but at some point I would like to add something more usable as a builtin plugin. For the code example I think it would be better to have that in documentation which is the next on my TODO list
useExec, useFetch and useSql these hooks follow the stale-while-revalidate principle, which handles fetching, refetching and caching. In combination with Raycasts loading indicators, this allows developers to work directly with the remote data without having to worry about loading/error states.
There are ad-hoc hacks in the JDK to avoid allocation for vectors; once we get some Valhalla features, vectors could be represented as plain value objects.
