mindstream icon indicating copy to clipboard operation
mindstream copied to clipboard

Avoiding global state

Open countvajhula opened this issue 1 year ago • 6 comments

Initially, Mindstream sessions were versioned buffers. At that stage, it was easy to define a distinct minor mode called mindstream-session-mode which could be activated in these buffers, and then there was no need to have any global state since versioning and sessions were a function of whether this mode was active in the local buffer or not.

But now, Mindstream sessions are associated with full git repos. We need to iterate the session every time there is a change in any file in the repo (which is not gitignored). For this purpose, we added a global registry of sessions mindstream-active-sessions that track which paths are currently mindstream sessions, and mindstream-session-mode was removed.

But it would be ideal to either avoid this kind of global state, or at least work out a scheme to manage it in a clean way, since naively, it can lead to bugs and unexpected behavior.

For instance:

  • If after a mindstream session is started the repo folder is moved (either within Emacs or in the shell) to a different path, it would no longer be recognized as an active session in Mindstream (since the path in the session registry is still the original one) and would no longer iterate the session on changes.
  • If mindstream-end-session is not explicitly called but all buffers in a repo path are closed, that path is still considered an active session unless we remove it from the registry by adding a function to kill-buffer-hook. Of course, it may make sense to do this, for now.

countvajhula avatar May 07 '24 21:05 countvajhula

(Comment from #21 ) On option is to make sessions live in dedicated Git branches (so that mindstream-begin-session will call git checkout -b mindstream-<unique-id+timestamp>). Then, whether a session is "active" could be determined by just checking whether the current Git branch begins with "mindstream" and we wouldn't need global state in the form of mindstream-active-sessions.

countvajhula avatar May 09 '24 19:05 countvajhula

@countvajhula, Leaving my comment here rather than the comment in code #21. I understand reasons for avoiding a global state in the form of mindstream-active-session. A naive question I have from the current workflow is this: how does mindstream know which Git repo to look for mindstream branch?

I now end any session anywhere outside of the "current session". This is possible because of mindstream-active-sessions. I suspect this will change and you will be only able to end a "current session". I have a feeling that I may want to know which buffers are mindstream sessions currently active... Perhaps this can be achieved by adding some string (e.g. "mindstream - " prefix) to the buffer name... Just a quick stream of thought.

nobiot avatar May 10 '24 08:05 nobiot

Yes, I think currently it's useful to be able to end sessions from anywhere since such sessions start accumulating and we might feel the need to tidy up. But in the proposed design where sessions are branches, we may no longer need end-session functionality since we could end a session simply by switching to a branch of our choosing, like main. Also, unlike the current UX where a session being active leads to noisy commits on a regular branch, in the new design, all such commits would be safe as they would happen on a mindstream branch.

Re: knowing which open buffers are in mindstream sessions, I can't immediately think of a reason we would need that, but one way could be to map all open buffers to their filenames -> repos -> checked out branch, and see if the branch starts with mindstream-.

countvajhula avatar May 11 '24 09:05 countvajhula

Re: knowing which open buffers are in mindstream sessions, I can't immediately think of a reason we would need that, but one way could be to map all open buffers to their filenames -> repos -> checked out branch, and see if the branch starts with mindstream-.

Slightly different, but a real use case that happened to me now.

  1. I am trying to compose a reply to a comment on GitHub. It has become rather long and complex, so instead of using the web interface, I start an anonymous session in mindstream, paste the draft so far, continue to write.

  2. I want to hold it off for now because I want to start cooking lunch. So I save the session. I don't close my laptop or Emacs. In Emacs, my anon session is still active and the anon-session buffer is open. I don't close it and go to the kitchen.

  3. I come back. The anon-session buffer is open in front of me in Emacs, but I know I have saved it before the lunch. I try to load the session to resume writing the reply. The load-session completion does not show the saved session. I am lost and need to find the saved session...


Now this issue is slightly different from finding all the open session buffers, and we can add the saved history to the session-history variable, so that it will appear in the minibuffer completion.

I have multiple anon-session buffers now. If I want to kill these buffers to de-clutter my Emacs, currently I look for scratch.txt with the very long md5 buffer name and kill it (and end the session).

As a user, I think the questions are:

  • "Where are my [saved] sessions?" <<< How does this work when you have a git branch for a session? I can have my git repo anywhere under my ~/.
  • "How do I kill all the anon sessions and end them?"

nobiot avatar May 11 '24 11:05 nobiot

Hmm. I am looking at the code and the way mindstream behaves more carefully. It's not exactly how I describe it above. The current anon session ends when I save it. It seems I need to play with mindstream-save-session-path. I will keep the little sketch above for now (even though the detail of how mindstream works is incorrect -- my human memory is not good).

nobiot avatar May 11 '24 12:05 nobiot

The new draft design includes the ability to "open" any active session (and a few different ways to narrow which sessions you are interested in), as you suggested.

countvajhula avatar May 27 '24 23:05 countvajhula