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

Previous Next

Full log

Message #89 received at 22300 <at> debbugs.gnu.org (full text, mbox):

From: Keith David Bershatsky <esq <at> lawlist.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22300 <at> debbugs.gnu.org, John Wiegley <jwiegley <at> gmail.com>,
 Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#22300: 25.1.50;
 Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
Date: Tue, 05 Jan 2016 19:56:35 -0800

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 <at> lawlist.com>
> > Cc:  22300 <at> debbugs.gnu.org,Drew Adams <drew.adams <at> oracle.com>,John Wiegley <jwiegley <at> 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.

Previous Next

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