bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Keith David Bershatsky]

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

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.

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

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

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Tue, 05 Jan 2016 20:28:21 +0200,
Eli Zaretskii wrote:
> 
>  Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
> 
> > Date:  Tue, 05 Jan 2016 09:27:03 -0800
> > From:  Keith David Bershatsky <esq@lawlist.com>
> > Cc:  22300@debbugs.gnu.org,Drew Adams <drew.adams@oracle.com>,John Wiegley 
> > <jwiegley@gmail.com>
> > 
> > Actually, I'm not sure why the `elisp` makes the target 
> > "/Users/HOME/Desktop/foo/FOO", instead of just "/Users/HOME/Desktop/foo".
> > 
> > When I evaluate
> > 
> >   (funcall (lambda (from) (expand-file-name (file-name-nondirectory from) 
> > "/Users/HOME/Desktop/foo" )) "/Users/HOME/Desktop/FOO")
> > 
> > I get the former incorrect value -- i.e., "/Users/HOME/Desktop/foo/FOO", 
> > instead of just "/Users/HOME/Desktop/foo".
> 
> Maybe there's some misunderstanding here.  Let me explain why I think
> this is the correct expected result.
> 
> First, (file-name-nondirectory "/Users/HOME/Desktop/FOO") yields
> "FOO", as it should, right?
> 
> Then (expand-file-name "FOO" "/Users/HOME/Desktop/foo") returns
> "/Users/HOME/Desktop/foo/FOO" because that's what it's supposed to do:
> it returns a file named "FOO" in the directory "/Users/HOME/Desktop/foo".
> 
> Can you tell what in this reasoning seems incorrect, and why?
> 
> > And that becomes the initial value of "to" when used by 
> > `dired-create-files` -- (setq to (funcall name-constructor from))
> 
> The code that special-cases MS-Windows and MS-DOS prevents this from
> causing the unexpected results.