Idea for C-x v u

Idea for C-x v u

[Richard Stallman]

It is definitely a good idea to check the diffs of a file before
reverting a change, but normally it's a waste of time for C-x v u to
do that because I will have done it manually.

However, if I ever forget to do that, it wouldn't hurt for C-x v u to
remind me.

So here's an idea.  Make C-x v d record the tick count of the buffer
when it was done.  Then C-x v u can show a diff, if you have not made
one of that buffer since the last edit in it.

This might be universally better than the two optional choices that
were previously proposed (either unconditionally show a diff, or never
show a diff).

Another idea is: if you have not made a diff since the last change in
the buffer, give an error, "Please look at a diff using C-x v = before
doing C-x v u".  It is more convenient for the user to make the diff
with a separate command than to examine it inside of yes-or-no-p.

Even if C-x v u does not make a diff, it should always call
yes-or-no-p.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Idea for C-x v u

[Jan Djärv]

Richard Stallman skrev 2011-06-27 15.06:

> Another idea is: if you have not made a diff since the last change in
> the buffer, give an error, "Please look at a diff using C-x v = before
> doing C-x v u".  It is more convenient for the user to make the diff
> with a separate command than to examine it inside of yes-or-no-p.
>
> Even if C-x v u does not make a diff, it should always call
> yes-or-no-p.
>

Why not a customize variable vc-show-diff-before-revert that takes values yes, 
no or ask?  Personally I'd set it to no.  When I revert, it is usually to get 
back to a sane state after inserting debugging code.  No need to see a diff of 
that.

	Jan D.

Re: Idea for C-x v u

[Richard Stallman]

    Why not a customize variable vc-show-diff-before-revert that takes values yes, 
    no or ask?

It is fine to offer those three alternatives, but I think I have
suggested another option that is better than those three.
Have you compared them?
-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Idea for C-x v u

[Jan Djärv]

Hello.

Richard Stallman skrev 2011-06-28 01.03:
>      Why not a customize variable vc-show-diff-before-revert that takes values yes,
>      no or ask?
>
> It is fine to offer those three alternatives, but I think I have
> suggested another option that is better than those three.
> Have you compared them?

Yes.  They lack the possibility of doing a revert without somehow showing a diff.

	Jan D.

Re: Idea for C-x v u

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Richard Stallman skrev 2011-06-28 01.03:
>>      Why not a customize variable vc-show-diff-before-revert that
>> takes values yes,
>>      no or ask?
>>
>> It is fine to offer those three alternatives, but I think I have
>> suggested another option that is better than those three.
>> Have you compared them?
>
> Yes.  They lack the possibility of doing a revert without somehow
> showing a diff.

How do you interpret "it is fine to offer those three alternatives"?

-- 
David Kastrup

Re: Idea for C-x v u

[Jan Djärv]

Sorry for being unclear.
The option suggested by Richard involves showing a diff at some point.
The customize alternative adds this possibility. A fourth value (smart ?) can implement Richards alternative.

I would like to be able to revert without any questions asked or diff shown.

     Jan D.


28 jun 2011 kl. 08:18 skrev David Kastrup <dak@gnu.org>:

> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> Richard Stallman skrev 2011-06-28 01.03:
>>>     Why not a customize variable vc-show-diff-before-revert that
>>> takes values yes,
>>>     no or ask?
>>> 
>>> It is fine to offer those three alternatives, but I think I have
>>> suggested another option that is better than those three.
>>> Have you compared them?
>> 
>> Yes.  They lack the possibility of doing a revert without somehow
>> showing a diff.
> 
> How do you interpret "it is fine to offer those three alternatives"?
> 
> -- 
> David Kastrup
> 

Re: Idea for C-x v u

[Chong Yidong]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Why not a customize variable vc-show-diff-before-revert that takes
> values yes, no or ask?  Personally I'd set it to no.

