> I'm suggesting that if you want two clearly distinct jobs done, and > they share a lot of similar code, you extract the duplicate code into > a library and then write two applications against that library.
No you weren't. > In this case, we should wind up with st, which consumes PTYs and emulates > a terminal, and we should wind up with your thing, which still sounds > closer to dzen than a term app. > > Loading up application code with disparate functionality isn't any good. I've got no problem with the terminal part of st being modularized and being called from a separate stub that handles how it connects to other processes. The particular method I was thinking of to implement the functionality I want would actually reduce the code complexity of st by removing the code to allocate PTYs and spawn a child process. If you removed the spawning code from st, to implement an xterm like terminal you could have a separate program that allocates a PTY with itself on the controlling end, and spawns st attached to the other end, and then execs itself to a shell which inherits the controlling end of the PTY. That way you've effectively got something that does the same job, but you've removed complexity from st itself, and you've increased flexibility.
