From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Turning on savehist-mode by default Date: Sun, 17 Dec 2023 10:12:50 +0200 Message-ID: <831qbll01p.fsf@gnu.org> References: <461a0999-6005-4aa4-a4b3-988123855f92@alphapapa.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27033"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org, sbaugh@catern.com, stefankangas@gmail.com To: Adam Porter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 17 09:14:02 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rEmHh-0006qP-Rh for ged-emacs-devel@m.gmane-mx.org; Sun, 17 Dec 2023 09:14:01 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rEmGs-0007ZC-8I; Sun, 17 Dec 2023 03:13:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rEmGq-0007Yy-W4 for emacs-devel@gnu.org; Sun, 17 Dec 2023 03:13:09 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rEmGp-0005Yy-TN; Sun, 17 Dec 2023 03:13:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=I12ly0qtBn9vyJPwYI3Qd9xON9KUr0ppq4Cmv2H+cIE=; b=oy6w6VfT3ka4 GEM4QEfNIjng1uZ1g9z/AK+eU7RPzcnshp2OorqHyOqq8iAol4s+fhl2OqxCeIuRfLxcMooBbaD2U 415e4hNe6P+CxcIrTIjzvTMH0q+kGgwq8xSLfVwQpbZ6esxwKZuzBUsCFhqlszyNk0TN0zquxIV1V zvQUNRou9vVV6lLVgxPBxt/FCMopgyDc9SRL1Xn4G+4aRaiYE2iraDmIJLVPPmaoztKC2GDLgUjll UyojstUtbI1N9Cs6N4o/oJKiP5ClKCm252bLc7YPmSptBlx3FGh9gANgxZrAe5RNdtNV8xiifJOJV J3QPjvxwsZM9BO8zEuNbrQ==; In-Reply-To: <461a0999-6005-4aa4-a4b3-988123855f92@alphapapa.net> (message from Adam Porter on Sat, 16 Dec 2023 23:42:15 -0600) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:313906 Archived-At: > Date: Sat, 16 Dec 2023 23:42:15 -0600 > Cc: eliz@gnu.org, emacs-devel@gnu.org, sbaugh@catern.com, > stefankangas@gmail.com > From: Adam Porter > > In addition to what Po said, I'd like to gently reiterate what I said > earlier in this thread: Given my experience with savehist causing > unexpected and hard-to-debug performance problems[0] That mentions a single 3rd-party package that triggers the issue, and includes a workaround solution. I see nothing awful there. > I'd guess that there are more such cases in the wild waiting to be > triggered. You know about other packages that add huge elements to history variables? Which ones? > If, e.g. Emacs 30.1 enabled it by default, I can imagine a number > of users suddenly encountering weird pauses, and they'd probably > blame GC initially[1]. This remains to be seen, and having this on master enough time in advance will allow such reports to come in, if indeed such problems exist. We could also introduce a limitation of element size (a defcustom) to be imposed by add-to-history, if we think such long elements are detrimental to performance. > As well, I have some concerns about savehist's having the potential to > cause weird bugs in other libraries: The savehist-save function seems to > comment out individual elements of savehist-minibuffer-history-variables > that it determines are unreadable. That's understandable from its > perspective, but what effect will that have on libraries that may not be > expecting for their data structures to have certain parts disappear > after restarting Emacs? I can just imagine the bug reports from users > showing apparently corrupted or elided data structures, and having no > clue as to what is mutating them, because the code isn't within the > library having a bug reported against it. If such bug reports will come in, we will handle them. As we do with any other Emacs feature. Why worry in advance, when we don't yet have any such reports, and therefore can do nothing about them? > IMHO, a feature like this is indeed expected and overdue in Emacs, but I > don't think savehist is a good way to enable it, given its current > implementation. ISTM that something built on top of the new > multisession library would be more appropriate and (at least, have the > potential to be) more robust. > > If savehist is to be used for this, I would at least recommend taking a > release cycle to publicly ask users to enable it by default and report > the results, and wait for at least a few hundred positive reports before > enabling it by default. Otherwise, I would expect not-insignificant > fallout, IMHO. If we enable it on master, it will give users precisely that, right?