Really?  If you type `C-x v u' by mistake, you lose your changes with no
possibility of retrieval.  If there's anything that needs a yes-or-no
prompt, vc-revert is it.

Re: Idea for C-x v u

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> Jan Djärv <jan.h.d@swipnet.se> writes:
>
>> Why not a customize variable vc-show-diff-before-revert that takes
>> values yes, no or ask?  Personally I'd set it to no.
>
> Really?  If you type `C-x v u' by mistake, you lose your changes with no
> possibility of retrieval.

Perhaps even "no" could update *vc-diff*, just not show it.  Since "no"
is an expert setting, the expert could then still switch to *vc-diff*
and reapply diffs he wants after all.

-- 
David Kastrup

Re: Idea for C-x v u

[Richard Stallman]

    Perhaps even "no" could update *vc-diff*, just not show it.

That would bring back the same problem I reported: that the old contents
of *vc-diff* are destroyed by the operation.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Idea for C-x v u

[Jan D.]

Chong Yidong skrev 2011-06-28 16:58:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>> Why not a customize variable vc-show-diff-before-revert that takes
>> values yes, no or ask?  Personally I'd set it to no.
>
> Really?  If you type `C-x v u' by mistake, you lose your changes with no
> possibility of retrieval.  If there's anything that needs a yes-or-no
> prompt, vc-revert is it.

I have never hit C-x v u by mistake.  u is pretty far from other common 
vc operations (=, d).  Just because something may be lost doesn't mean 
we should add yes-or-no for them all.  What if there is important text 
in a temporary buffer?  Add yes-or-no for C-x k?  I don't have rm 
aliased to rm -i either.  It works for me and probably others.

Anyway, the default may very well be ask.

	Jan D.

Re: Idea for C-x v u

[Óscar Fuentes]

"Jan D." <jan.h.d@swipnet.se> writes:

>>> Why not a customize variable vc-show-diff-before-revert that takes
>>> values yes, no or ask?  Personally I'd set it to no.
>>
>> Really?  If you type `C-x v u' by mistake, you lose your changes with no
>> possibility of retrieval.  If there's anything that needs a yes-or-no
>> prompt, vc-revert is it.
>
> I have never hit C-x v u by mistake.

I have never hit C-x v u by mistake. Sometimes hitted them on the wrong
buffer, though.

[snip]

> Just because something may be lost
> doesn't mean we should add yes-or-no for them all.

AFAIK, yes-or-no exists precisely with the purpose of being more
cumbersome to answer than y-or-no, as a way of saying: "beware: possible
data loss!"

> What if there is important text in a temporary buffer?

That's your fault. As the name implies, temporary buffers are made for
throwing them away.

> Add yes-or-no for C-x k?

C-x k asks for confirmation with yes-or-no-p when the buffer has unsaved
changes.

[snip]

Re: Idea for C-x v u

[Jan D.]

Óscar Fuentes skrev 2011-06-29 01:55:
> "Jan D."<jan.h.d@swipnet.se>  writes:
>
>>>> Why not a customize variable vc-show-diff-before-revert that takes
>>>> values yes, no or ask?  Personally I'd set it to no.
>>>
>>> Really?  If you type `C-x v u' by mistake, you lose your changes with no
>>> possibility of retrieval.  If there's anything that needs a yes-or-no
>>> prompt, vc-revert is it.
>>
>> I have never hit C-x v u by mistake.
>
> I have never hit C-x v u by mistake. Sometimes hitted them on the wrong
> buffer, though.

Semantics, not an argument.

>
> [snip]
>
>> Just because something may be lost
>> doesn't mean we should add yes-or-no for them all.
>
> AFAIK, yes-or-no exists precisely with the purpose of being more
> cumbersome to answer than y-or-no, as a way of saying: "beware: possible
> data loss!"

The bzr command run in a shell does not ask.  Why must Emacs be so much 
harder to use than the command line?  Isn't the point of vc-mode to be 
convinient?

>
>> What if there is important text in a temporary buffer?
>
> That's your fault. As the name implies, temporary buffers are made for
> throwing them away.
>

And how is that different?  Reverting the wrong file should be my fault 
also.  Why am I treated as a stupid child in one instance but as a 
responsible adult in another?

I don't know why you are arguing for this.  You can set default to be 
ask, I'm just asking for alternatives for those of us that don't what to 
be asked.

	Jan D.

Re: Idea for C-x v u

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> writes:

> The bzr command run in a shell does not ask.

Last time I looked, it waited for me to hit return and allowed me to
backspace over mistakes I made.

-- 
David Kastrup

Re: Idea for C-x v u

[Andreas Röhler]

Am 29.06.2011 01:55, schrieb Óscar Fuentes:
> "Jan D."<jan.h.d@swipnet.se>  writes:
>
>>>> Why not a customize variable vc-show-diff-before-revert that takes
>>>> values yes, no or ask?  Personally I'd set it to no.
>>>
>>> Really?  If you type `C-x v u' by mistake, you lose your changes with no
>>> possibility of retrieval.  If there's anything that needs a yes-or-no
>>> prompt, vc-revert is it.
>>
>> I have never hit C-x v u by mistake.
>
> I have never hit C-x v u by mistake. Sometimes hitted them on the wrong
> buffer, though.
>

