Here are the specs for a great weekend project that I don’t have time for.<\/p>\n
I edit and unit test on a Windows machine. I system test and deploy my server application on a remote (and hence low-responsiveness) Linux box.<\/p>\n
I use Windows, DOS*<\/sup> and Linux (over SSH with PuTTY).<\/p>\n Unfortunately, Windows, DOS and PuTTY offer very different user interfaces. (Okay, arguably, they are very similar user interfaces compared to, say, a mobile phone or a fork, but different enough to cause me problems.)<\/p>\n I am constantly tripping up because of the teensy little differences.<\/p>\n After making a selection by dragging with my mouse, I can copy it to the clipboard by hitting CTRL-C (Windows), hitting Enter (DOS) or doing nothing (PuTTY).<\/p>\n Looking at it the other way, CTRL-V will either paste the clipboard at the current location (Windows), insert ^V (DOS) or try to page down (Linux – in emacs, or on the bash line, which I use in emacs mode).<\/p>\n Similarly, CTRL-Z with either undo (Windows), enter the EOF flag (DOS) or put the job in the background (Linux).<\/p>\n My productivity suffers because my muscle-memory is gone, and it even makes non-development tasks slower: I keep typing CTRL-K when writing email (Kill the rest of the line, in Emacs mode) rather than Shift-End Del (Select to the end of the line, and delete, in Windows.)<\/p>\n A windows application consisting of two, vertically-tiled panes, and a row of buttons.<\/p>\n The top, larger, pane is a terminal window that shows the interaction with the shell. While this pane has focus, all of the keystrokes are relayed directly to the shell, and their results are sent back, just like a PuTTY window.<\/p>\n The shell would either be an SSH session or a DOS session, so working with each of them is identical from a low-level look-and-feel perspective.<\/p>\n The lower, shorter pane is an edit box that supports all of the standard Windows shortcuts and navigation. When a complete line is entered, the command is transmitted to the shell (appearing again in the top window.)<\/p>\n The main use-case is to enter all commands in the lower window, and watch the output in the upper one. The upper pane would only have focus when the shell enters an interactive mode (such as running an editor or other application), but for most simple console tasks, the bottom pane would be sufficient.<\/p>\n Ideally, the application could tell when it had left the confines of the bash\/DOS shell, and automatically change the focus.<\/p>\n Underneath (?) the bottom pane, a row of buttons would allow access to the commands that are hidden by Windows shortcuts – a “background” button would send CTRL-Z, a “cancel” button would send CTRL-C, etc. (There wouldn’t be a need to send Ctrl-K, as the Kill command has a Windows shortcut equivalent.<\/p>\n Some features of the bash command-line might be difficult to emulate (e.g. tab-completion). It would be possible to transmit the command line on the fly, rather than batched, to support such operations, but this may be slow and more difficult to implement.<\/p>\nProposed Solution<\/h3>\n