help-gnu-emacs
[Top][All Lists]
Advanced

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

RE: Reverting but keeping undo


From: Drew Adams
Subject: RE: Reverting but keeping undo
Date: Wed, 29 May 2013 09:33:18 -0700 (PDT)

> > why no discussion?
> 
> Who were you agreeing with, there?

Agreeing with?  It's a question.

> Because discussing every single thing takes more time and effort, and
> most people have a limited amount of them. It's not like you're
> sponsoring the development, right?
> 
> And, like it often happens, people with a lot of opinions are often the
> least qualified to make a decision. See "bikeshedding".

Doesn't matter.  It would have been better to open the proposal for
discussion.  There was a discussion about adding remove-to-trash-bin
behavior, for instance, and that feature did not even _replace_ the
existing file-deletion behavior.

Those offering opinions are not, in general, those deciding.  Discussing
is not the same thing as deciding.  Discussion is not and should not be
limited to only those who decide, or even to only those who are most
qualified.

Just because someone qualified will decide does not mean that there should
be no discussion before the decision, including contributions by those you
might judge "least qualified".

> > And it is not a discusson on emacs-devel by Emacs developers.
> 
> Again, are you an Emacs developer? You aren't. What do you care?

That remark bespeaks an arrogant attitude toward Emacs users.

Lots of Emacs users care about the development of Emacs.
They do not need to justify such care to anyone, including to you.

> Emacs committers are subscribed to emacs-diff or emacs-bugs, and if some
> aren't, they should. Anyone disagreeing can voice their opinion.
> Preferably without speaking for other people.

Blah.

> > Instead of willy nilly changing the basic function `revert-buffer',
> > this feature of extra protection against user mistakes (including
> > mistakenly confirming reversion!) should be implemented by creating
> > a separate command or user variable (perhaps option) - giving users
> > the choice to use it or not.  If `auto-revert-mode' is also implicated
> > then it can be made sensitive to the same (or an additional) user choice.
> 
> The "extra protection" feature means that the new behavior makes sense
> as default.

Maybe so.  But it was not made the _default_ behavior.  It was made _the_
behavior - more than just the default.  The new behavior replaces the old.

> So, a hypothetical new variable would revert the behavior to how it were
> before, but setting a new variable isn't too different from advising
> `revert-buffer', from a user's perspective.

It's a lot different.  You should know that.

> > I'm not the one assuming anything about the user base.  I'm not the one
> > claiming competence deciding what is good for everyone.   I'm not
> > imposing any change on the existing behavior.  My only assumption about
> > the user base is that users deserve control, choice.
> 
> You're assuming that the old behavior is important enough

...that a change should be proposed and open for discussion on the dev list.
That's all.

> for a decent amount of users to justify the expense of discussing it,
> adding a separate command, new variable, whatever, documenting it, and
> then maintaining these additions over the years. That's not a safe
> assumption.

No, I don't assume any of that.  I just think this should have been proposed
for discussion on the dev list, so we might hear from people with different
uses and more knowledge (than I have, at least).  Instead, we just get a few
knee-jerk reactions of "I like it!" on the help list.

Well, FWIW, I happen to like it too, for my personal interactive use.
And FWIW I have been using it for quite a while now.  Surprised?

I'm just not sure it is a great idea for Emacs (i.e., all users) as an
unconditional _replacement_ behavior.  That's all.  Unqualified to judge,
no doubt.  But would like to have heard from more, including some who are
qualified.

Can I be clearer?  I am not saying this change should not be made.
I'm saying I don't know whether it should be made, and there was no
discussion about it, which is too bad.  Discussion might have made any
issues clear, perhaps boosting confidence in the decision.

Even for minor changes we often see "Any objections?" in the dev list.
That's a courtesy, but it is also a safeguard to some extent.  This change
was not even brought up.

I asked why.  Your answer was that this is an unimportant, uncontroversial
change not worth remarking or discussing.  To you, discussion of this
would be bikeshedding.  I am not so sure as you.

> And the one user with special needs who does care about it can change
> the behavior with `defadvice'.

Wunderbar.



reply via email to

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