Conversation
|
Oh, and it needs to incorporate the "figure out where in the timeline this should go" logic. |
|
This works really nicely, actually. And it doesn't feel that slow here. |
Presumably the rest of the buffer should be frozen while the user builds their transaction, so is it actually necessary to resend the whole buffer every time? Isn't it enough to save a copy at the beginning, and then reuse that? |
I did run into a few issues:
|
|
@cpitclaudel Great point about only needing the file up to the point of insertion. And no, I haven't looked at this code any further since writing it. |
@enderw88 Here's an initial implementation that shows what I mean. It's not quite ready for prime-time for the following reasons:
Error handling is terrible. It just swallows chance errors so as not to disrupt the display.
It's slow, because it copies over the source buffer for literally every key pressed. But this is to take advantage of "prior knowledge" in what gets displayed, so in a way it's necessary.
It feels fragile overall, and I'm not sure my window management represents best practices.
However, it does work very nicely (for small ledger files at least), showing a colorized live display of what will get inserted.