Use as library

[leaanthony]

Firstly, thanks for creating a great project! I'm looking to integrate this into another CLI tool and am wondering how open you are to that. I'm happy to fork and make it happen. Just let me know your thoughts and I'll create a PR.

Thanks.

[mitranim]

This is a good reminder that all tools should be written as a library first, with a tiny CLI-adapter module second. Sooner or later, someone will want to use a given tool as a library.

To make gow usable as a library, some issues need to be resolved. Off the top of my head, here's a non-exhaustive list, in no specific order:

• Incomplete cleanup. Main.Deinit doesn't terminate goroutines for .Stdio, .Sig, and .Watcher, because currently, these are singletons which are terminated when shutting down gow. A library would have to implement proper cleanup because it has no right to assume that each type is only used once.
• Switching the terminal to raw mode and back may require additional coordination to avoid race conditions restoring the terminal to the wrong state. Currently there's only once instance of TermState, but when this is used as a library, there may be more, and they may need to coordinate between each other, or the API should ensure that there's only one instance with a counter for "clients" calling its init/deinit, to avoid redundant terminal state changes. (Worth noting that the current version of gow already has a related issue mentioned in the readme; it needs coordination of terminal state updates between different gow processes running concurrently in the same terminal tab.) This could be resolved by excluding support for raw mode and hotkeys from the library version, only implementing them in the CLI version, but that could also be tricky.
• The current implementation assumes exclusive rights over the standard input of the gow process and always reads from it.
• The current implementation has dependencies. I'm of a firm mind that libraries should only depend on the standard library. Libraries with dependencies create various issues for apps using them. The reason I've been cavalier about using dependencies in gow is because it was CLI only. Unfortunately, this is "wontfix".
• The current implementation has very little synchronization because there's not a lot of concurrent access to shared resources. If each internal type becomes a library type, they can no longer make this assumption, and may need additional synchronization for various methods and behaviors.