emacs-devel
[Top][All Lists]
Advanced

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

RE: [External] : Re: Default custom file was: Re: Propose to add setup-w


From: Drew Adams
Subject: RE: [External] : Re: Default custom file was: Re: Propose to add setup-wizard.el to ELPA
Date: Mon, 10 Jan 2022 22:02:06 +0000

> > Consider `transient-mark-mode'.
> > Its existence in Emacs was status quo for a
> > very long time, and the behavior was OFF.
> > Until it wasn't - the status quo was changed
> > to ON.  Holy Toledo!
> 
> > That was a backward-incompatible change in
> > behavior.  It affected thousands of users.
> > It took us _decades_ to get that change made.
> > Status quo, status quo, status quo.
> 
> And I didn't like that change.  IMO, it was a bad idea, but the
> decision has already been made.

It too hadn't been made when it was being discussed.

> Here, it has not, so it would be good
> to not repeat the same mistake.

It wasn't a mistake; it was done deliberately.
You don't like it; that doesn't make it a mistake.

> > And why was that change finally made?  It's
> > what those who decided expected that more
> > users would expect & want.  Users out in
> > the wild expect to see text that they select
> > to act on ("activated") be highlighted, so
> > they can see what they'll act on.
> >
> > What was the effect on users who did NOT
> > want `transient-mark-mode' on by default?
> >
> > They turned it off.  End of story.  Some
> > muffled grumbles, nothing more.  Why?
> > Because you can still use Emacs as before -
> > just turn `t-m-mode' off (Customize).
> > Happy campers all around.
> 
> Lucky.  We don't know that would be the case here.
> (And it was not the case with transient-mark-mode either.)

You're mixing things up.

It's not about whether you like the change to
`t-m-mode' ON by default.

The point in mentioning `t-m-mode' (since you
didn't like the example of `lexical-binding')
was to point out that longstanding (even very
longstanding) default behavior is sometimes
changed/flipped.  And that's sometimes done
after a lot of discussion.

And we do know that it would be the case that
you would be able to keep the current behavior
just by setting `custom-file' to your init file.
You can do that today.  Try it, or look at the
code for _function_ `custom-file', to see.

See the last line:

(defun custom-file (&optional no-error)
  "Return the file name for saving customizations."
  (if (or (null user-init-file)
          (and (null custom-file) init-file-had-error))
      ;; Started with -q, i.e. the file containing
      ;; Custom settings hasn't been read.  Saving
      ;; settings there won't make much sense.
      (if no-error
          nil
        (user-error "Saving settings from \"emacs -q\" \
would overwrite existing customizations"))
    (file-chase-links (or custom-file user-init-file))))

> > I'm as strong a proponent of not rocking the
> > status-quo boat as anyone.  And opinions can
> > certainly differ about whether `custom-file'
> > should default to a file name.  But what's
> > the downside of changing such a default
> > change?
> >
> > A relatively few users - those who remain
> > wedded to using only their init file - would
> > need to set `custom-file' to their init file
> > (or to nil, if we interpret that as using
> > the init file after the default change).
> 
> > Yes, and?  Anyone can rely on the behavior
> > they've long relied on and enjoyed, by just
> > setting `custom-file' to their init file.
> > End of story.
> 
> Nobody knows how "few" those users are,

I said "relatively" few.  And I'm sticking to
that.  (1) Fewer users today than tomorrow.
(2) How many existing users will insist on
continuing to let Customize save to their init
file?  I'm betting on relatively few.

> and even if someone did, it would still be
> better to cause less churn.

There you go again.  Turning a discussion of
relative cost/benefit into a black-&-white
less-churn-ALWAYS-better, aka NO-change-EVER.

> > In the case of `transient-mark-mode' I'd wager
> > that the _vast_ majority - maybe 90% - of
> > existing Emacs users had `t-m-mode' off when
> > the default was switched to on.
> 
> From anecdotal experience at my workplace, that is simply false.

At your workplace?  How many users at your
workplace had `t-m-mode' turned ON before
the default was switched to ON?

I don't know anyone who had it turned ON
before the change.  When it was turned on
by default it was a change for everyone I
knew who used Emacs.

So I'd still make that wager.  Will we ever
know?  Nope.

But maybe you'd grant that many Emacs users
had t-m-mode OFF when the switch to ON by
default was made - even if you don't agree
that they were the vast majority.

> > And I'd wager that a minority of them bothered
> > to switch it to off after the default changed.
> 
> Also untrue.

It's a wager.  (It's definitely true that
I'd wager that.)  We'll never know for sure
what proportion who had it off before the
change (which you think was not the vast
majority, at least) went to the trouble of
turning it off explicitly after the change.

> > It's not only about individual preferences,
> > and especially not only about _current_ ones.
> >
> > It's also about what we expect will be best
> > for most users, and in particular most users
> > in the future.  Most Emacs users are future
> > users, not current users.  What's the best
> > behavior for them?  I think it's to separate
> > the file that Customize writes to from their
> > init file.
> >
> > But _every_ user will have a simple, trivial,
> > quick, one-time way to get the behavior they
> > prefer: just set `custom-file' to the file
> > they want Customize to write to, whether
> > that be their init file or another file.
> >
> > Sensible behavior by default for everyone.
> > Individual preferences respected.  Happy
> > campers, all.
> 
> That's a catch-all excuse to make random changes, and a very slippery
> slope.  Imagine how many "one-time solutions" there would have to be
> if we made more and more changes under that slogan.

None of that follows.  It's not because Emacs
makes a rare flip of default behavior, with a
trivial way to get the pre-change behavior,
that Emacs is obliged to flip default behavior
all over the place.  Let's not be alarmist.

> > The exact number, sure.  But not the relative
> > number.  Unless Emacs is blown off the globe
> > it's certain that there will be more users in
> > the future than there are today.
> 
> And that globe might as well be blown to pieces tomorrow, so it is
> utterly pointless to make changes to please those who might not even
> exist.

Huh?

> > Diehards who said the same thing about turning
> > on `transient-mark-mode' will admit today that
> > their alarmism was misplaced.
> 
> I don't.  I know as a fact that it's annoying for people switching
> between Emacs 23 and 21, both of which still have users.

 /s/diehards/SOME diehards

Other diehard anti-transient-moders no doubt stick
to their guns.  That's their right, and they can
do so just by turning that mode off.  Thankfully.
End of story.




reply via email to

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