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

[Drew Adams]

> >> I wouldn't dismiss the proposal to enable it by default.
> >
> > I don't dismiss it.
> 
> So you don't oppose enabling savehist-mode by default?

I don't _dismiss_ it.

___

https://www.wordwebonline.com/search.pl?w=dismiss

WordWeb tells you:

Verb: dismiss

Bar from attention or consideration

"She dismissed his advances";
- disregard, brush aside, brush off [informal], discount, push aside, ignore
 
Cease to consider; put out of judicial consideration

"This case is dismissed!";
- throw out
 
...
 
Declare void

"The President dismissed the parliament and called for new elections";
- dissolve

> >> The issue is that beginners neither know how to do it, nor
> >> what all the options are that they might be interested in.
> >
> > And yet it's "done by (practically) everyone"?
> 
> Let us say, "(practically) everyone" who manages to stay along, by
> finding the right options to create a comfortable and productive
> environment for themselves.  There are certainly many beginners that
> never change this user option; but I suspect that these are also the
> ones that never get to taking a look at any user options, because they
> give up too soon.

So nearly all of those who (1) tried savehist
and (2) didn't give up on getting comfortable
and productive with it by fiddling with its
options.

That's a far cry from "(practically) everyone".
But OK, it's clear now: Most who persisted at
trying to use savehist continue to use it -
that's the claim now.  Might be the case.

> > ___
> >
> > Let's enable `delete-selection-mode' by default.
> >
> > It took decades to get `transient-mark-mode' ON
> > by default.  `delete-selection-mode' completes
> > that job.  It welcomes new users with the same
> > type-to-replace behavior they're used to outside
> > Emacs (everywhere).
> >
> > Persists nothing.  Is easy for anyone not who
> > doesn't want it ON to turn OFF.
> 
> One has to keep in mind that there are a lot of people who use Emacs,
> and are familiar with the "feel" of the default key bindings or at least
> some subset of these, without having much of an understanding of how to
> do things or what is going on.  These are users that should nevertheless
> be respected -- hence my point that enabling a feature has to take the
> workflow of people into account, for whom a change would break an
> expectation.

Not too worry.  One has been keeping this in mind
for many decades...

One kept it in mind about `transient-mark-mode',
yet that was eventually turned ON by default.

(There are still users, today, who turn off
`transient-mark-mode', but likely many fewer than
if the default behavior hadn't changed to ON.)

> Note that I am *not* saying that the goal should be to accommodate
> newcomers (following whatever current trends may be) at any cost,
> especially when this comes at the expense of long-term users.

Nor am I.  Nor was that behind turning ON
`transient-mark-mode' by default.

> To make this argument with savehist-mode, one would have to make the
> use-case believable, that someone expects the history of mini-buffer
> input to not persist between sessions.  I think that is a claim that it
> a lot harder to justify, than that inserting a key while a selection is
> active, replaces the selection.

No, I don't think making that use case believable
is a requirement.  Nor does anyone need to justify
it as a claim.

But FWIW, I do bet that someone - likely even most
users! - currently expect minibuffer input history
to NOT persist.  If it isn't persisted then, hey,
why would someone expect that it is?

To me that expectation _is_ believable.  But I'm
not assuming that "(practically) everyone" turns
on saving of minibuffer histories.  I'm guessing
that more people don't than do.  Just a guess.

__

FWIW, `savehist.el' is a general way to save variable
values, not just a way to save values of minibuffer
history variables.  It's often recommended (including
by me) as a way to persist any variables you like.

Why isn't it written with that foremost in mind, i.e.,
as a general variable-persisting feature?  Why make
users fiddle option `savehist-additional-variables'
to be able to use its (real) functionality?  Why have
pure-Boolean option `savehist-save-minibuffer-history'
instead of just an option whose value is a list of
variables to persist?

Did it start with just the aim of saving minibuffer
histories, and later grafted on the more general
functionality as a wart?  I guess not:

It's not in Emacs 20; I don't have Emacs 21; and in
Emacs 22 there's already the current design, with
variable `savehist-additional-variables'.  The code
comment expressing the motivation says it provides
Emacs with what "many editors (e.g. Vim)" already
had: minibuffer-history persistence.  (Presumably
they had something similar to a minibuffer and its
input histories.)

I understand that it treats minibuffer histories
specially, in that when you use a new history var
that automatically gets included in the list of
vars to persist.  Still, the general functionality
is to persist a set of vars.

__

FWIW, I repeat that I'm a user/fan of savehist.
My value of `savehist-additional-variables':
`(search-ring regexp-search-ring)'.