termbox

e don't use. Here's the closest I've been able to get so far: Use libraries by copying them. Let's see why this is good. For starters, it makes you robust to the leftpad failure mode. The library is literally copied into your repository. Who cares how small it is anymore?! It could literally vanish off the face of the rest of the earth, and your code would continue to work. A less obvious benefit is that copying a library puts you on a trajectory of taking responsibility for your dependencies. You don't need to understand all of it on day 1, but as you use it and run into issues you should be gradually understanding its internals better, gradually resolving features that you use, and features that you don't. That then gives you the option to rip out stuff you're sure you'll never need. Or to rip out stuff you may need in future, but is easy to put back (this is analogous to deleting code without fear because version control). I consider an example of exemplary library use to be how I copied the termbox library into Mu (https://github.com/akkartik/mu/commit/5f1285238b), periodically merged commits from upstream (https://github.com/akkartik/mu/commit/9ba313ab7f), gradually cleaned it up to fit better with my project (https://github.com/akkartik/mu/commit/9a31c34f0f), and gradually stripped out code from it that Mu does not require (https://github.com/akkartik/mu/commit/c04baba4f2; https://github.com/akkartik/mu/commit/8e7827dfcf; https://github.com/akkartik/mu/commit/547ec78bf2). In the process I made some wrong turns, deleting features that I later decided I wanted (https://github.com/akkartik/mu/commit/10a3b8cca2) and created bugs for myself (https://github.com/akkartik/mu/commit/3315a7d3bb; https://github.com/akkartik/mu/commit/0c0d1ea5cd). But when it did things I didn't want, I was now empowered to change them (https://github.com/akkartik/mu/commit/ee1a18f050). One of my patches was useful upstream, so I submitted it: https://github.com/nsf/termbox/commit/0730826a07. I would be in no position to submit that patch if I hadn't taken the trouble to understand termbox's internals. And that shows a final benefit of copying and privately forking libraries: it makes you a better citizen of the open source world, because open source depends on eyeballs, and using a library blindly helps nobody except your (extremely short-term) self. Now you may say, this sounds like a lot of work. I can't do it for all the libraries I use. Start small. Pick one dependency that is pretty central to your project, bring it in. See how you like it. As you gain experience come tell me what you discover. (My email is in my profile.) I didn't have all this thought out when I copied termbox into Mu. Benefits gradually became apparent. [1] http://akkartik.name/post/libraries [2] http://akkartik.name/post/libraries2 (Past versions of this comment: http://arclanguage.org/item?id=20213; https://lobste.rs/s/w4auk6/more_shell_less_egg_all_this#c_nv...)

l (e.g. one has to consider how to react to window-size (== terminal rows/cols size) events). You can then write your app similar to a game-loop like the following: while state['should_run']: render(state) update(state) get_input(state) I think such an API is pretty nice to work with - this is different to the React approach, but for writing terminal GUIs like text editors it worked pretty well for me. Many (native) games use a similar approach when rendering menu's and stuff and although there are terrible ones most menus of games look pretty slick.