[Custom Buffer][1.7.4] Edit won't render text

I've been working on this buffer system for my OS so that I can have a multitasked system. I didn't want to use the Window API due to its inefficiency (i.e. refreshing the whole vertical way for 1 term.write) and I can't use something already made due to a lack of the ability to tell buffers not to render to certain parts of the screen while they're active.
Anyway, I'm getting a weird glitch with my buffer system: Edit doesn't render text. The screen is blank except the for the control menu thingy. You can type and click on stuff to move your pointer, but there is no text. I'm completely lost as to why this is happening, I've tried putting a sleep in write to see if it was rendering then getting overlapped, but nothing. I don't know what other function could be causing it.

The buffer is dependant on Game-Engine for console logs, and is only distributed through my OS. The easiest way to get it is to run:

pastebin run 6JU1nY50 5 update
and install my entire OS. (you can do "sudo rm startup", reboot, and do "rm *" to get rid of it)
Test code:
9XFP8QEK
Just run:
oldEdit <filename>
to see the problem
(no, it's not a different edit program, I just have replaced the default edit in the OS and moved CC's edit to oldEdit)
You should also note the OS will give a warning message and then crash if you use a version under 1.7.4

This function is missing something important (the function above it has it).

This function is missing just about everything.

term.getTextColour, term.getBackgroundColour, and their American variants, are missing entirely.

Thanks, I was able to fix it, but it's still a little whacky. I've got it to a point where I can figure out how to solve it entirely.
blit() isn't used by edit, but it;s certainly something I need to get around to implementing. Really, it'd just be a special term.write, the way my buffer works there's no further optimization to be done. Unlike the window API, it makes the fewest writes possible by simply calling the functions being called on the actual term rather than refreshing the line

Ah, I was going to mention it before, but forgot - I've got a memory lurking somewhere that tells me that when you alter a line, the whole thing ends up being re-rendered anyway by CC's backend code - which means that always re-writing entire lines may be faster than attempting to gather sub-strings.

Dunno if that's still true, or even if it was ever true, but you might consider performing some tests on the matter.

I seem to recall that a line is the smallest unit of screen space that ComputerCraft will transmit over the network, so in versions with term.blit, blit the whole line at once. In all other versions, update changed lines with as few writes as possible.

For best network transmission speeds, anyway.