Move process management on top of sesman

[vspinu]

Sesman is a generic session manager designed specifically for ESS like use cases. It provides mainly:

• contextual detection of the current session
• user level utilities to associate/dissociate context with sessions
• life cycle managment

There are 3 built-in contexts (buffers, directories and projects) but there are others. Two notable examples:

• org-mode src-block containing a :session parameter must be associated with the corresponding session
• sessions can differ based on the local git branch Question: possible to link based on currently active git branch? vspinu/sesman#15

[jabranham]

Can you give us some examples of advantages/disadvantages of using sesman over our current setup?

[vspinu]

"contextual detection of the current session" is the biggest and the main reason for sesman to exists. You can run 20 sessions in 20 different projects and those will not mix up, with you as a user doing nothing to achieve that. Plus all the process management stuff will go away leading to a simpler code base.

There are no disadvantages AFAIC except that the C-c C-s key will have to be remapped to ess-session-map with things like sesman-link/unlink-session, browser and life-cycle management commands.

[jabranham]

Neat! Is sesman going to be a part of Emacs (e.g. on GNU ELPA)? Since we're trying (and very close) to moving ESS there, it would be nice not to depend on packages outside that system.

[vspinu]

Yes. I just want to have the two use cases (ESS and CIDER) working first, then will push to ELPA.

[lionel-]

You can run 20 sessions in 20 different projects and those will not mix up,

This is huge!