| 7 Nov 2024 |
 smolck | the issue is that this would just re-introduce vtables wouldn't it? hrmmmmm | 21:44:42 |
 bfredl | either vtables, or it would be tempting to make a static lib just with undefined symbols in place of the TUI callbacks.. | 21:45:21 |
| bfredl | as any embedding UI will typically make do with one set of callbacks for the ui client | 21:45:46 |
| smolck | In reply to @bfredl:matrix.org
either vtables, or it would be tempting to make a static lib just with undefined symbols in place of the TUI callbacks.. that sounds like the best choice, no? | 21:46:43 |
| smolck | not sure exactly the details of it, but that feels more performant and avoids the vtable BS | 21:47:15 |
| smolck | which would you suggest I do? | 21:49:18 |
| bfredl | In reply to @shadowwolf_01:matrix.org
which would you suggest I do? the latter is probably easier actually. Can mostly change the generator to use a generic name instead of tui_{event_name} when compiling as a library | 21:52:45 |
| smolck | In reply to @bfredl:matrix.org
the latter is probably easier actually. Can mostly change the generator to use a generic name instead of tui_{event_name} when compiling as a library alrighty, got some files to get me started? probably not gonna work on it much today, but I'll see about chipping away at it as I have time | 21:53:38 |
| smolck | like links to where in the code to go, to clarify | 21:54:27 |
| bfredl | ui_client.c and generators/gen_api_ui_events.lua | 21:54:29 |
| smolck | ty ty | 21:54:36 |
| smolck | ah the ol' generators | 21:54:43 |
| smolck | fuckin' C | 21:54:47 |
 Famiu | In reply to @shadowwolf_01:matrix.org
ah the ol' generators Those are what I've been working with recently for options | 21:56:21 |
| Famiu | Pretty darn cool | 21:56:26 |
| smolck | it's both cool and confusing af at times haha | 21:56:38 |
| smolck | the question is, is it better than using Jinja for metaprogramming? :P | 21:56:57 |
| Famiu | It was confusing at first then it became cool and now I feel like ZyX-at-home | 21:57:00 |
| smolck | "mom I want proc macros" | 21:57:41 |
| smolck | "we have proc macros at home" | 21:57:45 |
| smolck | proc macros at home | 21:57:47 |
| smolck | output:write(
'ui_client_dict2hlattrs(args.items['
.. (j - 1)
.. '].data.dict, '
.. (hlattrs_args_count == 0 and 'true' or 'false')
.. ');\n'
)
| 21:58:01 |
| smolck | In reply to @bfredl:matrix.org
the latter is probably easier actually. Can mostly change the generator to use a generic name instead of tui_{event_name} when compiling as a library the only thing I'm unsure about is how to do the undefined symbols thing, would it just be like, some header file forward declares these functions and either they're defined in the case of neovim itself or you have to define them in your own project to use them? | 22:01:17 |
| smolck | still not sure how that would look . . . | 22:01:21 |
| smolck | is this even like a thing that people do? | 22:01:48 |
| smolck | "hey here's a library, won't compile until you implement these functions . . ." | 22:02:02 |
| bfredl | yea, you would need header declarations for the unimplemented functions | 22:02:23 |
| bfredl | In reply to @shadowwolf_01:matrix.org
"hey here's a library, won't compile until you implement these functions . . ." on a low level, this is how all static libraries work | 22:02:37 |
| bfredl | (static libraries aren't real, they are just a bunch of .o files smashed together with duct tape) | 22:03:11 |
| smolck | interesting | 22:03:21 |
