always creating a new anonymous session
dasoju opened this issue · comments
Hi
I am using
mindstream-enter-anonymous-session from an org-mode buffer
everytime i use the command it creates a new anonymous session
I thought it was supposed to use an existing session
following are the sessions i see in anon directory, i tried 5 times and it created 5 new directories
2024-06-20-0c792b136c4874da7b9ef2060e21a13af05ccf4c
2024-06-20-d3cc9a363c1e98afab4118e8ae6eabe9fb87e90f
2024-06-20-dddb260d3c66c5431e841c30691c7ca9b6bc2e3c
2024-06-20-18c1c26ae3d40fdb50127cd338bd0c093cab6234
2024-06-20-d96113261253fb3f30e03abb36aaf7ef8df7a84b
Can someone please help
Hi! Did you mean to close this issue? Were you able to get to the bottom of it? If not, please re-open and let's figure out what might be going on.
For the moment, I'm not able to reproduce this on my end, so any additional information you can provide about your setup and the exact steps you followed, would help.
My first thought is are you sure you're running mindstream-enter-anonymous-session (default binding: C-c , b) and not mindstream-new (default binding: C-c , n)? The latter starts a new session every time whereas the former will visit an existing one if present.
Two possibilities I can think of given the information so far:
- Did you happen to save the session at any point (via
mindstream-save-session)? Once saved, sessions are no longer anonymous. - Did you call enter-anonymous-session while in a non-org buffer? Anonymous sessions are currently unique per major mode. In order to be taken to the Org anonymous session, you need to call enter-anonymous-session while in an Org mode buffer. If you are, say, in a python buffer, you would be taken to the python anonymous session (creating one if not present - you can still visit the original org anonymous session from an org buffer).
If none of these applies, what steps exactly did you take for this to happen?
Another thought (unrelated to the present issue): if you are using a session for three days, that sounds like a session that has become something you want to keep around and revisit, so you probably want to save it by giving it a name (mindstream-save-session / C-c , s).
I am using only one command
mindstream-enter-anonymous-session
i dont use any other commands as i dont see the need for my case
Also, I am always in org buffer
Main reason for using just one command(mindstream-enter-anonymous-session) is, i want mindstream to backup using git and i dont want to worry about saving or loading specific session, pretty much use scratch buffer for all my fleeting thoughts and let git take care of keeping the backups, also want to delete some content to keep scratch buffer more cleaner, but plan to use magit to go back to any old text that i might have deleted
But with this issue, mindstream-enter-anonymous-session sometimes just opens a new session eventhough there is an anonymous session that already exists
It happend just now again, my file list is now as below
Another thought (unrelated to the present issue): if you are using a session for three days, that sounds like a session that has become something you want to keep around and revisit, so you probably want to save it by giving it a name (
mindstream-save-session/C-c , s).
I dont want to do this because, i want to keep a buffer for fleeting thoughts, dont really want to save a session myself, remember the name and then search for it when needed.
okay, i think i might have found the issue
I see that if i kill the buffer (one which anonymous session opened), either because i restarted emacs or saved the file and killed the buffer itself
I see mindstream-enter-anonymous-session opens a new session.
I was wondering if this can be fixed
The use case I am thinking is, i keep brainstorming on a topic for few days at a stretch, i want to comeback to anonymous buffer quickly and perhaps to keep the brainstorming more organized, keep clearing some notes in the anonymous buffer (since its all backed up in git, i can always delete text and still be fine as i can always retrieve). Once i think the brainstorming session is useful i can save the session eventually.
sometimes i have to close emacs or clean up buffers etc or emacs itself crashes, then i lose the anonymous buffer
i think its better to fix this
i looked at the documentation and also the lisp code for following
I see that to determine if anonymous session already exists, its looking for buffer with name
*scratch - <mode>*
If the buffer doesn't exist, it creates a new session. I think, instead of this it shoud look at the anon directory and determine if the session already exists.
Mainly we need to handle case where emacs has crashed or it has been closed or computer has been restarted etc,
Currently mindstream assumes that anonymous buffer is always available unless mindstream-save-session is used, which is not true.
Interesting, yes, that would indeed cause the behavior you're seeing.
Currently, there could be many anonymous sessions in that path that never lead anywhere. The design expects that the next time you open Emacs and enter a session for a particular major mode, which could be a long time after the fact, you are expecting to start tabula rasa and are not interested in seeing what you were last working on (which the design assumes you would have saved if you were).
To accommodate your usecase, we could introduce a defcustom to allow you to indicate that you want only one anonymous session for all time, per major mode, so that it would always be reopened as the "active" anonymous session even across Emacs restarts (until it is saved, at which point it would be removed from the anonymous path).
I'm curious about your thoughts. There are plans to support more than one anonymous session being active at the same time per major mode. This would be useful in cases where, for instance, we may be working in a text session for fleeting thoughts, when something comes up and we need to send an email to someone. We'd like to start on the email in an anonymous session, but the current design forces us to save the existing one first -- which we may not be ready to do. We'd like to start a second, concurrent, anonymous session for this purpose, and would like to have a way to know about all the active Mindstream sessions (including anonymous sessions) so that we can visit them without going through a full buffer search.
With the above proposed defcustom, if you indicate you want just one anonymous session across restarts, then I think that would disallow more than one concurrent anonymous session for you as well -- is that the behavior you'd expect?
Siddharth
were you able to add the defcustom, please let me know
Thank you for your kind words @dasoju , and for your patience regarding this feature 🙂 I'm slowly getting back to things and there's a lot to catch up on!
I've started a PR implementing everything we talked about above. It proved to be a fairly substantial change to incorporate this functionality and also have it be compatible with non-unique anonymous sessions, and do it all in a way that kept the core functionality common while offering different superficial ways of using it. (Re: the usability issue with multiple anonymous sessions, yes, it would be great to provide previews or other conveniences down the line, or find ways to hook into existing previewing functionality provided by tools like Ivy - this PR just includes basic support / groundwork).
Please take a look! If you are using Straight.el (or Elpaca), you can install it from that branch directly and try it out, something like this:
(use-package mindstream
:straight
(mindstream
:type git
:host github
:repo "countvajhula/mindstream"
:branch "persistent-anonymous-session")
:custom
(mindstream-persist t))
Basically, with this config it should just work out of the box the way you envisioned. I'd appreciate any feedback / testing 👌
Otherwise if you are not able to test it, I will go ahead and merge it soon after a trial period to see if any bugs pop up in my usage.
I find that using Straight.el makes my Emacs config much more deterministic and stable.
The PR has been merged, so you should be able to update it via MELPA now. Please let me know if this issue has been addressed to your satisfaction @dasoju 🙂
Fixed by #27 .