[muixoozie]

I can't wait to try it. Love that it's keyboard layout agnostic. A lot of other good sounding ideas in the docs. Especially inspiration from Emacs as everything being an editable buffer. There's always some massive tradeoffs between editors though. Guess I'll have to see.

[exidex]

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

[wizzwizz4]

Can you elaborate on how this might look, both from an abstract perspective, and (if you've thought about it) from an API perspective?

[exidex]

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

[adrian_b]

> 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.

[wizzwizz4]

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?

[exidex]

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

[wizzwizz4]

But doesn't the ecosystem around the editor depend on the editor being, at its core, Vim? https://neovim.io/doc/user/lua-guide/#lua-guide-api describes "three different layers": basic examples like https://neovim.io/doc/user/lua/#watch-file call into the Nvim layer.

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).

[Izkata]

> 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.

[SloopJon]

An editor that tries to be layout agnostic is almost certainly going to be a nightmare for people like me who set the layout in the keyboard itself. I downloaded the editor (I'm on Windows at the moment), and tried it with my keyboard set to Dvorak, which was plainly broken. I'm sure there's a way to fix the mapping, but when software thinks it's smarter than you, you end up feeling pretty dumb.

[hou32hou]

Have you used `*` to pick the keyboard layout?