GNU bug report logs - #39057
27.0.60; copy-file interactive VS from lisp disagreement

Previous Next

Package: emacs;

Reported by: Tino Calancha <tino.calancha <at> gmail.com>

Date: Thu, 9 Jan 2020 21:04:01 UTC

Severity: normal

Found in version 27.0.60

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: tino.calancha <at> gmail.com, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 39057 <at> debbugs.gnu.org
Subject: bug#39057: 27.0.60; copy-file interactive VS from lisp disagreement
Date: Fri, 10 Jan 2020 16:12:37 +0200
> Date: Fri, 10 Jan 2020 15:48:02 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 39057 <at> debbugs.gnu.org
> 
> > I have printed out newname before the line
> > newname = expand_cp_target (file, newname);
> > at src/fileio.c
> > 
> > I)
> > M-: (copy-file "/tmp/foo" "~/") RET
> > ;; it shows "~/" as expected
> > 
> > II)
> > M-x: copy-file RET /tmp/foo RET ~/ RET
> > ;; it shows "~" (the '/' is missing)
> 
> Why would it be missing? which code removes it, if you typed it?

Answering myself: this is a problem with completion routines: when the
user types a file name that is exactly identical to the default (or
just presses RET, which is the same), then the completion code in
read-file-name-internal returns a value that has the trailing slash
stripped.  And we now require a trailing slash to recognize NEWNAME as
a directory.

Maybe Stefan can help us out here.




This bug report was last modified 5 years and 185 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.