search

Fanael / persistent-scratch

Preserve the scratch buffer across Emacs sessions
132 stars 14 forks source link

Number of backup files? #8

Closed alphapapa closed 8 years ago

alphapapa commented 8 years ago

Hi,

I'm a bit confused about the backup function. From what I can tell, there is no limit to the number of backups that are saved. I was expecting it to have a limited number, similar to how Emacs saves backup files.

Is this correct? If so, would you consider adding a limit? I would like to keep some backups, but I don't want infinite ones... :)

Thanks for making persistent-scratch! It's a really nice package.

Fanael commented 8 years ago

Is this correct?

Yes. There's absolutely no limit bar ENOSPC.

If so, would you consider adding a limit?

What kind of limit? Number of backup files? Total size of files? A time period? Something else?

At any rate, patches are welcome.

alphapapa commented 8 years ago

Hmm...I think the best limit would be a time period, and files older than that would be deleted. What do you think?

Fanael commented 8 years ago

Implemented in 0.2.4. Examples:

;; keep the newest 10 backups
(setq persistent-scratch-backup-filter
      (persistent-scratch-keep-n-newest-backups 10))
;; keep backups not older than a month
(setq persistent-scratch-backup-filter
      (persistent-scratch-keep-backups-not-older-than
       (days-to-time 30)))
alphapapa commented 8 years ago

That's great, thanks!

alphapapa commented 7 years ago

Hi, it's me again. I confess that after you added this, I forgot to turn it on. D:

Now I was about to do so, because my number of backup files has gotten quite large. But I noticed that, the way this is implemented, I can't use the customize interface to set the filter function.

What do you think about a customizable variable for the number of days of backups to keep, and a function that used that number and the file modification time to return the list of files? I'd be happy to send a PR.

Thanks.

Fanael commented 7 years ago

But I noticed that, the way this is implemented, I can't use the customize interface to set the filter function.

That's not true: (defalias 'foo (persistent-scratch-keep-backups-not-older-than (days-to-time N))) and then set persistent-scratch-backup-filter to foo using customize.

What do you think about a customizable variable for the number of days of backups to keep, and a function that used that number and the file modification time to return the list of files?

NAK, I don't want to prioritize persistent-scratch-keep-backups-not-older-than over persistent-scratch-keep-n-newest-backups and over custom predicates, and because I don't like customize, I'm unwilling to introduce something that serves only to placate customize.

alphapapa commented 7 years ago

Hm, yes, using defalias like that would work, but that's still working outside of customize. :)

Ok, fair enough, it's your project. :) I might make a little fork just for myself in that case. Thanks.

alphapapa commented 7 years ago

I don't want to prioritize persistent-scratch-keep-backups-not-older-than over persistent-scratch-keep-n-newest-backups

One note on this, though: I have been experiencing a bug in which the scratch file gets emptied and I have to restore from a backup. I don't know exactly what causes it, but it usually happens when I have some error in my init file, and I end up restarting Emacs several times while trying to fix the error.

It almost seems as if persistent-scratch is not loading the save file, but then saves the empty scratch buffer when I exit Emacs, and then reloads the new, empty save file the next time Emacs is run--but I don't understand how that could happen, since if persistent-scratch gets loaded at all, it should restore the save file in the first place. Nevertheless, it happens. :(

Anyway, my point is that the keep-n-newest-backups filter could cause data-loss in this situation, if the user restarted Emacs more times than the number is set to, without noticing that the scratch buffer is now empty. This happens to me, as I'm focused on the new, strange initialization error instead of the fact that the scratch buffer is empty. I usually end up restarting Emacs several times, finally fixing the error--and only then do I notice that the scratch buffer is empty, and now I have another problem to fix.

The keep-backups-not-older-than filter would not be vulnerable to this situation, since it's based on time and not number of backups, so the user could restart Emacs as many times as he needed, and the good backup files would still be available as long as it hadn't been so-many days since the scratch buffer was correctly restored.

And so my point is that, it might actually be a good idea to prioritize the time-based filter over the number-based filter, because it's safer.

Fanael commented 7 years ago

I might make a little fork just for myself in that case.

A fork seems a bit heavyweight, you can just define a function and a variable in your init instead.

One note on this, though: I have been experiencing a bug in which the scratch file gets emptied and I have to restore from a backup. I don't know exactly what causes it, but it usually happens when I have some error in my init file, and I end up restarting Emacs several times while trying to fix the error.

It almost seems as if persistent-scratch is not loading the save file, but then saves the empty scratch buffer when I exit Emacs, and then reloads the new, empty save file the next time Emacs is run--but I don't understand how that could happen, since if persistent-scratch gets loaded at all, it should restore the save file in the first place. Nevertheless, it happens. :(

Can you create a new issue? This behavior certainly sounds like a bug.

And so my point is that, it might actually be a good idea to prioritize the time-based filter over the number-based filter, because it's safer.

Sure, but that's "just" a bug. Besides, custom filters don't necessarily suffer from it, and like I said, I don't want to prioritize the time-based filter over them too.