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: Dan Espen
Subject: Re: Reverting but keeping undo
Date: Wed, 29 May 2013 14:42:30 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

Drew Adams <drew.adams@oracle.com> writes:

>> > 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.

I think most of us are wondering what the hell you're going on about.
You made your comments.  You got replies.  Yet you complain about
lack of discussion.

If there is someone else you want to discuss this with, seek them out.

Meanwhile, no one is going to put you in charge of mailing list
protocol.  What do you want to do, impose a fine because you didn't
get a "Any objections?" comment?

-- 
Dan Espen


reply via email to

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