Re: Reverting but keeping undo

[Dmitry Gutov <dgutov@yandex.ru>]

On 29.05.2013 17:55, Drew Adams wrote:
>>>> I think it's a great change.
>>>>
>>> Yes, why?  Any good reason?
>
> You misquoted.  My "why" there was about the lack of discussion prior to this change - why no discussion?

Who were you agreeing with, there?

> DG> > I think it's a great change.
> da> > > And why no discussion beforehand?
> da> Yes, why?  Any good reason?

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

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

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.

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

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.

>> Obviously not. The opened bug is a couple of years old now.
>
> There are thousands of bugs that have been open for a couple of years or more.  That means nothing.

That means someone has spent some time thinking, and then made a decision.

>> We're having this discussion now, and instead of giving actual reasons
>> you're speaking of hypothetical users.
>
> I gave reasons.  1. This is what reverting means, what reverting does (should do, always has done).

"foo has always done that" is not a reason. Here's an example of a 
plausible reason "Mary has a little lamb, she wants to shave it, but 
cannot do it unless `revert-buffer' clears the buffer undo list." Here's 
another: "foo has always done that, and the new behavior breaks packages 
X, Y and Z that depend on it".

"reverting means" whatever the user manual at any given point says it means.

> 2. `revert-buffer' is not used only interactively; it is a basic function used in lots of code.

Another reason to make the change. Basic functions shouldn't do too many 
things at once. If a consumer wants to clear the undo list, they can do 
that separately.

>> But the way you often assume the you know the userbase better than
>> everyone else is tiresome, to be honest.
>
> 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 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.

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