Re: Turning on savehist-mode by default

[Eli Zaretskii <eliz@gnu.org>]

> 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 <adam@alphapapa.net>
> 
> 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?