From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase. Date: Wed, 06 Jan 2016 17:40:45 +0200 Message-ID: <83vb763ede.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1452094880 30649 80.91.229.3 (6 Jan 2016 15:41:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Jan 2016 15:41:20 +0000 (UTC) Cc: 22300@debbugs.gnu.org, jwiegley@gmail.com To: Keith David Bershatsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 06 16:41:10 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aGqCz-0003rg-9i for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Jan 2016 16:41:09 +0100 Original-Received: from localhost ([::1]:54803 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGqCy-0007oB-MS for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Jan 2016 10:41:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGqCu-0007nW-AV for bug-gnu-emacs@gnu.org; Wed, 06 Jan 2016 10:41:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aGqCs-0004Lr-Qa for bug-gnu-emacs@gnu.org; Wed, 06 Jan 2016 10:41:04 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52246) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGqCs-0004Ln-Mk for bug-gnu-emacs@gnu.org; Wed, 06 Jan 2016 10:41:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aGqCs-00008h-Fs for bug-gnu-emacs@gnu.org; Wed, 06 Jan 2016 10:41:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Jan 2016 15:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22300 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22300-submit@debbugs.gnu.org id=B22300.1452094856514 (code B ref 22300); Wed, 06 Jan 2016 15:41:02 +0000 Original-Received: (at 22300) by debbugs.gnu.org; 6 Jan 2016 15:40:56 +0000 Original-Received: from localhost ([127.0.0.1]:40466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aGqCl-00008E-RR for submit@debbugs.gnu.org; Wed, 06 Jan 2016 10:40:56 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:56479) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aGqCj-000080-MV for 22300@debbugs.gnu.org; Wed, 06 Jan 2016 10:40:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aGqCd-0004J2-E2 for 22300@debbugs.gnu.org; Wed, 06 Jan 2016 10:40:48 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50700) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGqCU-0004Hz-GV; Wed, 06 Jan 2016 10:40:38 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4885 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aGqCS-0006mS-53; Wed, 06 Jan 2016 10:40:38 -0500 In-reply-to: (message from Keith David Bershatsky on Tue, 05 Jan 2016 19:56:35 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:111296 Archived-At: > Date: Tue, 05 Jan 2016 19:56:35 -0800 > From: Keith David Bershatsky > Cc: 22300@debbugs.gnu.org,Drew Adams ,John Wiegley > > Perhaps my misunderstanding stems from a belief that > "/Users/HOME/Desktop/foo/FOO" is a bad thing (to have as a result) when > `dired-create-files` runs `(setq to (funcall name-constructor from))`. I was > looking at this as a black and white situation -- i.e., `from` is > "/Users/HOME/Desktop/FOO"; and, `to` should be "/Users/HOME/Desktop/foo". We agree about that, I think. However, what you actually wrote was that you thought the result of expand-file-name in this case was incorrect. But expand-file-name and file-name-nondirectory are general-purpose functions, they do nothing specific to Dired, and their result in this case is correct and expected. It's the code that calls them that needs to be fixed, see below. > Because I do not understand the usefulness of "/Users/HOME/Desktop/foo/FOO" > (when the user had explicitly entered a new name of "/Users/HOME/Desktop/foo"), > I was expecting `(setq to (funcall name-constructor from))` to return > "/Users/HOME/Desktop/foo" in this particular situation. The logic of dired-do-rename in this case is very simple, and it mimics the logic of the 'mv' command when its argument is a directory. When given the command "mv foo bar", it does this: . if the target 'bar' is an existing directory, it moves 'foo' to be a subdirectory of 'bar', i.e. 'foo' will become 'bar/foo' . otherwise, 'foo' is renamed to the new name 'bar' What happens on case-insensitive filesystems is that when 'foo' exists, so does 'FOO' and 'Foo' and 'fOO'. So the above logic decides that the target is an existing directory, and attempts to move 'foo' into itself, which fails. So it's that logic which needs to be augmented for case-insensitive filesystems. But the place to augment it is not where we compute 'foo/bar' (or in this case 'foo/FOO'), the place is where the logic decides which of the above two alternatives to take. This same logic is implemented both in Dired and in rename-file, so it should be augmented in both of these places. As we've done for MS-Windows and MS-DOS. > If I am understanding you correctly, you believe that > "/Users/HOME/Desktop/foo/FOO" is a good thing at this point in the `elisp` code > -- to be dealt with further on down when `dired-create-files` does its thing > (with the assistance of some C-source code stuff under the hood). No, the logic that should be augmented is in dired-do-create-files, and it happens _before_ dired-create-files is called. By the time dired-create-files is called it's too late, because dired-do-create-files already decided which of the above 2 alternatives to use. Look at the source of dired-do-create-files, and you will see code in dired-do-create-files that special-cases MS-Windows to augment the logic. > From my layman's perspective (i.e., not a programmer by trade), I was thinking > that `(setq to (funcall name-constructor from))` should yield the absolute path > of what the user explicitly entered as the new name for the folder or file. I > had assumed, perhaps erroneously, that things would go awry rather quickly if > the value of "to" was incorrect at the outset of `dired-create-files`. The logic to which I alluded above takes care of that: it calls dired-create-files with a different name-constructor function, which does what you want: (dired-create-files file-creator operation fn-list (if into-dir ; target is a directory ;; This function uses fluid variable target when called ;; inside dired-create-files: (function (lambda (from) (expand-file-name (file-name-nondirectory from) target))) (function (lambda (_from) target))) marker-char) Which name-constructor function is passed to dired-create-files depends on the value of into-dir. The special-case code for MS-Windows takes care of making that value nil, so that the constructor which produces "incorrect" file name is not called by dired-create-files. To summarize: there is already code in dired-do-create-files that will DTRT in this case for case-insensitive filesystems. It just needs to be invoked on OS X when the underlying filesystem is case-insensitive, and the only problem preventing us from fixing this is that we don't yet have a way to tell that on OS X as we do on other systems. IOW, all it takes to fix this is to write an OS X specific predicate function that would accept a file name and returns and indication whether that file lives on a case-insensitive filesystem. Then we should just use that function in Dired and in rename-file.