Persistance

[mcolyer]

So here's my current use case, I'm currently a big user of tmux and vim. While I've switched over my day to day editing to Atom, I still find myself with many tmux sessions.

The thing I like about tmux is that I use it's sessions feature to group my terminals by the project that I'm working on. I then use windows within each session to split my output. I typically have an editor (until I switched to atom), tig (git client), background processes (such as rails s or tests) and then a scratch terminal for each project.

This is great because at any one time I have about 9 projects "open" and I can easily and quickly context switch between them.

What would be amazing for my workflow is to remove my use of tmux entirely, and have my terminals live inside of each Atom workspace in a persistent manner (maybe even across shell reloads? but that might be impossible). Currently that isn't possible because when I switch away from a terminal it loses all of my state.

So that was pretty long winded, @mutle what do you think of this?

[mutle]

Currently we're running one process per session (plus a shell and login process that get launched by the helper), I don't know if it would be useful to actually handle these sessions in a single process like tmux or screen, but that would allow multiple Atom views to connect to a single process.

Having a terminal view that can switch between different sessions could be useful, but I think the same can be achieved using tabs, or am I missing something here? (I never made the switch from screen to tmux, but I think both should be quite similar in the functionality they provide.)

maybe even across shell reloads? but that might be impossible

As far as I know this is impossible. The best we could do is do like Terminal.app by showing the backlog from the last session.

We could also capture the current env and restore it but that could cause problems, for example when boxen changes some env vars they would not update in the atom shell session. A simpler version that opens the same working directory when reopening a workspace could work.

The only way to actually make shell connections independent of atom restarts would be to have a daemon that manages all connections in a tmux-style fashion that the atom terminals connect to (instead of the forkpty stuff currently used). I don't think that is an acceptable default, but maybe as an option (similar to iTerm providing integration with tmux).

To better evaluate, could you make a quick list of what features you would need to replicate your workflow inside of atom?

[mcolyer]

Upon further thought I think it's best if I continue to use tmux but run my tmux client within the terminal plugin, that should save the hassle of persisting across restarts.

It might be cool to re-run the last command on reload so that I could have it automatically reconnect to my tmux server (as the tab should automatically get recreated on reload). That seems less complicated, what do you think of that? It looks like tmux almost works but that there are just some sequences that are missing for it to work properly.

In the far future maybe there could be a tighter integration along these lines: https://code.google.com/p/iterm2/wiki/TmuxIntegration

[mutle]

Upon further thought I think it's best if I continue to use tmux but run my tmux client within the terminal plugin, that should save the hassle of persisting across restarts.

:+1:

It might be cool to re-run the last command on reload

The only concern I have is if something like rm -rf important-shit or another destructive command was the last one executed this could lead to terrible unexpected results.

It looks like tmux almost works but that there are just some sequences that are missing for it to work properly.

Good point, I haven't really tested much with screen or tmux yet. If you have found some sequences that are unimplemented (should be logged in console, I think) let me know so I can prioritise implementing them.

In the far future maybe there could be a tighter integration along these lines: https://code.google.com/p/iterm2/wiki/TmuxIntegration

:+1:

[mcolyer]

On Thu, Aug 22, 2013 at 5:13 AM, Mutwin Kraus notifications@github.comwrote:

It might be cool to re-run the last command on reload

The only concern I have is if something like rm -rf important-shit or another destructive command was the last one executed this could lead to terrible unexpected results.

Maybe this could be configurable then per project, although I don't think atom has per project configuration values. So maybe this is something best left for the future.

[mcolyer]

I'm going to close this out in favor of other issues that would make tmux support better.