bug#30943: save-hist creates massive cache file

[Chris Findeisen <cfindeisen@google.com>]

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

>
> None of those look large.


yeah, I had rm'd my cache file when it was really huge (~1GB), now it's
regrowing. To get a sense of what I was looking at previously, I had a
similar output to this person's
https://emacs.stackexchange.com/questions/12086/abnormally-large-savehist-file.
The point is that over time these variables grow and grow and slow.

savehist doesn't truncate anything AFAICS.
> It just assumes variables are trimmed by add-to-history etc in the
> course of normal operation. So if you add a non-history variable to
> savehist (or set history-length to t), it will eventually blow up.
>

Hmm, ok. I may have misunderstood savehist's role then, I thought that
savehist managed history size. Eli, apparently the savehist-trim-history
function is only used on XEmacs--it's a noop on Emacs.

Sorry for the confusion then. First bug report :D ... failed bug report :(
. I'll talk to Spacemacs folks about fixing their configuration to guard
these variables accordingly. Thanks for your time!

Regards,
Chris Findeisen


On Tue, Mar 27, 2018 at 12:44 PM Glenn Morris <rgm@gnu.org> wrote:

> Chris Findeisen wrote:
>
> > 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
>
> None of those look large.
> You either want to post the whole output, or find the one where the
> offset jumps significantly from the previous match.
>

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