> 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.
Received on Fri Oct 30 2009 - 23:05:12 UTC
This archive was generated by hypermail 2.2.0 : Fri Oct 30 2009 - 23:12:10 UTC