bug#30943: save-hist creates massive cache file

[Chris Findeisen <cfindeisen@google.com>]

[-- Attachment #1: Type: text/plain, Size: 3864 bytes --]

Hey Eli,

Correct, the issue is that the variable is growing from session to session
without limitation.

For instance, some of the culprits from my particular configuration:
grep -E -b -o '^\(setq [^ ]+' ~/.emacs.d/.cache/savehist
....
51869:(setq evil-jumps-history
53265:(setq mark-ring
53287:(setq search-ring
53311:(setq regexp-search-ring
53579:(setq extended-command-history

I've also seen online this issue crop up for others:
https://emacs.stackexchange.com/questions/12086/abnormally-large-savehist-file

Save-hist doesn't truncate any variables except the ones it knows
> about, because it cannot be sure that truncating some list might leave
> the variable with an invalid value.  For variables like
> minibuffer-history, it knows that truncating the history will produce
> a history that is still valid, but how can it do the same with other

variables?

For example, it could be that some other variable needs to
> be truncated from the other end of the list, otherwise the value will
> be useless.


Hmm, I understand the dilemma about not knowing the format, however there
ought to be an alternative way of adding variables that we can "inform"
save-hist about. Whether that's demanding/documenting a valid format, "Hey
if you add this variable to be tracked by save-hist, it must be formatted
like so" or providing a secondary argument that takes a function specifying
custom handling, I'm not sure.

I think it makes sense to provide some method of honoring the
history-length variable. If the list is never culled, any emacs session
will just grow over time. That is almost never desired(at least for me),
and I would see no point to have additional-variables to be track (I would
have to worry about my buffer silently slowing me down).

Let me know if I'm missing something, or if you have alternate ideas.
Thanks!

Regards,
Chris Findeisen

On Mon, Mar 26, 2018 at 7:59 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Chris Findeisen <cfindeisen@google.com>
> > Date: Sun, 25 Mar 2018 19:11:21 +0000
> >
> > save-hist-additional-variables never get truncated by save-hist, leading
> > to a massive cache file and slowdown. Practically, this matters when the
> cache file silently grows to 1/2 a
> > GB, and emacs begins randomly freezing.
> >
> > history-length is supposed to keep a limit on the max history for
> save-hist-additional-variables, but it doesn't.
> >
> > In the savehist-save function:
> >
> > (dolist (symbol savehist-minibuffer-history-variables)
> >           (when (and (boundp symbol)
> >                      (not (memq symbol savehist-ignored-variables)))
> >             (let ((value (savehist-trim-history (symbol-value symbol)))
> >       ;;....
> >   ))))
> >
> > (dolist (symbol savehist-additional-variables)
> >   (when (boundp symbol)
> >     (let ((value (symbol-value symbol)))
> >     (when (savehist-printable value)
> >     ;; ...
> >     ))))
> >
> > As you can see, the save-hist-trim-history fn is not called in the
> > second code block.
>
> I'm not sure I understand the situation.  Is the variable you are
> trying to save using save-hist a long list or something, and it keeps
> growing from session to session without any limitation?
>
> Save-hist doesn't truncate any variables except the ones it knows
> about, because it cannot be sure that truncating some list might leave
> the variable with an invalid value.  For variables like
> minibuffer-history, it knows that truncating the history will produce
> a history that is still valid, but how can it do the same with other
> variables?  For example, it could be that some other variable needs to
> be truncated from the other end of the list, otherwise the value will
> be useless.
>
> If I'm missing something about your use case, please tell the details,
> and perhaps show an example of a variable with which this happens.
>
> Thanks.
>

[-- Attachment #2: Type: text/html, Size: 9723 bytes --]