Better support for sessions on arbitrary buffers

[countvajhula]

Mindstream was originally designed around the idea of a scratch buffer. Since then, we've decoupled sessions from scratch buffers to some extent, so that any buffer can be treated as a mindstream session if we enter mindstream mode.

But in practice, we'd only do this for buffers that we originally created as scratch buffers, and which we iterated on within mindstream. We wouldn't use mindstream for iterating on an existing file in an existing repo because it would be too noisy in terms of commits on that repo.

Yet, it would be helpful if we could.

We should design and implement a UX for this. For instance:

• tag the initial commit of the repo when mindstream mode is entered
• add a feature to "squash" the current session (beginning at the tagged commit) to a single commit, using a provided commit message
• alternatively, it might be even better to instead immediately start a fresh branch when mindstream mode is entered. Then, "squashing the session" would be accomplished by simply squash-merging this branch back into the original branch (which could be noted at the start of the session), and optionally deleting the session branch. Retaining the branch would have the benefit that we could "load" a session by simply switching to that branch. Of course, sessions that aren't merged (and represent work in progress) can always be loaded in this way.

[nobiot]

Hi @countvajhula,

I like the idea behind mindstream and started playing with it after the first issue report #17. Thank you (it's fixed).

Regarding this:

But in practice, we'd only do this for buffers that we originally created as scratch buffers, and which we iterated on within mindstream. We wouldn't use mindstream for iterating on an existing file in an existing repo because it would be too noisy in terms of commits on that repo.

Yet, it would be helpful if we could.

I am experimenting with this workflow below. It works for me. I am using this very repo that I cloned locally.

1. Visit a file in the repo.
2. Create a detached worktree from the main with git worktree add --detach throwaway (or with Magit Z option).
3. Visit a file in the throwaway sub-directory.
4. Call mindstream-begin-session.

After a certain point, I can manually rebase the worktree and squash all the commits automatically created.

I have further developed the idea I suggested in another comment so that I can now easily select a previous session to resume it when I call mindstream-load-session. See the screen shots below. First I choose a session (= the worktree directory named throwaway in this case) and then choose a file in it that I want to work on. I have enabled the history for my sessions, so savehist-mode records them.

As I can use any commmit from the Git repository, I think the workflow may also lead to what you note in #7.

If you like the idea, I can send you a PR or diff patch file so that you can inspect the changes I have done. I realize that this may not be the direction you want for your project, so please take it as only a feedback from a user who just started using mindstream. There is no problem if you don't need to see the code or see it and then decide not to take any of the ideas.

[nobiot]

I have just seen your reply comment after posting this comment here. I will send you a PR so that you can see my idea concretely. Please do not feel obliged to take any part of the code or ideas; if you do, that's also great :)

[countvajhula]

That sounds like a very reasonable workflow, and I've linked to it in the docs!

I know you're looking into the completion stuff right now (thank you!) but since you've brought it up, longer term, it'd be interesting to use git branches for this and to keep it abstracted. It is very interesting but also very much a rabbit hole (as you've guessed, I think) and there may be a lot of features to design/redesign. What do you think about something like this (there's no time constraint on this -- please read at your convenience!):

• begin-session always starts a new branch (even the first time for anonymous sessions)
• the branch names could be similar to how names for anonymous sessions are generated so they are both unique as well as useful (since they mention the date)
• add merge-session which prompts for (1) branch to merge into, (2) squash commit message. It could just delegate to Magit for this if possible, and it leaves the original session branch intact.
• if users want to delete old mindstream branches, they can use standard Git features to delete branches by regex match (probably?), and we don't need to provide any features for this
• we could begin a session anywhere, but most commonly, users don't want to start new branches, so provide a prompt like, "session is already active. start a new branch?" if the current branch is already a mindstream branch (i.e. a session)
• currently, there is a one-to-one mapping between mindstream session and Git repos. But with the ability to have sessions be branches, we can have any number of sessions on the same repo. So what should load-session do? One option is it could include all sessions in any repo based on session-history (but that is finite and not comprehensive.. could that be a problem?). Another is that we have two separate features, load-session and load-local-session. The former could go through 3 levels of prompts, first to select the folder, then the session, and then the file. At each stage, it should use "unique shortcircuiting," where if there is only one candidate, it selects it without needing to prompt. A third option is to only support loading "local" sessions, and leave the higher level project navigation to other tools like Projectile.
• we might need a new notion of "project" to map to the repo, and have "session" map to a branch. This will take some design work

This should work for existing anonymous sessions, loaded sessions, as well as ordinary repos that are not specifically for Mindstream, but I'm sure there are a lot of things that remain to be considered.

Based on your feedback, I can edit the issue description to capture the working design. Once we have something we agree is good, we could figure out how to work on it!

Tagging @greghendershott as well, I think this is essentially the next phase of design for this package and it ties together many other issues, so your input is essential 😄 . Again, there is no time pressure on any of this (and in fact I do want to focus on ensuring the current version is stable and good before exploring this in earnest). Once things start coming together more we could come up with more of a plan, as needed. Thank you!