Re: Turning on savehist-mode by default

[Adam Porter]

On 12/17/23 02:12, Eli Zaretskii wrote:
> > 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.

From my perspective, as the developer of the package being accused of 
having performance problems by random users, problems I couldn't 
reproduce, nor even begin to guess what the cause was, or if it was even 
an actual problem, it felt pretty awful.

> > 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?

My package does not add huge elements to history variables.  It simply 
passes arguments to functions via their interactive forms.  I didn't 
even know that such history variables existed until that bug report came 
to its conclusion, and I've used Emacs for years and published tens of 
packages which together have nearly a million downloads.  So if it can 
happen to me, it can probably happen to anyone.

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

You may be right, considering how many users who build master have been 
speaking up lately.  Still, my concern is that whether the problem 
happens depends very much on a user's established workflows and 
installed packages.  Some users will never encounter the problem, and 
other users will encounter it constantly, and those who do won't have a 
clue what's going on, because it's heavily obscured.  I don't know what 
sample size would be needed to be likely to detect such problems, but it 
wouldn't be small, given that probably 0.1% or less of the users of 
Ement.el seemed to experience the problem--but for those who did, it was 
crippling to their Emacs usage.

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

That would likely be necessary, yes.  No one wants 450 MB savehist files 
in their .emacs.d getting rewritten every few minutes.

> > 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?

I guess it's a matter of perspective--from mine, I'm sharing such a report.