Lost all my activities about activities.el

[josephmturner]

1. Using with-emacs.sh, install activities (and its dependencies).

   2. Define a test activity.

   3. Exit Emacs.

   4. Delete its elpa/ directory.

   5. Restart Emacs.

   6. Install activities again (including persist).

   7. M-x activities-resume RET.

I followed similar steps with emacs --init-directory=DIR instead of with-emacs.sh, and I also wasn't able to reproduce the issue.

Without an exact list of the steps you followed, it would be hard to know what happened and why.

It can be difficult to figure out what happened post-mortem, but if you are able to reproduce the issue again, please send me the steps.

I don't know what would happen on the persist side if the user changed the location of the file after the variable has a value; if the code isn't written to handle the location changing after the variable's been defined and its value loaded

Perhaps in the setter of the proposed activities-persist-location defcustom, we could call (activities--persist t) to ensure that the data is backed up in the new location. (Thanks for bringing this up! I'll do this in hyperdrive.el.)

We could also delete the old persist file which stores activities-activities, but I'd rather just tell the user to manually delete the old version if they don't want duplicate data.

[alphapapa]

Hi Julian,

Sorry to hear about that. I only ever had issues with losing the value of activities-activities when I was doing things during development that users shouldn't do, like calling unload-feature and then reloading a new version of the package; and that seemed to be some kind of weird interaction with the persist library. Since I stopped doing that, I've never lost my activities list.

Without an exact list of the steps you followed, it would be hard to know what happened and why. Since persist is not a built-in package, and since I don't know whether or in what order you might have restarted Emacs during those processes, it's hard to say what the various libraries might have done being initialized with various state.

FWIW, I tested the following:

1. Using with-emacs.sh, install activities (and its dependencies).
2. Define a test activity.
3. Exit Emacs.
4. Delete its elpa/ directory.
5. Restart Emacs.
6. Install activities again (including persist).
7. M-x activities-resume RET.

The result was that the persist/activities-activities file was still present and its value was still loaded.

The bookmark support is optional, and they only store a reference to an activity's name. An activity data structure can be quite large, and in the past there have been occasional issues with encoding, so it didn't seem like a good idea to store them directly in the bookmarks file (wouldn't want to break that file).

In the meantime, we can certainly mention the location of the data file in the documentation if you think that would be helpful. (I doubt most users would notice, but you're not most users.)

We could also allow the user to set the location of the data file, as persist seems to support that. That could make it easier to back it up, but if this happened due to a bug in Activities, Persist, or some kind of interaction, I don't think moving the location of the file would fix it.

I'll loop in the Persist maintainer: @josephmturner I don't know if there's anything that can be done about this, but what do you think?

[julian-hoch]

Thanks for the quick response! Fortunately, I found a backup of the file, so I am saved!
I understand that the fault does not lie with activities.el (which is a great package btw., so thank you very much for it).
My recommendation would be to simply mention the file that is used to store the activities in the main README, and to recommend to back it up.
Personally, I don't see a benefit in making the file itself configurable.

[alphapapa]

It's hard to say where the fault lies, if anywhere, really.

Anyway, I'm not necessarily opposed to mentioning the file in the docs, but OTOH there are numerous Emacs packages, some built-in, that store their data somewhere in the emacs.d directory (in fact, that seems to be the standard, even though I'd personally prefer to keep only configuration files there rather than data files--though the line can sometimes be blurry), so it seems like one should generally keep that directory backed up. So I'm not sure that it's necessary to mention this one specific file. (I don't mean to be argumentative, just in favor of simplicity; i.e. if every Emacs library mentioned the location of all of its data files, all of them being under .emacs.d anyway, it would seem redundant; better to just say, "Back up your emacs.d directory if you care about anything you do in Emacs.")

That's why I'm wondering if it might be more useful to allow the user to specify that the file should be stored elsewhere, e.g. in a place where they already are backing up such files (although I don't know what would happen on the persist side if the user changed the location of the file after the variable has a value; if the code isn't written to handle the location changing after the variable's been defined and its value loaded...maybe Joseph can shine some light on that issue).