Thinking about sessions
Updated: Oct 31
A number of ideas floating around in my head are coming together around the idea of adding sessions to marcel. Here are the pieces:
Similar to bash, there is one file that accumulates the history of executed commands. When a bash session terminates, it appends the commands executed to the history file. Marcel does something similar, but has a bug: If there are two concurrent sessions, then both write their changes to the history file on exit. But the appends from the first session are overwritten by the second session exiting.
There is one startup script, startup.py. I tend to add and remove functions to it depending on what I'm working on. I might want colorization, prompts, cluster, and database definitions to change from one project to another. But with one startup script, it has to represent the union of what I do across all my projects.
It would be nice if environment variables could persist. Again, this would be nice on a per-project basis.
All this points to the idea of a session: A session is the state of marcel as I execute commands. It includes a command history, the accumulation of commands in all sessions (ignoring the bug mentioned above). The initial state is contributed to by the startup script, and produces the same state each time that a marcel process (session) starts. Any further alterations to the environment -- assigning to variables, updating variables, deleting variables -- take place within a session and are then lost when the session ends.
We could expand on this idea by explicitly recognizing that a session has a history and an environment, and that a session should be able to be used across multiple processes. In order to do this, sessions need to be named. When a marcel process exits, the history and environment are stored under that name, and a future marcel process can then use that name to pick up where the previous process left off. To keep the idea and implementation simple, sessions should be limited to one process at a time. If one process is using a session, then another cannot until the first process ends.
There should probably be anonymous sessions. I don't always want to do something whose state and history needs to persist. We could persist such sessions, and generate names (e.g. based on a starting timestamp). Or we could simply not persist anonymous sessions, obtaining current behavior.
Does this idea make sense to you? I'm interested in reactions to this idea. (Send email using the link at the top of this page.)
By the way: "Session" is the wrong word. I think the usual understanding of a session is limited to a continuous block of time, and a single top-level process. What I have in mind would span processes.