Very satisfying to debug the difference between lcurses putting the
module table in an upvalue. Since I implicitly call initstr() rather
than define it as a primitive, I don't need to bother with that. I am
awesome. Lua is awesome for giving me that sense.
Not quite working. curses.stdscr() is returning userdata, not a window.
This is true even of the raw array example from the book. So we need to
learn something new here. How does lcurses's Pinitscr return a special
window object? From what I can tell it's just putting the results of
lc_newwin() on the stack. Which is the same as my curses_newwin() here.
First piece of working new vocabulary:
print(curses:cols())
Just pulling in code from lcurses for the most part. But I'm trying to
understand its internals as I gradually add them in, after my more blunt
first approach of packaging up lcurses/ext failed.
Overall plan for Teliva's API:
- start out with a 'curses' library that does what people who are used
to ncurses/lcurses expect.
- over time create a more opinionated library called 'screen' or
'window' or something.
User-defined C data.
I think I have some understanding of the Lua stack now. It's a different
kind of verbose, error-prone syntax than Mu that requires me to play
computer in my head. But I don't fully grok metatables yet. At least not
well enough to grok everything that's going on in lcurses/ext.
lua_State contains these StkId fields (stack, stack_last, base, top)
that expand to a pointer of a struct containing a Lua value and an int.
Unclear how it's used, or how you build a stack out of it.
At this point I'm done making this repo ncurses-ready. Remaining files
that allude to stdin/stdout/stderr:
lauxlib.c - unclear how these primitives should work; may kill them
ldblib.c - unclear what debug experience should be
liolib.c - might kill or simulate these
luac.c - let the compiler continue to be a terminal program
Kartik K. Agaram