From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Chris Findeisen Newsgroups: gmane.emacs.bugs Subject: bug#30943: save-hist creates massive cache file Date: Thu, 29 Mar 2018 16:27:12 +0000 Message-ID: References: <83o9jag9wg.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113f354ca3c59605688f9ab8" X-Trace: blaine.gmane.org 1522340774 24940 195.159.176.226 (29 Mar 2018 16:26:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Mar 2018 16:26:14 +0000 (UTC) Cc: 30943@debbugs.gnu.org To: rgm@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Mar 29 18:26:10 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1aNN-0006Mj-Ro for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Mar 2018 18:26:10 +0200 Original-Received: from localhost ([::1]:38224 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1aPP-00075R-RG for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Mar 2018 12:28:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1aPH-00074g-4y for bug-gnu-emacs@gnu.org; Thu, 29 Mar 2018 12:28:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1aPC-0000B4-LQ for bug-gnu-emacs@gnu.org; Thu, 29 Mar 2018 12:28:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50970) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f1aPC-0000Ap-Hw for bug-gnu-emacs@gnu.org; Thu, 29 Mar 2018 12:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f1aPC-0006Ry-5j for bug-gnu-emacs@gnu.org; Thu, 29 Mar 2018 12:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Chris Findeisen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 29 Mar 2018 16:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30943 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30943-submit@debbugs.gnu.org id=B30943.152234087524777 (code B ref 30943); Thu, 29 Mar 2018 16:28:02 +0000 Original-Received: (at 30943) by debbugs.gnu.org; 29 Mar 2018 16:27:55 +0000 Original-Received: from localhost ([127.0.0.1]:58867 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1aP4-0006RZ-U3 for submit@debbugs.gnu.org; Thu, 29 Mar 2018 12:27:55 -0400 Original-Received: from mail-io0-f174.google.com ([209.85.223.174]:37014) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1aP3-0006RN-Fg for 30943@debbugs.gnu.org; Thu, 29 Mar 2018 12:27:53 -0400 Original-Received: by mail-io0-f174.google.com with SMTP id y128so8330427iod.4 for <30943@debbugs.gnu.org>; Thu, 29 Mar 2018 09:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qziNw+Pl1xahb2iHHpKibRncZzr7UiBunGWvQka9Fto=; b=RmsPzm/sZOgfQWeh/Y5+r90Q0adpO2RhSeX+d6DJUoUfkzgxl7RZHG1xtiMp39ymaN E6S7TEhUJvYcNUv5eHNN2IT/c1sn/O4A3gxqK43vfM1oOKIqSyffFi+SkoKNWjzr2IDI HK3Mkaoq7AmAz2iqH/YJaW+1c0KVvkTL/Rf/xep/fE+l6hSTr8juzCC69dZUGzA8fGUu og1vu+5YPYmYVASZt1nBp/MKebuUTGYv6qdRr49/dF97O4fJEZuG9OhaXszDW8GHu2br 0A/o4piYtca7Qtj49r5D8YU/PIwNNHbQRE5aBfCSFEc9QOKChAyi3ZmrfeMEPWURkwDB DncA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qziNw+Pl1xahb2iHHpKibRncZzr7UiBunGWvQka9Fto=; b=ZorTe9TXX7lXU4wqg86umSPMPb0wRYmJa/o388HKwerWsKwkaNGEppg+0bJ1qCZVQf 6Ojl3YGOQvV2nWwzqqp9diANAXbnrWK0DBYnbkApBx0tA4jgaYxPPnA4/Mp5gS1DbsVS KOxTb42uvMr3zMzt7+9ms/bjVSX8+qhHMo/uDAizTlvx+dAqjUrSuJFaa+thA1boyxCv RcYvoadCUYP8wGQm6JRK+hhl5oksOvfd//tUYWoPESTGM4PolK1eDE9+ir7zFJlwudiz gtsvAzY+iq7XJF6nn6H+h20zORNH6bHZ9KPhEixVubMpU9fxxP+MunFn6RzGz48oJRNt EzIw== X-Gm-Message-State: AElRT7FpD7eeLw6+114aKou8zHd2Gt5vGdiLWL1r/1MhJw+pcmW7zxCc n1k4nj+lske/syFYYSJnwxM/XaQChtCfV5xCUFVKag== X-Google-Smtp-Source: AG47ELtU5AZFVYU3jshCbPSPO7x0KXnCbWiSa3aB41Sm+gafZI7RT7q+HkHOHZzpt/CKFJW7u6/DU0SNxmdrIeVehSg= X-Received: by 10.107.18.129 with SMTP id 1mr56027260ios.164.1522340867561; Thu, 29 Mar 2018 09:27:47 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:144691 Archived-At: --001a113f354ca3c59605688f9ab8 Content-Type: text/plain; charset="UTF-8" > > 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 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. > --001a113f354ca3c59605688f9ab8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
None of those look large.

yeah, I had rm'd my cache file when it was r= eally huge (~1GB), now it's regrowing. To get a sense of what I was loo= king at previously, I had a similar output to this person's=C2=A0http= s://emacs.stackexchange.com/questions/12086/abnormally-large-savehist-file<= /a>. 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
cour= se 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.=C2=A0

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

Regards,
Chris Findeisen


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.
--001a113f354ca3c59605688f9ab8--