Why not simply remove the key?

M-x COMMAND is a little bit harder, so no one will do it by mistake as 
easily

Re: Idea for C-x v u

[Jan D.]

Andreas Röhler skrev 2011-06-29 08:51:
> Am 29.06.2011 01:55, schrieb Óscar Fuentes:
>> "Jan D."<jan.h.d@swipnet.se> writes:
>>
>>>>> Why not a customize variable vc-show-diff-before-revert that takes
>>>>> values yes, no or ask? Personally I'd set it to no.
>>>>
>>>> Really? If you type `C-x v u' by mistake, you lose your changes with no
>>>> possibility of retrieval. If there's anything that needs a yes-or-no
>>>> prompt, vc-revert is it.
>>>
>>> I have never hit C-x v u by mistake.
>>
>> I have never hit C-x v u by mistake. Sometimes hitted them on the wrong
>> buffer, though.
>>
>
> Why not simply remove the key?
>
> M-x COMMAND is a little bit harder, so no one will do it by mistake as
> easily
>

This is becoming silly.

	Jan D.

Re: Idea for C-x v u

[Stefan Monnier]

>> Why not simply remove the key?
>> M-x COMMAND is a little bit harder, so no one will do it by mistake as
>> easily
> This is becoming silly.

Actually, not completely.  I use a local hack to eliminate the confirmation
prompt from revert-buffer in the case that I use M-x revert-buffer
rather than a keybinding.

Reverting isn't that common a command and "vc-revert" is just as easy to
remember as "C-x v u".


        Stefan

RE: Idea for C-x v u

[Drew Adams]

> I use a local hack to eliminate the confirmation
> prompt from revert-buffer in the case that I use
> M-x revert-buffer rather than a keybinding.

FWIW, I do the same - er, the opposite.  I bind `F5' to revert with no
confirmation.  I use that when I want to revert quickly (quick key, no
confirmation).

That is also the MS Windows key for updating (which is what most of the Emacs
"revert" functions really do - they do not revert to a previous state).

Re: Idea for C-x v u

[Andreas Röhler]

Am 27.06.2011 15:06, schrieb Richard Stallman:
> It is definitely a good idea to check the diffs of a file before
> reverting a change, but normally it's a waste of time for C-x v u to
> do that because I will have done it manually.
>
> However, if I ever forget to do that, it wouldn't hurt for C-x v u to
> remind me.

Hi,

think it might pay more to consider the conditions when forgetting occurs.

If it's just to late, a warning might make you still more forgetting.

BTW a feature I most enjoy is abolish warnings when a buffer get's closed.

(defun kill-buffer-unconditional (&optional puffer)
   " "
   (interactive)
   (when puffer
     (set-buffer puffer)
     (switch-to-buffer (current-buffer))
     )
   (set-buffer-modified-p 'nil)
   (kill-buffer (current-buffer)))

Well, sorry, that's again the opposite direction :)

Seriously: usually run two different VC's at same time: RCS in the 
background, committing more often --and without messages-- while above 
bazaar or whatever gets it, when it seems done.



Cheers,

Andreas