bug#27986: 26.0.50; 'rename-file' can rename files without confirmation

[Eli Zaretskii <eliz@gnu.org>]

> Cc: monnier@IRO.UMontreal.CA, johnw@gnu.org, rms@gnu.org,
>  p.stephani2@gmail.com, 27986@debbugs.gnu.org, michael.albinus@gmx.de
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 11 Sep 2017 09:45:48 -0700
> 
> On 09/11/2017 07:47 AM, Eli Zaretskii wrote:
> > do these changes modify interactive
> > behavior in incompatible ways?  I thought we agreed to leave the
> > interactive behavior intact, and only change the non-interactive uses.
> >
> That wasn't my understanding. In our last email exchange about 
> interactivity I proposed that Emacs prompt the user when the destination 
> is not a directory name but happens to be a directory (see 
> Bug#27986#97), but you were dubious about that (Bug#27986#100) so I left 
> it alone.
> 
> I normally use dired to rename files in Emacs, and dired's behavior 
> hasn't changed as far as I can tell. Where there is a bit of a change is 
> when using M-x rename-file directly. Here, in the typical case with file 
> name completion there is still no difference, since names of destination 
> directories are completed to have trailing /. However, if one uses "M-x 
> rename-file foo RET and then laboriously types out the name of an 
> existing directory /tmp/destination-dir without using completion and 
> without trailing / before hitting RET, one will notice a difference: 
> rename-file will now say "File /tmp/destination-dir already exists; 
> rename to it anyway? (yes or no)" and if one types "yes" the rename will 
> typically fail. So yes, this is a (noisy) incompatibility with previous 
> usage. If you like I can go back and implement the suggestion in 
> Bug#27986#97; this would be more-compatible with existing usage. I 
> suggest leaving it alone, though, as things are simpler and easier to 
> explain the way they are.

I think there was a confusion here between interactive and
non-interactive uses of rename-file.  For interactive use, AFAIR we
agreed that the behavior should stay as before, in particular to be
consistent with e.g. invocation of 'mv' from the shell prompt.

For non-interactive use, we agreed to change the behavior wrt
directories, with a slight preference to signaling an error even if
the target is an empty directory.