Re: Reverting but keeping undo

[Dmitry Gutov]

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