I've found that the specialized tools philosophy to be effective when building a, well a toolkit. Toolkits, if done well, are extensible and interoperable in wa

I've found that the specialized tools philosophy to be effective when building a, well a toolkit. Toolkits, if done well, are extensible and interoperable in ways that no 'integrated' system can be. However, There is a certain class of problem that doesn't really lend itself to the toolkit approach. This is the interface problem. Vim is an awesome text editor, it is streamlined in a way most editors could only dream of. It's a very good text editor. Python is a very good language. One of it's nice features is that it comes with a REPL, so I can program in it interactively. Using a third program Screen, I run both side-by-side and pipe content between them. This is the toolkit at work, and it works very well. However, there is a slight problem here. Each of these programs has a different interface design. Each has a separate key-binding scheme and different schemes collide. You have to learn three different interfaces and learn them well, to do this effectively. It would be nice if there was a program, similar to screen, that would stand between you and the editor and interpretor and allow you rebind and customize your keys and view ports so that they don't collide and are consistent. This program is emacs. It is the universal interface, a more flexible bash than bash, and people stay in it all day, not because they don't use toolkits, but because they prefer to use it to interface with toolkits rather than bash or some ill-conceived X monstrosity. Emacs doesn't replace cvs/git, ls, grep, awk, gdb, gcc, python, rbi, cron... It mostly just provides a very powerful scriptable interface to all of them.