Plans to convert into a library?
sean- opened this issue · comments
It would be excellent if this were turned into a client library that could be embedded in other Go applications. Are there any plans to factor out viewer from the main package?
I am not sure how exactly it should work.
Right now I'm relying on termbox for rendering, need to see if it's possible at all to draw on part of screen, without changing implementation
Can you give an example of use case you have in mind? Should it allow to take part of screen, or just "invoke viewer" from other app?
If this were a library, I'd replace a popen(3) of less(1) and would just call this native from within the app. There are numerous CLI apps that I'm writing or interacting with where this would be useful. Colorized output processing via foo | less -R is tedious compared to something builtin. It'd be nice for native Go apps to just call foo and have it detect if the terminal is native or not. For instance, here's a public CLI app that I've hacked on recently that would benefit from this:
- https://github.com/gwydirsam/go-scrum/blob/master/cmd/scrum/cmd/get.go#L161-L171
- https://github.com/gwydirsam/go-scrum/blob/master/pager/pager.go
?
#51 is submitted as an initial approach to slit as a library. While the viewer itself is not exposed, methods are provided to invoke the viewer on a given filepath, streaming channel, or directly from stdin.
Sweet, I'll take a peak. I ended up rolling something that works well enough. It'd be nice if this were all integrated, however.
Were there any plans to move the main command into github.com/tigrawap/slit/cmd/slit and keep the library at the top-level? That appears to be the common idiom at this point (e.g.
dep).