| 7 Nov 2024 |
 Famiu | * | 15:28:43 |
 smolck | so I mentioned this in the off topic chat but I'm thinking I'd like to start working on making libnvim actually ergonomic to use in the ways I can, I'd like to use it for my GUI | 17:30:01 |
| smolck | currently I think the biggest thing is making it where you can just add it as a CMake subdirectory, instead of having to manually run make libnvim to get it to work | 17:30:26 |
| smolck | don't really have anything actionable atm to get started on, but just figured I'd mention it here | 17:30:53 |
| smolck | * don't really have anything actionable atm to get started on right this moment, but just figured I'd mention it here | 17:31:00 |
| Famiu | In reply to @shadowwolf_01:matrix.org
so I mentioned this in the off topic chat but I'm thinking I'd like to start working on making libnvim actually ergonomic to use in the ways I can, I'd like to use it for my GUI Best of luck! That would be huge | 20:35:01 |
| Famiu | Libnvim would also be very helpful for when we want to implement something like multicursors | 20:35:33 |
| smolck | In reply to @moonglade:matrix.org
Libnvim would also be very helpful for when we want to implement something like multicursors how so? | 20:39:17 |
| Famiu | In reply to @shadowwolf_01:matrix.org
how so? I forgot exactly how but it should make implementing stuff like doing motions on multiple cursors easier or smth iirc | 20:42:37 |
| smolck | if anybody can point me in the right direction as to how the fuck to hook into the ui stuff in libnvim that'd be great because uh | 21:28:41 |
| smolck | there's a lot of new shit since I last looked | 21:28:47 |
 bfredl | well, what it is that you want to do, and which difficult (or too expensive) from the RPC UI interface? | 21:30:19 |
| smolck | In reply to @bfredl:matrix.org
well, what it is that you want to do, and which difficult (or too expensive) from the RPC UI interface? I basically want to define my own implementation for a UI a la ui_compositor or ui_client or just ui.c, from skimming the code | 21:32:06 |
| smolck | I'd like to avoid RPC because there's a lot of indirection there and I'd like to just interact with the C side of things directly | 21:32:21 |
| smolck | that way I could add my own stuff to the Lua environment, for example | 21:32:46 |
| smolck | and just overall I'd presume it'd be way faster and simpler, since no msgpack bs | 21:32:56 |
| bfredl | well, the old VTables have gone buy buy. you might want to hack into the generated ui_call_ wrappers if you wanna access events | 21:33:30 |
| smolck | In reply to @shadowwolf_01:matrix.org
I basically want to define my own implementation for a UI a la ui_compositor or ui_client or just ui.c, from skimming the code currently, it seems this would take some work to make possible a way to inject my own UI, basically use neovim as a library, but I'm happy to work on a PR for that sort of thing if that's what's necessary, it'd be awesome to make libnvim more of a first-class citizen | 21:33:41 |
| smolck | In reply to @bfredl:matrix.org
well, the old VTables have gone buy buy. you might want to hack into the generated ui_call_ wrappers if you wanna access events based on my understanding, it's currently hardcoded to either call ui_compositor.c's stuff or ui_client stuff etc. depending on what UI is in use (TUI vs. an rpc one etc.), if I understand correctly? | 21:34:25 |
| bfredl | * well, the old VTables have gone bye bye. you might want to hack into the generated ui_call_ wrappers if you wanna access events | 21:34:36 |
| bfredl | TUI is now an RPC UI like the rest | 21:34:55 |
| smolck | I remember you wanted to do that | 21:35:06 |
| bfredl | compositor is controlled by the ext_multigrid RPC option | 21:35:07 |
| smolck | that should make it relatively simple to do what I want then, right? just model my UI code after the TUI and somehow call the neovim internal stuff from libnvim to get the events and everything rolling, yeah? | 21:35:33 |
| smolck | my question is how much code do I need to just duplicate from main.c into my GUI, and how much should be either upstreamed to neovim or already exists I can just call into | 21:35:56 |
| bfredl | In reply to @shadowwolf_01:matrix.org
my question is how much code do I need to just duplicate from main.c into my GUI, and how much should be either upstreamed to neovim or already exists I can just call into you can look for stuff named with ui_client_ in main.c where the magic happens | 21:37:35 |
| smolck | In reply to @bfredl:matrix.org
you can look for stuff named with ui_client_ in main.c where the magic happens gotchya | 21:38:38 |
| smolck | so here's my thought right now, tell me what you think | 21:39:11 |
| smolck | it seems that honestly having just a straight-up lib.c/lib.h is the way to go? correct me if I'm wrong, it just seems like it'd clean up the distinction between the actual main code and library stuff. then:
- have either a main function or similar that allows you to pass in the functions that get called for your own UI client. not sure if this should be a struct of function pointers or just a bunch of
ui_setup_blah_blah_event_handler(...) functions?
- potentially return a reference to the lua environment and/or other stuff you'd want to access in a GUI application using
libnvim
- any other setup calls that may need to run
- figure out the threaded side of things/where the UI falls in the event loop or if it should run under a neovim thread or the neovim library run under a separate thread and the UI be the main one?
| 21:43:06 |
| smolck | seems like a good basic idea for how to get things working here? I presume a lot of this could be abstracted in a way that main.c ends up just calling the stuff from lib.c/lib.h as well, basically transitioning such that the code duplication would be unnecessary because the neovim binary itself would use libnvim in a sense | 21:44:14 |
