emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [External] : Re: Turning on savehist-mode by default


From: Drew Adams
Subject: RE: [External] : Re: Turning on savehist-mode by default
Date: Sun, 17 Dec 2023 18:48:57 +0000

> ... Given my experience with savehist causing
> unexpected and hard-to-debug performance problems,
> I'd guess that there are more such cases in the
> wild waiting to be triggered...
> 
> 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?...

+1.

At the very least, make users aware that
their input history is being saved by
default.  And explicitly point them to
how to configure savehist to save only
some histories and only some additional
variables.

IOW, let's not start silently saving
stuff users type/enter, without making
them very aware this is being done.

I also don't think changing the default
behavior is _necessary_, regardless of
whether some users might expect it
because they're used to something they
think is similar to that outside Emacs.

Do user choices from menus etc. get
recorded willy nilly outside Emacs?
Emacs completion choices are in some
ways like menu choices - especially
with fancy "completion frameworks".

Lots of stuff's input in the minibuffer
nowadays (esp. with completion) - a far
cry from just command, file, and buffer
names, which was the case for the first
several Emacs decades.

Emacs end users aren't necessarily
programmers.  And I think something like
a CLI `.history' file is a bit different
from all minibuffer input history.  The
latter is a wide net with tiny holes.
___

The first step is having users _aware_
of savehist.

And I think that's _sufficient_.  It's
_trivially easy_ for users to turn ON
saving of input history.  But they need
to know that that's the case.  And if
you change the default behavior it's
even more important for users to know
(a) that's being done and (b) how to
turn it off.  (And a NEWS item isn't
sufficient to provide such awareness,
IMO.)

If the argument is that saving should be
on by default _because_ users won't know
about being able to turn it ON, then an
even more important argument, _for the
same reason of user ignorance_, applies
to not saving by default.

All of this has already been said, but
Stefan K "didn't see any serious
objections".

Which is more serious: users not having
input saved because they're unaware of
that possibility, or users having input
recorded without being aware of that or
of how to control it?

(I'd make the same argument for bookmarks
and whatever other automatic saving is
done by default, but autosaving bookmarks
has been the default forever.  And part
of the initial idea of bookmarks is
persistence.)

Dunno how important this is, but I think
it's serious enough to at least consider.

IMO, it's fine to save stuff by default
_IF_ users are aware that's happening.
But they're not, in general, so I'd say
leave savehist OFF by default.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]