From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#30943: save-hist creates massive cache file Date: Fri, 30 Mar 2018 11:14:13 +0300 Message-ID: <83h8oyc756.fsf@gnu.org> References: <83o9jag9wg.fsf@gnu.org> <1rwoxusqjl.fsf@fencepost.gnu.org> <83po3md8hw.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1522397592 30451 195.159.176.226 (30 Mar 2018 08:13:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Mar 2018 08:13:12 +0000 (UTC) Cc: 30943@debbugs.gnu.org, cfindeisen@google.com To: Glenn Morris Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 30 10:13:08 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 1f1p9n-0007oK-So for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Mar 2018 10:13:08 +0200 Original-Received: from localhost ([::1]:42393 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1pBr-000858-F9 for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Mar 2018 04:15:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1pBi-00084l-RC for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2018 04:15:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1pBe-00028e-Qn for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2018 04:15:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51435) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f1pBe-00027y-Mi for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2018 04:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f1pBe-0000fN-F9 for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2018 04:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 Mar 2018 08:15: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.15223976772512 (code B ref 30943); Fri, 30 Mar 2018 08:15:02 +0000 Original-Received: (at 30943) by debbugs.gnu.org; 30 Mar 2018 08:14:37 +0000 Original-Received: from localhost ([127.0.0.1]:59332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1pBF-0000eS-IP for submit@debbugs.gnu.org; Fri, 30 Mar 2018 04:14:37 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42056) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1pBE-0000eG-EW for 30943@debbugs.gnu.org; Fri, 30 Mar 2018 04:14:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1pB5-0001jG-DH for 30943@debbugs.gnu.org; Fri, 30 Mar 2018 04:14:31 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33978) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1pB5-0001jB-8n; Fri, 30 Mar 2018 04:14:27 -0400 Original-Received: from [176.228.60.248] (port=3874 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1f1pB4-0004Hn-38; Fri, 30 Mar 2018 04:14:26 -0400 In-reply-to: (message from Glenn Morris on Fri, 30 Mar 2018 01:25:23 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:144726 Archived-At: > From: Glenn Morris > Cc: cfindeisen@google.com, 30943@debbugs.gnu.org > Date: Fri, 30 Mar 2018 01:25:23 -0400 > > Eli Zaretskii wrote: > > > I actually find that to be a nuisance even for visiting files. With > > 64-bit builds, this warning makes very little sense. > > 32-bit builds are almost dead, so you may want to revisit the default. > (See trend at https://debbugs.gnu.org/stats/emacs.html ) Yes, I think we should significantly increase the default value of large-file-warning-threshold. I always enlarge it in my .emacs, because the default is even small enough to allow me reading my email without annoying questions. > But isn't it about how much physical memory the system has? That's one factor to consider, yes. But even that is normally what? 8GB nowadays? And VM is then 2 or 4 times that? > The largest el(c) file in the Emacs sources is ja-dic at 2.2MB, > well below the current default for large-file-warning-threshold. > So not warning about loading a 1/2GB file like in the initial report > seems like a disservice. I wouldn't worry before it got 10 times that, but that's me. Don't forget that before that file was about to be read, it was written by the previous Emacs session, which means that previous session already had all that loaded, and took more memory than that file's size. If the user was not worried about their running Emacs's footprint, why should we annoy them with questions at startup time? IME, these measures are only useful when they prevent some very grave problem, like Emacs crashing or becoming completely unresponsive. (We had such problems years ago, when the 64-bit build still had bugs with using integer types that overflowed at INT_MAX, and we indeed had then tests to prevent users from crossing that border.) Otherwise, I personally would prefer _not_ warning about large files and let each user find the point where it becomes annoying to them. This is because IME that point is highly individual, and depends on both user preferences and the resources on their machine. We can never do as well with a fixed threshold, even if its value is somehow calculated from the available data: there are too many unknown factors here. Again, just my $0.02.