GNU bug report logs - #75834
[PATCH] Add missing custom :set to savehist-autosave-interval

Previous Next

Full log

Message #23 received at 75834 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75834 <at> debbugs.gnu.org
Subject: Re: bug#75834: [PATCH] Add missing custom :set to
 savehist-autosave-interval
Date: Sat, 1 Feb 2025 09:12:26 -0500

[Message part 1 (text/plain, inline)]

On Sat, Feb 1, 2025 at 8:57 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Sat, 1 Feb 2025 08:35:09 -0500
> > Cc: 75834 <at> debbugs.gnu.org
> >
> > On Sat, Feb 1, 2025 at 8:28 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> >  A disadvantage of idle timers is that they can miss changes.  This
> >  might be more significant for the save-place case, since by the time
> >  Emacs is idle, the file you visited might no longer be visited in any
> >  buffer.
> >
> > Changes to the save-place-alist in memory are not lost unless there is
> an Emacs crash or an abnormal
> > Emacs shutdown. Same for savehist-minibuffer-history-variables which are
> accumulated in memory until
> > persisted.
>
> But saving with a timer _is_ for the case of abnormal shutdown or
> crash, isn't it?  Because otherwise we could just save at exit, right?
>
> So if you are using an idle timer of 5 min, and is Emacs never idle
> for 5 min before it crashes, the data will be lost.
>
> > It's the interval to persist the save-place-alist that we're talking
> about. I think using an idle timer in both
> > saveplace and savehist will not cause a real-world issue. If people are
> truly concerned about persisting they
> > should set a very short timer and idleness occurs frequently, in
> practice.
>
> It's not just any idleness, it's 5 min of idleness.
>

That's right. And could be 10 seconds of idleness if a user wants. Since
idle timers don't rerun until the next idleness, it seems more optimal than
saving these structures every time the timer fires without knowing if
they've changed (not an optimization I'm inclined to put in, but could).

I wind up starting multiple versions of Emacs throughout the day, as I'm
sure many of you do, and having nearly up to date hist/places is helpful
beyond waiting for a long-lived Emacs to exit.

How about we offer the user to decide idle or regular timer? However, if a
timer was already in saveplace, I'd just have used what was there, so if
you feel strongly about a regular timer, I'll change saveplace to a regular
timer as savehist uses. I might be persuaded to change the idle timer I put
in a package I help maintain, too.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.