Support ability to have an interactive shell on a remote system, rather than one-off commands. My workflow on a remote server is to have vim open with multiple splits that include terminals to run commands like git and hg including log output, committing files, adding descriptions that open up an instance of vim to do so, and more.
Description
For the full vim experience, dropping into a shell would be very handy using the CLI. It's okay if a new instance of over-there is spawned to support this just like we'd do for tailing a running process.
Investigation work is needed to figure out how best to communicate frames (like mosh?) and engage with a tty. Or, could start with a simpler shell engagement that just communicates plain text?
Challenges
Shell output isn't too hard, but running commands that start leveraging curses or other TUI libraries is going to be hard unless we provide an experience similar to mosh, which is way beyond the MVP scope of this project.
Even if we stick to shell output, which could work okay enough with git log and hg sl, it won't help when we need to invoke our editor for a commit message. Other than the earlier "mosh-like" solution, another would be to wrap specific commands such that we feed input to them via stdin or cli args. E.g. git commit -m '<INSERT MESSAGE>' or hg commit -l <FILE WITH MESSAGE>. This is annoying as it involves handling specific commands and exposing them directly in vim (or other editors) versus it "just working" with this cli.
Even if we handled specific commands as described in 2, this wouldn't help with interactivity like hg histedit or hg commit --interactive`, which go back to needing a curses ui.
If we somehow supported a mosh-like experience as in 1, we'd be back to needing dotfiles for editors that are on the remote server. The only other option I can think of would be to have over-there support some sort of callback trigger to a specific client where you would alias EDITOR=over-there bridge <SERVER ADDRESS> <CLIENT ADDRESS>
Goal
Support ability to have an interactive shell on a remote system, rather than one-off commands. My workflow on a remote server is to have vim open with multiple splits that include terminals to run commands like git and hg including log output, committing files, adding descriptions that open up an instance of vim to do so, and more.
Description
For the full vim experience, dropping into a shell would be very handy using the CLI. It's okay if a new instance of over-there is spawned to support this just like we'd do for tailing a running process.
Investigation work is needed to figure out how best to communicate frames (like mosh?) and engage with a tty. Or, could start with a simpler shell engagement that just communicates plain text?
Challenges
Shell output isn't too hard, but running commands that start leveraging curses or other TUI libraries is going to be hard unless we provide an experience similar to mosh, which is way beyond the MVP scope of this project.
Even if we stick to shell output, which could work okay enough with
git logandhg sl, it won't help when we need to invoke our editor for a commit message. Other than the earlier "mosh-like" solution, another would be to wrap specific commands such that we feed input to them via stdin or cli args. E.g.git commit -m '<INSERT MESSAGE>'orhg commit -l <FILE WITH MESSAGE>. This is annoying as it involves handling specific commands and exposing them directly in vim (or other editors) versus it "just working" with this cli.Even if we handled specific commands as described in 2, this wouldn't help with interactivity like
hg histeditor hg commit --interactive`, which go back to needing a curses ui.If we somehow supported a mosh-like experience as in 1, we'd be back to needing dotfiles for editors that are on the remote server. The only other option I can think of would be to have over-there support some sort of callback trigger to a specific client where you would alias
EDITOR=over-there bridge <SERVER ADDRESS> <CLIENT ADDRESS>