On Sat, Aug 05, 2023 at 20:46:58 +0000, Charlotte Koch wrote: > I've been (slowly) working on a Lua binding for NetBSD curses, with the > intention of adding it to src alongside our other Lua libs (sqlite, > gpio, etc.) > > https://github.com/dressupgeekout/netbsd-lua-curses > > I finally have a bunch of free time and I want to get back to work on > it. My question is: how much of the API surface needs to be captured in > order for it to make sense as part of the base system? > > My gut feeling is "every user-facing function in curses(3) needs to have > an equivalent function in Lua" -- but maybe there's an optimal subset of > the API that would be sufficient. Like, maybe some bits of Curses are > "higher priority" than others?
Nice. What is prior art in this area? I know of https://github.com/lcurses/lcurses though I never used it myself and don't know its status. If it already has adoption in the lua community, it makes sense to use it and make sure it can be compiled against our curses. Though that may be less fun that writing your own from scratch :) It would be nice to be able to use the same lua binding with both our curses and ncurses. I have a simple screen grabber based on a rumpified wsvt25 that I wrote to test and debug the kernel terminal emulator(*) and it might be tempting to co-opt it as both wsvt25 *and* curses test bed (I know, Brett doesn't like the screen grab approach, but I think it has its place :). Being able to run the same test with ncurses and our curses and compare results will be handy. Thanks! *) https://hg.sr.ht/~nbuwe/wsemul -uwe
