> I see the merits, although my work on it is moving towards more GUI > integration, not less. I could totally see the rationale behind having > a minimalistic term-only version, though.
Just a wild suggestion that may or may not be very useful: why make it a term version? Since vty isn't supported on Windows, how about stripping vty out of yi-core, too? We could then have yi-core, yi-vty, yi-gtk… and yi-contrib (where all the rest goes.) yi would or would not compile without a display package (doesn't really matter, I think.) In the end, it would probably be more client-server oriented. You have a core "server" that keeps track of the cursor and buffer state(s) and handles requests, and a client. This would also bring a lot of decoupling with it, which might be very difficult to implement efficiently (i.e. ideally, the client shouldn't have to keep the whole buffer state itself just to perform reasonably.) I have no idea how feasible that is with regards to the current yi architecture. But I think implementing an MVC-esque design might be worth it in the long run, given how flexible Yi is supposed to be. ~A.
signature.asc
Description: Digital signature
