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.