[Top][All Lists]

[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 19:17:41 +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.
> this is being polemic, and you know it.

Sorry, but I disagree.

I don't think there's anything polemical in what
I said.  If you refer to reasoned argument then
sure.  But if you're suggesting dogmatic reflex
and argument for argument's sake then I have to

The point made was that sometimes (sometimes)
we do change the default behavior of something
(e.g. from off to on or vice versa).  And even
something that affects _lots_ of users.

Not often, thank goodness!  As I said, I'm one
of the strongest proponents, in general, for
NOT changing default behavior.

But sometimes we do.  We can.  And sometimes,
as in the case of `transient-mark-mode', the
change in default behavior even takes place
after a very long time - i.e., we flip a very
longstanding behavior.

That was the point, and it was made in response
to an argument that the behavior shouldn't be
changed _only because_ it's longstanding.  My
point was that that argument, alone, isn't a
strong one.  It's a legitimate argument, but on
its own it doesn't override all other argument.

The point is NOT that status quo is bad (far
from it), or that status quo should never be
changed.  The point is that change is sometimes
merited, even for longstanding behavior.

Nothing more.  I was countering the blanket
argument that nothing longstanding can or should
ever be changed.  (And yes, such a blanket
argument was made, IMO.)

> There may be reasons for a change (there often are), but they should be
> discussed on their merits. Sometimes, that discussion is arduous,
> because there are folks who prefer the old behaviour.

Exactly.  Which is why this is being discussed
on its merits.  And its costs.

> Dismissing something just because it sticks to the "status quo" 

No one did that.  Certainly not I.

> is a disrespect towards those users who /in this one case/ prefer this status
> quo for whatever good (to them!) reason. Gotta listen to that, instead
> of just telling them "you're a luddite" or "you're just resistant to
> change".

You are acting alarmist, IMO.  No one said
anything like your characterization.

(I'm in fact most often thought of as being
resistant to change.  I'm not systematically
opposed to change, but some have accused me
of that.  I do tend to oppose change for
which no reasons have been given, and whose
reasons are not obvious.)

> This can be even offensive: after all, it's a way of telling those
> people "you don't exist". Big flamewars have been in part fuelled by
> this pattern.

Sorry, but you're really being over the top.
I'm not telling "those people", or anyone,
any such thing.

I invite you to reread what I wrote, and then
read your response, and then think about who
might be fueling (or even igniting) flames.

(It might be enough for you to just look at
the messages that people have sent in response
to your message that I'm replying to now.  I
think you'll find that you ignited a useless
tit-for-tat emotional storm, with little-to-no
real content.  Do you disagree?  I believe you
changed the tone, as well as the content, of
the thread, and not in a positive way.)

> With a program as old as Emacs, which will
> have lots of more old users than new, I think
> those discussions are necessary.

Proposals to change behavior should always be
accompanied by reasons, and discussed with
reasons, counter-reasons, etc.

That's been the case here, at least on my end.

I'm a big fan of discussing what should be done
and (especially) why & why not.

And yes, it's particularly important to consider
existing users and longstanding behavior.

But the number of future users is always greater
than, not smaller than, the number of existing
users. (It might even be the case that there are
more past users than there are existing users.)

But existing users can speak for themselves,
whereas guessing what's appropriate for future
users is always risky.  Who can speak for them?
No one, really.

Examining the benefits & costs of some design,
while abstracting from what might already be
used, is one way to guess what might most help
the greater number of users.  It's reasonable
to ask what design we'd pick if starting from

But _by itself_, such an assessment has the
disadvantage of not taking into account the
effects of a possible change on existing users.

Both (1) guessing what's best for the greater
good, and (2) guessing what's good for existing
users, are appropriate when considering what
to do.

(And yes, even though existing users can speak
for themselves, #2 is a guess, as the number of
interlocutors in the discussion is limited.)

> In the present case, I'm against the proposed change. Why?

Very good to say why.  Thank you for that.
(I appreciate disagreement with expressed
reasons, and dislike it without reasons.)

> Because it alienates some old users for no reason but some "pedagogy" towards
> hypothetical new users, although there would be far better means to
> achieve that (several have been proposed in this thread).

I think this has already been gone over in
the discussion.

[I disagree that the proposed change helps
 only new users, or that they are only

 I gave reasons why I think it can help
 experienced users as well.  And anyone who
 doesn't want the proposed default behavior
 could simply use `setq' once, to return to
 the behavior s?he had before.]  

> Personally, I won't be affected by that: I 
> separated off the custom file long ago anyway.

Likewise.  Like you, changing the default
behavior wouldn't affect me.  I proposed the
change for Emacs users in general.  I think
it would help the most users, from novice to

Even those who've expressed disagreement with
changing the default have, so far, pretty much
agreed that if letting Customize save to the
init file were not the longstanding behavior,
the better design would be to use a separate

It's a better design for the default behavior.
Whether it makes sense to change to that
design now is the question. 

> I'd be miffed had I not and had the change come anyway

Would you really be _miffed_ by having to set
`custom-file' to your init file?

To me, such a strong reaction borders on a
demand that _nothing_ ever change in a way
that would cause you to do anything.  I mean,
if adding a `setq' provokes that kind of
reaction, where would it end?

I disagree with many, many, many changes
that Emacs makes, some of which require me
to go to great lengths to compensate or
adjust.  If I had a reaction such as what
you describe each time Emacs makes me change
my code or setup I'd have gone postal long
ago. ;-)  Life is too short.

> (I'm one of those who /edit/ the custom file after Customize has done
> its work, because (a) I can't stand "HANDS OFF! THIS FILE NOT FOR YOU!",
> and (b) because at the beginning it was a wonderful way to learn about
> Emacs's inner workings).

Seems like a similarly strong reaction,
just for a suggestion aimed to help users
avoid mistakes.

(I'm not defending that warning - I just
point out that it sounds like you have
quite a strong reaction there, as well.)

> So I can feel with those who now oppose this change.

I can too.  (And I think I've shown that.)

> > 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.
> You are overlooking something important: our community
> is (compared to others) pretty civilised.

Why/how do you think I'm overlooking such
a thing?

> Idiosyncratic, yes, but civilised. The
> maintainers are highly respected people (at least among most old timers,
> and this /is/ an important part of our community). So once a decision
> has been reached, each one tries to get along with it.

Why do you think I'm overlooking that fact?

> Still, I think this comes both ways, and this seemingly endless
> discussions are part of what helps people to stay civilised, because
> concerns from all sides are heard.

I haven't tried to silence the discussion.

I happen to agree that discussion, especially
reasoned argument - presenting reasons -
promotes a civilized, cooperative community,
as well as it advances understanding.

reply via email to

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