bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30943: save-hist creates massive cache file


From: Chris Findeisen
Subject: bug#30943: save-hist creates massive cache file
Date: Tue, 27 Mar 2018 02:50:57 +0000

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]