bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCA


From: Eli Zaretskii
Subject: bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
Date: Tue, 05 Jan 2016 18:46:00 +0200

> Date:  Mon, 04 Jan 2016 12:51:01 -0800
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  22300@debbugs.gnu.org,Drew Adams <drew.adams@oracle.com>,John Wiegley 
> <jwiegley@gmail.com>
> 
> I agree that `rename-file` could use a fix.
> 
> Once `rename-file` is ironed out on the C-source code level, I believe the 
> tail 
> end of `dired-do-create-files` will also need to be fixed because the 
> `name-constructor`
> 
> (function (lambda (from) (expand-file-name (file-name-nondirectory from) 
> target)))
> 
> returns the wrong path when used by dired-create-files.  
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22300#29

Why do you think the result of that is wrong?  I think it's exactly as
expected, because this:

  (expand-file-name "SOMETHING" "/Users/HOME/Desktop/foo")

should produce "/Users/HOME/Desktop/foo/SOMETHING" for _any_ value of
SOMETHING, even if SOMETHING is exactly "foo", in the same letter-case
as the last component of "/Users/HOME/Desktop/foo".  That's what
expand-file-name does -- it produces a file name in the directory that
is its 2nd argument.

> So, I believe it will be both areas of Emacs that need some TLC.

There's already code in dired-create-files that handles the same
problem for MS-Windows and MS-DOS, it just needs to be reused for OS
X.  The tricky part with OS X is that its filesystems are not always
case-insensitive, so we need (a) a way to tell whether the filesystem
of the file being renamed is case-insensitive, and (b) tweak that code
a bit to use the above test instead of just testing the OS type.

In any case, invoking 'mv' as a workaround sounds not very clean to
me.  Emacs ought to do whatever 'mv' does to handle this problem by
itself.

I cannot produce a patch for these issues, as I don't have access to
OS X and the man page that John pointed to indicates that calling
getattrlist needs some non-trivial code (the API might not be
supported by the OS, and if it does, the specific attributes might not
be supported, so the code will have to include some reasonable
fallbacks).  So the code will need quite a bit of testing before it
becomes reliable enough to commit to the repository.  I hope someone
with good access to OS X will be able to come up with the changes and
test them.

Thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]