I'm not sure glib is the right choice myself, as it has become pretty bloated over the years IMHO. It'd be great if we could rely on something lightweight like the nascent libposix library from gnulib, especially as that might give me the momentum to finish it :)
I'm quite happy to go this route instead, as it's less work for me. I would be happy from the user point of view with being able to install all the dependencies with LuaRocks (which looks as though it's finally getting 5.2 support, removing my one reservation about using it). Adding momentum to libposix would be a bonus: I'd be quite happy to add a GPLed add-on to luaposix and triple-license the whole so that you can either build a plain version under the MIT license, or build a gnulib-enhanced version under the LGPL/GPL (according to how you configure gnulib). This would consist of two bits of support:
1. Optional use of gnulib in the configure apparatus, so you get the gnulib platform-specific fixes to POSIX functions.
2. An extra C module which would inject GNU extension APIs into the posix namespace (seems fair enough rather than adding a new namespace, as the gnulib additions are specifically designed not to clash with POSIX names).
The combination of this would allow the removal in the Lua version of code such as that for copying a file, which are already replaced by gnulib functions in the C version.
I've profiled it, and during a huge paste (20 screen-fulls of text, which took over a minute to complete with profiling on), and it seems we're spending almost all of the time inside draw_line, or more specifically calling term_addch. Which is not surprising at all.
Actually, it's a surprise to me! I thought that it was the new buffer data structure, and that older versions of C Zile were unaffected (certainly, cutting and pasting was much faster at some point in the past). More likely, somehow it wasn't calling term_addch so much, either because it wasn't updating the screen for every character, or because at some point in the even more distant past I seem to recall it had a way to add a string to the screen.
I suppose the solution is that when the input buffer is not empty, Zile should not bother trying to update the screen at all (much like emacs) except perhaps once every 500ms or something?
Absolutely, although I wonder if it's simpler to start by optimising screen update so that each line of the screen is drawn by a single curses addstr call.
I don't know my way around C Zile that well, so it's not obvious where the line between internal buffer updating (presumably inside ncurses API calls?) and screen updating lies... or maybe I'm not being as dumb as I think and those two are still conflated?
I'm a little confused by this: Zile's internal buffers are updated in Zile code; ncurse's (along with actual screen updates) in ncurses code, and term_curses.c is pretty much a thin shim between the two. Zile keeps no representation of the screen internally. Referring to actual functions would help my understanding, if you do want to ask anything else!
I'll spend a little time trying to separate the two in Lua Zile and reduce the number of screen updates when still catching up with typeahead if I can... If I can get that working, then it should be easy for you to port it back to C Zile ;)
I hope that that won't be necessary, and that we'll have a stable version of Lua Zile "soon".