@Breja Can you probably help me to get the right direction with this?

https://github.com/hoschi/veonim/pull/1/files#diff-3f44925f3a8f492920e1b138dc5aaeb4R322
Doesn't seem to do anything, but all steps (see logs) are executed. I don't see what I'm missing 😞

Also I can't see a nvim error in the logs or where in code I could debug this. I set the grid ID for testing to 666 😈 which should throw a nvim error, because the grid is is unknown.

Got it! After adding error logging the problem nvim had was that the API instance was not attached. I must admit I didn't get why it works when using the master API instead, because there is only one nvim instance anyways ... but it works.

Glad you were able to figure it out. I admit I am curious how you plan to integrate Yode with multigrid. I never tried nvim_ui_try_resize_grid so I'm not sure what happens if the grid can be resized without affecting other grid sizes, and if the resized grid can be made smaller or bigger than the total UI area. I assumed ext_windows was necessary for that.

As for the master vs instance APIs:

master-control.ts runs on the main UI thread and talks to nvim via stdout/stdin. master-control mainly handles UI events (out: redraw, in: nvim_input). For any non-UI nvim events (like buffer events and manipulating buffer text) instance-api.ts and workers/instance.ts are used. workers/instance.ts runs in a Web Worker (another thread) and talks to nvim via unix domain sockets/windows named pipes using the --listen nvim argument.

The reason for this awkward duality of two connections to nvim has to do with performance. Because msgpack is insanely slow in v8 compared to JSON, I didn't want to parse possibly heavy buffer text events (especially on large files) on the main UI thread, as that would cause frames to be dropped and cause the UI to lag.

As to why UI events have issues in the instance connection via --listen unix sockets/windows named pipes, I think it's because nvim expects that UI clients will connect via stdout. I did some experiments to draw UIs from --listen pipe connections and had problems. After digging a bit in the nvim source code I found multiple references for nvim specifically looking to stdout/stdin pipe for UI related events.

Also the instance connection never calls nvim_ui_attach so I'm not sure what happens if veonim sends events like nvim_ui_try_resize without first attaching - I guess it doesn't work.

I'm also curious if all works out 😅 At first I just want some beta-ish state to get a better feeling for the workflows Yode offers when using it on a daily basis. I thought a lot about it, but my imagination has its boundaries 😄

I tried to implement Yode in Oni (onivim/oni#362 and onivim/oni#894), but drifted into other ideas like a "read-only version split" aka cockpit, master/slave tabs and such:
onivim/oni@master...hoschi:feature/yode-epp-starter

Also I run into problems I found no easy fix for, e.g. focus problem after startup, broken ligatures after second neovim instance created and the major effort it would be to sync all the nvim instances and prevent certain neovim actions. Oni1 is harder and harder to maintain and Oni2 is not really far yet, but still excited what they come up with! ReasonML is something I look forward to use, but had no time to get into it.

So I searched new Neovim UIs every now and then and found veonim. I think for a good first try with own commands to create new windows or split existing editors it can work. With the current state of the branch the "windows smaller than main grid" case works already. After 30 lines of text the scrolling of nvim kicks in, even the veonim window is bigger. When the windows get bigger as the main grid, as far as I understood it, the main grid needs to be resized manually so nvim_ui_try_resize_grid call doesn't prevents the resize by itself.

For a correct implementation of a new window manager/logic than the default one, you are right, ext_windows is needed. Then the builtin split/vsplit/... commands (e.g. issued by nvim plugin like Magit) can be handled in a way which make as much sense it is possible in the new window paradigm. But that's so far in the future, I'm not worried about it now 😁 I also have my doubts whether the grid system of Yode protoype are the best way. Global scrollbar scrolling every column seems strange. But I have no better idea at the moment and bigger problems (how to implement function buffers which are still linked to their file for e.g. save changes) 😅

Thanks a lot 💯 for the explanation about the instances, I totally overlooked all that connection stuff when scanning through the code!

Multigrid alone is really not enough. Even when I resize a window, the position of the other windows doesn't change and there is a gap.

I currently try how far ext_windows support would help and how mature it is.