From: Drew Adams <drew.adams@oracle.com>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: help-gnu-emacs@gnu.org
Subject: RE: Reverting but keeping undo
Date: Wed, 29 May 2013 09:33:18 -0700 (PDT) [thread overview]
Message-ID: <e35de324-2c18-4c82-a56a-7126814427f6@default> (raw)
In-Reply-To: <51A61D01.8070904@yandex.ru>
> > 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.
next prev parent reply other threads:[~2013-05-29 16:33 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-15 10:38 Reverting but keeping undo Óscar Fuentes
2013-05-16 5:29 ` W. Greenhouse
2013-05-16 15:10 ` Óscar Fuentes
2013-05-29 1:52 ` Stefan Monnier
2013-05-29 3:09 ` Drew Adams
2013-05-29 3:27 ` Dmitry Gutov
2013-05-29 5:13 ` Drew Adams
2013-05-29 12:26 ` Dmitry Gutov
2013-05-29 13:55 ` Drew Adams
2013-05-29 15:21 ` Dmitry Gutov
2013-05-29 16:33 ` Drew Adams [this message]
2013-05-29 17:51 ` Dmitry Gutov
[not found] ` <mailman.605.1369845207.22516.help-gnu-emacs@gnu.org>
2013-05-29 18:42 ` Dan Espen
2013-05-29 13:48 ` Stefan Monnier
[not found] ` <mailman.562.1369804408.22516.help-gnu-emacs@gnu.org>
2013-05-29 13:25 ` Dan Espen
2013-05-29 16:26 ` Drew Adams
2013-05-30 18:48 ` Michael Heerdegen
2013-05-30 18:41 ` Michael Heerdegen
2013-05-30 19:19 ` Óscar Fuentes
2013-05-30 21:26 ` Stefan Monnier
2013-05-30 22:05 ` Michael Heerdegen
[not found] ` <mailman.728.1369951538.22516.help-gnu-emacs@gnu.org>
2013-05-30 23:59 ` Dan Espen
2013-05-31 0:58 ` Stefan Monnier
[not found] ` <mailman.738.1369961954.22516.help-gnu-emacs@gnu.org>
2013-05-31 1:21 ` Dan Espen
2013-05-31 2:28 ` Drew Adams
2013-05-31 16:05 ` Michael Heerdegen
2013-05-31 18:29 ` Óscar Fuentes
[not found] ` <mailman.767.1370016367.22516.help-gnu-emacs@gnu.org>
2013-05-31 17:22 ` Dan Espen
2013-05-31 18:08 ` Barry Margolin
[not found] ` <mailman.699.1369939338.22516.help-gnu-emacs@gnu.org>
2013-05-30 18:45 ` Barry Margolin
-- strict thread matches above, loose matches on Subject: below --
2013-05-31 16:49 Barry OReilly
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e35de324-2c18-4c82-a56a-7126814427f6@default \
--to=drew.adams@oracle.com \
--cc=dgutov@yandex.ru \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).